Javascript y Accesibilidad

jquery ajax (5)

Creo que la respuesta está en cómo construyes 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 mente la accesibilidad y está probando adecuadamente ambos casos de uso (JavaScript vs. No JavaScript), debería poder escribir aplicaciones que se ajusten a ambas audiencias.

Ejemplo ($ (document) .ready call 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 solo evaluará el evento de clic de JavaScript si se admite JavaScript. 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 de manera adecuada.

¡Espero que ayude!

Como desarrollador web, varios de los proyectos en los que trabajo caen bajo paraguas del gobierno y, por lo tanto, están sujetos a las 508 leyes de accesibilidad y, en ocasiones, a las pautas de accesibilidad del W3C . ¿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 el uso de paquetes como jQuery para hacer cosas tales 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 retrocesos de javascript, sin embargo, todavía parece incierto el soporte para AJAX en el software de lector de pantalla. Si alguien tiene experiencia específica con esto, sería de gran ayuda.

La mejora progresiva es sin duda una de las rutas, pero la discrecionalidad no es el único objetivo de JavaScript, ya que los lectores de pantalla tienden a usar 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 WAI-ARIA los métodos modernos para hacer que AJAX sea accesible, y AxsJAX de Google para una buena forma de implementarlo.

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.

Una forma de hacerlo para reutilizar su código es hacer que su página "simple" invoque una "función" (o lo que sea que use para la lógica del servidor) que pueda llamarse por sí 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 armazón completo de campanas y silbatos, puede hacer que esto sea 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 documentos listos usando jQuery y agregando eventos onclick usando el propio enlace del ancla, la remplacación de / static / ajax / podría hacer su 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''.

Ver

También puedes echarle 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).

A la larga, 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.

Si su principal preocupación es la accesibilidad, siempre inicie un sitio web usando HTML (elija una definición de tipo de documento y adhiérase a él). 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 la mejora progresiva . Está agregando campanas y silbatos adicionales usando CSS / JavaScript, pero su sitio web / aplicación funcionará perfectamente bien sin ninguno de los dos.

Una gran herramienta para probar 508 , WAI , CSS desactivado, JavaScript desactivado, prueba usar el complemento Web Developer para Firefox.