The one where I make a public service announcement.

dbushell

A public service announcement clarifying that the ARIA Authoring Practices Guide (APG) is not a best-practices guide for building accessible websites — it exists to demonstrate the ARIA specification for browser and assistive technology developers. The first rule of ARIA use is to prefer native HTML elements over ARIA roles whenever possible. Misuse of ARIA, including pointing LLM agents at the APG to generate accessible components, is actively making the web less accessible. Data from WebAIM confirms that increased ARIA usage correlates with more detected accessibility errors.

ARIA, anti-patterns, and you

This was a great reminder that accessibility isn’t about adding ARIA everywhere—it’s about using the right semantic HTML first.
One thing I’m curious about though:
<ul>
<li>
Have you seen any particular ARIA anti-patterns that AI coding tools or component libraries tend to generate repeatedly?
</li>
<li>
For large teams, do you recommend accessibility linting or automated checks to catch these issues early?
</li>
<li>
And where do you draw the line between “no ARIA is better than bad ARIA” and cases where custom components genuinely need ARIA?
</li>
</ul>
I’d love to hear some real-world examples where removing unnecessary ARIA actually improved accessibility.

More ARIA doesn’t automatically mean more accessible

The best accessibility improvements I’ve made rarely involved adding code. They usually involved deleting unnecessary complexity.