E-mail List Archives

Search E-mail List Archives for

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

From: Sailesh Panchang
Date: Fri, Jul 07 2017 7:35AM
Subject: Misuse of TabIndex 0
No previous message | Next message →

Michael,
Does this not directly contravene SC 2.4.3: '...focusable components
receive focus in an order that preserves meaning and operability'?
If there are non-focusable elements with tabindex=0 or just empty tab
stops between focusable elements, will users not be confused i.e.
meaning and operability are impacted by a disappearing focus
indicator?
SC 2.4.7 only requires operable elements to have a focus indicator so
it will be a contravention of this SC if a non-focusable element with
tabindex=0 has a visible focus indicator. And as others suggested, in
this case it will fail SC 4.1.2 as the role is misleading.

Users need to be 'allowed to keep track of their location' [1].

Yes , tabindex=0 used to be suggested to ensure instructions placed
within form fields were not missed by SR users (as a hack) in order
to meet old S508 para (n) of 1194.22 before ARIA.

References:

1. From Understanding Guideline 2.4
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms.html
:
The intent of this guideline is to help users find the content they
need and allow them to keep track of their location.
Navigation has two main functions:, the first being: 'to tell the user
where they are'

2. From Understanding SC 2.4.3:
"For example, a screen reader user interacts with the programmatically
determined reading order, while a sighted keyboard user interacts with
the visual
presentation of the Web page. Care should be taken so that the focus
order makes sense to both of these sets of users and does not appear
to either of
them to jump around randomly".

3. Link to 'Giving focus to an element' referred to in Understanding SC 2.4.3:
See Section 17.11 on https://www.w3.org/TR/html401/interact/forms.html

Thanks and regards,


On 11/5/15, Moore,Michael (Accessibility) (HHSC)
< = EMAIL ADDRESS REMOVED = > wrote:
> Far more people than just screen reader users use tab navigation to move
> through a form. Adding unneeded tab stops to make everything on the form
> readable through the tab ring does a disservice to those users and provides
> screen reader users and others. It implicitly implies that all of the
> tab-able objects have a role of active. Far better to use aria-labelledby
> and aria-described by to make sure that critical information is not lost to
> a screen reader user. See comments on this thread from Steve Faulkner and
> Paul Adam.
>
> Modern screen reader software has an auto forms mode allowing the use of
> reading keys to navigate a form rather than just tabbing through. I am not
> saying that you would never use tab-index of 0 on a static object. There may
> be a rare use case when it is the only way to make an object accessible. But
> if the only purpose of tab-index 0 is to make sure that a screen reader user
> cannot avoid reading the instructions then you are denying them the same
> opportunity that anyone else has to ignore the instructions. It may be that
> they have already filled out the form 10 times before and don't need to read
> the instructions again.
>
> Much better form design is to use headings to define sections of a form and
> provide the instructions for each section immediately after the heading and
> before the fields start. Screen reader users will receive information about
> the number of headings when the form opens and will know that there are
> multiple sections. I could even see using aria-describedby or aria-label on
> the last field in a section to notify a screen reader user that this is the
> end of the section. This would be unobtrusive for other users and would not
> adversely impact the tab-order or the implicit roles of the objects in the
> form.
>
> Mike Moore
> Accessibility Coordinator
> Texas Health and Human Services Commission
> Civil Rights Office
>
>
>

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 7:45AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 14:35, Sailesh Panchang wrote:
> Michael,
> Does this not directly contravene SC 2.4.3: '...focusable components
> receive focus in an order that preserves meaning and operability'?

Going purely by the word of WCAG (if we want to split hairs), once you
add tabindex=0 you've made an element focusable, so it's just the order
that matters.

I do however usually note unnecessary tab stops on non-interactive
controls under 2.4.3 (and, under certain situations, cross-reference the
failure from 2.1.1 Keyboard as well).

I wouldn't say it fails 2.4.7 though, because once you've made an
element that's not normally focusable focusable, then it needs to have a
visible focus indication. The fact that it shouldn't be focusable in the
first place is no excuse for not indicating the focus visibly.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Graham Armfield
Date: Fri, Jul 07 2017 11:12AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

