E-mail List Archives

Search E-mail List Archives for

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

From: Marc Solomon
Date: Wed, Mar 16 2016 2:10PM
Subject: WCAG Violation for use of tabindex=0 on static elements.
No previous message | Next message →

Maybe https://www.w3.org/TR/WCAG20-TECHS/F44.html?

Best,
Marc

From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Mar 16 2016 2:01PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

I am preparing a report on the accessibility of a web application for a vendor. The vendor has placed a tabindex="0" on almost every static element. Thus we have things like this

<ul>
<li tabindex="0"><a href="...>destination 1</a></li>
<li tabindex="0"><a href="...>destination 2</a></li>
<li tabindex="0"><a href="...>destination 3</a></li>
</ul>

Which causes an extra tab stop between each link in a navigational section.

Or

<div tabindex="0">
<span tabindex="0">
<h1 tabindex="0">Heading text</h1>
</span>
</div>

Which causes three tab stops on the main heading...

On any given page there may be as many as 50 items that are included in the tab ring that should not be.

This is making the application virtually unusable for keyboard users and very difficult to use for screen reader users. In some cases buttons that are placed inside of divs with the 0 value tabindex are announced when focus is placed on the div but are not executable at that point.

Are there specific WCAG AA guidelines that I can cite for this problem?


Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office

From: Jared Smith
Date: Wed, Mar 16 2016 2:19PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

> Are there specific WCAG AA guidelines that I can cite for this problem?

I don't think so. 2.1.1 only requires that functionality be operable
via a keyboard - which it is. It doesn't indicate anything about
efficiency, having non-actionable elements placed in the keyboard
navigation flow, etc.

F44, as Marc suggested, is quite a stretch. It deals with defining a
navigation order that is not logical. In your situation, the order is
logical - it's just that there's a lot of useless navigation elements
thrown into the mix.

Despite what WCAG requires, this is clearly an issue for end users and
should be fixed.

Any accessibility effort that is so reliant upon WCAG that it neglects
to address end user issues that are not defined as WCAG failures will
rarely result in good accessibility.

Jared

From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Mar 16 2016 2:25PM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

Thanks Marc,

I was considering that one but talked myself out of it because the sequence seemed to be correct. It goes left to right from top to bottom. On further reflection though I may be able to argue that the correct sequence is to move logically from active element to active element. The addition of tabindex="0" on inactive elements is interrupting that sequence in a major way.


Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office

From: Lucy Greco
Date: Wed, Mar 16 2016 2:51PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

hello mike:
i would ask them to try and tab throu the page with out a mouse and then
find one of the hand restriktors that trace includes in there educational
kit and then ask them to do it again then tell them the point of web
acccess is to do no harm and let them know every time a person with carpel
tunnal has to hit a key the dev is doing harm smile hope this helps lucy

Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Wed, Mar 16, 2016 at 1:25 PM, Moore,Michael (Accessibility) (HHSC) <
= EMAIL ADDRESS REMOVED = > wrote:

> Thanks Marc,
>
> I was considering that one but talked myself out of it because the
> sequence seemed to be correct. It goes left to right from top to bottom.
> On further reflection though I may be able to argue that the correct
> sequence is to move logically from active element to active element. The
> addition of tabindex="0" on inactive elements is interrupting that sequence
> in a major way.
>
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
>
>

From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Mar 16 2016 3:30PM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

"Any accessibility effort that is so reliant upon WCAG that it neglects to address end user issues that are not defined as WCAG failures will rarely result in good accessibility."

I totally agree but am going for the stretch argument anyway. Otherwise it probably will not be fixed.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office

From: Birkir R. Gunnarsson
Date: Wed, Mar 16 2016 4:02PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Lucy!
I like your style!
If we are still talking WCAG I have 3 suggestions:
First, 2.4.7 .. when you tab through all of these, do you always see
where the focus is? I am highly suspicious that a focus indicator has
not been created around all the static elements with tabindex="0",
therefore 2.4.7 fails.
If that is true, I think the case for 2.4.3 is much strengthened.
User expects to be tabbing from one actionable element to the next.
If he tabs, loses sight of where he is, tries to activate the element,
and nothing happens, that would be hard to interpret as a logical
focus order.
The third is 4.1.2, name, role, value.
You expect that an element that receives focus is an actionable element.
Actionable elements have to have a role. divs and spans do not have a
role, and that matters when you can tab to them.

