WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: Rakesh P
Date: Feb 23, 2017 10:56PM


Sure Rob, I will share the article.

I agree with you to the point that developers should not overwrite browser
behavior or what spec says. At the same time depending on the context in
which we use the elements may sometimes miss important information to the
user. So in such context I believe developers can go to that extra mile to
make content accessible.
Eg: In a progress bar where future steps will be in disabled mode, If these
disabled items do not receive keyboard focus, screen reader users may miss
important information before they get to start filling the multi-step
process application. Giving focus to these disabled elements help users in
taking the decisions such as, Do I have all the information available with
me to start filling the application? Do I have enough time now to submit
the form ? etc.
I agree users will have option to navigate the disabled elements by screen
reader short-cut commands such as b for button or to navigate with arrow
keys but form elements and links should be primarily navigable with tab key
of the keyboard.


On Fri, Feb 24, 2017 at 3:08 AM, Tim Harshbarger <
<EMAIL REMOVED> > wrote:

> Another consideration...
>
> People (with and without disabilities) will be using a computing
> environment and they will become use to the default behaviours of that
> environment. So those default or native behaviours become part of the
> user's expectation of how user interfaces work. There might be situations
> that warrant overriding the default behavior, but those should be rare. I
> would actually only want to override those behaviours if I had some solid
> data that users were having trouble with that particular interaction--most
> likely data from a usability test.
>
> Honestly, most of the time accessibility experts don't have direct access
> to things like usability tests to make informed decisions--so we have to
> make decisions or suggestions based on what we know or think we know. That
> means it is fairly easy to assume users will have problems when they won't
> or that they will have no problems when they will. Logic used to build a
> theoretical idea of what problems users will experience should be carefully
> considered.
>
> We shouldn't avoid doing this--because it is sometimes all we have
> available to base our guidance on--but we should be mindful of its pro's
> and con's.
>
> Thanks,
> Tim
>