Una imagen de portada de un blog con un atributo alt es un problema resuelto. Un diagrama STEM no lo es. Tres propiedades de las imágenes científicas rompen los supuestos incorporados en alt, aria-label y el modelo de síntesis de voz del lector de pantalla.

En primer lugar, la densidad de información es tan alta que una sola frase no puede contenerla. Un anillo de benceno son seis carbonos, seis hidrógenos, enlaces dobles alternados, un sistema pi deslocalizado, una geometría plana y una longitud de enlace de 1,39 angstrom. La convención de texto alternativo pide «un breve reemplazo textual»; el benceno necesita un párrafo. Comprimirlo en una frase o bien pierde la información estructural («una molécula de benceno») o produce un texto corrido ilegible que el lector de pantalla tiene que deletrear a 180 palabras por minuto.

En segundo lugar, las relaciones entre los elementos transmiten tanto significado como los elementos en sí. En un diagrama de fuerzas, la flecha desde el bloque hacia la pared no es decoración — es la fuerza normal, y su ángulo respecto al vector de gravedad es la respuesta al problema. Una descripción plana no puede codificar «el ángulo entre estas dos flechas es de 90 grados y por eso el problema se resuelve», porque la descripción plana no tiene estructura. El SVG, utilizado con cuidado, sí la tiene.

En tercer lugar, los estudiantes de STEM necesitan navegar por el diagrama, no solo escucharlo. Un estudiante que trabaja con la gráfica de una función cúbica no quiere escuchar el texto alternativo de principio a fin — quiere situarse en el máximo local, preguntar «cuál es la pendiente aquí» y luego pasar al punto de inflexión. Se trata de un modelo de interacción diferente al que los lectores de pantalla ofrecen por defecto. Construirlo requiere manejadores de teclado sobre nodos SVG individuales, un árbol de contenido descrito con ARIA y una alternativa para las pilas de tecnología de apoyo que no pueden seguir el ritmo.

Prácticamente todos los libros de texto de STEM publicados siguen distribuyendo sus diagramas en formato PNG o JPG. Una imagen rasterizada es una cuadrícula de píxeles opaca: tiene un único punto de entrada para la tecnología de apoyo, el atributo alt, y una sola alternativa, el atributo longdesc que los navegadores llevan diez años dejando obsoleto. No hay estructura dentro de la imagen a la que un lector de pantalla pueda dirigirse. El diagrama es una caja negra con una etiqueta en la parte delantera.

SVG invierte el modelo. Cada forma de un documento SVG es un nodo DOM — direccionable, enfocable y etiquetable. Un anillo de benceno renderizado como SVG tiene seis elementos circle para los carbonos, seis elementos line para los enlaces y un elemento g envolvente que nombra el conjunto. Cada uno de esos nodos puede llevar atributos role, aria-label, aria-labelledby, aria-describedby y tabindex. El lector de pantalla ve un árbol de accesibilidad con regiones nombradas en lugar de un único objeto opaco.

El SVG accesible mínimo viable lleva tres elementos en su elemento raíz svg: role=“img”, aria-labelledby apuntando a un hijo title y aria-describedby apuntando a un hijo desc o a un párrafo externo por ID. Cada uno es pequeño. Cada uno hace un trabajo que los otros dos no pueden hacer.

Una advertencia importante: role=“img” en el elemento raíz svg cambia lo que la tecnología de apoyo hace con los elementos hijo. Con role=“img”, NVDA y JAWS tratan todo el SVG como una imagen etiquetada única y no exponen los nodos internos — incluso si esos nodos internos tienen tabindex. Para obtener ambos comportamientos — una etiqueta de resumen en la parte superior y elementos hijo direccionables en el interior — conviene dejar el rol raíz sin establecer (o establecer role=“graphics-document” del módulo W3C Graphics ARIA) y colocar la etiqueta en un elemento hijo g en lugar del raíz. Los navegadores y los lectores de pantalla manejan esta combinación de forma desigual. La matriz de la sección 6 documenta qué funciona en cada caso.

