WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: Tim Harshbarger
Date: Feb 23, 2017 2:38PM

Another consideration...

People (with and without disabilities) will be using a computing environment and they will become use to the default behaviours of that environment. So those default or native behaviours become part of the user's expectation of how user interfaces work. There might be situations that warrant overriding the default behavior, but those should be rare. I would actually only want to override those behaviours if I had some solid data that users were having trouble with that particular interaction--most likely data from a usability test.

Honestly, most of the time accessibility experts don't have direct access to things like usability tests to make informed decisions--so we have to make decisions or suggestions based on what we know or think we know. That means it is fairly easy to assume users will have problems when they won't or that they will have no problems when they will. Logic used to build a theoretical idea of what problems users will experience should be carefully considered.

We shouldn't avoid doing this--because it is sometimes all we have available to base our guidance on--but we should be mindful of its pro's and con's.

Thanks,
Tim
-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Robert Fentress
Sent: Thursday, February 23, 2017 10:46 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Disabled elements need keyboard focus?

So, is the issue that you are concerned that screen reader users who
navigate through a form by tabbing might not be aware of the disabled
affordance?

There are other ways they could discover the existence of the disabled
buttons. For instance, they could still know they were there by navigating
using their virtual cursor, right? Then, it would be the responsibility of
the screen reader to decide how to handle those buttons past that. For
instance:

- Should the cursor move to the button when you hit the quick key
combination for buttons?
- Should it show up in the list of buttons when that is brought up?
- In that list, should their disabled state be noted, etc.?

Ideally, the screen reader would enable the user to customize how this was
handled.

Regardless, it strikes me that this is really the responsibility of the
screen reader and end user to handle appropriately and, unless you have a
really good reason, you shouldn't override the browser defaults. If it is
not obvious what could be expected from the context and your audience, you
could provide instructions in the process that mention that "selected
options will be disabled" or something like that.

Hopefully, I'm not misunderstanding what you're asking, but that is my two
cents.

Best,
Rob

On Tue, Feb 14, 2017 at 4:33 PM, Jonathan Cohn < <EMAIL REMOVED> > wrote:

> I personally would not want to override the Browser / Operating System
> defaults on tab behavior with disabled items in most cases. There are
> certainly times where I would take exception to this.
>
> 1. In frequently used panes, where a specific button early in the tab
> order is disabled. Tab based navigators will be used to quickly hitting the
> tab key a specific number of times. Spell check dialogs come to mind
> immediately.
> 2. The disabled element provides hints of functionality not easily
> recognized. Your third example might be a case in point.
>
> I am a bit surprised that most of the answers so far have suggested
> overriding the Mac / Windows defaults of skipping disabled active elements
> when using the tab key.
>
> Best Wishes,
>
> Jonathan Cohn
>
>
> On Tue, Feb 14, 2017 at 5:41 AM shankar shan < <EMAIL REMOVED> >
> wrote:
>
> > If disabled buttons are not focusable with TAB, the user would think
> > that, that the button ever exists, and they will never find it.
> > this is my opinion, other experts may comment below.
> >
> >
> > On 2/14/17, Rakesh P < <EMAIL REMOVED> > wrote:
> > > Dear a11y specialists,
> > >
> > > Few of our friends are having different opinions on providing tab focus
> > for
> > > disabled buttons and links. When a disabled attribute is used keyboard
> > > focus is not observed on buttons and links in some browsers. Is it the
> > > expected behavior? One set of people argue that screen reader user will
> > > never know that the element exist if the focus is not provided. The
> other
> > > set of people argue that providing tab focus to disabled elements cause
> > > additional frustration especially in a process where time is a major
> > > factor. I have provide some situations where the disabled attributes
> can
> > be
> > > observed in general. Any thoughts on the topic is highly appreciated.
> > >
> > > a. Seats that are already booked in a seat selection widget: If
> keyboard
> > > focus is provided for booked seats, user should focus to all
> unavailable
> > > seats. In many websites booking process should complete in 15 minutes.
> > > Providing keyboard focus for non interactive elements will result in
> > > delaying the ticket booking process for keyboard only users and screen
> > > reader users.
> > > b. In a calendar widget for selecting a birthday, all the future dates
> > need
> > > to be in disabled state. Do they need tab focus. Similarly for booking
> a
> > > ticket previous dates will be disabled.
> > > c. Future links in a progressbar: In a checkout process, current step
> > will
> > > be active and the future steps are non-interactive until reaches that
> > step.
> > > Is it required for the user to navigate and check the steps with tab
> key
> > or
> > > making them non-focusable is fine.
> > >
> > > I would like to get your thoughts and publish a blog article.
> > > Thanks for your help in advance.
> > >
> > >
> > > Thanks & Regards
> > > Rakesh
> > > > > > > > > > > > > > >
> >
> >
> > --
> > jammed and internet hanged?Reach through the following means:
> > mobile: +91 9599194749 <+91%2095991%2094749>
> > whats app: +91 7795927572 <+91%2077959%2027572>
> > skype: Shankar.a
> > email: <EMAIL REMOVED>
> > Thanks and regards
> > Shankar
> > *****ACCESSIBILITY AND USABILITY TESTER AT HCL TECHNOLOGIES *****
> > > > > > > > > >
> > > > >



--
Rob Fentress
Senior Accessibility Solutions Designer
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>