WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG - Fail or not to - Static text tab-focusable in tables

for

From: Birkir R. Gunnarsson
Date: Jan 2, 2021 7:04PM


I totally agree that audit context is important. My initial reply to
this list highlighting that sometimes I can fail things for my company
without mapping it to a specific WCAG success criterion speaks to my
employer's commitment to an accessible and usable experience, so it
was just a note of appreciation for that. I spent years as a
consultant strictly auditing to WCAG, and part of the reason I
switched jobs was the opportunity to stop so heavily focusing on WCAG
and starting to focus on accessibility/ax (accessible experience).
WCAG 2.1 AA is still the standard, but if I come across serious AX
problems I can record and assign severity based on our assessment of
the user impact.

I still have to say that if you can make tens or hundreds of static
webpage elements keyboard focusable without failing a WCAG success
criterion, then WCAG is broken in that regard and this is something
that needs to be fixed. I may have to look at filing an issue against
WCAG 3.0 to have this looked into.


I would still fail this under either success criterion 2.1.2.,
keyboard trap (if it's near impossible to get past the static elements
in the table with the tab key this constitutes a keyboard trap) or
2.4.3 (I don't see how sending focus to dozens of non-focusable and
non-operable elements preserves meaning and operation, especially
operation).
Again, it's all about context, if the table has a "skip past table"
link this wouldn't apply. If the table is only in one location and
there's nothing operable after it (safe, perhaps the footer), it
probably would not be more than a minor to moderate impact. It also
depends on the number of static focusable elements, is it 1, 10, 100,
or hundreds?
Also it depends if the page is a static/ppublic page or whether it is
located behind a session where you can literally time out while
tabbing through the static elements, in that case the keyboard trap
argument becomes pretty strong.
So, context, context, context. Accessibility would not be a legitimate
and respected industry without a standard, and WCAG has done miracles,
but it's technology agnostic nature that makes it so powerful and
flexible can sometimes present confusion and inconsistencies between
experts, because interpretation is required.
And that, folks, is why this WebAIM mailing list is so great. I love
reading all the points of view and I never stop learning. I may
occasionally disagree with some posts but I never fail to appreciate
the thoughts and I have often changed my mind after reading all the
awesome discussions on here.
Cheers



On 1/2/21, Steve Green < <EMAIL REMOVED> > wrote:
> " Yet another reason to avoid performing "WCAG audits". I believe they're
> hurtful, and clients who want to only stick to it are cheaper served by any
> fly-by-night "a11y experts"."
>
> I don't often disagree with you, but that's absolute nonsense. The reality
> is that the vast majority of organisations are only interested in legal
> compliance. That can mean different things in different countries. For US
> organisations that are covered by Section 508, it means conformance with
> WCAG 2.0 rather than 2.1. In the UK, all public sector organisations must
> meet WCAG 2.1, but there are exceptions for certain types of content.
>
> In what possible way is it hurtful to achieve AA conformance? If you're
> suggesting that level AA isn't enough, then where do you draw the line and
> why? It's always possible to do more, so any line is arbitrary and it's a
> matter of diminishing returns after that.
>
> And the idea that there are "fly-by-night a11y experts" who can competently
> test for WCAG conformance is wishful thinking. In the UK there are probably
> no more than 10 testing companies and a handful of freelancers who can
> conduct a WCAG audit competently. It's really, really difficult and takes
> many thousands of hours of study and experience. Most of the test reports I
> have seen from other organisations and freelancers are very poor. Of course
> there are some notable exceptions in this forum.
>
> Steve
>
>
> -----Original Message-----
> From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of
> Mallory
> Sent: 02 January 2021 13:21
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
>
> I suppose technically a button which can only be activated with the "r" key
> also passes 2.1.1.
>
> Yet another reason to avoid performing "WCAG audits". I believe they're
> hurtful, and clients who want to only stick to it are cheaper served by any
> fly-by-night "a11y experts".
>
> However reports should always put the "this is 110% unusable" issues under a
> "UX" heading or something, and not point to an SC.
>
> cheers,
> _mallory
>
> On Fri, Jan 1, 2021, at 10:00 PM, Patrick H. Lauke wrote:
>> On 01/01/2021 18:50, Abi James wrote:
>>
>> > I would usually apply 2.1.1 keyboard operable as, while WCAG does not
>> > define "operable", we all understand that to be that keyboard operation
>> > a site must be actually operable for the user and so match the expected
>> > keyboard patterns. Wouldn't we fail a site that overrode tab key as the
>> > keyboard operation for moving focus?
>>
>> No, not necessarily. 2.1.1 doesn't define normatively that the
>> keyboard experience must match any "expected" patterns. Only that
>> there must be a way to be able to use the keyboard.
>>
>> Do you fail something announced as a button, but which reacts to Enter
>> but not Space, for instance? Again, this normatively passes 2.1.1.
>> Yes, you can then tell the client that really they should change it to
>> match the expected behaviour of a button, but to a strict reading of
>> 2.1.1.
>> And the understanding for 2.1.1 also gives no indication that the
>> intention ever was to fail "unexpected"/"non-standard" keyboard
>> operation.
>>
>> P
>> --
>> Patrick H. Lauke
> > > http://webaim.org/discussion/archives
> > > > > >


--
Work hard. Have fun. Make history.