WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relationship between WCAG and the ARIA inHTMLspecification

for

From: tim.harshbarger@deque.com
Date: Aug 7, 2023 10:35AM

If we have to locate really obscure combinations to try to fail something, is it really a problem then?

It is definitely a question that I find myself thinking about whenever I realize I seem to be looking really hard for a way to fail something and I am having trouble locating it.
-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Steve Green
Sent: Monday, August 7, 2023 11:20 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification

It was embarrassing to have to report a <div> inside a <span> as a non-conformance of SC 4.1.1, but a <button> element inside an <a> element is another matter completely. It's clearly wrong and SC 4.1.1 made it easy to get things like that fixed.

However, in the absence of SC 4.1.1 it seems we have to prove there is an actual problem, which begs the question how do we do that? How many browser and assistive technology combinations do we need to test? We obviously can't test them all. Perhaps we should try to find some obscure combination that reliably fails, so we only need to test with that one.

It seems we're relying on user agent heuristics to provide a good user experience, but where does that leave us with respect to WCAG's "robustness" requirement? There is no way to be sure that future user agents will handle the invalid code nicely.

Steve


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Birkir R. Gunnarsson
Sent: Monday, August 7, 2023 1:52 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] Relationship between WCAG and the ARIA in HTML specification

Yeap, I conceit that there are aspects of how 4.1.1 was interpreted that resulted in a lot of false positives, primarily the duplicate ID values, (only likely to affects accessibility if it's either used for labeling, to communicate an informational relationship, or if the element is a target of JavaScript focus function or CSS selector). Axe Core does this very well.
But, we digress, I see the point in what you're pointing out Patrick.
I am still concerned that removing this SC is not likely to simplify accessibility, but I hope it does.

As for the original question. ARIA in HTML is more of an implementation guide with a mix of normative and best practice recommendations.
I refer to the rules of ARIA from time to time, with some rewroding, and I use the HTML to ARIA mapping table in that document all the time, it is super useful.
So the document is super helpful but I wouldn't consider it a requirement in its own right.


On 8/6/23, Sailesh Panchang < <EMAIL REMOVED> > wrote:
> I went along with the reasoning, "tie the problem caused because of
> 4.1.1 transgression to another SC" but like Birkir, my preference has
> been check code validation first then check for accessibility
> violations.
> Accessibility aside, IT QA I suppose should also be looking at quality
> of code and ensuring code validation would be part of that, no? True,
> only a subset of those validation issues may result in accessibility
> barriers.
> But we are digressing from the question posed in this thread.
> Can one say "rrelationship between WCAG and the ARIA in HTML
> specification" is no different from the broader relationship between
> WCAG and the HTML specs" for instance?
> Thanks,
> --
> Sailesh Panchang
> Customer Success Strategist and Principal Accessibility Consultant
> Deque Systems Inc
> 381 Elden Street, Suite 2000, Herndon, VA 20170
> Mobile: 571-344-1765
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.