E-mail List Archives

You are here: Home > Community > E-mail List Archives > View Thread

Thread: WebAIM-Forum Digest, Vol 189, Issue 9

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

From: Schneider, Cindy R (DHS)
Date: Wed, Dec 16 2020 12:09PM
Subject: WebAIM-Forum Digest, Vol 189, Issue 9
No previous message | Next message →

Hello, please unsubscribe me from this list, as I'm not working in this area any longer. Thanks!

From: Brooks Newton
Date: Thu, Dec 31 2020 1:04PM
Subject: Re: WebAIM-Forum Digest, Vol 189, Issue 19
← Previous message | Next message →

Like Birkir, I'd call tab stops on static text a failure every time. From
my personal view, it is not permissible to include non-interactive elements
in the page focus order and have the page WCAG-compliant. I understand and
accept that others disagree.

Here's how I get to my conclusion to exclude non-interactive elements from
the focus order using the normative language in S.C. 2.4.3 Focus Order:

The normative text from this S.C. 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." I think including non-interactive elements in the navigation
sequence definitely affects the meaning or operation of focusable
components. People expect page components that receive focus to be
interactive. When they encounter an interface component with tab stops
that aren't actionable, they give up trying to interact with it.
Effectively, including non-actionable focusable elements in the page focus
order, can make the component inoperable because the users expectation of
the meaning of tab stops isn't met and they think the interface is broken.

Here's another way I get to that conclusion that non-interactive elements
should be excluded from the page focus order, this time as interpreted
through the informative language in S.C. 2.4.7 Focus Visible:

Can we all agree that all elements in the page focus order require a
visible focus indicator under S.C. 2.4.7 Focus Visible? One of the stated
benefits in the Understanding Document for S.C. 2.4.7 Focus Visible says
the following: "This Success Criterion helps anyone who relies on the
keyboard to operate the page, by letting them visually determine the
component on which keyboard operations will interact at any point in
time." If you place a visual focus indicator (VFI) on focusable
non-interactive elements to maintain the continuity of the VFI in the page
focus order, you are tricking users. You are tricking users by failing to
meet the explicit SC benefit and associated user expectation that elements
with visible focus indication are keyboard operable.

Just my two cents.

Brooks

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_-2617979330802611193_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Thu, Dec 31, 2020 at 1:03 PM < = EMAIL ADDRESS REMOVED = >
wrote:

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Patrick H. Lauke)
> 2. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Sailesh Panchang)
> 3. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Birkir R. Gunnarsson)
>
>
>
> ---------- Forwarded message ----------
> From: "Patrick H. Lauke" < = EMAIL ADDRESS REMOVED = >
> To: = EMAIL ADDRESS REMOVED =
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 13:25:58 +0000
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> 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
>
>
>
>
> ---------- Forwarded message ----------
> From: Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 09:48:32 -0500
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> 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 **
>
>
>
>
> ---------- Forwarded message ----------
> From: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Thu, 31 Dec 2020 11:42:39 -0500
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable in
> tables
> 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.
>
> > > > >

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From: Brooks Newton
Date: Mon, Jan 04 2021 2:50PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 4
← Previous message | Next message →

Hi,

I still stand by my statement about non-interactive elements in the focus
order. In my book, that's a WCAG fail. Last time I checked, "failing" a
page component in a WCAG review isn't synonymous with prioritizing errors
for clients. In other words, it's not OK to say that page conforms to WCAG
just because you personally don't think that errors you've found aren't
important. That's not how the WCAG conformance model works. I've been
part of the Accessibility Guidelines Working Group for the last four
years. And I can tell you that each and every A and AA Success Criterion
included in the WCAG standard is a big deal to someone, in terms of being a
potential deal-breaker. Removing non-interactive tab stops from the focus
order of the page is an easy fix to make, and that fix alleviates all sorts
of confusion about the role of non-interactive elements to keyboard users.
It also removes unnecessary blocks in the way of keyboard users advancing
to the content they want in the page content order.

