Community
Participate
Working Groups
20021113 The labels on the Radio groups in the JavaPreferencePage will not be read by screen readers. Use Group boxes instead. Also an issue for the Code Generation, New Project and Refactoring Page.
*** Bug 11706 has been marked as a duplicate of this bug. ***
*** Bug 16532 has been marked as a duplicate of this bug. ***
we have deferred this for 2.0 should revisit now. Below is the answer from Nick. Bug 15559 is marked as fixed. Tod - why are we not OK by now? --- from Nick --- Groups are more accessible than preceding labels. When using a screen reader like JAWS, it normally reads only those items that can take focus. When reading an item in a group box, it also prefixes the item's label and state with the group's label. Plain labels are skipped, unless the control itself does not have its own label (e.g. a List or Tree), in which case it reads the preceding label (giving this label a mnemonic is also used to give the other control focus). But there are some problems with this support too -- it does not work for Trees (this is a platform limitation - see bug 10755). JAWS is supposed to be able to read the whole dialog using a special key (Ins+D), but this does not work with our dialogs because they have a dumb algorithm -- they don't tunnel down through all composites. See bug 15559 for the gritty details. So, despite the ugliness, we have generally gone with groups for this reason. Nick
Bug 15559 is for a different problem. In that case when you did a reading of a dialog it read the parent - it now reads the dialog. However JAWS still has to imply a relationship between widgets and a label is not associated with radio buttons - only group boxes are. The basic way they do it is that when a widget gets focus it reads as high up the chain of parents as it can - as the label is not one of the widgets in the parent chain of the radio box it gets ignored.
refactoring page fixed for M4 (bug 26451)
Fixed remaining preference pages for build > 20030106
