E-mail List Archives

Search E-mail List Archives for

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

From: Vaibhav Saraf
Date: Mon, Dec 28 2020 10:05PM
Subject: WCAG - Fail or not to - Static text tab-focusable in tables
No previous message | Next message →

Hi Everyone,

This is a question on fail or not to, the application in hand uses ng-grid
of Angular 10, the grid in its defaults makes every cell tab-focusable. As
a result all the static text and empty fields take tab-focus.

I am really confused whether to fail this or not. I referred a few older
discussions on the list archives and on github, what I can conclude is that
it is not a violation to make a static text focusable, but ofcourse it is
not the right thing for usability. I want to know your thoughts whether
having all the cells taking focus for a large table including the empty
cells is the right thing or not?

And is there a good reference on how to implement a better version of this
using ng-grid?

Thanks,
Vaibhav

From: Birkir R. Gunnarsson
Date: Wed, Dec 30 2020 8:19AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

This should be a violation under either 2.4.3 (focus order) or even
2.1.1 (keyboard). If the table is large and there is no mechanism to
skip past it it could be near impossible for a keyboard only user to
navigate to anything on the page after the table.
Yes, 2.1.1 is a stretch, but I'd say 2.4.3 is applicable.
And for general keyboard usability, this is just a terrible implementation.
Not sure about this particular framework but Javascript could be added
to strip tabindex="0" from all the elements in the table (at least all
static elements, you'd just need a suitable selector to identify
them).
The important thing is to file this as a bug with the framework
vendor. Ultimately it's their responsibility to fix, but they won't
fix unless it's logged and promoted as a bug.
I'm sure we'd all be happy to comment or promote if we know where the
bug is filed.
Thanks


On 12/29/20, Vaibhav Saraf < = EMAIL ADDRESS REMOVED = > wrote:
> Hi Everyone,
>
> This is a question on fail or not to, the application in hand uses ng-grid
> of Angular 10, the grid in its defaults makes every cell tab-focusable. As
> a result all the static text and empty fields take tab-focus.
>
> I am really confused whether to fail this or not. I referred a few older
> discussions on the list archives and on github, what I can conclude is that
> it is not a violation to make a static text focusable, but ofcourse it is
> not the right thing for usability. I want to know your thoughts whether
> having all the cells taking focus for a large table including the empty
> cells is the right thing or not?
>
> And is there a good reference on how to implement a better version of this
> using ng-grid?
>
> Thanks,
> Vaibhav
> > > > >


--
Work hard. Have fun. Make history.

From: Sailesh Panchang
Date: Wed, Dec 30 2020 8:39AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

Hello Vaibhav,
I second my good friend Birkir.

SC 2.4.3 reads: 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.

Yes, navigation sequences affect meaning or operation when it
needlessly navigates to static content.
So it is surely a failure of the SC.
Thanks
Sailesh
On 12/30/20, Birkir R. Gunnarsson < = EMAIL ADDRESS REMOVED = > wrote:
> This should be a violation under either 2.4.3 (focus order) or even
> 2.1.1 (keyboard). If the table is large and there is no mechanism to
> skip past it it could be near impossible for a keyboard only user to
> navigate to anything on the page after the table.
> Yes, 2.1.1 is a stretch, but I'd say 2.4.3 is applicable.
> And for general keyboard usability, this is just a terrible implementation.
> Not sure about this particular framework but Javascript could be added
> to strip tabindex="0" from all the elements in the table (at least all
> static elements, you'd just need a suitable selector to identify
> them).
> The important thing is to file this as a bug with the framework
> vendor. Ultimately it's their responsibility to fix, but they won't
> fix unless it's logged and promoted as a bug.
> I'm sure we'd all be happy to comment or promote if we know where the
> bug is filed.
> Thanks
>
>
> On 12/29/20, Vaibhav Saraf < = EMAIL ADDRESS REMOVED = > wrote:
>> Hi Everyone,
>>
>> This is a question on fail or not to, the application in hand uses
>> ng-grid
>> of Angular 10, the grid in its defaults makes every cell tab-focusable.
>> As
>> a result all the static text and empty fields take tab-focus.
>>
>> I am really confused whether to fail this or not. I referred a few older
>> discussions on the list archives and on github, what I can conclude is
>> that
>> it is not a violation to make a static text focusable, but ofcourse it is
>> not the right thing for usability. I want to know your thoughts whether
>> having all the cells taking focus for a large table including the empty
>> cells is the right thing or not?
>>
>> And is there a good reference on how to implement a better version of
>> this
>> using ng-grid?
>>
>> Thanks,
>> Vaibhav
>> >> >> >> >>
>
>
> --
> Work hard. Have fun. Make history.
> > > > >


