Website redesign, launch and maintenance: an accessibility checklist

Why do it at the start

Accessibility problems are cheapest to fix before a page exists. A color palette that fails contrast, a menu that works only on hover or a form built without labels each spreads across every page that uses it. Treat accessibility as a requirement in the brief, like mobile support.

1. Brief and design

• Write the target into the brief: WCAG 2.2 Level AA (levels and versions).
• Check the color palette for text, buttons and borders against contrast ratios before design approval (guide).
• Design visible focus states, error states and form labels, not just the default screens.
• Make touch and click targets comfortable (minimum target size).
• Avoid putting text over busy photos without a solid layer behind it.

2. Build

• Use real elements: headings, lists, buttons, links and form controls (headings, names).
• Keep the focus ring (guide).
• Use fluid layouts and relative units so zoom works (guide).
• Scan each template as soon as it exists, so you catch problems while they are cheap.

3. Content

• Write alt text for meaningful images (guide).
• Caption videos and give audio a transcript.
• Write link text that makes sense out of context.
• Publish accessible documents: tagged PDFs or HTML pages instead of scans.

4. Pre-launch

1. Run an automated scan on a page from every template (free scan).
2. Complete the 15-minute hand check on the home page, a content page, a form and checkout.
3. Fix launch blockers: anything that stops a task by keyboard or screen reader.
4. Write down known issues and a date to fix them, and put them in your accessibility statement.
5. Save the scan results and the dates.

Questions to ask a design or development team

1. Which accessibility standard will the new site target, and who is responsible for checking it?
2. Do the designs include color contrast checks, focus styles and error states?
3. Will you test with a keyboard and a screen reader during the build, and not only at the end?
4. Which components are custom, and how will each one be made keyboard accessible?
5. How will you handle images, videos and documents we already have?
6. What will you give us at handover: a test record, a list of known issues and guidance for editors?

Design stage details

• Color: choose a palette whose text pairs meet 4.5 to 1, and document them.
• Type: pick readable fonts and sizes, with enough line spacing.
• Layout: design for narrow screens first, and check that content reflows at 320 pixels.
• Interaction: design focus states, hover states and error states, not only the default view.
• Content: plan headings and the structure of each template.
• Components: prefer standard patterns for menus, accordions and tabs, and avoid inventing new ones without good reason.

Migrating content

A redesign is a chance to clean up. Before moving content, audit it. Remove pages nobody uses, rewrite vague link text, add missing alternative text, replace images of text with real text, caption important videos and replace scanned PDFs with accessible versions or web pages. If you do this during migration, the new site starts clean. If you do not, you copy old problems into a new template.

Launch-day tests

Budget thinking

Adding accessibility at the start of a redesign usually costs far less than repairing a finished site, because decisions about color, structure and components are made once. Include time in the schedule for testing, fixing and retesting. For a sense of what outside reviews involve, see accessibility audit cost.

Why redesigns often make accessibility worse

A redesign is usually driven by visual goals: a fresh look, new branding, a modern feel. Designers reach for trends such as light grey text, thin fonts, full-screen video, hover effects and custom animated menus. Each is a risk. Thin grey text fails contrast. Hover-only menus fail on touch and with a keyboard. Custom widgets often lack names and keyboard support. When nobody on the project is responsible for accessibility, these risks pass into the finished site, and the cost of repairing them is much higher after launch.

Give accessibility an owner

Name one person on the project who is responsible for raising accessibility questions in each phase. They do not have to be an expert. Their job is to ask: have we checked contrast, have we tested with a keyboard, have we written alternative text. Having someone whose job it is to ask these questions changes what gets done. Add accessibility items to the definition of done for each page and component.

A phased plan

Redirects, URLs and the accessibility statement

During a redesign, page addresses often change. Set up redirects so old links still work, and check that your accessibility statement and contact route are carried over. If a customer has bookmarked a page, they should not hit an error. After launch, scan the redirected pages, since errors on old addresses are a barrier too.

Common redesign pitfalls

• Replacing a working form with a fancy custom one that is not keyboard accessible.
• Moving all content into a single page application without managing focus and titles on navigation.
• Using a full-screen auto-playing video background with no way to pause it.
• Shrinking text and spacing for a minimal look.
• Launching without testing the checkout.
• Forgetting that content editors will need training on the new system.

A worked example: a restaurant's new website

A restaurant commissions a new site with a full-screen video of the dining room, an overlay menu and a booking widget from a third party. The designer proposes pale text over the video and a minimalist menu button without a label.

Because accessibility is in the brief, the team makes four changes before build. The video becomes a short, muted loop with a pause button, and the text sits on a solid panel with strong contrast. The menu button gets the visible word "Menu". The menu itself is made a regular list of links that opens and closes with the keyboard. The booking widget is tested early and found to have unlabeled fields, so the team chooses a different provider that passes the same test. The restaurant also adds the menu as web text, not only a PDF photo. The site launches on time, with a test record and a short statement. Changing the plan at the design stage took a few hours; changing it after launch would have taken days and a costly rebuild of the booking flow.

A launch gate for accessibility

Treat accessibility as a gate in your launch process, just like checking links and forms. Before go-live, someone confirms that the key journeys pass a keyboard test, that every template has been scanned and that high-severity issues are fixed or have a dated plan. If the gate fails, the launch waits or goes ahead with a documented exception that the client understands. A gate keeps the standard from slipping when deadlines get tight.

After launch: the first ninety days

What to include in a redesign brief

A brief sets expectations for everyone who works on the project. A few sentences on accessibility make a large difference to what is delivered, and to how easily you can hold the team to it.

Adapt the words to your needs, and ask each bidder how they will meet them. The answers will tell you which suppliers have done this before.

Comparing suppliers

Handling content during the build

Content is often the last thing to arrive and the first thing to be rushed. Set a deadline for content that leaves time to add alternative text, check headings and caption video. Tell writers about the headings and link text rules early, and give them a short style guide. Ask for transcripts or captions for videos before the build begins, because producing them later delays the launch.

What to do if the budget is tight

1. Prioritize templates and components over individual pages.
2. Choose simple, tested patterns over novel interactions.
3. Cut features that are hard to make accessible and add them later.
4. Plan a second phase for deeper testing after launch, rather than skipping testing.
5. Keep a list of known issues, with dates, and be open about them in your statement.

A short list of things to avoid

• Pale grey text on white, in any size.
• Menus that only open on hover.
• Auto-playing video and carousels with no pause.
• Full-screen overlays that open without warning.
• Icons without labels.
• Custom controls where a native element would do.
• Text embedded in images.

If your design team wants any of these, ask what the accessible version would look like. Often there is a simple alternative that keeps the design intent. If there is not, record the decision and the reason.

Who signs off

Decide before the project starts who gives the final approval for accessibility. This could be the project owner, a named staff member or an outside reviewer. Give them a short list of what they should see before they sign: a scan summary, a keyboard test record and a list of known issues with dates. A signature is only useful if it follows evidence.

5. After launch: a maintenance routine

Clir's One Page assessment includes two rechecks, so you can confirm a round of fixes took effect. See the e-commerce checklist for store-specific points, and the agency workflow if you build sites for clients.