tecnología de apoyo

Qué es una tecnología de apoyo

Una tecnología de apoyo es cualquier herramienta —programa o aparato— que hace de puente entre una persona y su dispositivo cuando la forma habitual de usarlo no le sirve. El término aparece constantemente en la normativa de accesibilidad porque es el otro extremo del contrato: tu web pone la información, la tecnología de apoyo la traduce a un canal que la persona puede percibir y manejar.

Lo importante de esa definición es lo que implica. La herramienta no interpreta ni adivina: reexpresa lo que encuentra en el código. Si tu botón es un div sin nombre, lo que la persona recibe es exactamente eso: un elemento sin nombre. La accesibilidad no ocurre en la tecnología de apoyo, ocurre en tu HTML. La herramienta solo hace visible lo bien o mal que está hecho.

Las principales, y qué necesita cada una

Lectores de pantalla. Convierten el contenido en voz sintética o en braille, y permiten navegar saltando por encabezados, enlaces, regiones o formularios. Necesitan estructura: encabezados con jerarquía real, texto alternativo en las imágenes que aportan información, etiquetas asociadas a cada campo, nombres de enlace que se entiendan fuera de contexto.

Ampliadores de pantalla. Aumentan una zona de la pantalla, a veces mucho. Quien los usa ve una porción pequeña del total, así que necesita que las cosas relacionadas estén cerca unas de otras: el mensaje de error junto a su campo, no arriba del formulario; la confirmación junto al botón que la provoca. También necesitan que la página aguante el zoom sin desbordarse horizontalmente.

Navegación solo por teclado. No siempre implica un programa aparte: hay mucha gente que no puede usar un ratón con precisión y se mueve con tabulador y flechas. Necesita que todo lo interactivo sea alcanzable, que el foco se vea con claridad, que el orden de tabulación siga al orden visual y que no haya trampas de las que no se pueda salir.

Reconocimiento de voz. Se maneja el equipo dictando: «pulsa Enviar solicitud». Para que eso funcione, el nombre accesible del control tiene que coincidir con el texto que se ve. Es la razón técnica por la que un aria-label que no coincide con el texto visible del botón rompe el control por voz.

Teclados alternativos, conmutadores y punteros adaptados. Barridos, pulsadores, seguimiento ocular. Casi todo se reduce a lo mismo: número de acciones necesarias y tolerancia al error. Un formulario con doce campos opcionales y un límite de tiempo es hostil por diseño.

Ajustes del propio sistema y del navegador. Alto contraste, tamaño de fuente del sistema, reducción de movimiento. No suele considerarse «tecnología de apoyo» en sentido estricto, pero rompe webs con la misma facilidad cuando el CSS fija tamaños en píxeles absolutos o ignora las preferencias del usuario.

Lo que veo cuando audito

Hay dos ideas equivocadas que me encuentro casi siempre, y las dos salen caras.

La primera es pensar que la tecnología de apoyo arregla la web. He oído literalmente «si tiene un lector de pantalla, ya lo leerá». No. La herramienta anuncia lo que hay. Cuando un enlace pone «leer más» catorce veces en la misma página, lo que la persona oye es «leer más» catorce veces, sin manera de distinguirlos. Cuando la imagen de una tabla de precios no tiene alternativa, la información sencillamente no existe para quien no la ve.

La segunda es tratar el asunto como algo minoritario y raro. En la práctica, lo que descubro auditando es que la mayor parte del arreglo beneficia a todo el mundo. Un foco visible ayuda a cualquiera que rellene un formulario largo con el teclado. Un contraste decente se agradece con el móvil al sol. Un mensaje de error junto a su campo y escrito en cristiano reduce el abandono de todos los usuarios, usen lo que usen.

Y hay una prueba que no cuesta nada y que recomiendo antes que cualquier auditoría: guarda el ratón y completa tu propio proceso de compra o de contacto solo con el teclado. En diez minutos vas a encontrar más problemas reales que en un informe automático de cuarenta páginas.

Por qué le importa a un negocio

Porque el fallo es silencioso. Una persona que no puede terminar el formulario no te escribe para contártelo. Se va. En tu panel de analítica eso aparece como una tasa de abandono que llevas meses sin explicar, y ninguna métrica te va a señalar la causa.

Porque es obligatorio en un buen número de sectores. El EAA es una directiva europea, y una directiva no se aplica sola: obliga a los Estados a transponerla. En España lo hace la Ley 11/2023, de 8 de mayo, cuyas obligaciones son aplicables desde el 28 de junio de 2025 al comercio electrónico y a otros servicios privados. Por su parte, el RD 1112/2018 obliga al sector público —y a sus proveedores, por vía contractual— con plazos escalonados: 20 de septiembre de 2019 para los sitios nuevos, 20 de septiembre de 2020 para los preexistentes y 23 de junio de 2021 para las aplicaciones móviles. La referencia técnica de ambos es la EN 301 549, cuya versión 3.2.1 incorpora las WCAG 2.1 en nivel AA —ese es el listón exigible, aunque la versión más reciente de las pautas sea la 2.2—, y buena parte de esos criterios existen precisamente para que las tecnologías de apoyo funcionen.

Porque el mismo trabajo mejora el posicionamiento. Un rastreador tampoco ve el diseño: lee estructura, encabezados, alternativas textuales y enlaces. La lista de arreglos se solapa casi entera con lo que recomiendo en SEO y detallo en accesibilidad.

Errores frecuentes

Suponer que instalar un widget sustituye al trabajo. Las barras flotantes que cambian tamaños y colores no tocan el marcado que hay debajo, que es de donde bebe la tecnología de apoyo. En algunos casos empeoran las cosas, porque reescriben el DOM por encima de lo que la herramienta ya estaba interpretando bien.

Diseñar pensando solo en ceguera total. Es el sesgo más común. Ampliación, manejo por voz, movilidad reducida y sensibilidad al movimiento generan requisitos distintos, y a veces en tensión entre sí. Optimizar solo para el lector de pantalla deja fuera a mucha gente.

Mensajes que aparecen y desaparecen. El aviso de «añadido al carrito» que se esfuma a los tres segundos no llega a quien navega con voz sintética ni a quien está mirando otra zona de la pantalla con un ampliador. Si el cambio importa, hay que anunciarlo en el árbol de accesibilidad y dejarlo el tiempo suficiente.

Confiar en el porcentaje de una herramienta automática. Detecta lo detectable: contraste, atributos ausentes, roles inválidos. No detecta si el texto alternativo describe la imagen, si el orden de tabulación es lógico o si el error se entiende. Una nota alta no es conformidad.

Afirmar pruebas que no se han hecho. Decir «probado con lector de pantalla» sin haberlo hecho convierte un problema técnico en uno de credibilidad. En este sitio la declaración de accesibilidad detalla qué se ha verificado y qué no, precisamente para no caer en eso.