Pourquoi l'accessibilité web est-elle toujours une « compétence obscure » en 2026 ? Les efforts de l'industrie se sont concentrés sur l'évolution de JavaScript depuis plusieurs décennies. Pourtant, l'ensemble des modèles de conception du W3C (l'ARIA Authoring Practices Guide ou APG) n'est toujours pas couvert nativement par le HTML.

Il existe aujourd'hui un million de bibliothèques de composants JS qui font toutes exactement la même chose : réinventer la roue pour combler des lacunes sémantiques et interactives majeures. Tant qu'une simple interaction nécessitera des dizaines de lignes de code, l'accessibilité restera le privilège d'une minorité d'experts et sera ignorée par la majorité des projets. Pour résoudre ce problème, nous devons comprendre comment l'histoire du web a fracturé notre manière de concevoir les interfaces.

Partie 1 : Le piège du layout et le paradoxe sémantique du web moderne

L'illusion du document dynamique

CSS permet cette chose extraordinaire de séparer l'apparence de la structure du document. Voyons comment cela induit des effets de bord redoutables.

Dans les premiers jours du web, la question d'une divergence entre l'arbre d'accessibilité (AOM) et l'arbre structurel (DOM) ne se posait pas. Les deux mondes étaient strictement fusionnés. Le HTML était un format de document linéaire : on utilisait des boutons pour soumettre des formulaires, des cases à cocher pour des choix binaires, et des liens pour changer de page. Il n'y avait ni Single Page Applications (SPA), ni menus burgers, ni fenêtres modales personnalisées. Tout apparaissait dans l'ordre réel du flux des données, offrant une robustesse native où chaque élément possédait une localisation précise, une apparence standardisée, un rôle clair, prévisible et immuable.

Cependant, l'évolution du CSS et du JavaScript a scindé l'expérience utilisateur en deux mondes parallèles. D'un côté, le CSS moderne (Flexbox, Grid) permet de dissocier complètement l'ordre visuel de la structure du code. Visuellement, un élément peut être déplacé n'importe où sur l'écran, mais, sans correction via tabindex, la navigation au clavier et les lecteurs d'écran suivront toujours l'ordre initial et linéaire du DOM.

C'est le piège classique du layout : ce qui est vu et ce qui est parcouru n'ont pas nécessairement le même ordre. Pour corriger cela, les développeurs doivent injecter des scripts lourds pour manipuler dynamiquement l'attribut tabindex ou déplacer manuellement les nœuds du DOM en fonction de la taille de l'écran. Le web tente ainsi d'adapter une architecture de document historiquement statique aux besoins graphiques et dynamiques imposés par le design (visuel) moderne.

L'hérésie du design visuel exclusif

La culture technique dominante souffre d'un biais majeur : concevoir « l'écran d'abord » (et souvent à la souris). Ce paradigme pousse à l'utilisation abusive et stérile de balises neutres comme <div> ou <span> pour fabriquer des composants complexes (comme des boutons ou des interrupteurs).

Pourtant, la saine pratique d'ingénierie logicielle consiste à choisir la balise native possédant la solution de fallback la plus robuste. Par exemple, si l'on souhaite créer un composant de type "Switch" (interrupteur), le point de départ s'appuyant sur le bon sens sémantique consiste à utiliser un <input type="checkbox">. Même si les feuilles de style ou les scripts échouent à se charger, la case reste fonctionnelle (cochée/décochée). L'expérience utilisateur de base est préservée : en l'absence de JavaScript, la valeur du champ sera simplement mise à jour par envoie de formulaire au lieu d'être envoyée par Ajax.

Cependant, si on choisit un élément (fallback) dont le rôle est éloigné du composant de destination (exemple : passer d'une span à un bouton), l'écart se creuse. Un bouton, un lien ou une case à cocher ne réagissent pas de la même façon aux touches du clavier (la touche Espace, Entrée ou les flèches directionnelles). Faute d'alternatives déclaratives, le développeur doit coder manuellement chaque événement manquant pour combler l'écart entre la sémantique de l'élément de base (fallback) et le comportement attendu de par son nouveau rôle (ex : comportement lors d'une pression sur la barre espace, type d'action lors d'un click, sans oublier que l'apparence, le style, doit être cohérente avec le rôle).

Le fardeau de la promesse ARIA

Pour corriger ces écarts, la spécification ARIA (Accessible Rich Internet Applications) a été introduite comme un pansement sémantique. Mais ARIA souffre d'un paradoxe inhérent : elle oblige le développeur à maintenir manuellement une "promesse sémantique" via JavaScript. ARIA dit au développeur : « Vous êtes autorisé à modifier le comportement d'un élément natif, mais vous devez utiliser mes attributs pour ré-exposer sa sémantique aux technologies assistives, et vous devez coder vous-même toute la logique d'interaction associée. »

C'est là que le modèle s'effondre sous le poids de la complexité. Par manque de temps ou de spécialisation, le code se retrouve truffé de "mauvais ARIA" (des attributs injectés naïvement, sans logique événementielle derrière).

Prenons un cas d'usage devenu universel : un site adaptatif (responsive) affiche un gros bloc d'information avec un titre. Sur l'écran d'un ordinateur, le titre est statique. Sur l'écran d'un smartphone, pour économiser l'espace, ce titre (ou son conteneur) doit, dans certains design, changer de nature et devenir un bouton accordéon (un déclencheur dropdown) capable de masquer ou d'afficher le bloc sous-jacent. En l'état actuel des technologies, réaliser cette mutation contextuelle impose d'écrire du JavaScript pour écouter les dimensions de l'écran, intercepter les clics, commuter l'état aria-expanded, altérer dynamiquement le rôle et gérer le focus.

On peut pas, et on ne doit pas, se contenter d'un simple hack CSS. En mettant par exemple le titre dans une case à cocher et en utilisant un selecteur de voisin input[checked].title ~ div {display: block;} . C'est une solution qui parait très élégante lorsqu'on débute car on croit alors s'émanciper de javascript : Une intention théoriquement légitime, mais qui ignore les principes et les contraintes de l'accessibilité.

Le constat est sans appel : le langage de balisage est devenu dépendant d'une surcouche programmatique logicielle pour assurer sa propre sémantique.

Partie 2 : L'architecture AriaML ou la sémantique déclarative responsive

Face à ce constat, nous avons deux choix :

• Soit nous figeons le web dans un paradigme statique et abandonnons le CSS et le JavaScript (retour à la pré histoire du web),
• Soit nous donnons enfin des capacités sémantiques et dynamiques au langage de balisage lui-même. C'est l'objectif d'AriaML (Aria Markup Language), un fork du HTML conçu pour redonner au document son autonomie et déspécialiser l'accessibilité en la rendant purement déclarative.

AriaML introduit une architecture qui résout les problématiques soulevées en éliminant le besoin de scripts tiers pour la structure et l'interactivité de base.

1. Les Feuilles de Comportement (Behavior Sheets .bhv)

Pour résoudre le problème des composants qui doivent changer de nature selon la taille d'écran (comme notre titre devenant un bouton accordéon sur mobile), AriaML sépare les responsabilités. Tout comme le CSS gère l'apparence via les Media Queries, la Behavior Sheet gère la sémantique et l'interaction de manière responsive.

Ces feuilles utilisent une syntaxe proche du CSS, mais agissent exclusivement sur la dynamique du DOM et de l'AOM. Elles permettent de lier les éléments entre eux (définir nativement qu'un élément contrôle l'état expanded / collapsed d'un autre) et de modifier l'ordre réel du DOM en fonction des contraintes de l'écran. Le décalage entre l'ordre visuel et l'ordre de navigation au clavier disparaît, maintenant une cohérence parfaite et automatique sans aucun script de manipulation de focus.

Les "feuilles de comportement" sont non normatives. En utilisant des selecteurs, on peut creer les composants interactifs que l'on souhaite. C'est très pratique si l'on doit injecter ces comportement sur un site auquel on a enlever ses scripts JS sans avoir à modifier les templates.

2. L'intégration du cycle de vie et de la navigation

Les patterns de navigation courants (Single Page Application, transitions de formulaires) et leurs critères d'accessibilité associés sont intégrés au cycle de vie natif du document.

Des zones amovibles sont définies grâce à l'attribut nav-slot. Ainsi, lorsqu'un utilisateur clique sur un lien ou soumet un formulaire, AriaML prend en charge la mutation ciblée et chirurgicale des zones concernées de façon purement déclarative. Durant cette phase de transition de l'URI, le document bascule automatiquement à l'état aria-busy="true", gère l'inertie des zones non modifiées et repositionne intelligemment le focus sur le nouveau contenu. Le poids des requêtes est réduit, les ressources CPU sont préservées (pas de recalcule de page à chaque changement de contexte), et l'accessibilité aux lecteurs d'écran est garantie par le moteur de rendu, éliminant les comportements parfois défaillants des routeurs JS.

3. L'unification du modèle de données et de la sémantique par XPath

AriaML élimine les redondances historiques du HTML en supprimant les notions obsolètes de doctype, de balises <head>, <body>, ou de balises <meta> dupliquées. L'intégralité des métadonnées et du modèle d'état du document est centralisée dans un bloc de données standardisé au format JSON-LD (Schema.org).

Pour lier ces données aux éléments d'affichage sans recourir à un framework JavaScript, AriaML ressuscite et intègre les concepts déclaratifs du module XForms de l'XHTML via l'attribut ref. Cet attribut utilise la puissance de XPath (technologie native présente dans tous les navigateurs depuis les années 2000) pour lier et synchroniser en temps réel le contenu d'un élément (ou sa valeur si c'est un champ de formulaire) avec le modèle de données sous-jacent.

Voici un exemple de document AriaML valide, complet et dynamiquement synchronisé :

<aria-ml>
    <script type="application/ld+json">{
        "@context": "[https://schema.org](https://schema.org)",
        "@type": "WebPage",
        "name": "Rendre l'accessibilité accessible",
        "description": "Un manifeste pour un web déclaratif et résilient."
    }</script>

    <h1 ref="name"></h1>
    <p ref="description"></p>
</aria-ml>

Le modèle d'état pourra servir de base à une future synchronisation réactive avec le serveur (sans JavaScript). C'est à l'étude (et vous pouvez contribuer!)

Rétrocompatibilité, Sécurité et Résilience

Bien qu'AriaML se comporte comme un langage autonome, il est pensé pour être parfaitement rétrocompatible et s'intégrer de manière fluide dans l'écosystème existant :

• Négociation de contenu : Côté serveur (via une implémentation SSR PHP), le serveur analyse le header Accept. Si le navigateur supporte nativement le type text/aria-ml, le document brut lui est envoyé. Sinon, le serveur délivre le document AriaML encapsulé dans un conteneur HTML standard accompagné d'un polyfill d'interprétation (en JavaScript - SIC). Ce même pollyfill est disponible en tant que web extension. Il permet au navigateur de recevoir la version text/aria-ml et de la traiter même lorsque JavaScript est désactivé par l'utilisateur.
• Sécurité renforcée : En déplaçant les logiques d'interaction et de synchronisation des données dans une couche déclarative, AriaML rend à nouveau JavaScript optionnel dans la plupart des cas. Cela réduit drastiquement la surface d'attaque du navigateur en limitant l'exécution de scripts complexes, éliminant ainsi les inévitables failles zero-day courantes, liées à la complexité des moteurs JS, et restreignant les capacités de fingerprinting.

En retirant l'accessibilité des mains des seuls scripts pour l'inscrire directement au niveau du langage déclaratif, AriaML la déspécialise. Elle redevient une caractéristique native et automatique de tout document web, accessible à tout intégrateur, designer ou développeur junior. Le JavaScript peut alors enfin retrouver sa fonction originelle : une couche d'amélioration progressive non intrusive.