El atributo longdesc fue la respuesta original a «un atributo alt no es suficiente». Los navegadores llevan años eliminando silenciosamente su compatibilidad; Firefox lo eliminó en la versión 90, Safari nunca lo implementó y Chrome lo trata como un no-op. Cualquiera que siga escribiendo longdesc=“benzene-desc.html” en 2026 está publicando marcado que nada lee. El reemplazo no es un único atributo sino un patrón de tres capas que combina una descripción en línea, un panel expandible visible y metadatos legibles por máquina.

La capa uno es el elemento desc en línea dentro del SVG. De dos a cuatro frases. Los lectores de pantalla la leen cuando se anuncia el raíz SVG. Esta es la nueva longdesc — una descripción que forma parte del documento SVG y que viaja con él dondequiera que vaya el SVG.

La capa dos es un panel de descripción expandible visible junto al diagrama, disponible para todos los lectores, no solo para los usuarios de lectores de pantalla. Una línea de resumen más un botón de divulgación que abre un recorrido textual más extenso — normalmente de tres a diez frases para una molécula de química, más largo para un diagrama de estructura celular con veinte orgánulos etiquetados. El panel visible resuelve un problema que el elemento desc en línea no puede: los estudiantes con baja visión, los estudiantes con dislexia y cualquiera que aprenda el material por primera vez también necesitan la descripción larga. Situarla detrás de un botón no la oculta a los lectores de pantalla — enumeran la divulgación, el usuario la activa y la descripción se lee en el buffer.

La capa tres son los metadatos estructurados a través de JSON-LD. Un objeto CreativeWork cuyo array accessibilityFeature enumera lo que ofrece el diagrama: longDescription, alternativeText, structuralNavigation, describedMath, tactileGraphic (si se dispone de una impresión táctil). Los motores de búsqueda, los sistemas de recomendación de contenido y los escáneres de conformidad de accesibilidad consumen estos metadatos. No aportan nada a la experiencia inmediata de lectura del lector de pantalla, pero hacen que el diagrama sea descubrible como contenido accesible — lo que importa cuando un estudiante está eligiendo entre tres libros de texto y uno de ellos anuncia sus funciones de accesibilidad en formato legible por máquina.

Los diagramas estáticos son el caso fácil. El caso difícil es el diagrama animado — una mitocondria rotando en 3D, una onda sinusoidal trazándose a lo largo del eje x, una reacción química con enlaces rompiéndose y reformándose durante cuatro segundos. La respuesta convencional es un archivo de vídeo con una pista de audiodescripción, pero eso abandona la direccionabilidad del SVG: en el momento en que se integra la animación en un vídeo, cada nodo cuidadosamente etiquetado deja de ser un nodo DOM y vuelve a ser un píxel.

La alternativa accesible es mantener la animación como SVG (o Canvas con un árbol de accesibilidad fuera de pantalla) y emitir audiodescripciones a medida que avanza la animación, impulsadas por las mismas mutaciones del DOM que impulsan el cambio visual. El patrón: un MutationObserver observa el SVG en busca de cambios — un nuevo atributo transform, un enlace que aparece, un vector que rota — y en cada cambio significativo escribe una breve actualización de texto en una región global aria-live=“polite”. La animación visual impulsa una narración de audio generada al vuelo desde la misma fuente de verdad.

La implementación tiene tres partes móviles. La primera es la propia animación, expresada como una secuencia de fotogramas clave de la línea de tiempo — los mismos datos que consume el renderizador SVG. La segunda es una capa de anotaciones: cada fotograma clave lleva un breve texto que describe qué cambia en ese momento («se forma un enlace entre C1 y C2», «la onda cruza el cero desde abajo»). La tercera es el controlador de audiodescripción, que se suscribe a la línea de tiempo, recoge cada fotograma clave anotado y escribe su texto en la región activa unos cientos de milisegundos antes de que llegue el cambio visual. El tiempo de anticipación imita lo que hace la audiodescripción de producción para el cine: la descripción se escucha justo antes del evento visual, no después.

