Consider a booking page with two room rates. One can be cancelled until the previous evening; the cheaper one is non-refundable. Both have a Choose button, and their placement makes it clear which offer each button belongs to.
In a structured browser view, however, both buttons might appear simply as “Choose,” without a reliable connection to the cancellation terms. An agent using that view could struggle to distinguish the offers, although a screenshot or other page context might resolve the ambiguity.
This is a hypothetical example, not a booking incident I've witnessed or a test I ran. It illustrates how a choice that looks clear on screen can become ambiguous through another observation channel. Visual clarity alone may not be enough when people delegate decisions through a browser.
What the page shows and what the browser exposes
A page has a visible arrangement: spacing, colour, typography, and grouping that help people understand which controls belong together. Software can also read information exposed through HTML and accessibility semantics, including a control's role, accessible name, value, and state. Those representations overlap, but they don't always communicate the same details. Chrome's explanation of the accessibility tree describes a browser-derived semantic view used by assistive technologies, rather than a transcript of the rendered pixels.
A button may look disabled without being disabled programmatically. An option may appear highlighted without its selected state being exposed. Text may sit beside a form field without being associated with it as a label.
These problems already matter to people using assistive technology or keyboard navigation. The W3C guidance on accessible names explains why controls need names that identify and distinguish them, and recommends native HTML naming mechanisms where possible.
Browser agents can encounter some of the same gaps, depending on how they observe the page. Some use screenshots and vision; others use the DOM or accessibility information, or combine them. Playwright's locator guidance shows how roles and accessible names can identify elements. OpenAI's Atlas guidance describes using ARIA roles and labels when interpreting pages. Neither source implies that every agent sees the same representation.
That makes the observation method important. A label that helps an agent working from a semantic view may not tell us what a vision-based agent can infer, or what either will do after the page changes.
When two “Choose” buttons mean different things
Both buttons in the booking example have an accessible name. The problem is that “Choose” alone doesn't identify the offer attached to each one. A person can use their position on the screen; a structured view may not preserve that relationship.
“Choose refundable rate” and “Choose non-refundable rate” would distinguish the buttons more clearly. Depending on the interaction, a properly implemented selection group could also help express the shared choice and its current value. The appropriate control depends on what the user is actually doing.
Custom controls make the difference between names, values, and states especially important. The W3C's combobox pattern treats the control's name and value as separate information. Its listbox pattern also distinguishes keyboard focus from selection. Focus identifies the option currently receiving keyboard attention; it doesn't necessarily mean that option has been chosen.
A visible highlight could suggest that a rate is selected even when a programmatic reader can't determine whether it is merely focused. An incorrectly reported state can be more misleading still: the agent might treat a choice as selected when the page hasn't actually selected it. Clear names help, but the selected offer and its current state also need to be understandable.
A browser snapshot isn't an action contract
Some websites deliberately expose named operations for agents, with defined inputs. Dream Atlas examined that approach in The Website Exposed an Agent Contract. On an ordinary page, a browser agent may instead observe existing controls and decide how to interact with them, without any dedicated agent tool from the website.
Playwright MCP snapshots offer a concrete example. They provide a structured observation with roles, names, and references the browser tool can use to interact with particular elements. Those references belong to an observation that may need to be refreshed when the page changes.
Being able to identify and interact with a control doesn't mean the user has authorized the action. Nor does it show that the intended result occurred. Even a dedicated website operation with explicit inputs needs those checks. The interface may make an action legible without making it permitted or completed.
The clicked button isn't the reservation
Suppose the agent selects the refundable rate. Its browser tool reports an interaction, the button changes appearance, and the price summary updates. The page now appears to show that rate as selected. For a reversible form choice, that may be enough evidence to continue, but it doesn't establish that a reservation was submitted, accepted, or paid for.
A confirmation page, reservation identifier, or clearly reported pending status could support a stronger conclusion, depending on the product and the action. The agent also needs a fresh view of the page after interacting with it; controls and states may have changed since the previous observation.
One check is whether the agent can identify and select the intended rate. Another is whether the product makes the result of a consequential step visible to the user and agent. A reported click and a completed reservation are different events, and neither an understandable interface nor a successful interaction supplies the user's authorization on its own.
Accessibility doesn't become important because an agent showed up
I don't like the idea that accessibility has to earn its place by helping agents. Clear labels, keyboard interaction, focus behaviour, and feedback already matter to people. Adding an agent-only description that disagrees with the human-facing interface could create another source of confusion. More ARIA attributes won't help if their values are wrong or the underlying interaction remains inaccessible.
One practical check would be to compare the rendered page with the roles, names, values, and states exposed through the browser. A reversible interaction could then show whether the intended choice and its updated state are understandable. If an agent uses snapshots, its actual snapshot matters; if it uses vision or combined context, those observations need examining too.
That would establish something about one flow and the observation methods tested, not that a site is universally “agent-ready.” The cited documentation explains the mechanisms; it doesn't demonstrate a failure in any particular booking product.
For the two room rates, the important thing is that an agent can tell which offer it is choosing, whether that choice took effect, and whether any later booking action actually completed. Otherwise, the page may look clear to a person while the agent is still left to guess.
A page can look finished and still leave the choice unclear.
// End of transmission. Keep the choice legible. — ZYANE