If using tabindex="0" on instruction text between form fields is no longer
recommended, and aria should be used instead, please can someone spell out
with a code example what is considered to be best practice now.

Thanks
Graham Armfield

From: Sailesh Panchang
Date: Fri, Jul 07 2017 11:39AM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

Patrick,
Not sure how one can invoke 2.1.1 on an element that is simply not
operable in any way i.e. even via a mouse.
Forcing focus on a static element does not make it operable. So a
visual focus indicator for such an element compounds the problem and
adds another failure: 2.4.7.
What meaning and operability is preserved by adding tabindex=0 for
sighted keyboard users? I rely on WG guidance (references) in my last
email.
Thanks and best wishes,


On 7/7/17, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 07/07/2017 14:35, Sailesh Panchang wrote:
>> Michael,
>> Does this not directly contravene SC 2.4.3: '...focusable components
>> receive focus in an order that preserves meaning and operability'?
>
> Going purely by the word of WCAG (if we want to split hairs), once you
> add tabindex=0 you've made an element focusable, so it's just the order
> that matters.
>
> I do however usually note unnecessary tab stops on non-interactive
> controls under 2.4.3 (and, under certain situations, cross-reference the
> failure from 2.1.1 Keyboard as well).
>
> I wouldn't say it fails 2.4.7 though, because once you've made an
> element that's not normally focusable focusable, then it needs to have a
> visible focus indication. The fact that it shouldn't be focusable in the
> first place is no excuse for not indicating the focus visibly.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 12:39PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 18:39, Sailesh Panchang wrote:
> Patrick,
> Not sure how one can invoke 2.1.1 on an element that is simply not
> operable in any way i.e. even via a mouse.

2.1.1 will depend on the situation. I will often note it there as part
of a more general "keyboard operation is inappropriate/broken" point if
present.

> Forcing focus on a static element does not make it operable. So a
> visual focus indicator for such an element compounds the problem and
> adds another failure: 2.4.7.

2.4.7 says that the focus needs to be visible as otherwise sighted users
will get lost/not know where their focus is. If the focus is on an
element that has tabindex=0, it needs to be visible that there is focus
there - regardless of whether it's appropriate or not that the element
should receive focus in the first place. So it would fail 2.4.7 IF there
was a non-interactive element receiving focus and focus indication was
NOT given, as to a sighted user that would then appear as though the
focus disappears and reappears when they navigate through the page.

> What meaning and operability is preserved by adding tabindex=0 for
> sighted keyboard users? I rely on WG guidance (references) in my last
> email.

I'm not saying that it's appropriate to add tabindex=0 to
non-interactive elements. I am simply clarifying that, in my view, it's
not a strict failure of neither 2.4.3 (see for instance the
"understanding" document
https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html
which, at least from skim-reading it, does not necessarily say anything
about non-interactive elements receiving focus being a failure - though
I do personally still note it in 2.4.3 and sometimes, depending on
context, 2.1.1), nor 2.4.7 (as whatever it is that receives focus, the
focus needs to be visible - regardless of whether it's right or wrong
that that particular element/thing received focus or not).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 12:49PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 18:12, Graham Armfield wrote:
> If using tabindex="0" on instruction text between form fields is no longer
> recommended, and aria should be used instead, please can someone spell out
> with a code example what is considered to be best practice now.

I would depend on the specific situation, length of the instructions,
whether or not they're grouped/contained somehow. For instance, making
instructions part of a fieldset's legend could work in certain
situations (may require subtle rewording depending on what's currently
there)...

<fieldset>
<legend>Your favourite foods (pick at least one to proceed)</legend>
...
</fieldset>

If the instruction relates to one particular field only, relating it to
the form field using aria-describedby...

<label for="food">Your favourite foods</label>
<p id="food-instr">Give us a list of your favourite foods, separated by
spaces or commas</p>
<textarea id="food" area-describedby="food-instr"></textarea>

etc.

There may be more methods, and they may all be valid approaches
depending on context.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Sailesh Panchang
Date: Fri, Jul 07 2017 1:02PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

