The WCAG Accessibility Work You Think You're Doing vs. The Work You're Actually Doing
- Alain Davids
- Mar 12
- 6 min read
Updated: Mar 17
I grew up playing video games, and one design from that world has changed how I think about accessibility more than anything I've read in a guidelines document.
Xbox's adaptive controller lets players with physical impairments customize how they interact with the game entirely. One-handed players. Players using foot pedals. Players who could never pick up a standard controller.
It doesn't feel like a workaround. It feels like better design.
That's the standard I try to hold myself to as a learning designer. And for a long time, I wasn't meeting it.
The Comfortable Illusion of "Good Enough"
For a long time, my accessibility practice was contextual. For organization-wide content, the kind every employee would complete, we took it seriously. We produced JAWS-compatible versions of courses and made sure the basics were covered. That felt like enough.
It took a closer look at WCAG (the Web Content Accessibility Guidelines) to realize how much further the scope extends. Not because I didn't care, but because I hadn't fully considered how many touch points in a learning experience actually need to meet the same standard.
WCAG sounds like compliance jargon. Layers, criteria, conformance levels. It can feel like something your legal team worries about, not something that shapes how you build a learning experience. But once you understand the framework underneath it, it becomes something else entirely. A genuinely useful design lens.
WCAG Accessibility: The Four Principles Worth Knowing
Everything in WCAG sits under four principles, remembered by the acronym POUR.
Perceivable focuses on your content design. Before a learner can engage with anything, they have to be able to receive it. Captions, transcripts, alt text on images, and sufficient colour contrast all live here. If someone can't see your image or hear your audio, the content might as well not exist for them.
Operable addresses your interaction design. Can learners actually navigate what you've built? This means your course works with a keyboard alone, not just a mouse. Interactive elements have enough time to complete. Nothing flashes in a way that could trigger a seizure. Every click-to-reveal, drag-and-drop, and branching decision needs to be reachable by someone who can't use a mouse at all.
Understandable shapes your instructional design. Is the language clear? Does the course flow predictably? Do error messages in quizzes actually explain what went wrong? A course that's technically perceivable and operable but confusing to navigate has still failed the learner.
Robust governs your build and your LMS. Does the course hold up across different environments and devices? Can screen readers parse the content your authoring tool outputs? This is where your choice of tool and how you use it matters more than most designers realize.
What It Looks Like to Actually Apply This
On a recent project, I worked with a team where we went through all four of these principles.
We mapped tab order across every slide so keyboard-only users could move through the course logically. We wrote transcripts, not just captions, for audio content. We added off-screen text boxes specifically for screen readers to pick up context that sighted users get visually. Every interaction, every drag-and-drop, every click-to-reveal was tested to ensure it could be completed without a mouse.
It was more effort. It was also significantly better design.
And I'll be honest about a couple of mistakes I made along the way.
The first involved text overlaid on video. We used a dark opaque shape behind the text to ensure enough contrast for readability, which is the right instinct. But the client pushed back on how dark the videos looked. Getting the balance right meant going back through and manually adjusting the opacity on every single shape across the course, checking the contrast ratio at each adjustment to make sure the text was still legible without the videos feeling too heavy. It was time-consuming work that could have been avoided with a conversation about contrast requirements earlier in the project.
The second was trying to resolve an audio issue in Storyline using a shape as a workaround. What I didn't realize was that the shape itself became an accessibility problem. Screen readers were picking it up as an unlabelled element, creating confusion for users who couldn't see it was decorative. I was so focused on fixing one problem that I introduced another.
Accessibility isn't always intuitive. You can do the right thing badly.
Why the Urgency Is Real
This isn't just about good design values. The regulatory landscape is shifting fast.
In the US, public colleges and universities fall under a Department of Justice rule requiring WCAG 2.1 Level AA compliance by April 2026. Private institutions and corporate organizations operate under different obligations, but the direction of travel is the same across the board. The European Accessibility Act has already come into force, expanding requirements into the private sector. And the lawsuits are already happening. Over 8,800 ADA accessibility complaints were filed in 2024 alone.
The scale of the audience this affects is also worth sitting with. Around 1.3 billion people globally live with a significant disability, roughly one in six. In higher education, 11% of undergraduates report a disability. And yet the WebAIM Million report, which analyzes the top one million websites annually, found that 94.8% have detectable WCAG failures. The average page has 51 accessibility errors.
A Simple Audit to Start With
The most common reason teams don't do this work isn't that they don't care. It's that it gets deprioritized when time is tight. The best answer to that is building accessibility into your process from the start rather than retrofitting it at the end. A five-minute check during development costs a fraction of what it takes to fix after launch.
It's also worth remembering that accessibility doesn't stop at the edge of your authoring tool. A course can pass every WCAG check and still ship with an inaccessible Word document or PDF attached to it. Most teams don't catch it because the attachment sits outside the tool and outside the checklist. It's one of the easiest things to overlook and one of the most common gaps I see.
Start by asking yourself these questions during your next build:
Can you tab through your entire course using only a keyboard?
Does every image have alt text that describes its purpose, not just its appearance?
Does your text pass a colour contrast ratio check?
Do your videos have captions, and do you have transcripts for audio content?
Can every interaction be completed without a mouse?
Have you tested with a screen reader using a basic checklist, or better still, involved someone who actually uses one?
That last point matters more than it might seem. Brief, untrained screen reader testing can give you false confidence. You won't navigate it the way a real user does. WebAIM publishes screen reader user surveys and testing guides that are worth using as a starting point, and if you can involve an actual screen reader user in your testing process, do it.
A few free tools worth having in your process:
Articulate's built-in accessibility checker — a practical first step that many designers overlook entirely
WebAIM's contrast checker — free and takes thirty seconds to check any colour combination
WAVE browser extension — gives you a fast visual overlay of accessibility issues on any page
NVDA (Windows) or VoiceOver (Mac) — free screen readers for basic testing without specialist software
A11y Project checklist — community-maintained, maps directly to WCAG, and built for practical day-to-day use
None of these require a big time investment to get started. The barrier is usually awareness, not effort.
The Real Opportunity
Accessibility isn't a compliance exercise. It's a design quality signal.
Something I read recently reframed this for me entirely. The argument was simple: accessible design isn't a subset of good UX design. It just is good UX design. When you design for the full range of human experience from the start, you make better decisions for everyone. The constraints that accessibility introduces aren't limitations. They're the same constraints that produce cleaner navigation, clearer language, and more intuitive interactions across the board.
I remember the moment this shifted for me even further. Early in my accessible design journey, someone introduced me to the idea of the curb cut. Curb cuts, those small ramps built into sidewalks at crossings, were originally designed for wheelchair users. But watch who actually uses them. Parents pushing prams. Delivery workers with trolleys. Cyclists. Someone on crutches after a ski accident. A toddler on a scooter.
Nobody designs a curb cut and worries that non-wheelchair users are benefiting from it. That's the point.
The same logic applies to everything we build in learning. Captions help a Deaf learner and also someone learning in their second language, someone in a noisy open-plan office, someone whose audio has cut out mid-module. Off-screen text for screen readers helps a visually impaired learner and also anyone whose context needs more explanation than a visual alone can carry.
WCAG gives you a structured way to design for the full range of human experience. That's not a burden. That's what good learning design was always supposed to do.
