E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 17 (In chronological order)

From: Ajay Sharma
Date: Thu, Oct 27 2016 10:39AM
Subject: Should disabled elements receive tab focus
No previous message | Next message →

Hello and Greetings,


Looking for some expert advice on the case where it is desired by the
screen reader users that tab focus should go on disabled button and
screen reader should announce it's name, role and state which is
disabled. But doing so would affect the usability of keyboard only
users as the tab focus would land on non interactive element.
There are certain instances where the disabled control gets tab focus
both in the case of web and desktop applications, but there is no spec
or guideline that directly address to this issue.

So, please share your thoughts on it and I'd greatly appreciate if
there is some specs are already there.

Best Regards,
Ajay

From: Moore,Michael (Accessibility) (HHSC)
Date: Thu, Oct 27 2016 10:43AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

If the button is disabled then it should not be included in the tab ring. Screen reader users can find the button using standard reading controls. Just make sure that it is in the proper location in the reading order for the page.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Thomas Lee McKeithan II
Date: Thu, Oct 27 2016 5:08PM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

I differ. I believe that disabled buttons/controls should be in the tab order providing the user an accurate representation of what's presented on the page visually.


Respectfully,
Thomas Lee McKeithan II | Optum Technology Solutions
Electronic Accessibility Engineer, UX Design Studio (UXDS)
MD018, 6220 Old Dobbin Lane, Columbia, MD, 21045, USA

T +1 443-896-0432
M +1 202-276-6437
= EMAIL ADDRESS REMOVED =
www.optum.com
 

From: Mallory
Date: Fri, Oct 28 2016 3:07AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

Disabled controls are not in the tab list. Someone suddenly breaking
that pattern in one
place would be extremely confusing. If I can focus on it, it should Do
Stuff for me. If you
let me focus on it, then it had better well Do Something when I click
it.

That some users choose to use tab for everything is not a good reason to
make breaking
changes. I know users who only use a mouse to click each form field; by
the above logic,
it would be a good thing to use auto-focus to save them some trouble.
And of course that
is a bad idea for many reasons.

Readonlys, on the other hand, while not editable, do live in the tab
list (because I can
still for example select and copy that text).

_mallory

On Fri, Oct 28, 2016, at 01:08 AM, Thomas Lee McKeithan II wrote:
> I differ. I believe that disabled buttons/controls should be in the tab
> order providing the user an accurate representation of what's presented
> on the page visually.
>
>
> Respectfully,
> Thomas Lee McKeithan II | Optum Technology Solutions
> Electronic Accessibility Engineer, UX Design Studio (UXDS)
> MD018, 6220 Old Dobbin Lane, Columbia, MD, 21045, USA
>
> T +1 443-896-0432
> M +1 202-276-6437
> = EMAIL ADDRESS REMOVED =
> www.optum.com
>  
>
>
>
>

From: Steve Faulkner
Date: Fri, Oct 28 2016 3:23AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

native HTML interactive elements are implemented to not be focusable when
the disabled fattribute is set.

Adding tabindex="0" to a disabled button (for example) does not include it
in the focus order (because it is disabled).

suggest following platform interaction conventions is the right thing to
do.

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 28 October 2016 at 10:07, Mallory < = EMAIL ADDRESS REMOVED = > wrote:

> Disabled controls are not in the tab list. Someone suddenly breaking
> that pattern in one
> place would be extremely confusing. If I can focus on it, it should Do
> Stuff for me. If you
> let me focus on it, then it had better well Do Something when I click
> it.
>
> That some users choose to use tab for everything is not a good reason to
> make breaking
> changes. I know users who only use a mouse to click each form field; by
> the above logic,
> it would be a good thing to use auto-focus to save them some trouble.
> And of course that
> is a bad idea for many reasons.
>
> Readonlys, on the other hand, while not editable, do live in the tab
> list (because I can
> still for example select and copy that text).
>
> _mallory
>
> On Fri, Oct 28, 2016, at 01:08 AM, Thomas Lee McKeithan II wrote:
> > I differ. I believe that disabled buttons/controls should be in the tab
> > order providing the user an accurate representation of what's presented
> > on the page visually.
> >
> >
> > Respectfully,
> > Thomas Lee McKeithan II | Optum Technology Solutions
> > Electronic Accessibility Engineer, UX Design Studio (UXDS)
> > MD018, 6220 Old Dobbin Lane, Columbia, MD, 21045, USA
> >
> > T +1 443-896-0432
> > M +1 202-276-6437
> > = EMAIL ADDRESS REMOVED =
> > www.optum.com
> >
> >
> >
> >
> >

