ARIA Combobox Update, Differences between ARIA 1.1 and 1.2 and Responsive Design Considerations

ARIA Combobox Update, Differences between ARIA 1.1 and 1.2 and Responsive Design Considerations

Some of you may be familiar with my prior article about the ARIA 1.1 role=combobox update from years ago.

In practice, however, full support was never fully implemented within assistive technologies and browsers, which led to many broken and only partially accessible comboboxes across the web when these were added according to the ARIA 1.1 Combobox design pattern.

It was later agreed within the ARIA Working Group that full support for the 1.1 design pattern was never going to be reliably implemented, and to prevent further confusion and accessibility issues going forward, the 1.1 pattern was going to be deprecated and instead the ARIA 1.2 Combobox design pattern was going to be the better solution going forward.

Ironically this was the same design pattern I proposed in 2016 to solve the same problem before the 1.1 design pattern rewrite was added.

The important thing to keep in mind is that the ARIA 1.1 Combobox design pattern should never be used going forward, and instead the 1.2 Combobox design pattern should always be used instead. This will ensure the greatest level of accessibility possible for the widest range of assistive technology and browser combinations.

The good news is that the 1.2 Combobox has been widely supported for many years already, so we don’t have to wait for browsers to catch up to anything within the spec to make this work accessibly.

Combobox Test Pages

·???????Editable State and readonly Country combobox selectors.

·???????Editable search field combobox selector.

·???????Readonly simulated combobox button selector.

Additionally, this latter design pattern supplies some useful advantages for screen reader support, such as conveying the select state of listbox options within multiselect comboboxes.

Multiselect Combobox Test Pages

·???????Editable multiselect combobox selector.

·???????Readonly simulated multiselect combobox button selector.

Responsive Design and Scalability

There are some important considerations to be aware of about responsive design implementations, however, which the ARIA spec does not go into detail about. For this to work equally and scale across both desktop and mobile touch devices, for example, the following needs to be observed.

The use of aria-activedescendant plus aria-expanded to convey the expanded state and selection of a listbox option will not work to ensure equal accessibility across both desktop keyboard and mobile touch devices.

On desktops using JAWS and NVDA with Chrome, Firefox, and Edge, this technique will cause the referenced listbox option to be announced as though it received focus, even though the actual focus never leaves the combobox. This works because the screen reader never stops interacting with the combobox, and when aria-activedescendant is used to reference the id of an option within the listbox, the focus within the accessibility tree is then reported to the screen reader to have virtually moved into the listbox, even though no actual focus movement within the browser has really occurred. This feedback by the screen reader, however, will only happen when the combobox has focus. This occurs because the currently focused element in the browser must be the same element that includes the aria-activedescendant attribute, which is also the same element that includes role=”combobox”.

When interacting with the same combobox on a mobile device such as an iPhone or iPad running VoiceOver in Safari, however, you will notice that the aria-activedescendant referenced listbox option is not actually announced when it appears, only the expandable state of the combobox is. (This may change in the future, but this is the current behavior in the latest release of iOS16 as of 10/24/2022.) As a workaround, for mobile touch devices, a live region is used instead to announce the first matching listbox option when rendered. This makes it possible for non-sighted VoiceOver users to recognize (1) that a change has occurred, and (2) what the closest match to the typed in criteria is while the user is navigating the virtual keyboard by touch.

Important Upcoming Changes

Back when the ARIA 1.1 Combobox design pattern was being drafted, the aria-haspopup attribute was extended to support token values. The primary reason for this was to be included within the new 1.1 Combobox design pattern for the purpose of conveying to screen reader users the type of widget that the combobox was going to open. E.G. A “listbox”, “tree”, “grid”, etc.

Over the years, various bugs were filed with screen readers in an attempt to get this properly supported, however, sufficient support was never added; thus prompting Issue 1024 to be filed against the ARIA spec.

Since it is highly unlikely at this point that sufficient support will ever be implemented, the ARIA Working Group is moving towards reverting aria-haspopup back to its original values of “true” or “false”, and restricting its use to only refer to the opening of ARIA Menus and nothing else.

ARIA Menu Test Pages

·???????Left-click ARIA Menu.

·???????Right-click ARIA Menu.

This is relevant to comboboxes, because all instances of aria-haspopup=”listbox” and other token values will eventually stop working when these mappings are changed in the browsers and will simply revert back to “true” in the accessibility tree as they once did years ago.

Hopefully this article helps to explain the current state of the ARIA Combobox design pattern, and also how to implement them properly going forward.

You can download and run all of the above examples locally by cloning the Apex 4X GitHub project and get started by reading the Beginner Tutorial.

Sincerely,

Bryan Garaventa