Welcome to the second installment of SSB’s four-part review of the differences between ARIA 1.0 and 1.1. In the last post – Differences between ARIA 1.0 and 1.1: Deprecations & Additions – we reviewed deprecations and additions like aria-keyshortcuts, aria-roledescription, and aria-current. Today, we explore the additions to “role”.
The most recent Candidate Recommendation of the Accessible Rich Internet Applications (WAI-ARIA) specification was published on October 27, 2016. You can view the full document on the W3 website.
It’s important to note that this document is still subject to change with future publications, and that these observations are meant to provide a high-level overview of broad level changes that will be important to be aware of going forward. As such, these details are likely to remain valid regardless. Also, many of these additions are minimally supported or not supported at all by browsers and assistive technologies as yet.
role=”table” and role=”cell”
The table roles are meant to handle constructs where a non-interactive data table is needed when the underlying markup does not use a standard HTML table element. This construct is static and is not meant to be interactive in the same way that role=”grid” is used.
The “cell” role is only valid within a role=”table” construct, and is not valid within any other construct such as role=”grid”. The use of the roles “table” and “cell” are only valid within a construct that simulates a standard data table.
The role “term” is meant to accompany and explicitly associate role=”definition”, which was missing in ARIA 1.0.
The attribute role=”term” must never be used on an interactive element, but instead must be used on container elements that include textual content or container elements that surround an interactive element (e.g., a link or button).
When role=”definition” is used, it must include aria-labelledby to point to the ID of the role=”term” element to explicitly associate the term to which the definition refers.
The role “figure” is meant to surround user-navigable information, which may contain content ranging from graphical images to textual code fragments to mathematical equations. As such, the content of a figure is navigable in the same manner as a named region or landmark.
A figure may be explicitly named using either aria-labelledby or aria-label, or even reference an external caption using aria-describedby.
The role “feed” was added in ARIA 1.1 to provide a mechanism for handling infinite scrolling regions within dynamic feed environments.
The role=”feed” container acts much like a named region or landmark, though it must only include first-level child roles with role=”article”. The Article role may of course include any number of other roles and active elements.
Programmatic focus handling must be used to move focus between each role=”article” element within the role=”feed” container, and new role=”article” containers must be dynamically added to the beginning or end of the role=”feed” container when rendered.
The use of aria-describedby may be added on each focusable role=”article” container to automatically announce the desired content within that article when it receives focus.
A focusable button should also be available at the end of the role=”feed” container that will dynamically load additional role=”article” elements when activated. This is needed for touchscreen devices and screen readers that use off-screen browse modes.
The role “searchbox” was added to represent the same element type as an HTML input element that includes type=”search”.
The use of role=”searchbox” must be the only focusable element. This differs from role=”search”, which is meant to be a landmark that includes focusable active elements.
When role=”searchbox” is used, focus must be set to the role=”searchbox” element and the content of that element must then be directly editable. Since role=”searchbox” is a form field in the same manner as role=”textbox”, it must include an explicit label using either aria-labelledby or aria-label.
The role “switch” was added as a type of simplified checkbox that can only handle two values, “false” or “true” (On or Off). The “switch” role does not support aria-checked=”mixed”, which will default to “false” if detected.
The use of role=”switch” must never include focusable active elements, but must instead be the only focusable element.
When role=”switch” is used, focus must be set to the role=”switch” element, and the spacebar (in addition to onClick) must be available to toggle aria-checked between “false” or “true”.
Since role=”switch” is a form field in the same manner as role=”checkbox”, it must include an explicit label using either aria-labelledby or aria-label.
The role “none” was added to act as an alias for role=”presentation”, and both are the same and perform the same action. This was meant to provide clarity for those who were confused by the word “presentation.”
It was also proposed that role=”” also be available to perform the same behavior as role=”none” and role=”presentation”. However, this presented too many implicit role conflicts within browsers, assistive technologies, and framework development, so role=”” should never be used in place of role=”none” or role=”presentation”.
This is the second of a four-part series on the Differences between ARIA 1.0 and 1.1. Please click here for parts one, three and four. In the next installment, we’ll explore the changes that were made to various state and property attributes.
As a quick update, all of these ARIA 1.1 role additions and support criteria have already been added to Visual ARIA for quick visual identification on any live website.