Test whether AI agents can understand and complete a web funnel through its accessibility tree, DOM and visual interface without weakening human usability or safety.
Short answer: AI agents can complete a funnel only when the intended task is understandable and operable through the page’s semantics, DOM relationships and rendered visual state—and when every consequential action has a clear confirmation and recoverable failure path. Audit all three representations against fixed tasks. Do not infer agent readiness from accessibility scores, structured data or one successful demonstration.
A funnel can look obvious to a person and remain ambiguous to an automated agent. A styled container may behave like a button without exposing a button role; a floating overlay may hide the intended control; a validation message may appear visually but never be associated with the field. The failure is not merely technical. It changes whether an agent can accurately represent and execute a user’s intent.
The correct unit of audit is a task, not a page. “Submit a qualified enquiry with a chosen service and consent preference” is testable. “Make the site agent-friendly” is not. CDM’s harness records what the agent could perceive, which action it attempted, where the state changed, and whether the same path remained usable by keyboard and assistive technology.
What the official evidence establishes
web.dev’s guidance on agent-friendly websites describes three principal representations agents may use: screenshots, raw HTML and the accessibility tree. It recommends semantic controls, explicit labels and stable layouts, while warning that visually persuasive interfaces can be structurally confusing.
The W3C HTML Accessibility API Mappings specification explains how HTML elements and attributes are exposed to accessibility APIs. That mapping is relevant evidence for roles, names, states and relationships; it does not certify that an AI product will use or interpret them correctly.
CDM treats human accessibility and agent operability as related but non-identical test outcomes. Improvements such as semantic buttons, explicit labels and dependable focus often benefit both. A proprietary agent’s successful run, however, is not an accessibility conformance test, and an automated accessibility score does not prove end-to-end task completion.
The CDM Agent Task Completion Harness
Run the same goal through the semantic, DOM and visual paths, then compare the event trail. The harness records observable states rather than guessing how the model reasoned.
| Layer | Test question | Evidence captured | Typical failure |
|---|---|---|---|
| Task contract | What exact outcome, constraints and stop state define success? | Scenario, test data, expected state and prohibited actions | A vague goal allows an accidental action to count as success |
| Accessibility tree | Are names, roles, states, groups and errors exposed accurately? | Tree snapshot, focus order and announcements | Unlabelled control or invisible validation |
| DOM / HTML | Do element relationships and data survive without visual styling? | HTML snapshot, selectors, form associations and network state | Clickable div, unstable selector or hidden duplicate |
| Visual path | Does the rendered interface reveal hierarchy and action safely? | Screenshots at each state, occlusion and layout-shift notes | Overlay, tiny target or moving confirmation |
| Outcome ledger | Did the intended backend state occur once and only once? | Event log, record ID, confirmation and rollback | Visual success without a saved record, or a duplicate action |
How to run the Agent Task Completion Harness
1. Write a task contract
Define start state, user goal, permitted data, constraints, success evidence, stop conditions and actions that always require confirmation. Use representative but synthetic test data. Separate read-only discovery from consequential actions such as submitting a lead, changing an account or purchasing.
2. Inspect the accessibility tree first
Capture role, accessible name, state, value, grouping, heading structure and focus order for every step. Test errors and disabled states. A control should not require nearby visual text to explain its purpose if that relationship is not represented programmatically.
3. Audit the DOM and event path
Check whether native controls are used, labels point to inputs, duplicate IDs are absent and state changes are explicit. Record redirects, cookies, network calls and backend events. Avoid choosing selectors based on transient styling classes; use stable semantics and test identifiers where appropriate.
4. Test the visual representation
Run desktop and narrow mobile viewports. Capture cookie notices, chat launchers, sticky headers, modals, keyboard display and loading states. Identify controls that are covered, too small, displaced or visually indistinguishable. Verify that price, consent and confirmation remain visible at the decision moment.
5. Compare independent agent runs
Use a fixed scenario and record the agent, version, date, configuration and number of attempts. Repeat enough to expose variation, but do not turn a small internal test into a universal benchmark. A human tester should verify the actual backend outcome and review any unexpected side effect.
6. Repair the shared interface contract
Prefer native HTML and clear user-facing states before adding agent-only hints. Retest keyboard and assistive-technology paths after every change. Where an emerging agent API is used, treat it as an additional interface with its own permissions and fallbacks, not as a replacement for a coherent website.
Decision rules
Classify failures by the representation that broke and the consequence. This prevents a visual redesign from masking a missing accessible name or an agent prompt from hiding an unsafe transaction state.
| Signal | Decision | Evidence to retain |
|---|---|---|
| Task fails in accessibility tree and DOM | Repair semantics and relationships before agent-specific work | Tree diff, HTML change and regression test |
| Semantic path succeeds but visual path is occluded | Fix layout, overlays and target visibility across viewports | Before/after screenshots and viewport matrix |
| Agent reaches confirmation but backend state is absent | Investigate event and API contract; do not count visual completion | Network trace and backend record |
| Task succeeds inconsistently across repeated runs | Label as unstable and reduce ambiguity before launch | Run log with conditions and failure taxonomy |
| Agent can trigger a consequential action without user confirmation | Block release; add explicit authority and confirmation control | Permission test and confirmation evidence |
Build the evidence record before launch
A useful audit can be rerun after a design-system or funnel change. Preserve enough context to distinguish a page regression from agent variation or test-environment noise.
- Task contract, synthetic persona, starting URL, viewport and expected backend state.
- Browser, agent product/version where available, account state and test date.
- Accessibility-tree snapshots, focus sequence, labelled controls and error states.
- DOM snapshots, stable element identifiers, redirects and network/event traces.
- Visual screenshots at every decision, occlusion or layout-shift point.
- Attempt-level outcome, side effects, manual verification and rollback result.
- Human keyboard and assistive-technology regression results.
Do not store real credentials or customer data in an agent test. Use isolated test accounts and redact screenshots before circulation. The durable artefact is the failure taxonomy plus the corrected interface contract, not a video of one successful run.
Separate fact, CDM inference and the operating decision
Documented fact
Current web.dev guidance says agents may interpret screenshots, HTML and the accessibility tree, and recommends semantic HTML, labels and stable layouts.
CDM inference
A multi-representation audit should reveal failures that a single automated score misses, although the failure rate will depend on the chosen agent, tasks and environment.
Operating decision
Release a task to agent use only when semantics, visuals and backend outcomes agree, consequential actions preserve user authority, and failures are recoverable and observable.
Worked example: a demo-booking form that only looks complete
A fictional software company asks an agent to choose an enterprise plan, enter synthetic business details and request a demo. The accessibility tree exposes the name and email fields but calls the styled plan selector “group” without named options. In the visual run, a cookie panel covers the submit button on a narrow viewport.
After markup repair, the agent selects the correct plan and reaches a green success banner. The outcome ledger still shows no CRM record because a client-side error prevented the network request. The visual state was optimistic, so the first run was not completion.
The team associates labels and controls, replaces the custom selector with an operable radiogroup, fixes the mobile overlay and renders success only after an acknowledged CRM event. Three repeated runs then save one record each; keyboard regression also passes. The result is task-specific evidence, not a claim that every agent can use the entire site.
Limitations and review boundary
Agent products, models and browser tooling change. Results can vary by account, configuration and session state. The harness measures defined tasks under recorded conditions; it does not produce a permanent agent-readiness grade or reveal proprietary reasoning.
This process complements, but does not replace, professional accessibility evaluation, security review, performance testing or human usability research. Emerging agent interfaces can change and may not be supported across browsers. Preserve normal human paths and fail safely when agent-specific capabilities are absent.
Related guides
Frequently asked questions
Is an accessibility audit the same as an AI-agent audit?No. They overlap in semantics, labels and operability, but they answer different questions. Accessibility work evaluates barriers for people with disabilities against relevant standards and user needs. An agent audit tests a named automated system completing a defined task and must not be presented as accessibility certification.
Should we add hidden text just for agents?Prefer visible clarity and native semantics. Hidden agent-only instructions can become stale, conflict with the interface or create security problems. If an explicit agent API is used, govern it as a separate interface with authentication, permissions, logging and human confirmation.
How many agent runs prove a funnel works?There is no universal number. Repeat enough to observe variation across the risk-relevant states, report the denominator and conditions, and treat a passing sample as bounded evidence. High-consequence actions require stronger controls than a content lookup.
What is the most common false positive?A visible confirmation that is not matched by the intended backend record. Always verify the saved lead, order or account change and ensure retries did not create duplicates.
Does schema markup make a funnel agent-ready?No. Structured data may help describe entities or content, but task completion depends on controls, state, identity, transaction logic, confirmation and recovery. Schema cannot repair an unlabeled field or an unsafe action.
Method and publication status
This prepublication draft was researched from the primary materials linked at the claims they support and checked on 12 October 2026. It requires the named specialist review, live-product retesting where indicated, a real 16:9 editorial image and final URL verification before publication. It is operational analysis, not legal, security or compliance advice.
This article is editorial guidance. Apply the principles in proportion to your market, evidence, and responsibilities.
