DEV Community

stereobooster
stereobooster

Posted on • Originally published at stereobooster.com on

What are WCAG and WAI-ARIA?

#a11y #todayilearned #webdev

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, margin over image spacers and avoid tables for layouts - I thought people stopped doing that in 2010. I also would recommend to use gap instead of margin
  • it recommends to provide title for each page with the help of HTML title tag, 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:

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.

Learning resources

Top comments (7)

Collapse
 
ashleyjsheridan profile image
Ashley Sheridan •

There's a few odd things here.

Firstly, there's nothing wrong or outdated with their recommendation of using padding and margin instead of spacer images and table layouts. You recommend using gap instead, 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-label and aria-describedby which 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).

Collapse
 
stereobooster profile image
stereobooster •

but that's only an option if you're using CSS grid layout which you've not mentioned

caniuse.com/flexbox-gap

Using a title for each page is absolutely still recommended.

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

Their choice of not listing disabilities is correct.

As far as I understood, they will list more disabilities, to give more context in WCAG3

The most popular ARIA attributes are things like aria-label and aria-describedby which are used heavily by speech readers and Braille displays.

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

Collapse
 
ashleyjsheridan profile image
Ashley Sheridan •

caniuse.com/flexbox-gap

You said gap, not flexbox-gap, two very different properties. Also, there are still times where neither of these is being used. margin and padding are still very much in use today, and not out-of-date at all.

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

But it will, and I even mentioned examples.

Thread Thread
 
stereobooster profile image
stereobooster •

You said gap, not flexbox-gap, two very different properties.

.flex-parent {
  display: flex;
  gap: 1rem; // 👈 "gap"
}
Enter fullscreen mode Exit fullscreen mode

But it will, and I even mentioned examples.

With which assistive technology did you test it ( e.g. VoiceOver, NVDA, JAWS)?

Thread Thread
 
ashleyjsheridan profile image
Ashley Sheridan •

Sorry, you're right about the gap being 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.

Thread Thread
 
stereobooster profile image
stereobooster •

I need to get my hands on NVDA - I need virtual machine for that

Thread Thread
 
ashleyjsheridan profile image
Ashley Sheridan •

I'm assuming you're using a Mac then? VoiceOver should behave just the same. Or there's Orca and equivalents on Linux.

Read next

fourhtyoz profile image

Five cool JavaScript tricks

Fourhtyoz -

trevoirwilliams profile image

Getting Started with ASP.NET Core API, EF Core, and PostgreSQL on Neon

Trevoir Williams -

charlottetowell profile image

Creating a NextJS Web App With 0 Web Dev Experience

Charlotte Towell -

deniel_davenatividad_f4f profile image

Unlock the Power of the Cloud: Deploy Your Django App on AWS EC2

Deniel Dave Natividad -