3 estrategias para desarrollar un software más accesible
Resumen. Del mismo modo, los principales marcos accesibles que utilizan los desarrolladores no pueden considerarse que lo abarcan todo. Del mismo modo que los desarrolladores no crearían una nueva función con una sola herramienta, deberían tener varias entradas para guiarlos en la accesibilidad. Cuanto más sólidos sean los comprobadores de accesibilidad de los desarrolladores, mejor servirán a las personas con necesidades diversas. El autor presenta tres formas para que los desarrolladores eviten recurrir a herramientas y directrices de accesibilidad inadecuadas y mantenerse al día con los cambiantes umbrales de accesibilidad.
• • •
La Administración de Servicios Generales de los Estados Unidos publicó recientemente su Plan de acción de equidad, especificando un enfoque en la accesibilidad más allá del mínimo indispensable para todos los servicios gubernamentales digitales. Este paso de ser una agencia federal indica a las empresas que tendrán que seguir el ejemplo y esforzarse por lograr una accesibilidad que supere los cambios básicos inclusivos. Pero ir por encima del mínimo exige una mentalidad diferente por parte de los desarrolladores. Muchas de las personas que tienen la tarea de volver a concebir el bar para la accesibilidad dependen demasiado de un pequeño conjunto de herramientas que les dan visión de túnel al construir. React, Vue y Svelte tienen la accesibilidad incorporada, pero los desarrolladores que usan solo lo que viene de la estantería corren el riesgo de centrarse demasiado en ellos. Muchas herramientas dan prioridad a los elementos visuales de la accesibilidad porque son los más notables, pero ¿qué pasa con los usuarios con problemas auditivos o de movilidad? Del mismo modo que los desarrolladores no crearían una nueva función con una sola herramienta, deberían tener varias entradas para guiarlos en la accesibilidad. Cuanto más sólidos sean los comprobadores de accesibilidad de los desarrolladores, mejor servirán a las personas con necesidades diversas. He trabajado en desarrollo durante casi una década y he pasado los dos últimos años esforzándome por crear herramientas que ayuden a los diseñadores y desarrolladores de software a inculcar accesibilidad en su oficio. Así es como los desarrolladores pueden evitar recurrir a herramientas y directrices de accesibilidad inadecuadas y mantenerse al día con los cambios en el umbral de accesibilidad.
Mezcle y combine sus herramientas de accesibilidad.
Cada plataforma de desarrollo tiene su propio conjunto de directrices y requisitos de accesibilidad. Por ejemplo, las normas de accesibilidad (a11y) para la Web se detallan en la Pautas de accesibilidad al contenido web (WCAG), Apple usa Directrices de la interfaz humana (HIG), y Android tiene su propio conjunto de directrices. Bibliotecas web como Reaccionar y Vue tienen secciones sobre prácticas recomendadas de accesibilidad, al igual que las bibliotecas de componentes específicos, como Seleccione React y Selección de Vue. Pero si los desarrolladores solo siguen los parámetros de accesibilidad de la plataforma en la que están creando, inevitablemente dejarán algunos vacíos de accesibilidad sin cubrir. Usar solo un conjunto de pautas es como esperar que un índice le cuente toda la historia. La mejor manera de evitar este problema es combinar herramientas y directrices. Si su marco se inclina más por la navegación visual, combínelo con la de Googleárbol de accesibilidad o Firefox Inspector de accesibilidad, que ayuda a los desarrolladores a comprender cómo se expone el contenido a la tecnología de asistencia. Si sus requisitos son predominantemente para personas con discapacidades auditivas, pruebe los de Orca lector de pantalla para escritorios como MATE, GNOME y Unity. Los Sónar GNU/Linux el proyecto es genial para adaptarse a los usuarios con dificultades visuales También hay una gran cantidad de herramientas que los desarrolladores pueden utilizar para probar la accesibilidad en todas las plataformas.Borradoras son geniales para comprobar el código, mientrascomplementos de a11y puede admitir la escritura de componentes accesibles en Storybook. Cuantas más herramientas utilice junto con los requisitos de accesibilidad de su plataforma principal, más completa será su visión de la accesibilidad. Las herramientas tampoco tienen que ser meramente herramientas de desarrollo, sino debates en Reddit Accesibilidad webcomunidad, Rebosamiento de pila, y Slack canal de accesibilidad puede indicarle los lugares que sus directrices originales no cubren.
Aprenda de la legislación de accesibilidad localizada.
Los desarrolladores tienen que adoptar una mentalidad global a la hora de crear productos y, a su vez, tienen que reconocer que la adhesión a la accesibilidad cambia en función de la ubicación. La accesibilidad es mucho más que traducir texto y copiar y pegar desde un marco que funcionaba en otro lugar. Lo que puede ser legalmente compatible o inclusivo en un país probablemente sea diferente en otro. Por ejemplo, el Ley de accesibilidad para los ontarianos con discapacidades (AODA) no tiene las mismas especificaciones que el Norma europea de accesibilidad digital (ES 301 549). Y este tipo de legislación tiende a ir más allá del ámbito de los marcos técnicos populares como React, por lo que los desarrolladores no pueden crear productos conformes haciendo referencia exclusiva a esos marcos. Por ejemplo, la EN301 549 establece que la biometría no puede utilizarse como único medio de identificación del usuario. Sin embargo, las WCAG, un conjunto básico de directrices tecnológicas, no mencionan la biométrica. Algunas ubicaciones tendrán inevitablemente normas más estrictas en materia de accesibilidad y los desarrolladores tendrán que aplicar estas normas en sus productos en todos los ámbitos, incluso en los países que no las solicitan. Los requisitos máximos de accesibilidad que encuentre deberían ser los mínimos que incorpore en todo su trabajo. No es solo un deber moral, sino una decisión empresarial inteligente. En algún momento, las normas van a evolucionar y lo que se considera estricto ahora se convertirá en la norma más adelante. Invocar una serie de herramientas para incluir una mayor difusión de la accesibilidad desde el primer día ayudará a evitar que las empresas inviertan tiempo y dinero en solucionar los problemas de forma retroactiva.
Descubra las áreas grises de los marcos independientes mediante pruebas con usuarios.
No hay una certificación de finalización de accesibilidad. Cuantos más productos o funciones introduzca, más tendrá que probar y más lejos tendrá que ir más allá de las herramientas que utiliza para controlar su accesibilidad. Incluso si no publica activamente, siempre hay margen de mejora, sobre todo para elementos más complejos como el uso del teclado, el enfoque y los puntos de referencia. Revisar la accesibilidad requiere mucho más que descargar bibliotecas enteras que considere accesibles y crear a partir de ellas. Puede que los bloques de creación sean accesibles, pero eso no garantiza que el producto final lo sea. Los desarrolladores tienen la responsabilidad de probar el producto a medida que lo construyen, tanto a escala granular como en su totalidad. Hay que ponerlo en contexto, en las experiencias vividas para confirmar que realmente es accesible. Los desarrolladores deberían probar repetidamente los productos y funciones, en persona o de forma remota con un grupo diverso de usuarios de diferentes capacidades, edades y procedencias. En Stark, hacemos pruebas presenciales siempre que es posible, pero por lo demás utilizamos Zoom para realizar sesiones de comentarios y asegurarnos de que se cumplen los subtítulos, la interpretación de la lengua de signos y otras necesidades de los usuarios. Fábula es una plataforma brillante para involucrar a las personas con discapacidad en la investigación de los usuarios y para destacar los métodos de prueba que revelan las áreas grises de los marcos independientes. Para nosotros, las pruebas de usuarios mostraron que los marcos no impiden que los desarrolladores tengan un orden de enfoque configurado incorrectamente para los usuarios de teclado. Solo aprendimos hablando con personas que utilizan la navegación con el teclado para los sitios web. No hay un único experto en accesibilidad. Es una responsabilidad compartida y todos los desarrolladores tienen que aprovechar los conocimientos de los demás para aumentar su comprensión y manifestación de la accesibilidad. Del mismo modo, los principales marcos accesibles que utilizan los desarrolladores no pueden considerarse que lo abarcan todo. Tienen que usarse junto con otras herramientas y pruebas para mantenerse al día con una barra de accesibilidad más alta y seguir presionando por ella. _ por Michael Fouquet
