WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Misuse of TabIndex 0

for

From: sailesh.panchang
Date: Jul 7, 2017 3:33PM

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 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
> > > >