Apt, given the earlier discussion around Nolan Lawson's article: when used diligently, ARIA can help turn that div soup into something users, user agents, assistive technologies _and_ developers can make better sense of.
As the article mentions, slapping aria-label on everything won't make an interface accessible and might have unintended consequences.
jauntywundrkind•3h ago
I hate that this burns me out at all, but every job I've been at has insisted on adding some sort of data-test-id throughout the app, and I've always thought it was actively obfuscating seeing what's really happening for a perceived value add of test stability that in fact didn't matter but also actively his what was really changing over time.
Exactly as you say, it drives better accessibility, and gets everyone using the same referants (versus inventing a new third way outside of both query selectors & aria).
rhdunn•3h ago
The ARIA Authoring Practices Guide (APG) [1] is my usual goto for what ARIA markup I need for custom elements, as it is clear on what the keyboard navigation, ARIA roles, ARIA states, and ARIA properties should be for a given element in a given state. That makes implementing and testing it easier than reading the core specs.
ARIA is a 'boil the ocean' solution that primarily helps the accessibility industry. These problems are better solved through accessibility focused computer vision models.
askew•4h ago
As the article mentions, slapping aria-label on everything won't make an interface accessible and might have unintended consequences.
jauntywundrkind•3h ago
Anyhow, it's been a huge morale win to see really good works like the Testing Library strongly emphasize using page accessibility hooks to drive testing! https://testing-library.com/docs/queries/about/#priority
Exactly as you say, it drives better accessibility, and gets everyone using the same referants (versus inventing a new third way outside of both query selectors & aria).