Website Redesign Accessibility Checklist: Designing for WCAG From the Start

Website redesign accessibility is easiest to achieve when it is treated as a delivery requirement from discovery—not as a final audit after templates, content and components are already locked. A practical redesign checklist should cover research, information architecture, visual design, content, CMS migration, front-end development, forms, SEO preservation, testing and post-launch monitoring.

For most organizations, WCAG 2.2 is the current reference point for planning accessible digital experiences. Your team should still confirm the applicable legal, contractual and procurement requirements for the project, because a technical target and a legal obligation are not always identical.

What accessibility changes in a redesign

Accessibility affects more than color contrast or keyboard focus. It influences how users find information, understand page structure, complete tasks, recover from errors and use the site with assistive technology or alternative input methods.

A redesign can improve accessibility by simplifying navigation, clarifying content hierarchy, replacing inaccessible interaction patterns and establishing reusable components. It can also introduce risk when a team migrates inaccessible content, removes meaningful page structure, changes form behavior or treats a third-party widget as outside the project scope.

The key decision is whether accessibility is a quality attribute built into the system or a defect category checked at the end. The first approach is usually more efficient because issues are resolved at the source—in a design token, component, content model or template—rather than repeatedly patched across individual pages.

Website redesign accessibility checklist

1. Define the accessibility scope and success criteria

• Identify the site areas, templates, applications, documents, forms, media and third-party tools included in the redesign.
• Set a documented WCAG conformance target, such as Level AA, and record any approved exceptions.
• Identify important user tasks, including searching, contacting the organization, requesting a quote, purchasing, registering or downloading information.
• Assign ownership for accessibility decisions across product, design, content, development, QA and legal or compliance stakeholders.
• Decide how accessibility issues will be prioritized. A blocked primary task should usually outrank a low-impact cosmetic defect.

Scope matters because a polished public website can still create an inaccessible journey through a form provider, scheduling tool, PDF library or authenticated portal. Document dependencies early rather than discovering them during launch testing.

2. Audit the current experience before changing it

• Combine automated scanning with manual review. Automated tools can identify patterns, but they cannot reliably judge meaning, task completion or the quality of alternative text.
• Test representative page types rather than only the home page.
• Review keyboard navigation, visible focus, heading order, landmark structure, link purpose, form labels, error handling and responsive behavior.
• Check content at increased text size and browser zoom, including whether content is clipped, overlapped or forced into horizontal scrolling.
• Where possible, include moderated testing with people who use screen readers, keyboard navigation, magnification or other assistive technologies.

Record findings by template and reusable component. If the same issue appears in a global navigation pattern, fixing the component may be more valuable than correcting dozens of page instances separately.

3. Build accessible information architecture

• Use plain, descriptive labels for navigation and calls to action.
• Organize content according to user tasks and mental models rather than internal department names alone.
• Keep page titles, headings and navigation relationships predictable.
• Provide more than one way to find important content when appropriate, such as navigation, search and related links.
• Design a clear route to support, contact information and error recovery.

Information architecture also affects search performance and migration planning. A clear page purpose makes it easier to preserve useful URLs, map redirects and maintain coherent metadata when the CMS changes.

4. Design accessible visual systems and components

• Define color combinations that provide sufficient contrast for body text, interface text and meaningful graphics.
• Never use color as the only way to communicate status, category, selection or error.
• Specify visible keyboard focus states as part of the component design, not as an afterthought.
• Provide adequate target sizes and spacing for interactive controls, especially on touch devices.
• Use typography, spacing and hierarchy that remain understandable when users increase text size or adjust display settings.
• Provide reduced-motion alternatives for animated transitions and avoid motion that could create discomfort or distraction.

Design documentation should show component states, including default, hover, focus, active, disabled, loading, success and error. This helps developers implement behavior consistently and gives QA concrete states to verify.

For broader visual-system planning, connect accessibility decisions to the site’s overall design system and communication needs rather than treating them as isolated technical annotations.

5. Make content understandable and usable

• Write concise headings that describe the content or task that follows.
• Use lists, tables and short sections when they improve scanning and comprehension.
• Write link text that makes sense out of context; avoid relying on repeated phrases such as “click here.”
• Provide meaningful alternative text for informative images and empty alternative text for decorative images.
• Use captions, transcripts or other appropriate alternatives for audio and video.
• Identify the language of each page and mark meaningful language changes where the platform supports it.
• Preserve accessible structure when content is migrated from documents, spreadsheets or legacy editors.

Content migration is a frequent accessibility risk. Copying text into a new CMS does not necessarily preserve heading levels, table headers, list semantics, link context or image descriptions. Treat content remediation as a planned workstream with editorial acceptance criteria.

6. Design forms and error handling around completion

