Herramientas web adaptativas

Las herramientas de la interacción

Para las personas que dependen de herramientas web adaptativas para navegar por internet, la forma en que se construye y presenta el contenido lo es todo. La tecnología de apoyo más sofisticada del mundo no puede leer, anunciar ni operar contenido que no exista en una forma accesible. Un botón que en realidad es un <div> con estilos, una imagen sin alternativa textual o un desplegable personalizado sin compatibilidad con el teclado es sencillamente invisible —o peor aún, un callejón sin salida— para quienes dependen de estas herramientas cada día.

QualiBooth te ayuda a entender dos cosas a la vez: cómo interpretan realmente tu contenido las herramientas de un usuario y qué contenido o estructura falta, está roto o es ambiguo. Esa combinación es lo que distingue a un sitio web que técnicamente carga de uno que de verdad funciona para todos.

Esta guía recorre las principales categorías de tecnología de apoyo y adaptativa, cómo espera cada una que se comporte un sitio web y los pasos prácticos que puedes dar para construir con estas herramientas en lugar de contra ellas. También traza una línea clara entre la tecnología de apoyo genuina y los overlays de accesibilidad, porque ambas cosas se confunden con frecuencia, y esa confusión tiene consecuencias reales para usuarios reales.

Qué significan realmente las «herramientas web adaptativas»

Las herramientas web adaptativas —más comúnmente llamadas tecnología de apoyo (AT)— son software y hardware que cambian la forma en que una persona percibe u opera una interfaz digital. No son complementos de tu sitio web; son el propio entorno del usuario, configurado según sus necesidades y a menudo utilizado durante horas al día en miles de sitios.

Las principales categorías incluyen:

Lectores de pantalla que convierten el contenido en pantalla en voz sintetizada o braille actualizable.
Ampliación de pantalla que agranda y reorganiza parte o la totalidad de la pantalla.
Dispositivos de acceso por conmutador para personas que no pueden usar un teclado o ratón estándar.
Control por voz que maneja la interfaz por completo mediante comandos hablados.
Funciones integradas del navegador y del sistema operativo como modos de alto contraste, movimiento reducido y herramientas de lectura.
Ayudas a la lectura y la comprensión que simplifican, narran o reestructuran el texto.

Cada una de ellas se apoya en el mismo fundamento: una página bien estructurada, semántica y operable por teclado que sigue estándares consolidados. Cuando construyes conforme a WCAG 2.2, estás creando el contrato del que depende cada una de estas herramientas.

Lectores de pantalla: la estructura es la interfaz

Los lectores de pantalla son la tecnología de apoyo más conocida y, para muchos equipos, la más difícil de diseñar, precisamente porque la disposición visual que ves no dice casi nada sobre lo que anuncia un lector de pantalla.

Los lectores de pantalla más utilizados son NVDA y JAWS en Windows, VoiceOver en macOS e iOS, y TalkBack en Android. No «ven» tu página; construyen un modelo a partir del árbol de accesibilidad, que se deriva de la semántica de tu HTML y de cualquier ARIA que añadas encima.

Qué necesitan de ti los lectores de pantalla

Elementos semánticos reales. Usa <button>, <a>, <nav>, <main>, <h1>–<h6> y <table> para lo que son. Un encabezado debe ser un encabezado para que los usuarios puedan saltar entre secciones; un enlace debe ser un enlace para que aparezca en la lista de enlaces.
Alternativas textuales significativas. Toda imagen informativa necesita un atributo alt que describa su propósito. Las imágenes decorativas deben tener un alt="" vacío para que se omitan en lugar de anunciarse como ruido.
Etiquetas programáticas para los controles. Los campos de formulario necesitan elementos <label> asociados; los botones solo con icono necesitan un nombre accesible mediante aria-label o texto oculto visualmente.
Una jerarquía lógica de encabezados. Los encabezados son la principal forma en que los usuarios de lectores de pantalla hojean una página. Saltarse niveles o usar encabezados solo por su tamaño visual rompe esa navegación.
ARIA correcto, y solo cuando sea necesario. ARIA puede comunicar estados (expandido, seleccionado, deshabilitado) y roles para widgets personalizados, pero un ARIA mal hecho es peor que ninguno. La primera regla de ARIA es usar HTML nativo siempre que sea posible.

Un punto de confusión habitual es la diferencia entre un lector de pantalla y la conversión de texto a voz ordinaria. Una herramienta de lectura narra el texto; un lector de pantalla expone y opera toda la interfaz, incluyendo controles, estados y navegación. Tratamos esta distinción en profundidad en texto a voz frente a lectores de pantalla.

Dado que las herramientas automatizadas solo detectan una fracción de los problemas de lectores de pantalla, la única manera fiable de saber cómo suena tu sitio es probarlo como lo hacen los usuarios. Nuestra guía de pruebas con lectores de pantalla recorre el flujo de trabajo práctico, y una evaluación dedicada con lector de pantalla somete tus recorridos más importantes a ese proceso con testers experimentados.

Ampliación de pantalla: diseña para la vista ampliada

