I asked my followers a question and you would not believe how undecided they were.

Transcript

Last week, I asked my Twitter followers about this code snippet:

<button aria-level="2">Action</button>

Does it fail the Web Content Accessibility Guidelines (WCAG) or doesn’t it?

49% said yes, clearly fails WCAG. 51% said no.

So only half of them were right. Let’s explore which half and why!

♩ Upbeat Jingle ♩

I’m Eric Eggert, a Web Accessibility Expert. You can follow me as @yatil — Y-A-T-I-L — on social media. If you have questions about this or other videos, or want to propose a topic, ask in the comments, or use the hashtag #askYatil on Twitter.

Now, I personally found this example, which is a real-life example from a real-life website, to be rather clear-cut, but the complexity of WCAG can be a challenge. Let’s see how to unravel it!

First, we have to identify what the issue is with the code as provided. Most frontend people probably see it at the first glance: The aria-levelproperty is set to the button. But buttons can’t have “levels”. So, it clearly is invalid ARIA right there.

In case you wondered how to know this, you can take a look at the HTML Accessibility API Mappings specification which says that HTML button elements use the ARIA button role.

In the ARIA specification, the button role has supported and inherited states and properties. As aria-level is not mentioned there, we can assume that it gets ignored by assistive technologies as it is not relevant to buttons.

You can also look at the definition for the aria-level property which only allows the use of aria-level with the grid, heading, listitem, row, and tablist roles.

Now, back to WCAG!

Some people argued that it would be a WCAG failure of success criterion “4.1.1 Parsing”. However, the SC does not say that all code has to be valid to be parsed. Instead, it specifies:

In content implemented using markup languages, elements have complete start and end tags, elements are nested according to their specifications, elements do not contain duplicate attributes, and any IDs are unique, except where the specifications allow these features.

The code snippet has complete start and end tags, there are no nested elements, attributes are not used twice or more times, and there’s no ID used.

So, we have to conclude that there’s no violation of that Success Criterion.

Some have cited SC 1.3.5 Identify Input Purpose and 1.3.6 Identify Purpose (a AAA criterion) as possible justifications to call it a WCAG violation.

SC 1.3.5 does not apply as it reads:

The purpose of each input field collecting information about the user can be programmatically determined (… and then there are some qualifications …)

But here, the button is not an input field and it does not collect information about the user, so this SC does not apply.

SC 1.3.6 says:

(…) the purpose of User Interface Components, icons, and regions can be programmatically determined.

In this case, this success criterion wants us to add metadata to the control that basically defines what the action is. That allows for greater personalization. It is a AAA success criterion and while it could apply here, this has nothing to do with the aria-level property.

The biggest contender for this type of issue, however, is probably success criterion 4.1.2 Name, Role, Value, which has also been cited multiple times. It reads as follows:

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies.

This is one of the more complicated success criteria as it has those lists in lists, with an extra dash of semicolons!

Let’s try to take it from the top:

For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined

All of that is true for our humble button: It is a user interface component, it has a name — here the generic “Action” — and a role — the implicit buttonrole from the native HTML element. The SC continues:

states, properties, and values that can be set by the user can be programmatically set;

In our case, because aria-level is unsupported on a button element, it cannot be set by the user. The SC continues:

and notification of changes to these items is available to user agents, including assistive technologies.

It is impossible to change values of unsupported properties in a way, so they get supported, so this part of the SC also does not apply.

Last, but not least, some people argued that this could be an issue with future support. Guideline 4.1 Compatible states:

Maximize compatibility with current and future user agents, including assistive technologies.

And yes, I agree that it might be a problem if ARIA would be adding levels to buttons in the future. But, I don’t think it is likely.

On top of it, it is a Guideline in WCAG. When talking about failing WCAG, we usually talk about a specific success criterion, we don’t usually use guidelines as markers for failure.

They can be great to promote best practices, and valid code is certainly one we would promote.

In the end, none of the cited success criteria are failed, so the code snippet, despite being technically wrong, does not fail WCAG.

This comes back to the gist of my first video: You want to adhere to the guidelines and best practices as much as you can and exceed the limited baseline that success criteria provide for accessibility.

However, when looking at a finished product and vetting it for accessibility, doing it through the lens of the requirements as formulated by the success criteria is the most straightforward approach. It becomes about ensuring basic accessibility instead of exceeding them.

The divided opinion in the initial tweet shows two things: Many overstep the boundaries when reporting WCAG fails, which is not necessarily a bad thing. No product will be less accessible because you exceeded the requirements. An in this case, the change that would be required to address the issue is simple and would not take a lot of time.

On the other hand, I regularly see clients and developers confused because different web accessibility professionals give different advice.

Stay tuned to learn more about how to apply WCAG Success Criteria on my channel. Make sure to click subscribe and hit the notification bell icon to not miss anything. And of course you can support me on Patreon at patreon.com/yatil or follow me at twitter.com/yatil — that's Y-A-T-I-L — where you can send me questions using the #askYatil hashtag.

Thanks for watching and see you in the next video.

♩ Upbeat Jingle ♩