E-mail List Archives
Thread: Disabled elements need keyboard focus?
Number of posts in this thread: 9 (In chronological order)
From: Rakesh P
Date: Tue, Feb 14 2017 3:25AM
Subject: Disabled elements need keyboard focus?
No previous message | Next message →
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
From: shankar shan
Date: Tue, Feb 14 2017 3:41AM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> > > > >
--
jammed and internet hanged?Reach through the following means:
mobile: +91 9599194749
whats app: +91 7795927572
skype: Shankar.a
email: = EMAIL ADDRESS REMOVED =
Thanks and regards
Shankar
*****ACCESSIBILITY AND USABILITY TESTER AT HCL TECHNOLOGIES *****
From: Jonathan Cohn
Date: Tue, Feb 14 2017 2:33PM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> > > > > > > > > >
>
>
> --
> 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 *****
> > > > >
From: Robert Fentress
Date: Thu, Feb 23 2017 9:45AM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> > > > > > > > > > > > > > >
> >
> >
> > --
> > 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 *****
> > > > > > > > > >
> > > > >
--
Rob Fentress
Senior Accessibility Solutions Designer
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
From: Robert Fentress
Date: Thu, Feb 23 2017 9:50AM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
P.S. Make sure to share the blog article when you get it done!
On Thu, Feb 23, 2017 at 11:45 AM, Robert Fentress < = EMAIL ADDRESS REMOVED = > wrote:
> 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
>> > > >> > > >> > > >> > > >> > >
>> >
>> >
>> > --
>> > 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 *****
>> > >> > >> > >> > >> >
>> >> >> >> >>
>
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer
> Electronic Business Card (vCard)
> <http://search.vt.edu/search/person.vcf?person54847>
>
--
Rob Fentress
Senior Accessibility Solutions Designer
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
From: Tim Harshbarger
Date: Thu, Feb 23 2017 2:38PM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> > > > > > > > > > > > > > >
> >
> >
> > --
> > 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 *****
> > > > > > > > > >
> > > > >
--
Rob Fentress
Senior Accessibility Solutions Designer
Electronic Business Card (vCard)
<http://search.vt.edu/search/person.vcf?person54847>
From: Rakesh P
Date: Thu, Feb 23 2017 10:56PM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> > > > > > > > > > > > > > > > > > > >
> > >
> > >
> > > --
> > > 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 *****
> > > > > > > > > > > > > > >
> > > > > > > > > >
>
>
>
> --
> Rob Fentress
> Senior Accessibility Solutions Designer
> Electronic Business Card (vCard)
> <http://search.vt.edu/search/person.vcf?person54847>
> > > > > > > > >
From: J Isaac
Date: Fri, Feb 24 2017 2:46PM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | Next message →
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
> >
From: Rakesh P
Date: Sat, Feb 25 2017 6:23AM
Subject: Re: Disabled elements need keyboard focus?
← Previous message | No next message
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 < 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 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
> >
>
> > > > >