I hope that none of the creative WCAG interpretation thinking is needed.
This must be due to wanting to accommodate for accessibility without
fully understanding how.
I once audited a webpage which had access key attributes for every
link and piece of text on the page (they stopped because they ran out
of keys).





On 3/16/16, Moore,Michael (Accessibility) (HHSC)
< = EMAIL ADDRESS REMOVED = > wrote:
> "Any accessibility effort that is so reliant upon WCAG that it neglects to
> address end user issues that are not defined as WCAG failures will rarely
> result in good accessibility."
>
> I totally agree but am going for the stretch argument anyway. Otherwise it
> probably will not be fixed.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
>
>

From: James Nurthen
Date: Wed, Mar 16 2016 5:56PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

I agree with 4.1.2
Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies
to these traditionally non-widget components

As such they need to have an accessible name and the "correct" role exposed
to the Accessibility APIs. They now take focus so the non-widget roles they
have are not valid for these now interactive components.

Regards,
James




On Wed, Mar 16, 2016 at 3:02 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Lucy!
> I like your style!
> If we are still talking WCAG I have 3 suggestions:
> First, 2.4.7 .. when you tab through all of these, do you always see
> where the focus is? I am highly suspicious that a focus indicator has
> not been created around all the static elements with tabindex="0",
> therefore 2.4.7 fails.
> If that is true, I think the case for 2.4.3 is much strengthened.
> User expects to be tabbing from one actionable element to the next.
> If he tabs, loses sight of where he is, tries to activate the element,
> and nothing happens, that would be hard to interpret as a logical
> focus order.
> The third is 4.1.2, name, role, value.
> You expect that an element that receives focus is an actionable element.
> Actionable elements have to have a role. divs and spans do not have a
> role, and that matters when you can tab to them.
>
> I hope that none of the creative WCAG interpretation thinking is needed.
> This must be due to wanting to accommodate for accessibility without
> fully understanding how.
> I once audited a webpage which had access key attributes for every
> link and piece of text on the page (they stopped because they ran out
> of keys).
>
>
>
>
>
> On 3/16/16, Moore,Michael (Accessibility) (HHSC)
> < = EMAIL ADDRESS REMOVED = > wrote:
> > "Any accessibility effort that is so reliant upon WCAG that it neglects
> to
> > address end user issues that are not defined as WCAG failures will rarely
> > result in good accessibility."
> >
> > I totally agree but am going for the stretch argument anyway. Otherwise
> it
> > probably will not be fixed.
> >
> > Mike Moore
> > Accessibility Coordinator
> > Texas Health and Human Services Commission
> > Civil Rights Office
> >
> >

From: Jonathan Avila
Date: Wed, Mar 16 2016 6:30PM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies to these traditionally non-widget components

This brings up a question I have always wondered -- what role can you apply to text? None? Presentation? There are some rare situations where you may want to place text in the focus order and if you do -- what role would you be required to use in order for it to meet SC 4.1.2?

Jonathan

From: Chaals McCathie Nevile
Date: Wed, Mar 16 2016 7:31PM
Subject: Re: excess accesskeysWCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

On Wed, 16 Mar 2016 23:02:24 +0100, Birkir R. Gunnarsson
< = EMAIL ADDRESS REMOVED = > wrote:

...
> I once audited a webpage which had access key attributes for every
> link and piece of text on the page (they stopped because they ran out
> of keys).

They weren't trying hard enough. You can put any unicode character in
there. Although some are a bad idea…

More to the point, I know real users, who genuinely want this
functionality. I tend to suggest that they should use a browser extension
to do it, because asking content producers would be a terrible idea. But
it relies on actually having accesskey - if we stick to javascripted
shortcuts, you can pretty much forget about trying to make it work.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Sailesh Panchang
Date: Thu, Mar 17 2016 7:21AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Birkir beat me to it and in fact took the words out of my mouth!
It is a fail under all the 3 SCs he listed.
Thanks,
Sailesh




On 3/16/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies
>> to these traditionally non-widget components
>
> This brings up a question I have always wondered -- what role can you apply
> to text? None? Presentation? There are some rare situations where you may
> want to place text in the focus order and if you do -- what role would you
> be required to use in order for it to meet SC 4.1.2?
>
> Jonathan
>
>

