search

Esri / calcite-design-system

A monorepo containing the packages for Esri's Calcite Design System
https://developers.arcgis.com/calcite-design-system/
Other
289 stars 76 forks source link

Provide context to `dropdown` item selections when closing the menu for screen reader users #4866

Closed geospatialem closed 6 months ago

geospatialem commented 2 years ago

Summary

When a dropdown item is selected screen reader users aren't currently provided with feedback that a selection, or un-selection has been made. In order for them to get this context they must re-open the component in its entirety, and navigate through each item to hear the selection(s).

Actual Behavior

Screen reader users must navigate the dropdown menu completely upon selection/un-selection to identify if a selection, or multiple selections exist in the menu.

Expected Behavior

Provide context to users if they make item selections, or un-selections.

Reproduction Sample

https://developers.arcgis.com/calcite-design-system/components/dropdown/#sample

Reproduction Steps

  1. Enable a screen reader (NVDA, JAWS or VoiceOver)
  2. Navigate to the sample
  3. With the screen reader active, navigate via keyboard to focus on the "Activate dropdown" button to trigger the dropdown
  4. Select a dropdown item in the list.
  5. Observe no selection context is provided to the screen reader user, and they must navigate the dropdown in its entirety to receive feedback on the selections.

Reproduction Version

beta.83

Working W3C Example/Tutorial

No response

Relevant Info

Regression?

No response

driskull commented 2 years ago

I tried a few things with voiceover but no luck. I think this one might be related to the shadowRoot/slotting of web components. We might need to experiment or research a bit more.

geospatialem commented 2 years ago

I tried a few things with voiceover but no luck. I think this one might be related to the shadowRoot/slotting of web components. We might need to experiment or research a bit more.

Will dig into some research with this one this week. Thanks for taking an initial look at this, @driskull!

geospatialem commented 2 years ago

Based on the W3C editor menubar example it looks like we've built a solid implementation. For instance:

Users of assistive technologies can identify the currently active format options because they are represented by menu item radio and menu item checkbox elements that have a checked state.

We could provide context on selection, similar to WebAIM's solution, which provides context when the item is selected (e.g., "Mumbai" on selection).

We do provide this context when the disableCloseOnSelect property is set, but when the closeCalciteDropdown function is triggered, screen readers don't receive context the item has been selected. Instead users are informed the dropdown has closed and the focus has changed, with no indication a selection/un-selection has occurred.

Since this is the default function of calcite-dropdown, we should aim to provide feedback to screen reader users when the dropdown is collapsed on selection.

@driskull Would it be possible to provide the context of the selection in the calciteInternalDropdownItemSelect Event prior to the closeCalciteDropdown function call?

driskull commented 2 years ago

@geospatialem how do we provide that context?

geospatialem commented 2 years ago

@geospatialem how do we provide that context?

Not super confident in a good implementation. It seems like prior to closing, perhaps in the calciteInternalDropdownItemSelect, we'd need to ensure the selection is heard back prior to running lines 365-371.

Was able to get it to successfully work after delaying via a setTimeout of 0.05 seconds (50 ms), but that changes the expected experience to users.

@driskull Is there a better method, perhaps a Promise prior to running closeCalciteDropdown?

driskull commented 2 years ago

hmmm Let me play around with it a bit.

It could be that it's getting hidden when not open when it shouldn't be.

geospatialem commented 1 year ago

Moving to the May release, possibly sooner, if we are able to prioritize without a breaking change.

geospatialem commented 1 year ago

Research needed to determine next steps in the August milestone to identify a solution, or solutions to mitigate.

alisonailea commented 1 year ago

This requires a refactor of Dropdown to move aria- attributes to LightDOM elements

anveshmekala commented 6 months ago

We could provide context on selection, similar to WebAIM's solution, which provides context when the item is selected (e.g., "Mumbai" on selection).

Not sure if this is related to Voiceover , when selected the context is missing with WebAIM example. The menu is closed without announcing selection.

anveshmekala commented 6 months ago

Notes from sluething :

Providing context for default use case of dropdown when closeOnSelectDisabled is set to false might be complex considering the shift in focus on to trigger element when dropdown is closed. Considered the following solutions to solve this scenario but none of them seems to be feasible.

  1. Moved aria-attributes related to trigger element from slot to trigger element. This didn't solve the issue but would be a good refactor story to avoid setting aria attributes on slot elements as per W3C https://w3c.github.io/html-aria/tests/slot.html
  2. Adding a AT message element and announce to the user when the selection happens. This could have been a viable option but the focus behavior of dropdown limits us in going forward with this approach. Adding aria-live /aria-busy attributes and updating the content didn't help the case considering the focus shift from dropdown-item to trigger element after selection takes precedence over change in aria-live element content.
  3. Adding setTimeOut after closing the dropdown solves the issue but it isn't a rigid solution.

Additionally, stumbled up on VoiceOver missing context when user selects/de-selects an item when closeOnSelectDisabled is set to true with safari in contrast with NVDA/JAWS which provide context to the AT user.

geospatialem commented 6 months ago

We are closing the above issue as dropdown's missing context when an item is selected is expected considering the roles of "menu" and "menu-item", since there isn’t a separate role defined for the dropdown pattern from W3C. This is a similar pattern identified with other design systems, such as Fluent.

Once the item is selected, the component's menu is closed as per W3C recommendations.

Closing the component does not provide the context of which item is selected to the user because dropdown-items are hidden from the UI. This is expected considering the component's menu is often associated with change in UI or populating a form field. Users are suggested to use an ARIA live region on the element, which is updated related to dropdown-item selection as shown here.

Additionally, adding the closeOnSelectDisabled attribute provides context of items being selected/de-selected while the dropdown remains open. As an alternative option, if developers wish to provide context they can use the select or combobox components, which provide context once the option is selected and component is closed.