A (not so) short note on ARIA to the rescue

ARIA and HTML5 Native HTML elements don’t require the addition of ARIA attributes to expose the semantics they have, as, for the most part, browsers expose this information: YAY.

This is expressed in the ARIA specification:

…there are many situations in which WAI-ARIA semantics are redundant with host language semantics.

It is also expressed in HTML as a set of rules to dissuade developers from unecessarily adding ARIA attributes, acting under the falsehood that it is somehow beneficial.

Setting an ARIArole and/or aria-* attribute that matches the default implicit ARIA semantics is unnecessary and is not recommended as these properties are already set by the browser.

Default Implicit ARIA semantics – should not be used

This why developers who do so and check their HTML conformance with the HTML standard will get warnings like this:

Warning! The heading role is unnecessary for element h1.

And this is a good thing. Although in most circumstances the presence of ARIA semantics that duplicates default implicit semantics will not have a detrimental effect, addition of unecessary attributes leads to extra work, code bloat, and can lead to errors.

SHOULD NOT, because sometimes…

We have a client, who has set on an environment for particular reasons, that uses a locked down version of Chrome and allows only JAWS as a screen reader.

JAWS does not officially support Chrome and while Chrome does a good job at exposing the correct information for Assistive Technology (AT), sometimes the AT falls short in making use of the information or does not interpret the information correctly.

Sometimes the issue may be a regression in a new version of the software and will hopefully be fixed in the next version. Other times it’s a long standing bug in the browser or AT. As accessibility practioners/engineers/developers (call yourself what you will), we have to take a view on whether to advise the client to implement a work around or code the workaround ourselves, or whether users can take a hit, as it’s a temporary problem and not a show stopper for users.

In the case above the issue was that JAWS in combination with Chrome (as of version <=51) does not correctly identify heading (H1-h6) levels, so content structure/hierarchy is not conveyed. The problem here is with JAWS, Chrome exposes headings correctly in the accessibility tree. i.e. a <h1> has a role=heading and a level=1, a <h3> has a role=heading and a level=3, but JAWS reports all headings (h1-h6) as “heading level 2” doh!

As mentioned earlier, the environement is a set version of chrome (51) and a set version of JAWS (17) so me thinks this is not an issue that will go away soon, and users of this system will be at a disadvantage because of this. The initial advice was to at least provide some information up front to JAWS users, so they were aware of the issue. Then I thought I would try adding the aria-level attribute to the headings with a value that matches the default level of the heading:

<h1 aria-level="1">...
<h2>...
<h3 aria-level="3">...

I wasn’t super optimistic about this having an effect, as I know that the attributes through which ARIA can be used to manipulate the browser accessibility tree properties are exposed via the platform accessibility API properties/values (where they exist) rather than any ARIA magic, and both level and role=heading are standard across accessibility APIs. To my surprise use of aria-level worked, you can try it yourself in chrome/JAWS:

That it worked told me that JAWS is likely doing some DOM hacking and picking up the aria-level attribute rather than reading the correct value already conveyed by chrome through the Accessibility Tree. Point is it worked and the client can be advised on a simple workaround to support the correct semantics for users.

NOTE

This is a tale of a particular circumstance where going against the general rule of ARIA not being required to expose native HTML semantics, was of benefit. It is in no way meant to suggest that adding aria-level to h1-h6 is required or recommended in general. It is a bug in JAWS that needs to be fixed.

A (not so) short note on ARIA to the rescue

SHOULD NOT, because sometimes…

NOTE

Further reading