E-mail List Archives

Re: Should disabled elements receive tab focus

for

From: Jonathan Cohn
Date: Oct 28, 2016 8:42AM


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
> > > at http://webaim.org/discussion/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.
> > > at http://webaim.org/discussion/archives
> > > > at http://webaim.org/discussion/archives
> > > > > >