javascript - sirve - que es ecmascript

Accesibilidad y todos estos marcos de JavaScript (4)

He estado investigando algunos de los frameworks de JavaScript como Backbone.js y Batman.js por un tiempo, y aunque realmente me gustan, tengo una cosa interesante de la que sigo volviendo. Ese problema es la accesibilidad.

Como desarrollador web, siempre he intentado hacer que mis sitios web y aplicaciones tengan en cuenta la accesibilidad, especialmente con la idea de la mejora progresiva.

Claramente fuera de la caja, estos nuevos marcos JS no se degradan con gracia, así que me preguntaba cuáles son los pensamientos de otros desarrolladores sobre este tema y qué estás haciendo al respecto. Después de todo, la accesibilidad de un sitio web / aplicación no es realmente una opción ya que es parte de la ley en muchos países.

Tal vez estoy siendo demasiado celoso en este tema, y no aprecio lo lejos que han llegado las cosas en términos de accesibilidad.

Chris Blouch (AOL) y Hans Hillen (TPG) tuvieron una buena presentación sobre esto con respecto a jQuery, incluido el trabajo que hacen al revisar la accesibilidad. Hacer que las aplicaciones enriquecidas de Internet sean accesibles a través de JQuery Eso y otra presentación relacionada sobre accesibilidad de HTML5 y aplicaciones enriquecidas de Internet ( http://www.paciellogroup.com/training/CSUN2012/ ) deberían ser de su interés.

Mi dinero está en elegir el marco más accesible: jQuery ofrece una gran cantidad de degradación elegante o una recuperación de mejora progresiva, así como un enfoque general bastante bueno en la accesibilidad. Además, de forma indirecta, ayudo a probar y revisar varios sistemas que aprovechan jQuery (sitios web públicos e Intranet de Drupal) para que los defectos encontrados para la accesibilidad se encuentren y se reenvíen al proyecto para solucionarlos.

Como soy un usuario y desarrollador web con problemas de visión, hablaré aquí.

Estos marcos, en mi experiencia, no han sido un problema siempre que se tomen las medidas apropiadas con respecto a la accesibilidad.

Muchos lectores de pantalla entienden JavaScript, y nosotros, como desarrolladores, podemos mejorar la experiencia usando elementos como el atributo aria-live de HTML5 para alertar a los lectores de que todo está cambiando, y podemos usar el atributo de función para proporcionar pistas adicionales a los lectores de pantalla.

Sin embargo, el principio básico del desarrollo web con JavaScript es que primero debemos desarrollar el sitio subyacente, sin JavaScript, y luego usar esa base sólida, funcional y probada para proporcionar mejores características. No se debe requerir el uso de JS para comprar un producto, recibir servicios u obtener información. Y algunos usuarios deshabilitan JavaScript porque interfiere con la forma en que funcionan sus lectores de pantalla.

Hacer un sitio completo de Backbone.js o Knockout desde cero sin tener en cuenta el acceso resultará en algo parecido a "nuevo Twitter" que falla extremadamente duro con muchos lectores de pantalla. Pero Twitter tiene una base sólida y, por lo tanto, podemos utilizar otros medios para acceder a la plataforma. El injerto de Backbone en un sitio existente que tiene una API bien elaborada es bastante factible y muy divertido también.

Básicamente, estos marcos en sí mismos no son más un problema de accesibilidad que el propio QUQUery: el desarrollador necesita crear una experiencia de usuario que funcione para todos.

Cualquier página web que requiera javascript para obtener el contenido probablemente se enfrentará a desafíos relacionados con la accesibilidad. La accesibilidad de los frameworks de JavaScript es definitivamente una cuestión controvertida, aunque, en realidad, cualquier aplicación web sufre inconvenientes cuando el contenido se proporciona dinámicamente, independientemente del marco utilizado.

No hay una solución mágica para garantizar que tu sitio esté accesible y, desde luego, no puedo contabilizar todos los marcos de JavaScript. A continuación, presentamos algunas ideas sobre cómo evitar que su sitio sea totalmente inaccesible al usar JavaScript:

Siga las pautas de WCAG 2.0 sobre scripting del lado del cliente , y WCAG 2.0 en general.
Evite los marcos que requieren que genere la interfaz de usuario, los controles y / o el contenido de la página por completo a través de JavaScript, como Uki.js , o los que utilizan su propia Uki.js , como Jo . Cuanto más cerca te puedas quedar con contenido HTML estático (-ish) estático, mejor estarás.
Considere el uso de roles ARIA como role="application" y el atributo aria-live para indicar las áreas de su página que son dinámicas. Cada vez más roles de aria son apoyados por dispositivos de asistencia a medida que pasa el tiempo, por lo que el uso de estos atributos aria tiene sentido cuando puede agregarlos a su aplicación de manera adecuada.
En términos de bibliotecas JS, verifique su fuente y vea si generan algún rol de aria. Puede que no sean perfectamente accesibles, pero demostraría que están considerando dispositivos de asistencia.
Siempre que sea posible, trate JavaScript como una mejora en lugar de una necesidad. Intente proporcionar métodos o flujos de trabajo alternativos para acceder a la información importante que no requiere actualizaciones de páginas dinámicas.
¡Prueba y valida tu aplicación con tus usuarios! Realice algunas sesiones de prueba de usuario con personas que usan dispositivos de asistencia o tienen otras dificultades para usar el software web. Nada le ayudará a demostrar que su sitio es accesible más que a ver a personas reales usarlo.

El último punto es el más importante, aunque muchos tratan de escapar de él. Independientemente de la tecnología, el hecho es que está desarrollando una aplicación que las personas utilizarán. Ninguna máquina o teoría podrá validar perfectamente su aplicación como utilizable, pero de todos modos no la está construyendo para máquinas. ¿Derecha? :)

