AI can help audit a client website by explaining scanner findings, grouping repeated defects and drafting a repair list. It cannot replace a manual WCAG check. A person still has to test keyboard operation, screen reader meaning, useful alternative text, error recovery and complete user journeys before the agency claims a page meets a standard.
Start by agreeing exactly what the client means by an audit: a quick defect sweep, a tested sample of important pages, or a formal conformance assessment. Those are different deliverables. A clean scanner report establishes only that its rules found no matching defects in the pages and states it reached; it does not certify accessibility.
Draw the boundary around the audit before opening a scanner
Ask the client for the target standard and level (the W3C encourages using the latest version, WCAG 2.2, first published in October 2023 and updated in December 2024), the pages and states in scope, the user journeys that matter, and the date of the build being tested. WCAG means Web Content Accessibility Guidelines. Its success criteria describe outcomes, while testing methods can combine automated checks and human evaluation. Record whether the scope includes mobile layouts, logged-in areas, embedded payment or booking services, downloads, and content loaded after a button is pressed. A homepage-only scan cannot speak for a checkout, an account portal or a form with errors.
The W3C's tool selection guidance says tools identify potential problems but cannot determine accessibility on their own; human judgement is required. Its evaluation overview also says no single tool establishes whether a site meets accessibility standards. Write that distinction into the proposal and final report. If the client needs a formal claim for a contract or legal obligation, agree a qualified accessibility specialist's role and obtain legal advice on the applicable duty.
For an agency building a five-page marketing site, a practical scope might name the home, service, contact, enquiry confirmation and policy pages, plus the mobile menu and the enquiry form's blank, invalid and successful states. A different client with a member area may need account creation, sign-in, password recovery and renewal. The scanner should run on every chosen state, but the human checks should follow the whole task, not a random set of screenshots. If you need a design-stage checklist before this audit, the website accessibility handover tutorial addresses that earlier point.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowWhat a scanner can prove, and what AI merely suggests
An automated accessibility scanner inspects the page code and rendered document against rules. It can reliably flag some missing accessible names, invalid relationships, colour contrast combinations and structural problems. It can also surface items needing review. An AI assistant can translate a rule identifier into plain English, compare repeated findings across templates and propose a developer ticket. Keep the scanner's original evidence beside the AI summary: URL, element, rule, observed value, screenshot or code excerpt, scan date and tool version. An AI paraphrase is not a test result.
Take a decorative search icon with an accessible name of “Search”. A scanner may regard the name as present. A human must decide whether the control actually submits a search, opens a search panel or clears the field; the same name is wrong for two of those jobs. Likewise, an image with alternative text “picture” may pass a missing-text rule while telling a screen reader user nothing useful. On a product diagram, the correct alternative may describe the trend or decision the diagram conveys. That judgement depends on the page's purpose.
Use AI to draft a candidate correction, then compare it with the visible behaviour. An illustrative prompt is: “For this button, visible text is ‘View quote’, its accessible name is ‘Submit’, and it opens a quote preview without sending data. Explain the mismatch and suggest a concise name. Do not claim WCAG conformance.” An illustrative output is “Rename it ‘Submit quote’.” That is still wrong: the action does not submit. The reviewer should make the accessible name match the visible “View quote” text, or change both to “Preview quote”, confirm the name is announced by the assistive technology in use, and retest the button's focus and activation. The original mismatch is a likely failure of success criterion 2.5.3 Label in Name, which requires a control's name to contain the text presented visually. Matching the strings is mechanical; judging whether the wording describes what the button does is not.
Do not ask a model to assign a blanket pass or fail from screenshots alone. It cannot see every interactive state or infer all intended meaning from pixels. A model may write persuasive explanations with the wrong WCAG criterion number, overlook a hidden validation message, or suggest a code fix that makes the mouse experience better while breaking keyboard focus. Treat AI output as a draft for the developer and tester, never as an independent finding. For wider questions about when AI-generated site copy needs review, see auditing AI website content.
Which WCAG questions require somebody to use the page?
| Question | Why a scan falls short | Human evidence to collect | WCAG 2.2 criteria usually involved |
|---|---|---|---|
| Can the journey be completed by keyboard? | The scan sees focusable elements, not the user's route through a modal or menu. | Tab order, visible focus, activation and exit from each overlay. | 2.1.1 Keyboard; 2.1.2 No Keyboard Trap; 2.4.3 Focus Order; 2.4.7 Focus Visible; 2.4.11 Focus Not Obscured (Minimum) |
| Does the screen reader announce meaning? | Presence of a label does not establish that it describes the right action. | Announced control names, headings, errors and status changes. | 4.1.2 Name, Role, Value; 2.5.3 Label in Name; 4.1.3 Status Messages |
| Is alternative text useful? | Any non-empty text can be misleading or redundant. | Compare the text with the image's purpose in context. | 1.1.1 Non-text Content |
| Can a user recover from errors? | Rules may miss the sequence after an invalid submission. | Trigger errors, identify them, fix input and resubmit. | 3.3.1 Error Identification; 3.3.3 Error Suggestion |
| Can the page be read at zoom? | A single viewport scan misses clipping and horizontal scrolling. | Inspect key tasks at enlarged text and narrow widths. | 1.4.4 Resize Text; 1.4.10 Reflow |
Treat the criterion numbers as pointers for the specialist who reviews the register, not as verdicts. Of the 13 criteria in the table, seven are Level A. The other six (2.4.7, 2.4.11, 3.3.3, 1.4.4, 1.4.10 and 4.1.3) are Level AA, and 2.4.11 was added in WCAG 2.2, so an older report written against WCAG 2.1 will not mention it. Confirm which version and level the client's contract or brief names before citing any criterion, and quote the criterion's own wording from the W3C quick reference rather than an AI paraphrase of it.
For keyboard testing, start at the browser's address bar, then use Tab and Shift+Tab. Do not touch the mouse. Open and close the navigation, choose a service, reach the form, enter values and submit. Note whether focus disappears, jumps behind a dialog, becomes trapped or lands on a control that cannot be seen. Press Escape where the interface advertises that behaviour. Repeat after a validation error, because many failures appear only when the page inserts a message dynamically.
For a screen reader check, use a real screen reader with its supported browser and record the combination used. Navigate by headings and landmarks, then by controls. Ask whether the page title identifies the current page, whether headings make sense out of visual context, whether form labels and required state are announced, and whether a successful submit is conveyed. This is not a claim that one device or reader represents every user. It is a reproducible test of a particular implementation and state.
Consider a booking form that shows “Date unavailable” in red after submission. A scan of the initial page may be clean. If focus stays on the submit button and the new error is never announced, a screen reader user may believe nothing happened. The repair might require associating the error with the date field, giving the form a clear summary and moving or announcing focus appropriately. In the register this usually points to 3.3.1 Error Identification and, where the message appears without moving focus, 4.1.3 Status Messages. The tester must rerun the same invalid booking to verify the change. An AI-generated ticket can describe the defect, but the observed sequence is the evidence.
Run a two-pass audit on a realistic agency assignment
Here is an illustrative worked example, not a client result. A web agency is preparing a 12-page service site with three templates: home, service and contact. The agreed sample includes six URLs and four extra states: open mobile menu, empty form submission, invalid email and successful submission. That is ten test states, not twelve interchangeable page scans. Two staff members allocate an illustrative 9 hours: 1 hour for scope and credentials, 2 for scanning and deduplicating findings, 4 for keyboard and screen reader task testing, and 2 for retesting and reporting. These hours are planning assumptions, not a market benchmark.
First, the developer scans each selected state and exports 28 findings. Fourteen are instances of the same missing name in a repeated footer component. Group those into one root-cause ticket while retaining all 14 affected URLs. Six are contrast warnings that require inspecting actual text against its background. The remaining eight concern form labels, heading order and an icon button. AI can draft six issue summaries from the raw evidence; a human verifies each summary against the actual interface. Counting raw findings as 28 separate defects would inflate the report and waste the client's time.
Second, the tester completes two journeys without a mouse: service page to enquiry, and mobile menu to contact form. The first reveals that the submit button is reachable but the error summary is not announced. The second reveals that focus leaves the expanded menu and moves to links behind it. Neither issue is resolved by the clean contrast results. The tester records the starting URL, viewport, browser, input method, steps, expected result, actual result and screenshot or short recording. This lets a developer reproduce the defect and lets the client understand why it affects a task.
Third, the developer fixes the footer component once, repairs the menu focus behaviour and connects the form errors to their fields. A new scan removes the footer findings; a manual rerun confirms that the two journeys can be completed. If the tester cannot obtain a successful form submission because the staging server blocks email delivery, mark that state “not tested”, explain why, and schedule a production retest. Do not convert an untested state into a pass because the source code looks plausible.
A useful acceptance gate is precise: every in-scope high-impact defect has an owner and a retest result; unresolved issues have an explicit client decision and date; and the report distinguishes verified passes from items the team did not test. This does not by itself authorise a formal WCAG conformance claim. The W3C's conformance explanation describes the need for both automated and human evaluation and recommends usability testing as well.
Five small failures a green dashboard can conceal
Example one: a page with a sensible heading tree but no useful sequence. A services page may have one main heading and correctly nested subheadings, yet place “Book now” before the pricing caveat in keyboard order. The tester should follow the actual reading and focus sequence, then ask whether the action is understandable when reached. A visual layout review alone can miss that an overlay or CSS order changed the reading order. Record the page and the exact point where the meaning breaks, and check it against 1.3.2 Meaningful Sequence and 2.4.3 Focus Order.
Example two: a carousel that pauses only for pointer users. The pause control may exist and be named, so a scanner finds no missing button label. Try reaching the control by keyboard while content rotates. If the slide changes before the user can read it, note the timing and the task affected. The repair could be to pause automatically on focus or provide a reachable control, depending on the design; 2.2.2 Pause, Stop, Hide is the criterion to check for moving content. Retest the transition rather than accepting a code diff as proof.
Example three: a PDF linked from an otherwise tested page. The client may say the site is accessible because the HTML passed a scan, while the only price list is a downloadable document. Add the document to the inventory and test its structure, reading order, links and tables with appropriate tools and human inspection. If it is outside the current engagement, name that limitation in the scope. A user cannot complete the purchase decision if the essential information is inaccessible.
Example four: a consent banner that blocks the keyboard path. The agency checks its own templates, then a third-party banner is added after launch. It opens on every page and traps focus without a clear close or choice. Audit the integrated site, including third-party components and their states. If the supplier owns the code, raise a supplier ticket with reproducible steps and retain a fallback route for visitors. The same principle applies to an embedded chatbot; the chatbot launch test covers its wider conversation behaviour.
Example five: a search field with an announced result count but unusable results. An accessible live message may say “12 results”, yet keyboard focus stays in the search field and the result links are inserted somewhere unexpected. Complete the search, find a result, open it and return. A test of isolated widgets cannot prove the whole search task works. Explain in the ticket whether the defect is focus management, poor naming, absent status, or a combination.
These examples matter because the unit of quality is a visitor's task. An agency may be tempted to report only the number of errors removed. Keep that metric if the client wants it, but also state which journeys were completed, with which input method, and which states remain untested. A defect count can fall while a critical enquiry route is still impossible. If a chatbot is meant to hand off when a visitor cannot use it, test the human handover route by keyboard too.
Give the client a report they can act on and challenge
Use an issue register with one row per distinct root cause and references to every affected page. Suggested columns are ID, page or state, user impact, observed steps, expected result, evidence, relevant WCAG success criterion for specialist review, severity, owner, proposed repair, status and retest date. Do not let AI fill a criterion or severity unreviewed. Severity should reflect blocked tasks and frequency, not how quickly a developer can fix the code. A menu that blocks all keyboard access to contact is more urgent than a minor decorative-text issue.
An illustrative entry might read: “A-07; mobile navigation open on service page; pressing Tab after the final menu link moves focus behind the overlay while it remains visible; keyboard users may activate hidden links; reproduce at narrow viewport; owner: front-end developer; fix: contain or close navigation according to its interaction design; retest: pending.” This is more useful than “AI found poor focus.” The tester can attach the browser and screen reader combinations separately so the client can reproduce the observation.
Separate “confirmed failure”, “needs human decision”, “confirmed pass” and “not tested”. A scanner's “needs review” item should not silently become a failure, and a scanner's lack of findings should not become a pass for every criterion. State the exact sample and limitations on the cover page. If the agency says “WCAG 2.2 AA compliant”, that phrase implies a level of assurance the work may not support. Ask an accessibility specialist to review any formal conformance statement and a qualified adviser to interpret legal duties for the client's market and contract.
Give the client a short repair order rather than a huge unranked export. Start with task blockers, then repeated template defects, then lower-impact page-specific issues. For each change, explain how it will be checked again. A developer can resolve a repeated footer defect across a dozen pages by changing one component, but the tester should still sample multiple pages after deployment to ensure the component renders consistently. Keep the original scan and retest outputs so a later regression is visible.
Keep the method useful after the handover
Put a small scan in the agency's regular release checks, and reserve human time for changed journeys and representative pages. When a new modal, form, navigation pattern or external widget enters the site, rerun keyboard and assistive-technology tasks rather than relying on the old report. Record who approved an exception, why, and when it will be revisited. A later content editor may replace a meaningful image description with a filename or publish a document outside the original scope; the production workflow needs an owner for those changes.
For a practical release note, write: “Six URLs and four interactive states tested on the stated build. Automated findings reviewed and deduplicated. Keyboard enquiry and mobile navigation journeys retested. PDF price list outside scope; client to commission separate review. No site-wide conformance claim made.” Replace those figures and limitations with the actual work. This language allows the client to decide what to commission next without suggesting that AI or a green score has completed a human audit.
Further reads
- AI Chatbot Disclosure: What to Tell Customers at the Start of a Chat — Review disclosure in an embedded chat journey.
- How to Protect a Customer-Facing Chatbot From Misuse — Check visitor-facing widget failure modes.
- Who Is Liable When Your AI Chatbot Gets It Wrong? — Clarify responsibility for third-party chatbot output.
- AI Wireframe Generator for Web Designers: From Brief to Clickable Draft — Move from client answers to a tested clickable flow without mistaking generated screens for an approved site.
- Figma Make for Web Designers: Client Prototypes and Where It Breaks — How a web designer can turn a brief into a clickable Figma Make prototype, which plan to check, and the places it tends to fall short on real client work.
- Web Design Client Questionnaire: Collect Content and Goals With AI Help — Twenty questions to ask a new web design client, then prompts that turn the answers into a brief, sitemap and content plan.
- Web Design Proposal Template: Draft Scope, Fees and Timeline With AI — A filled-in web design proposal: scope, phases, payment schedule, assumptions and revision limits, drafted with AI and checked by you.
- Website Development by AI: What Agencies Can Ship and What Needs Review — A review checklist for AI-built client sites: what an agency can ship quickly and where a human check is mandatory.
- Can ChatGPT Design a Website for a Client? What It Gets Right and Wrong — A web agency's practical review of AI wireframes, page copy, responsive code and client-ready handover.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: W3C WAI Selecting Web Accessibility Evaluation Tools; W3C WAI Evaluating Web Accessibility Overview; W3C Understanding Conformance (WCAG 2.2); W3C How to Meet WCAG 2.2 quick reference; W3C WCAG 2 Overview.