I know it is hard to imagine for some, but not everyone is going to "get
it," in terms of being able to go ahead and operate an interface that is
scattered with non-interactive elements in the tab order of the page. For
some, this is a deal breaker. I also don't buy for one second that
establishing and meeting user expectations don't matter when it comes to
designing implementing web page content. Of course they matter.
Guidelines 3.2 (Predictable) and 3.3 (Input Assistance) are all about
managing user expectations. I don't need anyone on this thread to validate
my ticket as an expert in this field. Resorting to name calling in an
attempt to dissuade honest discourse about accessibility issues is what
bullies do. Not everyone agrees with how WCAG applies to various content
constructs. We don't all move in lock step. If we did, I think it would
look a bit fishy. There are many subjective points in this line of work.
Don't ever let anyone tell you differently. It's OK to disagree - just
make your argument using data, not resorting to childish ad hominem attacks.

Brooks

On Mon, Jan 4, 2021 at 1:03 PM < = EMAIL ADDRESS REMOVED = > wrote:

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Mallory)
> 2. Re: WCAG - Fail or not to - Static text tab-focusable in
> tables (Steve Green)
> 3. Code fix for every cell in a table being focusable (Mark Magennis)
> 4. Re: Code fix for every cell in a table being focusable
> ( = EMAIL ADDRESS REMOVED = )
> 5. Re: Code fix for every cell in a table being focusable
> (Swift, Daniel P.)
> 6. Accessible Carousel Working (Radhika Soni)
> 7. Re: Accessible Carousel Working (Jerra Strong)
>
>
>
> ---------- Forwarded message ----------
> From: Mallory < = EMAIL ADDRESS REMOVED = >
> To: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >, WebAIM
> Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Mon, 04 Jan 2021 09:40:05 +0100
> Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable
> in tables
> 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: John Foliot
Date: Mon, Jan 04 2021 4:22PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 4
← Previous message | Next message →

Edit:

...not really a candidate for for *aria-labeledby*...

JF

On Mon, Jan 4, 2021 at 6:20 PM John Foliot < = EMAIL ADDRESS REMOVED = > wrote:

> Brooks writes:
>
> > I still stand by my statement about non-interactive elements in the
> focus order. In my book, that's a WCAG fail.
>
> Hi Brooks,
>
> I am going to respectfully disagree, at least slightly.
>
> There are indeed use-cases and scenarios where placing non-interactive
> content in the tab order is actually important, and in fact may be
> necessary; the most common one being important text (<p>) embedded part way
> in a form - text that is related to a part of the form, but not
> specifically to an input (so thus, not really a candidate for aria-label or
> aria-describedby). For non-sighted users, with their screen readers in
> "Forms Mode", they might miss that important text as they tab from one
> input to the next (expected behavior), because the reading experience in
> Forms mode is different. Because of that difference, I'd in fact invoke *Success
> Criterion 1.3.2 Meaningful Sequence*, which states:
>
> "*When the sequence in which content is presented affects its meaning* (i.e.
> the important text needs to be read aloud in the middle of, and in the
> context of, the larger form)*, a correct reading sequence can be
> programmatically determined.*"
>
>
> So personally, I would avoid broad statements like that as being, if
> nothing else, a wee bit too simplistic.
>
> I do agree however that we're also seeing a trend where some developers
> "over-react" and try to make everything (or specific elements, such as
> Headings) tab-focusable, at which point they are introducing searious
> usability concerns (although, I am curious, if you consider it a WCAG Fail,
> which SC is it failing?). In those cases, I do agree that it's not helpful,
> and in fact can be harmful [sic] for some users.
>
> Respectfully,
>
> JF
>
> On Mon, Jan 4, 2021 at 4:51 PM Brooks Newton < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> Hi,
>>
>> I still stand by my statement about non-interactive elements in the focus
>> order. In my book, that's a WCAG fail. Last time I checked, "failing" a
>> page component in a WCAG review isn't synonymous with prioritizing errors
>> for clients. In other words, it's not OK to say that page conforms to WCAG
>> just because you personally don't think that errors you've found aren't
>> important. That's not how the WCAG conformance model works. I've been
>> part of the Accessibility Guidelines Working Group for the last four
>> years. And I can tell you that each and every A and AA Success Criterion
>> included in the WCAG standard is a big deal to someone, in terms of being
>> a
>> potential deal-breaker. Removing non-interactive tab stops from the focus
>> order of the page is an easy fix to make, and that fix alleviates all
>> sorts
>> of confusion about the role of non-interactive elements to keyboard users.
>> It also removes unnecessary blocks in the way of keyboard users advancing
>> to the content they want in the page content order.
>>
>> I know it is hard to imagine for some, but not everyone is going to "get
>> it," in terms of being able to go ahead and operate an interface that is
>> scattered with non-interactive elements in the tab order of the page. For
>> some, this is a deal breaker. I also don't buy for one second that
>> establishing and meeting user expectations don't matter when it comes to
>> designing implementing web page content. Of course they matter.
>> Guidelines 3.2 (Predictable) and 3.3 (Input Assistance) are all about
>> managing user expectations. I don't need anyone on this thread to
>> validate
>> my ticket as an expert in this field. Resorting to name calling in an
>> attempt to dissuade honest discourse about accessibility issues is what
>> bullies do. Not everyone agrees with how WCAG applies to various content
>> constructs. We don't all move in lock step. If we did, I think it would
>> look a bit fishy. There are many subjective points in this line of work.
>> Don't ever let anyone tell you differently. It's OK to disagree - just
>> make your argument using data, not resorting to childish ad hominem
>> attacks.
>>
>> Brooks
>>
>> On Mon, Jan 4, 2021 at 1:03 PM < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>> > Send WebAIM-Forum mailing list submissions to
>> > = EMAIL ADDRESS REMOVED =
>> >
>> > To subscribe or unsubscribe via the World Wide Web, visit
>> > http://list.webaim.org/mailman/listinfo/webaim-forum
>> > or, via email, send a message with subject or body 'help' to
>> > = EMAIL ADDRESS REMOVED =
>> >
>> > You can reach the person managing the list at
>> > = EMAIL ADDRESS REMOVED =
>> >
>> > When replying, please edit your Subject line so it is more specific
>> > than "Re: Contents of WebAIM-Forum digest..."
>> > Today's Topics:
>> >
>> > 1. Re: WCAG - Fail or not to - Static text tab-focusable in
>> > tables (Mallory)
>> > 2. Re: WCAG - Fail or not to - Static text tab-focusable in
>> > tables (Steve Green)
>> > 3. Code fix for every cell in a table being focusable (Mark Magennis)
>> > 4. Re: Code fix for every cell in a table being focusable
>> > ( = EMAIL ADDRESS REMOVED = )
>> > 5. Re: Code fix for every cell in a table being focusable
>> > (Swift, Daniel P.)
>> > 6. Accessible Carousel Working (Radhika Soni)
>> > 7. Re: Accessible Carousel Working (Jerra Strong)
>> >
>> >
>> >
>> > ---------- Forwarded message ----------
>> > From: Mallory < = EMAIL ADDRESS REMOVED = >
>> > To: "Birkir R. Gunnarsson" < = EMAIL ADDRESS REMOVED = >, WebAIM
>> > Discussion List < = EMAIL ADDRESS REMOVED = >
>> > Cc:
>> > Bcc:
>> > Date: Mon, 04 Jan 2021 09:40:05 +0100
>> > Subject: Re: [WebAIM] WCAG - Fail or not to - Static text tab-focusable
>> > in tables
>> > 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: Patrick H. Lauke
Date: Mon, Jan 04 2021 6:27PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 4
← Previous message | Next message →

On 04/01/2021 21:50, Brooks Newton wrote:
> I still stand by my statement about non-interactive elements in the focus
> order. In my book, that's a WCAG fail.

Alas, that's the rub. People are all reading from their own books, which
all seem to infer things from various parts of WCAG that aren't
necessarily in the normative text of WCAG. We're not arguing whether
this is an error that can be handwaved, but more fundamentally if this
is a situation that does normatively fail WCAG or not. And opinions are
split on this.

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: sangi usha
Date: Sun, Jan 17 2021 4:00PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

Sure ,Hunt

On Sun, Jan 17, 2021 at 4:03 AM < = EMAIL ADDRESS REMOVED = >
wrote:

> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://list.webaim.org/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Re: Known accessibility hurdles with popular design systems
> (Brooks Newton)
>
>
>
> ---------- Forwarded message ----------
> From: Brooks Newton < = EMAIL ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> Cc:
> Bcc:
> Date: Fri, 15 Jan 2021 14:18:05 -0600
> Subject: Re: [WebAIM] Known accessibility hurdles with popular design
> systems
> Thanks for the link, Birkir. I've looked through some of those resources
> already, and will check out the others I haven't yet reviewed. Thank you!
>
> I'm wondering if folks have found known accessibility issues in popular
> Design Systems, such as the ones listed in this 2019 article "10 Best
> Design Systems for 2019
> <https://www.webdesignerdepot.com/2019/08/10-best-design-systems-for-2019/
> >
> ":
>
> - Material
> - Fluent
> - Shopify Polaris
> - Mailchimp
> - Atlassian
> - Apple
> - IBM Design Language
> - AirBnB
> - Uber
> - Lightning Design System
>
> I've worked with a number of production teams who automatically assume that
> if it is a big name Design System and/or JS Framework, then it must already
> be vetted and fully approved for accessible use by people with
> disabilities. Are there any accessibility specialists who are reading this
> who have encountered the same assumptions on the part of their teammates
> who don't know much about accessibility? How do those assumptions match up
> with the reality of your testing? Should this community work together to
> test what the out of the box design system and/or framework provides, in
> terms of WCAG compliance? What about providing comprehensive guidance to
> help unknowing but well-intended production teams get their brand name
> frameworks, pattern libraries and style guides remediated for
> accessibility? Should we consider other accessibility benchmarks that may
> offer a more reliable measure of accessibility performance in fact versus
> in theory?
>
> It can be overwhelming, even frightening to take on the full brunt of the
> accessibility problems a site can have as a lone organization, or worse
> yet, as a lone accessibility specialist. In this forum and via other
> accessibility venues, I hear a lot of talk about in the weeds accessibility
> issues that content authors are required to take on themselves in
> isolation. But, I don't hear nearly as much talk about putting our minds
> together and trying to assess and fix known platform accessibility issues
> at a more centralized and efficient spot - such as at the Design System or
> JS Framework level. Why is that?
>
> Believe you me, I've got many ideas along these lines that have sprung from
> my frustration at bailing water out of the proverbial accessibility boat
> while taking on massive leaks from centralized sources that are frankly,
> beyond the scope of what individual content authors and site owners are
> best positioned to tackle. Who is in the best position to tackle
> accessibility problems at a centralized location?
>
> Brooks Newton
>
>
> On Fri, Jan 15, 2021 at 10:40 AM Birkir R. Gunnarsson <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> > check out
> >
> https://www.webaxe.org/web-accessible-code-library-design-systems-patterns/
> > It's a place to start.
> >
> >
> > On 1/12/21, Brooks Newton < = EMAIL ADDRESS REMOVED = > wrote:
> > > Hello All,
> > >
> > > Similar to my previous post, I've got a question for everyone. Does
> > anyone
> > > know of a collection of known accessibility hurdles associated with the
> > > most popular design systems in use today by web site production teams?
> > If
> > > there isn't any one authoritative collection, then maybe folks on this
> > > discussion list can supply their own observations from implementing and
> > > testing design systems in their own work. The observed hurdles can be
> > > WCAG-related or outside of the formal WCAG umbrella.
> > >
> > > Wouldn't it be wonderful if site owners and content authors could have
> a
> > > clear understanding of the baked-in accessibility problems they will
> > > inherit when they adopt a design system to support their organization's
> > > needs?
> > >
> > > Thanks!
> > >
> > > Brooks Newton
> > > > > > > > > > > > > > >
> >
> >
> > --
> > Work hard. Have fun. Make history.
> > > > > > > > > >
>
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> Virus-free.
> www.avg.com
> <
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail
> >
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> > > > >

From: Brooks Newton
Date: Thu, Jan 21 2021 12:11PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

Hi All,

This post is related to my call for known accessibility hurdles in popular
design systems. I haven't gotten any responses, so let me start.

Here's a question for everyone: How do "sticky" interactive elements, such
as a sticky button, or sticky headers/footers work for sighted keyboard
users who browse without the aid of assistive technology (AT)?

For what it's worth, the way I've seen sticky buttons featured in various
design systems is where they are intended to be used as always-visible,
quickly accessible mechanisms for users to activate important page
controls. Sometimes sticky buttons are used to activate the primary
function of the page. That's important stuff. And for a lot of users,
having a sticky button always positioned in the same portion of the
viewport works great! One reason content authors like sticky buttons is
that they allow page designers to pile lots and lots of content into a
single web page without making the primary button hard to discover and/or
tedious to activate. I mean, sticky buttons are always right there on the
screen for users to click or touch, aren't they?

Well, sticky buttons work great with a mouse cursor or via touch. But,
what happens when, for whatever reason, a user can't use a mouse or touch
to press the sticky button? What if users have to interact with the page
using a keyboard? Are keyboard users as close as a click, a touch, a Tab
press away from the sticky button? The answer is no, not in the default
implementations I've come across. Maybe you all have had better
experiences. Tell me where I'm getting this wrong.

