Skip navigation

Surfacing Accessibility Problems

Posted May 13, 2020

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.

You should definitely go read his post in full, but the short version is that he noted that the latest edition of the WebAIM One Million survey showed that increased numbers of accessibility issues appear to be correlated with certain Javascript frameworks.

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.

Meme: a guy (developers) slapping duct tape (ARIA) on a leaking tank of water (learning about accessibility)
Well-intentioned, but perhaps a little lazy.

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.

The infamous Windows blue screen of death
Ok, it might be slightly more subtle than this.

If your Javascript throws an error, you'll be alerted to it in the console. If your CSS syntax is wrong, the browser will tell you in the dev tools. In both cases, things won't look and/or work the way you expected, usually in an obvious fashion. HTML is a little more resilient since browsers will attempt to correct some issues for you, but more serious issues will likely still be apparent.

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?

A browser console warning that says 'Setting a role on a <nav> element can cause problems for users of assistive technologies.' and provides a link for more info.

Or how about an error if your <input> has no accessible name?

A browser console error stating that an input element on the page has no accessible name, with a link to a labelling tutorial.

Right now, these kinds of warnings are only surfaced if a developer goes out of their way to use a tool like WAVE or aXe. But browsers could easily do it themselves.

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:

A popup hovering over an inspected input element. The popup shows accessibility info such as the name, role and focusable status of the element.

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...

Share

Contact

  • Contact me on Twitter
  • Contact me on LinkedIn
  • Contact me by Email