Patrick,
Your view now seems to differ from the one you expressed in Nov /2015
when you seemed to agree with Michael re. 'operability' besides his
other assertions?
We are not discussing broken keyboard operability for elements that
are indeed operable ... so I do not understand application of 2.1.1 to
non-operable element with tabindex=0 now.
I do not see what you state for visible focus indicator as part of the
normative text of that SC. The Understanding doc covers 'operable'
elements.
Thanks,
On 7/7/17, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 07/07/2017 18:39, Sailesh Panchang wrote:
>> Patrick,
>> Not sure how one can invoke 2.1.1 on an element that is simply not
>> operable in any way i.e. even via a mouse.
>
> 2.1.1 will depend on the situation. I will often note it there as part
> of a more general "keyboard operation is inappropriate/broken" point if
> present.
>
>> Forcing focus on a static element does not make it operable. So a
>> visual focus indicator for such an element compounds the problem and
>> adds another failure: 2.4.7.
>
> 2.4.7 says that the focus needs to be visible as otherwise sighted users
> will get lost/not know where their focus is. If the focus is on an
> element that has tabindex=0, it needs to be visible that there is focus
> there - regardless of whether it's appropriate or not that the element
> should receive focus in the first place. So it would fail 2.4.7 IF there
> was a non-interactive element receiving focus and focus indication was
> NOT given, as to a sighted user that would then appear as though the
> focus disappears and reappears when they navigate through the page.
>
>> What meaning and operability is preserved by adding tabindex=0 for
>> sighted keyboard users? I rely on WG guidance (references) in my last
>> email.
>
> I'm not saying that it's appropriate to add tabindex=0 to
> non-interactive elements. I am simply clarifying that, in my view, it's
> not a strict failure of neither 2.4.3 (see for instance the
> "understanding" document
> https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-focus-order.html
> which, at least from skim-reading it, does not necessarily say anything
> about non-interactive elements receiving focus being a failure - though
> I do personally still note it in 2.4.3 and sometimes, depending on
> context, 2.1.1), nor 2.4.7 (as whatever it is that receives focus, the
> focus needs to be visible - regardless of whether it's right or wrong
> that that particular element/thing received focus or not).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
Phone 703-225-0380 ext 105
Mobile: 571-344-1765

From: Devarshi Pant
Date: Fri, Jul 07 2017 1:02PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

I have seen text patterns like warning messages / notifications with
tabindex = 0. This practice of using tabindex = 0 judiciously can be
helpful in my view, but open to interpretation when used on static text.

Another example: Consider https://www.ssa.gov/oact/STATS/table4a1.html with
3 large tables using <captions> to delineate unique tables. A screen reader
user is at an advantage being able to list captions from the tables list,
but a sighted keyboard user would skip past these tables unless table cells
have interactive elements. Tabindex = 0 on captions might help users to
stop on the table while tabbing.

And, yes, someone may have a contrary viewpoint.


On Nov 4, 2015 09:59, "Moore,Michael (Accessibility) (HHSC)" <
= EMAIL ADDRESS REMOVED = > wrote:

I am evaluating a large web based application that uses tabindex="0" to
place all of the explanatory text, instructions, FAQ's, questions for
groups of radio buttons and checkboxes, etc. into the tab ring.

I am of the opinion that this violates the intent if not the letter of
guideline 2.4.3 focus order. "If a Web page can be navigated sequentially
and the navigation sequences affect meaning or operation, focusable
components receive focus in an order that preserves meaning and operability"

My interpretation is that by placing inactive/static content within the tab
ring operability is severely adversely impacted for people who depend upon
tab navigation.

Operability is impacted in the following ways:

1. Additional tab stops make it harder to get to interactive controls
like links and form fields. This is particularly onerous for people who use
keyboard navigation due to a physical disability that limits dexterity in
their hands.

2. The additional tab stops may create confusion since the user will
expect to tab to controls, form fields and links and not static text.

3. The additional tab stops may create further confusion since some users
may assume that since the text is focusable that it will be actionable
(This may also violate 4.1.2).

Do you agree or disagree with my interpretation and why? Is there another
guideline at level A or AA that may apply here? Note: 2.4.7 Focus Visible
is being met.

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

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 1:19PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 20:02, Sailesh Panchang wrote:
> Patrick,
> Your view now seems to differ from the one you expressed in Nov /2015
> when you seemed to agree with Michael re. 'operability' besides his
> other assertions?

