Website Accessibility Acceptance Criteria for a Small-Business Redesign

“Make it accessible” is easy to put in a redesign brief and hard to check at launch. Nobody can sign off on a sentence like that, so it tends to slide to the end of the project, when changes are slow and expensive to make.

A better approach is to write accessibility down as acceptance criteria before design starts: specific statements a person can test, each with a named owner and a point in the project where it gets checked. This article gives you a starting set for a small-business redesign, based on the W3C’s Web Content Accessibility Guidelines (WCAG) 2.2.

This is a planning aid, not legal advice. Whether a particular standard applies to your business is a question for your own counsel, and nothing here promises that a site is compliant.

Start with the standard you will test against

Pick one written reference before design begins, so everyone is testing against the same thing. The W3C publishes WCAG 2.2 as a Recommendation, dated 12 December 2024. Each success criterion has a level (A, AA or AAA). Decide which levels you will test against, such as A and AA, and write that decision down. If the brief only says “WCAG”, the team will each read it differently.

Also decide what is in scope: every template, the checkout or contact flow, embedded forms and third-party widgets. A calendar or chat widget you did not build still appears on your page.

Criteria you can turn into launch gates

The following are real WCAG 2.2 success criteria, in plain language. Treat them as examples to adapt, not a complete list.

Images have text alternatives (1.1.1, Level A). The criterion says all non-text content presented to the user has a text alternative that serves the equivalent purpose, with listed exceptions. A testable gate: every meaningful image has alt text that says what the image is for, reviewed by whoever writes the page content.

Text has enough contrast (1.4.3, Level AA). The criterion asks for a contrast ratio of at least 4.5:1 for text, with a lower 3:1 for large-scale text. A testable gate: the final colour palette is checked against those ratios before it is applied to templates, not after.

Interface components are distinguishable (1.4.11, Level AA). Visual information needed to identify user interface components must have a contrast ratio of at least 3:1 against adjacent colours. A testable gate: buttons, form field borders and focus indicators are checked in the design file.

Text can be resized (1.4.4, Level AA). Text must be resizable up to 200 percent without assistive technology and without loss of content or functionality, other than captions and images of text. A testable gate: each template is checked at 200 percent zoom for overlapping or cut-off content.

Everything works from the keyboard (2.1.1, Level A). All functionality must be operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user’s movement and not just the endpoints. A testable gate: test every interactive component and flow on each in-scope template using only the keyboard, including at minimum the navigation menu and the contact form.

Keyboard focus is visible (2.4.7, Level AA). Any keyboard-operable interface needs a mode where the focus indicator is visible. A testable gate: while tabbing through each template, you can always see where focus is.

Touch and click targets are big enough (2.5.8, Level AA, new in 2.2). To meet this criterion, the size of the target for pointer inputs must be at least 24 by 24 CSS pixels, except where the criterion’s exceptions apply, such as sufficient spacing between smaller targets. A testable gate: buttons and links in navigation, footers and forms are checked against that size.

Pages have descriptive titles (2.4.2, Level A). Web pages need titles that describe topic or purpose. A testable gate: every page template produces a distinct, meaningful title, which is also good practice for search.

Forms have labels and clear errors (3.3.1 and 3.3.2, Level A). Labels or instructions are provided when content requires user input, and when an input error is automatically detected, the item in error is identified and described in text. A testable gate: every form field has a visible label, and a deliberately wrong submission produces a text message that names the problem.

Controls have names, roles and states (4.1.2, Level A). For user interface components, including form elements and links, the name and role must be programmatically determinable. States, properties and values that users can set must be programmatically settable, and notification of changes to these items must be available to user agents, including assistive technologies. A testable gate: inspect custom menus, accordions and widgets with accessibility-tree tools and a screen reader to confirm that each control exposes the correct name and role, communicates applicable states and values, and announces changes such as expanded, collapsed or selected. Fix or replace any component that fails.

Give every gate an owner and a checkpoint

A criterion with no owner will not get tested. For each gate, write down three things:

• Who is responsible: designer, developer, content editor or project manager.
• When it is checked: design review, staging build or pre-launch.
• What counts as passing: a specific, observable result, not “looks fine”.

Contrast and target size belong in design review, before anything is built. Keyboard, focus and zoom checks belong on the staging site. Alt text and page titles belong with whoever loads the content. Pushing every check to the final week is how accessibility becomes a launch-day argument.

Be honest about what automated tools cannot tell you

Automated checkers are useful for catching missing labels and contrast failures, but they cannot judge whether alt text is meaningful or whether a flow makes sense with a keyboard. Plan manual checks alongside any tool, and record who did them and on which pages. If a gate cannot be met on a particular template, write down the exception and who accepted it, so launch is a recorded decision rather than a surprise.

Put it in the redesign agreement

Add the agreed standard, level, scope and gate list to the project scope or statement of work, and make launch sign-off depend on the gates you listed. That gives your team and your web partner the same definition of done.

If you are planning a redesign and want accessibility built into the plan from the start, our website design service can work with you on the criteria, owners and checkpoints. You can contact us to request an accessibility-gated design review.

Two related reads while you plan: protect your search visibility with the website redesign SEO migration checklist, and make sure visitors can find their way with navigation menu design.