When thinking about web accessibility, many people tend to focus on checking the boxes: let’s make sure we pass Section 508 compliance, let’s make sure we don’t get yelled at or sued.
As my colleague Trevor Pierce says, this is the fear mindset. It’s doing accessibility as a way of running away from pain.
Accessibility specialist Derek Featherstone has been speaking about the notion of “Accessibility Beyond Compliance” for more than a decade. This concept acknowledges that you need to meet those standards, but accessibility doesn’t stop there. As a researcher, I’ve seen that it’s possible to meet the standards, check the boxes, and still have someone who uses a screen reader not be able to navigate your site because your headings don’t make sense, your links are styled as buttons (or vice-versa), or you otherwise break expected patterns for how real people use real websites.
Accessibility Beyond Compliance isn’t about fear. It’s not running from something. It’s running to an equitable, inclusive future where end users participate in development and where people building websites think about how an actual human being will interact with them. It’s about not being content to rest on your laurels with a clean compliance scan, but instead embracing the work of welcoming your users in, learning how you can do better, and then doing it.
One of my favorite examples of accessibility beyond compliance is podcast accessibility. In theory, you check the box by providing a bare-bones transcript. To go beyond compliance, you should provide an inclusive experience that brings the person experiencing your transcript into the world of the podcast. In audio drama, for instance, this might involve faithfully transcribing inflection and tone using drawn-out spellings, and robustly describing environmental and musical sound design. By using descriptive language and putting in the time and effort it takes to build an experience, as you would for someone listening to the podcast, you can transform words on a page into an immersive experience.
My favorite podcast, Join the Party, does this brilliantly. They put a ton of work into the sound design and that feeling transfers over into the transcripts.
[Amanda laughs]
Michael: Oh, I believe it.
Eric (as Ze’ol): How was aaaaaaah how waaaaassss the thing you had to do? How did it go? I know, I’m just asking because it’s fun. How did it go?
Brandon: Tracey holds up his cannon arm and it’s jammed.
Amanda (as Inara): Uh, yeah, where are we gonna be staying? I really gotta sleep here.
Eric (as Ze’ol): Uh, my room? I don’t… nobody sleeps here. We’re- I’ll keep everything moving. You’re fine.
Ad Hoc’s approach to accessibility involves contributions from every member of a product team. Researchers include people who use screen readers and other assistive devices in usability testing. Designers think about why a link indicates a different action than a button and structure layouts to facilitate scannability. Engineers ensure they use semantic HTML, where the code itself indicates the role of each piece of a page.
We do not pass a site off for an automated compliance check at the end of the process and wait to be told what needs to be fixed; the vast range of human needs permeates how and why we do work at every stage of a project. Everyone is responsible for talking about accessibility as more than treating edge cases and for supporting each other’s continued pursuit of usable accessible web experiences.
At the end of the day, the notion of Accessibility Beyond Compliance gets at the heart of why I do accessibility in the first place. My motivation for becoming a user experience researcher was that I really love people; I love learning about who they are, where they struggle, and where my team can be part of the solution. Accessibility Beyond Compliance also draws from this love of people: it’s not just about code, or laws, or checkboxes, it’s about embracing the rich variety of human experiences, and ensuring equitable access for all.
We’ve expanded this idea into our full Ad Hoc Accessibility Beyond Compliance Playbook covering everything from building products to hiring teams.