Has anyone on this email list ever tried to Tab to a sticky button on a
long page starting in the middle of the focus order? It's very frustrating.
It's kind of like toying with a cat, except you are the cat. You start
getting excited as you visually move keyboard focus through the Tab order
of the page getting closer and closer to the sticky button that's, let's
say, positioned at the bottom of the screen. Right when it looks like you
are about to move focus to the sticky button, the button jumps down the
screen as the page scrolls in the browser, putting the important button
just out of keyboard focus reach. In most web page implementations, this
frustrating experience continues until you, the keyboard user, reach the
bottom of the page. And, the bottom of the page may be a long, long way
away from where you start Tabbing. The way I've seen sticky buttons
implemented most frequently is to insert the sticky button at the end of
the DOM, after all of the other content on the visual page. So the button
looks like it is always close by in the page focus order, when in actuality
it is not close at all.

Now, we could say that it is the content owner/author's duty to remediate
the component by supplying a keyboard shortcut that would allow keyboard
users to quickly move focus to and interact with the sticky button. But
what keyboard shortcut should the page author use? She doesn't want to use
a keyboard shortcut that is already reserved for the browser and/or
assistive technology purposes. There are other issues page authors should
think about when choosing keyboard shortcuts, such as the provisions in the
WCAG 2.1 rule, SC 2.1.4 Keyboard Shortcuts. This is getting tricky,
needless to say. All of these considerations put a lot of pressure on each
and every web site owner and author out in the wild to make substantive
changes to a design system component they might have thought was already
good-to-go, in terms of accessibility. What will the result be if we are
all tasked with taking this on alone? Asking lone organizations to handle
this task in isolation will likely yield a mishmash of different
implementations, different keyboard shortcuts - ultimately a nightmare for
well-intentioned site owners/authors and their keyboard using customers
who, frankly, deserve better.

What do we do? Well, for one, we could adjust the current accessibility
governance model by asking all parties to the user interaction to do their
parts to make the content accessible. In other words, share that
responsibility for making sticky buttons accessible to keyboard users with
browser makers, AT makers, and standards organizations.

Maybe browser manufacturers could get together with assistive technology
manufacturers and choose one easily teachable keyboard shortcut so that all
keyboard users will know exactly what shortcut to use to move focus to a
sticky button, regardless of the site they are visiting. That would help
wares manufacturers to not step on each others' toes, so to say, in picking
reserved keyboard shortcuts. Standards organization(s) would have to work
in conjunction with the wares manufacturers to create and adopt
semantically meaningful HTML markup that would give user agents the "hook"
they need to know specifically what content is sticky content on the page.
This type of coordination would sure make life easier for content
owners/authors, as well as keyboard users. This collaborative approach
that emphasizes shared responsibilities would help in solving similar
situations, like when keyboard focus is mostly hidden underneath a sticky
header or sticky footer. Ever had that happen to you? I have. It's
disorienting for keyboard users to only see a sliver of the visual focus
indicator, if they can see it at all. If we had markup that would identify
a sticky footer, the user agent would know how to render the page so that
focused elements aren't hidden underneath author-defined sticky regions!

How do we get the appropriate players to work together in a collaborative
space where responsibilities are shared? That's hard to say. For some
specific digital accessibility issues, keeping content owners/authors as
the sole parties responsible for enabling digital access makes sense.
That's the way the system is set up now. All of WCAG, for example, is on
the site owner's/author's plate of responsibilities. But in my opinion,
asking wares manufacturers and standards bodies to help out is the best
approach to doing the organized heavy lifting required to make digital
accessibility feasible for owners/authors to implement, and easy for users
to understand and use.

Sticky buttons and sticky regions are two examples that illustrate how
working together in the spirit of shared responsibility makes the most
sense to clear hurdles to access. There are many, many other accessibility
scenarios where sharing responsibilities makes the best sense. I'm sure
the readers of this post can help think of some and add to this
conversation.

Brooks Newton

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_8169591751787689673_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

On Sun, Jan 17, 2021 at 5:01 PM sangi usha < = EMAIL ADDRESS REMOVED = > wrote:

