Combobox (Form) - Indicate live regions for dynamically changing content - (2036570497)

[dqateam]

Module:

40 Form

Violation:

Indicate live regions for dynamically changing content

WCAG Reference:

• 1.3.1 Info and Relationships

Instance ID:

2036570497

Severity:

9

Description:

[Issue]
There are dynamically changing content on activating or entering letter(s) in the "What is your favorite component(s)?" field that does not indicate live regions.

[User Impact]
Screen reader users will be unaware of important updates to this content when they occur.

[Code Reference]

<input aria-activedescendant="combobox-item-99352be9-91c2-5c5b-2603-da27e20e5061" aria-autocomplete="list" aria-controls="combobox-listbox-1b9b7881-0c55-e2cc-43a2-89b0875bd08e" aria-label="What is your favorite component(s)?" class="input input--single" id="combobox-input-1b9b7881-0c55-e2cc-43a2-89b0875bd08e" placeholder="Select favorites�" type="text">

Note:

[Suggestion]
Indicate live regions for dynamically changing content. Live regions can be created by adding a role attribute set to "log", "status", "alert", "progressbar", "marquee", or "timer" as appropriate. Alternatively, custom behavior can be created by using the aria-live, aria-atomic, and aria-relevant attributes. Text injected into this live region element will be announced by screen readers.

Importantly, the element with the ARIA live attributes must be available when the page loads. Otherwise, many screen readers will not detect updates to the element. Additionally, the element must be empty on page load unless an immediate screen reader announcement is desired.

Remove aria-hidden attributes from options.

Media Type:

Live Regions

Additional Resources:

• Report Source: Product accessibility evaluation conducted on the Calcite Design System in August, 2022.

[geospatialem]

Could be coupled with effort from #5587

[geospatialem]

When multiple values are present in the combobox, only one item (the latest added) is read back to AT, for instance in the following sample when Alert and Button are selected, only the last item, in this case, Button is provided to AT:

Screenshot of display:

JAWS transcript:

What are your favorite Calcite Components? �Combo box� 
Button
3 of 18
To change the selection use the Arrow keys.

There is a similar implementation by Twilio Labs with a Multiselect Combobox, which provides much better context with their code base.

Screenshot of display:

JAWS transcript:

Selected Paste components �list� 
with 2 items
Press Delete or Backspace to remove. Press Enter to toggle selection.
Alert

@jcfranco Not sure on the change we'd need to account for here. Could you take a peek to provide your expertise? 🧠

[jcfranco]

Excellent sleuthing! 🕵️‍♀️ Quickly comparing at DOM rendering, we could look into prototyping combobox using a container with the role of listbox for the selected items and it also applying option to selection chips to see if we get an improved interpretation.

[anveshmekala]

When multiple values are present in the combobox, only one item (the latest added) is read back to AT, for instance in the following sample when Alert and Button are selected, only the last item, in this case, Button is provided to AT:

Tested this with Voiceover + safari 16.4 and screen reader is able to read out all the selected options.

I see an issues with the combobox where user are unable to type or get into the input field of the combobox which could be an issues from Voiceover itself ( mentioned in multiple domains). The same issue is persistent in Twilio Labs Multiselect Combobox component.

To fix the above, tried moving the role attr to input element which fixes the above issue but restricts the Voiceover announcing selected options and treats the selected item chip's as plain text.

Additionally, I think there are multiple labels being read out, one from aria-label of the container element with role='combobox' , other from the <input/> element and also from the <label/> element which should have been removed here.

prototype #7323

[geospatialem]

Additional research will be sought in August to determine if the above recommendation:

1. Can be adopted with our current component,
2. If a refactor may be needed, and/or
3. If any of the accessible autocomplete examples can provide guidance for us

Additional observations from Anvesh's R&D and prototype include:

• label is being read due to some redundancy at the container level, input element level and label prop. One should remain, while the others should be removed/omitted
• The prototype isn't solving the original ask, however VO reads the selected options without issue
• NVDA and JAWS doesn't seem to have any specifics that could cause the issue to not be read back

[geospatialem]

Since the draft covers part of the context, and the efforts in providing support via dropdown in #4866 is underway, maybe we can combine some of the same efforts here as well? Pushing this issue out until December, to hold off until changes from 4866 can be ironed out.

[geospatialem]

Blocking this effort by the R&D of #4866.

[geospatialem]

Unblocked the above effort, however the efforts of dropdown cannot be included as there was no accepted solution that could be achieved.

[geospatialem]

Spike to determine if the above is still valid.

[geospatialem]

Context is provided when selecting or de-selecting combobox-items when performing manual testing with JAWS and NVDA. ✅

Additionally, there will be future efforts with #10144, which will provide further support via autocomplete and input search components.