ATAG is a set of guidelines for the accessibility of authoring tools. In this post I'll talk about what it is and why it matters.

Most people working on websites will be familiar with WCAG, the Web Content Accessibility Guidelines. There are two more related standards, one for user agents (like browsers) and one for authoring tools (like CMSes, WYSIWYG or Markdown editors, e-learning platforms and website creators). They work together: if we care about the accessibility of web content, we should also care about how it is created (in authoring tools) and displayed (in user agents).

“Web content” in accessibility standards refers to websites, apps and other content on the web. I like to think of it as the HTML that browsers serve to the user when they access your website or app. There isn't a definition for “web content” in WCAG, but there is one for “web content technologies”. From that definition we can draw that web content includes anything that is rendered by user agents, like HTML and SVGs.

Why ATAG matters

Better accessibility of content tools is critical for three reasons:

1. Everyone should be able to create content for the web, regardless of disability.
2. Authoring tools are in between the user and the HTML they create.
3. The authoring tool can have the unique ability to prevent inaccessibility.

Let's look at these reasons in a little more detail.

Content creation is for everyone

‘The web is for everyone’, as web inventor Tim Berners-Lee likes to say, applies as much to accessing websites as it does to creating them. His first browser had both viewing and editing capabilities, so clearly the web was always meant to be about both consumption and creation. Many of us love to create vlogs, set up online classes, publish recipes, tweet, make TikToks, create art… this should just work for people with or without disabilities. If content creation tools have barriers, that's everyone's loss.

The first web browser, “WorldWideWeb”, was also an editor.

In business, it would be illogical (and illegal) if you couldn't hire content professionals with disabilities, just because they can't use your content tools. In your company today, Harry from marketing might be able to use a mouse, but when he leaves his successor might only use keyboards.

Support for all of HTML

The second part to authoring tool accessibility is their ability to output accessible content. Imagine two tools to create bulleted lists. One does this with divs and images of bullets, the other uses the standard ul and li elements. The latter is what we need, and not just when dealing with lists, but for all kinds of markup:

• tables with captions
• videos with track elements and muted and autoplay attributes
• fieldsets with legends
• images with alt attributes
• translated content with lang attributes

Not all tools let you create all or these structures, at which point they basically become the accessibility issue.

Authoring tools as accessibility assistants

Even cooler than outputting sensible and appropriate markup, authoring tools could provide hints. They could try to be a helpful “accessibility assistant”, by point our potential barriers when they notice you're creating them. For instance, if an authoring tool lets you pick a foreground and background colour, it could warn you when you pick two colours that have insufficient contrast.

ATAG recommends various ways of assisting with making content more accessible: accessible default components and templates, solid documentation and, as described above, suggestions and hints.

Who meets ATAG

At the time I am writing this, I am not aware of any authoring tools that meet 100% of ATAG, as in, all criteria at level A or AA. That doesn't mean all is lost, every bit helps and there are a lot of authoring tools that meet many bits of the standard.

With the ATAG Report Tool, people can create a report with specific details about which parts of ATAG they do or do not meet.

As described above, there are lots of good reasons to try and meet ATAG. It is a worthwhile pursuit for authoring tool makers and a worthwhile request for procuring departments to put in tenders.

What's in ATAG

There are two parts to the ATAG standard:

• editing experience (part A): does the tool work for people with disabilities?
• output (part B): does the tool output accessible content?

If you're still with me, I'd like to describe ATAG in a bit more detail. Like WCAG, ATAG has Principles, Guidelines and Success Criteria. In the following sections, I will discuss the Principles and Guidelines in my own words. Full and official wording is in the ATAG 2.0, published by the W3C. This is not legal advice.

Authoring tool UI meets accessibility guidelines

• Web-based functionality is accessible:
  The full editing experience conforms to WCAG 2.0 or other accessibility guidelines. (A.1.1)
• Non-web-based functionality is accessible:
  The interface conforms to platform-specific accessibility guidelines. (This one specifically applies to authoring tools that are not web-based, which was more common when ATAG came out) (A.1.2)

Editing UI is perceivable

• Alternative content available to editors:
  If there is anything visible that is not text, like icons, images or video, there is alternative text available. (A.2.1)
