E-mail List Archives
Re: Disabled elements need keyboard focus?
From: shankar shan
Date: Feb 14, 2017 3:41AM
- Next message: Juliette: "accessible electronic signature"
- Previous message: Karl Brown: "Re: Dealing with Facebook's problematic automatic alt text generation (and other issues)"
- Next message in Thread: Jonathan Cohn: "Re: Disabled elements need keyboard focus?"
- Previous message in Thread: Rakesh P: "Disabled elements need keyboard focus?"
- View all messages in this Thread
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
whats app: +91 7795927572
skype: Shankar.a
email: <EMAIL REMOVED>
Thanks and regards
Shankar
*****ACCESSIBILITY AND USABILITY TESTER AT HCL TECHNOLOGIES *****
- Next message: Juliette: "accessible electronic signature"
- Previous message: Karl Brown: "Re: Dealing with Facebook's problematic automatic alt text generation (and other issues)"
- Next message in Thread: Jonathan Cohn: "Re: Disabled elements need keyboard focus?"
- Previous message in Thread: Rakesh P: "Disabled elements need keyboard focus?"
- View all messages in this Thread