I have sat in more kickoff meetings than I can count, and I still see the same pattern almost every time a company plans a redesign: nobody runs a website accessibility scan before building starts. The conversation covers branding, page speed, the new CMS, maybe a chatbot. Accessibility, if it comes up at all, gets one bullet point near the bottom: “make sure it’s compliant.” Nobody defines what that means. Nobody sets a date for it. It just waits there as a vague promise, usually addressed right before launch, usually in a panic.
As an IAAP certified accessibility specialist, I have watched this play out from both sides of the table. Early in my career, clients brought me in to fix a nearly finished site. More recently, I have been the one trying to convince agencies and in house teams to change that order entirely. My argument is simple, and I make it in almost every pitch now. Before anyone approves a single wireframe, run a website accessibility scan on the current site. Treat the results as part of the design brief, not as a punch list for after launch.
This is not a compliance lecture. It is a practical case for sequencing. I think every designer, developer, project manager, and client stakeholder should hear this before the next redesign starts.
What a Website Accessibility Scan Actually Tells You
A website accessibility scan checks a site against WCAG 2.2, the current Web Content Accessibility Guidelines. It looks for barriers that keep people with disabilities from using the site. Tools like WAVE, axe, and Lighthouse catch a meaningful chunk of issues on their own. They flag missing form labels, images without alt text, and color contrast that fails against the background. They also catch headings that skip levels and links that lead nowhere useful out of context.
A scan cannot replace a human review, and I tell every client that directly. Automated tools typically catch somewhere between a third and half of the accessibility problems on a page. The rest need a person who understands assistive technology to test them by hand. That includes questions like whether a screen reader user can complete a checkout flow. It also covers whether keyboard focus moves in a sensible order, and whether a widget announces its state correctly. A proper baseline covers both. It combines an automated sweep for breadth with manual testing, using a screen reader and keyboard alone, for depth.
This step needs to happen before design work starts, because it gives everyone a shared, factual starting point. Instead of guessing whether the old site is “probably fine,” the team gets a documented list of every problem. It also shows how severe each issue is and which patterns keep repeating. That list becomes a design input, not an afterthought.
Redesigns Are the Riskiest Moment for Accessibility
New Components Introduce New Barriers
People often assume a redesign automatically improves accessibility. They assume new code and a fresh visual system will naturally fix whatever gaps existed before. I wish that were true. A redesign is actually one of the most dangerous points in a website’s life. So much changes at once, and the team races toward a launch date. A website accessibility scan catches this shift before it ships.
New component libraries often skip keyboard support during the rush to build. Custom dropdowns and modals replace native HTML elements that used to work correctly with assistive technology by default. Writers rewrite content and drop alt text, or copy it over without rechecking it. Brand teams shift color palettes and nobody rechecks contrast ratios against the new colors. I have reviewed redesigned sites that scored worse on accessibility than the version they replaced. Nobody carried the old fixes forward, and nobody checked the new patterns before launch.
Waiting Until Launch Costs More
Waiting until the end of a project to think about accessibility gets the sequence backwards. By the time developers finish building and styling a site, and QA begins, fixing a structural problem costs far more. The same fix would have cost far less at the wireframe or component stage. Think of a card grid built with generic divs instead of a proper list. Or think of a navigation menu that traps keyboard focus. Fixing a contrast ratio in a style guide, before development starts, takes minutes. Finding and fixing the same issue after developers applied it across forty templates takes days. It usually means reopening code the team already considered finished.
I now describe this to clients using a simple idea: accessibility debt behaves exactly like technical debt. Every accessibility issue a team defers, rather than designing out correctly the first time, grows more expensive over time. It also gets more entangled with other decisions the longer it sits. A baseline scan at the start of a project stops that debt from accumulating in the first place. Otherwise, the team ends up paying interest on it for years after launch.
The Business and Legal Picture Has Changed the Math
I try not to lead with fear when I talk to clients. Anxiety driven compliance tends to produce shallow, checkbox level fixes rather than genuinely usable sites. But leaving out the numbers would be dishonest. They explain why this conversation happens more often now, and why it belongs earlier in the process.
WebAIM’s annual review of the top one million home pages found that 94.8 percent had detectable WCAG failures. The average page carried 51 distinct errors. The most common problems were mundane and entirely preventable. They included low contrast text, missing alt text on images, unlabeled form fields, empty links, and empty buttons. None of these require exotic engineering to fix. They just require someone to check for them before launch instead of after.
On the legal side, the picture for public sector sites has become considerably more concrete. The Department of Justice enforces Title II of the Americans with Disabilities Act. It requires state and local government entities to meet WCAG 2.1 Level AA. Compliance deadlines vary by population size, and regulators have shifted some of them as extensions came through. Private sector litigation has not slowed down either. Tracking organizations continue to log well over a thousand federal website accessibility cases every year. Plaintiffs’ firms increasingly target sites shortly after a visible redesign. A new site signals that something changed, and it offers an easy target to test.
None of this means a client should scan a site purely to dodge a lawsuit. But it does mean that “we’ll deal with accessibility after launch” no longer counts as a low risk default. It is a bet that nobody notices, and that bet has gotten worse over time. A website accessibility scan turns that bet into a documented, defensible record.
Pitching the Scan Early: What Actually Works in a Client Conversation
This is the part most specialists get wrong, myself included in my earlier years. I used to lead with WCAG success criteria and legal risk. I would watch stakeholders’ eyes glaze over within about ninety seconds. What actually moves a project team is framing. Present the baseline scan as a design tool, not a compliance requirement bolted onto the schedule. Here is the approach I use now. It has worked across agency pitches, in house redesign proposals, and RFP responses alike.
Bring the Data, Not the Argument
Before the pitch, I run a quick baseline scan on the client’s current site. Even an informal one, using a free tool, works. I bring two or three concrete findings into the room. Showing a stakeholder their own homepage failing a contrast check lands differently than any general statistic. It stops being theoretical the moment it is their site on the screen.
Position It as Reducing Rework, Not Adding a Step
Nobody wants another line item in a project plan. So I frame the baseline scan as something that shortens the overall build. It gives the design and development teams a documented list of patterns to avoid before they start building anything. That beats discovering the same broken patterns during QA, after developers already coded them forty times across the site.
Attach It to a Phase That Already Exists
Every serious redesign already has a discovery or audit phase, where the team reviews existing analytics, content, and technical debt. A website accessibility scan fits naturally into that phase. I do not ask for a new phase. Instead, I ask for one deliverable added to a phase the client already pays for.
Give It a Deadline That Matters to Them
I connect the scan’s timing to a decision the client is already making. Usually that means the point where the team signs off on wireframes or locks a design system. I explain that once those get approval, every accessibility issue baked into them multiplies across the whole site. That framing usually gets the scan scheduled before that milestone, not after it.
Name a Specific Number of Findings, Not a Vague Promise
In one recent engagement, a baseline scan on a mid sized nonprofit’s site turned up 12 distinct issues. Each one was high impact and repeated across every template. That included an accordion widget with no keyboard support and a donation form with unlabeled required fields. Naming that number, 12 patterns rather than 12 isolated bugs, gave the client’s project manager something concrete to show. It also gave the design team a clear reference point.
Offer a Lightweight Version If Budget Is Tight
Not every project can afford a full manual audit at the start. I have had success offering a scaled down baseline. This combines an automated scan with two hours of manual spot checking on the site’s most used templates. It is not as thorough as a full audit, but it beats nothing by a wide margin. Even so, it still surfaces the patterns that matter most, before they get built into the new design.
The common thread across all of this is simple. The pitch works best when it stops sounding like a warning. It works even better when it sounds like information the design team would want anyway.
What Belongs in a Proper Baseline Scan
What the Scan Should Cover
A website accessibility scan worth building a project on covers a few specific things. I always walk clients through each one, so they understand what they are paying for. The automated pass should run across the full site, not just the homepage. Problems often cluster on interior templates, like forms, search results, and checkout flows. The polished landing page everyone reviews first usually looks fine by comparison. Manual testing should include navigating key user journeys using only a keyboard. This alone catches a huge share of the issues automated tools miss entirely. Screen reader testing on the most important flows, using something like NVDA or VoiceOver, reveals a lot. It shows whether the underlying structure actually makes sense when you cannot see the page. The team should also check color and contrast. Use the brand palette proposed for the redesign, not the old one.
How I Present the Findings
I avoid handing clients a flat spreadsheet dump of raw scanner output. It overwhelms people. It fails to distinguish a minor issue from a barrier that blocks someone from completing a task. And it does nothing to help a designer understand what to change in the actual mockups. A useful baseline reads more like a short report. It states the problem, roughly how many people it affects, and what the fix looks like in practice. The team should organize findings by severity and by pattern. That way, designers and developers can see which fixes carry the broadest impact. They avoid facing an undifferentiated list of a hundred line items.
I also recommend timing the baseline carefully. It should land before the design team locks the component library, not during development and not after. On one recent project, the scan turned up a repeated pattern across every product page. A carousel there caused two problems. Nobody could operate it by keyboard, and it failed to announce slide changes to screen reader users. We caught it while the component still lived in Figma. The fix took one quick conversation with the designer about swapping the carousel for a simpler, tabbed layout. Imagine the same issue surfacing three months later instead. By then, developers had already built the component and reused it across dozens of templates. The fix would have meant rebuilding a shared piece of the design system under deadline pressure. Every dependent team would have waited on the change.
Answering the Objections You Will Actually Hear
Clients rarely say no outright. They raise specific concerns, and each one has a real answer. A website accessibility scan supplies the specifics behind every answer below.
“We don’t have the budget for a full audit right now.” This is where the scaled down baseline earns its keep. A partial scan focused on the most trafficked templates costs far less than a full audit. It still catches the patterns that would otherwise repeat across the whole redesign.
“Our developer said the new framework handles accessibility automatically.” No framework does this on its own. Modern component libraries make accessible patterns easier to implement correctly, but they do not enforce correct usage. Teams still build custom components that bypass whatever the framework provides by default. A scan checks the actual output, not the framework’s marketing claims.
“We’ll fix it after launch if anyone complains.” This position tends to change fastest once a client sees their own current error count. Waiting for a complaint means waiting for a real person to hit a real barrier. By then, the fix competes with every other post launch priority for engineering time. It nearly always slips.
“Accessibility will make the design less creative.” This objection softens quickly once I show examples of accessible sites that are also visually distinctive. The constraint is narrower than people assume. It rules out a handful of specific patterns, like relying on color alone to convey meaning. It still leaves enormous creative room everywhere else.
Bringing It Back to the Brief
None of this requires a client to become an accessibility expert overnight. It requires one change in sequencing: run the scan before design work begins, not after the team finishes the build. That single shift changes what the design brief includes. It also changes what the component library supports and what the QA phase actually checks for. By then, the team has already designed out the major structural issues. Nobody has to discover them too late to fix cleanly.
I have seen the difference this makes on real projects. Sites where the baseline scan happened during discovery consistently launch with far fewer accessibility issues. Sites that treated it as a post launch cleanup task launch with far more. The teams building them also spend noticeably less time on rework, because the patterns were right from the start. That is the pitch, stated plainly: a website accessibility scan at the start of a redesign is not extra work. It is the fastest way to avoid doing the same work twice.
If you are the one making this case internally or in a client pitch, keep the ask small and specific. Do not ask for a commitment to full compliance on day one. Ask for a baseline scan and a short list of the patterns that matter most. Ask for a promise that the design brief will reflect them. Everything else, deeper testing, policy documentation, ongoing monitoring, can follow later. It comes once the team sees that this first step made their job easier rather than harder. That is usually the moment a client stops treating accessibility as a line item. They start treating it as part of how they build instead.
Frequently Asked Questions
What is a website accessibility scan?
It is a review of a website against accessibility standards, most often WCAG 2.2. The review combines automated tools and manual testing to identify barriers that prevent people with disabilities from using the site. The W3C Web Accessibility Initiative explains the underlying standards in detail at w3.org/WAI.
How is a scan different from a full accessibility audit?
A scan, especially an automated one, typically surfaces a portion of the total issues on a site. It works quickly across many pages. A full audit adds manual testing with a keyboard and screen reader, which produces a more complete, prioritized picture. Deque offers a clear breakdown of what each level of testing catches at deque.com/blog.
Which WCAG level should a redesign target?
Most organizations reference WCAG 2.1 or 2.2 Level AA as the practical target. So do most legal requirements, including the ADA Title II rule for public entities. The W3C maintains details on the current version at w3.org/TR/WCAG22.
Can free tools catch everything during a baseline scan?
No. Free tools like WAVE genuinely help with a first pass, and WebAIM maintains them well. Even so, they only catch a portion of real world barriers. Pair them with manual testing. Find WebAIM’s tool at wave.webaim.org.
How many accessibility errors does the average website actually have?
WebAIM’s most recent large scale study looked at the top one million home pages. It found that 94.8 percent had detectable failures, and the average page carried 51 errors. Low contrast text and missing alt text ranked among the most common. Read the full report at webaim.org/projects/million.
Does a redesign automatically improve accessibility?
Not on its own. New code and new components can introduce fresh barriers just as easily as they remove old ones. That is why testing needs to happen during the redesign, rather than as an assumed side effect of it. Level Access covers this pattern in its discussion of accessibility debt at levelaccess.com/blog.
References
WebAIM. “The WebAIM Million: The 2025 Report on the Accessibility of the Top 1,000,000 Home Pages.” webaim.org/projects/million/2025
World Wide Web Consortium, Web Accessibility Initiative. “Web Content Accessibility Guidelines (WCAG) 2.2.” w3.org/TR/WCAG22
Deque Systems. “The Business Case for Accessibility.” deque.com/blog/the-business-case-for-accessibility
Level Access. “Accessibility Debt in Software Development, and How to Engineer It Out.” levelaccess.com/blog/accessibility-debt-in-software-development-and-how-to-engineer-it-out
UsableNet. “Web Accessibility Lawsuits: Trends and Strategies for Mitigating Risk.” usablenet.com
U.S. Department of Justice, Civil Rights Division. “Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities.” Federal Register, ada.gov
International Association of Accessibility Professionals. “Certified Professional in Accessibility Core Competencies (CPACC).” accessibilityassociation.org/cpacc