Dinoer

L'arbre d'accessibilité

La même page, affichée sous forme de texte, et générée directement par le navigateur. Cela coûte presque rien, et pour la plupart des tâches, c'est la seule vue dont Dinoer a besoin pour afficher les résultats.

Chaque navigateur crée une deuxième représentation de la page qu’il affiche : un arbre de rôles et de noms, destiné aux technologies d’assistance. Un lecteur d’écran l’utilise pour dire « bouton, Se connecter » plutôt que pour décrire les pixels.

Ce n’est pas quelque chose que Dinoer invente. C’est déjà là, dans chaque page qui a été ouverte, et cela correspond exactement à ce dont un modèle de langage a besoin — c’est pourquoi, pour Dinoer, ce n’est pas une option parmi plusieurs, mais la principale façon dont une page est lue.

À quoi ça ressemble

/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

Sortie réelle, en environ mille millisecondes, sans aucune étape de rendu — --a11y renvoie l’arbre et rien d’autre. Il n’y a pas de « mode rapide » distinct auquel s’abonner : avec aucun code de capture d’écran restant dans l’outil, c’est simplement la manière dont Dinoer lit une page.

Ce que le HTML brut ne permet pas de faire

Rôles. heading [level=1], link, et — sur une page de formulaire — textbox, combobox, button. Pas « un rectangle aux coins arrondis, » mais ce que l’élément est.

Destinations. link "Learn more" suivi de /url:. Où cela mène, avant de cliquer.

Structure. Ce qui se trouve sous quoi, sans les centaines d’éléments de mise en page que l’œil humain filtre automatiquement et qu’un budget limité ne peut pas gérer. <div>

Cela suffit souvent en soi

Quatre pages, trois requêtes, un mot-clé trouvé avec son contexte environnant — et aucune étape de rendu par navigateur exécutée à aucun moment.

L’arborescence est autonome pour toute une classe de tâches : recherche de texte ou d’une balise, navigation par liens puisque chaque href s’y trouve, vérification qu’un élément est présent, découverte de la manière dont une page est organisée. extraire_texte prend le relais là où la structure de l’arborescence cesse d’être importante et seulement le contenu textuel de la page compte. Les deux vues, côte à côte →

Une zone de dessin, une image cliquable sans étiquette accessible : celles-ci n’offrent rien que l’arbre ne puisse exposer, et Dinoer n’a aucun mécanisme de secours pour elles. C’est une limite réelle et déclarée, pas une limite cachée. Ce que la perception ne peut atteindre →

Pourquoi cela compte au-delà de Dinoer

Une page dotée d’un arbre d’accessibilité bien structuré est lisible par un lecteur d’écran, un moteur de recherche et un agent ; le même arbre sert les trois. Une page qui utilise des balises <div> stylisées pour ses boutons est opaque aux trois à la fois. L’arbre n’est pas une fonctionnalité d’accessibilité qui a l’avantage d’aider les machines. C’est la structure de la page, rendue explicite, et c’est celui qui rédige la page qui décide si cette structure existe.

En bref

  • Le navigateur construit cet arbre pour chaque page, afin de faciliter l’utilisation par les technologies d’assistance.
  • Il contient des rôles, des destinations et une structure ; une image n’en contient aucune de ces informations sous forme de texte.
  • --a11y le renvoie sans étape de rendu, en environ une seconde.
  • L’absence d’une représentation sémantique accessible signifie qu’il n’y a aucun moyen de contournement ; utilisez [extraire_texte] pour les textes narratifs, et acceptez la limite réelle où aucune des deux solutions n’est utile.