WCAG-Ready by Christmas: An AI Accessibility Audit

Christmas is about ten weeks away. That's enough time to find and fix most of the accessibility problems on a small business website, if you start now and you're honest about what software can and can't do for you.

This post walks through how we'd run an AI assisted accessibility audit on a typical Burnaby or New Westminster business site, what the evidence says about where AI helps, and where you still need a person with a keyboard and a screen reader.

What "WCAG-ready" actually means

The Web Content Accessibility Guidelines (WCAG) are the standard most accessibility work is measured against. According to the W3C, WCAG 2.2 was published as a W3C Recommendation on 5 October 2023. It added nine success criteria, including Focus Not Obscured, Dragging Movements, Target Size (Minimum), Consistent Help, Redundant Entry and Accessible Authentication, and it removed 4.1.1 Parsing as obsolete.

Most organizations aim for Level AA. A few concrete examples from the WCAG 2.2 text:

• Normal text needs a contrast ratio of at least 4.5:1 against its background (1.4.3).
• Non-text content, like product photos and icons, needs a text alternative that serves the same purpose (1.1.1).
• Pointer targets such as buttons should be at least 24 by 24 CSS pixels, with listed exceptions (Understanding 2.5.8).
• Keyboard focus shouldn't be hidden behind sticky headers or cookie banners (2.4.11, new in 2.2).
• Login steps shouldn't depend on a memory test or puzzle without an alternative (3.3.8, new in 2.2).

None of that is exotic. It's mostly the stuff that breaks when a theme gets updated or a new booking widget gets pasted in.

How bad is the average site?

Pretty bad, and it's getting worse. WebAIM's 2026 analysis of the top one million home pages found that 95.9% had detected WCAG 2 failures, averaging 56.1 errors per page. The most common problems were low contrast text (83.9% of pages), missing image alt text (53.1%), missing form labels (51%), empty links (46.3%) and empty buttons (30.6%).

Notice the pattern. These are repetitive, fixable, boring issues. That's exactly the kind of work where AI earns its keep.

Where AI genuinely helps

Rule based scanners have existed for years. What's new is pairing them with a large language model that can read the flagged code, understand the page context and draft a fix. Here's how we'd split the work on a typical site:

Triage at scale. A scanner crawls every page and spits out hundreds of findings. An AI pass groups them by root cause, so "312 contrast errors" becomes "one button colour in your theme file." That's where hours are saved.

Alt text drafts. A model can look at a product photo and draft a description. A human still decides whether the image is decorative, and whether "red ceramic mug" or "the 12 oz holiday mug from our Metrotown pop up" is the right description for your customers.

Form labels and link text. Turning "click here" into "Book a winter tune up" or adding a missing label to a postal code field is the kind of semantic fix models handle well.

Patch drafts for your developer. Instead of a PDF of problems, you get proposed code changes that someone reviews and merges.

The research backs the "draft, not decide" framing. A May 2026 study on arXiv, LLM Based Web Accessibility Repair: An Empirical Study of Detection, Remediation, and Cost by Oyelayo and colleagues, tested Kimi K2.5 on real accessibility violations. They reported a detection F1 score of about 0.65 overall, rising to 0.83 on semantic issues but weaker on syntactic and layout problems. Repairs improved compliance in 80.2% of instances and cut violations from 3.98 to 1.7 per file. But only 26% of cases were fully resolved, and about 30% of patches introduced structural changes. Their conclusion is that LLMs work for partial repair and need rule based validation alongside them.

That's a useful, honest picture. AI makes the fix list shorter and faster. It doesn't make it zero.

Why scanners and AI aren't the whole audit

The W3C is blunt about this. Its guide to selecting evaluation tools says "Tools cannot check all accessibility aspects automatically. Human judgement is required," and warns that tools can produce false or misleading results.

The UK Government Digital Service tested this directly. In a 2017 post, Mehmet Duran described building a page with 143 deliberate failures and running 10 automated tools against it. The best single tool found 37%. All ten combined found 71%, leaving a large minority that only manual checking caught. Tools have changed a lot since 2017, but the lesson holds, and WebAIM repeats it in its own report: absence of detected errors does not mean a page is accessible.