--
Join me at axe-con 2021: a free digital accessibility conference. Read more at
https://www.deque.com/axe-con/
Feel free to contact Deque marketing if you have any questions. Thanks!

Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765

** Stay Positive Test Negative **

From: Patrick H. Lauke
Date: Thu, Dec 31 2020 6:25AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

On 30/12/2020 15:39, Sailesh Panchang wrote:

> SC 2.4.3 reads: 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.
>
> Yes, navigation sequences affect meaning or operation when it
> needlessly navigates to static content.

The *order* seems to be meaningfully correct though. In terms of
operation, it makes it more tedious to operate, but it doesn't *affect*
operation in terms of not making it operable.

2.1.1 specifies that things need to be operable with a keyboard. Again,
it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
not fail, normatively.

Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
SC, but is still horrible usability and should be noted as a best
practice advice.

P
--
Patrick H. Lauke

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

From: Sailesh Panchang
Date: Thu, Dec 31 2020 7:48AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

I encourage the and patient readers to browse through the WebAim
thread started in Nov/2015 and later on had some posts in 2017:
"[WebAIM] Misuse of TabIndex 0"
Thanks and best wishes,
Sailesh


On 12/31/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 30/12/2020 15:39, Sailesh Panchang wrote:
>
>> SC 2.4.3 reads: 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.
>>
>> Yes, navigation sequences affect meaning or operation when it
>> needlessly navigates to static content.
>
> The *order* seems to be meaningfully correct though. In terms of
> operation, it makes it more tedious to operate, but it doesn't *affect*
> operation in terms of not making it operable.
>
> 2.1.1 specifies that things need to be operable with a keyboard. Again,
> it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
> not fail, normatively.
>
> Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
> SC, but is still horrible usability and should be noted as a best
> practice advice.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Join me at axe-con 2021: a free digital accessibility conference. Read more at
https://www.deque.com/axe-con/
Feel free to contact Deque marketing if you have any questions. Thanks!

Sailesh Panchang
Principal Accessibility Consultant
Deque Systems Inc
381 Elden Street, Suite 2000, Herndon, VA 20170
Mobile: 571-344-1765

** Stay Positive Test Negative **

From: Birkir R. Gunnarsson
Date: Thu, Dec 31 2020 9:42AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

I guess it's the luxury of working with one program ;) I can use the
"Birkir says it's a fail" without having to exercise WCAG gymnastics.
I don't use it all the time, but for this problem I wouldn't allow it. *grin*
One more creative option, again a longshot, is evoking 2.1.2 .. if the
table has hundreds of static focusable elements I think one can argue
that while it is not an absolute keyboard trap, for practical
purposes, it acts as one for anyone who needs to navigate to functions
further down the page.
In fact, if the page is in an authenticated environment with session
timeouts, it is possible that getting through the table would be so
slow that the session times out, and then the user is sent back to the
top of the page. In that situation it would be a keyboard trap.
Again, the main issue is to file a bug with React and getting this
resolved for future developers.

