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