WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: J Isaac
Date: Feb 24, 2017 2:46PM

A question has been tugging at me while I've been reading this thread.

Screen reader users are clearly disadvantaged if disabled elements are not marked up sufficiently, but there seems to be a lot of support in WCAG.

WCAG 2.0 treats disabled elements as incidental in terms of color contrast.

How do you support low vision users that are not covered but may be similarly disadvantaged?

Thanks,
== Joel Isaac
-----Original Message-----
From: WebAIM-Forum [mailto: <EMAIL REMOVED> ] On Behalf Of Rakesh P
Sent: Thursday, February 23, 2017 9:56 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Disabled elements need keyboard focus?

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
> > > > > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > > > >
> > >
> > >
> > > --
> > > 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 *****
> > > > > > > > > archives at http://webaim.org/discussion/archives
> > > > > >
> > > > > > archives at http://webaim.org/discussion/archives
> > > >
>
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer Electronic Business Card
> (vCard) <http://search.vt.edu/search/person.vcf?person54847>
> > > archives at http://webaim.org/discussion/archives
> > > > archives at http://webaim.org/discussion/archives
> >