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. >> > > -- > <oracle_sig_logo.gif> > 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 > 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
