«¿Por qué se presenta una demanda? Una guía práctica sobre los patrones de interfaz de usuario que subyacen a 6.666 reclamaciones por accesibilidad»

El encabezado es la primera superficie interactiva de cada página, y el botón de menú desplegable suele ser lo primero a lo que accede un usuario que navega con el teclado. Cuando ese botón se muestra como un <div> si incluye una imagen de fondo CSS, carece de un nombre accesible o despliega un menú que retiene el foco o no indica si está abierto o cerrado, todo el sitio web se vuelve estructuralmente inoperativo desde el teclado antes de que el usuario haya accedido a ningún contenido real.

El enlace de salto es el fallo asociado. Uno que funciona "Skip to main content" El enlace de salto es una solución de cinco líneas, pero también es el indicador más eficaz para saber si un equipo de desarrollo tiene la accesibilidad incluida en su lista de comprobación. Las quejas suelen mencionar ambos aspectos en el mismo párrafo, ya que la ausencia o el mal funcionamiento de un enlace de salto es una señal de alarma: si el equipo no ha implementado un enlace de salto, es casi seguro que tampoco haya implementado los estados «aria-expanded».

Representa el activador del menú como un elemento real <button> con una etiqueta de texto visible o solo para lectores de pantalla y un elemento gestionado aria-expanded atributo. Indique un "Skip to main content" enlace que se vuelve visible al pasar el cursor por encima y que aparece dentro del <main> punto de referencia. Asegúrate de que el foco se desplace al menú al abrirse, vuelva al elemento activador al cerrarse y de que Esc cierra el menú.

En la mayoría de los sitios web de gran tamaño, la función de búsqueda se ha rediseñado como un componente personalizado: un campo de texto con supresión de repeticiones que envía una solicitud con cada pulsación de tecla y muestra una lista flotante de sugerencias dentro de un elemento con posición absoluta <div>. El campo de entrada de texto en sí suele funcionar bien. La lista de sugerencias, en cambio, casi nunca. Se muestra fuera del contexto DOM del campo de entrada, no tiene role="listbox", no aria-activedescendant, y no se muestra ningún aviso de «región activa» cuando aparecen los resultados. Un usuario de un lector de pantalla escribe, no oye nada, pulsa Intro y obtiene una página de resultados que no sabía que estaba ahí esperándole.

El mismo patrón arquitectónico se repite en los paneles de filtrado de la búsqueda por facetas y en la propia lista de resultados: elementos en los que se puede colocar el foco del teclado, que están presentes visualmente pero que nunca se anuncian. Las quejas sobre la búsqueda rara vez se refieren al cuadro de búsqueda; se refieren a todo lo que aparece después de que el usuario escribe.

Utiliza el patrón de cuadro combinado WAI-ARIA establecido: role="combobox" en la entrada con aria-expanded, aria-controls, y aria-activedescendant conectado a un role="listbox" de sugerencias. Añade un área interactiva que muestre el recuento de resultados. Asegúrate de que se pueda acceder a la lista de sugerencias con la tecla de flecha hacia abajo, y no solo con el ratón.

La cuadrícula PLP concentra varios antipatrones en una sola pantalla. Cada mosaico suele ser una ficha en la que se puede hacer clic y que contiene tres o cuatro elementos secundarios interactivos —enlace a una imagen, enlace al título, muestras de color, botón de «Añadir rápidamente»— envueltos en otro enlace a la página del producto. El resultado son elementos interactivos anidados (un error de HTML), texto de enlace redundante («Enlace a imagen Hero Dash Three» que se repite cuatro veces) y muestras de color creadas a partir de <div> elementos con controladores de clic, pero sin función ni nombre.

La barra lateral de filtros añade una segunda categoría de error. Las facetas de filtro suelen ser listas de casillas de selección, pero están creadas con elementos «div» y «span» personalizados, a los que se les ha aplicado un estilo para que parezcan casillas de selección, mientras que el <input> oculto fuera de la pantalla. Cuando ese campo oculto pierde su asociación —ya sea por una regla CSS, un controlador de eventos de JavaScript que ignora las pulsaciones de la tecla de espacio o la ausencia de for atributo en la etiqueta visible: el filtro solo se puede manejar con el ratón.