Hay tres modos de fallo lo suficientemente comunes como para merecer una mención. Primero, las actualizaciones en ráfaga. Una animación que dispara 60 mutaciones por segundo satura el sintetizador del lector de pantalla — los anuncios se acumulan, retrasan la animación y se vuelven ininteligibles. Se deben anotar únicamente los fotogramas clave semánticamente significativos, no cada fotograma, y limitar a aprox. un anuncio cada 1500 ms. Segundo, perderse el inicio. Una región activa que no existía antes de que comenzara la animación no anunciará su primera actualización de forma fiable (véase el artículo sobre el planificador de aria-live para el problema subyacente). Montar la región activa vacía al cargar la página. Tercero, la ausencia de control de pausa. Los usuarios necesitan pausar la audiodescripción, reducir su velocidad o avanzar por ella evento a evento. Conviene construir una pequeña barra de controles — reproducir, pausar, evento anterior, evento siguiente — y conectar sus botones al mismo controlador de la línea de tiempo.

Una gráfica de función matemática que un estudiante con visión puede explorar con el cursor no es accesible hasta que un estudiante sin visión pueda explorarla con el teclado. El mecanismo es bien conocido y está mal implementado en la práctica: cada punto de datos significativo de la curva recibe tabindex=“0”, un aria-label que describe sus coordenadas y cualquier rasgo nominado («máximo local en x = -1, y = 4») y un manejador de teclado que responde a las teclas de flecha para el movimiento granular entre puntos adyacentes.

La granularidad correcta importa más de lo que la gente cree. Moverse con Tab por cada píxel graficado de una curva cúbica es hostil — el usuario escucha miles de anuncios «x igual a 0,1, y igual a 0,001» antes de llegar a cualquier cosa interesante. Moverse con Tab únicamente por los rasgos nominados (máximos locales, mínimos, puntos de inflexión, intersecciones con los ejes) es demasiado escaso. El compromiso pragmático: dos capas de navegación. La tecla Tab recorre solo los rasgos nominados — normalmente de tres a siete en una curva — y las teclas de flecha, una vez que un rasgo está enfocado, avanzan hacia la izquierda y la derecha a lo largo de la curva a un tamaño de paso definible por el estudiante, anunciando la coordenada en cada paso. Inicio y Fin saltan a los límites izquierdo y derecho de la curva. Av. Pág. y Re. Pág. saltan al siguiente rasgo nominado.

Para una gráfica de múltiples series — una gráfica de cinética química, una gráfica de oscilación de física con dos ondas — conviene añadir un eje de cambio de serie. Las teclas de flecha Arriba y Abajo se mueven entre series en la coordenada x actual; las teclas Izquierda y Derecha se mueven a lo largo de la serie actual. La convención es paralela a cómo los lectores de hojas de cálculo navegan por filas y columnas, y reutiliza un modelo mental que muchos usuarios ya tienen.

Un detalle que se pasa por alto: el punto de datos enfocado necesita un indicador de foco visible. Un usuario sin visión no lo necesita, pero un usuario con visión que usa un lector de pantalla sí, al igual que los instructores que acompañan al estudiante. Conviene renderizar un anillo de foco alrededor del elemento SVG enfocado con estilos :focus-visible — la misma convención que los anillos de foco de los botones, aplicada a los nodos SVG que el navegador no estiliza por defecto.

La verdad más difícil de este artículo: la pila de SVG accesible no funciona igual en todos los navegadores y lectores de pantalla, y las brechas no son errores en el marcado. NVDA en Firefox es la combinación más fiable — la única en la que cada patrón de este artículo se comporta como indica el mapeo de accesibilidad SVG del W3C. Todas las demás combinaciones tienen al menos una brecha conocida.

Safari en macOS con VoiceOver es la pila más problemática entre las principales. El árbol de accesibilidad SVG de WebKit tiene agujeros documentados en la forma en que expone los elementos g internos con etiquetas ARIA: las etiquetas están presentes en el DOM y son inspeccionables con el inspector de accesibilidad, pero VoiceOver no siempre las recoge cuando el usuario navega con VO-Flecha derecha. El comportamiento es inconsistente — a veces las etiquetas internas se anuncian, a veces solo se lee la etiqueta SVG raíz, sin ningún patrón visible para el cliente. El bugzilla de WebKit tiene problemas abiertos al respecto desde 2020. La implicación práctica: si el diagrama STEM funciona en Mac, eso es una condición necesaria, no suficiente. Conviene probar en Windows con NVDA antes de publicar.

