Closed Bug 1190366 Opened 9 years ago Closed 9 years ago

Accessibility label for Search Engine AutoComplete item is wrong

Categories

(Firefox :: Address Bar, defect, P1)

defect

Tracking

()

VERIFIED FIXED
Firefox 42
Tracking Status
firefox42 --- fixed

People

(Reporter: MarcoZ, Assigned: adw)

References

Details

(Keywords: access, Whiteboard: [unifiedcomplete][fxsearch])

Attachments

(1 file, 1 obsolete file)

Since the introduction of the new ability to perform a search right from the Awesome Bar, the accessibility label constructed for the AutoComplete item is wrong. For example:

1. Open a new tab.
2. Start typing in something that is not www or a protocol, but any kind of search term.
3. Focus lands on the first item in the AutoComplete list. Screen readers now speak something like shown in the following protocol excerpt:

INFO - globalCommands.GlobalCommands.script_navigatorObject_devInfo (15:32:23):
Developer info for navigator object:
name: u'Google moz-action:searchengine,{"engineName":"Google","input":"news","searchQuery":"news"} Search'
role: ROLE_LISTITEM
states: STATE_FOCUSABLE, STATE_SELECTABLE, STATE_FOCUSED, STATE_SELECTED
isFocusable: True
hasFocus: True
Python object: <NVDAObjects.IAccessible.mozilla.BrokenFocusedState object at 0x056FE210>
Python class mro: (<class 'NVDAObjects.IAccessible.mozilla.BrokenFocusedState'>, <class 'NVDAObjects.IAccessible.mozilla.Mozilla'>, <class 'NVDAObjects.IAccessible.IAccessible'>, <class 'NVDAObjects.window.Window'>, <class 'NVDAObjects.NVDAObject'>, <class 'baseObject.ScriptableObject'>, <class 'baseObject.AutoPropertyObject'>, <type 'object'>)
description: u''
location: (77, 156, 317, 89)
value: None
appModule: <'firefox' (appName u'firefox', process ID 4072) at address 528ec70>
appModule.productName: u'Nightly'
appModule.productVersion: u'42.0a1'
TextInfo: <class 'NVDAObjects.NVDAObjectTextInfo'>
windowHandle: 197194L
windowClassName: u'MozillaDropShadowWindowClass'
windowControlID: 0
windowStyle: -1778384896
windowThreadID: 4076
windowText: u''
displayText: u''
IAccessibleObject: <POINTER(IAccessible2) ptr=0xc2bf284 at 52a08a0>
IAccessibleChildID: 0
IAccessible event parameters: windowHandle=197194, objectID=-4, childID=-1031
IAccessible accName: u'Google moz-action:searchengine,{"engineName":"Google","input":"news","searchQuery":"news"} Search'
IAccessible accRole: ROLE_SYSTEM_LISTITEM
IAccessible accState: STATE_SYSTEM_SELECTABLE, STATE_SYSTEM_SELECTED, STATE_SYSTEM_FOCUSED, STATE_SYSTEM_FOCUSABLE, STATE_SYSTEM_VALID (3145734)
IAccessible accDescription: u''
IAccessible accValue: None
IAccessible2 windowHandle: 197194
IAccessible2 uniqueID: -1031
IAccessible2 role: ROLE_SYSTEM_LISTITEM
IAccessible2 states: IA2_STATE_OPAQUE, IA2_STATE_ACTIVE (1025)
IAccessible2 attributes: u'margin-left:0px;text-align:start;text-indent:0px;setsize:12;margin-right:0px;tag:richlistitem;class:autocomplete-richlistitem;margin-top:0px;posinset:1;margin-bottom:0px;display:-moz-box;explicit-name:true;'

The important part for this bug is:

name: u'Google moz-action:searchengine,{"engineName":"Google","input":"news","searchQuery":"news"} Search'

This looks like a JSON object to me. When constructing the text to be spoken for the screen reader, it should be something more sensible like "Search for [search term] with [readable engine name]". And of course, this should be localizable.

Please follow the guide provided by the code snippets to construct the label for bookmarks or tags.
Flags: firefox-backlog?
Flags: firefox-backlog?
Priority: -- → P1
Flags: firefox-backlog+
Whiteboard: [unifiedcomplete][fxsearch]
Assignee: nobody → adw
Status: NEW → ASSIGNED
Note this test could be re-used/improved: browser/base/content/test/general/browser_autocomplete_a11y_label.js
Rank: 19
Attached patch patch (obsolete) — Splinter Review
Marco Z., could you please try the build here?  https://ftp-ssl.mozilla.org/pub/mozilla.org/firefox/try-builds/dwillcoxon@mozilla.com-d68d07835372

This fixes both search suggestion labels and switch to tab labels, at least in my testing with Apple's VoiceOver.  Currently switch to tab labels also read as moz-action URI's, which surely can't be right.

Try server link: https://treeherder.mozilla.org/#/jobs?repo=try&revision=d68d07835372
Attachment #8645163 - Flags: a11y-review?(mzehe)
Comment on attachment 8645163 [details] [diff] [review]
patch

Try results look OK.  The oth failures are from another commit in my tree that happened to be on fx-team when I pulled.

Marco B., if you're doing reviews before the end of next week, feel free to fix any nits and land this, if you r+ it, since I'll be away.
Attachment #8645163 - Flags: review?(mak77)
Attachment #8645163 - Attachment is obsolete: true
Attachment #8645163 - Flags: review?(mak77)
Attachment #8645163 - Flags: a11y-review?(mzehe)
Attachment #8645353 - Flags: review+
Marco, you can check the results in the Try build Drew created:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=d68d07835372

Otherwise you can just wait for the Nightly after this patch will be merged to central, that I hope will happen today or tomorrow.

Please let us know if the situation improved and how we can make it even better.
Flags: needinfo?(mzehe)
Flags: in-testsuite+
https://hg.mozilla.org/mozilla-central/rev/8cc0bb696585
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 42
Not sure if it is this bug or some other bug that landed alongside, but the autocomplete list is now completely broken for me in the 2015-08-09 nightly build. It is sluggish, it is not exposing list items any more, and it is also not giving me any labels. The accessibles are "unknown". But the error console doesn't show anything significant.
Flags: needinfo?(mzehe)
I wonder if it's the opt-in notification, could you please try setting browser.urlbar.userMadeSearchSuggestionsChoice to true and check if that makes a difference?
Flags: needinfo?(mzehe)
No, doesn't make a difference. The moment the list or whatever it is appears, my whole accessibility tree gets borked. And there were no landings that could account for this from our end I believe, none that are active at least. A few e10s things, but I have e10s disabled.
Flags: needinfo?(mzehe)
OK, sorry for the noise! It appears to have been a local fluke that corrected itself as I started investigating the exact regression range. All works now, and the new labels work great, too. Thanks!
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: