Javascript y accesibilidad

Question

Como desarrollador web, algunos de los proyectos en los que trabajo están incluidos en las sombrillas gubernamentales y, por lo tanto, están sujetos a las leyes 508 Accessibility y, en ocasiones, a W3C accessibility. ¿Hasta qué punto se puede usar JavaScript sin dejar de cumplir estos requisitos?

En esta línea, ¿hasta qué punto es JavaScript, específicamente AJAX y utiliza paquetes como jQuery para hacer cosas como mostrar diálogos modales, ventanas emergentes, etc. compatibles con software de accesibilidad moderno como JAWS, Orca, etc.? En el pasado, la regla decía 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 y cuando no haya errores de javascript, sin embargo, todavía parece incierto el soporte para AJAX en el software lector de pantalla. Si alguien tiene experiencia específica con esto, sería de gran ayuda.

Answer 1

Si la accesibilidad es su principal preocupación, siempre iniciar un sitio web.! utilizando Cumple con los estándares (elige una definición de tipo de documento y adhiérete a ella) HTML. Si se trata de una aplicación web (envíos de formularios, etc.), asegúrese de que los formularios funcionen solo con HTTP GET y POST. Una vez que tenga un sitio web/aplicación completo, puede agregar bits de CSS y JavaScript, siempre y cuando el sitio siga funcionando, con uno o ambos desactivados.

El concepto más importante aquí es Progressive Enhancement. 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, prueba usando el plugin Web Developer para Firefox.

Answer 2

Creo que la respuesta está realmente en la forma en que se diseñan las cosas. JQuery tiene la capacidad de ser discreto y, por lo tanto, accesible. El truco es tener redundancia en torno a sus llamadas AJAX para que los navegadores sin JavaScript puedan utilizar su servicio. En otras palabras, donde sea que tengas respuestas, diálogos, etc. de JavaScript, necesitas tener un equivalente degradado.

Si tiene en cuenta la accesibilidad y está probando adecuadamente ambos casos de uso (JavaScript vs. No JavaScript), debería poder escribir aplicaciones que se adapten a ambas audiencias.

Ejemplo ($ (document) llamada ready omitido para mayor 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 esto sólo se evaluará el evento clic JavaScript si se admite JavaScript De lo contrario, se llevará a cabo como un enlace normal e ir a say_hello.htm - su trabajo como el desarrollador es para asegurarse de que ambos resultados son manejados de manera apropiada

Esperamos que ayuda

Answer 3

La mejora progresiva es sin duda una de las rutas, pero la discrecionalidad no es el principio de la accesibilidad a JavaScript, ya que los lectores de pantalla suelen utilizar los navegadores como base para su trabajo. Como esos navegadores admiten JavaScript, las secuencias de comandos en su página seguirán ejecutándose. Este es un problema particular con AJAX ya que al 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. Consulte en el WAI-ARIA los métodos modernos para hacer que AJAX sea accesible, y Google's AxsJAX para una buena forma de implementarlo.

---

Answer 4

jQuery tiene la capacidad para ser discreto y por lo tanto accesible. El truco es tener redundancia en torno a sus llamadas AJAX para que los navegadores sin JavaScript puedan utilizar su servicio. En otras palabras, donde sea que tengas respuestas, diálogos, etc. de JavaScript, necesitas tener un equivalente degradado.

Una forma de hacer esto para reutilizar el código, es que su página "simple" llamando a una "función" (o lo que se utiliza para la lógica del lado del servidor) que se puede llamar por sí mismo, volviendo 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 se estaría utilizando asp como plantillas de Django.

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

Habiendo hecho esto, iterando sobre todos los anclajes en el documento listo usando jQuery y agregando eventos onclick usando el propio enlace del ancla, remplacing/static/ajax/podría hacerte la vida más fácil.

¿Alguien puede pensar en razones para que esto sea una carga excesiva? Me gustaría saber si hay algún defecto serio en esta 'idea de diseño'.

Answer 5

Ver

• http://juicystudio.com/article/making-ajax-work-with-screen-readers.php
• http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php
• http://www.paciellogroup.com/blog/?p=15
• http://www-03.ibm.com/able/resources/ajaxaccessibility.html

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 utilizó AJAX cuando Flash estaba presente y el usuario no estaba usando la API de accesibilidad, es posible que tenga una solución razonable ... para Windows.)

En el largo plazo WAI- ARIA es la solución. Es un tanto compatible con JAWS 10 (beta) y Firevox, pero ciertamente no es suficiente para todos los usuarios de hoy.