Community
Participate
Working Groups
In Java Editor / Syntax / Preference the "Color button" and "Bold Checkbox" and "Custom Color Button" the labels are not associated with the controls. So JAWS and MS Inspect can't read them. This problems also appears in other pages there are implemented the same way.
Any plans to change this implementation? With the current model, this UIs are inaccessible.
please respond
MS Inspect does not report a name for the color buttons, so this is not a bug in JAWS. Recommend using IAccessible to report the name for these controls.
Nick would adding a Group around the list and the Color and Bold widgets fix the problem? This would result in a minor look change that would not invalidate screen shots in the documentation. Regarding IAccessible can you give us additional pointers, the only IAcessible class I've found is a internal win32 specific class.
When a control that can take focus is wrapped in a group, then the group label is read before the control when it takes focus (this is why we recommend using groups, since labels preceding the control are not read if the control has a label of its own). For example, on the Java / Editor / Syntax page, the colour button for custom background colour is read as "Background color, graphic 118, button". The "graphic 118" is how JAWS reads any graphic for which it doesn't have a mapping. The number changes when a different colour is chosen (the numbering is based on a CRC of the image contents). There is an option to turn reading unknown graphics off, so this is only a minor annoyance. As for the SWT accessibility support, the interface is org.eclipse.swt.accessibility.Accessible (IAccessible is in the OLE implementation). Something like the following should work: colorControl.getAccessible().addAccessibleListener( new AccessibleAdapter() { public void getName(AccessibleEvent e) { if (e.childID == SWT.CHILDID_SELF) e.result = "current color"; } } ); If you do this, this should avoid the "graphic X" being read, and a group will not be necessary. Recommend using MSAA's inspect32 tool to test this. See http://www.microsoft.com/enable/dev/ and follow the links to "Microsoft Active Accessibility 2.0 Software Development Kit Tools".
The example code below does not currently work with buttons - see Bug 21771. We are investigating how to make the ColorFieldEditor handle this by default - when that works we suggest switching to a ColorFieldEditor.
The JAWS accessibility support ignores the accessibility setting for buttons and will only read the text. There are two way we can make JAWS read these 1) Enclose the button in a group. This will look really bad. 2) Label the button using setText. I checked with the SWT team and there is no guarantee of display behaviour of a button if you set both the text and the image. On windows 2000 the text is ignored but this is not guaranteed behaviour.
Just to clarify: we already changed the bold check box for 2.0. It doesn't use a separate label anymore. So the checkbox should not cause any problems for screen readers. We only need a solution for the color button. IMO not only the Editor preference page is affect. Page that seems to be bogus in this regard are: Workbench->Appearance Workbench->Search Debug->Console Debug->Variables View Java->Editor External Tools Install Update Plugin Development->Editors Team->CVS->Console So we need a different solution for selecting colors. Currently this is always done using a button. Tod are there any new insights regarding this issue.
Bug 21771 describes the SWT issues with labelling a button with an Image. We donm't currently have a solution for this - it will have to be persued with Henter Joyce.
Moving to platform UI since this is not a JDT/UI only issue.
Marking as a dupplicate of Bug 18518 as this is part of the problem with JAWS ignoring the results of the IAccessible interface, *** This bug has been marked as a duplicate of 18518 ***