On 12/31/20, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> I encourage the and patient readers to browse through the WebAim
> thread started in Nov/2015 and later on had some posts in 2017:
> "[WebAIM] Misuse of TabIndex 0"
> Thanks and best wishes,
> Sailesh
>
>
> On 12/31/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>> On 30/12/2020 15:39, Sailesh Panchang wrote:
>>
>>> SC 2.4.3 reads: 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.
>>>
>>> Yes, navigation sequences affect meaning or operation when it
>>> needlessly navigates to static content.
>>
>> The *order* seems to be meaningfully correct though. In terms of
>> operation, it makes it more tedious to operate, but it doesn't *affect*
>> operation in terms of not making it operable.
>>
>> 2.1.1 specifies that things need to be operable with a keyboard. Again,
>> it doesn't say *how*, or that it must be nice/easy. So 2.1.1 would also
>> not fail, normatively.
>>
>> Long story short, I'd lean towards: doesn't actually hard-fail any WCAG
>> SC, but is still horrible usability and should be noted as a best
>> practice advice.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
>> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> >>
>
>
> --
> Join me at axe-con 2021: a free digital accessibility conference. Read more
> at
> https://www.deque.com/axe-con/
> Feel free to contact Deque marketing if you have any questions. Thanks!
>
> Sailesh Panchang
> Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
>
> ** Stay Positive Test Negative **
> > > > >


--
Work hard. Have fun. Make history.

From: Patrick H. Lauke
Date: Thu, Dec 31 2020 5:30PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

On 31/12/2020 16:42, Birkir R. Gunnarsson wrote:
> I guess it's the luxury of working with one program ;) I can use the
> "Birkir says it's a fail" without having to exercise WCAG gymnastics.

A counterpoint, of course, is that in the worst case you're just making
stuff up and saying it fails WCAG, which does the client (and your
reputation) a disservice...

P
--
Patrick H. Lauke

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

From: Birkir R. Gunnarsson
Date: Thu, Dec 31 2020 9:29PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

That's why I do it very rarely, and only in cases where I believe
there's an honest and major fail for certain users with disabilities,
e.g. keyboard only users. In those cases I back the opinion up with a
documented explanation, sometimes accompanied by a test page or video.

WCAG does not cover all major accessibility/usability fails. More
often, the success criteria are vague or open ended enough to require
interpretation or context. While adherence to a standard is good;
having standards is absolutely necessary;
but usability for the largest possible group of people is what
ultimately makes a difference.

At the end of the day (or year), accessibility is making sure people
with differing abilities can use your website/mobile app/digital
platform. I am willing to stake my reputation on that stance. So far
it's not been called into question frequently.

On 12/31/20, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 31/12/2020 16:42, Birkir R. Gunnarsson wrote:
>> I guess it's the luxury of working with one program ;) I can use the
>> "Birkir says it's a fail" without having to exercise WCAG gymnastics.
>
> A counterpoint, of course, is that in the worst case you're just making
> stuff up and saying it fails WCAG, which does the client (and your
> reputation) a disservice...
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Steve Green
Date: Fri, Jan 01 2021 10:30AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

I'm with Patrick on this one. If you have been asked to audit a website for conformance with WCAG 2.1 AA, then that's what you should do. You should not invent "missing" success criteria. After all, you are not reporting non-conformances with any of the numerous level AAA success criteria, so why should you report anything else that is not included in level A and AA?

If you have been asked to do an "accessibility audit" or an "expert review", then you can invent all the success criteria you like. But a "WCAG audit" has a defined scope and you should stay within it.

You might think you're providing added value, but my experience is that stakeholders do not welcome it. In the vast majority of cases, we find that clients only fix what they have to fix i.e. the level A and AA non-conformances. They don't want to know about anything outside of that.

Of course there are exceptions where clients really care about the user experience, so your context is important in determining what you do and don't report. But that decision should be driven by what your stakeholders want, not your personal biases.

Steve Green
Managing Director
Test Partners Ltd

From: Patrick H. Lauke
Date: Fri, Jan 01 2021 10:35AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

On 01/01/2021 17:30, Steve Green wrote:

> You might think you're providing added value, but my experience is that stakeholders do not welcome it. In the vast majority of cases, we find that clients only fix what they have to fix i.e. the level A and AA non-conformances. They don't want to know about anything outside of that.
>
> Of course there are exceptions where clients really care about the user experience, so your context is important in determining what you do and don't report. But that decision should be driven by what your stakeholders want, not your personal biases.

