The eye test: what a rendered page hides

Two renderings of every page

A browser produces two representations of your document. One is the pixels on screen. The other is the accessibility tree: the structure of roles, names, and states exposed to screen readers, voice control, and other assistive technology. Search crawlers also depend on machine-readable document structure rather than judging a screenshot, although they do not consume the accessibility tree as an assistive technology does.

The eye test inspects only the pixels. Every defect this article describes lives in the second rendering, which is why pages that look finished can be broken in ways their authors never see.

Same pixels, different machines

Style a generic container with padding, a background, and a pointer cursor, and it becomes visually indistinguishable from a button. The two are not interchangeable machines.

The native button receives keyboard focus, activates on Enter and Space, announces itself as a button with its label, and reports a disabled state when it has one. The styled container does none of this. Nothing in the rendered appearance distinguishes them; everything in the accessibility tree does. The same split exists between a real heading and a paragraph in a large font, between an associated label and adjacent text, and between a link and a click handler on a span.

What the eye cannot check

Six properties decide whether a page is operable, and none of them are visible in a screenshot:

• Names. Does each control announce something meaningful, or is it an unlabeled field the user must guess at?
• Roles. Is the thing that looks like a button actually a button to the machine reading the page?
• States. When a section expands or an option is selected, does the exposed state change with it, or was it set once and abandoned?
• Order. Does focus travel in the sequence the content reads, or does layout styling send it leaping across the page?
• Structure. Do the headings form an outline someone could navigate, or a decoration scheme?
• Announcements. When content changes without a page load, does anyone who cannot see the change find out about it?

Why this bites generated pages hardest

The eye test is exactly the test AI-generated markup is optimized to pass. The person prompting looks at the render, approves the render, and ships the render. The accessibility tree was never in the loop. This is not a moral failing of the tools; it is a measurement problem. What gets inspected gets fixed, and the second rendering is inspected by almost no one.

That makes the checks below disproportionately valuable for pages you did not write by hand. They are the cheapest way to inspect what the prompt never asked for.

Four ways to see the hidden rendering

1. Open the accessibility panel. Every major browser shows the computed tree beside the DOM inspector. Click your most important control and read its role and name. An empty name on an interactive element is a defect, found in seconds.
2. Remove the CSS. Reload with styles disabled and read the page top to bottom. The document order and heading structure that remain are what structural navigation actually uses.
3. Put the mouse away. Tab from the top of the page and complete one real task. Visible focus, sensible order, no traps, Escape closing what it should.
4. Listen to one screen reader pass. Turn the display off, or just look away, and finish the same task on speech output alone. The question is not whether every word is announced; it is whether the task can be completed without guessing.

None of these require expertise to start. They require deciding that the second rendering is part of what "done" means.

A five-minute worked example

Take a site's main navigation, since every page has one. Open the accessibility panel and click the menu button. Three questions, three immediate verdicts.

First, its role. If the panel reports a button, the machine contract exists; if it reports generic text with a click handler, keyboard and switch users have already lost the menu, however polished it looks.

Second, its name. "Menu" or "Main navigation" passes. An empty name, or a name that is the ligature of an icon font, means a screen reader user hears "button" with no idea what it does. Voice control users lose it too: you cannot say "click menu" at a control whose accessible name is a private-use glyph.

Third, its state. Open the menu and watch the panel. If an expanded state flips when the menu opens, the page is telling the truth. If nothing in the tree changes, then visually the menu is open while machine-readably nothing happened, and the user who cannot see the animation was never told. This single check, state that updates when the interface does, separates components that were built from components that were only styled.

Five minutes, no tooling installed, and you now know more about that page's real quality than a screenshot review of the entire site would have told you. The same three questions apply to accordions, tabs, dialogs, and every other interactive pattern: role, name, state, in that order.

The standard worth adopting

A page is finished when both renderings agree: when what a sighted mouse user experiences and what a keyboard or screen reader user experiences are the same page. The eye test checks half the work. The half it misses is where most shipped defects live, and it is the half that search engines and assistive technology both benefit from you describing honestly in markup.

Frequently asked questions

If a page looks right, what could be wrong with it?

Everything the pixels do not show: whether controls have names and roles, whether focus moves in a sensible order, whether headings form a real outline, and whether state changes are announced. Two visually identical pages can differ on all of these.

How do I see what assistive technology sees?

Open the accessibility panel in your browser developer tools next to the element inspector. It shows the computed role, name, and state for each element. Reading it takes less time than installing anything.

Is this only an accessibility concern?

No. Search crawlers read structure, not pixels. A heading that is only a big font, or a link that is only a click handler, is invisible to them in the same way it is unreachable for a keyboard user.