WCAG
Initially I was confused by WCAG, WAI-ARIA and other standards. I took time to figure out things.
WAI (Web accessibility initiative) produces several standards (recommendations, guides). WCAG (Web Content Accessibility Guidelines) is the “main” one.
WCAG 2.0 is also an ISO standard. WCAG 2.x serves as the basis for a lot of laws, regulations, etc. - requiring AA compliance.
WCAG has several versions. 2.1 is most recent one. 2.2 is working draft.
WCAG 2
WCAG 2.x consists of the main document (standard) and 3 supplemental documents:
- How to Meet WCAG 2 (Quick Reference)
- Understanding WCAG 2
- Techniques for WCAG 2
Standard intentionally written without technical details, so it can be applied to different technologies (HTML, JS, CSS, Flash, Silverlight, PDF, etc.). Technical details are listed in “Techniques for WCAG 2”.
Be aware that some of those techniques can be outdated, for example:
- it recommends to use
padding,marginover image spacers and avoid tables for layouts - I thought people stopped doing that in 2010. I also would recommend to usegapinstead ofmargin - it recommends to provide title for each page with the help of HTML
titletag, which obviously would not help screen reader users in context SPA. There is no page reload, so screen reader would not read out new title. Modern solution for this recommendation would be this.
Standard doesn’t specify which kind of disabilities are covered by which recommendation, so it is not always obvious how to test and what to take into account. Some of explanations are given in “Understanding WCAG 2”. But not all of them list disabilities.
To be fair some of recommendations are not targeted for people with special needs, but rather general UX advice, for example:
- provide clear description of buttons and links
- same looking elements should not have different actions
Which doesn’t make them worse - just an interesting observation.
“How to Meet WCAG 2 (Quick Reference)" is a checklist for WCAG 2, it essentially the same contet, but suppose to be mroe compact. It suppose to be, but I find it hard to work with (maybe because of strange website structure).
There are other checklists, for example:
- https://www.a11yproject.com/checklist/
- https://webaim.org/standards/wcag/checklist
- https://www.wuhcag.com/wcag-checklist/
- https://www.w3.org/TR/2006/WD-WCAG20-20060427/appendixB.html
Following WCAG will make content more accessible to a wider range of people with disabilities, including accommodations for blindness and low vision, deafness and hearing loss, limited movement, speech disabilities, photosensitivity, and combinations of these, and some accommodation for learning disabilities and cognitive limitations.
But WCAG addresses learning and cognitive disabilities to lesser extent
Significant challenges were encountered in defining additional criteria to address cognitive, language, and learning disabilities, including a short timeline for development as well as challenges in reaching consensus on testability, implementability, and international considerations of proposals.
For those disabilities they made a separate document “Making Content Usable for People with Cognitive and Learning Disabilities”.
WAI-ARIA
Accessible Rich Internet Application (WAI-ARIA 1.1) is additional standard. It meant to specify how interactive component would work in the context of assistive technologies.
It is relatively new compared to WCAG (it was released in 2014). Not all features supported by all assistive technologies.
HTML5 elements come with predefined assistive roles, so if you can use HTML5 tags use them instead of ARIA attributes.
ARIA components built with keyboard accessibility in mind, but not necessarily it will accommodate all assistive technologies, for example applying gridcell role to td, will break standard navigation for tables in VoiceOver. So blindly following standard doesn’t guarantee best experience - testing with real device required.
WAI-ARIA mentioned as one of techniques in “Techniques for WCAG 2” - so to some extent it is supplemental document for WCAG 2.
There is main document (standard) and supplemental one: WAI-ARIA Authoring Practices 1.1
There is a working draft of WAI-ARIA v1.2.
WCAG 3
WCAG 3.0 is the next major release planed for 2022.
WCAG 3 will addresses some issues of WCAG 2. It will focus more on user testing and will change scoring system.
Conclusions
Use WCAG 2.1 (also using 2.2 is pretty safe, because it will be approved in June this year). Strive for AA. WCAG is more focused on over all experience, not all criteria applicable in context of separate components, for example rule about page title.
WAI-ARIA 1.1 can serve as supplemental material, but prefer HTML5 whenever possible and don’t forget to test with real devices. WAI-ARIA focused on separate components, which seems to be more relevant for design system.
Top comments (7)
There's a few odd things here.
Firstly, there's nothing wrong or outdated with their recommendation of using
paddingandmargininstead of spacer images and table layouts. You recommend usinggapinstead, but that's only an option if you're using CSS grid layout which you've not mentioned. CSS grid has many quirks which make it all too easy to create less accessible content, such as breaking the natural document order and tabbing order by re-arranging content visually in a way that doesn't match the DOM.Using a title for each page is absolutely still recommended. If you're creating an SPA, you can still alter the title of the document to reflect the new view. The title isn't just something that's seen once and never again. Dynamic titles can benefit everyone. Just look at any popular messaging app or social network when in a tab not in the current foreground. They make use of dynamic titles (along with other methods) to alert the user that they have a message or notification to read.
Their choice of not listing disabilities is correct. Developers (and content creators) get far too attached to the idea of fixing things for a specific disability, that they don't see the bigger picture. Often, changes made to address a disability actually benefit everyone. For example, video captions were originally aimed to address the problems that the Deaf community faces, but captions are useful for a lot more people than that . Most of the guidelines are beneficial for more than a single disability, which is why they're not targetting any group of people at all.
You mention that ARIA is meant to address keyboard accessibility, but that's not entirely true. The most popular ARIA attributes are things like
aria-labelandaria-describedbywhich are used heavily by speech readers and Braille displays. ARIA is intended to fill the gaps that exist with our current ecosystem. HTML tags and their implied roles is only a small part of it, there are interactive associations (e.g. toggle buttons, revealed content, etc) and dynamic content (live areas, insertions, deletions, etc).caniuse.com/flexbox-gap
I'm didn't say you shouldn't use it. I said it will work only on the initial load, but not on consequent navigations
As far as I understood, they will list more disabilities, to give more context in WCAG3
That is true. What I meant that if you take a look at code examples, most of them are about how to add keyboard navigation (JS code). But markup and other attributes are indeed would be useful for other assistive technologies
You said
gap, notflexbox-gap, two very different properties. Also, there are still times where neither of these is being used.marginandpaddingare still very much in use today, and not out-of-date at all.But it will, and I even mentioned examples.
With which assistive technology did you test it ( e.g. VoiceOver, NVDA, JAWS)?
Sorry, you're right about the
gapbeing now also used for Flexbox, it's just badly documented.As for the dynamic title thing, just tested it in NVDA and it works fine. I think the problem you're running into is that you're just expecting the screen reader to read out anything on the page that has changed. That won't happen, you have to make the browser aware that it needs to watch regions for changes. But NVDA has absolutely no problem reading out the new title.
If you have a valid reason to change the title for someone not using a screen reader, then it also applies for someone who is using one.
I need to get my hands on NVDA - I need virtual machine for that
I'm assuming you're using a Mac then? VoiceOver should behave just the same. Or there's Orca and equivalents on Linux.