Redesign

Website accessibility: what to check before you approve a redesign

Review how customers can use the finished site, with a practical checklist and a clear record of what still needs fixing.

From Charlie’s Web Design · About Charlie

Published 12 October 2026 · 8 min read

The starting point

Before approving a redesigned website, ask the designer to demonstrate the main customer journey with a keyboard, enlarged text and a narrow screen. Check the form’s error and confirmation states as well as its appearance. Record the findings and agree who will fix them. These checks find useful problems; they do not establish full accessibility conformance.

Agree what “accessible” means in the project

A polished homepage is only one part of a usable website. A visitor may need a service description, a project photograph, a booking tool and a contact form before they can decide. Include that complete route in the review, with the cookie choices and any external tool it opens.

Ask which accessibility standard and level the proposal uses, which pages and states will be tested, and who handles issues in supplied content or third-party services. W3C’s Web Content Accessibility Guidelines (WCAG) provide a technical framework. WCAG 2.2 Level AA can be an explicit project target; it should come with an agreed evaluation scope rather than a vague badge.

For a UK or US business, keep that technical target separate from any claim about legal compliance. This article is a practical owner review. It does not decide which legal obligations apply to your business or certify a website.

Choose one real customer task

Write a short task that reflects the website’s purpose: “Find whether we undertake commercial refurbishments, read a relevant project and request a first conversation.” Use the pages a new visitor would encounter, rather than jumping straight to a page you already know.

Make a list of the components on that route: navigation, expandable service information, project viewer, enquiry fields and success message. Include a mobile menu or booking provider if the task needs it. Test each state, not just the closed menu or the empty form.

Ask for the same task to be demonstrated in the agreed preview before launch and checked again at the public address. A preview can differ from production in its scripts, cookie settings and connected tools. Use fictional test details and agree any real submission with the person receiving it.

Use the route without a mouse

Start at the top of the page and use Tab and Shift+Tab to move through controls. Use the appropriate keys to activate them. Ask the designer to show how to open and close the menu, change a tab, view a project and leave a dialog. Ordinary website tasks should have a keyboard route. W3C explains the keyboard requirement and its exceptions.

You should be able to see which control has focus. A focus indicator is different from a hover effect that appears only under a pointer; W3C’s Focus Visible guidance explains that distinction. Watch for a sticky header or floating panel covering the selected control.

Record a specific obstacle: the page, the control, the keys used and what happened. “The project viewer opens, but I cannot reach its close button” is a useful repair instruction. “The website feels awkward” gives the developer much less to work with.

Check reading at larger sizes

Enlarge the page using your browser’s zoom controls and check the service copy, menu and enquiry fields. At 200%, look for text or controls that disappear, overlap or become difficult to use. Ask for a narrow-screen check as well; a desktop screenshot alone cannot show how the layout behaves.

For ordinary vertically scrolling content, WCAG’s reflow criterion uses a width equivalent to 320 CSS pixels, with exceptions for content that needs a two-dimensional layout. The practical question is whether someone can read the paragraphs and complete the task without repeatedly scrolling sideways. A genuinely two-dimensional data table is a different case from a paragraph squeezed into a fixed-width box.

Test the actual words you will publish. An attractive placeholder heading may fit where a real service name does not. Include a long but plausible menu label and error message in the designer’s checks.

Review contrast, images and meaningful text

Have the designer check the actual text and background combinations, including text over photographs. For WCAG Level AA, the minimum text contrast is generally 4.5:1, or 3:1 for large text, with specified exceptions. Do not judge it from the brightness of one display or apply the large-text threshold to small captions.

Review image descriptions in context. A useful project photograph needs text that conveys its relevant meaning; a decorative image can have empty alternative text. W3C’s image decision tree helps distinguish those purposes. Avoid turning every description into a list of search keywords.

Ask the designer to show the heading structure and the names announced for icon-only controls. “Next project” is a clearer action than an unexplained arrow. If a downloadable brochure carries essential service information, include that document in the scope or provide an equivalent usable web page.

Make errors and completion understandable

Test a missing required field and an invalid email address with fictional data. Check that labels remain visible, the problem is described in words and the visitor can find the field to correct. A coloured outline alone does not explain what to do.

Check the successful path separately. The visitor should understand whether they have reviewed a draft, sent a request or reached a confirmed result. Ask how changing feedback is announced to assistive technology. W3C’s form notification guidance covers clear errors and successful completion.

Keep submission testing proportionate: agree one identifiable delivery test, check the receiving mailbox and avoid sending repeated enquiries to a client. For a calendar, payment service or embedded booking form, review the provider’s part of the route too. A usable parent page does not establish that every connected tool is usable.

Ask for a calmer version of the same experience

If the design uses parallax, moving panels or animated transitions, ask the designer to demonstrate it with the device’s reduced-motion preference enabled. The essential content and controls should remain available when the movement is removed.

W3C’s Animation from Interactions criterion is Level AAA; it addresses disabling non-essential motion triggered by interaction. That is a useful design consideration, not a reason to label every animation a Level AA failure. Automatically moving content has separate requirements. Agree which effects the reduced-motion version changes and check the finished behaviour.

Worked example: reviewing a project enquiry

An illustrative refurbishment business

Imagine a business whose new site presents completed refurbishment projects and invites an initial enquiry. This example is a review exercise, not a client case study or a measured commercial result.

During the agreed test, the reviewer can read the service page and open a project with the keyboard. Inside the project viewer, however, the close control is unreachable. At a narrow width, the enquiry button sits outside the visible content. The form marks an invalid address with a red border but gives no explanation.

The useful decision is to repair those obstacles before approving that customer route. Keep the project photography and visual style; change the viewer’s keyboard behaviour, let the button reflow and add a meaningful error message. Retest the same task and record the result. A screenshot of the repaired page alone would not verify all three fixes.

Keep a short review record

Use the worksheet to turn observations into decisions. Write the page or task, test conditions, result, evidence, owner and retest date. “Not tested” is a valid result and should remain visible. Do not turn a row of unchecked boxes into a claim that the site passed.

Owner review decisions — not conformance grades
Observation	Next decision
The main task cannot be completed	Repair the obstacle and retest that route before approval.
The task works, but a concern remains	Record it and agree the fix, owner and review date.
A component or state was not tested	Mark it as untested; include it in further evaluation.

Download the review worksheet (CSV)

The blank file opens in a spreadsheet and asks for no email address. Keep test data fictional and avoid copying customer details or credentials into a shared review. It is an owner’s record of checks, not an accessibility certificate.

Use checks as evidence, not a guarantee

An automated report can help identify issues, but it cannot determine every aspect of accessibility. W3C explains why human judgement remains necessary. Ask what manual evaluation and assistive-technology testing were performed, on which pages and states, and what remains unresolved.

For an important booking or enquiry journey, include an appropriately scoped evaluation by someone competent to assess it. Involving people with disabilities can also reveal practical barriers. Keep the report and its limits alongside the agreed standard; avoid publishing a blanket conformance claim based on a single tool score.

When you commission a custom business website, put these review responsibilities into the proposal. Explore the portfolio and clearly labelled demonstrations to discuss the interactions you need, then send your current website and main customer task. For the rest of a replacement launch, use the search launch checklist.

Sources and scope

The linked W3C guidance was checked on 12 October 2026. The task framework, worked example and review worksheet are original planning aids from Charlie’s Web Design. This owner review complements specialist evaluation; it is not a complete WCAG audit, legal advice or evidence of results for a client.