Lo primero que conviene decir claramente es que el largo y lento debate sobre si los navegadores deben representar las matemáticas de forma nativa ha quedado zanjado. Firefox renderiza MathML desde principios de la década de 2000; WebKit incluyó una implementación usable en Safari en 2013; el que resistía, Chromium, finalmente incorporó MathML Core en la versión 109 en enero de 2023. Esa única versión desbloqueó la plataforma: a mediados de 2026, los principales motores de navegadores en todos los escritorios y prácticamente todos los teléfonos móviles reconocen MathML como un lenguaje de primera clase. La vía de escape que la web estandarizó durante casi veinte años —representar las matemáticas como una imagen con un atributo alt en el que el usuario de lector de pantalla debe confiar— ya no es el comportamiento predeterminado responsable.

Lo que cambió en 2023 es más limitado de lo que sugiere el titular. Chromium no implementó todo MathML 3; implementó MathML Core, un subconjunto deliberadamente acotado a los elementos que los navegadores pueden representar de forma fiable y que las tecnologías de apoyo pueden navegar. La representación de matemática elemental (división larga, acarreos, suma apilada) no está en Core. El salto de línea dentro de una ecuación larga sí está en Core, pero la heurística es conservadora. Algunos operadores extensibles avanzados aún se representan de forma inconsistente entre motores. Pero la estructura básica —fracciones, radicales, subíndices y superíndices, matrices, integrales, sumatorio, el diccionario de operadores— ya está en todos los motores que importan.

La consecuencia en accesibilidad es directa. Una página que emite MathML directamente en el DOM incluye una expresión semántica que un lector de pantalla puede leer, navegar y releer con un nivel de detalle diferente. Una página que emite una imagen con un atributo alt incluye una única frase en la que el usuario de lector de pantalla no puede profundizar, que no puede releer ni copiar en una calculadora. Durante diez años, la disyuntiva era real porque Chromium no podía renderizar MathML y recurrir a imágenes reducía las páginas rotas. Esa disyuntiva ya no existe.

MathJax fue el puente que mantuvo legibles las matemáticas en la web durante el largo período en que Chromium no las soportaba. Desde su primera versión en 2010, MathJax tomaba LaTeX o MathML en la fuente y producía HTML con estilos o salida SVG que cualquier navegador podía renderizar. Durante la mayor parte de su historia fue la capa principal de renderizado de contenido matemático en la web: Wikipedia, arXiv, MathOverflow, Stack Exchange y la gran mayoría de las plataformas de publicación académica incluyeron MathJax en cada página.

El papel que desempeña MathJax en 2026 es diferente. Con Chromium renderizando MathML de forma nativa, el trabajo de renderizador de última instancia ha concluido. Lo que hace MathJax ahora, y hace mejor que ninguna otra herramienta, es situarse delante de fuentes LaTeX heredadas y convertirlas en MathML limpio que el navegador renderizará directamente. Sus versiones v3 y v4 fueron reescritas con este objetivo: el analizador de entrada LaTeX es maduro, la salida MathML es conforme a los estándares, y el entorno de ejecución puede configurarse para emitir MathML y luego apartarse, dejando que el navegador realice el trabajo de diseño. La biblioteca es más grande de lo deseable en una página de ruta crítica, pero es el conversor LaTeX a MathML más fiable de la web.

La mayoría del contenido matemático en la web tiene alguna fuente LaTeX en algún punto previo de la cadena. La pregunta es dónde ocurre la conversión de LaTeX a MathML: en tiempo de compilación, en tiempo de ejecución o nunca. El patrón que gana en todos los criterios de accesibilidad es la conversión en tiempo de compilación a MathML, con el MathML renderizado emitido directamente en el HTML de la página. El patrón que pierde en todos los criterios es enviar una imagen de un renderizado LaTeX con un atributo alt que parafrasea la ecuación.

