julio 27, 2020

Consejos para diseƱo en HTML y CSS accesibles

Te presentamos algunos consejos para diseƱo en HTML y CSS accesibles a fin de que la accesibilidad sea uno de los puntos imprescindibles para los diseƱadores al momento de crear interfaces de usuario.

No tener en cuenta el aspecto de accesibilidad en la fase de diseƱo puede provocar que el sitio web o aplicaciĆ³n sea inĆŗtil para los usuarios. Ya sea que se incluyan pruebas de usabilidad, creaciĆ³n de prototipos, adopciĆ³n de una biblioteca de patrones accesible o simplemente anotaciones en las estructuras, los diseƱadores deben tener presente en su flujo de trabajo.

De esta forma, las fases de revisiĆ³n serĆ”n mĆ”s sencillas para encontrar defectos de accesibilidad, y crear desde el principio la funciĆ³n de “desplazarse hacia la izquierda” lo cual puede tener un impacto positivo en los contenidos de una pĆ”gina.

HTML y CSS accesibles
HTML y CSS accesibles

El desplazamiento hacia la izquierda

El costo de los cambios y la reparaciĆ³n de defectos en diferentes etapas del proceso de desarrollo pueden ser muy caros. El hecho de no arreglar un defecto en la etapa de diseƱo que tiene un factor de 1x, podrĆ­a aumentan a 6x los costos durante la implementaciĆ³n, 15x durante las pruebas despuĆ©s de la confirmaciĆ³n del cĆ³digo, y llegar a 100x si se detecta despuĆ©s de que el defecto lo hace en producciĆ³n, indican algunos estudios.

Una investigaciĆ³n reciente realizada por el National Institute of Standards and Technology (NIST) estima que los costos de reparaciĆ³n de defectos son 10 veces mĆ”s durante que las pruebas de integraciĆ³n y 15 veces mĆ”s durante pruebas del sistema y 30 veces en producciĆ³n. [^ 2] Independientemente de cuĆ”les sean los costos reales de tu organizaciĆ³n, una cosa es segura: detectar defectos en el diseƱo y en la fase de desarrollo representa menor costo que mĆ”s adelante en el proceso.

Se cree que a medida que las aplicaciones web han aumentado en complejidad, el nĆŗmero de defectos por pĆ”gina ha aumentado de entre 30 y 50 defectos por pĆ”gina. Esto ha opacado las tasas de aspectos funcionales y amplifican el valor en pruebas de accesibilidad, asĆ­ como fijar una barra a la izquierda en el proceso.

Fase de diseƱo

Anotaciones

Otro de los consejos para diseƱo en HTML y CSS accesibles, son las anotaciones son explicaciones textuales o grĆ”ficas agregadas a un diseƱo para informar al implementador sobre la intenciĆ³n. Al igual que un diseƱador que considera el color y el tamaƱo de fuente, la informaciĆ³n de accesibilidad tambiĆ©n debe transmitirse en los diseƱos.

Nombre, rol y estado

El nombre accesible que se le da a un componente determinarĆ” la informaciĆ³n a un usuario de la tecnologĆ­a de asistencia cuando se interactĆŗe con Ć©ste.

Los diseƱadores deben de ser minuciosos en sus prototipos y anotar todos los aspectos (aunque parezcan obvios) para garantizar que los implementadores agreguen esta informaciĆ³n semĆ”ntica a las funcionalidades de un componente. Tener los roles asignados desde el principio ahorrarĆ” tener que regresar y agregarlos a los controles despuĆ©s del proceso de implementaciĆ³n.

Finalmente, al igual que los diseƱadores trazan la apariencia de un control cuando estĆ” en reparaciĆ³n, deben pensar en los diversos estados de su widget en tĆ©rminos de accesibilidad.

Pruebas de usabilidad

La prueba de usabilidad es una metodologĆ­a de investigaciĆ³n UX en la que un investigador hace que un usuario realice diversas tareas, despuĆ©s analiza su comportamiento, Ć©sta es una etapa muy importante en la fase de diseƱo.

