Panel Accessibility - Key Nav
- From: Glynn Foster <glynn foster sun com>
- To: gnome-hackers gnome org
- Cc: gnome-2-0-list gnome org
- Subject: Panel Accessibility - Key Nav
- Date: 17 Nov 2001 18:52:26 +0000
Okay, I might as well post some of the writeups that Calum did for
keyboard navigation [hope this is okay Calum ;)]...
See ya,
Glynn :)
**************************************************
**************************************************
By way of making the panel(s) keyboard accessible, I offer a bunch of a
problems that need solving, and few solutions as yet :o) All thoughts
welcome...
Cheeri,
Calum.
---
The panel needs to be able to gain focus somehow. From the user's point
of view, there would probably need to be a window manager shortcut to do
this (don't know what-- the closest Windoze shortcut is Ctrl+Esc, to
give focus to the Start menu). Additionally or alternatively, there
should probably be a way of specifying you want some/all of your panels
to appear in the Tasklist applet, and also in the sequence as you cycle
your way with Alt+Tab through the available windows.
Problem: Panels don't currently have names, AFAIK-- how would you know
which was which in the tasklist/Alt+Tab sequence?
Poss.Solution: provide default names for panels as they're created,
allow user to change these somewhere.
---
How to show a panel has focus-- is giving the first
menu/drawer/launcher/applet focus enough? Doing so would be in keeping
with the way we show that a toolbar has focus, so maybe yes.
Problem: the user should be able to pop up the panel shortcut menu using
only the keyboard, which logically would mean pressing Shift+F10 when
the panel (but not any of the objects on it) has focus. Otherwise you'd
get the shortcut menu for the focused panel object.
Poss.Solution: If we used Tab to navigate around a panel, we could
potentially include "panel focused but not any of its objects" in the
tab sequence for each panel. However, see below for why using Tab to
navigate around a panel may not be a brilliant idea :o) We'd also need
a graphical way of showing that the panel had focus but not its
contents, of course.
---
Once a panel has focus, probably want to be able to cycle focus between
other panels on the desktop-- so we could have just one desktop-wide
shortcut for "give focus to panels", rather than one for each panel
(which wouldn't be possible anyway). We could use Tab for this, the way
we've proposed for cycling between available menubars/toolbars/splitter
bars.
Problem: that would mean using arrow keys to move focus between objects
on a panel, which could be a problem with various applets that need
arrow key navigation themselves. E.g. the volume controller applet
should probably (when made accessible) use the arrow keys to
increase/decrease volume when it has focus); taslkist, xchat applets
would probably also rely on arrow key navigation once they had focus.
Poss.Solution 1: Use Tab to navigate around a panel instead. However,
as well as being inconsistent with toolbar/menubar approach, this leaves
no way to cycle only between available panels-- you'd have to rely on
Tasklist/Alt+Tab. That's probably acceptable, I guess.
Poss.Solution 2: Make it so you have to explicitly activate/deactivate
applets (i.e. give them focus, then press Enter) before you can use them
from the keyboard. Problem: When you interacted with an applet with the
mouse, that would presumably implicitly focus and activate it, and it
wouldn't be obvious that you then had to deactivate it if for some
reason you then wanted to reposition it on the panel using the keyboard
(for example).
---
Once a panel has focus, need to be able to give focus back to a window
on the desktop. Could use a second press of Ctrl+Esc for this, or
Ctrl+Tab (as our universal "get out of this" control), or even just
Esc? Tasklist applet and Alt+Tab would of course work as well.
Problem: Care needs to be taken when making tasklist applet accessible,
as using it with the keyboard may need to have a different effect from
using it with the mouse. For example, if I give the tasklist keyboard
focus, select a running app from its list with the keyboard, and press
Enter to activate that app, would I want focus to move to that app or
stay on the tasklist applet? There's a case for either behaviour.
---
Indicating a panel object has focus: how could we do this? Crudest and
simplest method probably just to draw a focus box (as per the current
gtk theme) around the icon/applet window.
---
Once a panel object has focus, need to be able to reposition it much as
you can do with drag and drop just now. Ctrl/Alt/Shift+arrow keys seem
like a reasonable way of doing this, following the current "default
movement" modes in control center, i.e.:
- Alt+arrow keys move focused object by a small amount, doesn't disturb
other panel objects until it actually collides with one, at which case
we could either jump over it or just stop. ("Free movement" in control
center).
- Ctrl+arrow keys moves focused object directly past the first object
encountered in that direction. ("Switched movement" in control center).
- Shift+arrow keys same as Alt+arrow keys, except applets are "pushed"
rather than "skipped" when there is a collision. ("Pushed movement" in
control center).
Problem: This would mean that focused applets couldn't use
Ctrl/Alt/Shift+arrow keys for their own purposes.
Poss.Solution 1: Have a "move objects" mode that you need to
engage/disengage from the keyboard somehow when you want to move things
around a panel. A bit yuck, but would avoid any unpleasant accidental
rearrangement accidents.
Poss.Solution 2: Require user to explicitly activate applets (i.e. focus
them and press Enter) before they can interact with them. See earlier
comment for issues with this.
---
You can currently copy or move a panel object from one panel to another
with [Ctrl+]drag and drop. If we wanted to provide keyboard equivalents
for this, we'd probably either need to look at doing it with
Cut/Copy/Paste-type shortcuts, or build new functionality into the panel
menus explicitly for this purpose. Possibly not an issue for a first
cut, though.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]