La première chose à dire clairement est que le long et lent débat sur la question de savoir si les navigateurs devraient rendre les mathématiques nativement a été tranché. Firefox rend MathML depuis le début des années 2000 ; WebKit a intégré une implémentation utilisable dans Safari en 2013 ; le retardataire, Chromium, a finalement intégré MathML Core dans la version 109 en janvier 2023. Cette seule version a débloqué la plateforme : à mi-2026, les principaux moteurs de navigateurs sur chaque ordinateur de bureau et presque chaque téléphone parlent MathML comme langage de première classe. La solution de repli que le web avait standardisée pendant près de vingt ans — rendre les maths comme une image, avec un attribut alt que l’utilisateur lecteur d’écran devait accepter sans pouvoir vérifier — n’est plus la valeur par défaut responsable.

Ce qui a changé en 2023 est plus étroit que le titre ne le suggère. Chromium n’a pas implémenté l’intégralité de MathML 3 ; il a implémenté MathML Core, un sous-ensemble délibérément limité aux éléments que les navigateurs peuvent rendre de manière fiable et que les technologies d’assistance peuvent naviguer. La notation des mathématiques élémentaires (division longue, retenues, additions empilées) n’est pas dans Core. Le retour à la ligne dans une longue équation est dans Core mais les heuristiques sont conservatrices. Certains opérateurs élastiques avancés se rendent encore de manière incohérente entre les moteurs. Mais la structure de base — fractions, radicaux, indices et exposants, matrices, intégrales, sommes, le dictionnaire des opérateurs — est désormais dans chaque moteur qui compte.

La conséquence pour l’accessibilité est directe. Une page qui émet du MathML directement dans le DOM livre une expression sémantique qu’un lecteur d’écran peut parler, naviguer et relire à un niveau de verbosité différent. Une page qui émet une image avec un attribut alt livre une seule phrase dans laquelle l’utilisateur lecteur d’écran ne peut pas plonger, ne peut pas relire et ne peut pas copier dans une calculatrice. Pendant dix ans, le compromis était réel parce que Chromium ne pouvait pas rendre MathML et que le repli sur les images signifiait moins de pages cassées. Ce compromis n’est plus valable.

MathJax était le pont qui a maintenu les mathématiques lisibles sur le web pendant la longue période sans Chromium. Depuis sa première version en 2010, MathJax prenait du LaTeX ou du MathML en source et produisait du HTML ou du SVG stylisé que tout navigateur pouvait rendre. Pendant la majeure partie de son histoire, il était la couche de rendu principale pour le contenu mathématique sur le web — Wikipedia, arXiv, MathOverflow, Stack Exchange et la grande majorité des plateformes de publication académiques intégraient MathJax sur chaque page.

Le rôle que joue MathJax en 2026 est différent. Avec Chromium rendant MathML nativement, le travail de moteur de rendu de dernier recours est terminé. Ce que fait désormais MathJax, et fait mieux que tout autre outil, c’est se positionner devant des sources LaTeX héritées et les convertir en MathML propre que le navigateur rendra directement. Ses versions v3 et v4 ont été réécrites avec cela à l’esprit : le parser d’entrée LaTeX est mature, la sortie MathML est conforme aux normes, et l’environnement d’exécution peut être configuré pour émettre du MathML puis s’effacer, laissant le navigateur prendre en charge le travail de mise en page. La bibliothèque est plus lourde que souhaité sur une page critique, mais c’est le convertisseur LaTeX-vers-MathML le plus fiable sur le web.

La majorité du contenu mathématique sur le web a une source LaTeX quelque part en amont. La question est de savoir où la conversion LaTeX-vers-MathML se produit — au moment de la construction, à l’exécution ou jamais. La pratique qui gagne sur tous les axes d’accessibilité est la conversion au moment de la construction vers MathML, avec le MathML rendu émis directement dans le HTML de la page. La pratique qui perd sur tous les axes est d’envoyer une image d’un rendu LaTeX avec un attribut alt qui paraphrase l’équation.

