Open Bug 967525 Opened 11 years ago Updated 4 years ago

Make CC: and other bug reporting field autocompletes accessible

Categories

(bugzilla.mozilla.org :: User Interface, enhancement, P3)

Production
enhancement

Tracking

()

People

(Reporter: MarcoZ, Unassigned)

References

(Blocks 3 open bugs)

Details

(Keywords: access, Whiteboard: [october-2019-bmo-triage] )

When creating a new bug, the search for components/products is very accessible to blind screen reader users. You hear when suggestions are available, and when selecting an entry using the arrow keys, you also get speech feedback. Please apply the same to the CC: and other fields where autocomplete is used when creating or modifying a bug.
Severity: normal → enhancement
How do we do that? What's the magical HTML attribute?
(In reply to Frédéric Buclin from comment #1) > How do we do that? What's the magical HTML attribute? 1. The edit field(s) get: a) aria-autocomplete="true" to indicate that there is an auto-complete mechanism at work. This is independent from the autocomplete attribute and is purely semantic for screen readers, so doesn't change browser behavior. b) aria-expanded="false" if no results are currently showing, and aria-expanded="true" once results are showing. c) aria-controls=idref to the listbox (see below) that contains the actual results. 2. The ul of autocomplete results gets: a) role="listbox". b) an ID (if it doesn't already have one) that aria-controls from above points at. 3. The individual entry li elements get: a) role="option". b) tabindex="-1" to make them focusable with the keyboard, but not include them in the tabbing order. c) aria-selected="true" if the current element is the selected one, otherwise aria-selected="false". All elements that are currently in the list must have an aria-selected value, but only one of them must be "true" at any given time. 4. Once there are elements showing, aria-expanded on the textbox gets a value of "true". 5. Once the user presses downarrow to go into the list, the first item should receive keyboard focus by setting resultElement.focus on it. Every subsequent press of up or down arrow will move the cursor up and down through the elements. 6. If the user presses Enter or tab to accept the autocomplete, the field gets filled, and keyboard focus is returned to the text field. 7. If the user presses Escape, focus is returned to the text field without accepting the chosen entry.
I’ll create an accessible autocomplete widget to replace the Devbridge Autocomplete jQuery plug-in we are currently using. https://github.com/devbridge/jQuery-Autocomplete The best practices and examples can be found at: https://w3c.github.io/aria-practices/#combobox
Assignee: ui → kohei.yoshino
Product: Bugzilla → bugzilla.mozilla.org
QA Contact: default-qa
Version: unspecified → Production
Blocks: 1478901
Blocks: 1493992
Blocks: 1539271

It’s time.

Status: NEW → ASSIGNED

Is this still being worked on?

Flags: needinfo?(kohei.yoshino)

Yes, I have a WIP branch, but I don’t think I can finish it soon.

Flags: needinfo?(kohei.yoshino)
Whiteboard: [[october-2019-bmo-triage] → [october-2019-bmo-triage]

Let's see if we can take Marco's changes in comment #2 and apply them.

Priority: -- → P3

I started using custom elements here (actually in Bug 1476107) and a blocker was the support for Microsoft Edge which doesn’t natively support the cool stuff. I guess I mentioned it before on Slack. This week it was announced that Chromium-based Edge would be shipping in January, so I’m planning to do this early next year.

Depends on: 1606014
No longer blocks: autocomplete-the-things
Assignee: kohei.yoshino → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.