WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: Jonathan Cohn
Date: Feb 14, 2017 2:33PM

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