angularjs - prod - Accesibilidad en aplicaciones de una sola página(ARIA etc)

angularjs production

Question

¿Cuál es el mejor enfoque para hacer que un SPA (AngularJS) sea accesible (para lectores de pantalla, etc.)?

Tengo poca o ninguna experiencia con la especificación aria, y me pregunto si funcionará en una aplicación de una sola página.

¿Cuáles son las trampas comunes al desarrollarse?

¿Cómo se depura y prueba la accesibilidad cuando se desarrolla?

Answer 1

Esto podría abarcar una amplia gama de problemas aquí. Así que repasaré algunos de los conceptos básicos con la esperanza de que te ayude a seguir tu camino, las trampas comunes, por así decirlo.

En primer lugar, como dijeron los comentaristas, sí, debe asegurarse de que las etiquetas ARIA se empleen correctamente. Entonces, digamos, si quisieras exponer un div como un botón, tendrías algo como esto.

<div id="mysuperflashybutton" ... role="button" aria-label="Super flashy" tabindex="0"></div>

Este botón, cuando lo seleccione un lector de pantalla, se llamará "botón súper llamativo", por lo que no necesita poner el botón en su atributo de etiqueta aria. Hay ejemplos más complejos por ahí, pero eso ilustra los conceptos básicos de ello, bastante. Rol, aria-label y tabindex serán los atributos ARIA más prevalentes que vea.

Los elementos de indexación de pestañas en los que desea que los usuarios del lector de pantalla hagan clic son vitales para esto. Establezca tabindex en 0 para incluirlo en su ubicación predeterminada en el documento. Si no quiere que las personas que utilizan la navegación con el teclado necesariamente lo contacten, configúrelo en -1. Esto significa que está fuera del orden normal de pestañas, pero aún se puede navegar si desea poner el enfoque del usuario manualmente a través de javascript / jquery .focus ().

Como se mencionó, a veces puede ayudar a los navegadores de teclado / usuarios de lectores de pantalla moviendo su enfoque hacia ellos. Un ejemplo sería si hacen clic en un botón y aparece un menú. Puedes hacer algo como esto para ponerlos en el primer enlace del menú:

$(''#linkmenuactivator'').on("click", function () {
    $(''#linkmenu'').find(''li:first a'').focus();
});

Sé que está en JQuery, no estoy familiarizado con AngularJS, pero mi breve visión me hace pensar que es más un controlador ViewModel en lugar de un UI específico como JQuery, pero corríjame si me equivoco.

Las regiones en vivo se pueden usar si estás haciendo cosas extrañas en la pantalla que no tendrán sentido para un usuario lector de pantalla. Puede escribir texto en los elementos de estas regiones para distribuir la información de forma textual. La forma más fácil de hacer esto es usar un rol de alerta o estado, para mensajes importantes o actualizaciones de estado genéricas respectivamente. Estas funciones hacen que su elemento sea una región en vivo de forma predeterminada, y cualquier cambio de texto allí se informará al lector de pantalla. Así que un ejemplo rápido sería algo como esto:

<p id="ariastatusbox" ... role="status"></p>

Luego, más adelante en JQuery (tomando el ejemplo de que cargas un documento y lo desvaneces cuando lo tienes):

$(''#maincontent'').fadeIn(function () {
    $(''#ariastatusbox'').text(''Document loaded'');
});

Esto permitirá que el lector de pantalla sepa que el documento está cargado y listo para ser leído en la pantalla. Las regiones en vivo pueden ser un poco difíciles, pero son una bestia poderosa si puedes dominarlas.

Finalmente, en cuanto a las pruebas de accesibilidad, hay algunas opciones. Algo que encontré recientemente es Wave que parece ser una herramienta de prueba en línea. Se ve bien desde el primer vistazo, puedes intentarlo. Otra opción es agarrar un lector de pantalla y darle una oportunidad. Recomiendo NVDA que es un lector de pantalla de código abierto (por lo tanto, gratuito). Es mi lector de pantalla de elección y es bastante bueno. El sintetizador con el que viene incluido no tiene la mejor voz, pero hay otras opciones, o puede desactivar la salida de voz y ver una visualización textual de lo que estaría diciendo usando el Visor de voz. Una última opción es solicitar que los probadores de accesibilidad lleven su aplicación a una prueba de manejo. Para productos de consumo o cosas en esos soportes, las personas ciegas y otros usuarios de tecnología accesible pueden ofrecerse voluntariamente a hacerlo si se les solicita. Para obtener más aplicaciones orientadas a los negocios que no desee en un foro público, hay varias organizaciones que pueden consultar sobre temas relacionados con hacer que las aplicaciones web sean accesibles.

Este no es, de ninguna manera, un manual completo sobre accesibilidad. Esperaba realmente ponerlo en marcha en la dirección correcta. Para una mirada más profunda, intente buscar en la documentación de roles de ARIA (todo esto ayudará, pero el código se encuentra bajo el encabezado de definiciones), y de ahí en adelante la documentación de Estados y propiedades de ARIA . Ambos pueden estar un poco secos, pero también tienen la lista completa de todo lo que puedes usar con ARIA. Google debería poder dar algunos tutoriales, también, espero.

Espero que esto te ayude a comenzar. ¡Buena suerte!