WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WebAIM-Forum Digest, Vol 190, Issue 4

for

From: John Foliot
Date: Jan 4, 2021 4:22PM

Edit:

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

JF

On Mon, Jan 4, 2021 at 6:20 PM John Foliot < <EMAIL 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 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 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
>> > > >
>> > > >
>> > > >