E-mail List Archives
Re: WebAIM-Forum Digest, Vol 190, Issue 4
From: Brooks Newton
Date: Jan 4, 2021 2:50PM
- Next message: John Foliot: "Re: WebAIM-Forum Digest, Vol 190, Issue 4"
- Previous message: Jerra Strong: "Re: Accessible Carousel Working"
- Next message in Thread: John Foliot: "Re: WebAIM-Forum Digest, Vol 190, Issue 4"
- Previous message in Thread: Brooks Newton: "Re: WebAIM-Forum Digest, Vol 189, Issue 19"
- View all messages in this Thread
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 REMOVED> > wrote:
> Send WebAIM-Forum mailing list submissions to
> <EMAIL 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 REMOVED>
>
> You can reach the person managing the list at
> <EMAIL 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 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 REMOVED> >
> To: "Birkir R. Gunnarsson" < <EMAIL REMOVED> >, WebAIM
> Discussion List < <EMAIL 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 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
> > >
> > >
> > >
- Next message: John Foliot: "Re: WebAIM-Forum Digest, Vol 190, Issue 4"
- Previous message: Jerra Strong: "Re: Accessible Carousel Working"
- Next message in Thread: John Foliot: "Re: WebAIM-Forum Digest, Vol 190, Issue 4"
- Previous message in Thread: Brooks Newton: "Re: WebAIM-Forum Digest, Vol 189, Issue 19"
- View all messages in this Thread