Utiliza un enlace por cada ficha con texto descriptivo, en lugar de tres enlaces por producto. Muestra las muestras tal y como son en realidad. <button> elementos dentro de un role="radiogroup". Crear facetas de filtro en el <input type="checkbox"> elementos con <label> Etiquetas: aplica un estilo visible a los campos de entrada en lugar de ocultarlos. Indica los cambios en el filtro mediante una zona activa discreta.

La página de detalles del producto es donde un usuario de un lector de pantalla debe realizar varias selecciones específicas en el orden correcto: elegir un color, elegir una talla, indicar la cantidad y, a continuación, añadir el artículo al carrito. Cada una de esas selecciones se implementa en el comercio electrónico moderno como un widget personalizado —normalmente una fila horizontal de <button>en forma de <div>En cuanto a los tamaños, los mosaicos de colores creados a partir de elementos `div` con estilos CSS y un control numérico formado por dos botones con iconos que flanquean un campo de entrada. Los botones de aumento y disminución suelen incluirse sin un nombre accesible; las quejas los describen como anunciado como «botón, botón» sin que se indique a qué se dedican.

Las guías y tablas de tallas constituyen un problema aparte: casi siempre se encuentran tras un enlace «Tabla de tallas» que abre una ventana modal, y el enlace en sí suele carecer de etiqueta, la ventana modal suele carecer de título visible y la tabla que contiene suele carecer de encabezados de filas o columnas.

Utiliza controles de formulario reales. Las muestras de color y los selectores de tamaño deben ser un role="radiogroup" de role="radio" botones (o controles de radio con un estilo que los haga invisibles), cada uno con un nombre accesible como «Talla: mediana». El control deslizante de cantidad debe ser un campo de número etiquetado con botones de incremento y decremento emparejados, cuyos nombres accesibles incluyan la acción y la cantidad actual. Encuadre todo el bloque de selección en un «fieldset» con una leyenda.

El botón «Añadir al carrito» es el momento más probado en cualquier embudo de comercio electrónico y uno de los que presenta fallos con mayor frecuencia para los usuarios de tecnologías de apoyo. El patrón es mecánico: un visitante pulsa el botón, aparece una pequeña ventana emergente de confirmación o un cajón con el minicarrito durante dos o tres segundos, y el icono del carrito actualiza el contador en el encabezado. Los usuarios videntes ven las tres señales. Los usuarios de lectores de pantalla, por lo general, no reciben ninguna. La ventana emergente se muestra fuera de cualquier área activa, el cajón aparece sin gestión del foco y el cambio en el recuento del carrito se transmite como una simple mutación del DOM que ningún lector de pantalla anunciará.

El resultado es un botón que, desde el punto de vista del usuario, no hace nada. Lo pulsan, no oyen nada, dan por hecho que no ha funcionado y vuelven a pulsarlo. Algunas quejas mencionan que se pulsó el botón cinco o seis veces antes de darse cuenta de que el carrito había acumulado, sin que se notara, cinco o seis artículos.

Envuelve la sección «cart-status» en aria-live="polite" y actualiza su texto cada vez que se añada un artículo correctamente. Si el diseño utiliza un panel de confirmación, desplaza el foco al panel cuando se abra y devuélvelo al botón original cuando se cierre. Actualiza la insignia del recuento del carrito con un mensaje destinado exclusivamente a lectores de pantalla, como «Se ha añadido 1 artículo. Total del carrito: 3 artículos».

Los controles que solo contienen iconos fallan de una forma previsible: el contenido visible es un glifo SVG o de fuente de iconos, el contenido accesible está vacío y la lectura del lector de pantalla se reduce al rol estructural del elemento sin nombre. El icono del carrito acaba anunciándose como «enlace» o «colapsado»; el globo de chat como «botón»; la fila de iconos sociales del pie de página como «enlace, enlace, enlace, enlace, enlace». El usuario no tiene forma de saber para qué sirve ninguno de ellos.