Chrome en Windows con JAWS es la segunda pila más fiable — cerca de NVDA + Firefox, con un matiz: JAWS trata el role=“img” en SVG de forma más agresiva que NVDA, colapsando los nodos internos más a menudo. La solución es usar role=“graphics-document” del módulo W3C Graphics ARIA en el elemento raíz svg, que JAWS maneja correctamente. NVDA también lo maneja correctamente. Firefox y Chrome implementan ambos los mapeos de API de plataforma necesarios.

El móvil es un problema aparte. VoiceOver en iOS hereda las brechas SVG de WebKit; TalkBack en Android con Chrome maneja los nodos internos de forma fiable pero aún no admite los roles W3C Graphics ARIA, por lo que recurre al comportamiento de role=“img”. Para un editor de libros de texto que trabaje tanto para escritorio como para móvil, la opción segura es publicar dos modos SVG: un modo con navegación estructural para escritorio y un modo de «resumen más descripción larga» que deshabilita la navegación interna en móvil. El cambio de modo lo impulsa el agente de usuario y la preferencia del usuario, almacenada entre sesiones.

Una lectura de la matriz: conviene tomar NVDA + Firefox como objetivo de referencia de conformidad, documentar las alternativas de Safari y TalkBack, y nunca usar la ausencia de un anuncio de nodo interno en un Mac como prueba de que el SVG no es accesible. El diagrama puede ser perfectamente accesible — la plataforma simplemente no está exponiendo las etiquetas escritas. El inspector de accesibilidad del menú Desarrollar de Safari muestra lo que hay en el árbol aunque VoiceOver no lo lea, y es la herramienta adecuada para distinguir «marcado roto» de «plataforma rota».

La mayoría de las orientaciones publicadas sobre accesibilidad de diagramas STEM se detienen en la capa de title y desc. Eso es el 30 por ciento fácil. El 70 por ciento restante — el panel de descripción larga, la línea de tiempo de audiodescripción impulsada por mutaciones del DOM, la navegación por teclado a dos granularidades, las alternativas específicas de plataforma — es diseño de interacción tanto como marcado. El lector de pantalla es un usuario; un estudiante sin visión que usa un lector de pantalla para navegar por una gráfica de función al ritmo de un compañero con visión es un usuario diferente, con necesidades diferentes.

El beneficio es grande y desigual. Un editor de libros de texto que publica la pila completa en aprox. 600 diagramas de un libro de texto de cálculo da servicio a cada estudiante sin visión que usa ese libro, a cada estudiante con baja visión que agradece el panel de divulgación, a cada estudiante con dislexia que puede leer la descripción larga pero no puede decodificar las convenciones visuales del campo, a cada estudiante que aprende inglés como segunda lengua y encuentra la descripción estructurada más fácil que las convenciones visuales del campo, y a cada instructor con visión que produce resúmenes de audio para podcasts. El mismo marcado sirve a cinco públicos distintos. El coste es unas pocas horas por diagrama, amortizadas a lo largo de décadas de uso por estudiantes.

El estado actual del arte es desigual porque las implementaciones del árbol de accesibilidad difieren entre los sistemas operativos que utilizan realmente los estudiantes. NVDA y JAWS en Windows han cerrado la mayoría de las brechas SVG. Safari en macOS no lo ha hecho. Hasta que las plataformas converjan, el patrón de producción consiste en crear para el objetivo más exigente — NVDA + Firefox — y documentar las alternativas para las plataformas con brechas conocidas. Eso requiere más trabajo del que solía exigir el modelo del atributo alt. Es también la única forma de publicar un libro de texto de STEM que no excluya a los lectores a los que se supone que debe enseñar.