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

ARIA and HTML5Native 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:

See the Pen headings with and without aria-level by steve faulkner (@stevef) on CodePen.

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.

Further reading

 

Categories: Technical

About Steve Faulkner

Steve was the Chief Accessibility Officer at TPGi before he left in October 2023. He joined TPGi in 2006 and was previously a Senior Web Accessibility Consultant at vision australia. Steve is a member of several groups, including the W3C Web Platforms Working Group and the W3C ARIA Working Group. He is an editor of several specifications at the W3C including ARIA in HTML and HTML Accessibility API Mappings 1.0. He also develops and maintains HTML5accessibility and the JAWS bug tracker/standards support.

Comments

It seems it’s been fixed in JAWS 18. I’ve tested using beta version 18.0.1811 and JAWS (Windows 10 / Firefox 46.0.1) is reading headings correctly.

Steve Faulkner says:

Hi, as detailed in the article it only occurs in Chrome, so suggest you try it using chrome/JAWS combo

Right. However, seems in Chrome (54.0.2840.59 m / Windows 10) it works correctly as well which is a good news, I think.

Steve Faulkner says:

That is good news, it indicates JAWS has fixed the bug o/ and it is why I wrote:

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.

Unfortunately for the use case I described the bug is still there as the client has frozen the JAWS version at 17.