On Sun, Jan 1, 2012 at 6:59 AM, Joanmarie Diggs <jdi...@igalia.com> wrote:
>> - Menus that are greyed out seem to not exist for screen reader users.
>
> Well, in terms of navigation, they don't exist for anyone. I see them,
> but I can't get at them physically. Whether or not greyed-out menus and
> menu items should be navigable by all users is a question for the Gtk
> developers.
>
> The fact that Orca should present greyed-out menus and menu items but
> fails to do so is nonetheless a valid concern. Given that Orca's normal
> mode of operation is to present the focused item as the user interacts
> with it, and given that these creatures are (at the moment) not
> focusable items, I think the most appropriate means to make these items
> "exist" for screen reader users would be via Flat Review since that's
> the "what's visible on the screen" mode. I've just opened the following
> bug against Orca and will try to address it in the very near future:
> https://bugzilla.gnome.org/show_bug.cgi?id=667087
Interesting.
On Windows, disabled but visible menu items receive focus as you arrow
through the menu.
On Mac OS X, disabled but visible menu items do not receive focus as
you arrow through the menu and are not highlighted when you cursor
over them. The behavior with VoiceOver appears to vary depending on
how you configure the interaction between the mouse pointer, keyboard
focus, and the VoiceOver cursor (Navigation tab in the VoiceOver
utility). You can always move between all menu items, enabled or
disabled, by moving the VoiceOver cursor directly. Sometimes keyboard
focus follows and even disabled menu items receive the blue highlight.
Sometimes just arrowing through the items includes disabled menu
items. In any case, when a disabled item receives focus, VoiceOver
reads something like "Paste Dimmed Command V".
In terms of platform APIs, I'd suggest it makes sense to allow
accessibility API clients like Orca to:
1. Move point of regard to a disabled menu item.
2. Intercept arrow navigation and substitute an alternative route
through the menu items that includes disabled items.
3. indicate the point of regard by visually distinguishing the
focused but disabled item.
Any user interface provided on top of these platform capabilities
should hopefully be clearer in its impact on menu navigation than
VoiceOver Utility's somewhat bewildering Navigation tab.
Skipping disabled items helps users who are using the keyboard for
reasons other than visual disabilities (e.g. people who struggle with
mice and power users who prefer to avoid them), so I doubt putting
disabled items into the default focus order would be beneficial.
It's also worth stepping back and thinking about the problems we're
trying to solve here.
As I understand it, the problem sof not being able to access the
disabled menu items are:
* The user cannot discover commands that are not currently applicable.
* Having discovered a command, the user cannot easily distinguish
between their failure to find a command and the command being
inapplicable.
Help menus on OS X have a very interesting feature: a search box where
you can type a word and the interface will be searched for a matching
command, including disabled items. The search results are presented as
menu items in the Help menu. As you focus a particular result, you can
activate the command. Also, the location of the command is visually
indicated so you can locate it later. (For example, a menu might be
open and a blue arrow hover alongside the command.)
Apple's implementation of this feature isn't particularly great (the
accessibility in particular is woeful), but I think some sort of "find
the command" feature could really help users deal with menus that are
complex and changeable. It's a little like tab completion of commands
in Emacs.
--
Benjamin Hawkes-Lewis
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
