Javascript y accesibilidad

https://stackoverflow.com/questions/266777

06-07-2019
|

Pregunta

Como desarrollador web, varios de los proyectos en los que trabajo caen bajo paraguas gubernamentales y, por lo tanto, están sujetos a 508 Accesibilidad leyes y, a veces, directrices de accesibilidad W3C . ¿En qué medida se puede utilizar JavaScript mientras se cumplen estos requisitos?

En este sentido, ¿en qué medida es JavaScript, específicamente AJAX y el uso de paquetes como jQuery para hacer cosas como mostrar cuadros de diálogo modales, ventanas emergentes, etc. compatibles con software de accesibilidad moderno como JAWS, Orca, etc.? En el pasado, la regla era algo así como "Si no funciona en Lynx, no funcionará para un lector de pantalla". ¿Sigue siendo cierto o ha habido más progreso en estas áreas?

EDITAR: El consenso parece ser que javascript está bien siempre que haya fallos no relacionados con javascript, sin embargo, todavía parece incierto sobre el soporte para AJAX en el software de lector de pantalla. Si alguien tiene experiencia específica con esto, sería de gran ayuda.

Solución

Si la accesibilidad es su principal preocupación, siempre inicie un sitio web utilizando HTML que cumpla con los estándares (elija una definición de tipo de documento y cúmplala). Si se trata de una aplicación web (envíos de formularios, etc.), asegúrese de que los formularios funcionen utilizando solo HTTP GET y POST. Una vez que tenga un sitio web / aplicación completo, puede agregar bits de CSS y JavaScript siempre que el sitio siga funcionando, con uno o ambos apagados.

El concepto más importante aquí es Mejora progresiva . Está agregando campanas y silbatos adicionales usando CSS / JavaScript, pero su sitio web / aplicación funcionará perfectamente bien sin tampoco.

Una gran herramienta para probar 508 , WAI , CSS desactivado, JavaScript desactivado intente utilizar Plugin de desarrollador web para Firefox.

Otros consejos

Creo que la respuesta está realmente en cómo se diseñan las cosas. JQuery tiene la capacidad de ser discreto y, por lo tanto, accesible. El truco es tener redundancia alrededor de sus llamadas AJAX para que los navegadores sin JavaScript puedan utilizar su servicio. En otras palabras, siempre que tenga respuestas de JavaScript, diálogos, etc., debe tener un equivalente degradado.

Si tiene en mente la accesibilidad y está probando adecuadamente para ambos casos de uso (JavaScript vs. Non-JavaScript), debería poder escribir aplicaciones que se adapten a ambos públicos.

Ejemplo ($ (documento). Llamada preparada omitida por claridad y brevedad:

<script>
  $("#hello").click(function(){
    alert("Hi");
  });
</script>
<a href="/say_hello.htm" id="hello">Say Hello</a>

Un ejemplo trivial, pero básicamente solo evaluará el evento de clic de JavaScript si JavaScript es compatible. De lo contrario, funcionará como un enlace normal e irá a say_hello.htm: su trabajo como desarrollador es asegurarse de que ambos resultados se manejen adecuadamente.

¡Espero que eso ayude!

La mejora progresiva es, sin duda, una ruta, pero la discreción no es el acceso completo a JavaScript, ya que los lectores de pantalla tienden a utilizar los navegadores como base para su trabajo. Dado que esos navegadores admiten JavaScript, las secuencias de comandos en su página aún se ejecutarán. Este es un problema particular con AJAX ya que hacer clic en una parte de la página podría cambiar otra parte de la página que el lector de pantalla no conoce.

A medida que AJAX madura, sin embargo, están surgiendo métodos para hacerlo accesible. Busque WAI-ARIA para obtener métodos modernos para hacer que AJAX sea accesible, y AxsJAX de Google para una buena forma de implementarlo.

Ver

También puede echar un vistazo a FlashAid, aunque está lejos de ser una solución perfecta. (Pero, si usó la mejora progresiva y solo usó AJAX cuando Flash estaba presente y el usuario no estaba usando la API de accesibilidad, podría tener una solución razonable ... para Windows).

A la larga, WAI-ARIA es la solución. Es algo compatible con JAWS 10 (beta) y Firevox, pero ciertamente no es suficiente para todos los usuarios actuales.

JQuery tiene la capacidad de ser discreto y, por lo tanto, accesible. El truco es tener redundancia alrededor de sus llamadas AJAX para que los navegadores sin JavaScript puedan utilizar su servicio. En otras palabras, siempre que tenga respuestas de JavaScript, diálogos, etc., debe tener un equivalente degradado.

Una forma de hacer esto para reutilizar su código es tener su " simple " página que llama a una "función" (o lo que sea que use para la lógica del lado del servidor) que se puede invocar solo, devolviendo JSON o XML.

Por ejemplo: /static/myform.asp (en el lado del servidor, 'incluye' la misma lógica que /ajax/myform.asp) de esa manera estarías usando asp como plantillas de django.

Por supuesto, con un marco completo de campanas y silbatos, podría hacer esto mucho más fácil (piense en tener una 'plantilla' html y xml para la misma vista en django), pero se aplica la misma idea.

Una vez hecho esto, iterar sobre todos los anclajes en el documento listo usando jQuery y agregar eventos onclick usando el propio enlace del ancla, reemplazar / static / ajax / podría facilitarle la vida.

¿Alguien puede pensar en razones para que esto sea una carga demasiado pesada? Me gustaría saber si hay alguna falla grave en esta 'idea de diseño'.

Creo que la respuesta aceptada, aunque está bien para su tiempo, ahora está desactualizada. (Literalmente, hace una década al momento de escribir esta respuesta. WCAG 2.1 se finalizó hace unas semanas ...)

El documento W3C WAI-Authoring Design Patterns Practices incluye el documento varios ejemplos de widgets comunes que requieren javaScript para comunicar la semántica, los estados y los roles correctos para las tecnologías de asistencia.

AJAX se puede hacer accesible, siempre y cuando tenga cuidado de dar a los lectores de pantalla pistas semánticas relevantes sobre cuál será la actualización en la página antes de que el usuario la active. Es posible que también deba notificar al lector de pantalla lo que realmente cambió después, p. una región de aria-live podría anunciar "se han cargado 20 nuevos elementos" o lo que sea. Esto se logra con javaScript.

Si su conocimiento de accesibilidad se detiene en 'mejora progresiva', y ve la respuesta aceptada arriba como justificación para esa posición, entonces es posible que necesite una actualización. Las cosas se mueven rápido en estos días.

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow