RE: Disabled elements need focus?

Ø  Your right, I just double checked. I was thinking of menus. My error. Menus indicate if the item is disabled.

That is a good point. Not sure why menus differ from focus order in that behavior.  Perhaps related to macros being used to activate menu items and they wanted a consistent number of key presses?

Jonathan


From: Sean Murphy (seanmmur) [mailto:seanmmur@cisco.com]
Sent: Wednesday, February 15, 2017 10:29 PM
To: Jonathan Avila; wai-ig list
Subject: RE: Disabled elements need focus?

Jonathan


Your right, I just double checked. I was thinking of menus. My error. Menus indicate if the item is disabled.

Sean Murphy
Accessibility Software engineer
seanmmur@cisco.com<mailto:seanmmur@cisco.com>
Tel: +61 2 8446 7751       Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com

 Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Thursday, 16 February 2017 2:15 PM
To: wai-ig list <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: RE: Disabled elements need focus?


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