Community
Participate
Working Groups
Win 7 and Mac, latest build (20121031-2000) With screen reader running (I was using JAWS on Win 7 and VoiceOver on Mac) type a few characters into the Quick Access field. (I typed the word "test"). The screen reader correctly says "t e s t" as you type. Now arrow down in the drop down list. The screen reader just says "test" "test" "test" every time you type a down arrow, instead of reading the selected item. It would seem that the focus is still on the text field. So, a bit of a dilemma here: the screen reader needs to read out the selected item... but the text field needs to keep the keyboard focus so that the user can continue to type in the search field. (i.e. be careful not to break bug 162926). I will find out what apps do to help screen readers in cases like this.
On Linux, Orca doesn't say anything at all when you type down arrow in the drop down.
The Windows "Start menu" has a "Search programs and files" text box that behaves in a similar manner. Both JAWS and NVDA Windows screen readers do a good job of this: - click on start menu, and they say something like: "Start menu search box edit. Type text or press up or down arrow to move through selections". - as the user types, keys are spoken, and the selected item at the top of the list is read. - up or down arrow reads the newly-selected item. I don't know if the screen readers have special handling for this, or if it j ust works.
*** Bug 409017 has been marked as a duplicate of this bug. ***
This may be able to be managed using SWT's accessibility listeners. We could add an accessibility listener to the 'text' control using text.getAccessible().addAc.... Then we'd need some logic to determine what the correct output we want to send to the reader is. For example rather than just emitting the text of the selected element in the list if it's a view the string we may want read might be "View <View name>"... This way we should be able to have the reader(s) do the correct thing even though the KB focus remains on the text control itself. +1 for Car's idea of trying to match the 'standard' windows start button handling.
Created attachment 231504 [details] SearchField.java Eric, I am attaching a "patch" (can't create an actual patch because I just imported org.eclipse.ui.workbench from the platform, so - sorry - I attached the whole SearchField.java file... you can paste it on top of your SearchField.java and then compare to see diffs). Note: It is NOT finished - I have to run - but it is a proof-of-concept, and it *works* (only tried it with NDVA - still would need to try with JAWS). The biggest remaining problem is that the selectionString needs to be cleared when the shell is dismissed, and better still, the accessible name listener should be removed from the table until it is dropped down again. Or something like that. Also there are still System.out.println's in the code - those need to be removed, code needs to be prettied and reviewed, but I think you should start with this and fine tune it, and you'll be done. Good luck.
You will also need to do the NLS/ResourceBundle stuff to concatenate the 2 strings with colon-space between. i.e. in SearchField.java: ... selectedString = NLS.bind(QuickAccessMessages.QuickAccess_SelectedString, item.getText(0), item.getText(1)); ... and in the associated messages.properties file: QuickAccess_SelectedString={0}: {1}
Thanks a bunch Car 1 Moving to 4.3.1 for implementation...
Review URL: https://git.eclipse.org/r/#/c/15817/
Committed: http://git.eclipse.org/c/platform/eclipse.platform.ui.git/commit/?id=b6e6a5e4921ab818676228e0638bd5005eebbc2f Wojciech, I don't have JAWS handy, could you take tomorrow's I-build and verify that this has gone in correctly ?
I reopen the defect because the last fix does not work with JAWS. With NVDA it works only sometimes. More investigation is necessary. Verified in build I20130916-2330.
I tested the quick access drop down once again, this time on fresh Windows 7 instances. The quick access works fine with NVDA, but does not work with JAWS at all.
It seems that the problem with JAWS is caused by a bug in SWT. I have opened a new bug 421255.
The underlying SWT bug is fixed. PW
It turns out that that bug 421255 was not the real cause of the problem. There are more problems related to SWT accessibility and JAWS - see bug 425586.
This may still not work with JAWS, but that appears to be a JAWS bug. See bug 425586 PW
Verified in I20140303-2000 with NVDA.