• Associate every form control with a clear label.
• Group related fields, such as address or payment information, when that improves understanding.
• Explain required fields before submission and do not rely only on color or an icon.
• Provide specific, actionable error messages near the relevant field and in a summary when appropriate.
• Preserve entered values when validation fails, unless there is a clear security reason not to.
• Make success, confirmation and next-step information available to assistive technology.
• Review autocomplete, input purpose, time limits and authentication flows for unnecessary friction.

Test the complete form journey, not just the form markup. A form may have technically correct labels but still be difficult to complete if the error summary does not move focus, the confirmation is unclear or a third-party widget cannot be operated by keyboard.

7. Implement accessible front-end behavior

• Use semantic HTML elements before adding custom ARIA behavior.
• Ensure every interactive control is keyboard operable and has a logical focus order.
• Make menus, dialogs, accordions, tabs, carousels and autocomplete fields expose their state and purpose correctly.
• Trap and restore focus appropriately in modal dialogs.
• Ensure hidden content is not unintentionally announced or keyboard reachable.
• Make dynamic updates, validation results and loading states understandable to assistive technology.
• Test responsive layouts at different widths and orientations without losing content or functionality.

Custom interactions are not automatically better because they look modern. Before building a bespoke component, confirm that a native control or simpler interaction would be more robust across browsers and assistive technologies.

8. Protect accessibility during CMS and SEO migration

Accessibility and discoverability can both degrade during a redesign migration. Maintain a shared inventory that includes page purpose, content owner, accessibility status, canonical URL, metadata, structured data, redirect destination and analytics requirements.

• Preserve meaningful page titles, headings and descriptive metadata.
• Map changed URLs and test 301 redirects, including important legacy paths.
• Review canonical tags and structured data after templates are deployed.
• Prevent staging, duplicate or obsolete versions from becoming indexable.
• Ensure breadcrumbs and internal links remain understandable and useful.
• Confirm that analytics events still measure important accessible journeys, such as form starts, errors and completions.

For a focused migration control list, see the related guide to 301 redirects in a website redesign. Accessibility work should be coordinated with, not separated from, technical SEO and analytics validation.

9. Test in layers before launch

No single tool or browser combination proves accessibility. Use layered QA:

Test realistic tasks with realistic content. A component may pass a technical check with short placeholder text but fail when a long heading, validation message or translated label is introduced.

10. Monitor after launch

• Run recurring automated scans, while recognizing that scans cannot replace manual testing.
• Include accessibility checks in the definition of done for new components and content templates.
• Monitor support requests and user feedback for recurring barriers.
• Retest after CMS upgrades, design-system changes, analytics updates and third-party integrations.
• Track defects by root cause so repeated issues lead to process or component improvements.
• Assign an owner and due date to remediation items.

Post-launch monitoring is especially important for sites with frequent publishing, multiple content authors or independently managed marketing tools. Accessibility can regress without any intentional design change.

Common redesign accessibility mistakes

Leaving accessibility until the final audit

Late testing often reveals structural problems in navigation, components or content models. By then, the team may be reluctant to change approved designs or migrate data again. Shift checks left by reviewing prototypes, component specifications and content models before development is complete.

Relying on an accessibility overlay as the main solution

An overlay cannot reliably repair every semantic, interaction, content or third-party issue. It should not replace accessible source code, inclusive design decisions and meaningful testing.

Testing only the home page

Users usually encounter forms, search results, articles, account areas, product pages and error states. Build a representative test set based on templates and important journeys.

Fixing contrast while ignoring structure

Color is visible, so it receives attention. But missing labels, poor heading order, inaccessible dialogs and unclear error handling can create more serious task barriers.

Treating PDFs and embedded tools as someone else’s problem

Users experience the entire journey as one service. Inventory downloads, video players, chat tools, scheduling systems, maps and payment or registration providers before committing to the redesign scope.

How to prioritize accessibility work

When time or budget is limited, prioritize by user impact and reach rather than by ease of implementation alone. A useful order is:

1. Remove barriers from critical tasks and primary conversion paths.
2. Fix global components that affect many pages.
3. Resolve issues that prevent keyboard or assistive-technology operation.
4. Improve content and media that are central to decision-making.
5. Address lower-impact defects and polish remaining inconsistencies.

Also distinguish between a one-time remediation and a system fix. Correcting a single image helps one page; improving the CMS field that prompts editors for alternative text can reduce future risk across the site.

Coordinate accessibility with the wider redesign plan

Accessibility should have explicit checkpoints in the redesign schedule: discovery, information architecture, component design, content migration, development, pre-launch QA and post-launch review. It should also share documentation with SEO, analytics and performance work rather than operating as a parallel checklist.

For related technical planning, review performance considerations in a website redesign and the guide to redesign conversion optimization. These topics overlap in practical ways: clear structure, efficient interaction, resilient templates and measurable user journeys support accessibility as well as business outcomes.

If the project needs broader planning across research, UX, content, development, migration and launch governance, the website redesign service overview is the appropriate next resource. The checklist above remains useful regardless of who implements the work: its purpose is to make accessibility a measurable part of the redesign process from the beginning.