Landmarks are uniquely identifiable
What it checks
AI browser agents traverse the accessibility tree and use a landmark’s role plus accessible name to target the right region. Two landmarks of the same role — a primary <nav> and a footer <nav>, two <aside>s, two <main>s — without distinct accessible names are indistinguishable, so an agent can act on the wrong region. A landmark with no same-role sibling is unambiguous and is not flagged.
Standard A11yBackedAudit aggregation over the one rule it wires (landmark-unique): any page failing → fail; incomplete without a pass → warn; any pass → pass; nothing applicable → na.
Why it matters
Landmark elements — Wrapping primary content in <main> or <article>, and chrome in <nav>, <header>, <footer> or <aside>, changes what boilerplate-removal extractors keep and drop. Content inside landmark containers matching the extractor’s body selectors is retained. Subtrees whose element or ARIA role resolves to navigation, banner, contentinfo or complementary are deleted before the text ever reaches the model. On a page built from undifferentiated divs, the same extractors fall back to class/id string heuristics and text-density guesses, so nav and footer text leaks into the extracted body and body text can be discarded.
Accessibility tree consumption by computer-use… — Browser-embedded agents perceive the page as a serialized accessibility tree — role plus accessible name plus state plus an opaque element reference — and issue actions against those references rather than against CSS selectors or screen coordinates. An element’s presence, role correctness and accessible name in the a11y tree therefore determine whether an agent can see it and act on it at all. Elements that are role-suppressed, unnamed or misrole’d are functionally invisible to this class of agent, however they look on screen.
Evidence
Landmark elements
Both dominant extractors act on the landmark, and the behaviour is readable in their source. trafilatura keeps article, div, main and section nodes, and nodes marked as the article body by itemprop or role. It deletes subtrees whose role is navigation, along with footer and header markers and anything hidden from assistive technology [trafilatura-xpaths]. Its documented fallback ladder tries ‘article tags’ before dropping back to ‘the raw text of the whole page body’ [trafilatura-corefunctions].
Mozilla Readability consults ARIA landmark roles directly. Its UNLIKELY_ROLES list — menu, menubar, complementary, navigation, alert, alertdialog and dialog — triggers subtree removal. Its candidate scoring penalises footer, header, menu, sidebar, related and social, and rescues article, body, content and main [mozilla-readability-source]. HTML-AAM makes the element→role mapping normative: main→main, nav→navigation, header→banner, footer→contentinfo, article→article, aside→complementary [w3c-html-aam], over WAI-ARIA 1.2’s ratified landmark role set [w3c-wai-aria-1-2]. Anthropic’s own get_page_text is documented to ‘return the page’s visible text as plain text, prioritizing the main article content’ [anthropic-browser-use-tool], and Playwright snapshots list ‘roles and landmarks… contentinfo sections’ as snapshot contents [playwright-mcp-snapshots].
Accessibility tree consumption by computer-use…
Three independent major-vendor harnesses, all first-party. Anthropic’s read_page ‘Return[s] the page’s accessibility tree as text with each element tagged with a reference such as [ref_2]’. The security guidance instructs implementers to ‘build page reads from what the page renders (the accessibility tree or visible text), not raw DOM source’ [anthropic-browser-use-tool]. Microsoft: ‘Uses Playwright’s accessibility tree, not pixel-based input’ [playwright-mcp-repo], with snapshot mode the default and vision mode reserved for ‘pages with poor accessibility markup’ [playwright-mcp-snapshots].
Google: chrome-devtools-mcp take_snapshot is ‘a text snapshot… based on the a11y tree… along with a unique identifier (uid)’ [chrome-devtools-mcp-tool-reference]. The dominant OSS library resolves interactivity from ARIA roles, role/tabindex attributes, ARIA state and the accessibility properties ‘focusable, editable, settable’ [browser-use-clickable-elements]. The standard research benchmark exposes observation_type='accessibility_tree' [webarena-repo, webarena-paper]. The tree’s contents are governed by ratified specs [w3c-wai-aria-1-2, w3c-accname, w3c-html-aam].
Limits
Landmark elements — Landmarks are one path among several, not a gate. trafilatura also matches bare divs by id/class and falls back to justext/readability; Readability gives no special boost to <main> at all and can extract a landmark-free page perfectly well via text density. So a page with zero landmarks is degraded, not invisible. Adoption is partial — only 40.72% of pages use <main> [web-almanac-2025-accessibility] — which means extractors cannot depend on landmarks and have been tuned to work without them.
No AI-search vendor documents landmarks as a requirement, and Google explicitly disclaims special optimizations for AI features [google-ai-features-docs]. Over-nesting also backfires: multiple <main> or a <nav> wrapping real content will actively delete content, so this signal is bidirectional and an audit should penalise misuse as well as absence.
Accessibility tree consumption by computer-use… — The claim must be scoped to browser-embedded agents, and even there it is contested. Some consumers are pixel-only. Anthropic’s desktop computer-use tool is screenshot-only, with no DOM and no a11y access [anthropic-computer-use-tool]. OpenAI’s computer-use tool takes base64 PNG screenshots, and ‘the model looks at the current UI through a screenshot’ with no structured input [openai-computer-use-guide, openai-cua-announcement]. Gemini Computer Use is likewise screenshots plus action history [gemini-computer-use-docs].
And the a11y tree is not even always the better representation. A 2026 study measured Claude Sonnet 4.6 gaining +14.6pp, and GPT-5.1 at high reasoning gaining +17.5pp, when given raw HTML instead of the accessibility tree. Strong models ‘exploit layout information in HTML for better action grounding’. The a11y tree only won for lower-capability models [observation-reduction-paper]. So a11y-tree quality is a strong, well-documented determinant for one large and growing class of agent, not a universal precondition.
How it scores
Landmark elements — The proof is in the source of the two dominant extractors, not in a claim about them. trafilatura’s body selector keeps article, div, main and section, and its discard pass deletes navigation, footer and header subtrees outright. Readable, shipping code that acts on the element is documented consumer behaviour, which is the grade-A bar. The grade is about direction, not sufficiency: trafilatura also matches bare divs by id and class and falls back to justext and readability, and Readability gives <main> no special boost at all, so a landmark-free page is degraded rather than invisible.
Accessibility tree consumption by computer-use… — Three major vendors document the same architecture first-party. Anthropic’s read_page returns “the page’s accessibility tree as text with each element tagged with a reference such as [ref_2]”. The security guidance tells implementers to build page reads “from what the page renders (the accessibility tree or visible text), not raw DOM source”. Playwright MCP and browser-use serialise role, name, state and a reference the same way. Named agents acting on the tree is the grade-A bar. The scope is browser-embedded agents only: Anthropic’s desktop computer-use tool is screenshot-only, and OpenAI’s computer use “looks at the current UI through a screenshot”, so a pixel-driven agent needs none of this.
Sources
- trafilatura/xpaths.py (BODY_XPATH, OVERALL_DISCARD_XPATH) — Adrien Barbaresi / trafilatura, vendor-doc (verified 2026-08-20)
- trafilatura core functions documentation — Adrien Barbaresi / trafilatura, vendor-doc (verified 2026-08-21)
- Readability.js source — _isProbablyVisible — Mozilla, repo (verified 2026-08-20)
- HTML Accessibility API Mappings 1.0 — W3C, draft-spec (verified 2026-08-21)
- Accessible Rich Internet Applications (WAI-ARIA) 1.2 — W3C, spec (verified 2026-08-20)
- Browser use tool (browser_toolset_20260801) — Anthropic, vendor-doc (verified 2026-08-21)
- Snapshots — Playwright MCP — Microsoft, vendor-doc (verified 2026-08-20)
- Web Almanac 2025 — Accessibility chapter — HTTP Archive, dataset (verified 2026-08-20)
- AI features and your website — Google Search Central, vendor-doc (verified 2026-08-21)
- microsoft/playwright-mcp README — Microsoft, vendor-doc (verified 2026-08-21)
- chrome-devtools-mcp tool reference (take_snapshot) — Google / Chrome DevTools, vendor-doc (verified 2026-08-20)
- browser-use ClickableElementDetector source — browser-use, vendor-doc (verified 2026-08-20)
- web-arena-x/webarena repository — WebArena / CMU, dataset (verified 2026-08-20)
- WebArena: A Realistic Web Environment for Building Autonomous Agents — arXiv (Zhou et al., 2023), study (verified 2026-08-20)
- Accessible Name and Description Computation 1.1 — W3C, spec (verified 2026-08-20)
- Computer use tool — security and prompt injection guidance — Anthropic, vendor-doc (verified 2026-08-20)
- Computer use — OpenAI API guide — OpenAI, vendor-doc (verified 2026-08-21)
- Computer use — Gemini API — Google, vendor-doc (verified 2026-08-20)
- Read More, Think More: Revisiting Observation Reduction for Web Agents — arXiv (Enomoto, Obara, Zhang, Oyamada, 2026), study (verified 2026-08-20)
- Computer-Using Agent (CUA) — OpenAI, vendor-doc (verified 2026-08-20)
- mozilla/readability Readability.js source — Mozilla, vendor-doc (verified 2026-08-20)
- AI features and your website — Google Search Central — Google, vendor-doc (verified 2026-08-21)
- Computer use tool — Anthropic, vendor-doc (verified 2026-08-20)