From: Steve Faulkner
Date: Fri, Oct 28 2016 3:29AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

On 28 October 2016 at 10:23, Steve Faulkner < = EMAIL ADDRESS REMOVED = >
wrote:

> Adding tabindex="0" to a disabled button (for example) does not include it
> in the focus order (because it is disabled).


here is a code demo (button 2 is disabled and has tabindex="0"
http://s.codepen.io/stevef/debug/dpEdQp
--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Jared Smith
Date: Fri, Oct 28 2016 8:14AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

You can use aria-disabled on the control instead and a screen reader
user would be informed that the control is disabled - though it
wouldn't actually be disabled unless you use scripting to render it
unusable.

Sometimes developers want a disabled control to be navigable because
the disabled state is used to indicate something else about the form -
such as a disabled button indicating that there is a form validation
issue. This pattern can be rather confusing to everyone and there are
certainly better ways to provide error feedback.

Jared

From: Moore,Michael (Accessibility) (HHSC)
Date: Fri, Oct 28 2016 8:14AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

How does keeping non-actionable controls out of the tab order present a more accurate description of the interface in its present state? If I can tab to something then the assumption is that I can do something with it. If I am reading through the interface I can see all of the disabled controls and all of the static/informational content and I can also discover all of the actionable controls. I believe that the reasoning that we have to have non-actionable controls in the tab-ring comes from a fundamental misunderstanding of how screen reading software functions. Far too often I have seen test scripts that call for the tester to fail anything that cannot be discovered by tabbing. This usually results in everything getting a tab-index of 0 and a nightmare to use or remediate.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Steve Faulkner
Date: Fri, Oct 28 2016 8:15AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

On 28 October 2016 at 15:14, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> Far too often I have seen test scripts that call for the tester to fail
> anything that cannot be discovered by tabbing. This usually results in
> everything getting a tab-index of 0 and a nightmare to use or remediate.


Bingo

--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Jonathan Avila
Date: Fri, Oct 28 2016 8:24AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

> How does keeping non-actionable controls out of the tab order present a more accurate description of the interface in its present state?

There are a few instances where it could be useful. For example, if I have 5 checkboxes but one of the 5 checkbox is disabled until I change something in the form and I am a screen reader user who happens to be using tab to navigate through the form I could wind up in a situation where I wasn't aware of the 5th checkboxes existence. Yes, screen reader users could go looking for it and yes generally non-interactive items shouldn't be in the tab order -- but asking a person to review the form in browse mode when tab otherwise might be used could trip up some people. I'm not advocating for putting a lot of things in the focus order -- I agree it's an issue -- but there are some situations where it could be helpful.

A similar problem is with the exception of disabled controls not needing to meet contrast requirements. I understand the desire to make the control look disabled by changing the contrast. However, some disabled controls are not readable to people with low vision do to contrast. So the low vision user is forced to try and figure out what in the form is needed to make that disabled control enabled so they can read it only to find out it wasn't something they wanted anyway. If the control is on-screen it should be readable with a minimum level of contrast by all users so they can make the determination of what to do or not do in the form.

Jonathan


Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

From: Jonathan Cohn
Date: Fri, Oct 28 2016 8:42AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

So in the situation where there are two combo-boxes and a submit button on
a page, and the second combo box has no choices until the first combo box
has a selection made would you want that second combo to be in the tab
order? We were talking about adding a aria-disabled to the second combo box
until there are choices in the it, would make more sense to mark it
completely disabled?

On 28 October 2016 at 10:24, Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> > How does keeping non-actionable controls out of the tab order present a
> more accurate description of the interface in its present state?
>
> There are a few instances where it could be useful. For example, if I
> have 5 checkboxes but one of the 5 checkbox is disabled until I change
> something in the form and I am a screen reader user who happens to be using
> tab to navigate through the form I could wind up in a situation where I
> wasn't aware of the 5th checkboxes existence. Yes, screen reader users
> could go looking for it and yes generally non-interactive items shouldn't
> be in the tab order -- but asking a person to review the form in browse
> mode when tab otherwise might be used could trip up some people. I'm not
> advocating for putting a lot of things in the focus order -- I agree it's
> an issue -- but there are some situations where it could be helpful.
>
> A similar problem is with the exception of disabled controls not needing
> to meet contrast requirements. I understand the desire to make the control
> look disabled by changing the contrast. However, some disabled controls
> are not readable to people with low vision do to contrast. So the low
> vision user is forced to try and figure out what in the form is needed to
> make that disabled control enabled so they can read it only to find out it
> wasn't something they wanted anyway. If the control is on-screen it should
> be readable with a minimum level of contrast by all users so they can make
> the determination of what to do or not do in the form.
>
> Jonathan
>
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> Check out our Digital Accessibility Webinars!
>
>
>

From: Moore,Michael (Accessibility) (HHSC)
Date: Fri, Oct 28 2016 8:46AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

Why not just hide the second combo box from everyone until the first combo box is filled out. It's pretty much just visual clutter until then anyway.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Jonathan Avila
Date: Fri, Oct 28 2016 9:43AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

> So in the situation where there are two combo-boxes and a submit button on a page, and the second combo box has no choices until the first combo box has a selection made would you want that second combo to be in the tab order? We were talking about adding a aria-disabled to the second combo box until there are choices in the it, would make more sense to mark it completely disabled?

I'd say it is best practice to advise the user that changing something in a control will affect/change or add content later/further in the document.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group 
= EMAIL ADDRESS REMOVED =
703.637.8957 (Office)

Visit us online: Website | Twitter | Facebook | Linkedin | Blog
Check out our Digital Accessibility Webinars!

From: Sailesh Panchang
Date: Fri, Oct 28 2016 10:42AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

Designers / developers need to review when it makes sense to include
disabled controls in the UI. For instance in the page navigation
links, the 'Next' button can be disabled and yet be rendered visually
when the last page is in view. It becomes conspicuous by being absent
in the tab order then!
On the other hand dependent controls generally should be hidden if
they are disabled. It makes for a cleaner uncluttered UI for everyone.
Please review
http://www.mindoversight.com/csun/2016/Overview.html
and example for poor design- disabled controls.
Thanks,
Sailesh


On 10/28/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> So in the situation where there are two combo-boxes and a submit button on
>> a page, and the second combo box has no choices until the first combo box
>> has a selection made would you want that second combo to be in the tab
>> order? We were talking about adding a aria-disabled to the second combo
>> box until there are choices in the it, would make more sense to mark it
>> completely disabled?
>
> I'd say it is best practice to advise the user that changing something in a
> control will affect/change or add content later/further in the document.
>
> Jonathan
>
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
> 703.637.8957 (Office)
>
> Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> Check out our Digital Accessibility Webinars!
>
>
>

From: Mallory
Date: Fri, Oct 28 2016 3:50PM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

" So the low vision user is forced to try and figure out what in the
form is needed to make that disabled control enabled so they can read it
only to find out it wasn't something they wanted anyway."

This would be a case where designers, developers, info architects ought
to be coming up with better ways of getting necessary information to the
user. Or, if the necessary info is only in a faint disabled control,
that means something to fix.

Though yeah, we often don't have the above luxury :)


On Fri, Oct 28, 2016, at 06:42 PM, Sailesh Panchang wrote:
> Designers / developers need to review when it makes sense to include
> disabled controls in the UI. For instance in the page navigation
> links, the 'Next' button can be disabled and yet be rendered visually
> when the last page is in view. It becomes conspicuous by being absent
> in the tab order then!
> On the other hand dependent controls generally should be hidden if
> they are disabled. It makes for a cleaner uncluttered UI for everyone.
> Please review
> http://www.mindoversight.com/csun/2016/Overview.html
> and example for poor design- disabled controls.
> Thanks,
> Sailesh
>
>
> On 10/28/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
> >> So in the situation where there are two combo-boxes and a submit button on
> >> a page, and the second combo box has no choices until the first combo box
> >> has a selection made would you want that second combo to be in the tab
> >> order? We were talking about adding a aria-disabled to the second combo
> >> box until there are choices in the it, would make more sense to mark it
> >> completely disabled?
> >
> > I'd say it is best practice to advise the user that changing something in a
> > control will affect/change or add content later/further in the document.
> >
> > Jonathan
> >
> > Jonathan Avila
> > Chief Accessibility Officer
> > SSB BART Group
> > = EMAIL ADDRESS REMOVED =
> > 703.637.8957 (Office)
> >
> > Visit us online: Website | Twitter | Facebook | Linkedin | Blog
> > Check out our Digital Accessibility Webinars!
> >
> >
> >

From: Ajay Sharma
Date: Tue, Nov 01 2016 10:02AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | Next message →

Hello, a sin sear thanks to all for sharing your views, this has
certainly helped in understanding the impact of disabled elements in
variety of scenarios.

Also, recently came across few instances e.g. MS Office online, where
tab focus goes on disabled elements such as undo, redo, copy paste
etc, which are disabled by default in a new document, and same is the
case with native desktop apps.

So, came up with following conclusion,

1.Disabled interactive control should not be in tab order, except for
some complex applications / scenarios, where it's certainn that
keeping that particular element out of the tab order would confuse the
AT user.
2.Disabling the submit button on the forms should be avoided to handle
errors / validations.
3. In case of desktop apps, disabled elements should be focusable as
here it's not as easy to navigate with reading keys as in web with
browse mode.

Please let me know if above assumptions are good enough to build an
accessibility policy for a product.

Best Regards,
Ajay

On 10/29/16, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
> " So the low vision user is forced to try and figure out what in the
> form is needed to make that disabled control enabled so they can read it
> only to find out it wasn't something they wanted anyway."
>
> This would be a case where designers, developers, info architects ought
> to be coming up with better ways of getting necessary information to the
> user. Or, if the necessary info is only in a faint disabled control,
> that means something to fix.
>
> Though yeah, we often don't have the above luxury :)
>
>
> On Fri, Oct 28, 2016, at 06:42 PM, Sailesh Panchang wrote:
>> Designers / developers need to review when it makes sense to include
>> disabled controls in the UI. For instance in the page navigation
>> links, the 'Next' button can be disabled and yet be rendered visually
>> when the last page is in view. It becomes conspicuous by being absent
>> in the tab order then!
>> On the other hand dependent controls generally should be hidden if
>> they are disabled. It makes for a cleaner uncluttered UI for everyone.
>> Please review
>> http://www.mindoversight.com/csun/2016/Overview.html
>> and example for poor design- disabled controls.
>> Thanks,
>> Sailesh
>>
>>
>> On 10/28/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> >> So in the situation where there are two combo-boxes and a submit button
>> >> on
>> >> a page, and the second combo box has no choices until the first combo
>> >> box
>> >> has a selection made would you want that second combo to be in the tab
>> >> order? We were talking about adding a aria-disabled to the second combo
>> >> box until there are choices in the it, would make more sense to mark it
>> >> completely disabled?
>> >
>> > I'd say it is best practice to advise the user that changing something
>> > in a
>> > control will affect/change or add content later/further in the document.
>> >
>> > Jonathan
>> >
>> > Jonathan Avila
>> > Chief Accessibility Officer
>> > SSB BART Group
>> > = EMAIL ADDRESS REMOVED =
>> > 703.637.8957 (Office)
>> >
>> > Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>> > Check out our Digital Accessibility Webinars!
>> >
>> >
>> >

From: Birkir R. Gunnarsson
Date: Tue, Nov 01 2016 10:09AM
Subject: Re: Should disabled elements receive tab focus
← Previous message | No next message

I think it is good.
I would add something along the lines of:"Don't override focusable
behavior resulting from use of the html disabled attribute.
If it is necessary to keep a disabled lement in the focus order, use
aria-disabled="true" to indicate its disabled state to assistive
technologies, CSS to vidually indicate the disabled state of the
element, and Javascript to ensure that the element is truly disabled
for all users (mouse and keyboard).
-B


On 11/1/16, Ajay Sharma < = EMAIL ADDRESS REMOVED = > wrote:
> Hello, a sin sear thanks to all for sharing your views, this has
> certainly helped in understanding the impact of disabled elements in
> variety of scenarios.
>
> Also, recently came across few instances e.g. MS Office online, where
> tab focus goes on disabled elements such as undo, redo, copy paste
> etc, which are disabled by default in a new document, and same is the
> case with native desktop apps.
>
> So, came up with following conclusion,
>
> 1.Disabled interactive control should not be in tab order, except for
> some complex applications / scenarios, where it's certainn that
> keeping that particular element out of the tab order would confuse the
> AT user.
> 2.Disabling the submit button on the forms should be avoided to handle
> errors / validations.
> 3. In case of desktop apps, disabled elements should be focusable as
> here it's not as easy to navigate with reading keys as in web with
> browse mode.
>
> Please let me know if above assumptions are good enough to build an
> accessibility policy for a product.
>
> Best Regards,
> Ajay
>
> On 10/29/16, Mallory < = EMAIL ADDRESS REMOVED = > wrote:
>> " So the low vision user is forced to try and figure out what in the
>> form is needed to make that disabled control enabled so they can read it
>> only to find out it wasn't something they wanted anyway."
>>
>> This would be a case where designers, developers, info architects ought
>> to be coming up with better ways of getting necessary information to the
>> user. Or, if the necessary info is only in a faint disabled control,
>> that means something to fix.
>>
>> Though yeah, we often don't have the above luxury :)
>>
>>
>> On Fri, Oct 28, 2016, at 06:42 PM, Sailesh Panchang wrote:
>>> Designers / developers need to review when it makes sense to include
>>> disabled controls in the UI. For instance in the page navigation
>>> links, the 'Next' button can be disabled and yet be rendered visually
>>> when the last page is in view. It becomes conspicuous by being absent
>>> in the tab order then!
>>> On the other hand dependent controls generally should be hidden if
>>> they are disabled. It makes for a cleaner uncluttered UI for everyone.
>>> Please review
>>> http://www.mindoversight.com/csun/2016/Overview.html
>>> and example for poor design- disabled controls.
>>> Thanks,
>>> Sailesh
>>>
>>>
>>> On 10/28/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> >> So in the situation where there are two combo-boxes and a submit
>>> >> button
>>> >> on
>>> >> a page, and the second combo box has no choices until the first combo
>>> >> box
>>> >> has a selection made would you want that second combo to be in the tab
>>> >> order? We were talking about adding a aria-disabled to the second
>>> >> combo
>>> >> box until there are choices in the it, would make more sense to mark
>>> >> it
>>> >> completely disabled?
>>> >
>>> > I'd say it is best practice to advise the user that changing something
>>> > in a
>>> > control will affect/change or add content later/further in the
>>> > document.
>>> >
>>> > Jonathan
>>> >
>>> > Jonathan Avila
>>> > Chief Accessibility Officer
>>> > SSB BART Group
>>> > = EMAIL ADDRESS REMOVED =
>>> > 703.637.8957 (Office)
>>> >
>>> > Visit us online: Website | Twitter | Facebook | Linkedin | Blog
>>> > Check out our Digital Accessibility Webinars!
>>> >
>>> >
>>> >