Los iconos de carrito fallan con más frecuencia que otros iconos por una razón de diseño: en muchas implementaciones, el número de artículos del carrito se incluye dentro del nombre accesible del icono (por ejemplo, el icono muestra un «0» dentro del SVG), y el lector de pantalla solo detecta el dígito. Las quejas señalan que el icono del carrito se anuncia como «3, enlace» o «0, enlace», sin indicar que el «3» se refiere a la cantidad de artículos en el carrito de la compra.

Todos los controles que solo contienen iconos deben tener un nombre accesible. Añade un aria-label en el botón o incluir una etiqueta de texto oculta visualmente en su interior: "Shopping cart, 3 items". Evita incluir dígitos numéricos en el nombre accesible del icono sin contexto. En el caso de los iconos decorativos que aparecen junto a texto visible, utiliza aria-hidden="true" en el icono y deja que el texto sirva de etiqueta.

La página de pago concentra más riesgos de incumplimiento normativo por píxel cuadrado que cualquier otra página de un sitio de comercio electrónico, y los fallos son muy frecuentes. Los menús desplegables de direcciones se muestran como elementos personalizados <div> componentes que ignoran la tecla de espacio. Los indicadores de campos obligatorios se muestran únicamente como un asterisco rojo, sin aria-required y sin asociación programática. Los mensajes de error se muestran en línea, en texto rojo, debajo del campo, sin aria-describedby se vincula el campo al error y no se muestra ningún mensaje en la zona activa cuando falla la validación. El usuario rellena el formulario, pulsa «Continuar», es redirigido sin previo aviso y no tiene forma de saber qué campos han fallado ni por qué.

En cientos de casos se repite el mismo tipo de queja: no se anuncian los mensajes de error, los mensajes de error son imprecisos, no se puede introducir la información de facturación. No se trata de errores aislados, sino del comportamiento predeterminado de la mayoría de los componentes de pago de las tiendas online que se comercializan sin haber sido adaptados explícitamente para la accesibilidad.

Utiliza datos reales <label> elementos asociados a las entradas mediante for/id. Marca los campos obligatorios con aria-required="true" e indica el requisito con texto visible, no solo con el color. Si falla la validación, muestra el mensaje de error dentro del campo de entrada aria-describedby destino, indica el campo con error aria-invalid="true", y desplaza el foco del teclado al primer campo con un valor no válido. Incluye un área de resumen de errores en la parte superior del formulario con enlaces a cada uno de los campos con errores.

El bloque de pago es atípico porque suele mostrarse mediante un iframe integrado de un tercero —Stripe Elements, Braintree Hosted Fields o un complemento de Adyen—. Dentro del iframe, el formulario del proveedor de pagos suele estar bien etiquetado. Pero en el momento en que un sitio web crea su propio formulario de captura de datos de tarjeta, o envuelve los campos incrustados en un diseño personalizado que sustituye las etiquetas por marcadores de posición visuales, los cuatro campos —número, fecha de caducidad, CVV y código postal— se convierten en una fila de campos en blanco para un lector de pantalla.

El campo del CVV es el que con mayor frecuencia se etiqueta de forma incorrecta, ya que los diseñadores suelen sustituir su etiqueta por un icono de interrogación que abre una ventana emergente en la que se explica qué es el CVV. La ventana emergente no es la etiqueta; el campo sigue necesitando un nombre programático. Cuando no lo tiene, el lector de pantalla anuncia todo el bloque de pago como «editar, editar, editar, editar» y la transacción se detiene.

Si utilizas una integración de campos alojados de terceros, sigue las directrices de accesibilidad del proveedor; la mayoría ofrece una forma documentada de etiquetar los campos desde fuera del iframe. Si estás creando un formulario de captura de tarjetas personalizado, cada campo de entrada debe tener un <label> elemento con una etiqueta de texto visible, además de autocomplete="cc-number" / cc-exp" / cc-csc" atributos para que los gestores de contraseñas y las tecnologías de apoyo puedan identificar los campos según su finalidad.

