| I generally agree with Peter here…
I think the user agent, Orca in this case, can and should provide augmentations to the overall user experience. Items that do not gain focus ordinarily need to be presented to users with vision impairment anyway as knowing what isn't available in a certain mode is tremendously important to us.
On Jan 5, 2012, at 11:23 AM, Peter Korn wrote:
Hi Joseph,
You raise a very good point, but I think we need to be careful about
when we conflate sighted keyboard-only users with screen
reading/magnifying keyboard users. In some cases their needs are
the same (e.g. how does a sighted keyboard user select text from a
web page to copy it to the clipboard? same way as a blind keyboard
users moves the caret & selects text), in some cases not (e.g.
how does a sighted keyboard user discover what the menu's contents
are, including which menu items are not available).
Since we don't expect sighted keyboard-only users to use an external
assistive technology, everything *must* be built-in. However, we do
expect blind users to use an external assistive technology - in this
case a screen reader (which of course should be Orca). When
external AT is involved, it *may* be appropriate to have any given
piece of functionality in the AT rather than built into the
widgets/toolkit/desktop/environment itself.
I not certain what the right answer is here for unavailable menu
items - whether they should be keyboard navigable or not. In some
toolkits they are keyboard navigable (e.g. Swing). But - other than
display of any tooltip associated with an unavailable menu item -
there isn't much overlap between sighted keyboard-only users and
screen reader users. Therefore it isn't so clear that the access
solutions for those two use cases should be the same.
Regards,
Peter
On 1/5/2012 6:25 AM, Joseph Scheuhammer wrote:
All,
Here are a couple of issues related to the accessibility of
disabled menu items.
A similar problem occurs in tool bars with disabled tool bar
buttons. In some toolkits, keyboard-only users cannot navigate
(put focus) on disabled buttons. The rationale for that behaviour
is that sighted keyboard-only users *can* see the button, its
icon, its label, and so on. Users can also see that it is
disabled (it's greyed out). For efficiency sake, this rationale
goes, there is no need to navigate to it.
However ...
When users hover over a toolbar button with the mouse, a tooltip
pops up. This occurs even when the button is disabled. BTW, tool
bar buttons are not the only UI elements that have tooltips or
descriptions. Other widgets, including menu items (sometimes)
have tooltips.
There's an a11y heuristic: whatever users can do with the mouse,
they should be able to do with the keyboard.
There needs to be a way that keyboard only users can navigate to
disabled widgets to acquire information about them, such as their
role, their label, a tooltip/description, the fact that they are
disabled, and other information.
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
|
