As explained in Bug 1285591 comment #17, the autocomplete-popup might be setting aria attributes on the wrong element depending on how the user triggered the autocompletion. (In reply to Yura Zenevich [:yzen] from comment #17) > Comment on attachment 8774272 [details] > > Regarding the active element: though in practice it might act as expected, > e.g. active descendant of current user focus is the autocomplete, in reality > I think it's a mistake. There are other ways screen reader users navigate > other than focus and tabbing, for example via virtual cursor[s]. These > virtual cursors are often separate from the keyboard focus. > > In this case contextually it will be confusing to find active descendants on > elements that autocompletes do not really belong to. I realize this > complicates things but it should somehow be addressed to avoid digging > ourselves deeper into the workaround hole. > > I'll remove the a11y-review for now, if you don't mind, so we could find the > suitable solution. The autocomplete popup callers should explicitely provide the autocomplete input when calling AutocompletePopup::openPopup (could default to the anchor if not provided ?)

We have 3 call sites for autocompletePopup:openPopup at the moment: - inplace-editor: provided anchor is the autocomplete input - sourceeditor/autocomplete: provided anchor is not the autocomplete input. The input can be retrieved on the codemirror instance using cm.getInputField() - inspector-search: provided anchor is not the autocomplete input. The anchor is a XUL textbox widget which is composed of an html:input which actually has the focus. The only way to get this input here seems to be via document.activeElement when the textbox has the focus Given the issue described for inspector-search, I am blocking this on Bug 1262443, which is about migrating the remaining XUL elements of the inspector to HTML. I am blocking this bug on Bug 1262443.