Uso un js-framework (spine.js en mi caso) en mi último sitio. De todos modos, me aseguro de que los navegadores que no son js (ciertamente no demasiado entusiastas: piensen en SEO) puedan navegar por mi sitio y digerir los contenidos.

Como ejemplo, voy con una página de búsqueda con productos que se muestran. Los productos pueden ser buscados, filtrados, clasificados. Por supuesto, este es un ejemplo de la idea generalizada.

PREREQ: use un motor de plantilla que pueda mostrar tanto el lado del servidor como el del lado del cliente. (Yo uso bigote). Esto asegura que puede representar modelos sin js- a través de plantillas del lado del servidor y renderizar modelos con js a través de plantillas del lado del cliente.

Inicialmente: represente los productos utilizando bigote-plantilla del lado del servidor. Incluya también un objeto ''bootstrapJSON'' que contenga los mismos productos en formato JSON.
Inicialmente: todos los enlaces (página de detalles del producto, paginación, clasificación, filtrado) son URL reales del lado del servidor (sin URL hashbang)
El resultado final es una página que se puede navegar al 100% con paginación, clasificación y filtrado sin el uso de JS.
todas las URL de búsqueda, clasificación y filtrado dan como resultado una solicitud al servidor, lo que a su vez genera un nuevo conjunto de productos. Nada especial aquí.
JS habilitado - en domload:
- busque el bootstrapJSON y haga modelos de producto a partir de él (use sus funciones js-framework para hacer esto).
- Después reenvía los productos usando la misma plantilla de bigote, pero ahora lo hace desde el lado del cliente. (Nuevamente usando su js-framework).
- Visualmente, nada debería cambiar (después de que todas las representaciones del lado del servidor y del lado del cliente se realizaron en los mismos modelos, con la misma plantilla), pero al menos ahora existe una vinculación entre el modelo del lado del cliente y la vista.
- transformar las URL a hashbang-urls. (por ejemplo: / products / # sort-price-asc) y usa tus características de js-framework para conectar los eventos.
ahora cada url (filtrado, paginación, clasificación) debería dar como resultado un cambio de estado del lado del cliente, lo que probablemente daría como resultado que su js-framework hiciera una petición ajax al servidor para que devuelva nuevos productos (en formato JSON). Reformular esto nuevamente en el cliente debería resultar en su vista actualizada.
La parte lógica del código para manejar la solicitud ajax en 6. en el lado del servidor es 100% idéntica al código utilizado en 4. Diferenciar entre una llamada ajax y una solicitud ordinaria y escupir los productos en JSON o html (usando bigote en el lado del servidor) respectivamente.

EDITAR: ACTUALIZAR ENERO 2013 Dado que esta pregunta / respuesta está obteniendo una tracción razonable, pensé que compartiría algunos aha-momentos estrechamente relacionados del último año:

Escupir JSON y renderizarlo desde el lado del cliente con su mvc del lado del cliente elegido (pasos 6. y 7.) puede ser bastante costoso para la CPU. Esto, por supuesto, es especialmente evidente en los dispositivos móviles.
He hecho algunas pruebas para devolver los fragmentos de html en ajax (utilizando la representación de la plantilla del bigote del lado del servidor) en lugar de hacer lo mismo en el lado del cliente como se sugiere en mi respuesta anterior. Dependiendo de su dispositivo cliente, puede ser hasta 10 veces más rápido (1000ms -> 100ms), por supuesto su millaje puede variar. (prácticamente no se necesitan cambios de código, ya que el paso 7 ya podría hacer ambas cosas)
Por supuesto, cuando no se devuelve JSON, no hay forma de que un MVC del lado del cliente construya modelos, administre eventos, etc. Entonces, ¿por qué mantener un MVC en el cliente? Para ser honesto, incluso con páginas de búsqueda muy complejas en retrospectiva, no tengo mucho uso para los mvc del lado del cliente. El único beneficio real para mí es que ayudan a separar claramente la lógica del cliente, pero ya deberías estar haciendo eso por tu cuenta. En consecuencia, eliminar el MVC del lado del cliente está en todo.
Oh, sí, cambié Bigote por Hogan (la misma sintaxis, un poco más de funcionalidad, pero sobre todo, ¡extremadamente eficiente!). Pude hacerlo porque cambié el backend de java a Node.js (que me gusta)