E-mail List Archives
Thread: Disabled elements need keyboard focus?
Number of posts in this thread: 1 (In chronological order)
From: Rakesh P
Date: Sun, Mar 12 2017 10:47PM
Subject: Disabled elements need keyboard focus?
No previous message | No next message
All,
Thanks for your inputs. Finally I am able to publish the article on
Keyboard interaction for disabled elements. Here is the blog post.
http://www.maxability.co.in/2017/03/keyboard-interaction-for-disabled-elements/
On Sat, Feb 25, 2017 at 6:53 PM, Rakesh P < = EMAIL ADDRESS REMOVED = >
wrote:
> 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 ADDRESS 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 ADDRESS REMOVED = ] On
>> Behalf Of Rakesh P
>> Sent: Thursday, February 23, 2017 9:56 PM
>> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS REMOVED = ] On
>> > Behalf Of Robert Fentress
>> > Sent: Thursday, February 23, 2017 10:46 AM
>> > To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS 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
>> >>
>>
>> >> >> >> >>
>
>