Community
Participate
Working Groups
build I20021105 In talking with a blind user, he asked how to get to the accessibility help topic. Here are the steps I sent him: Use Alt+H, H to get to Help > Help Contents. This opens up the Help window. Hit Tab 9 times to give focus to Workbench User Guide, the first entry in the TOC. Hit Enter to open it. The chapters in the User Guide appear under it. Hit Down Arrow twice to give focus to Concepts. Right Arrow to expand Concepts. Down Arrow 12 times to give focus to Accessibility features. Enter to select it. The contents now appears in the pane at right. Hit Tab 22 times to give the pane focus (I know of no shorter way of doing this). Further tabs navigate through the links on the page, which lead to sub-sections on accessibility. Further tabs eventually cycle you back to the TOC. The other accessibility sections are shown under Accessibility features in the TOC. These include: "Navigating the user interface using the keyboard", "Keyboard shortcuts", "Font and color setttings using the Window Preferences". Phew. This could clearly be improved. This must be similar to other accessibility problems with frame-based web pages, although this seems particularly bad. There are a lot of extra tab stops, some of which are invisible. It would help (pun intended, I guess) if initial focus was given to the first entry in the TOC. I'm not sure how much control we have over these aspects though.
This is a better description for bug 20206. One thing that is missing in your explanation and improves things quite a bit is using Ctrl-Tab and Ctrl-Shift-Tab to move to the next/previous pane. You won't need 22 tabs to get to it. The bug is still very valid ,though.
In the latest help driver, we added a basic UI that is used by any browser other than IE/Mozilla/Netscape6&7. That UI works without Javascript enabled, has only 3 frames and should be much easier to deal with. Perhaps we should make it available as a preference for user who need keyboard support.
Ctrl+Tab helps a lot. I didn't know about that. The trimmed down browser sounds interesting, I'd like to see it.
In the latest build, run help, then Ctrl-N in the help view to open a full IE browser, copy the url location and paste it to a Netscape 4 browser.
Sorry, why would I do this? Is running an external IE better in some way than the embedded one? Is using Netscape 4 better than IE for accessibility? Why should a keyboard user have to go through these extra steps?
No, users should not do any of these. I was just interpreting your last sentence: "The trimmed down browser sounds interesting, I'd like to see it." as, "what can I do now to see how this would work?" and provided the instructions for the current driver so we could get some feedback from you. So, if you follow those steps and think that we could go with a simpler UI for accessibility, we could make that a preference setting that those users would pick.
BTW, the stripped down version of the help UI works in any browser, not just Netscape. The code right now will never pick it up if the browser is IE/Mozilla, but we could make that a preference, as mentioned in my last comment.
Thanks for the clarification, I'll try it out.
A blind user (Jim Homme) says: When I am in the help perspective, I cannot tab to the text in the help window. I have to click with the JAWS cursor to make focus go there. Solving that one problem would go a long long way to getting me to lots of stuff that I can much more easily read. Please keep in mind that we have WSAD 4.02 here. --- Compare accessibility in our help with the standard Windows help on other apps. E.g. In IE, choose Help / Contents and Index. The contents list has focus and the first item is read properly in JAWS. Ctrl+Tab cycles the tabs. F6 switches panes. Ours requires -way- more keystrokes. Now, I know we have a challenge using a web browser, and using frames. But we must be able to make some improvements here, and should not require using a different help mode for those that need to or want to use the keyboard.
WSAD 4.02 is based on Eclipse 1.0, which is basically completely inaccessible (not just Help). I will encourage Jim to switch to WSAD 5.0 (on Eclipse 2.0) as soon as possible. However, we still need to look at improvements here.
Thanks for the feedback. It is great to actually get this kind of info for people who are actually using it. I have some doubts that accessibility can be significantly improved on the main help ui, as we are using web pages to make it look more like a real app. The basic help ui that I mentioned before would be a better candidate, but I would like to firt get Jim's take on the current help.
Nick, The bug was initially opened for the Eclipse 1.0 help. In 2.1, using the browser key bindings: ctrl-tab: next frame shift-ctrl-tab: previous frame, navigation should be reasonable. Could you please let us know what problems, if any, are still in a later driver, so we can focus on them. Thanks!
It certainly is better with Ctrl+Tab. However, there are still some unnecessary tab stops, e.g. the Contents frame. There are 3 "dead" tab stops at the end of the cycle. Also, it's still not apparent where the initial focus is. I still have to hit Ctrl+Tab 4 times then Tab once to give focus to the table of contents.
This is an unfortunate side effect of using frames. Without frames, user's experience would be pretty bad. It is possible to change the order in which frames receive focus, but then it probably confuse users. Right now things are flowing top/down, left/right. If in 2.2 we have our own html widget perhaps we can define our own key bindings for directly navigating to a certain frame. We'll investigate the issues a bit more, but don't have a clear solution.
It's still unclear to me why there are hidden tab stops. Are there some hidden frames?
Good catch! Pressing Ctrl-Tab to move through the frames there is only one hidden tab stop (don't know why). Only when pressing Tab to move through everything then you get the 3 hidden tab stops. We will investigate.
I have removed two tab stops between search frame (the top) and the navigation frame, by skipping navigation toolbar that has no selectable elements, and skipping stop on the frame that contains navigation toolbar and the navigation IFrame. The focus goes directly to the navigation IFrame. I have added code to place the initial focus in the search input field. You now need only one Ctrl+Tab to get to the TOC. I cannot get rid of the 3 tab stops at the end of the cycle (there is also one in the middle - after tabs frame). Two of the stops are IE bug, and one is SWT. We are using nested frames, with each frameset defined in a separate source file, which seem to confuse IE. Content frame is nested twice, and IE adds two dead tabs stops, when getting focus out of this frame. I all framesets were defined in the same file, IE would handle this. Mozilla has no problems with nested frames. The third tab stop is actually at the beginning of the cycle, but since we now place the initial focus in the entry field, it seems like it is at the end. The bug is a small leftover from the bug 12398 that SWT could not fix.
Good news about the tab stops. Just to clarify: all buttons are still accessible?
Yes, it has not affected the buttons. They are accessible as before.
In M5, letf and right arrows can be used to move the focus between the tabs at the bottom of the navigation. Pressing up arrow selects the given tab and moves the focus to the navigation frame so that user does not have to use Shift- tab or tab around to get to the navigation. Nick, Is there anything outstanding in this bug that has to be fixed for 2.1?
The changes that have been made for 2.1 have really improved things. I don't see any major issues that need to be addressed for 2.1.
I will close the bug then. Please do not hesitate to open if any new problem is found.
