Re: Can the community work with Gnome to improve GTK+ a11y?

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.



On 1/5/2012 6:25 AM, Joseph Scheuhammer wrote:

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.

Peter Korn | Accessibility Principal
Phone: +1 650 5069522
500 Oracle Parkway | Redwood City, CA 94065

<green-for-email-sig_0.gif> Oracle is committed to developing practices and products that help protect the environment
gnome-accessibility-list mailing list
gnome-accessibility-list gnome org

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]