CAPTCHA: Análisis de su accesibilidad

Accesibilidad en el posicionamiento web

Animaciones accesibles en páginas web

Tablas de soporte de HTML en los lectores de pantalla

En Screen reader HTML support tables se pueden consultar tablas de soporte de HTML de los lectores de pantalla JAWS y NVDA.

Razones egoístas para desarrollar interfaces de usuario accesibles

En Selfish reasons for building accessible UIs:

• Debuggability
• Naming things
• Testability
• Power users

Focus priming

En Focus priming se explica algo que hacemos muchos de los que hacemos evaluaciones de sitios web. Cuando haces clic en algún lugar de una página web, puede parecer que no ocurra nada, pero en realidad estás determinando el punto de inicio del enfoque (focus) para la navegación con el teclado. Este detalle es importante al evaluar la accesibilidad.

¿Qué es el "focus priming"?

Es la acción de hacer clic en un punto específico de la página para establecer dónde comenzará el enfoque del teclado (por ejemplo, al presionar la tecla Tab). Aunque el enfoque inicial en la página no es visible (porque la página no es interactiva), existe y se puede modificar haciendo clic.

Ejemplos de cómo se mueve el enfoque:

• Al hacer clic en un campo de formulario o botón, el foco se mueve allí.
• Al hacer clic en un enlace, puede llevarte a otra parte de la página o del sitio.
• Al hacer clic en texto o imágenes no interactivas, simplemente se define un nuevo punto invisible de inicio del foco.

El término "focus priming" se refiere a esta técnica de establecer el foco antes de usar el teclado para realizar pruebas de accesibilidad.

Cómo la inteligencia artificial puede ayudar a las personas con discapacidad

 

Limitaciones de las herramientas automáticas de evaluación de la accesibilidad web

En Automated accessibility test tools find even less than expected se explica que, aunque muchas de las herramientas automáticas de evaluación de la accesibilidad web afirman cubrir entre el 30 % y el 50 % de los errores según WCAG, estudios y expertos como WebAIM, W3C, Karl Groves o Deque Systems confirman que esta cobertura es parcial y limitada.

El autor del artículo diseñó un conjunto de seis páginas HTML con 164 casos de prueba negativos (es decir, que deberían generar un error), centrados en el nombre accesible de los elementos interactivos (lo que lee un lector de pantalla cuando el foco llega a un botón, enlace, imagen, etc.).

El autor evaluó diferentes herramientas (gratuitas y comerciales) para ver cuántos errores detectaban, sobre elementos como <button>, <a>, <img>, <iframe>, formularios y elementos con roles ARIA.

Los resultados fueron:

• Ninguna herramienta superó el 40 % de cobertura, y muchas puntuaron por debajo.
• Algunas no reconocen elementos con role="button" u otros roles ARIA.
• Se observó gran variabilidad en el rendimiento dependiendo del tipo de contenido.
• No se evaluó el impacto del error (ej. falta de nombre en un botón de envío vs. en una imagen decorativa).

La conclusión del autor es que deberíamos matizar las cifras habituales de cobertura de herramientas automatizadas: cubren entre el 30 % y el 50 % de los problemas más comunes y fácilmente detectables, pero no todos. Además, el caso del nombre accesible indica que la cobertura real en casos prácticos puede ser incluso menor.