Closed Bug 1437431 Opened 4 years ago Closed 4 years ago

Adjust the accessible role for the PopupAutoCompleteRichResult panel to not be a menu

Categories

(Toolkit :: Autocomplete, defect, P1)

defect

Tracking

()

RESOLVED FIXED
mozilla60
Tracking Status
firefox-esr52 --- unaffected
firefox58 --- unaffected
firefox59 --- unaffected
firefox60 --- fixed

People

(Reporter: MarcoZ, Assigned: MarcoZ)

References

Details

(Keywords: access, regression)

Attachments

(1 file, 1 obsolete file)

After bug 1427366 landed, the parent of the RichListBox of the AwesomeBar AutoComplete, ID PopupAutoCompleteRichResult, is now a role "menu", where it was previously a role "unknown". Especially on Windows, however, some screen readers react very sensitively to a menu whose children are anything other than menu item, menu item checkbox, or menu item radio elements. Therefore, it would be better to adjust the role for this element to be a grouping (role="group") instead.

Paolo, where is this element defined exactly?
Flags: needinfo?(paolo.mozmail)
Nevermind, found it. :) Testing patch now.
Flags: needinfo?(paolo.mozmail)
Assignee: nobody → mzehe
Paolo, Surkov, I tried changing the XBL binding instead first, so we wouldn't have to assign a role for each panel or such that uses the binding, but that didn't result in a proper grouping role for the panel, but instead, an unknown accessible was created. I didn't manage to figure out why. Somehow, overriding the role from the base binding failed. Does either of you know why this is happening?
Attachment #8950198 - Flags: feedback?(surkov.alexander)
Attachment #8950198 - Flags: feedback?(paolo.mozmail)
Priority: -- → P1
Comment on attachment 8950198 [details] [diff] [review]
Alternative that does not work for a so far unknown reason

We are removing support for the "role" attribute on XBL bindings as part of the XBL removal project, and the "xul:groupbox" value is not supported since bug 1428930.

The element name is now what determines the role, and there is generally one role for each XUL element. Some element names may have different roles thanks to some special cases implemented in the XULMap.h file:

https://dxr.mozilla.org/mozilla-central/rev/9a0655ea8ae02f4d96bf23a607a94641f1c57f1b/accessible/base/XULMap.h#38
Attachment #8950198 - Flags: feedback?(surkov.alexander)
Attachment #8950198 - Flags: feedback?(paolo.mozmail)
Comment on attachment 8950197 [details]
Bug 1437431 - Give the Rich autocomplete panel a proper role to override the default popup XBL binding of menupopup,

https://reviewboard.mozilla.org/r/219462/#review225216

Looks good to me, since support for the "role" attribute on individual elements will still be available.

I wonder if the PopupSearchAutoComplete a few lines above, which is used for the separate search bar, should get the same role as well?
Attachment #8950197 - Flags: review?(paolo.mozmail) → review+
(In reply to :Paolo Amadini from comment #5)
> I wonder if the PopupSearchAutoComplete a few lines above, which is used for
> the separate search bar, should get the same role as well?

Yes, and the one above that one, for the general autocomplete on pages, as well. I'll add them and land the updated patch. Thanks!
Attachment #8950198 - Attachment is obsolete: true
hg error in cmd: hg push -r . -f try: pushing to ssh://hg.mozilla.org/try
searching for changes
remote: waiting for lock on working directory of /repo/hg/mozilla/try held by process '2595' on host 'hgssh4.dmz.scl3.mozilla.com/effffffc'
remote: abort: working directory of /repo/hg/mozilla/try: timed out waiting for lock held by 'hgssh4.dmz.scl3.mozilla.com/effffffc:2595'
abort: stream ended unexpectedly (got 0 bytes, expected 4)
Pushed by mzehe@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e458f8679b88
Give the Rich autocomplete panel a proper role to override the default popup XBL binding of menupopup, r=Paolo
https://hg.mozilla.org/mozilla-central/rev/e458f8679b88
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
You need to log in before you can comment on or make changes to this bug.