WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Should disabled elements receive tab focus

for

From: Moore,Michael (Accessibility) (HHSC)
Date: Oct 28, 2016 8:46AM


Why not just hide the second combo box from everyone until the first combo box is filled out. It's pretty much just visual clutter until then anyway.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Jonathan Cohn
Sent: Friday, October 28, 2016 9:42 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Should disabled elements receive tab focus

So in the situation where there are two combo-boxes and a submit button on a page, and the second combo box has no choices until the first combo box has a selection made would you want that second combo to be in the tab order? We were talking about adding a aria-disabled to the second combo box until there are choices in the it, would make more sense to mark it completely disabled?

On 28 October 2016 at 10:24, Jonathan Avila < <EMAIL REMOVED> >
wrote:

> > How does keeping non-actionable controls out of the tab order
> > present a
> more accurate description of the interface in its present state?
>
> There are a few instances where it could be useful. For example, if I
> have 5 checkboxes but one of the 5 checkbox is disabled until I change
> something in the form and I am a screen reader user who happens to be
> using tab to navigate through the form I could wind up in a situation where I
> wasn't aware of the 5th checkboxes existence. Yes, screen reader users
> could go looking for it and yes generally non-interactive items
> shouldn't be in the tab order -- but asking a person to review the form in browse
> mode when tab otherwise might be used could trip up some people. I'm not
> advocating for putting a lot of things in the focus order -- I agree
> it's an issue -- but there are some situations where it could be helpful.
>
> A similar problem is with the exception of disabled controls not
> needing to meet contrast requirements. I understand the desire to
> make the control look disabled by changing the contrast. However,
> some disabled controls are not readable to people with low vision do
> to contrast. So the low vision user is forced to try and figure out
> what in the form is needed to make that disabled control enabled so
> they can read it only to find out it wasn't something they wanted
> anyway. If the control is on-screen it should be readable with a
> minimum level of contrast by all users so they can make the determination of what to do or not do in the form.
>
> Jonathan
>
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> <EMAIL REMOVED>
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog Check
> out our Digital Accessibility Webinars!
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Moore,Michael (Accessibility) (HHSC)
> Sent: Friday, October 28, 2016 10:14 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Should disabled elements receive tab focus
>
> How does keeping non-actionable controls out of the tab order present
> a more accurate description of the interface in its present state? If
> I can tab to something then the assumption is that I can do something
> with it. If I am reading through the interface I can see all of the
> disabled controls and all of the static/informational content and I
> can also discover all of the actionable controls. I believe that the
> reasoning that we have to have non-actionable controls in the tab-ring
> comes from a fundamental misunderstanding of how screen reading
> software functions. Far too often I have seen test scripts that call
> for the tester to fail anything that cannot be discovered by tabbing.
> This usually results in everything getting a tab-index of 0 and a nightmare to use or remediate.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission Civil Rights Office
> (512) 438-3431 (Office)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Thomas Lee McKeithan II
> Sent: Thursday, October 27, 2016 6:08 PM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Should disabled elements receive tab focus
>
> I differ. I believe that disabled buttons/controls should be in the
> tab order providing the user an accurate representation of what's
> presented on the page visually.
>
>
> Respectfully,
> Thomas Lee McKeithan II | Optum Technology Solutions Electronic
> Accessibility Engineer, UX Design Studio (UXDS) MD018, 6220 Old Dobbin
> Lane, Columbia, MD, 21045, USA
>
> T +1 443-896-0432
> M +1 202-276-6437
> <EMAIL REMOVED>
> www.optum.com
>
>
>
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Moore,Michael (Accessibility) (HHSC)
> Sent: Thursday, October 27, 2016 12:43 PM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Should disabled elements receive tab focus
>
> If the button is disabled then it should not be included in the tab ring.
> Screen reader users can find the button using standard reading controls.
> Just make sure that it is in the proper location in the reading order
> for the page.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission Civil Rights Office
> (512) 438-3431 (Office)
>
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Ajay Sharma
> Sent: Thursday, October 27, 2016 11:39 AM
> To: <EMAIL REMOVED>
> Subject: [WebAIM] Should disabled elements receive tab focus
>
> Hello and Greetings,
>
>
> Looking for some expert advice on the case where it is desired by the
> screen reader users that tab focus should go on disabled button and
> screen reader should announce it's name, role and state which is
> disabled. But doing so would affect the usability of keyboard only
> users as the tab focus would land on non interactive element.
> There are certain instances where the disabled control gets tab focus
> both in the case of web and desktop applications, but there is no spec
> or guideline that directly address to this issue.
>
> So, please share your thoughts on it and I'd greatly appreciate if
> there is some specs are already there.
>
> Best Regards,
> Ajay
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >
> This e-mail, including attachments, may include confidential and/or
> proprietary information, and may be used only by the person or entity
> to which it is addressed. If the reader of this e-mail is not the
> intended recipient or his or her authorized agent, the reader is
> hereby notified that any dissemination, distribution or copying of
> this e-mail is prohibited. If you have received this e-mail in error,
> please notify the sender by replying to this message and delete this e-mail immediately.
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >