Series II: From infrastructure to agentic projects in production. Episode 17 of 20.
A website can look polished yet leave people uncertain about what to click, which information is required, or whether a request was registered. For an SME, preparing for agents starts with these ambiguities, not with adding a chatbot. The main decision: audit one real journey, from intention to a verifiable outcome, before assessing the entire website.
We continue our fictional B2B portal for requests and documents. The previous episode defined actions through an API, the interface through which programs communicate. Now we examine the web interface. This proposed scenario does not describe a client audit and does not assume that every tool sees the page in the same way.
Three different questions
Accessibility concerns people with disabilities using a website, including through assistive technologies. Indexability concerns whether a page can be included in a search index. Here, “agentic readiness” means practical preparation for interactions performed by software agents under specified conditions and with specified tools. We do not treat it as a universal certification.
These overlap but are not equivalent. An indexed page does not guarantee a usable form. Accessible labels help identify controls without guaranteeing an agent's success. A confidential document must remain protected even if that makes it unavailable for public indexing.
We also separate roles: a development agent changes and tests code; an agent integrated into the portal might summarize documents; an authorized external assistant might operate the interface on a user's behalf. The audit does not automatically grant them identical permissions.
Start with one journey and a controlled environment
In our scenario, a company representative finds the service, reads its conditions, signs in, attaches a test document, and submits a request. The expected outcome is a request appearing in the correct company's account with an explicit identifier and status.
Run tests in an environment separate from production, using an authorized account and synthetic data. Avoid client documents and notifications to real recipients. Record the application version, language, account role, browser, window size, and tool. Otherwise, two apparently contradictory attempts may have different conditions.
Check the journey on both desktop and mobile. A consent panel or fixed header might cover the submit button only in a particular configuration. This is something to test, not a finding about every website.
What information the tool receives
HTML is the language of page structure. Rendering turns structure, styles, and potentially JavaScript code into the displayed interface. The DOM is the browser's structured representation of the document; the accessibility tree exposes information such as control names, roles, and states to assistive technologies.
A tool might use screenshots, page structure, or combinations of these. Check the actual representation available rather than assuming that an agent reads everything a person sees. Compare the initial HTML response with the loaded page: are the service conditions, price if applicable, and primary action available when interaction happens?
Google documents JavaScript processing for Google Search. This does not describe every agent's behavior. Check content dependent on interaction or additional loading with your chosen tool. Keep important conditions in readable text, not exclusively in an image or an element visible only when hovering.
Structure and forms without guesswork
Semantic HTML uses elements appropriate to their function: headings for information hierarchy, links for navigation, and buttons for actions. W3C WAI guidance supports clear page structure. In the portal, “Submit request” is more explicit than “Continue” when the action finalizes the request.
Each field needs a clear label programmatically associated with its control, not merely nearby text. Explain required fields, accepted formats, and file limits before submission. “Supporting document, PDF” is more useful than an unexplained icon.
Try keyboard navigation and check focus order, meaning which element receives commands. An improvement for people can also reduce automation ambiguity, but an accessibility test remains distinct from an agent test. Do not hide essential information merely to simplify the visual appearance.
Observable states and demonstrable results
Check the journey when something fails too: a rejected file, expired session, or interrupted connection. The message should explain what happened and what the user can do next. For a form error, identify the field and necessary correction without exposing sensitive information in messages or logs.
WCAG 2.2 explains programmatically identifying status messages for assistive technologies when such messages appear without moving focus. This is a relevant accessibility requirement, not a promise that every agent will interpret a message correctly.
In the proposed scenario, verify request registration through its identifier, status, and presence in the account. A clicked button or green indicator alone does not prove that the operation succeeded. If the outcome is uncertain, do not encourage blind resubmission: apply the safe retry mechanisms discussed in the API episode.
A practical audit worksheet
Use this worksheet as a working proposal, not as a report about an already evaluated site. For each row, add the observation, evidence, owner, and verdict: accepted, issue, or not tested.
Prioritize access to another company's data, lost requests, and ambiguous confirmations. Then address completion and navigation obstacles. If the deterministic test succeeds but the agent makes a mistake, investigate the instructions and tool before changing the website. If both fail at the same point, you have a reproducible issue to investigate. Attach relevant screenshots and extracts only after removing sensitive data. Repeat the check after remediation and keep observations separate from interpretations.
Control | What to check | Expected evidence |
|---|---|---|
Finding the service | Understandable name and conditions | Available text and reproducible journey |
Completion | Labels, instructions, keyboard | Fields identifiable without guessing |
Error | Unsupported file | Explanation and opportunity to correct |
Submission | Loading and confirmation | Verifiable identifier and status |
Protection | Authorized account and company | Access limited to approved data |
Automated test, then an agent trial
A deterministic automated test executes defined steps and explicit checks. Playwright supports identifying elements by role and label and checks certain conditions before actions. Waiting for an observable outcome is more robust than an arbitrarily chosen fixed pause. These features do not replace an accessibility audit or verification of the outcome in the application.
Then run the journey with your chosen agent, recording the model, tool version, and instructions. WebArena research, published at ICLR 2024, evaluates the functional correctness of web tasks. We borrow the idea of a verifiable outcome, not historical scores as predictions for our portal.
Do not disable multifactor authentication or anti-abuse controls to obtain a successful test. When human intervention is necessary, record the handoff point. The useful outcome is a prioritized list of blockers and evidence, not an invented readiness percentage. The next episode separates this ability to operate a website from finding and citing content through AI systems.
Sources
Documentation checked on 18 October 2026. Portal examples are hypothetical; the 2024 research is a methodological reference, not a current product comparison.
- W3C WAI: page structure
- W3C WAI: labeling forms
- W3C WAI: form notifications
- WCAG 2.2: understanding status messages
- Google Search: JavaScript SEO basics
- Playwright: locators and actionability checks
- Zhou et al.: WebArena, ICLR 2024
Want to check an important journey on your company's website? Talk to i8 about a web audit with clear outcomes and priorities.
