Community
Participate
Working Groups
On Eclipse 3.0 the infopops are not read by the JAWS screen reader. It states that you have hit f1 (which brings up the infopop) but the text and the links are never read even though you can see that the infopop has the focus and the focus moves through the links as you tab round. This means that Eclipse is not section 508 compliant This seems similar to bug 25320 which was fixed in an earlier release.
Car, this works for me with WindowEyes (using Eclipse M7), so it seems that Help is doing what it should. Can you try this on JAWS?
Build 200403230800 infopops work ok in Window-Eyes, but not as well in JAWS. Both screen readers will read the "focus link", which is a "read-only edit". (Although JAWS seems to think you can type into the text because they didn't notice that it is read-only). For Window-Eyes to read the introductory text (label) at the top of the dialog, I needed to turn on Global -> Verbosity -> Activated...-> Entire Window if Dialog. I should be able to type INS+B in JAWS and have this label spoken, but it doesn't work. Note that the MSAA inspector is able to read everything, so it's not that we aren't providing the info, it's just that JAWS isn't using it. They tend to only read focusable stuff. Frank- would you be able to provide any insight into what JAWS is looking for when the user types INS+B? Are they looking for direct children of a dialog? (i.e. because most stuff in eclipse typically has several layers of control before you get to the meat...) If so, can we convince them to look deeper?
Thank-you for looking into this - however I am not even hearing as much as you!!! When I hit f1 JAWS says "f1" and the infopop appears (but it says nothing) as I tab round JAWS says "tab" but does not read out the link it will eventually tab back to the text at the top, but again all it says is "tab" rather than reading out the text!!!! I am using the beginners level on a typical install of JAWS 5.00.621 and this happens on both Eclipse 2.1 build 200306271545 and Eclipse 3.0 build 200401301130. What level of JAWS are you using and do you have any special options set??? Kim
I have just taken JAWS 5.0.844 from the Freedom Scientific website (my version 5.00.621 was straight out of the box) and it reads infopops as you describe. However I have some quite long infopops and JAWS seems to read part of the text and then stops. It appears to read about 40 words and then gives up - is there a limit to the text you can put in infopops??? All the text is displayed , just not read.
The JAWS screen reader does not read the static text in infopops in V3 if there are links within the infopop (it did in V2) - it just tabs between the links. If there are no links then only about the first 40 words of the infopop are read. This means that Eclipse and products based on it are not section 508 compliant. It is becoming increasingly important that this problem is fixed because my product need to be compliant - what is the outlook for it to be fixed????
It appears this is working fine with two screen readers, just not with JAWS. Carolyn, do you have any intention to do anything special for JAWS? If not, please declare this one resolved and lets have Frank get after JAWS to fix this.
Carolyn sent me a test case that illustrates this problem. One of the little dialogs has some static text (window class is static text) at the top that is read by JAWS as the dialog opens along with the edit field that has focus. The other little dialog also has some static text (window class is "SWT_Window0") at the top. JAWS only reads the edit field, but not the static text. A couple of things here: 1. I am not sure what causes JAWS to read the static text at all as it never has focus. I will bring that up with the Freedom Scientific folks next week when I visit there. It may be that JAWS mistakes these little dialogs as message boxes that need to have the message read. 2. I disagree with Steven Wasleski's comment at the bottom. First, I only see one other reference to a screen reader, Window Eyes. Second, while I am not a Window Eyes expert, it seems that Carolyn got WinEyes to read it by turning on a function that would cause every dialog to be read in its entirety. That would never be a setting that a blind user would turn on as their default because there would be so much chatter as to drive the user nuts. The JAWS user can read the dialog by routing JAWS cursor to PC cursor, moving to the top and then telling JAWS to read to the bottom. I don't think either one of these approaches constitutes accessibility. 3. I see the Insert+B JAWS key mentioned a lot. I don't think that should be a measure of whether JAWS can read a window or not. My understanding is that it is supposed to read all fields in a dialog "at the same hierarchal level." My experience is that this does not usually read everything in a dialog. The bottom line here is that, if I look at dialogs in general, I would not expect JAWS to read static text in a dialog unless it is actually associated with some field that can get focus. I would venture to say that is usually the case throughout other apps. How would we expect a screen reader to determine which static text needs to be spoken with wchich fields? I will report again after I run this by Freedom Scientific next week.
Yes, it was only one other reader. I had mistaken the MSAA inspector reference in comment 2 as a second reader.
I honestly think that one of the heuristics that JAWS (and other screen readers) are using is to always read the static text at the top of a dialog. JAWS only does this if the window class happens to be "Static". Window-Eyes reads the text (when you tell it to read all) even though the text is drawn in some other window class, because MSAA says that it is read-only text. Personally, I think screen readers shouldn't care what the window class is. If MSAA says it's read-only text, and if it is at the top of a dialog, just read it.
As I have probably mentioned before Eclipse 3.0 has gone backward in respect of infopops and the screen reader . In 2.1 JAWS reads the static text of the infopops but fails to state that there are links available. With Eclipse 3.0 the static text is not read although it does tell me about the first link available. If this bug can not be fixed such that the static text is read and the links are mentioned then could Eclipse 3.0 revert back to how 2.1 worked. The static text would then be read and I could put a sentence in the static text of my infopops to tell the user to use the links for more information. At least that way my product would be 508 compliant in this area. Thanks Kim
Carolyn, is there more work for this that will be targeted for 3.0?
No. This is really a duplicate of bug 60884 now - thanks for pointing it out. Kim, JAWS is not the final answer when it comes to Section 508 compliancy. There are other screen readers out there that do read infopops. Also, the MSAA Inspector reads it, which effectively says "It's not our fault that JAWS can't read it". It does NOT mean that your infopop, or your product, are not 508 compliant. We are trying to work with the various screen reader developers to ensure that eclipse, and eclipse plug-ins, can be read by all of them. *** This bug has been marked as a duplicate of 60884 ***
