[a11y] Refine ARIA implementation

[steveszc]

The following items resulted from an accessibility audit performed by Interactive Accessibility on an app I'm working on. I'm happy to take on the bulk of the work outlined below, but some of these changes may require non-trivial changes to the architecture of some of the add-on's components. I imagine I may need some assistance to make some of these changes without introducing breaking changes to the API or visual styling.

What's broken? / why do these changes need to be made?

The main issue currently is that due to incorrect implementation of aria roles and attributes the power-select component is not very usable by a screen reader. For example as as screen reader user keys through the options, the currently focused option can not be announced, and the number of available options can not be announced. This should be considered a "critical" issue from an a11y perspective. The items outlined below *should* fix this. ARIA is a complicated beast so I'm open to feedback on the items below. I've tried to provide links to W3C WAI-ARIA docs justifying these changes. At the end of the day these changes will need to be tested across a range of screen readers to ensure it functions correctly.

Work items

• basic-dropdown Use aria-owns instead of aria-controls to associate the combobox with the listbox
  
  https://www.w3.org/TR/wai-aria/roles#combobox

• basic-dropdown aria-owns/aria-controls must reference an element that exists in the dom.
  
  Currently the trigger's aria-controls attribute references an ID of a dom node that does not exist when the power-select is in the collapsed state. This is considered invalid markup and can break screen readers. The controlled element (the listbox) should be maintained in the dom even when collapsed, it can be an empty div/ul. - https://www.w3.org/TR/wai-aria/states_and_properties#aria-owns

• basic-dropdown aria-haspopup should not be used on the trigger
  
  aria-haspopup is an implicit property of a combobox. Explicitly adding aria-haspopup implicitly and incorrectly defines the element as an aria menu (similar in semantics to a right-click contextual menu or the menu ribbon in MS Word or an OS), which not the correct role for the trigger. This attribute is not necessary on a combobox.
  https://www.w3.org/TR/wai-aria/states_and_properties#aria-haspopup
  https://www.w3.org/TR/wai-aria/roles#combobox

• basic-dropdown aria-pressed should not be used on the trigger.
  
  aria-expanded is sufficient to imply behavior to screen readers. aria-pressed is intended for toggle buttons such as checkboxes or tri-state buttons.
  https://www.w3.org/TR/wai-aria/states_and_properties#aria-pressed

• Assign role="combobox" to the trigger
  
  role="button" is inappropriately used here. The trigger should be given the combobox role and should be present in the dom as a combobox regardless of the expanded/collapsed state of the power-select. https://www.w3.org/TR/wai-aria/roles#combobox

• Use role="combobox" on the trigger when search is disabled, set aria-autocomplete="none"
  
  Even when search is disabled the power-select is still a combobox and should be defined as one. aria-autocomplete should be set to "none" when search is disabled, or the attribute can be removed since "none" is the default aria-autocomplete value for a combobox
  https://www.w3.org/TR/wai-aria/roles#combobox

• Add aria-autocomplete="list" attribute to the combobox
  
  When search is enabled the aria-autocomplete="list" attribute should be added to the combobox
  https://www.w3.org/TR/wai-aria/states_and_properties#aria-autocomplete

• Implement aria-activedescendant on the combobox
  
  aria-activedescendant allows a screen reader to track which option is currently focused. Each option needs an id, as focus changes from one option to the next this attribute should be updated to reference the id of the selected option.

• Use aria-selected (instead of aria-current) to indicate currently selected option
  
  https://www.w3.org/TR/wai-aria/states_and_properties#aria-selected
  https://www.w3.org/TR/wai-aria-1.1/#aria-current

• Add aria-multiselectable to the listbox for power-select-multiple
  
  https://www.w3.org/TR/wai-aria/states_and_properties#aria-multiselectable

• Add role="presentation" to markup for groups
  
  When groups are displayed all markup associated with a group should have role="presentation". Currently role="options" is present on the group li elements AND the actual options which are nested inside the groups, which is invalid. Additionally, each group's ul has role="group", which should be changed to role="presentation". Each group label should have tabindex="-1" and role="presentation" so that it can be focused an announced by screen readers.

• Remove aria-controls from ul elements inside the listbox.
  
  This is invalid. These lists do not actually control the trigger.

• Implement a role="status" container to track current number of options
  
  To replicate functionality of a native html select, a screen reader should be informed of the number of options in the power select. There should be a hidden div with role="status", aria-live="polite", and a unique id which should be referenced by an aria-controls attribute on the associated combobox.

• Add screen reader instructions for operating the select/multiselect
  
  Add a hidden div with a unique id containing instructions for operating the power select or multiselect. This should be associated to the combobox using the aria-describedby attribute on the combobox, referencing the id of the div.
  ex "As you type suggestions will be made available. Browse the suggestions using the up and down arrow keys. Pressing enter will select the current option. Pressing escape will clear the current selection."

Test Plan

TBD

Most of this is probably difficult or impossible to test using typical acceptance/integration tests

[cibernox]

Currently the trigger's aria-controls attribute references an ID of a dom node that does not exist when the power-select is in the collapsed state. This is considered invalid markup and can break screen readers. The controlled element (the listbox) should be maintained in the dom even when collapsed, it can be an empty

I believe that this is impossible. Would it be acceptable to add the aria-controls/aria-owns only when the component opens?

Could also that agency perform an audit of https://github.com/cibernox/ember-basic-dropdown? That is the component that contains a good amound of the a11y concerns.

I believe that part of there issues arise because EPS is a combobox that is built on top of EBD, which is a more generic/agnostic click-here-and-content-will-appear. Not that it cannot be fixed, but I'd like to know which would be sane default for EBD, even it then EPS decides to overrides (p.e, disable aria-haspopup)

[cibernox]

I've experimented quickly with mixed results.
I was able to make the single select (using voice over) to work reasonably well when the search is disabled. It tells you the option you are highlighting and allows you to select it.
I couldn't make it work easily when the search is enabled. I think that in that case the searchbox must be considered a combobox inside another combobox and must have its own aria-activedescendant.

But I think that all the pieces are ready, now you can play with this. I think it's close.

[Willibaur]

Hi there, is there any update on this issue?
I just noticed that Screen readers are not catching options within dropdown at all.
Thanks

[theklr]

any updates on this?

[mkszepp]

We have added some parts in the last years and specially in v8 and the addon should be conform with a11y

If something is missing/incorrect please open a new isuue for a11y improvment, so we will try to fix/improve it