From: Birkir R. Gunnarsson
Date: Thu, Mar 17 2016 7:49AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

off-otpic
Coincidence?
I doubt it.
I have had the privellege to work with and receive training from some
pretty awesome accessibility people.

Sailesh is one of the Deque folks who taught me the most about accessibility.
So did many people ouside of Deque such as Bryan Garaventa, Denis
Boudreau, the WebAIM folks, and a lot of people on this list (if I
started naming all the names it would end up being a long email and
awfully off-topic).
But I must take a moment to say thank you to everyone on this list who
help me, from the moment I first heard about web accessibility 7 or 8
years ago, to where I am today.
And big thanks to Jared and the WebAIM folks who have kept this list
going for almost a decade.

I hope to help pass the knowledge on to others so we can all help make
the web an equal opportunity universe.
end-of-off-topic.
Cheers
-B



On 3/17/16, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> Birkir beat me to it and in fact took the words out of my mouth!
> It is a fail under all the 3 SCs he listed.
> Thanks,
> Sailesh
>
>
>
>
> On 3/16/16, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
>>> applies
>>> to these traditionally non-widget components
>>
>> This brings up a question I have always wondered -- what role can you
>> apply
>> to text? None? Presentation? There are some rare situations where you
>> may
>> want to place text in the focus order and if you do -- what role would you
>> be required to use in order for it to meet SC 4.1.2?
>>
>> Jonathan
>>
>>

From: Andrew Kirkpatrick
Date: Thu, Mar 17 2016 7:55AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

This is definitely an area that I'd like to see clarified in the future. I would argue that text _is_ a user interface component, and if you have:

<p tabindex=0>Some text</p>

You have set the name and role by using a paragraph and by the paragraph having the text content. The browser may report the element as clickable (the state), so some of these concerns may actually be addressed. Of course there are accessibility support issues, but we will put that aside for now.

The questions that I have about this type of interaction (apart from "is this really necessary?") are:
Will a screen reader user know that this is a link or provides some other interaction and if so, know how to activate it and what it is for? (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make sure that the control has a name that describes the input, 4.1.2 just requires a name - 1.1.1 requires that it describes the purpose)

Will a sighted keyboard user be able to know that this control is interactive and how to use it? (SC 2.4.7 for focus visibility. The how to use it is likely a question that will affect all users)

So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Accessibility
Adobe

= EMAIL ADDRESS REMOVED =
http://twitter.com/awkawk
http://blogs.adobe.com/accessibility








On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:

>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies to these traditionally non-widget components
>
>This brings up a question I have always wondered -- what role can you apply to text? None? Presentation? There are some rare situations where you may want to place text in the focus order and if you do -- what role would you be required to use in order for it to meet SC 4.1.2?
>
>Jonathan
>
>

From: Snahendu Bhattacharya
Date: Thu, Mar 17 2016 8:08AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

There are two different aspect. Accessibility and Usability.

By following the guidelines we need to ensure we have better Accessibility
rather ease of access. We should not try to make things complex.

Question is why should I make static element keyboard focusable?

Keyboard users can be of two types. 'Keyboard only' and 'screen reader +
keyboard' users.

In either cases user has option to read through the entire page, either
using 'eyes' or by using 'assistive technology'.

We should not force our user to traverse through all the elements of the
page unless those areas or elements need some user interaction. That
increases number of keystrokes and ends in a very poor user experience.

One of the major purpose of Accessibility is 'P O U R', where O is
operability. To implement this, we should not make it unusable.

I think this can be the argument to focus.
On Mar 17, 2016 9:55 AM, "Andrew Kirkpatrick" < = EMAIL ADDRESS REMOVED = > wrote:

