Dinoer

The accessibility tree

The same page as text, built by the browser itself. It costs almost nothing, and for a great many tasks it is the only view Dinoer ever needs to return.

Every browser builds a second representation of the page it displays: a tree of roles and names, meant for assistive technology. A screen reader uses it to say “button, Sign in” rather than describing pixels.

It is not something Dinoer invents. It is already there, in every page ever opened, and it happens to be exactly what a language model needs — which is why, for Dinoer, it is not one option among several but the primary way a page is read.

What it looks like

/opt/dinoer/venv/bin/python3 /opt/dinoer/shot.py \
  --url https://example.com --a11y --guide-version 1.6
- heading "Example Domain" [level=1]
- paragraph: This domain is for use in documentation examples without needing permission. Avoid use in operations.
- paragraph:
  - link "Learn more":
    - /url: https://iana.org/domains/example

Real output, about a thousand milliseconds, no rendering step at all — --a11y returns the tree and nothing else. There is no separate “fast mode” to opt into: with no screenshot code path left in the tool, this is simply how Dinoer reads a page.

What it carries that raw HTML buries

Roles. heading [level=1], link, and — on a form page — textbox, combobox, button. Not “a rectangle with rounded corners,” what the element is.

Destinations. link "Learn more" followed by /url:. Where it goes, before clicking.

Structure. What nests under what, without the hundreds of layout <div>s a human eye filters out automatically and a token budget cannot.

It is often enough on its own

Four pages, three requests, a keyword found with its surrounding context — and no browser rendering step run at any point.

The tree is self-sufficient for a whole class of work: searching for text or a tag, navigating by links since every href is there, checking that an element is present, discovering how a page is organised. extraire_texte picks up where the tree’s structure stops mattering and only the page’s prose does. The two views, side by side →

A canvas, a clickable image with no accessible label — these have nothing for the tree to expose, and Dinoer has no fallback for them. That is a real, stated limit, not a hidden one. What perception does not reach →

Why this matters beyond Dinoer

A page with a well-built accessibility tree is legible to a screen reader, a search engine, and an agent — the same tree serves all three. A page that paints its buttons with styled <div>s is opaque to all three at once. The tree is not an accessibility feature that happens to help machines. It is the page’s structure, made explicit — and whoever writes the page decides whether that structure exists.

In short

  • The browser builds this tree for every page, for assistive technology.
  • It carries roles, destinations and structure — an image carries none of it as text.
  • --a11y returns it with no rendering step, in about a second.
  • No accessible semantic representation means no fallback at all — reach for extraire_texte for prose, and accept the real limit where neither helps.