Community
Participate
Working Groups
Build Identifier: M20100211-1343 Currently, the filter text field uses the dialog's message as its accessible label. The list box has no accessible label at all. To clarify, these labels are the ones that are used by accessible technologies (such as a screen reader) to describe the widgets. Ideally, it would be great to be able to get access to each of the widgets' Accessible objects to set a custom label. Reproducible: Always
Created attachment 188263 [details] Screenshot
(In reply to comment #0) > Ideally, it would be great to be able to get access to each of the widgets' > Accessible objects to set a custom label. I am not sure it is going to achieve anything. There are two "selectable" elements on this dialog: filter text and list of items. The filter text already has a label, settable by ElementListSelectionDialog#setMessage(). This message will be read by screen readers when the filter widget gets focus. The list does not have a label, but generally screen readers don't read labels for lists. In the screenshot attached I added a label "Abc" and it is not read by Jaws. Similarly, labels for lists are not read in other Eclipse dialogs I've checked. Moreover, I tried to use getAccessible().addRelation(ACC.RELATION_DESCRIBED_BY) and ACC.RELATION_DESCRIPTION_FOR and still Jaws won't read the extra text for the list. So, providing access to dialog widgets won't help you and neither adding direct label to the list. The best bet here is to formulate status text so that it makes it clear what those two controls (filter and list) are for. === If you have some deeper plans for using Accessible interface on those widgets, you can override ElementListSelectionDialog#createDialogArea() and change the code to be something like: protected Control createDialogArea(Composite parent) { ... Label messageWidget = createMessageArea(contents); Text filterWidget = createFilterText(contents); FilteredList listWidget = createFilteredList(contents); listWidget.getAccessible().doSomething(...) ... } The #createDialogArea() in this class is very simple and functions used there return exactly the widgets you were looking for.
Oleg, there is a fundamental problem with using ElementListSelectionDialog.setMessage() as the label for the text field. Using your screenshot as an example, you have set the message to "Select color:". This is a very reasonable message for this dialog, and one that I would expect to see. The problem is that if I'm using a screen reader and I tab into the text field, I will be told I'm in the "Select color:" text field. How am I supposed to select a color from a text field? Because you and I can understand the implicit nature of the text field is to filter the options in the list, this is fine for us. It's not ok for those using screen readers, however. In regards to JAWS not reading the name of lists, this is a bug in JAWS. If you use a tool like Inspect to view the properties of a list, you will see that it is still necessary to properly associate a label with lists. I am unable to easily override ElementListSelectionDialog.createDialogArea() because ElementListSelectionDialog.fElements is a private field. However, even if this were not the case, this would be a hacky workaround at best. It would be better to have reusable, built-in accessibility support in this dialog instead.
I've looked into different ways this is done in other Eclipse dialogs. To me, they all have the same fundamental problem that you describe: if a person is not familiar with the UI paradigm of a filtered list / tree, it is probably hard to understand what's going on. The are some ways to mitigate this, most notably: 1) including better description, like "Enter type name prefix or pattern (*, ?, or camel case):" 2) adding initial text in the filter along the lines of "type filter text". For practical purposes, especially considering that you use previous release, not the current release, have you considered using FilteredItemsSelectionDialog instead of ElementListSelectionDialog? The FilteredItemsSelectionDialog has a number of nice improvements, including the accessibility bits mentioned in (1) and (2). (In reply to comment #3) > In regards to JAWS not reading the name of lists, this is a bug in JAWS. If you > use a tool like Inspect to view the properties of a list, you will see that it > is still necessary to properly associate a label with lists. Hmm... not really. In Inspect32, especially if you turn the highlight rectangle on, note that it is the element of the list that gets selected when you tab into the list or mouse click in it. The element's information is read, not the parent's (parent being the list). In theory it is possible to override accessible text for the list element to include label of its container, but I don't think we do it in any SDK dialog. The reason for this behavior is probably that when you get into the list, there is already a lot of information to be read - the text for the list item, the fact that it is inside a list, position in the list and so on. (It is possible that there is an option to change this and/or that other screen readers behave differently. I just wanted to mention that this is probably the intentional behavior and not a bug.) === To summarize, I'd recommend seeing if the more modern FilteredItemsSelectionDialog can be used instead of ElementListSelectionDialog.