> This is definitely an area that I'd like to see clarified in the future.
> I would argue that text _is_ a user interface component, and if you have:
>
> <p tabindex=0>Some text</p>
>
> You have set the name and role by using a paragraph and by the paragraph
> having the text content. The browser may report the element as clickable
> (the state), so some of these concerns may actually be addressed. Of
> course there are accessibility support issues, but we will put that aside
> for now.
>
> The questions that I have about this type of interaction (apart from "is
> this really necessary?") are:
> Will a screen reader user know that this is a link or provides some other
> interaction and if so, know how to activate it and what it is for? (perhaps
> 2.4.4 if the effect is that a link is created, or 1.1.1 to make sure that
> the control has a name that describes the input, 4.1.2 just requires a name
> - 1.1.1 requires that it describes the purpose)
>
> Will a sighted keyboard user be able to know that this control is
> interactive and how to use it? (SC 2.4.7 for focus visibility. The how to
> use it is likely a question that will affect all users)
>
> So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> = EMAIL ADDRESS REMOVED =
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
>
>
>
>
>
>
> On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" <
> = EMAIL ADDRESS REMOVED = on behalf of
> = EMAIL ADDRESS REMOVED = > wrote:
>
> >> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
> applies to these traditionally non-widget components
> >
> >This brings up a question I have always wondered -- what role can you
> apply to text? None? Presentation? There are some rare situations where
> you may want to place text in the focus order and if you do -- what role
> would you be required to use in order for it to meet SC 4.1.2?
> >
> >Jonathan
> >
> >

From: Megginson, Jason
Date: Thu, Mar 17 2016 8:17AM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

> Keyboard users can be of two types. 'Keyboard only' and 'screen reader + keyboard' users.

I make the argument for a third; low vision users of screen magnification. I agree that we should not force users to traverse through all the elements of the page unless those areas or elements need some user interaction. But I would also want to give the option to navigate or browse dynamic content (tooltips, dynamic regions etc) while retaining programmatic focus on the controlling element.

I am waiting for the day that screen magnification software utilize aria-controls (for example) where programmatic focus can be retained on a controlling element but allow the magnified screen to pan to the referenced dynamic region per the user's discretion. The trick, however, is informing sighted or low vision keyboard users that the controlling element references dynamic content in a non-obtrusive manner.

Jason Megginson Director, Accessibility Compliance Office (ACO)

The College Board
T 571.392.2195 | M 703.244.7755
= EMAIL ADDRESS REMOVED =

From: Snahendu Bhattacharya
Date: Thu, Mar 17 2016 8:22AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Hi Jason!

I completely agree without any argument.

My whole point was relayed to static content, which we should leave to
users wish, whether they want to read it or not. Contents like paragraph or
headings etc.

Wherever contents are dynamic and user should be able to focus and read the
content with ease.
On Mar 17, 2016 10:17 AM, "Megginson, Jason" < = EMAIL ADDRESS REMOVED = >
wrote:

> > Keyboard users can be of two types. 'Keyboard only' and 'screen reader +
> keyboard' users.
>
> I make the argument for a third; low vision users of screen magnification.
> I agree that we should not force users to traverse through all the elements
> of the page unless those areas or elements need some user interaction. But
> I would also want to give the option to navigate or browse dynamic content
> (tooltips, dynamic regions etc) while retaining programmatic focus on the
> controlling element.
>
> I am waiting for the day that screen magnification software utilize
> aria-controls (for example) where programmatic focus can be retained on a
> controlling element but allow the magnified screen to pan to the referenced
> dynamic region per the user's discretion. The trick, however, is informing
> sighted or low vision keyboard users that the controlling element
> references dynamic content in a non-obtrusive manner.
>
> Jason Megginson Director, Accessibility Compliance Office (ACO)
>
> The College Board
> T 571.392.2195 | M 703.244.7755
> = EMAIL ADDRESS REMOVED =
>
>
>

From: Jonathan Avila
Date: Thu, Mar 17 2016 8:37AM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

> Will a screen reader user know that this is a link or provides some other interaction

In regards to interactive content, F59: Failure of Success Criterion 4.1.2 due to using script to make div or span a user interface control in HTML without providing a role for the control (https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20160317/F59) already covers this situation. My concern was around those rare situations when text needs to be placed in the focus order and is not interactive. It sounds like the default native semantic structure elements would be sufficient absent role of none.

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: Guy Hickling
Date: Thu, Mar 17 2016 9:21AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Michael, since it seems, from all the comments in this thread, that finding
support for this in the WCAG is, at best, somewhat shaky, or would
involve arguments that the client might not choose to accept, maybe
the answer
is to fall back on discrimination liability at law and the client's
possible vulnerability to that.

I don't know the details of how the law works on accessibility in the US,
you will know more about that than me; but here in the UK any claim of
disability discrimination would not need to rely on the WCAG for proof. A
disability claim could use the WCAG if it helped, but is not limited to
just that approach.

Under the Equality Act 2010 it is, quite simply, illegal to discriminate
against anyone due to their disability. It identifies "indirect
discrimination" which happens when a policy or practice is applied to
everyone, but it has a particular disadvantage for disabled people.

So a disabled person who has to use the keyboard would only have to
demonstrate to a court that a website is either unusable for them, or is
significantly more difficult for them to use than for non-disabled people,
due to practices pursued by the developers (in this case the indiscriminate
use of tabindex), in order to be very likely to win their case. A provider
of products or services must take steps to avoid discrimination. This
approach affects all kinds of things that might not be covered specifically
by the WCAG.

So in your position, I would just point out to the client their *probable*
liability under law, and no doubt that would be sufficient to cause them to
make the changes you recommend. Especially if, as Birkir suggested, it may
be that they simply misunderstand what tabindex is for. If this wouldn't
work the same way under US law, let me know.

Regards,
Guy Hickling

From: Kevin Prince
Date: Thu, Mar 17 2016 1:04PM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Thanks for this discussion. I have had to use precisely this hack to expose helper text in a form where the backend doesn't allow for aria or for html to attach the helper text to the field. I'd argue that, in my case, these are actionable - they are elements of the form that you need to read to complete it, the focus is correctly indicated and it's the lesser of two evils. Having 3 tabstops for a heading isn't logical though so fails for me without any stretch of WCAG.

Kev
Access1in5
0212220638
039290692
Independent Accessibility and IT Consultancy.



> On 18/03/2016, at 02:55, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>
> This is definitely an area that I'd like to see clarified in the future. I would argue that text _is_ a user interface component, and if you have:
>
> <p tabindex=0>Some text</p>
>
> You have set the name and role by using a paragraph and by the paragraph having the text content. The browser may report the element as clickable (the state), so some of these concerns may actually be addressed. Of course there are accessibility support issues, but we will put that aside for now.
>
> The questions that I have about this type of interaction (apart from "is this really necessary?") are:
> Will a screen reader user know that this is a link or provides some other interaction and if so, know how to activate it and what it is for? (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make sure that the control has a name that describes the input, 4.1.2 just requires a name - 1.1.1 requires that it describes the purpose)
>
> Will a sighted keyboard user be able to know that this control is interactive and how to use it? (SC 2.4.7 for focus visibility. The how to use it is likely a question that will affect all users)
>
> So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
>
> Thanks,
> AWK
>
> Andrew Kirkpatrick
> Group Product Manager, Accessibility
> Adobe
>
> = EMAIL ADDRESS REMOVED =
> http://twitter.com/awkawk
> http://blogs.adobe.com/accessibility
>
>
>
>
>
>
>
>
> On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" < = EMAIL ADDRESS REMOVED = on behalf of = EMAIL ADDRESS REMOVED = > wrote:
>
>>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now applies to these traditionally non-widget components
>>
>> This brings up a question I have always wondered -- what role can you apply to text? None? Presentation? There are some rare situations where you may want to place text in the focus order and if you do -- what role would you be required to use in order for it to meet SC 4.1.2?
>>
>> Jonathan
>>
>>

From: Maxability Accessibility for all
Date: Sun, Mar 20 2016 11:45AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

If we consider having tabindex for static content as violation whats your
stand on the following situation.
When the user activate a link on the page it opens a modal. The modal has a
heading as first element. To set focus on to the first element on the modal
when it is opened the developer has used tabindex=0 to the heading in the
modal.
In this case to fix a problem related to 2.4.3 focus order tabindex is
used. In this case I think heading role is already provided through the
native control, so no 4.1.2 violation. May be other checkpoints such as
2.4.7 etc comes into force.
Any thoughts.

Thanks & Regards
Rakesh

On Fri, Mar 18, 2016 at 12:34 AM, Kevin Prince < = EMAIL ADDRESS REMOVED = >
wrote:

> Thanks for this discussion. I have had to use precisely this hack to
> expose helper text in a form where the backend doesn't allow for aria or
> for html to attach the helper text to the field. I'd argue that, in my
> case, these are actionable - they are elements of the form that you need to
> read to complete it, the focus is correctly indicated and it's the lesser
> of two evils. Having 3 tabstops for a heading isn't logical though so fails
> for me without any stretch of WCAG.
>
> Kev
> Access1in5
> 0212220638
> 039290692
> Independent Accessibility and IT Consultancy.
>
>
>
> > On 18/03/2016, at 02:55, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
> >
> > This is definitely an area that I'd like to see clarified in the
> future. I would argue that text _is_ a user interface component, and if
> you have:
> >
> > <p tabindex=0>Some text</p>
> >
> > You have set the name and role by using a paragraph and by the paragraph
> having the text content. The browser may report the element as clickable
> (the state), so some of these concerns may actually be addressed. Of
> course there are accessibility support issues, but we will put that aside
> for now.
> >
> > The questions that I have about this type of interaction (apart from "is
> this really necessary?") are:
> > Will a screen reader user know that this is a link or provides some
> other interaction and if so, know how to activate it and what it is for?
> (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make
> sure that the control has a name that describes the input, 4.1.2 just
> requires a name - 1.1.1 requires that it describes the purpose)
> >
> > Will a sighted keyboard user be able to know that this control is
> interactive and how to use it? (SC 2.4.7 for focus visibility. The how to
> use it is likely a question that will affect all users)
> >
> > So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
> >
> > Thanks,
> > AWK
> >
> > Andrew Kirkpatrick
> > Group Product Manager, Accessibility
> > Adobe
> >
> > = EMAIL ADDRESS REMOVED =
> > http://twitter.com/awkawk
> > http://blogs.adobe.com/accessibility
> >
> >
> >
> >
> >
> >
> >
> >
> > On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" <
> = EMAIL ADDRESS REMOVED = on behalf of
> = EMAIL ADDRESS REMOVED = > wrote:
> >
> >>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
> applies to these traditionally non-widget components
> >>
> >> This brings up a question I have always wondered -- what role can you
> apply to text? None? Presentation? There are some rare situations where
> you may want to place text in the focus order and if you do -- what role
> would you be required to use in order for it to meet SC 4.1.2?
> >>
> >> Jonathan
> >>
> >>

From: Cliff Tyllick
Date: Mon, Mar 21 2016 12:13AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

Rakesh, I see no violation there. In fact, even when the first element in the modal is just a paragraph, there is no violation. As Andrew pointed out, <p> assigns the proper role for body text just as effectively as <h1> through <h6> assign the proper roles for headings.

I can't think of situations that show more clearly than these two why tabindex="0" is needed at all:
- Having to direct focus to the beginning of the contents of a modal window.
- Having to ensure that instructions needed to correctly complete a form appear in the tab order exactly where they are needed.

Cheers!

Cliff Tyllick
Accessibility Specialist
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On Mar 20, 2016, at 10:45 AM, Maxability Accessibility for all < = EMAIL ADDRESS REMOVED = > wrote:
>
> If we consider having tabindex for static content as violation whats your
> stand on the following situation.
> When the user activate a link on the page it opens a modal. The modal has a
> heading as first element. To set focus on to the first element on the modal
> when it is opened the developer has used tabindex=0 to the heading in the
> modal.
> In this case to fix a problem related to 2.4.3 focus order tabindex is
> used. In this case I think heading role is already provided through the
> native control, so no 4.1.2 violation. May be other checkpoints such as
> 2.4.7 etc comes into force.
> Any thoughts.
>
> Thanks & Regards
> Rakesh
>
> On Fri, Mar 18, 2016 at 12:34 AM, Kevin Prince < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Thanks for this discussion. I have had to use precisely this hack to
>> expose helper text in a form where the backend doesn't allow for aria or
>> for html to attach the helper text to the field. I'd argue that, in my
>> case, these are actionable - they are elements of the form that you need to
>> read to complete it, the focus is correctly indicated and it's the lesser
>> of two evils. Having 3 tabstops for a heading isn't logical though so fails
>> for me without any stretch of WCAG.
>>
>> Kev
>> Access1in5
>> 0212220638
>> 039290692
>> Independent Accessibility and IT Consultancy.
>>
>>
>>
>>> On 18/03/2016, at 02:55, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>> This is definitely an area that I'd like to see clarified in the
>> future. I would argue that text _is_ a user interface component, and if
>> you have:
>>>
>>> <p tabindex=0>Some text</p>
>>>
>>> You have set the name and role by using a paragraph and by the paragraph
>> having the text content. The browser may report the element as clickable
>> (the state), so some of these concerns may actually be addressed. Of
>> course there are accessibility support issues, but we will put that aside
>> for now.
>>>
>>> The questions that I have about this type of interaction (apart from "is
>> this really necessary?") are:
>>> Will a screen reader user know that this is a link or provides some
>> other interaction and if so, know how to activate it and what it is for?
>> (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make
>> sure that the control has a name that describes the input, 4.1.2 just
>> requires a name - 1.1.1 requires that it describes the purpose)
>>>
>>> Will a sighted keyboard user be able to know that this control is
>> interactive and how to use it? (SC 2.4.7 for focus visibility. The how to
>> use it is likely a question that will affect all users)
>>>
>>> So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
>>>
>>> Thanks,
>>> AWK
>>>
>>> Andrew Kirkpatrick
>>> Group Product Manager, Accessibility
>>> Adobe
>>>
>>> = EMAIL ADDRESS REMOVED =
>>> http://twitter.com/awkawk
>>> http://blogs.adobe.com/accessibility
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" <
>> = EMAIL ADDRESS REMOVED = on behalf of
>> = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
>> applies to these traditionally non-widget components
>>>>
>>>> This brings up a question I have always wondered -- what role can you
>> apply to text? None? Presentation? There are some rare situations where
>> you may want to place text in the focus order and if you do -- what role
>> would you be required to use in order for it to meet SC 4.1.2?
>>>>
>>>> Jonathan
>>>>
>>>>

From: Jeevan Reddy
Date: Mon, Mar 21 2016 4:46AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | Next message →

i see it as usability issue more than accessibility issue for low
vision and keyboard users.
modern browsers provide focus indicator(2.4.7) for the elements
having tabindex greator or equal to zero but may not be sufficient for
low vision users in order to keep track where they are in.
adding tabindex for more elements in a page, for example for the hint
text in a form, force the keyboard users to use more tabs while
navigating.
The real example of adding tab index for non static elements which is
absolutely required is the terms and conditions in a dialog. todays Ux
showing that unless the user scroll through the list of terms and
conditions the dialog proceed and cancel buttons will not be enabled.

if you wish todo so consider 2.4.7
On 3/21/16, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
> Rakesh, I see no violation there. In fact, even when the first element in
> the modal is just a paragraph, there is no violation. As Andrew pointed out,
> <p> assigns the proper role for body text just as effectively as <h1>
> through <h6> assign the proper roles for headings.
>
> I can't think of situations that show more clearly than these two why
> tabindex="0" is needed at all:
> - Having to direct focus to the beginning of the contents of a modal window.
> - Having to ensure that instructions needed to correctly complete a form
> appear in the tab order exactly where they are needed.
>
> Cheers!
>
> Cliff Tyllick
> Accessibility Specialist
> Texas Department of Assistive and Rehabilitative Services
>
> Sent from my iPhone
> Although its spellcheck often saves me, all goofs in sent messages are its
> fault.
>
>> On Mar 20, 2016, at 10:45 AM, Maxability Accessibility for all
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> If we consider having tabindex for static content as violation whats your
>> stand on the following situation.
>> When the user activate a link on the page it opens a modal. The modal has
>> a
>> heading as first element. To set focus on to the first element on the
>> modal
>> when it is opened the developer has used tabindex=0 to the heading in the
>> modal.
>> In this case to fix a problem related to 2.4.3 focus order tabindex is
>> used. In this case I think heading role is already provided through the
>> native control, so no 4.1.2 violation. May be other checkpoints such as
>> 2.4.7 etc comes into force.
>> Any thoughts.
>>
>> Thanks & Regards
>> Rakesh
>>
>> On Fri, Mar 18, 2016 at 12:34 AM, Kevin Prince < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> Thanks for this discussion. I have had to use precisely this hack to
>>> expose helper text in a form where the backend doesn't allow for aria or
>>> for html to attach the helper text to the field. I'd argue that, in my
>>> case, these are actionable - they are elements of the form that you need
>>> to
>>> read to complete it, the focus is correctly indicated and it's the lesser
>>> of two evils. Having 3 tabstops for a heading isn't logical though so
>>> fails
>>> for me without any stretch of WCAG.
>>>
>>> Kev
>>> Access1in5
>>> 0212220638
>>> 039290692
>>> Independent Accessibility and IT Consultancy.
>>>
>>>
>>>
>>>> On 18/03/2016, at 02:55, Andrew Kirkpatrick < = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>> This is definitely an area that I'd like to see clarified in the
>>> future. I would argue that text _is_ a user interface component, and if
>>> you have:
>>>>
>>>> <p tabindex=0>Some text</p>
>>>>
>>>> You have set the name and role by using a paragraph and by the paragraph
>>> having the text content. The browser may report the element as clickable
>>> (the state), so some of these concerns may actually be addressed. Of
>>> course there are accessibility support issues, but we will put that aside
>>> for now.
>>>>
>>>> The questions that I have about this type of interaction (apart from "is
>>> this really necessary?") are:
>>>> Will a screen reader user know that this is a link or provides some
>>> other interaction and if so, know how to activate it and what it is for?
>>> (perhaps 2.4.4 if the effect is that a link is created, or 1.1.1 to make
>>> sure that the control has a name that describes the input, 4.1.2 just
>>> requires a name - 1.1.1 requires that it describes the purpose)
>>>>
>>>> Will a sighted keyboard user be able to know that this control is
>>> interactive and how to use it? (SC 2.4.7 for focus visibility. The how
>>> to
>>> use it is likely a question that will affect all users)
>>>>
>>>> So I would say that 1.1.1 and 2.4.7 are SC that I'd look at for this.
>>>>
>>>> Thanks,
>>>> AWK
>>>>
>>>> Andrew Kirkpatrick
>>>> Group Product Manager, Accessibility
>>>> Adobe
>>>>
>>>> = EMAIL ADDRESS REMOVED =
>>>> http://twitter.com/awkawk
>>>> http://blogs.adobe.com/accessibility
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 3/16/16, 20:30, "WebAIM-Forum on behalf of Jonathan Avila" <
>>> = EMAIL ADDRESS REMOVED = on behalf of
>>> = EMAIL ADDRESS REMOVED = > wrote:
>>>>
>>>>>> Adding tabindex=0 makes it a User Interface Component so 4.1.2 now
>>> applies to these traditionally non-widget components
>>>>>
>>>>> This brings up a question I have always wondered -- what role can you
>>> apply to text? None? Presentation? There are some rare situations where
>>> you may want to place text in the focus order and if you do -- what role
>>> would you be required to use in order for it to meet SC 4.1.2?
>>>>>
>>>>> Jonathan
>>>>>
>>>>>

From: Joe Chidzik
Date: Mon, Mar 21 2016 5:28AM
Subject: Re: WCAG Violation for use of tabindex=0 on staticelements.
← Previous message | Next message →

In this case though, the developer should probably use tabindex="-1" which restricts the focus to only being placed onto an element programmatically, rather than the element appearing in the focus order with tabindex="0".

As an aside, I would probably place the focus onto the actual dialog container itself (with role=dialog), rather than the heading, with the title of this container picked up from the dialog heading via aria-describedby or similar.

Joe

>

From: Maxability Accessibility for all
Date: Tue, Mar 22 2016 6:14AM
Subject: Re: WCAG Violation for use of tabindex=0 on static elements.
← Previous message | No next message

I agree with you Kliff.
Hi Joe,

If the focus is moved to the modal container, I was wondering screen reader
may read the content of the entire modal or if it restrict to the content
called by aria-describedby.
The other problem I observe commonly is the screen reader moves to forms
mode when role dialog is used. This means screen reader user should switch
to browse mode and then read the content on the modal.


On Mon, Mar 21, 2016 at 4:58 PM, Joe Chidzik < = EMAIL ADDRESS REMOVED = >
wrote:

> In this case though, the developer should probably use tabindex="-1" which
> restricts the focus to only being placed onto an element programmatically,
> rather than the element appearing in the focus order with tabindex="0".
>
> As an aside, I would probably place the focus onto the actual dialog
> container itself (with role=dialog), rather than the heading, with the
> title of this container picked up from the dialog heading via
> aria-describedby or similar.
>
> Joe
>
> >