Community
Participate
Working Groups
The problem in a nutshell (from a blind user in Brazil): I've some dificulties when debugging a class. I don't know for example if a line contains a breakpoint unless I switch to the breakpoint view.
From Darin W: I don't know how a blind user would determine that there is a breakpoint in the editor's vertical ruler. Perhaps Kai can tell us, as it should be the same for all "annotations" in the ruler - i.e. instruction pointer, search results, etc.
From Frank D: When I open the Breakpoints view, I can read where the breakpoints are, but that would assume that the user remembers line numbers. I guess it would be better to somehow know when a line has a breakpoint while I am in the editor. You know, I am reminded of when you set Microsoft Word to show all the formatting stuff. Then the blind user can hear all the formatting marks along with the text. Do you guys think something similar might be possible for all of these things that normally show up in the right and left scroll bar like the error indications?
Another thought that Frank noticed: JAWS (and maybe other screen readers) have the capability to know the highlight color of the line. Note that when someone is actually debugging, the editor highlights the current line - something like this could be used to show breakpoints. Of course, it would have to be configurable, because if we highlight all annotated lines in a different color, then sighted users would complain <g>.
A quick workaround for the time being: you can open the ruler context menu (Ctrl+F10 from the editor) - if the second menu entry (Enable / Disable Breakpoint) is enabled, you know that there is a breakpoint.
*** Bug 236440 has been marked as a duplicate of this bug. ***
Hi, Is there an outlook on which Eclipse 3.5 milestone this would be addressed? This is affecting the accessibility of consuming products.
What coincidence. We were just looking at this today. In order to fix this we need more information/help on how a blind person would interact with the annotations. Bug 236440 mentions hovering but I don't see how a blind person can hit the right spot on the ruler to make the hover appear. What we need are real-life scenarios how a blind person would want to interact with the editor and its annotations. Without them we would most like build something which is not too useful. Tom, maybe you have some insights here.
Hi, Dani. Thanks for looking at this. You are correct that hovering with the mouse is not an option. And the line color idea that I mentioned in comment 3 doesn't make sense, so please ignore that. My current thinking is that the best thing is to have a keystroke that brings up the annotations hover for the current line. Currently, the screen reader user can type, for example, Ctrl+Space followed by TAB to hear Content Assist (using arrow keys to scroll through the list), or Ctrl+1 followed by TAB (and arrows) to hear Quick Fix suggestions. (Aside: It's too bad they have to type the TAB, but the screen reader doesn't know about the focus change unless they do... maybe we can improve that? Dani, can you try adding something like this, right after the content assist or quick fix tooltip shell is made visible? tooltipShell.getAccessible().setFocus(ACC.CHILDID_SELF); Do you have JAWS or another screen reader there so you can try it and see what I mean? If not, please tell me what class to edit and I can try it for you). Anyhow, my thinking is that a very specific keystroke can be defined for "pop up the annotations tooltip for the line containing the I-beam cursor (if any)". Again, it would be nice if the user does not have to type an extra TAB to give the shell focus. (because if there are no annotations for the line, then they would be typing a TAB into their editor... which they would then have to delete). When I type Ctrl+Shift+L to get the list of keystrokes available in Eclipse, I see one that might be useful: Context Information = Ctrl+Shift+Space. I can't figure out what this currently does - do you know? It might be possible to use this to open the current line's annotations tooltip shell? Tod, do you have any insight on this?
>Dani, >can you try adding something like this, right after the content assist or quick >fix tooltip shell is made visible? Do you mean the completion proposal list or the tool tip on the right of the list? > Context Information = Ctrl+Shift+Space. I can't figure out what this currently > does - do you know? This brings up the content assist's parameter hint when typing a method, so we do not want to use this. >My current thinking is that the best thing is to have a keystroke that brings >up the annotations hover for the current line. We also think about something like this, but which annotations would we read: 1) all annotations configured to show up in the vertical ruler 2) all annotations visible in the editor's text 3) all annotations that exists even if not configured I would probably go for 1 as this covers more annotation types and given that it is configurable what appears in the vertical ruler. Do blind people need to know whether the annotation is on the ruler or the text? Another question: is there a way for screen readers to read the status line? I ask because whenever an annotation is at the caret location we set the status line.
> Do you mean the completion proposal list or the tool tip on the right of the > list? I meant the completion proposal list. Sorry - I don't know the correct names. > which annotations would we read: > 1) all annotations configured to show up in the vertical ruler > 2) all annotations visible in the editor's text > 3) all annotations that exists even if not configured Wow - so many choices. <g> I don't really understand all of them. What I was thinking was the annotations list that shows up if the user hovers over a single little icon in the left vertical ruler. I guess I was thinking that the vertical ruler on the left would be more useful to a blind person than the ruler on the right? (Are you saying that this is configurable?) For example, say that a line of code in an editor has a breakpoint icon, and a little red x icon, in the left vertical ruler. A sighted user can hover over this (merged) icon, and he will see a popup that says there are multiple markers for the line: (a) that this line of code has a breakpoint and (b) it has a compiler error. It would be nice if a screen reader user could move the I-beam to anywhere on that line of code using the keyboard, and then type a specific keyboard accelerator to open the same annotations list popup for the line of code. > Do blind people need to know whether the annotation is on the ruler or the > text? I'm not sure. Can we run through an example of each? > Another question: is there a way for screen readers to read the status line? > I ask because whenever an annotation is at the caret location we set the > status line. A very good question. Frank, did you ever figure out a way to get JAWS to read the Eclipse status line?
(In reply to comment #9) > Another question: is there a way for screen readers to read the status line? I > ask because whenever an annotation is at the caret location we set the status > line. > Yes, using jaws it is possible to read the status line. This is how I identify a compile error or warning. First I press ctrl+. to find an annotation and then I read the status line. I am not sure but I never found information about break points in the status line. I am testing eclipse with orca, but with orca I can not read the status line
>I guess I was thinking that the >vertical ruler on the left would be more useful to a blind person than the >ruler on the right? (Are you saying that this is configurable?) Agree, that the vertical ruler is more useful. What I meant however, is that it is configurable what appears in vertical ruler, right ruler and text (see General > Editors > Text Editors > Annotations preference page). Also note that some annotations only appear in the ruler (e.g. breakpoints) and some only appear in text (e.g. Occurrence marks and spelling errors). >I am not sure but I never found information about break points in the status >line. Right. Currently we only show problem annotation text there.
(In reply to comment #7) > Tom, maybe you have some insights here. No additional insight from my vision-impaired friends...
Dani, do you think it would be useful to narrow the scope of F1 Help so that it could bring up the annotations info? For example, right now, if the user navigates to anywhere in an editor using the keyboard and then presses F1, they get the Help view for Java Editors. After doing this two or three times, this help is not useful any more. Maybe we could make F1 a whole lot smarter by having it be *really* context-sensitive. For example, if the (I-beam) cursor is on a line containing annotations, open the annotations for the line - just as if the user had hovered the mouse on the ruler. If the I-beam cursor is on a line with no annotations, then open the Java Editors Help View. Another possibility is to look at augmenting F2 help, which currently is defined as "Show Tooltip Description" and opens the Javadoc for the Java element that the I-beam cursor is currently in. Something like Ctrl+F2 might be a good way to open the annotations tooltip for the current line, if any. Or maybe we could use F2, but the user would have to move the I-beam outside of any Java elements before typing F2, so it might not be as useful as just providing Ctrl+F2. (I notice that Shift+F2 is already taken for "Open External Javadoc").
(In reply to comment #11) > Yes, using jaws it is possible to read the status line. Jose, what JAWS command do you use to read the status line? > I am testing eclipse with orca, but with orca I can not read the status line Does Orca read the status line in any other GTK application? If so, what Orca command do you use to read a status line?
(In reply to comment #15) > (In reply to comment #11) > > Yes, using jaws it is possible to read the status line. > > Jose, what JAWS command do you use to read the status line? I use Kps_Lock+PageDown, LapTop layout > > > I am testing eclipse with orca, but with orca I can not read the status line > > Does Orca read the status line in any other GTK application? If so, what Orca > command do you use to read a status line? Yes, I can read the status line in applications like gnome-terminal, thunderbird, firefox, evolution, open office and etc. I mapped Kps_lock+pageDown to read the status line, like in jaws. >
(In reply to comment #12) >>I am not sure but I never found information about break points in the status >>line. >Right. Currently we only show problem annotation text there. Perhaps this should be configurable as well? For example, the status line could show all annotation types that are currently configured for Ctrl+. (Next Annotation). So if I have Errors and Spelling Errors selected and I type Ctrl+. and navigate to a spelling error, then this is what is displayed in the status line. (Can Ctrl+. be configured to navigate to a breakpoint?)
Here's what we will do for 3.5: 1) we will allow to enable Next/Previous navigation for breakpoints so that either using the toolbar button or Ctrl+. and Ctr+, can be used to navigate to a breakpoint 2) we will change our code so that all annotations that are reached via navigation will update the status line ==> blind users can use Next/Previous annotation and then request to read the status line. That way all annotations can be reached. For me the remaining question on this scenario is whether Eclipse should automate this i.e. always read the status line if it changes? Or always read the annotation text when using Next/Previous annotation. How would we send this to the screen reader? If time permits we will add a command (Ctrl+F2 is not a good binding as this terminates a debug session ;-) that allows to show the hover that we currently show when hovering over the vertical ruler icon. This hover already contains all annotations if there's more than one.
>1) we will allow to enable Next/Previous navigation for breakpoints so that See bug 270467.
>2) we will change our code so that all annotations that are reached via >navigation will update the status line This is done.
(In reply to comment #18) > 1) we will allow to enable Next/Previous navigation for breakpoints so that > either using the toolbar button or Ctrl+. and Ctr+, can be used to navigate > to a breakpoint > 2) we will change our code so that all annotations that are reached via > navigation will update the status line I like this - it is a good solution. > For me the remaining question on this scenario is whether Eclipse should > automate this i.e. always read the status line if it changes? Or always read > the annotation text when using Next/Previous annotation. How would we send > this to the screen reader? I don't think Eclipse should automatically read annotation text, and our accessibility API does not currently have a nice way of doing it. > If time permits we will add a command (Ctrl+F2 is not a good binding as this > terminates a debug session ;-) that allows to show the hover that we > currently show when hovering over the vertical ruler icon. This hover > already contains all annotations if there's more than one. I'm not sure that this is necessary if the status line has all of the info... What does the status line show if there are multiple annotations at the current location?
(In reply to comment #19 and comment #20) Great - thanks, Dani! FYI, I have opened bug 270472 to track that Orca does not read the status line on Linux-GTK. One more question: If there are multiple annotations (say, for example, a compile error and a breakpoint) then does Ctrl+. (and Ctrl+,) always navigate to both? If so, then I think you can close this bug.
>What does the status line show if there are multiple annotations at the current >location? The status line shows the closest annotation. That's not something we'd want to change, also because the status line is not well suited for lots of text. I've added bug 270475 which requests to add documentation about how to best configure the editor for accessibility. >One more question: If there are multiple annotations (say, for example, a >compile error and a breakpoint) then does Ctrl+. (and Ctrl+,) always navigate >to both? Yes, it will go to all that are enabled (checked) in the toolbar icon. >If so, then I think you can close this bug. I think a command to show all annotations still helps (as additional support). If not for 3.5 M7 then we will do it for 3.6.
OK, sounds good.
(In reply to comment #8) > Again, it would be nice if the user does not have to type an extra TAB to give > the shell focus. (because if there are no annotations for the line, then they > would be typing a TAB into their editor... which they would then have to > delete). > Yes, this is just what happens with me. I press ctrl+space and tab to verify if there are some proposals. It would nice avoid the extra tab key.
>It would nice avoid the extra tab key. Carolyn, I started to look into this but I cannot test because StyledText blocks if the Windows Narrator is running (filed bug 271291). Maybe you can test it for me using JAWS? What we also need to test is whether the editor gets back the control once the popup closes or whether we need to transfer the ACC focus back. I have attached a patch (against org.eclipse.jface.text for you to try out). If applying the patch is too complicated I can also commit it to HEAD and you can try it out in an N-build.
Created attachment 130967 [details] First cut of setting ACC focus to proposal popup
(In reply to comment #26) > transfer the ACC focus back. I have attached a patch (against > org.eclipse.jface.text for you to try out). If applying the patch is too > complicated I can also commit it to HEAD and you can try it out in an N-build. > I have no conditions to apply the patch but I can test with jaws if it was present in a nightly build. I'd like to test using orca too. Thanks.
Jose, I've committed the code to HEAD for you. Please try out upcoming N20090406-2000.
Testing with last nightly build with jaws 10.0.512 with no luck. I type for exemple: System. Jaws doesn't jump to the proposal list. I need to press the tab key. The same if I press ctrl+space to activate the code completion or if I press ctrl+1 to activate the quick fix. Another observation is that I couldn't read the break point information in the status line. Pressing ctrl+. doesn't navigate to the line where breakpoint is set. Am I doing something wrong? Thanks.
>System. >Jaws doesn't jump to the proposal list. It should not jump to the list but read the first item and when using up/down arrow keys it should read the element from the list. If it's not doing that then fProposalShell.getAccessible().setFocus(ACC.CHILDID_SELF); is either the wrong API or it is not working in JAWS. >Pressing ctrl+. doesn't navigate to the line where breakpoint is >set. Yes, you need to enable it on the tool bar button (either Next or Previous) first.
> fProposalShell.getAccessible().setFocus(ACC.CHILDID_SELF); Dani, can you try sending this to the list instead of the fProposalShell? I'm not certain that JAWS will pick this up, but I think it should. >Pressing ctrl+. doesn't navigate to the line where breakpoint is set. >Yes, you need to enable it on the tool bar button (either Next or Previous) >first. Jose, to do this using the keyboard, you need to first give focus to either an editor or the Outline View (to enable the annotation navigation tools) and then navigate to the toolbar (I use Ctrl+Shift+Tab) until you hear "Toolbar Next Annotation (Ctrl+.) SPLIT BUTTON". Then type down arrow to drop down the tool menu. Press Enter when you get to "Breakpoint" to enable navigating to breakpoints with Ctrl+.. Dani, do you think it makes sense to add "navigation enabling" to the Text Editors - Annotations Preferences page?
>Dani, can you try sending this to the list instead of the fProposalShell? Sure. Done in HEAD / N20090407-2000. >Dani, do you think it makes sense to add "navigation enabling" to the Text >Editors - Annotations Preferences page? Duplicates the preference but wouldn't hurt. Can you file a new bug for this? Do you think it's important for 3.5?
(In reply to comment #31) > It should not jump to the list but read the first item and when using up/down > arrow keys it should read the element from the list. If it's not doing that > then > fProposalShell.getAccessible().setFocus(ACC.CHILDID_SELF); > is either the wrong API or it is not working in JAWS. > It doesn't read the first item and when I press down key nothin is read. The same when testing with orca. > >Pressing ctrl+. doesn't navigate to the line where breakpoint is > >set. > Yes, you need to enable it on the tool bar button (either Next or Previous) > first. > Sorry, where I find this option?
>Sorry, where I find this option? See Carolyn's comment 32. Please try tomorrow's build: I changed the code as Carolyn suggested.
Created attachment 131146 [details] patch to make JAWS read content proposals list > Please try tomorrow's build: I changed the code as Carolyn suggested. Actually, I was able to try this change today, and unfortunately, it doesn't work. I tried giving ACC focus after the shell was visible, too, and that doesn't work either (I thought it would). I guess the list has to get "real" focus before JAWS will read the list contents. I am providing a patch that works beautifully with JAWS - probably Orca, too, but I didn't try it there. All I did was set keyboard focus to the list after the shell is made visible. (it doesn't work to give keyboard focus to the list before it is visible, for some reason). Note that I do not know if this breaks anything else... I do not pretend to understand the focus requirements of the completion proposals popup <grin>. Anyhow, this will give you an idea of what really does work, so you can maybe work with this idea to get the correct fix in.
(In reply to part 2 of comment 33) >>Dani, do you think it makes sense to add "navigation enabling" to the Text >>Editors - Annotations Preferences page? >Duplicates the preference but wouldn't hurt. Can you file a new bug for this? Done: bug 271491. >Do you think it's important for 3.5? Since there is a work-around, I think the Preferences page feature could wait until Eclipse 3.6, but Jose would be better able to answer this than I would. Jose, could you please let us know in bug 271491 whether you think the current method of enabling breakpoint navigation is way too complicated for a JAWS user, and should really be fixed before Eclipse 3.5 ships? We can make it better, but we are getting to the end of the Eclipse 3.5 development cycle, and we need to concentrate on priority items now.
Sorry Carolyn but giving the focus to the table is a no-go as this would break the behavior for users that are used to content assist working this way for years now. Is there no way to make the screen reader read something that's not in focus? Or: is there API that would tell us that a screen reader is listening and we'd only transfer the focus if that's the case.
There's no API to know that a screen reader is running - at least, nothing reliable and multi-platform. Would it be possible to add it as a preference on the Text Editors - Accessibility preference page? There are already a few preferences there that are specific to accessibility. (Hmmm... what is the "Use characters to show changes in vertical ruler" preference for?)
>Is there no way to make the screen reader read something that's not in focus? I just noticed that you asked this question. The answer is that there is a way... sort of. It is the API you saw: .getAccessible().setFocus(ACC.CHILDID_SELF); Screen reader manufacturers don't like having focus "faked" like this. The ACC focus API is supposed to be used for custom controls to specify that certain parts of their client area "have focus" (i.e. internal areas that have a child ID, and are being used to implement the custom control). In all cases, the Canvas or Composite window that is implementing the custom control really has the focus, so specifying that parts of it "have focus" is not too much of a leap of faith. But in the case of the completion proposals, the StyledText actually has the focus, and we are trying to tell the screen reader that a list in a completely different shell "has focus" when it really doesn't. It is too far from the truth <g> so the screen reader is ignoring it.
>(Hmmm... what is the "Use characters to show changes in vertical ruler" >preference for?) This is for color-blind people or people for which the change ruler is too small. >Would it be possible to add it as a preference on the Text Editors - >Accessibility preference page? Yes, that's what I had in mind as well as a last resort but wanted to avoid because quite a bunch of new API would be needed to pass that preference along to the proposal popup and we're in API freeze now. Jose, given we have a workaround I'd like to defer this to 3.6 M1.
(In reply to comment #41) > Jose, given we have a workaround I'd like to defer this to 3.6 M1. > Nice.
The fix that would automatically set the focus to the proposal table might not be too good because once the focus is transferred the user can no longer type additional characters to filter the list further. Jose, what's your opinion on this? Did you think of this restriction? Could maybe some other accessibility API do the trick, e.g. org.eclipse.swt.accessibility.Accessible.selectionChanged()? Or some API that allows me to explicitly feed the string to be read?
(In reply to comment #43) > The fix that would automatically set the focus to the proposal table might not > be too good because once the focus is transferred the user can no longer type > additional characters to filter the list further. Jose, what's your opinion on > this? Did you think of this restriction? > To be honest I never thought of that, and I agree entirely. One idea, maybe stupid but simple, would be put in the status line the information that exists a proposal table. Before press the tab key, the user could read the status line to check if the proposal table is present. Of course it could be configured on the Preferences page for accessibility.
You mean, you need an indication for cases where the proposal popup came up automatically (e.g. after typing a '.') and not when you've invoked it using Ctrl+Space? I still think there must be a way to feed string directly into the narrator.
(In reply to comment #45) > You mean, you need an indication for cases where the proposal popup came up > automatically (e.g. after typing a '.') and not when you've invoked it using > Ctrl+Space? I still think there must be a way to feed string directly into the > narrator. > Everytime the proposal popup appears in the screen, either because it is activated automatically or because I've invoked using ctrl+space or ctrl+1. Regarding feed string directly into the narrator I've no information and I'm not sure if it would be a solution, to all plattforms.
(In reply to comment #44) > (In reply to comment #43) > > One idea, maybe stupid but simple, would be put in the status line the > information that exists a proposal table. > Before press the tab key, the user could read the status line to check if the > proposal table is present. > Of course it could be configured on the Preferences page for accessibility. > Another stupid idea could be put a message in a tooltip instead of put the information in the status line. Jaws could be configured to read the tooltip automatically. The message would inform that a proposal table is present and the user may press the tab key to access the table.
I'm marking this bug as fixed and opened bug 272167 to track the screen reader issue regarding content assist and bug 272172 for the idea of adding a command that shows the vertical ruler hover.
Agree. Thanks, Dani.
(In reply to comment #18) > Here's what we will do for 3.5: > > 1) we will allow to enable Next/Previous navigation for breakpoints so that > either > using the toolbar button or Ctrl+. and Ctr+, can be used to navigate to > a breakpoint > 2) we will change our code so that all annotations that are reached via > navigation > will update the status line > > ==> blind users can use Next/Previous annotation and then request to read the > status line. That way all annotations can be reached. How does one request to read the status line?
(In reply to comment 50): >How does one request to read the status line? If you are running the JAWS screen reader, you type INS+PageDown on a desktop computer, or CapsLock+PageDown on a laptop computer.
Paul, the Help contains a document regarding accessibility features and setup: Workbench User Guide > Concepts > Accessibility features in Eclipse You can also reach that page via F1 in the editor.