> Sure ,Hunt
>
> On Sun, Jan 17, 2021 at 4:03 AM < = EMAIL ADDRESS REMOVED = >
> wrote:
>
> > Send WebAIM-Forum mailing list submissions to
> > = EMAIL ADDRESS REMOVED =
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > http://list.webaim.org/mailman/listinfo/webaim-forum
> > or, via email, send a message with subject or body 'help' to
> > = EMAIL ADDRESS REMOVED =
> >
> > You can reach the person managing the list at
> > = EMAIL ADDRESS REMOVED =
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of WebAIM-Forum digest..."
> > Today's Topics:
> >
> > 1. Re: Known accessibility hurdles with popular design systems
> > (Brooks Newton)
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Brooks Newton < = EMAIL ADDRESS REMOVED = >
> > To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
> > Cc:
> > Bcc:
> > Date: Fri, 15 Jan 2021 14:18:05 -0600
> > Subject: Re: [WebAIM] Known accessibility hurdles with popular design
> > systems
> > Thanks for the link, Birkir. I've looked through some of those resources
> > already, and will check out the others I haven't yet reviewed. Thank
> you!
> >
> > I'm wondering if folks have found known accessibility issues in popular
> > Design Systems, such as the ones listed in this 2019 article "10 Best
> > Design Systems for 2019
> > <
> https://www.webdesignerdepot.com/2019/08/10-best-design-systems-for-2019/
> > >
> > ":
> >
> > - Material
> > - Fluent
> > - Shopify Polaris
> > - Mailchimp
> > - Atlassian
> > - Apple
> > - IBM Design Language
> > - AirBnB
> > - Uber
> > - Lightning Design System
> >
> > I've worked with a number of production teams who automatically assume
> that
> > if it is a big name Design System and/or JS Framework, then it must
> already
> > be vetted and fully approved for accessible use by people with
> > disabilities. Are there any accessibility specialists who are reading
> this
> > who have encountered the same assumptions on the part of their teammates
> > who don't know much about accessibility? How do those assumptions match
> up
> > with the reality of your testing? Should this community work together to
> > test what the out of the box design system and/or framework provides, in
> > terms of WCAG compliance? What about providing comprehensive guidance to
> > help unknowing but well-intended production teams get their brand name
> > frameworks, pattern libraries and style guides remediated for
> > accessibility? Should we consider other accessibility benchmarks that
> may
> > offer a more reliable measure of accessibility performance in fact versus
> > in theory?
> >
> > It can be overwhelming, even frightening to take on the full brunt of the
> > accessibility problems a site can have as a lone organization, or worse
> > yet, as a lone accessibility specialist. In this forum and via other
> > accessibility venues, I hear a lot of talk about in the weeds
> accessibility
> > issues that content authors are required to take on themselves in
> > isolation. But, I don't hear nearly as much talk about putting our minds
> > together and trying to assess and fix known platform accessibility issues
> > at a more centralized and efficient spot - such as at the Design System
> or
> > JS Framework level. Why is that?
> >
> > Believe you me, I've got many ideas along these lines that have sprung
> from
> > my frustration at bailing water out of the proverbial accessibility boat
> > while taking on massive leaks from centralized sources that are frankly,
> > beyond the scope of what individual content authors and site owners are
> > best positioned to tackle. Who is in the best position to tackle
> > accessibility problems at a centralized location?
> >
> > Brooks Newton
> >
> >
> > On Fri, Jan 15, 2021 at 10:40 AM Birkir R. Gunnarsson <
> > = EMAIL ADDRESS REMOVED = > wrote:
> >
> > > check out
> > >
> >
> https://www.webaxe.org/web-accessible-code-library-design-systems-patterns/
> > > It's a place to start.
> > >
> > >
> > > On 1/12/21, Brooks Newton < = EMAIL ADDRESS REMOVED = > wrote:
> > > > Hello All,
> > > >
> > > > Similar to my previous post, I've got a question for everyone. Does
> > > anyone
> > > > know of a collection of known accessibility hurdles associated with
> the
> > > > most popular design systems in use today by web site production
> teams?
> > > If
> > > > there isn't any one authoritative collection, then maybe folks on
> this
> > > > discussion list can supply their own observations from implementing
> and
> > > > testing design systems in their own work. The observed hurdles can
> be
> > > > WCAG-related or outside of the formal WCAG umbrella.
> > > >
> > > > Wouldn't it be wonderful if site owners and content authors could
> have
> > a
> > > > clear understanding of the baked-in accessibility problems they will
> > > > inherit when they adopt a design system to support their
> organization's
> > > > needs?
> > > >
> > > > Thanks!
> > > >
> > > > Brooks Newton
> > > > > > > > > > > > > > > > > > > >
> > >
> > >
> > > --
> > > Work hard. Have fun. Make history.
> > > > > > > > > > > > > > >
> >
> > <
> >
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > Virus-free.
> > www.avg.com
> > <
> >
> http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail
> > >
> > <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
> > > > > > > > > >
> > > > >

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#m_8169591751787689673_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

