Yes. AI-assisted and rule-based tools can flag many accessibility problems before a web design agency hands over a client site, but they cannot certify the whole experience. Run a scan on representative pages, then test keyboard use, forms, content meaning, responsive views and assistive technology manually. Record fixes, remaining issues and who checked them.
The useful question is not “Did the scanner pass?” but “Can a person complete the site's important journeys?” W3C's guidance on evaluation tools is blunt: tools cannot check all accessibility aspects automatically, human judgement is required, and tools can produce false or misleading results. A green score can coexist with confusing link text, unusable error messages or a booking widget that traps keyboard focus.
Agree the handover standard and page sample
Before testing, agree what the agency is promising. Identify the accessibility standard named in the contract, any client-specific policy, the pages in scope and whether third-party widgets are included. If the contract refers to WCAG, record the version and level rather than writing a vague “accessible” promise. A qualified accessibility specialist or legal adviser should review claims of conformance where they carry contractual or regulatory weight.
Build a page inventory from real journeys. For an illustrative kitchen fitter site, include home, service detail, gallery, pricing or quote information, enquiry form, confirmation state and any embedded booking tool. Test at least one page from each template and every unique interaction pattern. A scan of the home page alone misses errors on the quote form. If the site has a members' area, include login, password reset and the first task after login.
For each page, record URL, template, owner, test date and viewport. Add the expected task: “find installation options”, “request a quote”, “download care instructions”. This lets the tester check whether a barrier blocks a meaningful task, rather than collecting isolated technical findings. If the site uses generated copy, the website copy workflow can help shape plain-language content before testing; the agency still checks meaning and hierarchy.
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 nowRun automated scans, then triage findings
Start with a browser-based checker such as axe DevTools on each representative state. Deque describes axe-core as the rules engine behind its automated checks, offers free axe browser extensions for Chrome, Firefox and Edge, and adds semi-automated Intelligent Guided Tests in axe DevTools that walk the tester through question-and-answer prompts. Deque itself positions manual testing by experts as the way to catch barriers automation cannot detect. Use the tool's element location and rule explanation to inspect the actual interface. A result may point to a missing label, colour contrast issue or invalid relationship. Confirm it on the page, fix the cause in the shared component where possible, and rerun the same state.
Do not count each repeated component error as a separate design decision. If one navigation icon lacks a name on 24 pages, fix the navigation component and verify it on several page templates. Conversely, a single form error can be serious if it blocks every enquiry. Sort findings by task impact, frequency and remediation owner rather than by the scanner's raw count. Keep screenshots or element references so a developer can reproduce the issue.
An illustrative scan of a nursery site shows 18 “button has no accessible name” results. Sixteen are instances of the same menu button; two are separate carousel controls. The agency fixes the shared menu once and then checks the carousel controls individually. The count falls to zero, but the reviewer still tabs through the menu because an accessible name does not prove its focus order or opening behaviour is usable.
AI can help explain a rule to a developer or propose likely code changes. Give it the specific finding and the relevant markup, not an entire client database. Treat its suggested fix as a hypothesis. A button may technically gain an accessible name while still doing nothing when activated with a keyboard. The pass condition is a working interaction tested in the browser, not a convincing code snippet. For a wider discussion of the audit's limits, see whether an AI audit can replace a manual WCAG check.
Use the keyboard to complete real journeys
Put the mouse aside. From the address bar, use Tab, Shift+Tab, Enter, Space and arrow keys as appropriate. On each representative journey, check that focus is visible, follows a sensible order, reaches every control and can leave pop-ups or menus. W3C's Easy Checks include a visible keyboard focus check, and WCAG success criterion 2.1.2 (No Keyboard Trap) requires that focus can be moved away from any component using the keyboard alone. Test the expanded and collapsed states of menus; automated tools often inspect only the state currently on screen.
For the kitchen fitter's illustrative enquiry journey, a tester tabs through “Services”, opens a dropdown, follows “Kitchen fitting”, then reaches the quote form. Suppose a cookie banner appears after the second Tab and focus continues behind it. The scan may not describe the practical confusion. The agency changes the banner behaviour, then retests keyboard focus from entry to dismissal and back to the page. Record the actual keys used and the observed result.
Check the end of the task, not merely the first input. Submit a form with one required field empty, read the error, correct it and submit successfully. An error that says only “invalid” or is announced far from the relevant field may make the process hard to complete. On a mobile viewport, inspect zoom, text reflow and whether a sticky header obscures focused controls. A test can pass at desktop width and fail when the on-screen keyboard reduces the visible area.
Read content as a visitor, not as a code rule
Automated checks can detect some missing attributes. They cannot reliably decide whether an image description conveys the important information. A gallery image of a fitted kitchen might have alt text “modern kitchen”, while the surrounding copy promises a comparison of two cabinet layouts. If the image communicates that difference, the description needs to convey it. Decorative images can be treated differently. The content owner must decide purpose in context.
Check heading structure, link names, instructions and reading order. A link saying “view details” may pass a technical scan but be meaningless in a list of six services when read out of context. Change it to “view kitchen fitting details” or another accurate destination label. An AI assistant can draft alternatives, but someone must compare the label to the actual destination. Similar wording on different links should not hide different actions.
Before and after, from an illustrative care agency page: “Click the blue button below to start” becomes “Complete the care enquiry form”. The first wording relies on colour and position; the second names the task. If the form is external, add that information when it matters to the visitor's expectation. Do not let a language model invent a claim such as “takes two minutes” unless the team has actually tested that timing.
Ask a human reviewer to read the page at 200% zoom and with images unavailable. W3C's zoom check notes that some people enlarge content to 200% or more, so treat that as a floor; one pass at that level still does not prove conformance. Look for clipped prices, hidden labels and content that appears only on hover. If text is embedded in an image, the reviewer should determine whether equivalent text exists in the page. Generated imagery may introduce new text or icons during revision, so repeat this check after the final content freeze.
Build a small content test sheet for the client editor. For each image, ask “Does this picture convey information that the nearby text does not?” For each heading, ask “Would a visitor understand the page's structure by reading headings alone?” For each link, ask “Does the label tell me what opens?” The editor can ask AI for alternative wording, but must select the wording that matches the actual page. This keeps the maintenance task practical after the agency leaves. It is more useful than handing over a list of technical rules with no examples from the client's own site.
One illustrative gallery card shows a stair-free entrance, while its image description says only “front of building”. The nursery's visitors may need the entrance detail. A reviewer changes the description to “Main entrance with a level path from the gate”, after checking the image really shows that route. The same image might be decorative on a page that already describes the access route in adjacent text. Context changes the right answer; an image recognition model cannot settle it on its own.
Test forms, media and third-party additions separately
Forms deserve a state-by-state test: empty, valid, invalid, server error and confirmation. Check that fields have persistent labels, required information is understandable, errors identify the problem and keyboard users can recover without losing entered data. An AI tool can help draft plain error text, but cannot know whether the form's actual validation announces it correctly. Use a screen reader or an experienced tester for that interaction.
Take a quote form (illustrative) where the button says “Send”, the loading state has no announcement, and the successful submission silently replaces the form with a small tick. A visitor may submit twice because no clear result appears. The agency changes the button to “Request a quote”, provides a visible confirmation heading and tests that it is announced in the chosen assistive-technology setup. This is a functional handover check, not a score improvement.
Video needs captions checked for words, timing and speaker changes; audio content needs an appropriate text alternative. A generated transcript is a starting draft and may mishear product names or numbers. The agency should agree with the client who supplies, corrects and maintains those assets. If the scope includes a third-party booking calendar, chat widget or payment page, test it as part of the visitor journey and document which supplier owns the fix. The website chatbot comparison addresses tool choice, but any installed widget still needs accessibility testing.
For media, make the verification task small enough to perform. Select the first minute, a middle section with a name or number, and the closing call to action; compare captions against sound and inspect timing. If errors appear, extend the review to the whole clip. Say an explainer video (illustrative) says “call us before 5”, but the generated captions say “call us before 9”. That is not a cosmetic typo: it changes the instruction. Correct the caption file, re-export it and check the displayed version after the upload, because a content platform can retain an older caption track.
Ask the supplier of any embedded widget for its accessibility documentation and the method for reporting defects. The agency still needs to test the installed version, because configuration can change behaviour. A booking tool may have an accessible default screen and an inaccessible custom date-picker added by the agency. If the widget cannot be repaired promptly, document a genuinely usable alternate route and have the client decide whether it meets the launch requirement. Avoid promising that a different plugin will solve the issue until it has passed the same journey test.
Eight hours on a seven-page nursery site, step by step
The worked example follows a seven-page childcare nursery website; every figure in it is illustrative. The agency identifies four templates and three unique interactions: mobile menu, enquiry form and booking widget. It budgets two hours for automated scanning and triage, three hours for keyboard and content checks, two hours for fixes, and one hour for retesting and the handover record. That is eight hours of planned effort across two days; the actual time depends on defects found.
The first scan raises 23 results. After grouping repeats, the team has eight distinct issues: two missing control names, two contrast problems, one heading hierarchy problem, one unlabelled input and two third-party widget findings. Manual testing adds four more: invisible focus on the menu, a form error that does not identify its field, a cropped button at zoom and a booking pop-up that cannot be closed from the keyboard. The raw scan found only part of the work.
By handover, the team has fixed ten of the 12 distinct issues. The two widget issues remain with the supplier, and the client is given their effect, workaround if any, supplier ticket, owner and target review date. This is an illustrative project log, not an accessibility certification. If the unresolved pop-up blocks bookings, the agency should not present the site as ready for that journey; it may need a different booking route or a delayed launch. The decision is based on task impact, not the number “two”.
A practical calculation helps the manager plan retests. If a shared button component appears on five pages, one fix can remove five scan results, but it still needs testing in at least the states where it behaves differently. Allocate 15 minutes to verify it in the menu, form and modal rather than marking all five pages resolved from one screenshot. Document the sampling rule so the client can understand what was and was not inspected.
Reserve time for a second tester, too. In the illustrative eight-hour budget, replacing one hour of developer self-check with one hour from someone unfamiliar with the design may expose a different class of problems. Give that tester a task rather than an issue list: “Find the fee information and request a visit using only a keyboard.” Watch where the task stops, then locate the underlying component. The tester should record the browser, viewport, input method and exact step, so the team can reproduce and fix it. A vague comment that the site “felt hard to use” is a clue, but it is not enough for a developer hand-off.
If the agency has only a short window before launch, prioritise by blocked journeys. A missing label on a decorative search field and an unusable final submit button are not equivalent. Fix the blocked submit first, then the remaining defects. Do not hide lower-priority findings; carry them into the handover with an owner and date. A severity label should describe the visitor's obstacle in plain language: “Cannot submit the form by keyboard” is more useful to the client than an unexplained code or colour badge.
Give the client an honest pre-launch record
Use a table with page or journey, finding, impact, evidence, owner, fix, retest result and residual risk. Include the tool and version used for scans, the date, the page states tested, and the manual test methods. Do not issue a blanket “WCAG compliant” statement because a plugin displayed zero findings. W3C's guidance is explicit that tools can produce misleading results and cannot determine accessibility by themselves.
Two sample rows (illustrative) show the level of detail. The first: “Quote form, invalid email state; error appears visually but is not announced; prevents some visitors from correcting the form; developer added a field-linked error and focus movement; retested by keyboard and screen reader on 3 November; closed.” Another row might say: “Booking widget modal; keyboard close fails; supplier ticket open; alternate telephone booking offered; owner: client operations; launch decision pending.” The second row is not solved merely by listing a workaround.
Make the handover repeatable. Tell the client which content changes require a new check: a new page template, a replaced form, a new video, a different chat widget or a redesign of navigation. Offer a short content-editor checklist for alt text, headings, meaningful links and captions. An automated scheduled scan can detect regressions, but it cannot review the meaning of a new image or the behaviour of a new interaction. Assign that review to a person.
Finally, ask someone outside the build team to complete the top two journeys without guidance. Record where they hesitate, what they expect and whether they finish. A fresh pair of eyes can reveal confusing labels the builders have learned to ignore. Pair that observation with the scan and manual checks; together they give the client a defensible account of the site's state at handover and a concrete list of work still owned after launch.
Further reads
- AI Website Builder or Web Designer: What Each Really Costs — Scope the human design and testing work around a site build.
- How to Write Website Articles With AI That Still Rank on Google — Plan ongoing page content without losing editorial review.
- How Much Does a Website AI Chatbot Cost, and Will It Pay Off? — Assess whether a new chat widget is worth its maintenance burden.
- How to Audit Your Website for AI Content That Needs Fixing — Review generated copy for factual and editorial defects.
- AI Content Management Platform: How a Web Agency Picks One for Clients — Score WordPress, Webflow, Squarespace and Wix per client site on editor AI, hosting, cost and handover, then apply a simple decision rule.
- Website Maintenance Plan: Packages a Web Agency Can Add With AI — Three maintenance tiers with tasks and price bands, tool costs per site, and the minutes AI saves on reports and update checks.
- 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 Web Accessibility Initiative, Selecting Web Accessibility Evaluation Tools, Easy Checks (Visible Keyboard Focus and Zoom Levels) and Understanding Success Criterion 2.1.2 No Keyboard Trap; Deque, axe overview page (all checked 4 November 2026).