RE: Recommendation for Disabled Items

Hi all,

 

please find my comments below in Don's mail.

 

Best Regards,

Stefan

 

 

Dr. Stefan Schnabel 
Accessibility Expert 
User Experience - Accessibility 

SAP AG
Dietmar-Hopp-Allee 16, 

69190 Walldorf, Germany


T: +49 (6227) 7-65652
F: +49 (6227) 78-29877


mailto:stefan.schnabel@sap.com <mailto:stefan.schnabel@sap.com>  


W: www.sap.com; http://www.sapdesignguild.org
<http://www.sapdesignguild.org/> 

 

 

From: wai-xtech-request@w3.org [mailto:wai-xtech-request@w3.org] On
Behalf Of Evans, Donald
Sent: Dienstag, 13. Mai 2008 21:17
To: wai-xtech@w3.org
Subject: Recommendation for Disabled Items

 

1.	*  The PFWG has asked the DHTML Style guide to make a
recommendation about keyboard access with respect to disabled items.  We
have discussed it, but have not come to consensus.  Below you will find
the current recommendation.  Please feel free to add your comments. 

        Use case: A locked spread sheet. A disabled item on a menu. A
read-only or disabled property in ARIA. 

*	Accessible information must be perceivable, navigable and
usable. In the case of disabled information, by definition it is not
usable, but never-the-less must be perceivable and navigable. 

I fully agree.

*	For information to be perceivable it should be announced as you
enter a widget. In the case of a menu with disabled menu items, it might
announce, "Menu with 5 items. 3 are disabled.". 

We do announce disabled items, but we don't announce explicitly the
number of disabled items on entry, I think this is a little bit
overdone.

In the case of a disabled spread sheet, it might announce "Grid with 15
read only cells". 

If the entire sheet is disabled, it should be announced as such, with
given row/col count (not cells, this number may become  laaarge), e.g.:


Grid with 10 rows and 5 columns - Read-Only 

*	For information to be navigable, you must be able navigate to it
and have it read with a screen reader. This does not necessarily mean
that focus needs to move there with the tab key.but it does mean that
you should be able to navigate to it with some set of key strokes. In
the case of a menu, you tab into the widget and tab out of the widget.
Once in the widget, the arrow keys take over for navigation. 

I fully agree. In some cases yes (lists, menus and read-only grid
navigation), in others no (forms). Have to be very precise here what to
navigate how.

The arrow keys should move to all menu items even the ones that are
disabled.

Yes. Very important.

The same principle holds true for the grid example. 

*	Allowing navigation to the disabled content could be implemented
as a user preference in the AT. 

User preference of navigation to the disabled content we consider as a
good idea, too, but we don't want AT to handle that. This sounds to us
that AT should do the Keyboard navigation, and we don't think that this
is justified for ARIA role=application at all. Instead JS libraries and
User Agents should support this and AT should not hinder that at all.

Resist the temptation to believe/demand that AT should handle keyboard
navigation specialties. If so, you rely one day on some specific AT
vendor because your disabled controls will be in the tab chain only with
product XYZ. This is a dead-end street !!!

 

Donald F. Evans

Sr. Program Manager,

Office of Accessibility,

AOL LLC

AIM: donaldfevans

Phone 703.265.5952