Soporte de accesibilidad y criterio del auditor: ¿fallo del sitio o del lector?

Una misma página probada con cuatro combinaciones de navegador y lector produce cuatro salidas distintas. Parte de esas diferencias son fallos del sitio; otras, formas legítimas de cada lector de presentar la información; otras, defectos del navegador o del lector; y algunas, errores de configuración del propio auditor. Separarlas bien es lo que da credibilidad a un informe: reportar como fallo una pista de verbosidad desacredita al auditor, y descartar como «cosa del lector» un control inoperable deja a personas usuarias sin servicio. En la lección anterior aprendiste a localizar la capa del problema; en esta aprenderás a decidir qué hacer con él.

Qué significa «compatible con la accesibilidad»

Como viste en el curso de metodología WCAG-EM (se abre en una ventana nueva), el cuarto requisito de conformidad de las WCAG establece que, para cumplir los criterios, solo puede confiarse en formas de uso de las tecnologías que sean compatibles con la accesibilidad (accessibility supported): deben funcionar con las tecnologías de apoyo de las personas usuarias y con los navegadores disponibles. Las WCAG no dicen qué lectores ni cuántos; eso lo concreta la línea base de cada auditoría, que se fija y documenta antes de empezar.

De ahí salen dos consecuencias prácticas para la revisión manual:

• Un código válido según la especificación, pero que no funciona en las combinaciones de la línea base, no sirve para cumplir. No basta con que «el atributo exista en ARIA».
• Un defecto que solo aparece con un lector o navegador que no está en la línea base no convierte el sitio en no conforme, aunque puede merecer una observación si afecta a personas usuarias reales.

Cuatro tipos de resultado

1. Fallo del sitio. Falta información en el árbol (nombre, rol, estado, relación) o el control no se puede operar. Suele reproducirse en todas las combinaciones y el código lo demuestra. Veredicto: no cumple, con el criterio correspondiente.
2. Uso no compatible. El código usa una técnica que la línea base no soporta de forma fiable. Ejemplo típico: un aria-label sobre un span o div sin rol. WAI-ARIA 1.2 (se abre en una ventana nueva) prohíbe dar nombre a los elementos genéricos y los lectores lo tratan de forma desigual. Veredicto: no cumple, con recomendación de una técnica soportada.
3. Diferencia de presentación. La información llega, pero con otras palabras, otro orden u otra verbosidad. Veredicto: no es un fallo y no se registra como hallazgo.
4. Defecto del navegador o del lector con un código correcto y una técnica ampliamente soportada. Si en una combinación de la línea base impide o dificulta seriamente la tarea, se registra el hallazgo indicando la combinación y la causa, con una recomendación de mitigación si existe; si es una molestia menor, como un anuncio duplicado, se anota como observación.

Diferencias legítimas que no son fallos

Cada lector añade información propia que no procede del sitio. Conviene reconocerla para no confundirla con contenido de la página:

• NVDA puede decir «clicable» cuando un elemento tiene un manejador de clic. Es una pista útil (a menudo delata un div que debería ser un botón o un enlace), pero la palabra en sí no es un fallo: investiga si el elemento es operable con teclado y tiene rol.
• JAWS indica «en la misma página» en los enlaces a anclas y VoiceOver puede decir «visitado».
• TalkBack y VoiceOver añaden indicaciones de uso, como «toca dos veces para activar», que dependen de sus ajustes de verbosidad.
• El orden de nombre, rol y estado, la forma de anunciar la posición («2 de 4») y la agrupación de un enlace con imagen varían entre lectores.
• Con niveles bajos de puntuación, algunos signos no se verbalizan; antes de reportar que «falta» un signo, comprueba el nivel configurado.

<!-- No compatible: nombre en un elemento genérico -->
<span aria-label="4 de 5 estrellas">★★★★☆</span>

<!-- Compatible: rol de imagen con nombre -->
<span role="img" aria-label="4 de 5 estrellas">★★★★☆</span>

Antes de culpar al sitio, revisa tu equipo

Una parte de los «hallazgos» que se descartan en la revisión de calidad de un informe nacen en el puesto de pruebas. Comprueba estas causas antes de registrar nada:

• Ajustes de teclado del navegador: Safari y Firefox en macOS no detienen Tab en los enlaces sin la configuración que viste en la lección de teclado.
• Modo del lector: si NVDA está en modo formulario cuando debería estar en modo navegación, las letras de navegación rápida se escriben en la página y parece que «no funcionan».
• Idioma de la voz: si el lector no tiene instalada la voz del idioma marcado con lang, o tiene desactivado el cambio automático de idioma, no cambiará de voz aunque el código sea correcto.
• Versiones: navegadores o lectores desactualizados producen fallos ya corregidos; anota siempre las versiones.
• Extensiones: gestores de contraseñas, bloqueadores y capas de accesibilidad (overlays) inyectan elementos y alteran el árbol. Audita con un perfil de navegador limpio.
• Perfiles de verbosidad personalizados: parte de los ajustes por defecto para que tus resultados sean comparables con los de otro evaluador.

Cómo decidir: preguntas en orden

1. ¿Se reproduce con configuración por defecto, versiones actualizadas y perfil limpio? Si no, es un problema del puesto de pruebas.
2. ¿Falta la información o la operación en el árbol de accesibilidad? Si falta, es un fallo del sitio.
3. ¿La técnica utilizada funciona en las combinaciones de la línea base? Si no, es un uso no compatible: no cumple.
4. ¿Impide o dificulta seriamente la tarea en alguna combinación de la línea base? Si es así, registra el hallazgo indicando la combinación y la causa; si no, es una diferencia de presentación o una observación.
5. Documenta también lo descartado. Una línea basta: «Descartado: anuncio duplicado del mensaje de estado en TalkBack; código correcto; observación». Así quien revise el informe sabe que se consideró.

Cuando, tras estas preguntas, no puedas determinar el resultado con seguridad, usa el veredicto «no se puede determinar» del protocolo, explica qué falta para decidir y planifica una prueba adicional. Si identificas un defecto de un navegador o de un lector, conviene comunicarlo a su fabricante por sus canales públicos de incidencias y anotarlo en el informe, sin sustituir con ello el veredicto sobre el sitio.

Resumen

• El requisito de conformidad de usos compatibles con la accesibilidad obliga a que la técnica funcione en la línea base, no solo a que sea válida según la especificación.
• Clasifica cada resultado como fallo del sitio, uso no compatible, diferencia de presentación o defecto del navegador o del lector.
• Las pistas propias de los lectores («clicable», «toca dos veces para activar») no son contenido del sitio, pero pueden señalar un fallo real que hay que investigar.
• Antes de registrar un hallazgo, descarta causas del puesto de pruebas: modo, idioma de la voz, versiones, extensiones y ajustes de teclado.
• Decide con preguntas en orden y documenta también lo descartado y lo no determinable.