Community
Participate
Working Groups
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648; .NET CLR 3.5.21022; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729) Build Identifier: I20091020-0931 The caret doesn't move in the majority of the readonly text boxes and screen reader doesn't read its contents. Reproducible: Always Steps to Reproduce: To see accessible text box: 1. Go to Window -> Preferences -> General -> Appearance -> Label Decorations. 2. Select an item, press tab until the item description text box is focused and move the caret within it. You'll see that the caret moves and this text box is accessible. Now, do the following to see inaccessible text boxes: 1. Go to Window -> Preferences -> Java -> Code Style -> Formatter. 2. Go to any preview text box in this category and subcategories and move the caret. You'll see that the caret doesn't move and all of these text boxes are completely inaccessible. Note that there are many more inaccessible text boxes in eclipse preferences (for example, in java -> Editor -> Save actions, checking "perform selected actions on save", checking "Additional Actions" and tabbing to the text box. Moreover, if you go to Help -> About Eclipse SDK, you'll see that the readonly text box that contains the eclipse version is inaccessible (this particular text box is inaccessible in eclipse 3.4 too). Probably, there are many more. Fix for this bug its important for blind people.
This doesn't seem to be working properly for me on Linux/gtk+ either. SWT?
This bug has not been fixed yet. It's crucial to blind users to have this feature resolved. Can developers look for a solution to this bug? Thanks for the attention given.
Felipe, in the steps in comment 0, the "working" example is a Text, and the "not working" example is a StyledText. I am not sure what JDT is doing to turn off the caret (are they setting it to null or something?). The StyledText was not created with READ_ONLY style, according to SWT Spy. Can you look into this, please? I only verified on Windows, but comment 1 says it's the same problem on GTK. I tried with JAWS, and when you tab to the StyledText, JAWS says nothing. If you *select* stuff using the keyboard, then JAWS does speak the selected text. i.e. you can type shift + arrow keys. But it should work with just arrow keys. I am reducing the severity to normal because there is a work-around of selecting text in a read-only StyledText to get a screen reader to speak the contents. For example, you can type Ctrl+A to select all.
see org.eclipse.jdt.internal.ui.preferences.formatter.JavaPreview The relevant code is (I believe): fSourceViewer= new JavaSourceViewer(parent, null, null, false, SWT.V_SCROLL | SWT.H_SCROLL | SWT.BORDER, fPreferenceStore); fSourceViewer.setEditable(false); Cursor arrowCursor= fSourceViewer.getTextWidget().getDisplay().getSystemCursor(SWT.CURSOR_ARROW); fSourceViewer.getTextWidget().setCursor(arrowCursor); fSourceViewer.getTextWidget().setCaret(null); I don't have JAWS to test. Try test with this snippet: public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); StyledText text = new StyledText (shell, SWT.MULTI); text.setEditable(false); text.setCaret(null); text.setText("some text for testing"); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); }
(In reply to comment #1) > This doesn't seem to be working properly for me on Linux/gtk+ either. SWT? And the Orca screen reader (gnome/gtk/... stuff) doesn't report the information as expected.
The snippet in comment 4 does not reproduce the problem exactly. But it gives a flavor of the problem, because the user cannot navigate using arrow keys (unless SHIFT is also held down to select the text). For some reason, JAWS is speaking the whole text when the StyledText in the snippet gets focus, but it does not speak anything when any of the "inaccessible StyledText" examples in comment 0 get focus.
I've downloaded the eclipse 3.5 milestones to see in what build the problem started to happen. All the text boxes I reported as being inaccessible were accessible in eclipse 3.5m1 (build I20080807-1402) and started to be inaccessible in eclipse 3.5m2 (build I20080918-0100). Does it help to discover the cause of the problem?
Thank-you, Sergio. The problem is that the text boxes that are not navigable with the caret have actually had their caret explicitly disabled with the following line of code: text.setCaret(null); I am not sure why, but my best guess is that the developers felt that non-editable text areas should not show a caret. They probably did not realize that by turning off the caret, they made the text area pretty inaccessible to screen reader users. (ctrl+A still allows the whole text to be spoken at once, but I agree that this is not a solution and that navigation is the only way for a screen reader user to truly read the text). Here are the places in the UI where setCaret(null) is called: org.eclipse.ui.internal.about.AboutFeaturesPage.createInfoArea(Composite) org.eclipse.ui.internal.dialogs.AboutDialog.createDialogArea(Composite) org.eclipse.ui.texteditor.templates.TemplatePreferencePage.doCreateViewer(Composite) I am cc'ing some folks who may know the reason(s) behind setting the caret to null (you are correct that it happened sometime after 3.5M1). Perhaps we can have a discussion about either turning the caret back on, or some other solution.
(In reply to comment #8) > org.eclipse.ui.internal.dialogs.AboutDialog.createDialogArea(Composite) I looked at this one case and could find the call "setCaret(null)" all the way back to the beginning of time (well, in our case it means September 2002 because that's how far we can see the history in CVS).
(In reply to comment #8) > (ctrl+A still allows the whole text to be spoken at once, > but I agree that this is not a solution and that navigation is the only way for > a screen reader user to truly read the text). I would say more. In these text boxes, which main purpose is to show text formatting (blank lines, indentation, etc), it's crutial (to me in particular, and I think to blind users in general) to allow us to see the text formatting without copying the text to another editor or something like this. As it is, I hear all the text, but it's difficult to me to understand the most important thing: formatting. And people who are blind and are now starting to program in eclipse, how do they guess that they have to select all the text and copy it? I wouldn't be able to guess if I haven't known the text boxes before. Thank you for your time.
(In reply to comment #8) > I am cc'ing some folks who may know the reason(s) behind setting the caret to > null (you are correct that it happened sometime after 3.5M1). Perhaps we can > have a discussion about either turning the caret back on, or some other > solution. I would be open to turning the caret back on. Susan, any thoughts?
(In reply to comment #11) > (In reply to comment #8) > > I am cc'ing some folks who may know the reason(s) behind setting the caret to > > null (you are correct that it happened sometime after 3.5M1). Perhaps we can > > have a discussion about either turning the caret back on, or some other > > solution. > > I would be open to turning the caret back on. Susan, any thoughts? I don't know the history here, but I'm open to turning the caret on assuming we can check tab traversal on all platforms and make sure there isn't a problem that this was trying to get around. Also, I think it would be worth understanding why a null caret was OK in 3.5M1 but not after...
(In reply to comment #12) > Also, I think it would be worth understanding why a null caret was OK in 3.5M1 > but not after... In comment 9, Boris only looked at the one case that had a null caret before 3.5M1: org.eclipse.ui.internal.dialogs.AboutDialog.createDialogArea(Composite) The other 2 places only began setting the caret to null after 3.5M1: org.eclipse.ui.internal.about.AboutFeaturesPage.createInfoArea(Composite) org.eclipse.ui.texteditor.templates.TemplatePreferencePage.doCreateViewer(Composite) In comment 7, Sergio said "all" the text boxes worked before 3.5M1 and stopped working after, but I suspect that he hadn't tried Boris' AboutDialog case... that one was probably a problem all along because it always had a null caret.
We set the caret to 'null' so that the users don't think they can edit in there. This is a workaround because neither the disabled nor the read-only look for StyledText look right (see bug 4745, especially comment 7). The screen reader should simply also work when the caret is set to 'null', e.g. read all the text.
(In reply to comment #14) > We set the caret to 'null' so that the users don't think they can edit in > there. This is a workaround because neither the disabled nor the read-only look > for StyledText look right (see bug 4745, especially comment 7). > The screen reader should simply also work when the caret is set to 'null', e.g. > read all the text. See comment 10 of this bug. In my modest view, as it is, you create another problem: not only this type of text box doesn't allow a screen reader to read whether it's readonly or not (bug 221937 (I don't know why, but in recent versions of JAWS it is announced)), but also it's impossible to move the caret. Given this situation, I don't worry about the other bug, because I'm used to this problems and, even to people less knowledgeable (both blind and sighted), I think it's obvious to distinguish whether a text box is editable or not. However, it's not so easy to magically guess that the text box has text if the caret doesn't move. How can I select a thing which I don't know it's there? In eclipse preferences' context, what is easier: look for the screen and see that the text is there, type and verify that the text box is readonly, or tab to the text box, don't hear anything and guess that it's necessary to type ctrl+a and probably ctrl+c? Before this change, blind people were in equal conditions to sighted people, because both didn't have the information of whether they are editable or not. Now, not only no one knows this, but also it makes blind tasks harder. In sort, I think you shouldn't compromise accessibility due to another bug (bug 4745)which isn't fixed yet.
Sérgio, I can follow your arguments. I will change all my code for RC1 (see bug 311162). Keeping this bug for the problem that the screen reader doesn't work at all when the caret is 'null'.
Can you check for me whether setting back the caret but leaving the ARROW cursor to indicate the read-only state works? I checked that the tab traversal is OK.
(In reply to comment #17) > Can you check for me whether setting back the caret but leaving the ARROW > cursor to indicate the read-only state works? I checked that the tab traversal > is OK. What were the build that you change it? Is it I20100429-1549? If it is, the caret doesn't move yet. I've red org.eclipse.ui.texteditor.templates.TemplatePreferencePage.doCreateViewer(Composite) method, but this line is there: viewer.getTextWidget().setCaret(null); Sorry for this, but I'm a beginner in these things of reading eclipse source code.
No worries, Sergio - I'll test the change for Dani. I am quite sure that the arrow cursor will not affect the speaking and navigating of the text in any way, but I'll try it out to make sure. I'll report back here in a couple of hours - I have something else I have to finish first.
Hi. Sorry to take so long to get back to you. The following snippet works fine with JAWS - I can move the caret to read lines, characters, and words, and there is an arrow mouse cursor. (note that the setCaret(null) is commented out in the snippet). import org.eclipse.swt.*; import org.eclipse.swt.custom.*; import org.eclipse.swt.graphics.*; import org.eclipse.swt.layout.*; import org.eclipse.swt.widgets.*; public class StyledTextNotEditable { public static void main(String[] args) { Display display = new Display(); final Shell shell = new Shell(display); shell.setLayout(new FillLayout()); StyledText text = new StyledText (shell, SWT.MULTI | SWT.BORDER); text.setText("some text for testing\nmultiple lines\nwith caret navigation."); text.setEditable(false); Cursor arrowCursor= display.getSystemCursor(SWT.CURSOR_ARROW); text.setCursor(arrowCursor); // text.setCaret(null); shell.pack(); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) display.sleep(); } display.dispose(); } } Boris & Susan, do you think this solution is acceptable for now? It may be possible to come up with a better solution in future, however the better solution that I am thinking about is not yet implemented in JAWS (soon, but not yet), so I cannot test it yet, and I therefore can't recommend it (yet). If we simply put back the caret for now, then these read-only text areas will be navigable for eclipse 3.6, and I believe we will be able to add some new support to make everybody happy in Eclipse 3.6.1.
Thanks Carolyn for checking. I'll go ahead with my fix then. Sérgio, the fix will be in the next RC1 build.
Thanks for fixing this. If you fix the three places where the caret is null, it will be fantastic. I don't remember a release of eclipse with much great accessibility as the one that will come next. Thank you for the great development and to provide a better development life for the others.
(In reply to comment #20) > Boris & Susan, do you think this solution is acceptable for now? Yes. Susan, could you make the changes for the next I build given that I am traveling?
(In reply to comment #22) > Thanks for fixing this. If you fix the three places where the caret is null, it > will be fantastic. I don't remember a release of eclipse with much great > accessibility as the one that will come next. Thank you for the great > development and to provide a better development life for the others. Thank you very much for the kind words, Sergio. If you find any other places where Eclipse has important accessibility issues, please enter new bugs similar to this one. Feel free to add Carolyn or Oleg (obesedin@ca.ibm.com) to the cc list if you feel that no progress is made on accessibility bugs, even if you filed it against another Eclipse project or component.
Let me take the bug since I also have to fix the other places. Can someone please review and +1 the fix.
Created attachment 166728 [details] Fix
Filed bug 311308 for the accessibility issue in SWT.
Created attachment 166729 [details] Fix
+1. Thanks, Dani - the patch looks good for AboutFeaturesPage and AboutDialog. I see that Bug 311162 covers TemplatePreferencePage. Please do not mark this bug fixed until that code is released, too. Thanks for opening bug 311308. I will take it and mark it for 3.6.1 to make sure that I look at this again in that time frame.
SSQ, after Dani's fixes are in, can you please test this with Orca? Thanks.
Committed patch to HEAD and marked it with review+ according to comment 29. Keeping bug open until dependent bug 311162 is committed (awaits review).
Fixed dependent bug.
Thanks, Dani!
Testing with orca and eclipse build I20100504 I found the following problem when scrolling in the eclipse about box with the arrow keys. I can move the cursor until i found the text (c) Copyright Eclipse contributors and others 2000, 2010. All rights reserved. After that the cursor is locked and I can not move it neither up nor down.
(In reply to comment #34) > Testing with orca and eclipse build I20100504 I found the following problem > when scrolling in the eclipse about box with the arrow keys. > I can move the cursor until i found the text > (c) Copyright Eclipse contributors and others 2000, 2010. All rights reserved. > After that the cursor is locked and I can not move it neither up nor down. Did you test with build I20100504-0800? If yes, this change wasn't propagated to this build. Test with N20100503-2000 and you'll see that it works. A fast way to see that change is: 1. Go to help -> about eclipse sdk 2. press alt+shift+f1 3. Click on the class that appears (AboutDialog). 4. Go out of about dialog and ctrl+f7 to go to the editor. 5. Verify that setCaret(null) is commented.
>Did you test with build I20100504-0800? If yes, this change wasn't propagated >to this build. Test with N20100503-2000 and you'll see that it works. Maybe Platform UI missed the build input?
(In reply to comment #36) > >Did you test with build I20100504-0800? If yes, this change wasn't propagated > >to this build. Test with N20100503-2000 and you'll see that it works. > Maybe Platform UI missed the build input? This was brought up yesterday on our conference call and yes we forgot to submit to the I build. Our apologies.
Testing with orca and build N20100505 seems ok. When scrolling in the about box with the arrows, the text "(c) Copyright Eclipse contributors and others 2000, 2010. All" seems to be duplicated. However if I copy the entire content from the about box and paste to an editor, the text is ok.
(In reply to comment #38) > Testing with orca and build N20100505 seems ok. > When scrolling in the about box with the arrows, the text "(c) Copyright > Eclipse contributors and others 2000, 2010. All" seems to be duplicated. > However if I copy the entire content from the about box and paste to an > editor, the text is ok. Coud it be an orca ug, or a problem with SWT/GTK? I tested with JAWS and NVDA and it's working well. I neither understand SWT-spy to inspect this, nor I have the environment at the moment to test.
> Coud it be an orca ug, or a problem with SWT/GTK? I tested with JAWS and NVDA > and it's working well. Sorry, with NVDA it's not working, but it is related with the way swt retrieves information accessibility and the way NVDA is implemented.
(In reply to comment #38) > When scrolling in the about box with the arrows, the text "(c) Copyright > Eclipse contributors and others 2000, 2010. All" seems to be duplicated. > However if I copy the entire content from the about box and paste to an > editor, the text is ok. Jose, could you please file a new bug for this issue? Thanks! Also, Sergio, if something is working with JAWS but not NVDA it's worth entering a bug about that, too.
Actually, the NVDA problem was just fixed. See bug 312097.
(In reply to comment #42) > Actually, the NVDA problem was just fixed. See bug 312097. I don't know how you can do this. Thanks!!
Verified in I20100520-1744.
