Accessibility Checklist Before a Site Redesign

A redesign is the most common way a website loses accessibility. New templates drop skip links, fancy menus break keyboard focus, and rebuilt forms lose their labels. The damage is invisible to most stakeholders — until a customer complains, a lawsuit lands, or an accessibility audit fails. This checklist is what to do before you redesign, so you preserve what works and fix what doesn't.

1. Audit the current site first

You can't preserve what you haven't measured. Before any design work starts, run an accessibility audit on the live site. Use automated tools to catch the obvious issues (missing alt text, low contrast, empty links, missing form labels), then manually test the things tools miss:

• Tab through every page with a keyboard only. Can you reach and operate every link, button, and form field?
• Turn on a screen reader (VoiceOver on Mac, Narrator on Windows) and try to complete your main conversion task.
• Zoom the browser to 200% and check that nothing overlaps or disappears.
• Check color contrast on text, icons, and focus indicators.

Document every issue with a screenshot and the page URL. This becomes your baseline — and your proof of progress later.

2. Inventory what's already working

Most sites have accessibility wins buried in them: a well-labeled contact form, a logical heading order on the blog, a skip-to-content link someone added years ago. List these explicitly. They are the things your redesign must not break.

Pay special attention to:

• Forms — labels, error messages, and required-field indicators
• Navigation — keyboard operability, focus order, mobile menu behavior
• Media — captions, transcripts, alt text
• Interactive components — accordions, tabs, modals, carousels

If a component works today, write down why it works (e.g., "uses a real <button> with visible focus"). That note is what stops a designer from replacing it with a <div>.

3. Write accessibility into the redesign brief

Accessibility fails when it's treated as a QA step at the end. Put it in the brief as a hard requirement, not a nice-to-have. A simple line works:

All new templates must meet WCAG 2.2 Level AA. Keyboard operability, visible focus, and 4.5:1 text contrast are non-negotiable.

Then attach the audit findings from step 1 as the acceptance criteria. Designers and developers now know exactly what "done" looks like.

4. Decide what to keep, fix, or retire

Not every legacy component deserves to survive. Go through your inventory and sort each one:

• Keep — works well, meets WCAG, no reason to change
• Fix — usable but has known issues (e.g., a carousel that traps focus)
• Retire — rarely used and hard to make accessible (e.g., a custom drag-and-drop widget)

Retiring a broken component is often faster and cheaper than rebuilding it accessibly. Be honest about which is which.

5. Test the new design in low-fidelity before build

Accessibility problems are cheapest to fix in a wireframe. Before high-fidelity mockups, check the new layout for:

• Heading hierarchy — does each page have one H1 and a logical H2/H3 structure?
• Focus order — does the visual order match the DOM order?
• Contrast — do the new brand colors pass 4.5:1 for body text and 3:1 for large text and UI components?
• Touch targets — are interactive elements at least 24×24 CSS pixels (WCAG 2.2 minimum) with adequate spacing?
• Motion — is there a way to pause or disable animations?

If your brand refresh introduced a lighter gray or a pastel accent, this is where you catch the contrast failure — not after launch.

6. Plan the migration, not just the launch

Redesigns often ship in phases. If you're moving to a new CMS, theme, or component library, plan how accessibility carries over:

• Will existing alt text and captions migrate, or will they be lost?
• Will form labels and error messages survive the new form builder?
• Will redirects preserve anchor links and skip links?
• Who owns accessibility after launch — design, dev, or content?

Assign an owner. "Everyone" means no one.

7. Re-test before you go live

Run the same audit you ran in step 1 against the staging site. Compare results side by side. Anything that regressed is a launch blocker, not a "phase two" item.

A quick pre-launch pass:

• Keyboard-only run-through of your top five pages
• Screen reader test of your primary conversion flow
• Automated scan of the full staging site
• Manual contrast check on every new color combination
• Zoom-to-200% check on mobile and desktop

8. Keep accessibility alive after launch

Accessibility is not a one-time project. Add it to your routine:

• Include an a11y check in your content publishing checklist
• Re-audit after every major template or component change
• Train anyone who touches the site — writers, marketers, designers — on the basics
• Track issues in the same backlog as bugs, with the same priority

A redesign is a rare chance to raise the floor. Treat accessibility as part of the brief, test it before launch, and you'll ship a site that works for more people — and avoids the expensive scramble when someone notices it doesn't.

Want a quick read on how your current site performs on accessibility, speed, and the signals that matter for search? Run a free audit and get a prioritized list of fixes before you start rebuilding. For more pre-launch and pre-redesign guidance, browse the guides library.

More guides · Compare audit tools · Run a free website audit