• What's indicated visually in the UI can be programmatically determined:
  Status indicators (like changes or spelling errors) and text properties (like italics or bold) are conveyed to users of assistive technologies. (A.2.2)

Editing UI operable

• Works with keyboard:
  Everything that can be done with a mouse, can just as easily be done with a keyboard, including drag and drop and drawing capabilities. There should be no keyboard traps. Keyboard usage should be efficient and easier to use than just with sequential access (for example: use WAI-ARIA landmarks or offer keyboard shortcuts). (A.3.1)
• Enough time:
  Time limits in the editor, like for auto-save, can be turned off or extended (some exceptions apply). (A.3.2)
• Flashing content optional:
  Flashing content, like videos, including previews of that kind of content, can be paused or turned off. (A.3.3)
• Content can be navigated by structure:
  Users can navigate quicker by structure, for example headings, lists or HTML elements. (A.3.4)
• Content searchable:
  Users can search in text content, results are focused when shown. If there are no matches, this is indicated. User can search in two directions (backwards and forwards). (A.3.5)
• Supports display preferences:
  If there are user settings for display, this only affects the editing view, not the output. If a content editor uses OS settings like high contrast mode or their own stylesheet, this does not break the editing experience. (A.3.6)
• Previews are accessible:
  When the tool shows a preview of the content, that preview is at least as accessible as in current browsers and other user agents. (A.3.7)

Editing UI is understandable

• Helps editor prevent and correct mistakes:
  The tool lets users undo changes and settings. (A.4.1)
• (Accessibility) features documented:
  The tool has documentation for all features, including accessibility features. (A.4.2)

Fully automatic processes produce accessible content

• Generates accessible markup:
  When the tool generates markup, that markup is accessible. If accesssibility information is required, like alternative texts, the content editor is prompted to provide that information. (B.1.1)
• Preserves accessibility information:
  If content is pasted from a word processor or converted from one format into another, any accessibility information is preserved. (B.1.2)

Supports producing accessible content

• Accessible content production is possible:
  If some options produce more accessible content than others, they are displayed more prominently. If properties and attributes can be set, those relevant for accessibility can also be set. (B.2.1)
• Editors guided:
  Editors are guided to produce accessible content. (B.2.2)
• Text alternatives can be managed:
  There is a tool for providing text alternatives to “non-text content”, like images, videos and data visualisation. (B.2.3)
• Accessible templates available:
  There are accessible templates available. If there is a repository of templates, it is easy to find the ones that prioritise accessibility. (B.2.4)
• Accessible components/plug-ins available:
  If any components or plugins are built-in to the tool, they are accessible. If there is a gallery of components or plug-ins, it indicates accessible options. (B.2.5)

Helps with improving the accessibility of existing content

• Checks accessibility automatically:
  Has built-in checks for common accessibility problems, for example a check to identify missing alternative text. (B.3.1)
• Helps content editors fix problems:
  Provides suggestions to content editor about accessibility problems. (B.3.2)

Promotes and integrates accessibility features

• Accessibility features prominent:
  Accessibility features are on by default and a prominent part of the editing workflow. Documentation shows examples of how to create accessible content, for instance with example markup or screenshots. (B.4.1)
• Documentation promotes accessibility:
  The tool provides suggestions to content editors about accessibility problems. (B.4.2)

Wrapping up

In summary, ATAG recommends two things:

• a fully accessible authoring tool interface (basically, one that meets WCAG)
• the possibility to produce accessible “web content” and help with that in the form of documentation, default templates and suggestions

The instructions are more detailed in the standard, but that's what it comes down to in most cases.

