Does making a website accessible mean changing the whole design?
Usually not. Most of what the accessibility standard asks for lives in code and content: alt text, form labels, headings and keyboard access. The change to the look is mostly color contrast, usually fixed by darkening a few colors. Other visible changes are small: links marked by more than color, a visible focus outline, clearer field borders, and tap targets of 24 by 24 pixels or enough space around them. A full redesign is justified when the layout breaks under zoom or a rebuild was due anyway.
What it usually means
The claim is usually sincere, and it comes from one of three places. The brand palette itself fails contrast, so the fix feels like a change to the look: light gray body text, or white button text on a mid-tone brand color. The site was built page by page, in a page builder or an older theme where colors and spacing were set section by section, so every fix has to be repeated on every page; that's real labor, but it's labor. Or the site was due for a rebuild anyway, and accessibility is the reason that's easiest to say out loud.
What the standard actually asks is mostly invisible. WebAIM's annual scan of the top million homepages lists the six most common detected failures, which account for 96% of all the errors it found: low-contrast text (83.9% of homepages), missing alt text (53.1%), missing form labels (51%), empty links (46.3%), empty buttons (30.6%) and a missing page language (13.5%) (WebAIM Million, 2026). Only the first is something a sighted visitor can see. The other five are attributes in the code: fixing them mostly changes what a screen reader announces, not what a sighted visitor sees; the exception is a form that relies on placeholder text, which may gain visible labels. WCAG sets thresholds, not a style. It says how much contrast text needs, not which colors to use, and text that's part of a logo or brand name has no contrast requirement at all.
The claim is right in a narrower set of cases, and they're worth knowing because they're checkable. A layout that can't reflow into one column when someone zooms in, menus and configurators built from custom parts that a keyboard can't operate, and headlines that are pictures of text on every page mean templates have to be reworked. Even then, the brand, the photography, the typefaces and the page structure can usually survive. The thing being rebuilt is the build, not the design, and when a designer says design they often mean the build.
What it costs while it stays this way
Once accessibility is filed under the next redesign, the barriers stay up until that budget exists, which can be years away. The Department of Justice's 2022 web guidance lists the barriers it has in mind: poor color contrast, color used alone to give information, images without alt text, videos without captions, inaccessible online forms, and navigation that needs a mouse (ADA.gov). Every one of those can be fixed on the site you have now. For a supplier, the inaccessible form is the expensive one, because it's usually the quote request. An engineer zoomed in on a phone at the plant, or a buyer who moves through forms with the keyboard, either reaches that form and sends it or quietly doesn't.
The opposite mistake costs more. A new design doesn't make a site accessible; the build and the testing do. If the brief for the redesign never names a target and a test, the new site can launch with the same failures in a fresh layout, and the money spent on the redesign didn't buy the thing it was justified by.
A redesign quote also makes an overlay widget look like the cheap alternative, but a widget patches the page in each visitor's browser after it loads, and the templates and content where the failures live stay exactly as they were. In April 2025 the Federal Trade Commission approved a final order requiring one overlay vendor, accessiBe, to pay $1 million, in part over its claim that its widget could make any website compliant with WCAG (FTC).
How to confirm it yourself
- Run Lighthouse on two pages and read the group headings. In Chrome, open your homepage, right-click and choose Inspect, open the Lighthouse tab, tick only Accessibility, and click Analyze page load. Repeat on your quote or contact page. Failing audits sit under group headings: Contrast, Names and labels, Navigation, ARIA, Tables and lists, Audio and video, Internationalization and localization, and Best practices. Contrast changes what the page looks like, and so can a target-size failure under Best practices, which means a link or icon is too small, or too close to its neighbours, to tap reliably. Everything else is code or content. Count the failures under each heading; that count is your first answer to how much of the work is design.
- Test your brand colors, not your pages. Contrast failures repeat a handful of color pairs across many elements, so find the pairs. With DevTools open, click the Inspect arrow and hover over gray body text, a button and a link; the tooltip shows each one's contrast ratio and a warning if it fails. Copy the two color codes the tooltip shows for any failing pair into WebAIM's free Contrast Checker (webaim.org/resources/contrastchecker/). Body text needs 4.5:1. Large text (about 24px, or about 18.5px bold) needs only 3:1, the same ratio required of icons people need to understand the page, and of form field borders when the border is what shows where the field is. Write down the number of failing pairs. Two or three pairs is a color adjustment.
- Tab through the homepage and the quote form. Click an empty spot near the top of the page, then press Tab repeatedly. You should always see where you are, reach every menu item, and be able to fill in and submit the form. If the focus outline vanishes, that's usually one line of styling someone removed (your developer will recognize outline: none), and putting it back is a small code change. If the dropdown menus only open on hover and can't be reached at all, that menu is a component to rebuild, which is still one component and not the whole site.
- Zoom to 400% and watch the layout. With the browser window maximized on a normal laptop or desktop screen, press Ctrl and plus (Cmd and plus on a Mac) until the zoom reads 400%. That's the reflow test in WCAG 1.4.10. If the content stacks into one column and you only scroll down, the layout passes the core of the reflow test, as long as nothing is cut off, hidden or unusable. If text overlaps, gets cut off or forces you to scroll sideways to read a line, that's a genuine layout problem and the strongest evidence for the designer's view. Note whether it's one element, such as a wide table or a fixed header, or every page. One element is a fix; every page is the case for a rebuild. Data tables, maps and diagrams are exempt, since they need two dimensions to make sense.
- Try to select the headline on your hero image. Drag your cursor across the main homepage headline as if to copy it, or right-click it; if it won't highlight, or you see Save image as, the words are part of the picture. That fails WCAG 1.4.5 Images of Text, which allows pictures of text only where that exact look is essential, a logo being the usual case. And unless the image's alt text repeats the words, a screen reader gets none of them. The fix keeps the look: the same photo, with the headline set as live text on top.
- Find out where a fix has to be made. Press Ctrl+U (Cmd+Option+U on a Mac) to view the page source, then Ctrl+F (Cmd+F) to search it for elementor, et_pb_ (Divi) or vc_row (WPBakery). Any of those means at least part of the site was assembled in a page builder; elementor can turn up when Elementor only builds the header, so check whether it also appears in the main content. On a site built from shared templates or a component library, a color or label fix is made once and reaches every page. On a builder site it may have to be made page by page, unless the builder's global colors and fonts were used. Either way it's a cost question, and the answer should come as an estimate of hours, not as a redesign.
What the vendor's answers actually mean
The same few lines come up whenever accessibility enters a website conversation. Each one has an honest version, and each one can be tested against the checks above.
“Making the site accessible means redesigning it.”
Means at least one of three things: the palette fails contrast, the build repeats its styles on every page, or a rebuild is wanted for other reasons. Ask which WCAG success criteria need a layout change. A real answer names them, usually 1.4.10 Reflow or 1.4.12 Text Spacing for layout, or 2.1.1 Keyboard for a custom menu, which is a component rebuild rather than a layout change. An answer without criteria is a recommendation.
“Your brand colors aren't ADA compliant.”
The ADA doesn't specify colors, and WCAG sets contrast ratios for text and interface parts, with logos exempt. What's usually meant is that one brand color fails when it's used for small text or as a button background behind white text. Ask for the failing pairs and their ratios. The fix is often a darker shade of the same color for text and buttons, with the original kept for everything else. For a light brand color like yellow or orange, the usual fix is the opposite: keep the color and put dark text on it instead of white.
“We can add an accessibility plugin and you'll be covered.”
Usually that means an overlay. The DOJ's guidance treats overlays and automated checkers as tools to use with care, and warns that passing an automated check isn't proof the site is accessible. It's an add-on to the fix, never a substitute for it.
“Lighthouse gives us 100, so we're compliant.”
Lighthouse runs a set of automated audits, and Google's own scoring notes say its manual checks don't count toward the score. WebAIM says the same of every automated tool: not all failures can be detected automatically. A 100 means no automated failures were found, which is a good start and not a certificate.
“We'll make sure the new site is accessible.”
A promise with no target and no test. Ask for the standard in the scope, such as WCAG 2.2 Level AA, how it will be tested (keyboard and screen reader passes, not only a scan), and who fixes failures found after launch.
What actually fixes it
A working answer arrives as a list. Each finding names the WCAG success criterion it fails, where it lives, and which kind of fix it needs. Content fixes are work your own team can do: alt text and link wording in the CMS, and document titles in the PDFs themselves before they're uploaded. Code fixes go into templates once: form labels, button names, the page language, focus styles. Design fixes are color values: a few pairs, ideally defined in one place in a design system so the change reaches every page. Last come the components that need rebuilding, like a hover-only menu. Work the quote form and the navigation first, because a barrier there stops a request from ever being sent. The web accessibility definition covers the principles behind each kind.
A rebuild is the honest answer when the zoom test fails across the site, when custom components fail the keyboard test throughout, when the builder means every fix is repeated on every page and the site was nearing its end anyway, or when the platform itself won't let anyone change the templates, labels or page language. If that's where you land, make it a real decision about redesign vs. rebuild on its merits, and put the target, WCAG 2.2 Level AA, and the test method in the brief, so accessibility is priced and checked from the start rather than retrofitted again. If the page builder is what makes every fix slow, say so in the brief too, because the next site will inherit the same problem if the editing setup doesn't change.
If the quote for the fix still reads as a redesign after the list exists, line it up against the findings. Each line of work should trace to a criterion and a location. Anything that doesn't is a separate piece of work with its own case to make, which is the same test that applies when simple things are billed heavily.
The message to send
This turns a verdict into a list without arguing with it. The reply tells you whether the redesign is a requirement or a recommendation, and it's useful to you whichever it turns out to be.
Hi [name],
Thanks for raising accessibility. Before we decide on a redesign, can you send the findings as a list: each issue, the WCAG 2.2 success criterion it fails, and where it lives (a color value, a template, a component, or page content)?
For anything you think needs a layout change, can you note the criterion that requires it? We'd also like the color pairs that fail contrast, with their current ratios and the closest passing shade you'd suggest. Our target is WCAG 2.2 Level AA.
Could we have the list by [date two weeks out]? Then we can decide what to fix on the current site first and what, if anything, belongs in a rebuild.
Common questions
Will an accessible website look plain?
No. WCAG sets minimums for contrast, size and behavior, not a style. Layout, photography, typefaces and brand colors all survive; the W3C's own explanation of the contrast rule notes that the lower ratio for large text allows a wider range of color choices. What changes is usually the palest gray text and the smallest tap targets.
Do we have to change our brand colors?
Rarely all of them. Your logo has no contrast requirement. A brand color that fails as small text or behind white button text can stay as an accent, a background for large type or an illustration color, with a darker shade of it added for text and buttons. Check each pair with a contrast checker before anyone redraws the palette.
Can we fix accessibility on our current website?
Usually most of it, yes. Labels, alt text, headings, focus styles, the page language and contrast can all be fixed in place. The cases that need more are a layout that fails the 400% zoom test, custom components the keyboard can't operate, and headlines baked into images on every page. Run the checks above to see which of those you have before accepting either answer.
Which WCAG version and level should we ask for?
WCAG 2.2 Level AA is the sensible target for new work. The W3C published it as a Recommendation on October 5, 2023, and it keeps the 2.1 criteria apart from one obsolete one it removed. The DOJ's 2024 rule for state and local government websites names 2.1 AA. That rule covers public bodies, not private companies, but it's the clearest benchmark the government has set, and a site built to 2.2 AA generally clears it too. Level AAA is rarely required for a whole site. This isn't legal advice.
Who should make the fixes, our team or the developer?
Both, split by kind. Your team can write alt text and fix vague link wording in the CMS, and set the title in each PDF's document properties before uploading it. The developer handles labels, focus styles, the page language and anything in templates. Color changes need a designer's eye but not a redesign. Splitting the list this way usually shortens it, because the content half doesn't have to wait for anyone.