Welcome to the third 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: Additions to “role” – we explored the additions to “role”.  Today, we review the changes that were made to various attributes.

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.

Changes

aria-owns

The aria-owns attribute can be used to change the order of the accessibility tree, which is important when the DOM element structure of a widget does not match the correct parent-child relationship necessary to make such a structure work correctly. In such cases, the aria-owns attribute can be used to reference the IDs of the elements that are meant to be children of that container element.

The aria-owns attribute will cause the accessibility tree to be reordered, which will be recognized by assistive technologies that support the use of ARIA. In contrast, the use of the aria-owns attribute will not in any way reorder the element structure within the DOM, it only affects the order of the accessibility tree that is perceivable by assistive technologies.

The aria-owns attribute is a global attribute and may be added to any element. However, it is important to note that aria-owns must not be used on elements or roles that do not support children, such as HTML input elements or img elements. The same is true for combobox widgets that use role=”combobox” on an HTML input element, or any use of an HTML input+type=”text” or HTML textarea element, none of which should include the use of aria-owns. This is equally true for active elements such as links or buttons which should never include aria-owns to reference other active elements or container elements that include active elements.

The aria-owns attribute is often confused with the aria-controls attribute, though both are very different. The aria-controls attribute simply conveys an association between one or more elements that are controlled by the first, however, there is no parent-child relationship between these elements. Also, the use of aria-controls does not ever reorder the accessibility tree, only aria-owns can be used to reorder the accessibility tree.

aria-activedescendant

In ARIA 1.0, the use of aria-activedescendant was defined as referencing the ID of a descendant child element to convey the child element as having focus in the accessibility tree, which required a parent child relationship in the accessibility tree according to spec.

In ARIA 1.1 however, the use of aria-activedescendant has been widened in scope to also allow for the referencing of any other element that is not a direct descendant of the focused element, meaning that aria-activedescendant can be used to convey that focus has moved to any other widget type regardless where that element actually is located in the DOM. The caveat being, that aria-activedescendant must point to an element that has an implicit or explicit widget role.

This change is especially important for interactive widgets such as autosuggest comboboxes, where the use of aria-activedescendant on the input control can allow the perceived focus in the accessibility tree to move into an associated Listbox control so that the up and down arrow keys can then change the highlighted option by dynamically updating the aria-activedescendant attribute on the HTML input field. This technique can also be used to traverse associated controls such as date pickers by referencing the date links using aria-activedescendant, which then controls the movement of the date picker using various keys all of which simply update the aria-activedescendant attribute on the focused input element. The same is true when using aria-activedescendant on an input to reference the various role=”treeitem” nodes within an ARIA Tree, so that the arrow keys when pressed will dynamically update the aria-activedescendantattribute on the input in order to convey that accessibility tree focus has moved into the tree even though literal DOM focus remains on the input element.

It’s important to note the difference between accessibility tree focus and literal DOM focus, which are not the same thing.

Literal DOM focus occurs when focus is set to a focusable element in the DOM, such as an active element like a link or form field. The accessibility tree focus however, is what is reported in the accessibility tree as currently having focus. To put this another way, the literal DOM focus reflects the currently focused element in the DOM, whereas the accessibility tree focus reflects only the accessibility tree object that is reported as presently having focus. In the DOM, only one element is allowed to have focus, which is also true in the accessibility tree, where only one accessibility tree object is allowed to be set as focused.

Assistive technologies like screen readers announce the accessibility tree object that has focus, not the DOM element that literally has focus. In practice, both the literal DOM focus and the accessibility tree focus always match, so that the element that has literal focus in the DOM is the same as the accessibility tree object that is announced to screen reader users as having focus.

The aria-activedescendant attribute however, can be used to override this automatic behavior in the browser and instead point to a different accessibility tree object to report as being focused, even though literal focus in the DOM has not moved.

aria-haspopup

In ARIA 1.0, the use of aria-haspopup could be either set to “true” or ““false”, and its only purpose was to convey the presence of an attached menu when set to “true”. The use of aria-haspopup was only valid when used for this purpose.

In ARIA 1.1 however, the use of aria-haspopup was extended to support a list of token values that can be used to fit a number of different circumstances. These include all of the following:

• false (default) = Indicates the element does not have a popup
• true = Indicates the popup is a menu
• menu = Indicates the popup is a menu
• listbox = Indicates the popup is a listbox
• tree = Indicates the popup is a tree
• grid = Indicates the popup is a grid
• dialog = Indicates the popup is a dialog

Also, in ARIA 1.0, the aria-haspopup attribute was not specifically called out as needing to be placed on a focusable keyboard accessible element, however this has been tightened up in 1.1 where it now specifies that the use of aria-haspopup should be placed on a keyboard accessible element where it can be triggered properly.

It’s important to note that none of the token values are supported within browsers or assistive technologies as yet, and likely won’t until the end of 2017 at the earliest.

role=”form”

In both ARIA 1.0 and 1.1, role=”form” is declared as a landmark. However, the assistive technology mappings were changed in 1.1 to cause role=”form” to behave as a landmark, whereas before they did not. This also impacts the implicit role mappings for the HTML form element, which historically do not map to the ARIA form role as expected.

This lack of implicit role mapping for the HTML form element is intended, however, because if it were otherwise, all form elements would be declared as landmarks on all web pages, which would be extremely confusing and non-intuitive. So a compromise was reached, where an HTML form element will only be mapped to the ARIA form landmark role if it includes an explicit name using either aria-labelledby or aria-label. Otherwise, the HTML form element will not be mapped to the ARIA form role as a landmark.

One more to go!

This is the third of a four-part series on the Differences between ARIA 1.0 and 1.1. Please click here for part one and part two. In the next installment, I’ll delve into role=”combobox”. It’s a bit complicated, so it deserves its own post.