La página del carrito repite el fallo del control deslizante de cantidad de la página de detalle del producto, pero con mayores consecuencias: un usuario de lector de pantalla que no pueda manejar el control deslizante no podrá completar el pedido. El control «Eliminar» es en sí mismo un antipatrón: suele ser un pequeño icono en forma de «×» situado junto a cada artículo, a menudo sin texto visible, sin aria-label, y no se emite ningún aviso cuando se elimina la fila. El usuario pulsa lo que cree que es el botón de eliminar, la fila desaparece y el lector de pantalla no dice nada. No hay forma de confirmar que la acción se haya realizado correctamente.

Varias quejas señalan un problema similar: el total acumulado del carrito se actualiza dinámicamente cuando cambian las cantidades o se eliminan artículos, pero el nuevo total se muestra como texto DOM normal fuera de cualquier área interactiva, por lo que el usuario no tiene ni idea de cuánto se le va a cobrar.

Cada partida debe incluir un botón de eliminación con su correspondiente etiqueta (por ejemplo, "Remove Blue T-Shirt, size M, from cart"). Los controles de selección de cantidad deben indicar su valor actual como parte del nombre accesible o mediante actualizaciones de la zona interactiva asociada. El subtotal del carrito debe aparecer dentro de un aria-live="polite" región, por lo que se anuncian los cambios. Confirma las eliminaciones mediante una opción para deshacer.

Esta es la categoría más numerosa del conjunto de datos, ya que es el problema más barato de detectar y el más costoso de ignorar. Un lector de pantalla recorre el DOM, encuentra un <input>, y lee su nombre accesible —que calcula a partir de, en este orden: aria-labelledby, aria-label, una filial <label for>, el title atributo o el marcador de posición. Si no existe ninguno de ellos, el lector de pantalla solo anuncia la función: «cuadro de edición» o «edición, en blanco». Esa frase, casi textualmente, aparece repetidamente en cientos de registros de reclamaciones.

La razón por la que es tan habitual es de carácter estructural. Los sistemas de diseño modernos suelen mostrar texto de marcador de posición dentro del campo de entrada como sustituto de la etiqueta visible, y los desarrolladores dan por sentado que el marcador de posición cumple la función de etiquetado. Pero no es así. El marcador de posición desaparece cuando el usuario escribe, no deja ningún nombre programático y hace que el campo resulte inutilizable para cualquiera que llegue a él más adelante en el flujo o vuelva a él tras un error.

Cada control interactivo cuenta con una etiqueta visible, asociada mediante programación. <label for="email">Email</label><input id="email" type="email"> es el patrón canónico. Los marcadores de posición son indicaciones complementarias, no sustitutos. En los controles en los que realmente no sea conveniente que la etiqueta sea visible (campos de búsqueda, botones con iconos), utiliza aria-label con un texto descriptivo — nunca con el marcador de posición duplicado.

La frase «no se anuncia ni se le da el foco» aparece textualmente en más de 400 entradas de quejas y es una de las frases más repetidas de todo el conjunto de datos. Describe un fallo concreto: aparece un modal o un cuadro de diálogo en la página (a menudo de forma automática —suscripción al boletín, verificación de edad, confirmación de ubicación—), el contenido visible cambia, pero el lector de pantalla no recibe ninguna señal de que haya ocurrido algún cambio. El foco permanece en la página subyacente. El usuario sigue desplazándose con la tecla Tab por lo que había debajo del modal, sin darse cuenta en absoluto de que ha aparecido un cuadro de diálogo que bloquea la pantalla.

Este es el típico ejemplo de un modal que falla en todos los aspectos a la vez: no role="dialog", no aria-modal="true", no se produce un cambio programático de enfoque al abrir la ventana, no se produce una «trampa de enfoque» mientras está abierta, no se produce el comportamiento de cierre con la tecla Esc y no se muestra el título. Dado que todos estos fallos van de la mano, solucionar cualquiera de ellos de forma aislada no supone ningún avance en la resolución del problema.

Utiliza un patrón de diálogo establecido (la especificación «WAI-ARIA Authoring Practices» es la referencia). Al abrirlo: desplaza el foco al primer elemento seleccionable dentro del diálogo, establece aria-modal="true" y role="dialog", asigna un nombre al cuadro de diálogo con aria-labelledby señalando su título. Mientras esté abierto: mantén el foco dentro del cuadro de diálogo. Al cerrarlo: devuelve el foco al elemento que lo activó. Respeta la tecla Esc. Si el cuadro modal interrumpe un flujo (por ejemplo, la reproducción automática al cargar la página), ofrece al usuario un único mecanismo para cerrarlo de forma permanente.

