[nfbcs] Tabbing to Disabled Web Controls

Fri Apr 5 18:32:36 UTC 2013

Nicole,

There are a lot of "if's" in your note, though, and I don't think you will even get a clear preference from blind people which was 
what I was trying to get at.  Does it make sense to tell developers that either option A or option B is a requirement if we don't 
have a clear idea ourselves which is best?  I, for example, don't like it when a "Next" button does not appear in the tab sequence 
before one checks the "I Agree to whatever the software developer asks" button when installing software.  I'd rather hear the 
"next" button and that it is disabled.  However, if there are whole groups of controls that become inactive, I don't suppose I 
would want to have to tab through them all.  We need that ESP interface.  This is an interesting discussion.

Best regards,

Steve Jacobson

On Thu, 4 Apr 2013 17:49:17 -0700, Nicole Torcolini wrote:

>JMHO, it is not over kill when it is easy to implement and if it makes a
>difference in user satisfaction, especially when you are working with a code
>library for making web controls that has a basic function for disabling
>controls that changes the ARIA hidden attribute and the tabIndex but that is
>perfectly capable of altering the default behavior based on something that
>is easily discernable, such as ARIA role.

>Nicole

>-----Original Message-----
>From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Steve Jacobson
>Sent: Thursday, April 04, 2013 11:03 AM
>To: NFB in Computer Science Mailing List
>Subject: Re: [nfbcs] Tabbing to Disabled Web Controls

>At some point, we have to figure out when we're over-managing.  Does it
>really matter that much if one approach is much more work than another?
>There are so many roadblocks to accessibility, that it seems like overkill
>to me to define accessibility at this level when either approach is
>workable.  This assumes, of course, that disabled controls that are grayed
>out or whatever are identified by the screen reader.  

>Best regards,

>Steve Jacobson

>On Wed, 3 Apr 2013 17:48:21 -0700, Mike Freeman wrote:

>>I agree with David andrews; if you can't activate controls, there's no 
>>reason to be able to tab to them.

>>Mike

>>-----Original Message-----
>>From: nfbcs [mailto:nfbcs-bounces at nfbnet.org] On Behalf Of Jim Barbour
>>Sent: Wednesday, April 03, 2013 5:41 PM
>>To: NFB in Computer Science Mailing List
>>Subject: Re: [nfbcs] Tabbing to Disabled Web Controls

>>Hmmm, I think I'm in the other camp.  I definately think they should be 
>>read as "dimmed", but if users are tabbing around they might want to 
>>know that there is a submit button there, but that you can't activiate it
>yet.

>>Jim

>>On Wed, Apr 03, 2013 at 07:36:47PM -0500, David Andrews wrote:
>>> No, they should just show up as dimmed, and since you can't do 
>>> anything with them you probably shouldn't be able to tab to them.
>>> 
>>> Dave
>>> 
>>> At 09:04 PM 3/31/2013, you wrote:
>>> >The other day, at work, some of us who work on or are interested in 
>>> >web accessibility were discussing whether or not it should be 
>>> >possible to tab to a web control, such as a button or a checkbox, 
>>> >that is disabled. The two scenarios that we discussed are:
>>> >1. There is a web form that has text fields that must be filled in 
>>> >with certain types of information, and the submit button is disabled 
>>> >until the requirements are met.
>>> >2. There is a form with radio buttons. Depending on which radio 
>>> >buttons are checked, certain checkboxes are enabled or disabled.
>>> >I am curious to know what people think of this. Should it be 
>>> >possible to tab to the disabled submit button in the first scenario? 
>>> >The disabled checkboxes in the second scenario? Should there be a 
>>> >standard for different control types--such as button vs. checkbox, 
>>> >or is this something that really should be decided on a case by case
>basis?
>>> >
>>> >Nicole
>>> 
>>> 
>>> _______________________________________________
>>> nfbcs mailing list
>>> nfbcs at nfbnet.org
>>> http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>> To unsubscribe, change your list options or get your account info for
>>nfbcs:
>>> http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/jbar%40barcore.com
>>> 

>>_______________________________________________
>>nfbcs mailing list
>>nfbcs at nfbnet.org
>>http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>To unsubscribe, change your list options or get your account info for
>nfbcs:
>>http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/k7uij%40panix.com

>>_______________________________________________
>>nfbcs mailing list
>>nfbcs at nfbnet.org
>>http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>>To unsubscribe, change your list options or get your account info for
>nfbcs:
>>http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40vis
>>i.com

>_______________________________________________
>nfbcs mailing list
>nfbcs at nfbnet.org
>http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>To unsubscribe, change your list options or get your account info for nfbcs:
>http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/ntorcolini%40wavecable.co
>m

>_______________________________________________
>nfbcs mailing list
>nfbcs at nfbnet.org
>http://nfbnet.org/mailman/listinfo/nfbcs_nfbnet.org
>To unsubscribe, change your list options or get your account info for nfbcs:
>http://nfbnet.org/mailman/options/nfbcs_nfbnet.org/steve.jacobson%40visi.com