And even in those contexts, I'd say it's important to make a clear
distinction between what is an actual hard failure of WCAG, and what
does go above and beyond the minimum normative requirements. If nothing
else, for consistency with any other reports/audits from other companies
the client may be getting. Ditto when doing an Accessibility Conformance
Report based on VPAT. Otherwise, it negates the point of them being all
based on the same baseline understanding of WCAG.

P
--
Patrick H. Lauke

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

From: Abi James
Date: Fri, Jan 01 2021 11:50AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

This has been an interesting thread to follow over the New Year holiday but I would agree with the earlier contributions that this is a WCAG failure for all the good examples of negative impact on the user.

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?

For a table where static text is tab focusable I would be highlight to the developer that it has broken the mental model for keyboard users and they should
- if the cells are meant to be interactive (as indicated by receiving focus) then they should be operable with enter or spacebar.
- if the table contains interactive cells then it should match the data grid keyboard pattern where focus is moved through the cells using arrow keys.
- if the table cells are not interactive then they should not receive focus.

As adding focusable elements within a table is highly likely to break a screen reader's table navigation function, I would also make sure the tables are thoroughly tested with a screen reader which may add weight to a 2.1.1 non conformance.

I am not saying I would always fail 2.1.1 for a static text/element receiving focus but when a component has clearly been built to not match expected keyboard operation, as documented in the WAI-ARIA patterns, then it should not be considered accessible.

Regards

Abi James


On 1 Jan 2021, at 17:35, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:

CAUTION: This e-mail originated outside the University of Southampton.

On 01/01/2021 17:30, Steve Green wrote:

> You might think you're providing added value, but my experience is that stakeholders do not welcome it. In the vast majority of cases, we find that clients only fix what they have to fix i.e. the level A and AA non-conformances. They don't want to know about anything outside of that.
>
> Of course there are exceptions where clients really care about the user experience, so your context is important in determining what you do and don't report. But that decision should be driven by what your stakeholders want, not your personal biases.

And even in those contexts, I'd say it's important to make a clear
distinction between what is an actual hard failure of WCAG, and what
does go above and beyond the minimum normative requirements. If nothing
else, for consistency with any other reports/audits from other companies
the client may be getting. Ditto when doing an Accessibility Conformance
Report based on VPAT. Otherwise, it negates the point of them being all
based on the same baseline understanding of WCAG.

P
--
Patrick H. Lauke

https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.splintered.co.uk%2F&amp;data%7C01%7Ca.james%40soton.ac.uk%7C00c5079b8675402ec34e08d8ae7b9cab%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637451193220315464%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=LP%2FJdD8Mfrxkkk2AnNHPP2uODgQKID4x7xfyVt15x7Q%3D&amp;reserved=0 | https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fpatrickhlauke&amp;data%7C01%7Ca.james%40soton.ac.uk%7C00c5079b8675402ec34e08d8ae7b9cab%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637451193220325460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=vZlR1jdCuhLdm5DQxGEMmJc1gk%2FYfwL1qZVZmRU7P68%3D&amp;reserved=0
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fflickr.com%2Fphotos%2Fredux%2F&amp;data%7C01%7Ca.james%40soton.ac.uk%7C00c5079b8675402ec34e08d8ae7b9cab%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637451193220325460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdatas8l8O%2FhjTVoH6haNDfLGmnml2T6z5Ixl0ESYuxNI3g%3D&amp;reserved=0 | https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.deviantart.com%2Fredux&amp;data%7C01%7Ca.james%40soton.ac.uk%7C00c5079b8675402ec34e08d8ae7b9cab%7C4a5378f929f44d3ebe89669d03ada9d8%7C0%7C0%7C637451193220325460%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=%2FnhoWKYDfW38o2ey4ZZ4oPpC0i0moEC9whHgB2tl4pc%3D&amp;reserved=0
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: glen walker
Date: Fri, Jan 01 2021 12:31PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

I think we all agree it's a bad experience but the key is separating
conformance testing (strict adherence to WCAG) from usability testing.
Accessibility is obviously more than about a minimum baseline of
checkpoints, but when hired to do a WCAG conformance test, that's what
should be kept in mind, as Steve talked about. Some companies are just
starting out with accessibility and it can be quite overwhelming, so
sticking to strict WCAG failures is a nice start, but once you move from
that minimum to a more holistic approach and treat accessibility being
about people and not checklists, then this keyboard issue could be
addressed.