La informaciĆ³n recopilada de las pruebas de usabilidad es vital para configurar las experiencias de los usuarios digitales. La posibilidad de realizar este tipo de pruebas con usuarios con discapacidades es extremadamente importante porque permite tener una idea de la facilidad con la que estos usuarios podrĆ”n interactuar con el contenido que estĆ”n creando. Si se realizan pruebas de usabilidad en un sistema existente, se podrĆ” configurar un escenario realista y aterrizado para el participante, lo cual es excelente cuando se trata de usuarios que confĆ­an en diversas tecnologĆ­as de asistencia.

Si realizas pruebas de usabilidad en un sistema que aĆŗn no existente, debes prepararte para enfrentar los desafĆ­os de accesibilidad que rodean la salida del software de diseƱo. Los prototipos interactivos generados por estas herramientas suelen ser diferentes de lo que serĆ” el producto final en un navegador o en una plataforma del sistema operativo. AdemĆ”s, los “prototipos funcionales” suelen ser inaccesibles, lo cual se traducirĆ” como uno de los consejos para diseƱo en HTML y CSS accesibles.

Si es posible, encuentra una alternativa que se pueda usar en el lugar de tu prototipo, lo que puede darte una buena idea de cĆ³mo interactuarĆ”n los participantes con el sistema. Por ejemplo, si creas un nuevo componente de navegaciĆ³n mĆ³vil, busca uno similar en internet y realiza pruebas de usabilidad con este. Determina quĆ© funcionĆ³ en esta alternativa y aprende de sus mejoras.

De cualquier manera, siempre debes de estar preparado para hacer adaptaciones los sus participantes de las pruebas de usabilidad en funciĆ³n de sus discapacidades. Asegurarse de que las pruebas se realicen sin problemas y sin obstĆ”culos no solo facilitarĆ” el proceso a los usuarios, sino que tambiĆ©n le permitirĆ” realizar mĆ”s pruebas en menos tiempo.

Bibliotecas de patrones

Las bibliotecas de patrones son colecciones de componentes para la interfaz de usuario y son beneficiosas tanto en las fases de diseƱo como en la de desarrollo. Tener un conjunto de componentes de interfaz de usuario accesibles hace que la creaciĆ³n de aplicaciones funcionales sea mucho mĆ”s fĆ”cil. Para el diseƱador, estos componentes ayudan a mantener una buena consistencia en su aplicaciĆ³n, lo que mejora la experiencia general de sus usuarios.

Por otro lado, para el desarrollador, tener componentes reutilizables, accesibles y probados ayuda a producir contenido de alta calidad. Estos componentes deben tratarse con especial cuidado en tƩrminos de accesibilidad porque se usarƔn numerosas veces a travƩs de las aplicaciones

Trabajar con desarrolladores

Se recomienda hablar con otros desarrolladores y diseƱadores, ya que suele pasar que trabajan completamente aislados unos de otros. No solo se debe incluir a los desarrolladores en la fase de diseƱo como reuniones de revisiĆ³n de diseƱo, sino que se deben incluir a los diseƱadores en la fase de desarrollo.

Los desarrolladores deben estar al tanto de los detalles de implementaciĆ³n que pueden ayudar a dar forma a las composiciones de diseƱo o incluso pivotar un enfoque para resolver un problema de diseƱo.

Del mismo modo, los diseƱadores pueden ayudar a mantener a los desarrolladores todo bajo control cuando se trata de implementar sus diseƱos de manera accesible porque los aspectos orientados a detalles, como el espacio y el uso de colores especƭficos, pueden tener impacto en la accesibilidad.

Mientras que los desarrolladores implementan un diseƱo, los diseƱadores deben prestar mucha atenciĆ³n a cosas como el enfoque, el orden de tabulaciĆ³n, el orden de lectura, las fuentes, los colores e incluso los nombres accesibles y los textos alternativos de las imĆ”genes. Porque, despuĆ©s de todo, Āæde quĆ© servirĆ­an todas esas anotaciones de accesibilidad si el desarrollador las ignora?

La fase de desarrollo

Prueba de accesibilidad automatizada

A los desarrolladores les encanta la idea de que ciertas cosas en nuestros flujos de trabajo se pueden automatizar. Afortunadamente, hay bibliotecas de automatizaciĆ³n de accesibilidad increĆ­bles disponibles, que se deberĆ­an aprovechar para ayudar a crear interfaces accesibles sostenibles.

