WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Relationship between WCAG and the ARIA in HTML specification

for

From: Birkir R. Gunnarsson
Date: Aug 6, 2023 3:10PM


Yup, y'all thought about it a lot more than I did. ;)
What I like about 4.1.1 is how directly you can do validation and how
easily you can just tie the validation to the markup, no
interpretation required.
Working with developers, this one needed the least amount of
explaining or analysis.
Also this means there's inconsistency in where people pin down use of
ARIA, is it 4.1.2 or 1.3.1 or something else. If the issue is caused
by invalid ARIA markup you could just tie it directly to 4.1.1.
Again, easier, more straight-forward.
In terms of issues not necessarily covered by other SCs the one I hvae
the hardest time tying down is interactive elements nested in links.
You can focus them, typically in the correct focus order.
You can interact with them, at least buttons, I can't 100% speak to
checkboxes/radio buttons or dropdowns.
The issue becomes the screen reader markup again, depends on the
screen reader and user agent, so you have to do extra testing to see
if it really has an impact and with what combinations and then assign
it to 4.1.2, instead of just calling it invalid nesting of interactive
elements, which is not allowed in HTML, and call it a day.
Anyways, like I said, a lot of very smart people spent a lot of itme
thinking about this, so I figure they have thought those scenarios
through.
My main gripe, a perspective from the trenches, is that losing this
criterion makes keeping findings consistent becomes that much harder.


On 8/6/23, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
>
>
> On 06/08/2023 12:14, Birkir R. Gunnarsson wrote:
> [...]
>> This is one of the primary reasons I've always been dead set against
>> removing 4.1.1 from WCAG. I've made such comments on a few threads or
>> posts related to this decision, but I am too busy for lengthy academic
>> debates.
>>
>> I just have to trust that those who made that decision, thought all
>> this through a lot more than I did.
> The tl;dr is: invalid markup per se is not a failure. If invalid markup
> leads to actual problems for users, then report the problem under the
> most appropriate SC that deals with that particular problem.
>
> During the discussions leading to the decision, I don't believe we came
> up with problems caused by invalid markup that did not *also* manifest
> themselves in other SCs that are more directly tied to user needs.
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> https://mastodon.social/@patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.