So a real audit has a manual layer. Someone tabs through your checkout with no mouse. Someone listens to your booking form with a screen reader. Someone zooms the page to 200% on a phone. That's the part AI can't sign off on.

A ten week plan to Christmas

Here's the sequence we'd follow. Timings are illustrative and depend on site size.

Weeks 1 to 2: Inventory and scan. List your key journeys: home page, contact form, booking or checkout, and any login. Run automated scanning across the whole site, then use AI to cluster findings by template and component.

Weeks 3 to 5: Fix the templates. Contrast, focus styles, button sizes and form labels usually live in a handful of theme files. Fixing those once can clear a large share of the repeated errors.

Weeks 6 to 7: Content pass. AI drafts alt text and rewrites vague links. A person approves each one. This is also when you check PDFs and embedded videos for captions.

Weeks 8 to 9: Manual testing. Keyboard only, screen reader, zoom and mobile checks on each key journey. Fix what turns up.

Week 10: Write it down. Publish an accessibility statement with a way for people to report problems, and set a monthly automated scan so a December plugin update doesn't undo the work.

Where this doesn't apply

A few honest limits.

There's no "compliant" button. Be wary of overlay widgets or one click fixes that promise instant WCAG compliance. The W3C's own wording is that tools can only assist in determining accessibility, not determine it. If a vendor says otherwise, ask what their manual testing looks like.

Third party widgets may be out of reach. If your booking engine, payment form or chat tool is hosted by someone else, you can report problems but you often can't fix them. Sometimes the right move is switching providers, not patching.

Very small sites might not need AI at all. A five page brochure site can be checked by hand in an afternoon. The AI layer pays off when you've got dozens of pages, a product catalogue or a blog with years of images.

The legal picture in BC is still developing. The Accessible British Columbia Act currently applies to over 750 public sector organizations, such as local governments, school districts, health authorities and public libraries, and it provides for accessibility standards to be developed. As of October 2026, that page doesn't set out website rules for private businesses. We're not lawyers, so if you sell into the public sector or operate outside BC, get proper advice on what applies to you.

AI drafts can be wrong. Per the arXiv study above, roughly three in ten AI patches changed page structure. Every change needs review before it goes live.

The short version

Most Metro Vancouver small business sites fail on the same handful of issues. AI is genuinely good at finding them fast, grouping them, and drafting fixes. People are still needed to judge context, test with real assistive tech and approve changes. Done in that order, ten weeks is a realistic runway to a much more usable site by Christmas.

Sources

• W3C Web Accessibility Initiative, "What's New in WCAG 2.2", 2023. https://www.w3.org/WAI/standards-guidelines/wcag/new-in-22/
• W3C, "Web Content Accessibility Guidelines (WCAG) 2.2", W3C Recommendation, 2023. https://www.w3.org/TR/WCAG22/
• W3C Web Accessibility Initiative, "Understanding Success Criterion 2.5.8: Target Size (Minimum)". https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html
• W3C Web Accessibility Initiative, "Selecting Web Accessibility Evaluation Tools", updated 2024. https://www.w3.org/WAI/test-evaluate/tools/selecting/
• WebAIM, "The WebAIM Million", 2026. https://webaim.org/projects/million/
• Mehmet Duran, GOV.UK Accessibility Blog, "What we found when we tested tools on the world's least accessible webpage", 2017. https://accessibility.blog.gov.uk/2017/02/24/what-we-found-when-we-tested-tools-on-the-worlds-least-accessible-webpage/
• Oyelayo, Abushaqra, Asadi, Dey and Costa, "LLM Based Web Accessibility Repair: An Empirical Study of Detection, Remediation, and Cost", arXiv, 2026. https://arxiv.org/abs/2605.27716
• Government of British Columbia, "Accessible B.C. Act". https://www2.gov.bc.ca/gov/content/governments/about-the-bc-government/initiatives/accessibility/legislation

Want a second set of eyes on your site before the holiday rush? Book a free call with Autana. We'll look at your key pages together and tell you plainly what AI can speed up and what needs a human.