WCAG 2.2 for Business Websites: A 90-Day Accessibility Roadmap

Start your WCAG rollout with a real task. Open a service page, find the contact form and try to submit it using only a keyboard. If focus disappears, a dialog traps you or a field error goes unannounced, fix that journey first. The same approach works for account registration, checkout and other tasks customers need to complete.

1. Set an accessibility target and measure search separately

The Web Content Accessibility Guidelines (WCAG) describe how to make web content accessible to people with disabilities. For this roadmap, use WCAG 2.2 Level AA as the technical target. Assess applicable Level A and AA criteria across full pages and every step of each process in scope.

Descriptive headings, meaningful links and informative text alternatives help people navigate and make page content easier to interpret. For SEO, check crawl access and indexing separately. For answer engine optimization (AEO) and generative engine optimization (GEO), keep useful answers and supporting evidence available as readable text. Google applies its existing Search requirements to AI Overviews and AI Mode. Track search visibility and observed AI citations separately from accessibility conformance.

W3C WCAG 2.2 standard · Google guidance on AI features

2. Prioritize barriers and assign the work

Content

• Describe the purpose of informative images. Use empty alt text for purely decorative images. If an image is the sole content of a link or button, describe its destination or action.
• Provide synchronized captions for prerecorded video with meaningful audio, including relevant non-speech sounds. Provide a text alternative for prerecorded audio-only content and assess audio description for visual information that the soundtrack leaves out.
• Use a descriptive page title, a logical heading hierarchy and link text that makes sense in context.

Design and front end

• Fix barriers that block key tasks first, including keyboard traps, unusable forms and inaccessible navigation. Prefer native links, buttons and form controls. Add ARIA where needed and test the result with assistive technology.
• Provide a way to bypass repeated navigation. Check Tab and Shift+Tab order, visible focus and activation with the appropriate keys. Check whether sticky headers or overlays fully obscure the focused element. For dialogs, test opening, closing and focus restoration.
• Give form controls accessible names and visible labels where appropriate. Identify required fields, explain errors in text and associate each message with its field. Verify that dynamic status messages are announced.
• Check text contrast against WCAG thresholds of 4.5:1 for normal text and 3:1 for large text, subject to the applicable exceptions. Use text or another cue alongside color to convey status.
• Test zoom and reflow on narrow screens. For pointer targets, check the WCAG 2.2 minimum of 24 × 24 CSS pixels and its exceptions, including spacing.

DevOps and QA

• Run automated accessibility checks against representative templates and key interaction states. Add agreed regression checks to CI, with an owner for failures.
• Keep a separate technical SEO checklist for HTTP responses, robots directives, sitemaps and structured data. Check rendered content and consider server-side rendering if the main content is difficult for crawlers to access.

3. Example of a labeled field and status message

<label for="contact-email">Email (required)</label>
<input id="contact-email" name="email" type="email"
       autocomplete="email" required>
<p id="contact-status" role="status"></p>

Place the status region in the DOM before updating its text. When the server confirms a successful submission, update the region with a confirmation. For a field error, display what went wrong and how to fix it, associate the message using aria-describedby and set aria-invalid while the field is invalid. Connect this example to your actual submission and validation logic.

4. Combine automated checks with task-based testing

1. Establish a baseline. Scan representative pages and states with a tool such as axe-core. Record the WCAG criterion, component, affected task and steps to reproduce.
2. Test manually. Complete key journeys with a keyboard and screen readers on desktop and mobile. Include validation errors, dialogs, zoom and narrow layouts.
3. Test with users. Ask people with different access needs to perform realistic tasks. Record where they succeed, need help or abandon a step.
4. Retest fixes. Repeat the original steps on the updated version and add regression coverage where feasible. Use human evaluation alongside scanner results when assessing conformance.

W3C guidance on evaluating web accessibility

5. A 90-day implementation roadmap

6. Define acceptance and track outcomes

• Accessibility. Report findings by criterion and task impact. Record the pages, states, devices and assistive technologies tested, along with unresolved issues.
• Task completion. Divide successful attempts by total attempts for each task. Use the same scenarios when comparing results before and after changes.
• Conversions and organic search. Track form submissions, purchases, indexing status, impressions and clicks for affected URLs. Record concurrent changes to content, campaigns and site configuration when interpreting trends.
• AI visibility. If you monitor citations, reuse the same set of questions and record the platform, date and cited URL. Report observations for the sampled queries.

At handover, give the team a list of tested journeys, evidence for resolved issues and owners for remaining work. Repeat the relevant checks whenever a shared component or key journey changes.