Though the standard is only met at most partially by most tools today, a wider landscape of ATAG-supporting tools would be fantastic for web accessibility (because it's easier when you do it earlier). Increasingly, authoring tool makers start to realise this and that is wonderful.

---

Originally posted as ATAG: the standard for accessibility of content creation on Hidde's blog.

Reply via email

I worked in web accessibility in different setups: as a freelance developer specialised in accessibility, as a WCAG auditor and as a full time team member of the W3C's Web Accessibility Initiative. As a developer I would receive audit reports, as an auditor I would write them and as a WAI team member I would work on promoting and documenting the standards these audits are based on. An observation: in the developer role, advocating for accessibility can be the hardest in various ways.

Perspectives

Writing audit reports, a company would request in-depth feedback with the intent to fix stuff (ideally; sometimes it's just because the law says they have to 🤷). At WAI, I engaged with accessibility standards and practices on more of a meta level. When developing tools or resources, I never had to explain why I wanted videos to be captioned or have a visible focus indicator on the stuff we published, because everyone else on the team had worked with WCAG for years, often decades, and many had lived experienced to draw from.

In the developer role, I had more responsibilities than ensuring accessibility, I also had to make sure our assets didn't break under an updated Content-Security-Policy, fix a deployment pipeline or figure out with which templating language my client could use their design system most widely. And then there was accessibility, my main interest and priority. I mean, why have a web app if it's inaccessible… I would often do that work under the radar, sometimes because other developers in the team weren't interested or skilled in that particular area, sometimes because I felt it would take more time to get extra time for a thing than to just do the thing.

Accessibility and support

Accessibility is hard to do bottom up, I found. In some cases, especially when working for government and non profits, accessibility would explicitly be in the requirements and or I would specifically be hired for that expertise. This was great and gave something to work with. In other situations, it was much more of a challenge. Time would go into making a business case (I learned about WAI's business case page late), trying to get budget for external audits or screenreader licenses (procuring JAWS is no fun) and figuring out how to go about recruiting users with disabilities for user tests. And that's still the meta stuff.

When it comes to writing code as an accessibility specialised developer, you can ensure you follow lots of users with disabilities and accessibility specialists to try and learn about implementation issues early. You can find lots of good resources. My favourite are blog posts by developers and accessibility specialists who have tested a solution with users and go at length to describe all the ifs and buts you need to understand the nuance and compromise. But let's be honest, if you want to rely on the official documentation (normative or not) that is also used by browsers and assistive technologies, it can be pretty difficult to find out exactly what to do.

Gaps in documentation

There are systematic problems in accessibility standards documentation:

• outdated examples are often not marked as outdated and hardly ever removed
• it is not always clear if examples are ready to use or merely displays of how stuff ‘should work’ if all browsers and assistive technologies followed the standards (a problem ARIA Authoring Practices Guide has)
• it's hard to find user-tested examples
• the guidance can be scattered across many places

From the standards org perspective this is all explainable. There is a lot of work on few plates, the consensus process and organisational structure have, besides benefits, an impact on how responsibilities can be and are distributed. It's understandable, but has an effect. It impacts how effectively developers (and designers, content editors etc) can build accessible products. Even if from the standards side of things, you can only do so much to try and have standards that are implemented interoperably by browsers and assistive technology makers. There are relatively few people in the space who specialise in this.

Channeling one's inner developer

From the auditor's perspective, as well as from the standards org perspective, accessibility looks different. The system is, sadly, ableist and almost every website you look at has accessibility conformance and usability issues… it has often frustrated me and made me more cynical than I want to be. You write down the same issues over and over, knowing they are just a few lines of code. I always had to channel my inner developer again, and remember what it can be like. Yes, removing the line outline: none is trivial, and it's extremely ableist to keep it in, but what can a developer do if the QA and/or design departments flag it as a bug and they're the only one on the team who ‘gets’ this need. Let's not blame the developer, let's blame the ableist system we all operate in. Or, as Adrian Roselli recently said, ‘arm developers’ with useful feedback so that they are more enpowered to make the changes (being an auditor often puts one in this somewhat rewarding position).

I don't know where I'm going with this, but thinking about what I'd like to see for the web if I had a magic wand, I would want to see better accessibility documentation (clear, up to date and user tested), more engineering budget for compatibility between standards, browsers and assistive technologies and have legal requirements that make it so that serious organisations see accessibility like they see security and data protection. At least some if not all of these wishes are in progress, of course, in various places… they have been for years, I just wish ✨ change ✨ could be sooner.

Developer experience and user experience

Some say ‘user experience is more important than developer experience’, and I'm all for that sentiment. Of course. Web accessibility is all about users with disabilities. That's the point of it. Developers ‘just’ need to do the job.

But companies who make products they want developers to use effectively, like browsers, have dedicated developer experience teams to try and ensure that developers can use their stuff well. To try and set them up for success. In their case, that makes good business. Might we, as the accessibility field, also benefit from better developer experience (of web accessibility) to get to more widely spread user experience?

What if standards orgs hired content designers, like governments with similarly complex content do so successfully? Isn't explaining standards essential when making standards? In the majority of cases, an inaccessible pattern can be addressed in code, by developers. Might some focus on developer experience be a sensible means to an end? If it was less frustrating to find out how to build, say, a combobox, in practice not in theory, we would more easily get to the end goal: less frustrating experiences to end users.

Besides a focus on quality of documentation, I feel like we should keep the individual developer's perspective in mind, acknowledging they may have constraints beyond their control. We could contribute to fight those constraints by providing executives and team leads with the right tools too. We've got to set teams up for success. That way we all win.

---

Originally posted as Accessibility from different perspectives on Hidde's blog.

Reply via email

Last month, I wrote about fixing common accessibility issues. That post seems to have resonated with people, so I have written up five more fixes you could do to your codebase today. Let's go!

I have tried to make these as hands-on as possible. For each, you'll find a description of what the issue problem, how fixing it helps end users and which team member can take the lead on it.

In my last post, the issues were what WebAIM described as the top 5 isuses in their WebAIM Million project. This time, I have looked into accessibility audit reports I wrote and combined that with what Deque wrote about coverage and the numbers that 200OK took from public data about common issues across the Dutch government websites (taken from the register of accessibility statements).

Missing focus states

If an element on a page is focusable, it needs a focus state. This goes for all interactive elements:

a (if the href attribute is present), audio (if the controls attribute is present), button, details, embed, iframe, img (if the usemap attribute is present), input (if the type attribute is not in the Hidden state), label, select, textarea, video (if the controls attribute is present)

(from: HTML, Interactive content)

It also goes for as well for divs or other elements that have click and keyboard events (but best use buttons in those cases while you're at it; see below).

For all of these, designers can come up with a focused state (ideally this is one thing, eg an outline, that is the same for all elements on the site, so that it's easy to spot when focus moves). Developers can remove any outline: nones from their stylesheets (if you must undo default outlines, because you're using some other CSS property for outlines, best use outline-color: transparent instead so that it doesn't break in High Contrast Mode).

Browsers can also ship with a feature that forces focus indication, some do. Users could also use user styles, though no website owner should expect they will, it requires CSS knowledge and a plugin in most browsers these days.

More: Indicating focus to improve accessibility

Missing captions and transcriptions

When you publish how-to videos, vlogs, podcasts, basically anything that has audio and/or video, the content should be available as text, too.

My friend Darice de Cuba has written about how to create podcasts transcripts. Part of this applies to video, too. Captions and transcripts are created for end users with disabilities. They also benefit users who are learning your language and users who want to catch your content but are in public without headphones. Transcripts and captions can even benefit your SEO strategy.

One of my own videos with captions turned on (It's the markup that matters on YouTube)

Writing out all recorded content isn't necessarily something you could do today as it can take a bit of time, especially if you have lots of content. I still felt I could include this common issue here, because most teams don't do this themselves and outsource the work to specialised agencies. These are costs you can budget for. If there is too much current content, you could consider starting with future or most popular content?

Project managers can make sure captioning and transcribing are part of any project that includes audio or video. Developers can ensure the CMS has fields for transcripts and captions. Designers can design the UI to allow for full transcript display. Social media managers can produce caption any videos for LinkedIn or Twitter.

Invalid HTML

There used to be a time when websites would proudly display a badge that showed the current page was composed of valid HTML. These badges have disappeared from most websites, but validation is still a sound accessibility strategy.

The HTML of web pages is parsed by lots of tools, like browsers and assistive technologies, if the HTML is invalid it can lead to unexpected bugs. Simon Pieters' Idiosyncrasies of the HTML parser is a great book about this, especially if you want a deep dive into what could possibly go wrong.

Since HTML5, error handling is specified as part of HTML, which should improve unexpected bugs due to invalid HTML, but there are still plenty of accessibility problems you can find by validating your HTML. Did you accidentally nest a <button> inside of a <a>? The validator will call it out and help you prevent the myriad of problems that could cause.

So… developers and test automation engineers can ensure HTML validation is included in tests.

More: validator.nu that allows inputting HTML by URL, file upload or pasting is (can run from command line per instructions in README)

Headings that don't describe their section

In HTML, headings (h1-h6 elements) exist in the context of a section, they are supposed to describe the content that follows them. When I say section, I don't mean specifically content in a <section> (or other “sectioning content”), I mean more generically content that forms a logical part of a page, regardless of which HTML element used.

Descriptive headings are useful, because some users access headings in a page as a table of contents. For example, your one page band website could have a “Discography”, “Tickets” and “Merchandise” headings. Your search application could have a filters section with a “Filters” heading. Some websites useheading tags (h1-h6) to mark up text that's “just” bigger or bolder, which will break the experience for people who navigate by headings, as it will add entries into their navigation that don't describe sections.

Content designers can ensure headings describe sections, and that things that don't describe sections aren't marked up as headings. developers can ensure that if there are headings in their front-end components, that they describe content and don't just exist for style reasons.

Can't do all things with just a keyboard

Accordions, tabs, ‘toggletip’ triggers… if your page or app has things that users can click on, they should also be usable with just a keyboard.

Fixing this issue is great for people who can only use a keyboard, and for users with numerous other devices that may or may not be keyboard like (there's some examples in How people with disabilities use the web).

Often, this issue occurs when clickable elements are divs with a click handler. Developers can make sure they use a button element whenever things can be clicked (or a if it navigates to somewhere). Yes, you need some CSS to change the styling to your liking, but this is do-able, it makes it easier for you to get all of the web platform's buttonness in one package and, most importantly, your users will thank you.

Wrapping up

So, that's five more common accessibility issue that you could fix in your codebase today. I hope this is helpful to some readers. Should you still have questions about any of these, please feel free to contact me on Twitter (@hdv) or via email.

---

Originally posted as More common accessibility issues that you can fix today on Hidde's blog.

Reply via email

I use Firefox as my main browser, both for development and for just regular… browsing. Increasingly, core functionality of websites breaks for me, as, presumably, not all developers test in Firefox anymore.

Yesterday, for instance. I signed up for a conference and their signup form wouldn't submit. It relied on JavaScript, which borked in Firefox. Some ES feature was used that isn't supported in Firefox yet, with no feature checks or fallbacks. As forms have been part of the web for decades, in all browsers, my primary response was ‘hey this shouldn't have to be broken!’

Testing your work in Firefox matters. Right? Well, it does to me, like testing in lots of browsers and assistive tech does. When I shared this on Twitter, realising a little late that this point is controversial, I saw some themes in the responses.

Some said Firefox should test with their websites. They do, actually… Mozilla hosts and sponsors the web compat community which helps debug sites that work in one browser and not another and feeds into improving those browsers. This is really hard and complex work, I remember from hanging out some of the people working on this when I was at Mozilla (the stories…). I recommend Mike Taylor's talk about web compat at View Source 2019.

Others signalled they found it too much work. For a large part of my career, front-end development was all about making stuff work across browsers, because they weren't as well aligned as they are today. I, for one, am so happy to be past the years of needing multiple VMs to test versions of Internet Explorer. With tools like Browserstack and Browsersync, we've come a long way.

Lastly, some said it's ‘not worth it’ given Firefox's marketshare. To be honest, I hadn't checked Firefox's market share before I tweeted and did not realise how small it is today 😢. The percentage is small.

I guess I can understand the idea that organisations prioritise browser support by browser market share. But shouldn't we want browser diversity and browser engine diversity? (This nuance is nicely explained in Brian Kardell's What is actually a web browser?).

Yes, some of the web's smartest and nicest minds work on Chrome and Chromium, I have see them do great work improving the web and prioritise (mostly) the right things over and over. Increasingly so now that the Edge people are also working on making Chromium better. I'm a fan of their work and most of the time Google push the web forward in ways it would simply not have without them. But, as Tim Kadlec mentions in a blog post, they don't always.

It's in everyone's interest to not give one company a near monopoly over what the web can do through their browser, or a handful of companies through their engine (Microsoft Edge, Samsung Internet, Brave and many others also use Chromium). Various people wrote about this when Edge announced they would use Chromium. “No single company, let alone a user-tracking advertising giant, should control the internet”, said Jeffrey Zeldman in Browser diversity starts with us. Competition is about growing, wrote Rachel Nabors, in a post where she compares the browser ecoystem with the world's ecosystem. Hurting engine diversity hurts the web, explains Andre Garzia.

Less browser engines doesn't necessarily mean that all decision making power lies with one company, though. In Beyond Browser Vendors, Brian Kardell mentions the origin story of CSS Grid as an example: originally conceived by CSS co-inventors Bert Bos and Håkon Wium Lie, further worked on years later by Bert Bos, then picked up by Microsoft and ultimately paid for by Bloomberg to be implemented in Webkit and Chromium by teams from Igalia, a company that works on all major browsers and JavaScript engines. This is also how potential futures of the web can be decided.

In any case… I'm curious how thinking may have shifted over the last years. How do you think about browser testing in 2022?

---

Originally posted as Test in many browsers on Hidde's blog.

Reply via email

The health and inclusiveness of a community can be affected by action, but also by inaction. In this post, I'll share some reflections on banning pretty much objectively bad content and on issues with the word ‘cancel culture’.

When a political party tries to attract voters with racism, sexism and homophobia, should all pages on their website be banned from a healthy, inclusive coder community? Last week I got into a discussion I didn't expect I would get into… it could be summarised as this question. (Spoiler alert: to me, the answer is yes).

In one of my communities, someone had shared a link to a blog post on the website of a controversial, far right political party that perpetuates all sorts of racism, sexism, homophobia and misinformation. Just like that, a link in the #general channel that all members join by default, for roughly 7000 people to see, who signed up to collaborate on and talk about code. The blog post itself didn't contain such things per se, but the party owns the website.

In short: I feel such a link should not be allowed on a healthy, inclusive coder community. Failing to moderate this content can make those marginalised by systemic racism, sexism and homophobia feel unwanted. It signals that this community has no specific problems with the link, at least not specific enough to ban it. It could unintendedly scare people away and send out a message about who belongs. Should a community prioritise people who want to share or say whatever they want or people who don't want to have racism, sexism or homophobia affect their daily lives?

My point is… healthy, inclusive communities do the work to make people, especially those who are marginalised, feel wanted. For so many reasons. Sure, banning the post and maybe even the poster could make the poster feel unwanted. That's not great. But… we've got to prioritise the marginalised over the marginalisers (after all, they did post the link).

Do I feel links to all political parties should be banned? No. What about the extreme left or the somewhat right, where does it end? I don't know, but in this case it was easy to tell as this was a party with years of controversies that reasonably go against community spirits. Community members and managers should speak out if they can, remove problematic content actively and reinforce principles. Because not doing that is a message too, and it reinforces something too.

‘Cancel culture’ is the wrong word

I ended up calling for moderation and got into some conversations after that. One person called my request an opinion. Challenging my inner pedant: non discrimination is part of human rights declarations that almost all of the world's countries have signed. A request to reduce discrimination isn't an opinion, it's an attempt to claim basic human rights that whole societies agree on. Except, maybe, in communities of human rights scepticists, but this wasn't one of those.

Others said moderation would be like ‘cancel culture’ or ‘censorship’. The book We need snowflakes by Hannah Jewell, which I happen to be currently reading, does a great job dissecting these frames and the people who use them. Very often, she explains, those who claim to be cancelled ostensibly still have their platforms, be it their job or their status.

The word ‘cancel culture’ is a red flag. When you hear it used, it's worthwile considering how it's employed to shift who the victim is. In The Netherlands, we recently had football club director Marc Overmars ‘cancelled’ for sending female staff photos of his genitals. The word ‘cancel culture’ suggests calling out wrongs is an activity people do for little more than their own entertainment, and that Overmars is now some kind of victim, rather than the women he had literal power over. He was hired in the same position by a Belgian football club weeks later and his Wikipedia page hardly mentions the event (it does have a list of honours). A more apt response would be to ask: how are the women doing?

I am getting carried away a bit, but let's also consider ‘censorship’. Again, paraphrasing Hannah Jewell's book: is one truly censored if no government put rules in place to limit their free speech? If one can still say whatever they want in plenty of other places? If they aren't arrested for what they did? The ‘censorship!1!’ exclaimers should compare what they're exclaiming about to actual censorship that sadly happens in various states around the world.

In healthy communities, asking someone to remove content is simply a request to stop their harm in a specific community. Because it happens to be a community that has a principle on whose feelings to prioritise. Because that matters.

---

Originally posted as Action, inaction and ‘cancel culture’ on Hidde's blog.

Reply via email