RE: Recommendation for Disabled Items

I would like to support Stefan's comments and below I have included
Donald's original comments and Stefan's response, followed by mine
prefixed with SC:.
Sally Cain
Digital Accessibility Development Officer
From: [] On
Behalf Of Evans, Donald
Sent: Dienstag, 13. Mai 2008 21:17
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.

SC: I fully agree with this too. Just because the information is read
only, does not mean it is not important.

*	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
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 

SC: I like the idea of announcing rows and columns and it is essential
to state read only on a sheet that is purely read only. However I also
like Donald's idea for a sheet of disabled and non-disabled that the
non-disabled items are also listed. 

*	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.

SC: I agree with Stefan that we have to be precise here what to navigate
how. Moving through items with the tab key would include taking the
focus to the read only area, why would you choose to do this with a
keystroke instead? You might do this with a keystroke as well though
perhaps?  The three of us seem to agree though that the focus needs to
get there somehow in order to read that information. Also not forgetting
screen mag users who are using the keyboard, also benefit very much from
the focus.

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

Yes. Very important.

SC: I agree

The same principle holds true for the grid example. 

SC: Absolutely

*	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 !!!

SC: I hope I am understanding this point correctly. If navigating to the
disabled content is a user preference in the AT, what happens if you are
a keyboard user but not an AT user? Keyboard only users want to get to
that disabled information as well. So there is the issue here for
keyboard non AT users, but as Stefan also mentions relying on a specific
AT vendor which is a good point.


Donald F. Evans

Sr. Program Manager,

Office of Accessibility,


AIM: donaldfevans

Phone 703.265.5952


Click here
RwD5oRfo6kDdZmea!hyiP0Ew1cJCyJu9V!oeaPLWGci2!g==>  to report this email
as spam.


NOTICE: The information contained in this email and any attachments is 
confidential and may be privileged.  If you are not the intended 
recipient you should not use, disclose, distribute or copy any of the 
content of it or of any attachment; you are requested to notify the 
sender immediately of your receipt of the email and then to delete it 
and any attachments from your system.

RNIB endeavours to ensure that emails and any attachments generated by
its staff are free from viruses or other contaminants.  However, it 
cannot accept any responsibility for any  such which are transmitted.
We therefore recommend you scan all attachments.

Please note that the statements and views expressed in this email and 
any attachments are those of the author and do not necessarily represent
those of RNIB.

RNIB Registered Charity Number: 226227


This message has been scanned for viruses by BlackSpider MailControl -

Received on Wednesday, 14 May 2008 14:47:06 UTC