Los indicadores de enfoque suelen desactivarse deliberadamente por parte de un desarrollador o diseñador que consideraba que el contorno predeterminado del navegador era un elemento de distracción visual y escribió *:focus { outline: none; } en una hoja de estilo global. Ahora, la página tiene un aspecto más limpio para un usuario vidente que utiliza el ratón. Sin embargo, para un usuario vidente que utiliza el teclado —incluidos la mayoría de los usuarios con baja visión, los usuarios con discapacidad motora y los usuarios que navegan sin ratón—, la página se vuelve inutilizable. El usuario puede pulsar la tecla Tab, pero no puede ver dónde se encuentra.

Este es uno de los pocos fallos que se pueden detectar sin necesidad de tecnología de apoyo. Un revisor de control de calidad que recorra la página de inicio una vez con el teclado, sin utilizar ninguna otra herramienta, lo detectará en menos de un minuto. El hecho de que los equipos de accesibilidad lo encuentren sistemáticamente en sitios web objeto de litigio, mientras que las revisiones internas lo pasan por alto, es una de las señales más fiables del conjunto de datos de que el sitio no ha superado en absoluto las pruebas de accesibilidad con teclado.

Nunca desactives todo de forma generalizada :focus contornos sin sustituto. Establece un estilo de foco visible —normalmente un contorno de 2-3 píxeles con suficiente contraste tanto con respecto al elemento como a su fondo— utilizando :focus-visible por lo que el indicador aparece al navegar con el teclado, pero no al hacer clic con el ratón. Compruébalo en todos los componentes interactivos, incluidos los widgets personalizados, los enlaces dentro de las tarjetas y los elementos con tabindex.

El logotipo es la imagen más visitada de un sitio web y una de las que más a menudo no se carga correctamente. Normalmente se encuentra en un enlace que redirige a la página de inicio, pero la imagen se carga sin alt, no aria-label en el enlace, sin texto a su alrededor. El lector de pantalla solo lee «enlace», sin ninguna indicación de adónde lleva. Multiplica eso por cada página del sitio.

La categoría más amplia —imágenes sin texto alternativo— abarca los banners, las fotos de productos, las ilustraciones destacadas, los iconos de redes sociales y el amplio catálogo de imágenes de marketing que suele ofrecer un sitio web de comercio electrónico típico. Las reclamaciones en esta categoría suelen citar nombres de archivo de imágenes concretos, lo que indica que el perito del demandante realizó una comprobación automática que enumeró todas las imágenes cuya alt El atributo faltaba o estaba vacío, cuando debería haber sido descriptivo.

Los logotipos deben incluir un texto alternativo que describa el nombre de la empresa y, si el logotipo enlaza a alguna página, el destino — alt="Acme Co. — homepage". Las imágenes decorativas tienen el atributo «alt» vacío (alt=""), lo que las oculta deliberadamente a las tecnologías de apoyo. Las imágenes informativas deben incluir un texto alternativo descriptivo. Evita generar automáticamente el texto alternativo a partir de los nombres de archivo o mediante subtítulos generados por IA sin revisión humana; los registros de reclamaciones citan repetidamente casos en los que las herramientas de superposición describían el logotipo de una empresa como «un letrero azul y amarillo».

Los lectores de pantalla muestran una vista de «lista de enlaces», muy utilizada por los usuarios experimentados para examinar una página en cuestión de segundos. Esa vista muestra únicamente el texto del enlace, separado del párrafo que lo rodea. Una página en la que cada resumen de entrada del blog termina en «Leer más» se muestra en esa vista como quince entradas idénticas. Una página con cinco enlaces vacíos — <a href="..."></a>, algo habitual cuando los iconos se encuentran dentro de etiquetas de enlace sin texto alternativo, muestra cinco espacios en blanco.

