How Not To Misuse ARIA States, Properties and Roles

Many content authors will put ARIA properties on content in an attempt to meet accessibility standards and make their content work with assistive technology (AT). Unfortunately, there is a lot of incorrect use of ARIA, with authors seemingly adding attributes until they get something that works with screen readers. One reason authors may continue to add incorrect ARIA properties is the lack of apparent issues when ARIA is misused – no harm is detected and thus people continue the practice. While some people may be less concerned with technically invalid code, it’s harder to debug and maintain and may cause unexpected issues. This post will expound on the different things that I have seen and provide best practices for how to use ARIA attributes properly.

Native and Implied Semantics

Generally ARIA should not be added to HTML content that already has the desired implied semantics. More importantly, ARIA markup should never be added that conflicts with the strong native semantics between HTML and ARIA. Refer to the default implied HTML semantics and strong native semantics found in the vocabulary and associated APIs for HTML and XHTML document for additional information. I am aware of bugs in screen readers such as VoiceOver that make adding ARIA to default implicit HTML5 semantics tempting in certain circumstances. For example, VoiceOver on the iPad will automatically append a percent to values of the input element type range. To get values spoken without percent you have to add an ARIA role and aria-value text. Similarly, aria-required seems to be more widely supported than the HTML5 required attribute.

Invalid Use of Roles, States, and Properties

Others add inappropriate attributes to elements that weren’t designed to work with controls of a particular role. The expected result is often inconsistent with assistive technology. ARIA has very specific designated attributes that can be assigned globally and others that can only be assigned to certain roles. Still other attributes can be assigned to different elements but are specified narrowly by the ARIA User Agent Implementation Guide to work in a particular way. Some of the inconsistencies in AT come from how AT accesses ARIA information. Screen readers such as NVDA tend to pull the information from the accessibility API rendered by the browser while other screen readers such as JAWS may pull from the accessibility API or directly from the document object model (DOM) of the page. JAWS reads from the DOM directly to make sure ARIA is supported in the IE browser, where the browser may not implement all of the information needed to rely on accessibility API methods alone.

aria-selected

You might be tempted to put aria-selected on links to simulate toggle buttons or to indicate that a checkbox is checked. These are incorrect uses of aria-selected –  a checked and selected state are not the same. Use aria-pressed for toggle buttons – that is the only place where aria-pressed can be used. Selection indication is most often used when a control can have multiple items selected such as options in a listbox or rows in a grid, or to indicate that something is active but not focused such as a page tab.

Only use aria-selected with these roles: option, tab, menuitemradio, treeitem, gridcell, row, rowheader and columnheader. Currently the ARIA spec indicates aria-selected can be used with radio buttons, but this is not a correct use of the property. When authors want to indicate that a radio button is checked they should use the aria-checked state –  in general, the aria-selected state should not be used with radio buttons.

aria-checked

aria-checked may be similarly confused with aria-selected with some authors using aria-checked to indicate selection of page tabs, links, or other controls. aria-checked should only be used with option, menuitemradio, radio, treeitem, checkbox, and menuitemcheckbox roles. option and treeitem roles may be selected and checked because it’s possible to have a list or tree of items that have checkboxes by them and that allow for multiple selection.

aria-haspopup

This attribute seems useful for indicating controls such as dialogs and rollover content, however, the ARIA specification indicates it is only to be used for indicating popup menus or sub-level menus even though it can be used with elements of any role. In fact some screen readers will announce “has menu” instead of “haspopup” enforcing the idea that this state should be used with menus. Broader use of this attribute is something that may be considered in the future.

aria-label and aria-labelledby

These properties are supposed to override the accessible name of the control per the accessible name calculation algorithm. However, many screen readers announce this accessible name in addition to the link text for links. When these are used on other content such as paragraphs and div, the support for screen readers varies widely and these accessible names may not be announced to the user at all. aria-label and aria-labelledby can safely be used on form fields with good assistive technology support. Remember that aria-label is not available to users with disabilities that do not use screen readers, so whenever aria-labelledby can be used it is preferred. For example, if aria-label is used to provide a name for a play button with visual arrow, users of speech recognition software won’t know what text to voice to activate the play button.

aria-activedescendant

This attribute is often misunderstood. It should be used in situations where the author doesn’t want to provide focus to individual elements and instead can indicate the focused descendant by specifying the id of the descendant or owned element in the aria-descendant attribute. This is most often used in controls such as toolbars, grids, page tabs, listboxes and trees. The attribute should be used on the ancestor element and the ancestor should have a tabindex=0. Some user agents may require that all descendants that may be indicated as focused may need a tabindex=-1. When aria-activedescendant is used, focus should not be set on the individual descendants – this is the purpose for the attribute and would negate it’s use.

Presentation role

Contrary to popular belief this role does not hide content from assistive technology. Instead it obscures the structure of the element and any required elements that the element owns. For example, it will hide the structure of a layout table from assistive technology and the accessibility applications programming interface (API) exposed in the browser, but not the content of the table. It would not obscure the structure of other non-table content contained within the layout table such as links, form fields, etc.

Required Owned Elements

Elements with certain roles require certain child/parent elements. For example a control with a role of tab must be contained within a tablist. Lists must contain listitem or group elements, grids must contain rows or rowgroup, listboxes must contain options, menus must contain menuitem or groups, trees must contain treeitem or groups, a combobox must contain a listbox and a textbox, etc. Make sure that you always implement composite controls with their required controls.

Conclusion

Authors must use appropriate ARIA roles, states, and properties or unpredictable issues may occur. It is not recommended to use incorrect properties to simply achieve support with a screen reader. Similarly, authors should not override strong native semantics for elements and should be very cautious about adding implied ARIA properties to semantically equivalent HTML elements. The ARIA specification will likely be updated and further implementation guidance provided in the future so please share your comments and recommendations to improve ARIA.