Re: Recommendation for Disabled Items

Hi Becky,  While I agree with the principle, I am a bit confused over the 
"interactive" vs "browse" concepts.  I use jaws and voiceover and neither 
use these terms or anything I fully recognize as such.  JAWS is fully 
interactive when there is something to interact with except when typing in 
an edit field in some applications such as ie and firefox.  Voiceover is 
always interactive and browseable and provides information about 
disabled/(dimmed) items in menus and dialogues depending on how the app is 
coded.

I would fully support and emphasize that it is the task of the browser to 
provide quantification of instance information to the user in all cases and 
that this information be passed on to the at in a configurable way in the 
browser so as to avoid tipping the playing field among AT.

----- Original Message ----- 
From: "Becky Gibson" <Becky_Gibson@notesdev.ibm.com>
To: <wai-xtech@w3.org>
Sent: Thursday, May 15, 2008 8:27 AM
Subject: Re: Recommendation for Disabled Items



While I agree with the concept of providing access to disabled items, I
find it more difficult to meet the needs of all users.

Currently browsers do not set focus to disabled form controls when
navigating via the tab key.  The only way an assistive technology user can
discover them is by reviewing the page in "browse" mode rather than
interactive mode.   The fact that disabled controls are removed from the
tab order makes navigation for keyboard users more efficient since there
is no need to stop on a control where interaction is not allowed.

It gets a bit more complicated when the user is interacting with menu
items and toolbar buttons.   The AT user may want to know that a certain
feature is sometimes available so it would be nice is there was a "browse"
mode for these types of interactive components.  Then the screen reader
user could review all parts of the component and understand all of the
options. Currently, a screen reader user must be in "interactive" mode to
work with scripted ARIA components.  The question is does the screen
reader user want to have to navigate to and hear all of the options when
working interactively with a toolbar or menu?  Hearing, "bold - disabled,
italic - disabled, underline-disabled", when the user wants to navigate to
the bulleted list button to create a list can be very tedious. And, we are
adding keystrokes for the keyboard user  who can see which buttons are
disabled.  The same argument can be made for menu items.   I think this is
the issue the DHTML style guide was trying to address with the statement,
"Allowing navigation to the disabled content could be implemented as a
user preference in the AT".

I also do not think that it is the author's responsibility to provide the
actual numbers of disabled items.  This number may change dynamically and,
in my opinion, is not efficient use of JavaScript coding to calculate
this.  I'd be interested in the opinions of AT users.   I also think the
browser could calculate this and provide it to the AT if necessary.

my two cents,
-becky

Becky Gibson
Web Accessibility Architect

IBM Emerging Internet Technologies
5 Technology Park Drive
Westford, MA 01886
Voice: 978 399-6101; t/l 333-6101
Email: gibsonb@us.ibm.com
blog: WebA11y

Received on Thursday, 15 May 2008 13:04:42 UTC