La solución es bien conocida, al igual que el error, y por eso este patrón sigue apareciendo en las quejas: su persistencia pone de manifiesto un proceso de desarrollo que carece de un linter automatizado para el texto de los enlaces y de una revisión manual con un lector de pantalla.

Cada enlace debe tener un nombre accesible que describa su destino o la acción que realiza. Sustituye las expresiones genéricas por otras descriptivas — «Leer más» se convierte en «Más información sobre los resultados del tercer trimestre». En el caso de los enlaces que solo contienen un icono, añade texto oculto visualmente o un aria-label. Ejecuta una comprobación automática (Axe, Lighthouse, etc.) para detectar elementos vacíos <a> elementos durante la CI.

Los vídeos aparecen en las quejas siguiendo dos patrones. El primero es el más evidente: un vídeo de marketing, una demostración de producto o un vídeo explicativo se publica sin subtítulos, transcripción ni ningún texto alternativo, por lo que un visitante sordo o con discapacidad auditiva no puede acceder al contenido. El segundo es más sutil: un vídeo destacado que se reproduce automáticamente al cargar la página, lo que interfiere con la salida del lector de pantalla e incumple los controles de pausa/parada exigidos en el nivel AA de las WCAG 2.2 (según el criterio de éxito 2.2.2 «Pausa, parada y ocultación» para contenido en movimiento y el criterio de éxito 1.4.2 para cualquier audio).

Algunas reclamaciones incluidas en este conjunto de datos afirman que «la falta de subtítulos en los vídeos del sitio web constituye una infracción de la ADA», lo cual se presenta como una conclusión jurídica. La validez de tal afirmación varía según la jurisdicción y las circunstancias; lo que resulta más indiscutible es que estos vídeos incumplen sistemáticamente las WCAG 2.2 AA, la norma que la mayoría de los tribunales y los acuerdos extrajudiciales consideran el criterio de cumplimiento de referencia.

Incluya subtítulos sincronizados en todos los vídeos pregrabados que contengan audio. Proporcione también una transcripción textual; las transcripciones resultan útiles para los usuarios que utilicen dispositivos con el audio silenciado, en entornos con poco ancho de banda y para la indexación. Evite la reproducción automática; si es necesaria por motivos de diseño, incluya un control de pausa/parada al que se pueda acceder directamente mediante el teclado. En el caso de contenidos que solo contengan vídeo (sin audio), proporcione una audiodescripción o un texto alternativo.

El inicio de sesión es la puerta de acceso a toda la experiencia de autenticación. Cuando el formulario falla, todas las páginas posteriores quedan inaccesibles, y las quejas suelen considerar esa cadena de fallos como un único obstáculo. El patrón es el mismo fallo de etiquetado de formularios que en E·01, a menudo combinado con tres subfallos específicos: un conmutador «Mostrar contraseña» implementado como un botón que solo contiene un icono, sin nombre y sin anuncio del cambio de estado; un CAPTCHA que impide por completo el uso de lectores de pantalla; y errores en línea («credenciales no válidas») que se muestran en pantalla pero no se anuncian.

La casilla «Recordarme» es un error secundario recurrente adicional: se muestra como un elemento con estilo <div>, con el <input> Al estar oculta fuera de la pantalla, la casilla de verificación se puede seleccionar con el ratón, pero no con el teclado ni con un lector de pantalla. El usuario no tiene forma de activar una sesión persistente.

Utiliza datos reales <input>, <label>, y <button> elementos. Haz que el conmutador para mostrar/ocultar la contraseña sea un botón real con un nombre accesible que se actualice según el estado ("Show password" / "Hide password") y anunciar el cambio con aria-pressed. Ofrecer una alternativa accesible a los CAPTCHA basados en imágenes (CAPTCHA de audio o, preferiblemente, sustituir el CAPTCHA por una autenticación basada en el riesgo o por las variantes accesibles de hCaptcha).

Los lectores de pantalla permiten recorrer la página a través de tres modos de navegación: por encabezados, por puntos de referencia y por enlaces. Una página que se publica sin un <h1>, sin <main>, <nav>, y <footer> lugares emblemáticos, y sin un lang="en" atributo en el <html> elemento, ha eliminado los tres modos de navegación a la vez. Los usuarios no pueden desplazarse por la página, no pueden saltar directamente al contenido y el lector de pantalla no puede cargar el motor de pronunciación adecuado.

