Community
Participate
Working Groups
org.eclipse.ui.dialogs.FilteredList is used in AbstractElementListSelectionDialog class. When mouse is hovering over the list, there is no accessible name available to screenreader, if the mouse is over empty space or if the list is empty (if mouse hovers over an item in the list then the name is available).
As this is abstract the name should be set up by the subclass. However we should see if there is some API we can do to make this easier.
Is there any ETA for the solution?
We are past the window for adding anything but stop-ships for 3.2, so there is no milestone assigned to this bug right now. We'll be doing bug triage for 3.3 and assigning milestones once 3.2 ships. If this is a serious bug for your project, it could also be considered for 3.2.x releases.
We have very strenuous requirements for accessibility, so it is rather serious problem (and this defect was submitted in 2004 ;-)
I'll tag this with a 3.3 milestone so it won't get lost. This means it'll get a look early in the 3.3 cycle and I'm assuming you would lobby for it to go in a 3.2.x maintenance update.
tagging 3.2.1
Karice - I am no accessibility expert, so can you please read my remarks and recommendation and comment? Presumably the behavior whereby the item in the list being hovered over is read by the screen reader is the platform-provided behavior. You are requesting that we augment the behavior to provide an accessibility name when - the mouse is hovering over blank space - the list is empty. Providing a message when the mouse is hovering over blank space is a bit problematic, in that the client would have to be able to hit-test the filtered list, which means they would know that the list was implemented as a table, etc. The filtered list could do this internally, but that would subvert any accessible listeners provided by external clients (what happens when multiple clients add accessible listeners...does the last one to set the name win?). I also don't like this because it is inconsistent with the accessibility behavior of other lists. This seems like a fairly low-level detail that shouldn't be fixed by each client. Eclipse would have some lists that had accessible messages when the mouse was hovering over white space, and others where it does not. I think it's best to have a consistent story and trust that users have learned the platform behavior? Setting the accessibility name when the list is empty is a bit simpler, as there is already API in FilteredList to answer whether the list is empty, and there is already API in AbstractElementListSelectionDialog to set an "empty list message" for the user. We could add an accessible listener that sets the empty list message as the accessible name when the list is empty. Doing this would require an API addition in FilteredList so that the accessible object of the underlying table could be accessed. For this reason, this can't be done in 3.2.1, but could be done in 3.3. Attaching a patch for the proposed solution. Alex, could you try this out and see if it is sufficient? Note that you would have to use #setEmptyListMessage(String) in your dialog subclass in order for this to work. Another alternative is to define a new API (setEmptyListAccessibleName) if it doesn't make sense to use the empty list message as the accessible name.
Created attachment 44844 [details] org.eclipse.ui.dialogs using existing API to provide an accessible name when the filtered list is empty
Susan, I am not sure I understand the proposed idea? I also do not know how to grab files from CVS.
The proposed idea is that we would add an accessible name for the list when it was empty, but we would not attempt to provide an accessible name when the list had items but the user was hovering over blank space. The accessible name would be settable by the code creating the dialog using the existing API setEmptyListMessage(String). This means that the same text shown in the message area when the list is empty would also be used as the accessible name when the user hovered over the empty list. This would require the code creating the dialog to set up an empty list message on the dialog. Other alternatives might be: - the code creating the dialog sets up a name to be used for an empty list (rather than reuse the message for empty lists) - we use a generic accessible name (such as "Empty List") so that the client code doesn't have to do anything.
If I had access to the List (or Table) control, I could use its 'setAccessible' methods to provide accessible name. It would have been the easiest solution. Is there something that I don't understand about FilteredList?
Alex that would make the most sense to me as well. Lists get thier context from thier assoicated label - this is not possible with a FilteredList. a getListControl() API would be suffecient I think.
Alex, you mentioned in the original defect report that this is only a problem when the list is empty. I think this is why Susan proposed the solution she did - that the FilteredList class set the accessible listener to some sort of empty list name whenever the list is empty. Susan, I still have yet to check what happens with JAWS for empty tables that are not FilteredLists before I can comment on your recommendation.
What I reported originally was "When mouse is hovering over the list, there is no accessible name available to screenreader, if the mouse is over empty space or if the list is empty". Tod, There is no getListControl() method on the FilteredList class, and the Table control is private.
Yes, I assumed from the original problem description that : - the problem was with empty lists - the problem was with hovering over empty space in the list - the behavior whereby the hovered list item is used is desirable. I also assumed that the client code would not want to deal with installing the accessibility listener and ensuring that only the empty list case was handled. But from comment #11 it sounds as if you are willing to install the listener yourself. However, I would rather see FilteredList add the message #getAccessible() rather than #getListControl(). The list is currently implemented as a table, and while I doubt we would rewrite it, I don't like the idea of exposing the implementation. If we instead provide #getAccessible() in FilteredList, your dialog can retrieve the Accessible and install the listener without knowing exactly what kind of control it is.
>Susan, I still have yet to check what happens with JAWS for empty tables that >are not FilteredLists before I can comment on your recommendation. Karice, that info would help. If there is some default behavior (like the closest label name, etc.) that we are missing because of the nested composite introduced by FilteredList, then it's possible we could fix this inside filtered list without Alex having to do anything.
We are installing our own listeners left and right anyway. If FilteredList had getAccessible() it would be fine too. I only though about having getControl() method (which I could then cast to Table or List, or nothing) as a way of having more flexibility in customizing FiltredList class.
Alex that was my point. And yes I would actually prefer a getList() as developers may generally want to play with the List (setting selection etc).
Tod - Currently FilteredList defines API so clients can play with the list without knowing how it's implemented (setSelection, setElements, addSelectionListener, etc.). Adding #getAccessible() seems more in line with this philosophy. If we'd rather just punt and expose the table control, shouldn't we call it #getTable() rather than #getList()?
Sorry - didn't check. Thought it was a list. Regardless your first idea of adding getAccessible sounds better for the sake of consistency.
Added the #getAccessibility API which returns the Accessible for the table. This is technically an API change (override of an API method), so I'm releasing to 3.3 stream. Fixed >20060620. Alex, if you have an urgent need for this to be backported to 3.2.1, let me know. We may be able to make a case that this could go in, since FilteredList inherited this method in 3.2 with a different implementation, and the impact is only to accessibility clients.
Thank you, Susan. Any noncompliance with accessibility checklist is an issue. If there is a way to have this fix in 3.2.x, we'd prefer that.
cc'ing McQ for direction on "API change." McQ, you can ignore most of this history. The remaining issue is that the fix involved reimplementing an API method (Control.getAccessible()) in FilteredList to return the Accessible for the table, not the parent composite. Since this is an override of an API method, I consider it an API change. Can this kind of override go into a maintenance release?
We do not make API changes in mainenance releases unless there is a critical need to do so. However, since it is simply overriding an existing method, the only people that would be broken are those who depend on the current behavior. If it is conceivable that such exist, we should hold off until R3.3.
It is important that we have it 3.2.1. Accessibility compliance list is a product of IBM, just as FilteredList class is. Right now the UI that uses this class deviates from compliance.
Alex, are you just using FilteredList or the AbstractElementListSelectionDialog class? If you are using the latter, then you will still encounter the same problem, even with this fix, because the list cannot take focus when it is empty as it is set to be disabled in the case when the list is empty.
I am using it in my own class that extends AbstractElementListSelectionDialog (see original description). It does not have to take focus, because the issue is with mouse hovering over it.
It sounds like there are deeper issues here, which need to be resolved. Should the bug be re-opened? Separate from that, you need to understand that, whether it's accessibility compliance, FilteredList itself, or even the workbench as whole, the fix for *every* bug is evaluated based on: - the scope of the change and potential impact on other aspects of the system - the number of users who are impacted by the problem - where we are in the development cycle, and - whether it can reasonably be made without impacting existing consumers. Not all bugs can be fixed in maintenance releases. Have you verified that there is no way to read the compliance spec such that this is not a deviation? At the very least, this does not seem like it is severity "major" given that, when content is present, it is correctly read. What do other applications do in this case?
I am familiar with IBM's accessibility guidelines and I am not aware of one that requires a screen reader to identify a widget and its contents by hovering over it - it has to have focus. Can you provide a pointer to the requirement for this function?
I guess my first question is how is getAccessibility() for FilteredList implemented differently in 3.2 vs. the 3.3 fix? If my understanding is correct, if 3.2 FilteredList implementors do not change this in 3.2.1, the screen reader behavior should be the same (albeit still reading a NULL accessible name), so the risk of impacting existing users should be minimal. We're getting a very strong push to resolve ALL of our accessibility violations, and this defect is one of the last few remaining. I assume many of you are using the same checklist as I am, so if anyone would like to email me privately with a more liberal interpretation of the ruleset (thus making this much less lower priority for us), I would invite that. :)
I guess I want to ensure that we are identifying the right problem and fixing it properly. There is a document from the accessibility center that states how to use JAWS to test for accessibility and in the section about using JAWS cursors it states: "Remember, since a blind user cannot use the mouse, the keyboard must always be used when testing for accessibility." So if the only issue with the FilteredList is regarding lack of screen reading on hover then this bug is invalid. If a list is disabled then a screen reader or inspect32 will skip over it when tabbing through the widgets as it is not relevant info to the user. I think the patch should be rolled out.
Backed out of the proposed fix, >20060621. No need to add API until we understand the issue better. It sounds as if we are not sure there is a violation here. Awaiting further info from Alex.
Created attachment 45009 [details] No accessible name in filtered list
http://w3-03.ibm.com/able/devtest/AC_InspectObjects_HowTo_SW.html#testinstr states: In addition to the information contained in the table below, the following must also be confirmed for each object: The "name" property must not be NULL, The "role" property must be defined and must match the type of the object, The "state" property must be defined and must match the state of the object. See the attachement: the NAME is NULL.
So it would seem that the issue is unrelated to hovering or empty lists, correct? The issue is that there is no accessible name assigned to the list. In this case I believe that the proposed fix would work, that is you could assign a name to the table inside the filtered list by installing an accessibility listener on it (via a new method #getAccessible). But I am just guessing...Karice, does that sound right?
Applied the following hack which makes everything work: Control[] ctrls = m_filteredList.getChildren(); for( int i = 0; i < ctrls.length; ++i ) { if( ctrls[i] instanceof Table ){ ctrls[i].getAccessible().addAccessibleListener( a ); break; } }
okay, then I think the right thing to do is (re)release the fix for 3.3 so that you don't have to hack through the children of the FilteredList. But this hack can get you by in the meantime, so I don't see backporting to 3.2.1. Okay?
It seems there was a misinterpretation of the original problem description on my behalf. In light of that, I concur with Susan's suggestion in comment #37.
Fixed >20060621. Released to HEAD (3.3 stream) Alex, this should be available in tonight's 3.3 nightly build, the next 3.3 integration build, etc. Can you please download the next 3.3 build that is convenient for you and test without your workaround to ensure we have this right?
Comment on attachment 44844 [details] org.eclipse.ui.dialogs marked obsolete (the actual fix did not make any changes to AbstractElementListSelectionDialog)
Susan and Karice I hate to bring this up again but what do you think about having an optional label rather than using getAccessible? With a label we will: 1) solve the accessibility problem by following the z order rules (i.e. the label will come before the list and screen readers will catch it for free) 2) Allow for a decent mnemonic to get back to the list 3) give some more context to regular sighted users If we want to go a different route we should remove the new API before M1
If the label is optional, wouldn't we need both the label and the getAccessible() method (for the case where we don't want the list to have a label) in order to be compliant?
No. If you don't need the label you have enough context from the dialog (like we do for preferences). If you think the user needs the extra context then you can use the label.
I think Karice's question is valid...if you don't need the context (and the label), then you are back to being non-accessible. I understand the benefits of your suggestion, but I don't see that it prevents us also having the getAccessible API. And have we seen bug reports or comments that indicate the lack of a label is a problem?
No - it was just a thought that I wanted to make before the API was solidifed for 3.3.
verified in I20060807-2000, Win XP through source inspection. Alex, have you had a chance to verify this fix without the workaround discussed in comment #36?
