Form.Autosuggest Accessibility

[MaxFrank13]

Improvements

There are a number of adjustments that can be made to the Form.Autosuggest component to make it more accessible. Some of these adjustments are relatively trivial and involve simply updating the attributes on a few of the HTML elements. However, other changes will require a bit of refactoring around the HTML structure, especially with regards to how labels are associated with the <input> element.

---

Resources

Accessible Autocomplete examples Anatomy of an Accessible Auto Suggest Best practices for the accessibility of an autocompletion component

---

Moving forward

Aperture team has plans to address these issues over time, but the work has not yet been assigned so we welcome any assistance others can provide. If any updates are made regarding the accessibility of the Form.Autosuggest component, please reference this issue and don't hesitate to reach out to @openedx/2u-aperture.

### Tasks
- [ ] https://github.com/openedx/paragon/issues/2435
- [ ] https://github.com/openedx/paragon/issues/2436
- [ ] https://github.com/openedx/paragon/issues/2437
- [ ] https://github.com/openedx/paragon/issues/2438

[brian-smith-tcril]

Great writeup here! I'm thinking it might make sense to split this up into a couple issues:

• Trivial fixes/more complex attributes
• Label Association (this seems like it could use some discovery/discussion around how we want to handle it, I think it'd be nice for those conversations to live on their own issue)
• Tab Behavior (this also could use some discussion, I'm not sure what best practices are for tabbing through/out of a suggestions dropdown)

[wittjeff]

@MaxFrank13 This is a good succinct summary of the accessibility issues. Just a couple of additional details:

• wrapping labels around controls works for virtually all screen readers, but it is still considered a WCAG 2.1 AA violation now; there should be a "programmatic" association of labels to their objects.
• aria-controls is also considered a requirements by some, so I suggest adding it in there. A control that has aria-haspopup attribute should generally also have an aria-controls attribute that points to a list that appears when aria-haspopup=list.
• We're wanting to move toward minimizing use of floating labels, due to incompatibility with browser autosuggest / autofill features. We might want to add an option for floating label state (previously suggested) so authors can show the label above the control all the time if they want to (and perhaps we should make that state the new default).

[wittjeff]

Regarding focus behavior, I refer to the linked articles outlining or demonstrating accessible autosuggest requirements. Additional background re aria-activedescendant: this attribute is intended to be a kind of "sub-focus". So a parent item has focus, but you're really working on some kind of child item. The two examples that come to mind are grids (parent has focus, active cell has aria-activedescendant) and comboboxes (input has focus, menu items have activedescendant.).

One thing to know here is that there are sometimes two ways to implement theses common patterns; you can make a grid where the cell being modified has focus, or where some control within that cell has focus.

Aria-activedescendant is intended to guide a screen magnifier so it can keep the thing you're working on in the magnification frame at all times. I'm not entirely sure of the level of support across accessibility tools.

Regarding aria-live: be aware that testing with VoiceOver on Mac OS with Chrome may not work as expected, particularly with aria-live. Instead use VoiceOver with Safari. This is a longstanding issue; I don't think Apple feels strongly motivated to fix Chrome compatibility bugs.