This point smacked me in the face hard a few weeks ago after WebAIM released their survey of the top million websites.
Our tech decisions help create this problem
My go-to examples are routing and focus management. It’s a sad, sorry state of affairs that this critical functionality oftentimes requires third party plugins to make them capable of interfacing with assistive technology. The decision to use SPAs, and all that come with them, can often come from baseless nerd navelgazing—many business owners would be livid to find out that the technology choices their teams are making are actively incurring legal liability.
But this is more than just a technology problem.
Developers don’t know how to build accessible websites
Eric pointed out one of the more depressing aspects of the survey.
In a sea of already demoralizing findings, probably the most notable one is that pages containing ARIA—a specialized language intended to aid accessibility—are actually more likely to have accessibility issues.
I don’t think this is intentional malice on the part of authors, but it is worth saying that the road to hell is paved with good intentions. These failures via omission and ignorance actively separate people from their civil rights.
And I’ll be honest, I struggle with this a lot myself.
Accessibility is hard, particularly if you’re not someone who uses assistive tech to access the web. The way things seem like they should work isn’t always how they actually work.
Accessibility is very contextual
One example I like to come back to is accordions versus toggle tabs.
On the surface, they seems like two different visual treatments of the same type of component: a thing that shows/hides groups of content. But so much about how people who use assistive technology expect to interact with those components is wildly different.
- Are typically a collection of headings with associated content that’s hidden beneath them.
- The heading should be focusable (as in, probably wrapped in a button).
- That button should have an
[aria-controls]attribute on it with a value equal to the ID of the content it shows/hides.
Tabkey on your keyboard should bring you down to the next focusable element, probably the next accordion header.
- Are typically a linked list that points to groups of content.
- Also need the
Tabkey on your keyboard should skip sibling tabs and jump straight into the tab content. Instead, the arrow keys navigate between tabs.
There’s a lot of nuance.
It’s easy for me to say, “You can always just use
querySelector() to get an element in the DOM.” But there are few cut-and-dry statements like that with accessibility.
The decisions you make are driven by the specific thing you’re trying to do, and, often, the content and markup involved.
How do we get better at this?
Eric has a ton of ideas: some social, some technological, some based on people of influence pushing for us to do better here (much like we did with web standards back in the day).
I particularly loved this quote.
Some engineers who work with physical materials have a constant reminder of the gravity of the decisions they make. They wear iron rings to be reminded that they have an obligation to the public good, and that actual lives are on the line. I like that idea a lot—I think it’s a concept we as an industry could benefit from if we borrowed from it thematically.
It’d take some organizing to get to a place where we do such a thing. And maybe that’s a good thing—right now it feels like we’re an industry of overpaid, fly-by-night plumbers who have the luxury of saying they don’t believe in using wrenches.
Culturally, I want there to be more shame around not building things accessibly.
I don’t really love negative, stick-based motivation. But too often, we seem comfortable building inaccessible experiences that “we’ll fix later.” That’s not ok. You should feel like shit if you knowingly do that.
But I also really loved Ethan’s thoughts on focusing on one thing instead of accessibility at large.
Basically, aim to do one thing this week to broaden your understanding of how people use the web, and adapt your design or development practice to incorporate what you’ve learned.
Resources for learning
Per Ethan, I’d recommend picking just one thing and diving into it. Here are some resources to help.
- I really like the A11Y Newsletter, but it throws a lot at you and can be overwhelming if you’re just getting started.
- The A11Y Project is an awesome collection of patterns, checklists, articles, and more around accessibility. It’s best-in-class.
My most valued resource around learning this stuff is people willing to answer dumb questions. For me, those include…
I’d love to see more accessibility woven into tutorials and courses elsewhere, too.