Se trata de un fallo inusualmente grave: la ausencia de un único punto de referencia provoca una cascada de problemas posteriores, ya que todas las estrategias de navegación de los lectores de pantalla que dependen de él dejan de funcionar. Las quejas de esta categoría suelen enumerar cuatro o cinco problemas estructurales concretos, que se presentan como prueba de que el sitio carece de una base semántica.

Cada página tiene uno y solo uno <h1>, con subtítulos (<h2>, <h3>) anidados de forma lógica. Encuadra las regiones en elementos de referencia de HTML5: <header>, <nav>, <main>, <aside>, <footer>. Configurar lang en la raíz <html> elemento. Valídalo con un verificador de esquemas o ejecuta document.querySelectorAll('h1').length === 1 como prueba de funcionamiento en la integración continua.

La mayor parte del control de calidad de la accesibilidad se lleva a cabo en navegadores de escritorio con NVDA o JAWS. Las tecnologías de apoyo para dispositivos móviles —VoiceOver en iOS, TalkBack en Android— muestran una representación diferente del mismo DOM, a menudo con errores distintos. Las quejas utilizan repetidamente la abreviatura «usuario de lector de pantalla móvil» (mobile SRU ) para señalar fallos que son exclusivos de la vista móvil: un menú de hamburguesa que funciona con NVDA en el ordenador de sobremesa pero no responde con VoiceOver, un botón de Apple Pay al que se puede acceder en un portátil pero no en la versión para iPhone de la página, mensajes de error que se anuncian en el ordenador de sobremesa pero no en el móvil.

Los datos indican que los demandados, cuya accesibilidad en ordenadores de sobremesa es, por lo demás, sólida, siguen siendo objeto de demandas por cuestiones específicas de los dispositivos móviles. La paridad móvil es un requisito de auditoría en sí misma.

Realiza pruebas con VoiceOver en Safari para iOS y con TalkBack en Chrome para Android como mínimo, siguiendo los mismos flujos que se incluyen en el control de calidad para ordenadores de sobremesa. Presta especial atención a las interacciones basadas en gestos, a los botones de pago nativos y a la lectura de los campos de formulario cuando se seleccionan. Si existe una aplicación nativa, sométela a la misma auditoría; las quejas suelen abarcar tanto la web como la aplicación en el mismo caso.

La superposición de accesibilidad es el único ejemplo de este catálogo en el que el fallo no reside en absoluto en el sitio web subyacente, sino en la supuesta capa correctiva que se añadió para solucionarlo. Las quejas de esta categoría describen dos problemas distintos. El primero es que las superposiciones no eliminan realmente las barreras subyacentes, por lo que el usuario se encuentra con los mismos modales defectuosos, formularios mal etiquetados y errores sin previo aviso, independientemente de si el widget está presente o no. El segundo es más concreto: las superposiciones a veces introducen nuevos fallos al insertar etiquetas incorrectas, aplicar erróneamente roles ARIA o interferir con la propia configuración de tecnología de apoyo del usuario.

Un detalle que cabe destacar: en las reclamaciones de 2024 y 2025 se menciona cada vez más al proveedor de la superposición por su nombre. En dos pasajes concretos de las reclamaciones se identifica a UserWay y AccessiBe en términos inequívocos, y las recientes medidas de la FTC han creado un riesgo explícito de que la incorporación de una superposición constituya en sí misma una prueba de que no se han llevado a cabo medidas correctoras reales, en lugar de una defensa frente a un litigio.

Considera las capas superpuestas como una señal de alerta, no como una solución. Si actualmente tienes alguna implementada, elabora un plan de acción para una corrección real que aborde el código subyacente en lugar de ocultarlo. La vía más probada consiste en una combinación de: un escáner automatizado integrado en la integración continua (CI), una revisión manual conforme a las WCAG 2.2 AA, pruebas manuales con al menos un lector de pantalla y navegación solo con el teclado, y un control de calidad de la accesibilidad continuo en el proceso de diseño y desarrollo.