Community
Participate
Working Groups
Choose Help > Software Updates > Manage Configuration. In the resulting Product Configuration dialog, tab/cursor through the icons at the top (so, the 'Show Install Locations', 'Show Nested Features', 'Show Disabled Features', etc. buttons). Screen readers read these as check boxes - so, for example, the screen reader will say 'Show Disabled Features check box not checked'. In the main workbench UI, the screen reader always refers to these icons as 'buttons'. FYI - I tested this with both Jaws and Microsoft Narrator, and got the same result. FYI - I, personally, consider this a very low priority bug. It doesn't impacted the usability of the dialog by the person relying on a screen reader - it just misleads a bit... (apologies if 'Update' is the wrong component to open this against - I'm only guessing about this)
I have now noticed this in other places in the workbench. It's true - in the main workbench UI toolbar, these are read out correctly by the screen reader. But in other places, they are not... for example, the Fast view icons (when you've created Fast views, those icons at bottom left of workbench), some view icons. I will transfer this elsewhere - I'm just not sure yet... Probably UI.
I'm changing this to the UI component, in hopes that it is the correct one.
This is an MSAA limitation IIRC. Either way SWT is the link between widgets and the OS. Usually the best test tool is Microsoft Inspect Objects as it shows exactly what MSAA thinks it is getting.
I discussed with the accessibility centre - they will look into why this happens with Jaws. For now, I am to leave this bug open. Pending their investigation, they will tell me to close this or they will open a bug of their own (at which time I'll close this one).
It is actually because those particular ToolItems have CHECK or RADIO style, and on Windows, those are implemented using the BTNS_CHECK style bit. Here is the MS definition, found on the following web page: http://msdn.microsoft.com/library/default.asp?url=/library/en- us/shellcc/platform/commctls/toolbar/styles.asp BTNS_CHECK Version 5.80. Creates a dual-state push button that toggles between the pressed and nonpressed states each time the user clicks it. The button has a different background color when it is in the pressed state. So by using the word "checked" instead of "pressed" the screen readers are actually using the correct word to more closely convey the meaning that "this button has been pressed and it stayed pressed". The reason that you hear "button" on the main workbench toolbar is that most of the tool items are push buttons. Note that the "Toggle Mark Occurrences" and "Show Source of Selected Item Only" buttons do have CHECK style. You can press them in and they stay pressed, or press again and they look "un-pressed". To enable those buttons, give focus to an editor and type ctrl+tab a few times. You will hear JAWS say "checked" or "unchecked" according to whether the button is "in" or "out". So, unless you feel strongly that JAWS should use a different word to describe the "pressed in" and "pressed out" state of a CHECK/RADIO button in a tool bar, then there is nothing to do here. I suspect that blind users have grown used to having virtual check boxes in tool bars. This is how a screen reader would speak this particular item in any application, not just eclipse. (although there are not that many applications that actually let the toolbar take focus, so eclipse is breaking ground there).
I don't feel strongly... Like I said, I have passed this on to the accessibility centre. They have this bug number. If they want to re-raise the issue, they can - until that happens, I'm happy leaving this as resolved invalid. Thanks...
