HTML5 Accessibility Chops: When to use an ARIA role

Custom ARIA - HTMl5 logo There has been discussion of late on whether authors should be allowed to include an ARIA role value on an HTML element that matches the default implicit ARIA role as defined in HTML5. The divergent opinions are mirrored in the differing author conformance requirements between the W3C HTML5 specification and the WHATWG living standard.

Note: this information is now being actively maintained as part of Using ARIA in HTML.

The W3C HTML5 specification

Does not prohibit authors from applying the default implicit role as defined in the WAI-ARIA section of the specification.

The WHATWG living standard

Does prohibit authors/developers from adding default implicit ARIA semantics to HTML elements:

Authors must not set the ARIA role and aria-* attributes to values that match the default implicit ARIA semantics

Addition of default implicit roles – what does it do?

For example, the default implied ARIA role for an a element that creates a hyperlink is the ARIA link role. So in the W3C HTML5 specification it is not forbidden to do this:

<a href="http://www.html5accessibility.com" role="link">HTML5 Accessibility</a>

The addition of the role does nothing as the a element has been around for yonks and the role value mapped in accessibility APIs, in browsers that support accessibility, is already implemented by the browser. So in effect it is the same as this:

<a href="http://www.html5accessibility.com">HTML5 Accessibility</a>

When the information being exposed by Accessibility APIs is viewed using an inspect tool, it can be seen that there is no difference between the 2 examples, both expose (in the case of FireFox on Windows via MSAA and IAcessible2) the following:

MSAA

Name: HTML5 Accessibility
Value: http://www.html5accessibility.com/
Role: link
State: focusable , focused , linked , traversed
Description: (none)

IAccessible2

Name: HTML5 Accessibility
Value: http://www.html5accessibility.com/
Role: link
State: Horizontal, Opaque, Selectable text
Description: (none)

Redundant roles

The ARIA role in this case is redundant as the browser has already done the job of conveying the semantics. The addition of the role has no effect, it is not necessary but does no harm. Authors do not need to and should be made aware that they do not need to add roles for the default semantics of accessibility supported elements, but if they do its not the end of the world.

Accessibility Supported elements

Authors/developers can safely assume that any element that has been around since HTML 4.0 is already accessibility supported in browsers that support accessibility. So they do not need a default implicit role added. The situation for new HTML5 elements is different and likely to remain so for some time. It will be years before New HTML5 elements get robust accessibility support implemented across browsers and platforms. This is particularly so for non interactive elements such as the new HTML5 structural elements because accessibility APIs in general do not have defined roles for many non interactive elements. In this case it is recommended to add the appropriate ARIA roles to elements that are meant to convey meaning but are effectively meaningless due to lack of implemented accessibility support.

For example, adding role=navigation to a nav element fills the gaps in support for HTML5 semantics as ARIA is more robustly supported by most modern browsers and assistive technology:

Unlike the WHATWG living standard, the W3C HTML5 specification has a more realistic stance towards the use of default implicit roles, as it allows authors to use ARIA to fill the gaps in browser implementation support.

What do Validation tools do?

Currently, the 2 main HTML5 conformance checkers (validator.nu and W3C Nu markup Validation Service) do not flag the presence of a default implicit role as an error, so in this respect they follow the HTML5 specification author conformance requirements for use of the ARIA role attribute.

What should Validation tools do?

HTML documents should not be considered invalid due to the addition of implicit roles.

Given that it has not been shown that the addition of implicit roles does any harm, is unnecessary in some cases, but useful in other cases, it is suggested a nuanced warning message, not an error would be appropriate.