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 ARIA
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:
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
<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
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.
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
h1-h6 is required or recommended in general. It is a bug in JAWS that needs to be fixed.
- Short Note on HTML conformance checking
- On HTML belts and ARIA braces (The Default Implicit ARIA semantics they didn’t want you to know about)
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.
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.
That is good news, it indicates JAWS has fixed the bug o/ and it is why I wrote:
Unfortunately for the use case I described the bug is still there as the client has frozen the JAWS version at 17.