WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: Robert Fentress
Date: Feb 23, 2017 9:50AM

P.S. Make sure to share the blog article when you get it done!

On Thu, Feb 23, 2017 at 11:45 AM, Robert Fentress < <EMAIL REMOVED> > wrote:

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



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