(In reply to James Teh [:Jamie] from comment #0) > After bug 1513337, the address bar suggestions are pretty broken for screen readers (and probably other accessibility clients). > > STR (with the NVDA screen reader): > > 1. Focus the address bar. > 2. Type test > 3. Press backspace. > - Expected: NVDA should say "t" > - Actual: It says nothing. > 4. press right arrow. > 5. Press NVDA+upArrow to report the current line. > - Expected: NVDA should say "tes" > - Actual: It says nothing. > 6. Press NVDA+tab to report the focus. > - Expected: NVDA should say just "Search with Google or enter address combo box focused expanded has auto complete editable, tes" > - Actual: NVDA says this, followed by "list graphic" and all of the search results. > 7. Press down arrow to move to a suggestion. > - Expected: NVDA should report the suggestion. > - Actual: NVDA says "unknown". > > This is due to aria-owns="urlbarView-results" on the input. As I noted in bug 1522440 comment 15, this was previously a no-op because of the different id scope. After bug 1513337, it takes effect and causes some undesirable side effects. > > There are two problems here: > > 1. Making the list owned by the input means that the content of the list is treated as part of the input. This is the cause of the broken behaviour outlined in steps 5 and 6 above. > > We can fix this by putting role="combobox" on the moz-input-box parent and moving aria-owns to that. Sigh... moz-input-box is supposed to go away at some point so we probably don't want to use that. I was wondering why the input is wrapped in a seemingly useless div here: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html#sc1_label Now I begin to understand. This seems ugly and I don't understand how authors are supposed to know this in the first place. The whole combobox accessibility story seems brittle and not at all intuitive. > 2. #urlbarView-results is inside a popup panel, which means it has a different OS widget (HWND on Windows). When a focus event is fired for the selected suggestion, on Windows, an event gets fired with the HWND of the popup and the id of the suggestion. The client then retrieves the accessible for that HWND (the panel element) and asks it for the id of the suggestion. Unfortunately, since the suggestion has been re-parented with aria-owns, it's no longer a descendant of the panel, and thus we fail: Bug 1551598 is moving us away from using a popup.
Bug 1567377 Comment 3 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to James Teh [:Jamie] from comment #0) > 1. Making the list owned by the input means that the content of the list is treated as part of the input. This is the cause of the broken behaviour outlined in steps 5 and 6 above. > > We can fix this by putting role="combobox" on the moz-input-box parent and moving aria-owns to that. Sigh... moz-input-box is supposed to go away at some point so we probably don't want to use that. I was wondering why the input is wrapped in a seemingly useless div here: https://www.w3.org/TR/wai-aria-practices/examples/combobox/aria1.1pattern/listbox-combo.html#sc1_label Now I begin to understand. This seems ugly and I don't understand how authors are supposed to know this in the first place. The whole combobox accessibility story seems brittle and not at all intuitive. > 2. #urlbarView-results is inside a popup panel, which means it has a different OS widget (HWND on Windows). When a focus event is fired for the selected suggestion, on Windows, an event gets fired with the HWND of the popup and the id of the suggestion. The client then retrieves the accessible for that HWND (the panel element) and asks it for the id of the suggestion. Unfortunately, since the suggestion has been re-parented with aria-owns, it's no longer a descendant of the panel, and thus we fail: Bug 1551598 is moving us away from using a popup.