Personally, I would not fail 2.1.1 because "All functionality of the
content is operable through a keyboard interface". The fact that you can
also tab to static text is kind of strange, but does not prevent any of the
interactive elements from being operable. And as mentioned before, 2.4.3
is about the "meaning or operation" of the focus order. Again, it's
strange to tab to static text but the order is still accurate and preserves
the meaning. It's not like the static text order is all out of whack - it
still goes in the order of the table. Now, if the static text order were
in some funky order, then it would fail 1.3.2 (if it was not focusable) or
2.4.3 (if it were focusable).

From: Patrick H. Lauke
Date: Fri, Jan 01 2021 2:00PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

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

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

From: Mallory
Date: Sat, Jan 02 2021 6:20AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

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

From: Steve Green
Date: Sat, Jan 02 2021 1:49PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

" 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

From: Birkir R. Gunnarsson
Date: Sat, Jan 02 2021 7:04PM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

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

From: Mallory
Date: Mon, Jan 04 2021 1:40AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

Steve,
>In what possible way is it hurtful to achieve AA conformance?

Birkir answered what I would have said: the example WCAG compliant page with the billion Tab stops is harmful to real people, but passes WCAG. If a client hired me to say that I'd go find them someone with less soul left over to do it instead. There's a place for lawyers who can get their clients off serious charges based on technicalities (the system of the law has to work), but I'd rather not be the one to do it.

You may be thinking of clients who are so awful qua accessibility that even a WCAG audit improves them. This can be true. However many of these are the clients who argue on every point to claim why they don't have to, or make "fixes" that are awful but are now improved enough that you can't in good conscious fail them on that SC anymore (let's say, going from zero keyboard accessibility, a clear fail, to a dynamically-added tabindex=0 to every element, even though that's not what you recommended). They are also the repeat customers, coming back every 6 months or year to have another audit, only to show that they not only invented their own changes but have nothing systemic to keep fixes viable and they get poor scores every time. Sometimes it seems the legal requirement is simply "we recently had a WCAG AA audit" rather than actually fix anything. I only have so many years to live, yo, and I'd like to keep my remaining hairs on my head.

After a lot of thinking, I think I know what this is. Someone I know (a developer) has been running into this at his work as well. A company says "we want to be accessible!" or "accessibility is important to us!" but it turns out what that means is the same thing as "we care about children starving in Africa! We believe that's horrible!" I think a lot of developers have this too. They want, in a generalised foggy way, to be what they consider or were told to be good, but they don't know what that means in a practical manner.
Once they see it, the specific things they need to do, the ideal starts having a cost. This quickly turns into a "let's see what's literally, minimally required by us" check. So where my developer friend worked, it turned out that the company went and checked how compliant they needed to be and discovered that their company is *explicitly named in the nation's accessibility law* as being exempted (even though they receive government funding). Once they discovered that, it was back to "accessibility is important, but our pasty branding colours on links is even more important." And so this is the state of that software today (in 2025 the law will adjust and they'll also have to comply, but I see them doing it like a cat struggling to not get dunked into a bathtub).

And yes, I know people out there advertising services who would know they could pass a billion-Tab-stop page ("it's keyboard accessible, after all!"). They recommend setting overly-verbose aria-labels on everything and don't know best practice techniques, but none of those things fail WCAG. They're (probably) cheaper than I am. Better for the law-abiding client; now they're paying less.

(Where are these people? I tend to find them because they message me on LinkedIn/email offering their services, lol. I'm not saying they're amazing and agree some are insufficient, but I mean, WCAG is a basement-bare minimum, not rocket surgery.)

cheers,
_mallory

On Sun, Jan 3, 2021, at 3:04 AM, Birkir R. Gunnarsson wrote:
> 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/public 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 ADDRESS 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
> >
> >
> >

From: Steve Green
Date: Mon, Jan 04 2021 2:15AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

Mallory, it sounds like your experience of the accessibility market is entirely different from mine. Your statement "clients who are so awful qua accessibility that even a WCAG audit improves them" applies to every client we have ever had.

