If You're Checking for Accessibility at the End, You're Already Too Late

I'll start with a confession: for most of my 25 years in learning and development, accessibility was something I knew I should care about and rarely thought about. I only started to understand what it requires, and why it matters, over the past 18 months.

That's an uncomfortable admission, because I'm one of the learners it's meant to serve. I have significant hearing loss in one ear, and I wear a hearing aid to manage the tinnitus that came with it. Some voices are harder for me to hear than others, certain higher tones don't register at all, and I regularly have to ask people to repeat themselves or speak up. For years, I handled that quietly, on my own, without ever connecting it to the courses I was building for other people.

Last month, I got a lesson in what that gap costs. I sat down to add one card to the Accessibility section of my website's Resources page, and I checked the page against the standards I now hold myself to. It failed them. The text was too small, the filter buttons gave screen readers no indication of what was selected, keyboard users had no visible focus indicator, and the subtitle didn't meet WCAG contrast requirements.

Fixing those issues should have taken an afternoon. Instead, each correction created a new problem. Larger text made the filter labels overflow on phones, and the longer page tripped a site-wide fade-in script that never triggered on a block that tall. For a few hours, the entire page was invisible: an accessibility fix that made the page inaccessible to everyone.

That is what treating accessibility as a final check really costs. You aren't correcting one decision; you're unwinding every decision that was built on top of it.

Why "At the End" Doesn't Work

Disability scholar Mike Oliver introduced the term social model of disability in 1983, and it draws a distinction that changed how I think about my own work. A person's impairment is one thing. The disability is the barrier the environment puts in front of them. My hearing loss is an impairment. A facilitator who won't use the microphone, or a video with no captions, is the barrier.

If barriers come from the environment, then in our field they come from design, and design decisions get made early. Text size, color, navigation, interaction style and media formats are typically locked in during the design phase. By the time an accessibility review happens at the end of development, those decisions have been storyboarded, built, reviewed by stakeholders and approved. Changing them means reopening all of that work.

Software engineer Barry Boehm described this pattern back in 1981: the later a defect is found, the more it costs to fix, because more work has been built on top of it. My Resources page was a small-scale version of the same thing. The text size was never just a text-size decision, because the layout, the mobile behavior and a script on a completely different part of the site all depended on it.

An end-of-project accessibility check doesn't prevent problems. All it does is find them at the point where they're most expensive to fix.

The Learners You'll Never Hear From

The most common objection I hear is a practical one: "We'll accommodate anyone who asks." It sounds responsible. The numbers say it isn't.

According to the CDC, more than 1 in 4 U.S. adults, over 70 million people, report having a disability. In a global survey of nearly 28,000 employees, Boston Consulting Group found that 25% self-identified as having a disability or limiting condition, while their employers reported only 4 to 7%. Most employees with disabilities never tell their employer. And because so many disabilities aren't visible, you can't identify those learners by looking around the room.

I understand that gap from the inside. Every time I ask someone to repeat themselves, I'm doing the accommodating myself. I have to notice the problem, decide it's worth interrupting for, and speak up. An accommodate-on-request model puts that burden on every learner, every time. Many of them, especially new employees, people in compliance training and anyone who has been treated differently after disclosing, will simply stay quiet and learn less.

If you design only for the people who ask, you end up designing for a small fraction of the people who need it.

Where Accessibility Actually Belongs

Building accessibility in from the start doesn't add a phase to your process. It changes what you do in the phases you already have. Here's how that looks in my own ADDIE work.

Analysis.

My learner persona guides now include access needs alongside role, experience and motivation. That doesn't mean guessing at diagnoses. It means assuming the audience includes people with differences in hearing, vision, mobility and cognition, and recording the conditions they'll learn in: noisy break rooms, shared screens, phones, keyboard-only setups.

Design.

I define all 14 color slots in a course's Storyline theme in the style guide, and I check each text and background pairing for contrast before a single slide is built. Navigation, focus order, and what happens to visual-only interactions for screen reader users all get decided in the design document, not discovered during QA.

Development.

Alt text is written at the same time as the content, by the person who knows what the image is supposed to communicate. Captions come from the narration script, which already exists, so you don't have to transcribe the audio after the fact.

Implementation, in the classroom.

For instructor-led training, the same principle applies. Send materials in accessible formats before the session so learners can preview them. Use the microphone every time, even when the room "isn't that big." Repeat audience questions before answering them. Turn on live captions for every hybrid or virtual session. And write all of this into the facilitator guide so it doesn't depend on whoever happens to be presenting that day.

Evaluation.

Testing with a screen reader such as NVDA and an automated checker such as axe DevTools still matters. But its job changes. It should confirm decisions you've already made, not uncover the ones you skipped.

What the Research Supports, and Where It Pushes Back

None of this is new thinking. In 1997, architect Ronald Mace and his colleagues at North Carolina State University's Center for Universal Design published the Principles of Universal Design, arguing that environments should be usable by the widest range of people without later adaptation. CAST's Universal Design for Learning framework applies the same logic to instruction. It treats learner variability as the expected condition and calls for planning multiple means of engagement, representation and action from the start. That guidance was updated as UDL Guidelines 3.0 in 2024.

The most popular argument for this approach is what Angela Glover Blackwell called the curb-cut effect. Curb cuts were built for wheelchair users and turned out to help parents with strollers, travelers with luggage and delivery workers with carts. Captions work the same way. Research from the UK regulator Ofcom found that about 80% of people who use captions aren't Deaf or hard of hearing.

That argument is useful, but it has limits. Legal scholar Blake Reid warns that leaning too heavily on the curb-cut effect can subordinate the needs of disabled people to the convenience of everyone else. If the only reason to caption a video is that it helps everyone, captions become optional the moment a budget gets tight. The primary reason to build accessible learning is that disabled learners are entitled to the same learning as everyone else. The benefits for other learners are a bonus.

Learning science adds one more caveat. Ruth Clark and Richard Mayer's redundancy principle cautions that showing on-screen text that duplicates the narration can increase cognitive load for some learners. That isn't an argument against captions. It's an argument for making them learner-controlled, with a caption toggle the learner chooses rather than text forced onto every screen. That's a design decision too, and it's much easier to make at the start than to retrofit at the end.

What Doesn't Count

If you're hoping a tool can make this go away, the evidence isn't on your side. WebAIM's 2026 analysis of the top million home pages found that 95.9% had detectable WCAG failures, averaging 56 errors per page. The most common failure, low-contrast text, appeared on 83.9% of pages. Those are basic design decisions, not obscure technical problems.

Accessibility overlays, the plug-ins that promise automatic compliance, haven't solved this either. In 2025, the Federal Trade Commission required accessiBe to pay $1 million for deceptively claiming its AI tool could make any website WCAG-compliant. In April 2026, the Department of Justice

and said itself that generative AI "does not yet reliably automate" the remediation of inaccessible content at scale.

No plug-in can retroactively make a design decision you never made.

Build It In

I came to accessibility late, and I'm still learning. But the biggest lesson from these last 18 months is simple. Accessibility isn't a review you pass at the end of a project. It's a set of decisions you make at every stage, and every decision you postpone gets more expensive to make later.

Somewhere in your next audience is a learner who won't ask you to repeat yourself. Design for that person from the start.