You mean I may have changed my mind in the course of the last 1.5 years?
Perhaps so. My main point is: while I would generally note issues like
non-interactive elements receiving focus in 2.4.3, I wouldn't
categorically state that these are hard FAILs, exactly because the
language of WCAG doesn't explicitly say that non-interactive elements
should NEVER receive focus. This is the wooly part of WCAG where - often
based on context, personal reasoning, interpretation - we have to apply
some creative "under what WCAG SC can I fail this thing which is not
good but doesn't have a clear SC related to it".

> We are not discussing broken keyboard operability for elements that
> are indeed operable ... so I do not understand application of 2.1.1 to
> non-operable element with tabindex=0 now.

See above. As the fact that non-interactive elements fall into the
keyboard focus cycle falls across various SCs, without clearly - in my
view - being a hard FAIL, it can - depending on what other issues under
2.1.1 there may already be - be something that I'd mention there as well
as part of a more general "there are issues relating to how this
site/app operates or doesn't via the keyboard". Again, point being: it's
not a clear cut failure that falls very squarely into a neat single SC,
so sometimes you'll need to be a bit creative on where you ding a site
for doing this.

> I do not see what you state for visible focus indicator as part of the
> normative text of that SC. The Understanding doc covers 'operable'
> elements.

So what are you saying? That if the focus is on an inoperable element,
there should NOT be a visible indication of focus?

2.4.7 relates to "keyboard operable user interface". It does not say
"operable elements" specifically, nor does it explicitly say "if an
element receives focus but it is not operable, it should not have a
focus indication". Leaving aside things that shouldn't be forced into
focus with tabindex=0 that aren't interactive...what about read-only
text fields? Do you consider them "not operable", and therefore exempt
from requiring visible focus indication under 2.4.7? Presumably not, and
under that same rationale I'm saying that 2.4.7, to paraphrase, says:
"sighted user must be able to see where the current focus is". It does
not make any value judgement about what should or should not RECEIVE
focus in the first place, it merely says that focus needs to be visibly
discernible.

And to avoid doubt: I'm not saying adding non-interactive things into
the focus order with tabindex=0 is good practice, far from it. What I
*am* saying is that in my view there's not a clear-cut "well, this fails
2.4.3 / 2.4.7" situation, based on my current reading of WCAG. I usually
still fail this sort of thing in audits, but it's not necessarily a
"hard" fail per the exact letter of WCAG, more of a judgement call about
exactly where/how you note the failure.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 1:22PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 20:02, Devarshi Pant wrote:
[...]
> Another example: Consider https://www.ssa.gov/oact/STATS/table4a1.html with
> 3 large tables using <captions> to delineate unique tables. A screen reader
> user is at an advantage being able to list captions from the tables list,
> but a sighted keyboard user would skip past these tables unless table cells
> have interactive elements. Tabindex = 0 on captions might help users to
> stop on the table while tabbing.

Non-screen reader keyboard users don't just use TAB/SHIFT+TAB. Cursor
keys and SPACE/SHIFT+SPACE are used to scroll/page around a document. So
no, even without making captions focusable, these keyboard users won't
"skip past" the tables, they'd simply use these other keys to
scroll/page through them.

However, if we wanted to be helpful here to keyboard users, why not
provide a table of content at the start of the page with in-page links
to jump directly to the relevant tables?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Devarshi Pant
Date: Fri, Jul 07 2017 2:52PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

Ofcourse, they can arrow down etc., but those who cannot use the mouse
still need to use the tab key to interact with a link / control within a
table. Question being - is it an accessibility issue to use tabindex 0 on
important static text?

You are correct, using table of contents would be more helpful here.

On Jul 7, 2017 15:22, "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = > wrote:

On 07/07/2017 20:02, Devarshi Pant wrote:
[...]

Another example: Consider https://www.ssa.gov/oact/STATS/table4a1.html with
> 3 large tables using <captions> to delineate unique tables. A screen reader
> user is at an advantage being able to list captions from the tables list,
> but a sighted keyboard user would skip past these tables unless table cells
> have interactive elements. Tabindex = 0 on captions might help users to
> stop on the table while tabbing.
>