We have worked for many hundreds of clients and not one of them was anywhere near WCAG AA conformant when they first came to us. In most cases, merely achieving AA conformance was extraordinarily difficult and very few actually got there even after many rounds of fixing and retesting - there are almost always some things that can't be fixed.

If your clients are organisations who already exceed AA and want to get even better, then I would love to know where you find them. In nearly 20 years, I have never encountered a client like that.

I would also add a qualifier to your final statement. Developing a WCAG AA-conformant website is not rocket surgery if you know what you are doing. However, competently testing an existing badly designed website and making the necessary recommendations for changes *is* rocket surgery. Anyone can do it badly, but it's insanely difficult to do well, given the appalling state of most of the websites we are asked to work on. The really scary thing is that despite being appalling, most of them are better than those that are doing nothing about accessibility.

Steve

From: Mallory
Date: Tue, Jan 05 2021 4:14AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | Next message →

Hi,

>Your statement "clients who are so awful qua accessibility that even a WCAG audit improves them" applies to every client we have ever had.

Oh, agreed, this is true over here as well. It's just that with the limit of "WCAG-AA-only" their solutions can become "passing but completely unusable". I'd rather do an "accessibility audit based on WCAG" than limit to "WCAG-only", was my point.

> If your clients are organisations who already exceed AA and want to get
> even better, then I would love to know where you find them. In nearly
> 20 years, I have never encountered a client like that.

I have actually but... they were accessibility companies :P I also occasionally get surprised by how well some random company is, but there's indeed usually something that needs fixing.

>However, competently testing an existing badly designed website
> and making the necessary recommendations for changes *is* rocket
> surgery.

Making good, best-practice-based and ultimately usable-by-real-people recommendations, yes. I think that's where skilled a11y practitioners shine.
For the thing I'm calling limited-to-WCAG-AA, recommendations are often pre-written one-liners. Failing 2.1.1? Recommendation: ensure controls are operable with the keyboard, or similar. For someone who merely wants compliance, that's what they're looking for. More than once my long-winded HTML 101 recommendations were not appreciated ("too difficult for the developers" etc). Also, I'm simply windy :P Different clients are expecting different things. I'd rather work for the ones who want to
1. actually be fairly accessible (not merely have a cert)
2. are willing to learn (or have a dev team that learns) the techniques for doing so.

cheers,
_mallory

On Mon, Jan 4, 2021, at 10:15 AM, Steve Green wrote:
> Mallory, it sounds like your experience of the accessibility market is
> entirely different from mine. Your statement "clients who are so awful
> qua accessibility that even a WCAG audit improves them" applies to
> every client we have ever had.
>
> We have worked for many hundreds of clients and not one of them was
> anywhere near WCAG AA conformant when they first came to us. In most
> cases, merely achieving AA conformance was extraordinarily difficult
> and very few actually got there even after many rounds of fixing and
> retesting - there are almost always some things that can't be fixed.
>
> If your clients are organisations who already exceed AA and want to get
> even better, then I would love to know where you find them. In nearly
> 20 years, I have never encountered a client like that.
>
> I would also add a qualifier to your final statement. Developing a WCAG
> AA-conformant website is not rocket surgery if you know what you are
> doing. However, competently testing an existing badly designed website
> and making the necessary recommendations for changes *is* rocket
> surgery. Anyone can do it badly, but it's insanely difficult to do
> well, given the appalling state of most of the websites we are asked to
> work on. The really scary thing is that despite being appalling, most
> of them are better than those that are doing nothing about
> accessibility.
>
> Steve

From: jeffgutsell
Date: Tue, Jan 05 2021 9:11AM
Subject: Re: WCAG - Fail or not to - Static text tab-focusable in tables
← Previous message | No next message

Hi all,
I just wanted to chime in with the observation that the following is one of
the more memorable quotes I've heard in the past year:
today (in 2025 the law will adjust and they'll also have to comply, but I
see them doing it like a cat struggling to not get dunked into a bathtub).
Mallory, thanks for the wit.

Jeff Gutsell