From: Jonathan Avila
Date: Fri, Jan 22 2021 1:52PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

There are a few options in addition to using a keyboard shortcut. The functionality should likely also be available elsewhere on the page - such as at the top of the page. The sticky control might also be best as the last control on the page allowing the user to move to the address bar and then shift+tab to reach it. Other options include some sort of keyboard link at the top of the page that would expose hot keys and/or allow you to jump to the sticky control much like a skip link. On mobile sticky controls are often the default control of the app and some assistive technology has keystrokes to perform a default action.

Really what we need is a way to access a list of page level actions from anywhere in the browser. That is a page could expose page level actions through an API that the user could access in the way that works best for them. The same thing could be implemented similar to how the adjustable rotor works for a specific control with multiple actions on iOS or Android.

Jonathan

From: Brooks Newton
Date: Tue, Jan 26 2021 1:09PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

Great points, Jonathan. Are any of those extra instructions intended to
mitigate accessibility hurdles associated with sticky floating content
included in design system instructions? Any way for organizations who use
design system components to know that there's more accessibility work to do
than just using an out-of-the-box solution? That question is for anyone
who's reading this.

When production staff adopt a big name design system, I believe that many
assume all is ready to go, in terms of accessibility. I think we've
established that out-of-the-box accessibility is an arguable point for some
design system component types. NOTE: As an accessibility specialist, it is
very demoralizing to have to convince unknowing production staff and
managers that there are often significant remediation steps necessary to
bring big name design system components into compliance with WCAG, for
example. It sets up an antagonistic dynamic and makes it even harder for
us to do a very difficult job.

Here's another known accessibility issue (in my opinion), which I've found
in multiple big name design systems: automatically disappearing content.

In particular, I'm talking about notifications that appear on the screen
and disappear after a set period of time without a user actively dismissing
the content. I'm talking about things like snackbars, toasts, etc. that
don't give users the ability to turn off the message duration time limit,
or don't give users the ability to prolong the length of time the message
remains on the screen.

Again, tell me where I'm wrong here, but in my honest opinion I can't see
how this type of out-of-the-box component passes WCAG 2.0/2.1 SC 2.2.1
Timing Adjustable Level A. Maybe it is OK if you provide a personalization
option for not automatically dismissing content as part of the site's user
settings? But, that's not part of any out-of-the-box component I've seen.
And, I think the default setting in this scenario should be to make
messaging persistent unless a user actively chooses to make messaging
temporary. Let me know if anyone has an easy solution for this fundamental
accessibility problem. SC 2.2.1 is one of a limited number of success
criteria that seek to make content accessible to people with cognitive
disabilities, as well as other disabilities that make it hard for people to
read and/or interact with content given an arbitrary time limit.

Think about how critical it can be to have a message remain on the screen
to read in these unsettled times. Nerves are frazzled, stress is high,
attention is hard to focus. Maybe an organization decides to use a design
system to stand up an online COVID-19 vaccination portal quickly. Maybe
the page authors use a component with automatically disappearing content
that informs users that "Your scheduled vaccination appointment was not
reserved - try again in 30 seconds." What if a user with a disability
isn't able to read that automatically disappearing content quickly enough
and thinks that everything is all set for the appointment time they think
they have booked? Too bad, I guess. We can and should do better than that.

If you add a close button to a pop-up announcement that floats on a
different layer above the main page content, we've at least given the user
control over when to dismiss the announcement. But, in the process of
making the pop-up announcement remain on the screen until actively
dismissed, we've introduced the same types of keyboard issues I spoke about
in my previous post about sticky floating buttons. This brings me back to
my call for new HTML markup that content authors can use to designate
floating/sticky content, so that user agents and assistive technology have
the "hook" they need to give users immediate access to the content and
associated close button. It won't work for a standards body to create the
markup, add it to guidelines and hope that it is adopted by wares makers
and content authors alike. The effort must be collaborative and
coordinated.