Non-screen reader keyboard users don't just use TAB/SHIFT+TAB. Cursor keys
and SPACE/SHIFT+SPACE are used to scroll/page around a document. So no,
even without making captions focusable, these keyboard users won't "skip
past" the tables, they'd simply use these other keys to scroll/page through
them.

However, if we wanted to be helpful here to keyboard users, why not provide
a table of content at the start of the page with in-page links to jump
directly to the relevant tables?


P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 2:56PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

On 07/07/2017 21:52, Devarshi Pant wrote:
> Ofcourse, they can arrow down etc., but those who cannot use the mouse
> still need to use the tab key to interact with a link / control within a
> table.

And they're not prevented from doing so, even when the caption is NOT
made keyboard focusable with tabindex=0, or am I missing something?

> Question being - is it an accessibility issue to use tabindex 0 on
> important static text?

I'd personally class it more as an annoyance in most cases, and
potentially confusing, rather than a hard failure.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: sailesh.panchang
Date: Fri, Jul 07 2017 3:33PM
Subject: Re: Misuse of TabIndex 0
← Previous message | Next message →

You seem to be equating keyboard operable with keyboard navigable / focusable. Tabindex 0 is not operable



Sailesh. ...Sent from my iPhone

> On Jul 7, 2017, at 3:19 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 07/07/2017 20:02, Sailesh Panchang wrote:
>> Patrick,
>> Your view now seems to differ from the one you expressed in Nov /2015
>> when you seemed to agree with Michael re. 'operability' besides his
>> other assertions?
>
> You mean I may have changed my mind in the course of the last 1.5 years? Perhaps so. My main point is: while I would generally note issues like non-interactive elements receiving focus in 2.4.3, I wouldn't categorically state that these are hard FAILs, exactly because the language of WCAG doesn't explicitly say that non-interactive elements should NEVER receive focus. This is the wooly part of WCAG where - often based on context, personal reasoning, interpretation - we have to apply some creative "under what WCAG SC can I fail this thing which is not good but doesn't have a clear SC related to it".
>
>> We are not discussing broken keyboard operability for elements that
>> are indeed operable ... so I do not understand application of 2.1.1 to
>> non-operable element with tabindex=0 now.
>
> See above. As the fact that non-interactive elements fall into the keyboard focus cycle falls across various SCs, without clearly - in my view - being a hard FAIL, it can - depending on what other issues under 2.1.1 there may already be - be something that I'd mention there as well as part of a more general "there are issues relating to how this site/app operates or doesn't via the keyboard". Again, point being: it's not a clear cut failure that falls very squarely into a neat single SC, so sometimes you'll need to be a bit creative on where you ding a site for doing this.
>
>> I do not see what you state for visible focus indicator as part of the
>> normative text of that SC. The Understanding doc covers 'operable'
>> elements.
>
> So what are you saying? That if the focus is on an inoperable element, there should NOT be a visible indication of focus?
>
> 2.4.7 relates to "keyboard operable user interface". It does not say "operable elements" specifically, nor does it explicitly say "if an element receives focus but it is not operable, it should not have a focus indication". Leaving aside things that shouldn't be forced into focus with tabindex=0 that aren't interactive...what about read-only text fields? Do you consider them "not operable", and therefore exempt from requiring visible focus indication under 2.4.7? Presumably not, and under that same rationale I'm saying that 2.4.7, to paraphrase, says: "sighted user must be able to see where the current focus is". It does not make any value judgement about what should or should not RECEIVE focus in the first place, it merely says that focus needs to be visibly discernible.
>
> And to avoid doubt: I'm not saying adding non-interactive things into the focus order with tabindex=0 is good practice, far from it. What I *am* saying is that in my view there's not a clear-cut "well, this fails 2.4.3 / 2.4.7" situation, based on my current reading of WCAG. I usually still fail this sort of thing in audits, but it's not necessarily a "hard" fail per the exact letter of WCAG, more of a judgement call about exactly where/how you note the failure.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Patrick H. Lauke
Date: Fri, Jul 07 2017 3:39PM
Subject: Re: Misuse of TabIndex 0
← Previous message | No next message

On 07/07/2017 22:33, = EMAIL ADDRESS REMOVED = wrote:
> You seem to be equating keyboard operable with keyboard navigable / focusable.
No I'm not, but thanks for playing.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke