Krypton Solid

Simplificando la accesibilidad con Ally.js – Smashing Magazine

Simplificando la accesibilidad con Ally.js – Smashing Magazine

He sido desarrollador web durante 15 años, pero nunca había investigado la accesibilidad. No conocía a suficientes personas con discapacidades (graves) para comprender adecuadamente la necesidad de aplicaciones accesibles y ningún cliente tiene siempre me requirió saber qué es ARIA. Pero me involucré con la accesibilidad de todos modos, y esa es la historia que me gustaría compartir con ustedes hoy. En la Conferencia Fronteers de octubre de 2014, vi a Heydon Pickering dar una charla titulada «No llegar a ninguna parte con las mejores prácticas de CSS». Entre otras cosas, defendió el uso de atributos WAI-ARIA como aria-disabled="true" en lugar de clases como .is-disabled para expresar el estado de la aplicación. En ese momento me di cuenta de que me estaba perdiendo algunos estándares bien preparados, simplemente porque ARIA pertenece a ese espacio de accesibilidad del que no tenía ni idea.

He sido desarrollador web durante 15 años, pero nunca había investigado la accesibilidad. No conocía a suficientes personas con discapacidades (graves) para comprender adecuadamente la necesidad de aplicaciones accesibles y ningún cliente tiene siempre me requirió saber qué es ARIA. Pero me involucré con la accesibilidad de todos modos, y esa es la historia que me gustaría compartir con ustedes hoy.

En el Conferencia de Fronteers en octubre de 2014 vi Heydon Pickering dar una charla llamada «No llegar a ninguna parte con las mejores prácticas de CSS”. Entre otras cosas, defendió el uso de WAI-ARIA atributos como aria-disabled=“true” en lugar de clases como .is-disabled para expresar el estado de la aplicación. En ese momento, me di cuenta de que me estaba perdiendo algunos estándares bien preparados, simplemente porque ARIA pertenece a ese espacio de accesibilidad del que no tenía ni idea.

Otras lecturas en SmashingMag:

Después de hablar un poco más con Heydon, finalmente entendí que ARIA podía ayudarme a escribir aplicaciones web sin tener que hacerlo. cobertizo para bicicletas nombres de clases para varios estados (está desactivado, está visible, todavía se está cargando …). La discusión no tocó en absoluto la accesibilidad, simplemente estábamos hablando de cómo hacer que el desarrollo web sea un poco más simple.

Decidí que necesitaba profundizar en ARIA, honestamente, no porque me preocupara profundamente la accesibilidad, sino porque no tenía intención de reinventar las ruedas que ya tenían. Una de las primeras cosas que aprenderá al mirar ARIA es que Apoyar la navegación por teclado es fundamental. Y el primer paso para comprender la navegación por teclado es comprender qué enfocar es. Y aquí es donde tropecé, porque nadie sabía (en detalle) qué elementos podían recibir atención y cuáles no.

Habiendo tenido un poco de experiencia probando la compatibilidad del navegador (“Transiciones CSS3: ¡Gracias a Dios tenemos una especificación!”), Decidí que dedicaría un tiempo a investigar. Un libro electrónico que cubre mis hallazgos está en proceso y estará listo para hacerle perder el enfoque a principios de 2016. Pero lo más importante es que la variante JavaScript de ese libro está disponible hoy:

Simplificando la accesibilidad
ally.js es una biblioteca de JavaScript para ayudar a las aplicaciones web modernas con problemas de accesibilidad al simplificar la accesibilidad.

Aspectos destacados de ally.js

Antes de que veamos por qué y cómo surgió este proyecto, aquí hay una breve lista de cosas en las que puede ayudarlo:

ally.js incluye algunas calzas y un polyfill, pero no tiene dependencias importantes. Está diseñado para ser compatible: UMD, AMD, CommonJS, ES6, módulos o empaquetados – Es tu elección.

¡Muéstrame algo de código!

Al hacer que el teclado de su aplicación sea accesible, es importante ocultar elementos del teclado con los que actualmente no se puede interactuar. Este puede ser el caso cuando se ve un cuadro de diálogo modal o se muestra el menú fuera de la pantalla. Podemos deshabilitar fácilmente todo fuera de nuestro diálogo:

// disable everything that is not a child of #our-dialog
var handle = ally.maintain.disabled({
  filter: '#our-dialog',
});
// re-enable everything that we disabled previously
handle.disengage();

El mismo principio es cierto para cualquier contenido (no solo el interactivo) para asegúrese de que los usuarios de lectores de pantalla no se pierdan. Podemos escondernos facilmente todo fuera de nuestro diálogo:

// hide everything that is not a child of #our-dialog by adding aria-hidden="true"
var handle = ally.maintain.hidden({
  filter: '#our-dialog',
});
// re-enable everything that we disabled previously
handle.disengage();

A veces necesitamos actuar sobre claves específicas como Ingresar y Escapar:


var handle = ally.when.key({
  enter: function(event) {
    // handle the enter event
  },
  escape: function(event, disengage) {
    // handle the escape event…
    disengage();
  },  
});
// stop listening for keys
handle.disengage();

Motivación

Echemos un vistazo a por qué pensé que era necesario crear algo nuevo en primer lugar. Si bien existen varias razones, estas son las importantes:

  1. Muchos artículos (especialmente los más antiguos) contienen ejemplos y enfoques de códigos que no son fácilmente comprensibles y promueven prácticas de codificación que, según los estándares actuales, se considerarían perjudiciales.
  2. Incluso los buenos artículos generalmente solo se enfocan en la accesibilidad, ignorando todo lo que sea relevante para crear sitios web y aplicaciones atractivos.
  3. Literalmente sin artículos ni recursos Cuota código. No parece haber mucha colaboración (en el código) fuera de los proyectos individuales, lo que lleva a que lo mismo se codifique una y otra vez.
  4. Muchos problemas no parecen bien comprendidos o, para empezar, no se consideran un problema.
  5. En algunos aspectos, la accesibilidad se siente indeterminada. En prácticamente todos los casos relacionados con la semántica, nos encontramos en un estado que se parece a principios de la década de 2000: es posible que haya creado algo que se ajuste a los estándares, pero eso no significa que funcione en todas partes, o incluso en cualquier lugar.

Al final, sentí que nos faltaba una caja de herramientas adecuada. Como jQuery es conquistar el DOM sin tener que preocuparse mucho por la compatibilidad del navegador, ya sean agujeros o errores sutiles. Como D3 es conquistar la visualización interactiva de datos. O como lo fue RaphaelJS para conquistar SVG hace solo unos años. No pude encontrar nada similar que hiciera el trabajo pesado para la accesibilidad, al menos nada completo e independiente del marco.

Ejecución

Tengo algunos principios que guían mi forma de trabajar:

  1. Si no comprende el problema, no está creando soluciones. La investigación es clave.
  2. Empiece poco a poco, vaya construyendo con el tiempo.
  3. Las soluciones complejas no cambian el mundo. La simplicidad es clave.
  4. Una persona solo puede hacer mucho. La colaboración es clave.

La investigación es clave

Antes de que pueda escribir una sola línea de código para hacer algo, debe tener una idea bastante clara de lo que se supone que debe hacer esa línea de código. Si solo resuelve el problema en cuestión, es probable que se esté perdiendo el panorama general. Sin la imagen más grande frente a ti creando soluciones duraderas es increíblemente difícil, si no casi imposible.

Una vez que me di cuenta de que ni yo ni Internet podíamos responder la simple pregunta de qué elementos pueden enfocarse, solo quedaba una opción: arremangarme y descubrir qué hacen realmente los navegadores. Esto condujo a una tabla de compatibilidad detallando lo que los navegadores consideran enfocables, un comparación de estilos de enfoque y una gran cantidad de errores archivados.

Empieza pequeño

Durante los últimos 14 meses logré mantener centrarse en la navegación del teclado. Sin perderme a mí mismo, ni a la biblioteca, en demasiada semántica de ARIA. Hacer una cosa y no comenzar nada nuevo hasta que haya terminado no es fácil, especialmente si está aprendiendo una docena de trucos nuevos al día.

Comenzar con poco también significaba limitar el alcance del navegador. No necesitaba navegadores antiguos de Internet Explorer y Android, por lo que la versión 1.0.0 no admite nada por debajo de IE10 y Android 4.4. La versión 1.1.0 agregará soporte para IE9, un segundo paso razonable.

La simplicidad es clave

Si desea que las personas utilicen sus herramientas, debe asegurarse de que su la herramienta tiene sentido para ellos, preferiblemente sin requerir un título en ciencia espacial. Pero, ¿cómo se oculta la complejidad interna de una herramienta para que parezca simple?

  • Proporcione una API coherente y memorable.
  • Proporcione documentación que no solo explique cómo usar una función, sino también por qué es necesaria en primer lugar.
  • Exponga meticulosamente todos los casos extremos en la documentación para evitar que las personas tengan que depurar tu código.
  • Haga que consumir su herramienta sea muy sencillo. AMD y CommonJS se pueden generar a partir de ES6. Los módulos se pueden agrupar y exponer como UMD.
  • Proporcione tutoriales que expliquen cómo las funciones de su herramienta funcionan juntas para resolver problemas particulares.
  • Proporcione formas de experimentar rápidamente con las funciones de su herramienta sin tener que instalar Internet primero.

La colaboración es clave

He reunido todo mi tiempo libre en los últimos 14 meses y lo he dedicado a mis proyectos de código abierto. No te voy a mentir: fue duro y estoy seguro de que no podré seguir así. Para evitar el fracaso de un espectáculo individual, el proyecto deberá encontrar e involucrar a personas de ideas afines. Pero la colaboración es un tema multifacético.

La contribuyentes principales son personas que dedican tiempo al proyecto de forma habitual. Esta es la forma más rara de contribución, ya que requiere el mayor compromiso. Por eso estoy increíblemente feliz de dar la bienvenida. Marcy Sutton ¡a bordo! En muchos formas en que Marcy ha mucho más experiencia en el mundo de la accesibilidad que yo, por lo que su incorporación al equipo es nuestra primera gran victoria. Para asegurarnos de que más personas puedan intervenir, todo lo que hacemos es documentado.

Es bastante común que las personas envíen parches más pequeños al código fuente y la documentación. Debido a que es probable que una sola persona solo contribuya con unos pocos cambios, nos gusta llamarlos contribuyentes de drive-by. Para ellos es importante poder realizar sus cambios de forma rápida y segura. Es por eso que todas las páginas de documentación tienen vínculos convenientes para abrir problemas, editar páginas y señalar recursos relacionados (archivos fuente, documentación, pruebas).

Y luego está el grupo de personas que no están contribuyendo al código del proyecto, más aún a su éxito. La integradores son personas muy importantes, ya que se están haciendo cargo de ampliar otros proyectos al agregarles funciones de ally.js. Actualmente estamos hablando con la gente de interfaz de usuario de jQuery y Angular’s ngAria sobre cómo apoyar mejor sus esfuerzos descargando cosas a ally.js. Algunas personas de la comunidad React también han expresado su interés.

Todo lo que hacemos dentro del espacio ally.js tiene la intención de mejorar el status quo para todos, incluso y especialmente para las personas no usando la biblioteca. Los errores del navegador que estamos registrando y la discusión sobre la mejora de nuestros estándares web se basan en la investigación que estamos haciendo para mejorar la biblioteca. Sin embargo, no te sorprenderá que la biblioteca se mueva mucho más rápido que los estándares web en general.

El futuro

De las tres columnas de accesibilidad (compatibilidad con teclado, semántica y UI flexible), ally.js actualmente solo cubre la primera. Con las ideas que Marcy trae consigo (y tal vez algunas mentes más) pretendemos sumergirnos en el pilar de la semántica. Comprender ARIA es una cosa, pero comprender qué hacen los navegadores y lectores de pantalla con él es otra historia.

Buscaremos proporcionar API simples para ARIA para sus necesidades imperativas. Investigaremos opciones para automatizar la aplicación de semánticas como estas «Consejos para crear archivos SVG accesibles”En tiempo de ejecución y dentro de su proceso de construcción.

Veremos cómo mejorar su uso de ARIA proporcionándole soporte de teclado extendido para widgets comunes (como el cuadro de lista).

Conclusión

Puede preocuparse por los problemas de accesibilidad sin verse afectado por una discapacidad. En muchos formas, haciendo que sus aplicaciones y sitios sean accesibles todos. ally.js te ayuda a lograr eso.

ally.js se está posicionando como un centro para colaborar en funciones relacionadas con la accesibilidad, proporcionando herramientas de bajo nivel a otras bibliotecas y marcos, así como funciones de alto nivel a los desarrolladores. Si empezamos a trabajar juntos, podríamos llegar a alguna parte …

Deja un comentario