E-mail List Archives

Re: Should disabled elements receive tab focus

for

From: Mallory
Date: Oct 28, 2016 3:50PM


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

This would be a case where designers, developers, info architects ought
to be coming up with better ways of getting necessary information to the
user. Or, if the necessary info is only in a faint disabled control,
that means something to fix.

Though yeah, we often don't have the above luxury :)


On Fri, Oct 28, 2016, at 06:42 PM, Sailesh Panchang wrote:
> Designers / developers need to review when it makes sense to include
> disabled controls in the UI. For instance in the page navigation
> links, the 'Next' button can be disabled and yet be rendered visually
> when the last page is in view. It becomes conspicuous by being absent
> in the tab order then!
> On the other hand dependent controls generally should be hidden if
> they are disabled. It makes for a cleaner uncluttered UI for everyone.
> Please review
> http://www.mindoversight.com/csun/2016/Overview.html
> and example for poor design- disabled controls.
> Thanks,
> Sailesh
>
>
> On 10/28/16, Jonathan Avila < <EMAIL REMOVED> > wrote:
> >> 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?
> >
> > I'd say it is best practice to advise the user that changing something in a
> > control will affect/change or add content later/further in the document.
> >
> > 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 Jonathan Cohn
> > Sent: Friday, October 28, 2016 10:42 AM
> > To: WebAIM Discussion List
> > 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
> >> > >>
> > > > > > http://webaim.org/discussion/archives
> > > > > > > > > > > >
> > > >