Rendre les maths est la moitié du travail. L’autre moitié est la navigation : une longue équation ne peut pas être linéarisée en une seule phrase parlée sans que le lecteur perde le fil. Chaque lecteur d’écran majeur intègre désormais un « mode math » permettant à l’utilisateur d’entrer dans une fraction, de parcourir son numérateur, de plonger dans un indice, de remonter à l’expression parente et de relire la sous-expression courante à un niveau de verbosité différent. Les implémentations diffèrent en maturité, en frappes et surtout dans la bibliothèque de règles de parole qu’elles partagent.

Derrière presque toute expérience moderne de parole mathématique sur le web se trouve un projet que la plupart des ingénieurs n’ont jamais entendu parler : le Speech Rule Engine, ou SRE. Le SRE a démarré au sein de l’équipe ChromeVox de Google au milieu des années 2010 et est aujourd’hui une bibliothèque open source maintenue principalement par Volker Sorge. Il prend du MathML en entrée et émet une forme parlée structurée en sortie — dans plusieurs langues, plusieurs niveaux de verbosité et plusieurs ensembles de règles (MathSpeak, ClearSpeak, ChromeVox-classic). C’est aussi le moteur qui pilote le comportement de navigation mathématique que MathJax expose sur sa propre sortie rendue, et il est référencé par MathCAT et plusieurs expériences d’accessibilité côté navigateur.

La raison pour laquelle le SRE importe comme infrastructure est que sans bibliothèque de prononciation canonique, chaque lecteur d’écran inventerait sa propre façon de dire x au carré plus y au carré égale r au carré. Avec le SRE, les implémentations majeures convergent vers un petit ensemble d’ensembles de règles sanctionnés, ce qui signifie qu’un enseignant rédigeant une équation dans un outil de création de manuels peut prédire à peu près comment un élève utilisant NVDA, JAWS ou ChromeVox l’entendra. La convergence n’est pas complète — VoiceOver est l’exception — mais elle est réelle et croissante.

Le principe général — émettre du MathML, convertir depuis LaTeX au moment de la construction quand c’est possible, s’appuyer sur le SRE pour la parole — s’applique à chaque type de document. Les spécificités varient selon la surface. Voici des recommandations concrètes pour les quatre classes de documents que la plupart des équipes d’accessibilité produisent.

L’accessibilité des mathématiques sur le web a été la frontière d’accessibilité la plus lente à mûrir. Les normes étaient prêtes en 1998. Les lecteurs d’écran étaient prêts, de façon basique, au milieu des années 2000. Les moteurs de navigateurs ont attendu jusqu’en 2023. L’intégration entre ces trois couches — balise, rendu, parole — n’a vraiment fonctionné ensemble que dans la seconde moitié de cette année, alors que MathCAT remplaçait MathPlayer dans NVDA, que JAWS adoptait le même back-end, et que ChromeVox et MathJax convergeaient vers le même Speech Rule Engine sous-jacent.

Le travail restant se situe aux marges. La notation des mathématiques élémentaires n’est pas dans MathML Core, et les plateformes qui enseignent l’arithmétique du primaire doivent encore recourir aux extensions MathML 3 ou aux images. La navigation mathématique de VoiceOver est utilisable mais moins granulaire que ce qu’obtiennent les utilisateurs Windows. Le retour à la ligne dans les très longues équations est conservateur, et certains opérateurs élastiques se rendent encore inégalement entre les moteurs. Ce sont de vrais problèmes qui méritent d’être résolus. Ils ne sont pas du même ordre que « Chromium ne peut pas rendre les maths du tout » pendant la décennie avant 2023.

Pour une équipe d’ingénierie qui produit une nouvelle surface produit en 2026 avec du contenu mathématique, la valeur par défaut défendable est : émettre du MathML, le générer depuis LaTeX au moment de la construction quand la source le permet, recourir à MathJax v4 pour le LaTeX hérité qui ne peut pas être pré-traité, et faire confiance à la pile de lecteurs d’écran — NVDA avec MathCAT, JAWS avec MathCAT, ChromeVox avec SRE, VoiceOver nativement — pour gérer la couche de parole. Le long chemin n’est pas terminé. Mais pour la première fois, il mène quelque part de lisible.