Accessibility Tree

Regarde ce que voit un lecteur d’écran.

Pas ce que toi tu vois.

Ce que eux voient.

Pas ton DOM avec ses divs bien indentées.
Pas ton composant React avec ses jolis hooks.

Mais l’Accessibility Tree.

Ce truc planqué dans les DevTools.

Un arbre parallèle.
Un reflet sémantique.
Le monde réel pour ceux qui naviguent sans leurs yeux.

Et parfois… c’est le cauchemar.

🧨 T’as oublié un aria-label ?
Le bouton est “non nommé”.
T’as foutu 15 <div> imbriquées avec un onClick ?
Y’a plus de structure, plus d’ordre logique.
T’as stylé un <span> pour en faire un faux bouton ?

Pour le lecteur d’écran, c’est du texte mort. Pire qu’un bug : un silence.

L’Accessibility Tree, c’est là que tout pète ou tout brille.

C’est pas un outil “bonus”.
C’est ton test ultime.

T’as beau avoir passé tous les checkers, si cet arbre est vide ou foireux… ton accessibilité est du flan.

💡 L’erreur, c’est de croire que le HTML est visuel.
Le HTML est sémantique.
Le CSS, c’est l’apparence.

Mais le HTML, c’est la vérité brute.

Et l’Accessibility Tree, c’est son miroir audio.

Le jour où j’ai compris ça, j’ai arrêté de shipper des composants juste parce qu’ils “avaient l’air bien”.

Je suis allé voir comment ils sonnent.

Et ça a tout changé.

🔥 T’as déjà exploré cet arbre dans Chrome ou Firefox ?
Tu l’utilises en debug régulier ? Ou c’est encore une zone floue pour toi ?

Dis-moi comment tu l’exploites 👇