Las personas con baja visión a menudo amplían la pantalla entre un 200 % y un 800 % o más, viendo solo una pequeña porción de la página a la vez. Algunas usan el ampliador del sistema operativo; otras recurren al zoom del navegador o a software especializado.

Con una ampliación alta, decisiones de diseño en las que nunca piensas se vuelven críticas:

Reorganización (reflow). El contenido debe reorganizarse en una sola columna al 400 % de zoom (criterio de éxito 1.4.10 de WCAG 2.2) para que los usuarios no tengan que desplazarse en dos direcciones para leer una frase.
Proximidad de los elementos relacionados. Si un mensaje de error aparece lejos del campo que describe, un usuario con ampliación puede que nunca los vea en el mismo viewport. Mantén juntos las etiquetas, las entradas y la retroalimentación.
Foco visible. Un indicador de foco claro y de alto contraste permite a un usuario con ampliación encontrar dónde está después de que la vista salte.
Sin pérdida de contenido ni función. Nada debe quedar recortado, superpuesto o inoperable cuando el texto se amplía hasta un 200 % (criterio de éxito 1.4.4).

La ampliación premia los diseños limpios y responsivos y penaliza los diseños de píxeles fijos y el contenido que depende del hover.

Acceso por conmutador y operabilidad por teclado

Los dispositivos de conmutador permiten a las personas operar un ordenador con una o dos entradas simples —un botón, un dispositivo de soplo y aspiración o un movimiento de cabeza— normalmente recorriendo los elementos interactivos de uno en uno. El acceso por conmutador se construye sobre la compatibilidad con el teclado: si tu sitio funciona por completo desde el teclado, casi con seguridad también funciona con conmutadores.

Eso convierte la plena operabilidad por teclado en una de las cosas de mayor impacto que puedes hacer bien:

Todo alcanzable. Todo elemento interactivo debe poder enfocarse y operarse sin ratón: enlaces, botones, controles de formulario, menús, modales, carruseles y widgets personalizados por igual.
Un orden de foco visible y lógico. El foco debe moverse por la página en un orden que coincida con el flujo visual y de lectura, y el elemento enfocado debe estar siempre claramente indicado.
Sin trampas de teclado. Los usuarios deben poder mover el foco fuera de cualquier componente, incluidos medios incrustados y diálogos.
Enlaces de salto. Un enlace «saltar al contenido principal» permite a las personas omitir la navegación repetida en lugar de recorrerla en cada página.

Si un cliente está rellenando un formulario, ¿puede tabular por cada campo, abrir un desplegable, elegir un producto y enviar, todo sin tocar el ratón? ¿Cooperará el autocompletado del navegador con tu marcado? Estas son las preguntas que los usuarios de conmutador y teclado responden sobre tu sitio, las hagas tú o no.

Control por voz: los nombres y las etiquetas visibles importan

Las herramientas de control por voz como Dragon, Voice Control y Voice Access permiten a los usuarios decir comandos como «pulsar Enviar» o «desplázate hacia abajo». Para que estos comandos funcionen, la etiqueta visible de un control debe coincidir con su nombre accesible. Esta es la base del criterio de éxito 2.5.3 de WCAG 2.2, Etiqueta en el nombre.

Orientación práctica:

El nombre accesible debe contener el texto visible. Si un botón dice «Enviar mensaje», no le pongas un aria-label de «Enviar formulario»: el usuario que diga «pulsar Enviar mensaje» será ignorado.
Evita los controles solo con icono sin texto, o dales un nombre accesible que coincida con un comando hablado probable.
Mantén los objetivos clicables lo bastante grandes para seleccionarlos de forma fiable, lo que también satisface el criterio de tamaño del objetivo de WCAG 2.2.

Funciones de accesibilidad del navegador y del sistema operativo

No todas las herramientas adaptativas son productos separados. Los navegadores y sistemas operativos modernos incorporan potentes funciones integradas que los usuarios activan a nivel de sistema, y tu sitio debería respetarlas automáticamente:

Movimiento reducido. Respeta la media query prefers-reduced-motion para desactivar o suavizar las animaciones para usuarios que sufren náuseas o distracción con el movimiento.
Modo oscuro y alto contraste. Admite prefers-color-scheme y el Alto Contraste / Colores Forzados de Windows para que tu interfaz siga siendo legible sin que tengas que pelearte con la configuración del usuario.
Redimensionado de texto y zoom. Usa unidades relativas para que funcione el escalado de texto del navegador, en lugar de fijar tamaños en píxeles.
Modos de lectura y herramientas de lectura. Las vistas de lectura del navegador y herramientas como Immersive Reader reducen una página a su contenido esencial, lo que funciona mucho mejor cuando tu HTML es semántico y está libre de desorden.

Estas funciones no cuestan nada extra al usuario y muy poco para ti, pero mejoran drásticamente la comodidad de un público amplio, incluidas personas sin discapacidades diagnosticadas.

Herramientas de lectura y comprensión

