WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Disabled elements need keyboard focus?

for

From: Rakesh P
Date: Feb 25, 2017 6:23AM

Yes Joel, I agree with you. I hope this will be raised in LV Task Force and
addressed in WCAG 2.1 or WCAG 3.0

On Sat, Feb 25, 2017 at 3:16 AM, J Isaac < <EMAIL REMOVED> > wrote:

> 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 < tim.harshbarger.cqwg@
> statefarm.com> 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
> > > >
> > > at http://webaim.org/discussion/archives
> >
>
> > > > >