Community
Participate
Working Groups
This is to capture accessibility related problems encountered on our first "no mouse day" (Nov. 19, 2001).
In documentation, need to explain all keyboard access functionality from the ground up, including: - context menu key (on some keyboards) - use of mnemonics - standard OS accelerators: SHIFT+F10, F10, ALT, ALT+F4, etc. - all our global accelerators - view- and editor-specific accelerators
When first started, I ouldn't pop up menu in repository view to add new repository initially. The empty pane apparently doesn't take focus until clicked on.
Progress dialog for loading stream didn't seem to have focus. ESC gave focus to main window. No way of getting back to progress dialog if main window gets focus.
Doc: use CTRL+TAB, CTRL+SHIFT+TAB when in editor, or other widget which uses TAB itself. Need to clarify whether it's acceptible for the editor to use SHIFT+TAB.
Tab order not updated when views rearranged. - in Java perspective, open Repositories views - it has no tabs - drag over folder containing packages view - hit Tab - it should go to folder tabs, but instead goes to toolbar
In Java Build Path project properties page, ALT+R doesn't activate the Remove button. No apparent conflict with &R.
Editor switcher should use bring-to-top history, not activation history. E.g. when using search
Popup menu should open submenu when shortcut key is pressed. Win2000 - Tested on 1.0 and latest 2.0 1) Activate Navigator 2) Open popup menu 3) Press o (To select goto resource) ** It should open the submenu 4) Press R to open the "Goto resource dialog" ** It will open "Properties" The Windows Start menu is different. 1) Open start menu 2) Press S. The settings menu shows up.
Acelerators do not work when OLE editor is activated. 1) Open a *.txt file 2) Open a *.bmp file (should open MS Paint) 3) Try Crlt F6 ** Nothing happens. There is no way to switch to other view or editor using keyboard.
Not always easy to know which Control has focus. 1) Run (debugging) a java program and close it. 2) Activate the debug view 3) Select "Remove all activated lauches" in the debug toolbar 4) Press enter to clean all item in the debug view. 5) Press CTRL TAB a few times. When the focus gets in the debug toolbar there is nothing indicating it since the last toolbar item is now disabled.
Comments from RG: 1) Some preference pages are grabbing focus when they become visible. This makes it difficult to taverse the preference tree (same for some property pages). 2) Creating a Java Project opens the packages view in the Java Perspective and selects the new project but you do not have focus in the packages view. 3) Could not resize table columns 4) The ctrl-f6 ctrl-f7 popups: a) Wouldn't it be better to have these in a static order rather than mru (more predictable and learnable). You could still preselect the last to support fast back and forth switching. b) There always seems to be one extra row at the bottom of every list. 5) Viewing problem descriptions is a pain (have to find them in the task list).
Comments from TC: The Preferences Dialog has focus on the first entry first - it would be better to focus on the list F10 = run again in Java Perspective - how do we get to menus then? New perspective selection combo activates as you scroll through it Opening an editor does not focus the edtor - muat reselect to get menu PDE cannot tab through In the Java Perspective switching to the PackagesView doesn't work - it selects the fast view instead. Can only cycle through one editor at a time with tabs
Comments from DS: In about 2 hours of playing I didn't find anything I was incapable of doing, except for navigation in the Compare and Sync views. Here are some minor issues I found. I will play with it tomorrow for a few more hours. It would be really nice if the neumonic for a view was underlined in the view title. As it currently is, I have to find it by looking in the Show View menu. A neumonic in the view title is consistent with my past experience for menus, and would suggest that accelerator access is possible. The Show View menu contains 2 lists, the static config and the open views. I find it overloading when I have a lot of views. Is it possible to show categories? Or split the list into two, with a separator between static and open? Problem: If the focus is in an editor, and I press Alt + P together, the Perspective menu opens. If the focus is in a toolbar I need to press Alt, release it, then P, to get the Perspective menu open. The separation between view and editor navigation is interesting. If I'm in a view I can hit F12 to get the editor. If I'm in an editor, how come I can't hit F12 to get back to the last view? This might make it very easy to toggle back and forth. When I open the view or editor popup I am always slightly confused by the contents. The current view / editor appears at the top, but the selection is the second item. (I recognize that it is the last active part, but for some reason my mind is confused by this). Beyond the second item, the other items appear in MRU order, but I can never remember the MRU order, so it forces me to do a linear scan of the list when looking for views. I know this is not your area, but let me complain about Step Over, Step Into, etc. If my focus is in the editor, and I invoke the accelerator for either, the Debug view is activated. It is terribly annoying. Again, this is not your issue. Once the focus is in the Debug view, if I need to select an item further up in the stack trace, the Debug view opens up the editor for every item as I move up using the cursor keys. It would be nice if they had a delay. Put focus in the perspective drop down list box. Then invoke Alt - Hyphen to invoke the system menu for an editor. Invoke Move, move the editor around, hit return. Then move the cursor keys and notice how focus is still in the drop down list box. If I invoke the menu for a part perhaps the part should receive focus?
Interesting. Pasting DS's comments from Notes excluded the item numbers. Here are my replies to DS: Re 1. View mnemonic underlining The mnemonic is not necessarily the same as the accelerator. The accelerator may not use a character which is in the view. For example, another product uses F4 for the properties view. Also, mnemonics are normally triggered by ALT+ {mnemonic}. The view accelerators so far use CTRL+ALT. Finally, if we make mnemonics visible in the main window, we have to ensure that they don't conflict with the main menus. Re 2. Static vs. open items in show view menu Interesting suggestion. Perhaps part of the problem is that the order of items seems ill-defined. Is there a defined order between the perspective's own view shortcuts and those contributed by other plugins? Opened ones are currently just added to the end if not already there. Re 3. Menu mnemonics not working in toolbar. Seems like an SWT or platform bug. I've filed bug 6103 for this. Note that accelerators work, and it works if toolbar combobox has focus. Re 4. F12 to switch between editor and last view Interesting suggestion. In general it's bad UI design to have an action work differently in different contexts: it creates a "command mode". But this one seems reasonable. If you were clicking between two editors, e.g. in a split editor area, should it alternate between them, or still between the last editor and last view? Note that CTRL+F7 once will always get you to the last view. Re 5. MRU order in switchers is confusing Not sure what to do here. As with ALT+TAB in Windows, you can use it to switch to the previous view without thinking. After that, you have to look and read the items. After a few items the order is essentially random since you don't remember recently used views beyond 2 or 3 back. Re 6. Debug accelerators losing focus I've filed bug 6105 for this. Re 7. Editor changing when moving up in stack frame list. This is a general problem we have, anywhere where we're opening or activating something else on a single click. This is fine for mouse input, but is slow and flashy for keyboard input. We should have a delay in such cases when changing selection via keyboard, but not when using mouse. Re 8. Giving focus to part after using its system menu. Seems reasonable.
Comments from LK: Hey Nick. I tried to do the "no mouse" some - it's kind of painful. It seems like there's too many windows/toolbars to quickly become effective with this mode of operation (i.e., you'd have to practice at it some to get patterns down). Anyway, things that I noticed (or maybe just don't know how to do): 1. - Software Updates Wizard does not have mnemonics for its buttons (i.e., an underlined letter that will activate the button). That is the only wizard that I noticed that didn't. 2. - How does one resize the columns of a table with the keyboard? 3. - How does one get hover help when in keyboard mode? 4. - I tried to useTAB/CTRL-TAB to get to the various tool bars on the various windows in the perspectives. It was hard to get a good feel for where focus would go next. Maybe with practice it would become more apparent. I did notice that in the Help View that it was impossible to get to the search tool button. On my window all the tools before the combo box were disabled. TAB goes to the combo box, but continuing to press TAB never cycles to the search button (this was true of the other perspectives - once that combo had focus it was hard to get to any tools after it). 5. - In the Help window I also found it confusing that once I got to the tool bar on the help window, pressing next (i.e., via arrow key) wouldn't take me to the "X" to close the window. Visually the close button seems like it's part of the other group of tools (i.e., the group with the arrow and the printer icons). 6. - I couldn't figure out how to close a perspective via the keyboard when the perspecitve toolbar had focus. Hope this helps some...I will continue to try to use the keyboard some. My feedback is based on 20011116.
Reply to LK's comments: Re 1. Software updates wizard missing mnemonics I've filed bug 6106 for this. Re 2. Resizing table columns There is currently no way of doing so. The OS has no support for this. We will likely need to add extra dialogs for doing this in some views, e.g. task list. Unclear how to handle this well in other contexts. Re 3. Getting hover help There seems to be no way currently. Screen readers like JAWS will read this info out, but there should be another way for sighted users. Re 4. Tab getting stuck in combobox This is fairly confusing. The combobox in the toolbar is a separate tab item from the toolbar it's contained in. If this has focus, you can hit SHIFT+TAB one more time to give focus to the toolbar itself, then arrow keys to get to the buttons both before and after the combobox. We're looking at this. The combobox shouldn't be a separate tab item. Re 5. Not getting to close box. This is fixed in builds after 20011116. All view toolbar buttons are on a single toolbar now. Re 6. Can't close perspective when combobox has focus. The combobox itself doesn't let you do this, but you should still be able to ALT+P, C to choose close on the perspective menu. There's a known problem where menu accelerators like ALT+P don't work when a toolbar button has focus. It works for the combobox though.
Discussion with KR: KR> I didn't participate for long because I had to switch to WSDD (R1.0) today. All I noticed is that revert to saved is not accessible by keyboard. NE> You should be able to access it on the editor's context menu, just as with the mouse. Use the menu key or Shift+F10 to get context menus. Does this not work for you? KR>I didn't know about the shift+F10, thanks! I looked in the Edit menu but it doesn't seem to have everything that the context menu has. NE>I'm not going to file a PR for this, since I assume it's by design. Regarding context menus, the Windows UI guidelines ("The Windows User Experience") recommend the following (my summary): - include only commands that apply to the selected object (or objects) and its context, rather than commands grouped by function - keep length and depth (submenus) to a minimum - limit to common, frequent actions - container of selection usually provides the context menu, but includes object- specific actions - avoid using context menu as the only way to access a particular action - but, need not limit it only to actions included in drop-down menus (e.g. commonly used property otherwise available on secondary dialog) - recommended order of items: - object's primary commands first (e.g. Open, Play, Print) - tranfer commands next (e.g. Cut, Copy, Paste) - other commands supported by object (whether provided by object itself or its context) - "What's This?" when supported - "Properties" last - use separators to separate groups of commands
Reassessment done on the current errors. If all of the dependant PRs are fixed this one can be closed.
Bug 6103 is not critical. Bug 8313 has been reclassified as usability, not accessibility. Closing this one.
