In the case of Orca speech could there be an optional:
- Auditory cue (low volume double speed narration?) when keyboard
navigation bypasses disabled widgets.
- Shifted mode which allows the user to traverse through and view
the disabled widgets
The first has the advantage that I don't think it requires changes
in gtk, but I don't think it would work with braille output
devices. The second option would require changes in gtk but could
work with braille devices.
On 01/ 5/12 04:31 PM, Christian Hofstader wrote:
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
_______________________________________________
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-accessibility-list
|
