W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2017

(unknown charset) RE: Disabled elements need focus?

From: <accessys@smart.net>
Date: Wed, 15 Feb 2017 23:05:50 -0500 (EST)
To: (unknown charset) Jonathan Avila <jon.avila@ssbbartgroup.com>
cc: (unknown charset) wai-ig list <w3c-wai-ig@w3.org>
Message-ID: <Pine.LNX.4.60.1702152305020.21426@cygnus.smart.net>

remember there are far more OS than windows/mac and at least USA law 
requires OS neutrality


On Thu, 16 Feb 2017, Jonathan Avila wrote:

> Date: Thu, 16 Feb 2017 03:15:22 +0000
> From: Jonathan Avila <jon.avila@ssbbartgroup.com>
> To: wai-ig list <w3c-wai-ig@w3.org>
> Subject: RE: Disabled elements need focus?
> Resent-Date: Thu, 16 Feb 2017 03:16:30 +0000
> Resent-From: w3c-wai-ig@w3.org
> Ø  My point of view is very simple. What occurs in a windows/mac environment with a GUI product? The focus does land on disable items.
> In my many years of using Windows native applications it is my experience that focus generally does not land on disabled controls.  In browsers native HTML elements like button and input are removed from the focus order as well.
> Jonathan
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
> 703.637.8957 (Office)
> Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | LinkedIn<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
> See you at CSUN in March!<http://info.ssbbartgroup.com/CSUN-2017_Sessions.html>
> The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.
> From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com]
> Sent: Wednesday, February 15, 2017 6:56 PM
> To: Rakesh; wai-ig list
> Subject: RE: Disabled elements need focus?
> Hello,
> My point of view is very simple. What occurs in a windows/mac environment with a GUI product? The focus does land on disable items. As already outlined, the screen reader regardless of their method of navigation via the tab/shift tab or using the screen reader shortcut keys for browsing. They should be:
> •        Told it is disabled.
> •        Focus moved to the disable element when using the tab or shift tab.
> Sean Murphy
> From: Rakesh [mailto:prakesh369@gmail.com]
> Sent: Tuesday, 14 February 2017 9:23 PM
> To: wai-ig list <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
> Subject: Disabled elements need focus?
> 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.
> --
> Best Regards
> Rakesh Paladugula
> www.maxability.co.in<http://www.maxability.co.in>
Received on Thursday, 16 February 2017 04:06:26 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 16 February 2017 04:06:27 UTC