Continuando con nuestra publicación anterior sobre la accesibilidad del diseño, nos gustaría compartir nuestro proceso de documentación de accesibilidad en la web y los equipos de diseño.En Vanilla, trabajamos arduamente para garantizar marco de vainilla lo más conveniente posible. No pretendemos ser perfectos, pero la accesibilidad es una verdadera prioridad para nosotros y siempre estamos trabajando para mejorar. Recientemente comenzamos a escribir documentación de accesibilidad para nuestros componentes. Describen cómo funciona el componente, así como cualquier consideración importante de accesibilidad que se deba tener en cuenta en la implementación.
Tabla de Contenidos
importancia
en la corriente Documentación de implementación original , proporcionamos un ejemplo de código para cada componente. Las personas pueden acceder a la documentación, encontrar la variante que necesitan y copiar y pegar el código. Fácil, ¿verdad? Cuando se trata de un componente estático simple, no tenemos que preocuparnos demasiado. Sin embargo, en casos más complejos, la implementación es importante para garantizar que los componentes permanezcan accesibles. Decidimos que en lugar de esperar que la gente entendiera por qué estamos agregando un aria-describeby aquí, un aria-label, pensamos que ayudaríamos a explicar.
persona involucrada
Formamos Accessibility Guild dentro de los equipos de Web y Diseño, lo que nos ayudó a gestionar un grupo de mentes brillantes de diversas disciplinas que estaban especialmente interesadas en la accesibilidad. Esto significa que cuando comienza la escritura, somos afortunados de tener una amplia gama de experiencia lista e inminente. Este grupo incluye desarrolladores, diseñadores de UX (experiencia de usuario) y diseñadores de UI (interfaz de usuario).
Al escribir, puede ser difícil asegurarse de que todas las bases estén cubiertas. Siempre habrá cosas que no haya considerado, pero involucrar a tantas personas como sea posible en el proceso de revisión reduce esa probabilidad.
decidir qué incluir
Al crear el componente desde cero, no incluimos consideraciones de diseño accesible porque no están bajo el control de los usuarios del marco Vanilla. Nuestro increíble equipo de diseño hizo todo lo posible para obtener los componentes más fáciles de usar, así que se los entregamos.
Sin embargo, pueden surgir problemas en áreas que escapan a nuestro control, como lo que alguien decide usar para el texto de su etiqueta o los valores de atributos de ARIA. Creemos que es mejor que los usuarios se concentren en esto: cómo usar nuestros componentes existentes de la manera más accesible.
Lo que hemos encontrado hasta ahora
Lo primero que notamos fue cuánto aprendimos. Para poder escribir documentación precisa y concisa para cada componente, la información debe recopilarse de diferentes fuentes.Eso es obvio Pautas de accesibilidad al contenido web (WCAG) 2.1 y Práctica de creación de WAI-ARIA 1.1 (Guía específica de patrón), que es muy útil.También observamos cómo otros sistemas de diseño manejan su documentación de accesibilidad (p. Sistema de diseño de carbono.
Toda esta investigación ha beneficiado enormemente al equipo.Recientemente completamos un excelente taller de accesibilidad productos hexagonales, y escribir la documentación fue una buena modificación para nosotros. Además, estudiar cada componente con tanto detalle significó que nos encontramos con puntos en los que quizás no habíamos pensado al principio.
Algunos componentes son (relativamente hablando) un paseo por el parque, como el acordeón. Hay toneladas de recursos a su alrededor.parte específica de Directrices específicas del modo WAI-ARIA Es fácil encontrar lo que deberíamos cubrir, y un ejemplo para mirar Sistema de diseño de carbono.
Otros son más complicados, como las cartas.Sin sección de tarjeta específica Directrices específicas del modo Siga, así que tuvimos que investigar un poco más.que partes tenemos que averiguar (WCAG) 2.1 Aplicar al usar la tarjeta e incluirla en el documento.
Algunos componentes nos hacen cuestionar nuestro ejemplo actual. Mientras investigamos las listas, notamos que uno de nuestros ejemplos de listas no usaba el elemento de lista HTML. Esto significa que los lectores de pantalla no sabrán que el contenido debe estar agrupado, lo que lo hará menos accesible.Una problemas de Github Archivado para que podamos rastrearlo y arreglarlo.
trabajo en progreso
Recién comenzamos nuestro viaje para escribir documentación de accesibilidad, y todavía tenemos mucho camino por recorrer. Siempre estamos aprendiendo y agradecemos sus comentarios con los brazos abiertos.Si está interesado y quiere ver lo que hemos hecho hasta ahora, puede ver qué componentes hemos cubierto y cuáles aún están bajo revisión. Estamos siguiendo esto en GithubPor favor, siéntase libre de comentar, ¡cualquier comentario es muy apreciado!
