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.

role=term

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.

role=figure

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.

role=feed

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 onto 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.

role=searchbox

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.

role=switch

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.

role=none

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”.

Reposted from SSBBart Group

The most recent version of the Accessible Rich Internet Applications (WAI-ARIA) guidelines 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.

I’ll be posting a quick summary, and my thoughts here that will be divided between four blog posts. Today’s post will include the deprecations and some additions in ARIA 1.1.

Deprecations

In ARIA 1.1 the drag and drop attributes aria-grabbed and aria-dropeffect were slated to be deprecated.

The idea was to use native accessibility API features for drag and drop instead. However, in practice, since the accessibility API features for accessible drag and drop still don’t exist and likely won’t for several years, these attributes will continue to be supported on the Windows OS and reflected in the accessibility tree for some years to come until these APIs become available for use in development.

As such, the prior ARIA 1.0 guidance for making drag and drop accessible still remains valid at this time.

Additions

aria-keyshortcuts

The aria-keyshortcuts attribute was added to convey which hotkey combinations are available to activate or focus on a particular element.

This is not like the accesskey attribute, where the modifier is handled by the browser and may differ between browsers, but instead represents the static shortcut combination that is programmed across all browsers.

In all cases where aria-keyshortcuts is used, these key commands need to be added by the developer using JavaScript, because there is no way for the browser or AT to know the expected functionality of all custom hotkey combinations. This attribute simply conveys the availability of these shortcuts and identifies what they are.

In short, adding the aria-keyshortcuts attribute without including the relevant scripting to make it work will result in shortcuts being conveyed to the user that do nothing when pressed.

At present, the aria-keyshortcuts attribute should only be used on focusable active elements.

aria-roledescription

The aria-roledescription attribute is meant to suppress the native role of an element and replace it with whatever the attribute string value states.

It’s important to note that the underlying role mapping remains the same in the browser and accessibility API, however assistive technologies like screen readers will announce only the value of aria-roledescription as the role of the element instead of the actual role that is mapped. At least, this is what the specification states.

However, some screen reader venders have already stated that they will not prevent the role from being conveyed to their users because this would cause too much confusion, but will instead announce both, thus forecasting that they have no intention to follow the spec in this matter. This will result in some screen reader vendors suppressing the role and others not, making this an unreliable attribute at best, and potentially an extremely dangerous feature if misused by conveying the wrong role or an incomprehensible role on critical interactive controls.

aria-modal

The aria-modal attribute was added to accompany the roles ‘dialog’ and ‘alertdialog’, to indicate to browsers and assistive technologies that the dialog is meant to be modal or non-modal.

If set to ‘true’, the background content in the accessibility tree should be hidden by browsers and assistive technologies so that only the modal content is perceived by the user.

If set to ‘false’ or left undefined, then the background content should not be hidden from the perception of AT users.

Currently this is only supported on iOS using VoiceOver iOS 9.X, so additional testing is needed to verify future levels of support.

To ensure forward compatibility for ARIA dialogs, all modal dialogs that use either role=”dialog”or role=”alertdialog” should include aria-modal=”true” to enable this support in the future. This should only be true for modal dialogs where the background content is not meant to be interacted with while the modal is open.

aria-errormessage

The aria-errormessage attribute takes an ID reference in the same manner as aria-describedby, and is only exposed when aria-invalid is set to ‘true’ on the same element. The use of a live region attribute such as aria-live=”polite” on the error message container element is optional.

aria-placeholder

The aria-placeholder attribute is meant to simulate the HTML5 behavior of the placeholder attribute and make it valid within other simulated control types and roles where the HTML5 placeholder attribute is not valid.

All scripting, styling, and functionality of the use of this attribute must be implemented manually by the developer since the attribute itself is not meant to have any effect on browser functionality.

The aria-placeholder attribute and the HTML5 placeholder attribute should not be used together on the same element, nor should aria-placeholder be used on native form controls where the HTML5 placeholder attribute is appropriate.

aria-current

The aria-current attribute is meant to convey to an assistive technology that this is the current item within an associated collection of elements.

When set to “false”, “”, or the attribute is undefined, nothing is exposed to assistive technologies. Otherwise, aria-current accepts a list of token values that convey the type of item being represented in the set. These are listed below:

• page = Represents the current page within a set of pages
• step = Represents the current step within a process
• location = Represents the current location within an environment or context
• date = Represents the current date within a collection of dates
• time = Represents the current time within a set of times
• true = Represents the current item within a set

aria-current must never be used as a substitute for aria-selected where aria-selectedis a required attribute for specific roles.

You can use aria-current in addition to aria-selected when aria-current conveys that one node is currently active, regardless of which element is selected. For example: when a language selector where aria-current conveys the currently chosen language, and arrowing through the listbox conveys which language option is currently selected.

aria-details

The aria-details attribute takes an ID reference in the same manner as aria-describedby, and is meant to provide access to a more comprehensive description (when available) that may include additional active elements.

As such, aria-details takes precedence over aria-describedby if both are present on the same element. However, it is necessary for the user to navigate to the container referenced by aria-details to view and interact with the content of that description. This differs from aria-describedby, which is part of the naming calculation for the element that has focus, and where it is not necessary to move focus away from that element to hear the description. In contrast, aria-details is not included in the naming calculation for setting the Description property, and the user must instead navigate away from the focused element to view the detailed description.

Reposted from SSBBart Group