Renderizar las matemáticas es la mitad del trabajo. La otra mitad es la navegación: una ecuación larga no puede linealizarse en una sola frase hablada sin que el lector pierda el hilo. Todos los principales lectores de pantalla incluyen ahora un «modo matemático» que permite al usuario entrar en una fracción, recorrer el numerador, bajar a un subíndice, saltar a la expresión principal y releer la subexpresión actual con un nivel de detalle diferente. Las implementaciones difieren en madurez, en los atajos de teclado y, fundamentalmente, en qué biblioteca de reglas de pronunciación comparten.

Detrás de casi toda experiencia moderna de pronunciación matemática en la web hay un proyecto del que la mayoría de los ingenieros nunca han oído hablar: el Speech Rule Engine, o SRE. El SRE nació en el equipo ChromeVox de Google a mediados de la década de 2010 y es ahora una biblioteca de código abierto mantenida principalmente por Volker Sorge. Toma MathML como entrada y emite una forma hablada estructurada como salida, en múltiples idiomas, múltiples niveles de detalle y múltiples conjuntos de reglas (MathSpeak, ClearSpeak, ChromeVox-classic). Es también el motor que impulsa el comportamiento de navegación matemática que MathJax expone en su propia salida renderizada, y tanto MathCAT como varios experimentos de accesibilidad en el lado del navegador lo referencian.

La razón por la que el SRE importa como infraestructura es que, sin una biblioteca de pronunciación canónica, cada lector de pantalla inventaría su propia forma de decir x al cuadrado más y al cuadrado igual a r al cuadrado. Con el SRE, las principales implementaciones convergen en un pequeño conjunto de conjuntos de reglas sancionados, lo que significa que un docente que escribe una ecuación en una herramienta de creación de libros de texto puede predecir aproximadamente cómo la escuchará un estudiante que use NVDA, JAWS o ChromeVox. La convergencia no es completa —VoiceOver es la excepción— pero es real y va en aumento.

El principio general —emitir MathML, convertir desde LaTeX en tiempo de compilación cuando sea posible, apoyarse en el SRE para la pronunciación— se aplica a todos los tipos de documentos. Los detalles cambian según la superficie. A continuación se ofrecen recomendaciones concretas para las cuatro clases de documentos que más frecuentemente gestiona un equipo de accesibilidad.

La accesibilidad matemática en la web ha sido la más lenta de las grandes fronteras de accesibilidad en madurar. Los estándares estaban listos en 1998. Los lectores de pantalla estaban listos, de forma básica, a mediados de la década de 2000. Los motores de navegadores tardaron hasta 2023. La integración entre esas tres capas —marcado, renderizado, pronunciación— encajó de verdad solo a lo largo de la segunda mitad de ese año: cuando MathCAT sustituyó a MathPlayer en NVDA, cuando JAWS adoptó el mismo back-end y cuando ChromeVox y MathJax convergieron en el mismo Speech Rule Engine subyacente.

El trabajo que queda está en los márgenes. La notación de matemática elemental no está en MathML Core, y las plataformas que enseñan aritmética de niveles iniciales aún deben recurrir a las extensiones de MathML 3 o a imágenes. La navegación matemática de VoiceOver es usable pero menos granular que lo que obtienen los usuarios de Windows. El salto de línea del navegador dentro de ecuaciones muy largas es conservador, y algunos operadores extensibles aún se renderizan de forma irregular entre motores. Estos son problemas reales que vale la pena corregir. No son el mismo tipo de problema que «Chromium no puede renderizar matemáticas en absoluto», que fue la situación durante la década anterior a 2023.

Para un equipo de ingeniería que en 2026 lanza una nueva superficie de producto con contenido matemático, la opción predeterminada más justificable es: emitir MathML, generarlo desde LaTeX en tiempo de compilación cuando la fuente lo permita, recurrir a MathJax v4 para el LaTeX heredado que no pueda preprocesarse, y confiar en la pila de lectores de pantalla —NVDA con MathCAT, JAWS con MathCAT, ChromeVox con SRE, VoiceOver de forma nativa— para gestionar la capa de pronunciación. El largo camino no ha terminado. Pero por primera vez, lleva a algún lugar legible.