Las herramientas de anĆ”lisis estĆ”tico como eslint-plugin-jsx-a11y pueden advertir a desarrolladores sobre posibles problemas de accesibilidad mientras estĆ”n codificando. Los desarrolladores incluso pueden configurar su editor de texto para que muestre estas advertencias correctamente mientras escriben el cĆ³digo, detectando estos defectos a medida que aparecen.

Los motores de reglas de accesibilidad, como ax-core, se pueden integrar en casi cualquier marco o entorno y pueden ayudar a detectar problemas de accesibilidad comunes.

Una manera de garantizar que el equipo estĆ© creando contenido accesible es integrar este tipo de herramientas en los canales de integraciĆ³n continua y entrega continua. Escribir casos de prueba especĆ­ficos de accesibilidad (unidad o extremo a extremo) es otra forma de automatizaciĆ³n. Esto significa que podemos garantizar defectos de accesibilidad mĆ­nimos incluso llegar a los servidores de desarrollo y no alcanzar la fase de producciĆ³n.

Administra los defectos de accesibilidad

Los problemas de accesibilidad no deben tratarse de manera diferente a los defectos de seguridad o funcionalidad. Deben clasificarse y priorizarse regularmente con el resto de la carga de trabajo “normal”.

La mediciĆ³n del progreso y la recopilaciĆ³n de mĆ©tricas especĆ­ficas para los defectos de accesibilidad tambiĆ©n pueden ser Ćŗtiles, especialmente si el equipo estĆ” enfocado en aumentar la accesibilidad, lo cual puede ayudar a identificar los puntos dĆ©biles o cuellos de botella en el sistema. Si el equipo participa en retrospectivas de sprint, la accesibilidad deberĆ­a ser un tema de conversaciĆ³n. Reflexionar sobre lo que funciona y lo que no es un ejercicio saludable y puede conducir a mejoras en el enfoque general.

La herramienta axe beta

Las pruebas manuales requieren una comprensiĆ³n profunda de la accesibilidad, asĆ­ como las pautas de accesibilidad al contenido web del W3C, o “WCAG”. La aplicaciĆ³n Axe Beta ayuda a superar las pruebas manuales sin tener que ser un experto en accesibilidad. Tiene un gran conjunto de pruebas guiadas inteligentes, que hacen preguntas simples y facilitan el trabajo.

Tomemos imĆ”genes como ejemplo y quĆ© informaciĆ³n proporcionan en el contexto de una pĆ”gina web. Una biblioteca de automatizaciĆ³n de accesibilidad no puede derivar una intenciĆ³n informativa escaneando o procesando una imagen. Incluso si alimentamos una imagen con un algoritmo de aprendizaje automĆ”tico y hay una descripciĆ³n perfecta de lo que hay en esa imagen, no se sabrĆ” quĆ© transmite esa imagen en el contexto de la pĆ”gina. La informaciĆ³n que transmite una imagen determinada, o si se usa Ćŗnicamente como decoraciĆ³n, depende completamente del autor del contenido.

Todo junto

Tener en mente la accesibilidad desde el comienzo del desarrollo hace que la creaciĆ³n de contenido accesible sea mucho mĆ”s fĆ”cil que hacer que las consideraciones en el ciclo de vida del desarrollo de software. Al incorporar la accesibilidad a las ideas, el diseƱo y la implementaciĆ³n de su software, crea un producto mĆ”s sostenible.

Prepara a tu equipo utilizando recursos como WCAG, ARIA, ARIA Authoring Practices y Stack Overflow. Evita que los defectos de accesibilidad lleguen al software aprovechando las bibliotecas de automatizaciĆ³n de accesibilidad e integrĆ”ndolas en los servidores de integraciĆ³n continua.

LeĆ­ste: Consejos para diseƱo en HTML y CSS accesibles, te recomendamos: CĆ³mo configurar HTTPS con create-react-app

Te invitamos a que nos sigas en nuestras redes sociales: Facebook, Twitter, Instagram y Youtube con el perfil:Ā @tortugacode