Las herramientas de lectura sirven a personas con dislexia, TDAH, discapacidades cognitivas o alfabetización limitada en el idioma de la página. Incluyen narradores de texto a voz, reglas de lectura, resaltado de palabras, resumidores y herramientas de traducción.

Para que funcionen bien con ellas:

Escribe en un lenguaje sencillo y bien organizado, con encabezados descriptivos y párrafos breves.
Marca la página de modo que el contenido principal sea claramente identificable y el orden de lectura sea correcto.
Evita transmitir significado solo mediante color, disposición o imágenes: proporciona un equivalente textual.
Asegúrate de que el idioma esté declarado (atributo lang) para que la narración y la traducción usen la pronunciación y las reglas correctas.

Una buena estructura de contenido ayuda a la vez a todas las herramientas de este artículo, porque todas se nutren del mismo marcado subyacente.

Tecnología de apoyo genuina frente a overlays de accesibilidad

Esta es la distinción que más importa, y es donde muchas organizaciones se equivocan.

La tecnología de apoyo genuina —lectores de pantalla, ampliadores, acceso por conmutador, control por voz— se ejecuta en el dispositivo del usuario, bajo su control, y opera tu sitio web a través de su semántica y su compatibilidad con el teclado. El usuario ha pasado años configurándola. Tu trabajo es simplemente construir una página que estas herramientas puedan entender.

Los overlays de accesibilidad son scripts de terceros que añades a tu propio sitio y que prometen «hacerlo accesible» automáticamente, normalmente mediante un widget flotante. No son un sustituto de la tecnología de apoyo, ni una solución para un sitio inaccesible. He aquí por qué:

No pueden reparar el código subyacente. Los overlays se sitúan encima de la página; no pueden inventar de forma fiable el texto alternativo que falta, arreglar estructuras de encabezados rotas ni hacer que un <div> se comporte como un botón real en todos los lectores de pantalla.
A menudo entran en conflicto con la AT real. Muchos usuarios de lectores de pantalla informan de que los overlays interfieren con las herramientas en las que ya confían, haciendo a veces los sitios más difíciles de usar, no más fáciles.
Crean una falsa sensación de cumplimiento. Instalar un widget no satisface WCAG 2.2, la EAA ni la ADA. Se han presentado demandas contra sitios que usan overlays precisamente porque las barreras subyacentes seguían presentes.
No reflejan la experiencia vivida. La accesibilidad la juzgan en última instancia las personas que usan AT cada día, por lo que realizamos auditorías por personas con discapacidad en lugar de fiarnos de las afirmaciones de un script.

El camino fiable es corregir la accesibilidad en el código y validarla con pruebas tanto automatizadas como humanas. Explicamos esta filosofía con más detalle en qué significa la verdadera accesibilidad digital.

Un flujo de trabajo práctico para construir con herramientas adaptativas

Construir para la tecnología de apoyo no es un proyecto puntual; es un proceso que encaja en cómo ya entregas software. Un enfoque sostenible suele combinar cuatro cosas:

Escaneo automatizado, pronto y a menudo. Herramientas como el software de escaneo de accesibilidad detectan un gran volumen de problemas a nivel de código —etiquetas que faltan, fallos de contraste, ARIA roto— antes de que lleguen a producción. Las comprobaciones automatizadas son rápidas y repetibles, pero solo cubren parte del panorama.
Pruebas manuales y con tecnología de apoyo. Los problemas que más afectan a los usuarios reales —orden de foco confuso, anuncios poco claros, widgets personalizados inutilizables— requieren a una persona. Nuestra guía de auditorías manuales de accesibilidad describe cómo esto complementa a la automatización.
Integrar la accesibilidad en tu equipo. Tratar la accesibilidad como una disciplina continua, respaldada por la mejora del proceso de accesibilidad, evita la lenta regresión que ocurre cuando las correcciones son cosas aisladas.
Las herramientas adecuadas para tu stack. El kit de herramientas de accesibilidad de QualiBooth reúne escaneo, monitorización e informes, mientras que Agora y nuestra community edition ofrecen puntos de entrada para equipos en distintas etapas de madurez.

Si la terminología de este artículo te resulta nueva, el glosario de accesibilidad es un buen compañero mientras pones en práctica estas pautas.

Dónde encaja QualiBooth

QualiBooth identifica los problemas de tu sitio web existente y también puede escanear páginas antes de que se publiquen, de modo que los clientes que usen cualquier herramienta adaptativa obtengan una experiencia fluida que aumenta la usabilidad y la fidelidad a la marca. Combinamos la detección automatizada con la evaluación de testers experimentados y personas con discapacidad, y luego ayudamos a tu equipo a convertir los hallazgos en correcciones duraderas, nunca un overlay que enmascare el problema.

El objetivo es sencillo: un sitio web que funcione con las herramientas en las que tus usuarios ya confían, en sus términos, cada vez que lo visitan.

¿Listo para ver cómo funciona tu sitio con tecnología de apoyo real? Ejecuta un escaneo de accesibilidad gratuito para detectar mejoras rápidas, solicita una demo para ver QualiBooth en acción o habla con nuestro equipo sobre un proyecto de consultoría de accesibilidad a medida.