Digital accessibility is difficult to understand, and even harder to design
and code into practice. In my opinion, it is harder than it has to be
because we have pushed the fixes required to remediate digital content down
the line to individual organizations and production line contributors.
Instead, we should try to address these key global issues further up the
chain where standards bodies and wares makers can have the greatest impact
for the greatest number of users. Anyone else have thoughts on this?
Again, let me know where I've gotten this wrong. Anyone have additional
known design system accessibility hurdles they like to discuss?

Brooks Newton

On Fri, Jan 22, 2021 at 2:52 PM Jonathan Avila < = EMAIL ADDRESS REMOVED = >
wrote:

> There are a few options in addition to using a keyboard shortcut. The
> functionality should likely also be available elsewhere on the page - such
> as at the top of the page. The sticky control might also be best as the
> last control on the page allowing the user to move to the address bar and
> then shift+tab to reach it. Other options include some sort of keyboard
> link at the top of the page that would expose hot keys and/or allow you to
> jump to the sticky control much like a skip link. On mobile sticky
> controls are often the default control of the app and some assistive
> technology has keystrokes to perform a default action.
>
> Really what we need is a way to access a list of page level actions from
> anywhere in the browser. That is a page could expose page level actions
> through an API that the user could access in the way that works best for
> them. The same thing could be implemented similar to how the adjustable
> rotor works for a specific control with multiple actions on iOS or Android.
>
> Jonathan
>
>

From: Steve Green
Date: Tue, Jan 26 2021 7:13PM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

I agree with your point about automatically disappearing content being a WCAG non-conformance. Even if you apply an ARIA live region, it only benefits screen reader users. Screen magnifier users are very likely to miss the content completely.

When you refer to design systems, do you mean JavaScript frameworks like Angular or things like https://design-system.service.gov.uk/? The latter is highly accessible, but not comprehensive (although they are always adding to it). However, every JavaScript framework that has ever existed has been plagued with serious accessibility issues. Also, most of the third-party plug-ins for them are even worse. Perhaps the reason your question did not get many responses is because it's far too broad. Almost everything is bad in every framework - it's easier to list the things that don't need to be fixed.

Frankly, I find it appalling that almost no "professional" developers (let alone development managers) seem to be aware of this. Accessibility has been part of their job description for 20 years, so how can they not know about it?

That said, I still take a very soft approach when explaining it to them, precisely to avoid the antagonism you mention. I don't tell them that they have to do anything - testers shouldn't do that. I just tell them the way things are and the consequences of the various options they have, which includes not changing anything. If they want a VPAT or an accessibility statement (which all UK public sector websites must now have), I tell them that it will have to include every single non-conformance they choose not to address. They are not keen to be publicly embarrassed like that, so I find that they almost always do what needs to be done.

Steve Green
Managing Director
Test Partners Ltd

From: Jonathan Avila
Date: Thu, Jan 28 2021 11:13AM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | Next message →

While I agree there should be options to keep notifications persistent - it's complex - I think this issue might also be solved by allowing the user to expand a notifications area of their choosing as long as that disclosure control was visible. It could also indicate new notifications present. Having notifications popup and persist has it's own issue when multiple notifications come in and take up the screen and then you have issues when there are so many you can't fit them on the screen - then what? You almost need to dismiss them because there is no place to put new ones! Notifications are also very distracting and features to mute, etc. will also be needed. I think we'd need to do some research to find out what is practical for users.

Jonathan

From: Brooks Newton
Date: Thu, Jan 28 2021 11:58AM
Subject: Re: WebAIM-Forum Digest, Vol 190, Issue 14
← Previous message | No next message

For what it is worth, I filed a GitHub bug for the ARIA Practices repo
associated with automatically disappearing toaster messages two and a half
years ago.

Alert Dialog Example: Is disappearing toaster alert WCAG compliant? #756
<https://github.com/w3c/aria-practices/issues/756>

Needless to say, I was not satisfied with the answer I received. These
days I see lots of excuses for why we should not enforce certain WCAG AA
rules. I know it is hard to create engaging, modern web content and still
be in compliance with WCAG. I don't think the answer is to hand out passes
that allow content authors to use controls and design patterns that don't
support access. I think the answer, as Jonathan points out, is to gather
more user data from people with disabilities and to work those solutions
into broad, easy-to-implement solutions that all content authors can use
without the need for custom scripting at the site level.

Brooks Newton

>
>
>
>
>