Kilian Valkhof recently posted a great piece about how many accessibility problems stem from the fact that developers often don't even realize that there's anything wrong with the code that they're writing.
His theory was that this is because these frameworks are commonly used by beginner developers who are more likely to be unaware that accessibility is a thing they need to think about.
The road to a11y hell
Whether or not he's correct about the correlation with frameworks is debatable, but the broader point about developers not knowing what they don't know is spot on.
I had been thinking about writing a post similar to his for a while, although in my own musings I was reflecting on the fact that use of ARIA attributes seems to be correlated with higher numbers of accessibility issues as well.
This would seem to represent a slightly different, although related phenomenon to Kilian's theory. Presumably ARIA isn't being used by novice developers who don't even know that accessibility is a thing. Rather, this is likely the work of well-intentioned developers who just don't know that they're doing it wrong.
Regardless of what the case may be, both would seem to come back to the same underlying issue, however—that it's easy to break accessibility without even realizing it.
Break all the things
With most development work, issues are immediately obvious.
None of this is true for accessibility issues.
Particularly so when it comes to ARIA. There's no feedback when you break things. Want to add
role="menu" to all your
<nav> elements? Great! How about slapping
aria-roledescription on everything? Super. While we're at it, let's do this to all our links:
<a href="somewhere.html" target="_blank" aria-label="opens in a new window">actual name of my link</a>
You can do all of those things on your website (with the best of intentions, I might add), and never realize that you've broken anything.
No, REALLY break all the things
So what do we do about this? Kilian's solution is... well... to break things. For example, having browsers not display images that have no alt attribute.
Personally I'm not sure that this is the right approach. For one thing, it seems likely to lead to some unscrupulous responses:
<img src="photo.jpg" alt="."> <img src="photo2.jpg" alt="."> <img src="photo3.jpg" alt="."> <img src="photo4.jpg" alt=".">
While there are some cases where browser interventions make sense, IMO they're few and far between. I don't like the idea of taking control away from responsible developers just because there are others who don't do things correctly.
I think there's a better way: surface those issues in the same way that other detectable problems are surfaced. In the dev tools.
What if you got a console warning when you overrode the implicit semantics of an element?
Or how about an error if your
<input> has no accessible name?
Good things on the horizon
Browsers have been getting better about this in recent years. Firefox now exposes the accessibility tree in the dev tools. Chrome and Edge have an accessibility panel, and are adding a vision deficiency simulator. Just today I opened up the dev tools in Edge (v84) and discovered this:
I don't know if this is something that the Edge team is doing on their own, or part of Chromium (please let me know if you do), but it's exactly the kind of thing that we need. Think about how many developers will become aware of accessibility concerns just by simply putting it front and center like this.
Now, if we can just take things a step further and get some of those scary red console messages on our side...