Community
Participate
Working Groups
[This bug is in response to Bug 142231.] It seems that the ColorFieldEditor returns 'Color Selector' by default in the getName() method of the accessible API. This is not much use if the user doesn't know what s/he is selecting the color for. I suggest to use the labeltext as the default name for the screen reader to narrate the labeltext instead.
Created attachment 42065 [details] This screenshot shows a preference page containing multiple color selectors. You can see from the screenshot here that we have multiple color selectors...thus the default text narrated is 'Color Selector' for each of the buttons. This is not very useful in terms of actual accessibility. By default, I believe it should associate the accessibility name of the control to the label text, and the 'Color Selector' part can, perhaps, be provided as the description of the control (for example, instead of the default 'Push button -to press, use Space bar', the button's accessibility listener method can be overridden to provide 'Color selector - to select, use space bar').
Thanks, Syed. Targeting this for 3.3 since you have a workaround, and if it comes up again from other apps we might consider for 3.2.x.
We could fix this by having the field editor install a listener on the ColorSelector's button, using the field editor label as the name. This is the most straightforward, although ColorSelector would still be installing its own listener using "ColorSelector" as a name. Since this approach worked as a workaround in bug #142231, I assume that the last installed listener wins. I can verify on windows using Inspect32, but not sure how to verify on other platforms. The only way to avoid installing multiple listeners would be to add API to ColorSelector to supply the accessible name of the button, and then ColorSelector could install the listener to use that name if provided, or "ColorSelector" by default. I don't like this as it adds API for specifying accessibility info, and we don't normally do that. Karice, do you know how to check a control's accessible name on non-windows platforms so that I could verify that having FieldEditors install a second listener would work on all platforms?
There is a lack of tools and assistive technology for non-Windows platforms. If it works on Windows then I think is ok.
The reason we have not added any more support than the default is that to a non sighted user "Color Selector" is suffecient to let them know that it is of no use to them. The fact that it is a color for a particular item is not that helpful. I'll also point out that the themes extension point puts color settings in the colors and fonts preference page which is much easier for a user with color problems to use. Otherwise they have to hunt around all of the preference pages to find the one that defines the color they are having trouble with. I think any further work on this would be a waste of time as there is no user it would be useful for. ColorSelector does not have an associated label so adding one to cover this unneccessary feature would break all uses of ColorSelector out there. I would mark this WONTFIX. And Susan using the inspect32 tool is suffecient to test anything that calls the SWT accessibility API.
The suggestion was not to add a label to ColorSelector, but to use the label of the ColorFieldEditor as the accessible name when a ColorFieldEditor creates a ColorSelector. However, I understand Tod's position that a non-sighted user won't be changing the color anyway. Apps that want more specific labels can install the listener themselves as was done in bug #142231. So I will mark this as WONTFIX and if anyone else has issue with this it can be reopened.
