Community
Participate
Working Groups
Build ID: M20080911-1700 Steps To Reproduce: 1. Open any wizard in eclipse. (New Project...) 2. Press tab until the wizard description has a blinking cursor. More information: Why would anyone want to traverse (with tab) to the description? If this is the desired behaviour then it should just as well do it for the Title. Recommend that the description not be a tab stop item, when pressing tab. One can just add a traverseListener and call event.doit = false etc etc
(In reply to comment #0) > Build ID: M20080911-1700 > > Steps To Reproduce: > 1. Open any wizard in eclipse. (New Project...) > 2. Press tab until the wizard description has a blinking cursor. > > > More information: > Why would anyone want to traverse (with tab) to the description? If this is the > desired behaviour then it should just as well do it for the Title. This is intentional. It is an accessibility requirement, intended for blind users who use screen readers. Screen readers require tab stops on anything that will be read to the user. The description typically explains what the page of the wizard is all about, so it is included. This is also done for error message areas and other places that do not have mnemonics but are required reading for the user. I'm assuming we don't do it for the title because the title is not necessary to understand the wizard (and typically the title simply repeats the menu/button text that launched the wizard originally).
FWI, the accessibility feature in windows (vista) doesn't read the description field when the wizard is opened. Only after it gets focus (from tab) it is read. It only receive focus tabbing through the entire dialog. I would expect this to be read first and not last after a tab sequence. By looking at the way the accessibility feature handles the rest of the os dialogs the descriptions get read and they are not text boxes, but labels. I also noticed that the window and wizard title gets read first. I suspect that it will be read before the wizard contents if it wasn't a text field. Would it not be better for the client of the wizard (eg: me), to have the ability to tweak this, rather than giving me no choice on the matter? I might want the description to be read first etc.
my understanding of the screen readers is that they will read labels that are adjacent to corresponding text fields. So when the focus is in a text field, the screen reader reads the adjacent label. But a label that exists by itself is not read because there is no corresponding field to receive focus. Hence the decision to use read-only (in the tab order) text. So that it is possible to read it. Since the focus is typically first placed in some modifiable field (text field, combo selection, etc.) the description is not read until the user shift-tabs back to it or tabs forward to it. To get the description to be read first, you'd have to place the focus in the description field. I suppose (but I don't know for a fact) that screen reader users are quite used to his and shift-tab back to the description if needed. What kind of client-side control are you looking for? Something in the code you could subclass the wizard and set the focus to the description if that's what you want), or are you saying you'd like some kind of accessibility preference that would affect the default behavior of all wizards? Since initial focus placement is done in each individual wizard, the latter is unlikely to happen...
Prakash is now responsible for watching bugs in the [Wizards] component area.
This works as intended and is a workaround for the issue described in the bug 248410. The "wizard description" field is actually used to show status and error messages. Prior to IAccessible2 adoption the only way to read error messages was to Tab to them. Hence, they were included in the Tab order. This behavior will be preserved for the time being as even after the bug 248410 is resolved, older versions of screen readers won't be able to take advantage of IAccessible2 functionality.
