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
> -----Original Message-----
> From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On
> Behalf Of Robert Fentress
> Sent: Thursday, February 23, 2017 10:46 AM
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] Disabled elements need keyboard focus?
>
> So, is the issue that you are concerned that screen reader users who
> navigate through a form by tabbing might not be aware of the disabled
> affordance?
>
> There are other ways they could discover the existence of the disabled
> buttons. For instance, they could still know they were there by navigating
> using their virtual cursor, right? Then, it would be the responsibility of
> the screen reader to decide how to handle those buttons past that. For
> instance:
>
> - Should the cursor move to the button when you hit the quick key
> combination for buttons?
> - Should it show up in the list of buttons when that is brought up?
> - In that list, should their disabled state be noted, etc.?
>
> Ideally, the screen reader would enable the user to customize how this was
> handled.
>
> Regardless, it strikes me that this is really the responsibility of the
> screen reader and end user to handle appropriately and, unless you have a
> really good reason, you shouldn't override the browser defaults. If it is
> not obvious what could be expected from the context and your audience, you
> could provide instructions in the process that mention that "selected
> options will be disabled" or something like that.
>
> Hopefully, I'm not misunderstanding what you're asking, but that is my two
> cents.
>
> Best,
> Rob
>
> On Tue, Feb 14, 2017 at 4:33 PM, Jonathan Cohn < <EMAIL REMOVED> >
> wrote:
>
> > 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 *****
> > > > > > > > > > > > > > >
> > > > > > > > > >
>
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer
> Electronic Business Card (vCard)
> <http://search.vt.edu/search/person.vcf?person54847>
> > > > > > > > >