No hay un solo 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 tomarse como exhaustivos. Del mismo modo que los desarrolladores no crearían una nueva función con una sola herramienta, deberían tener varias entradas que los guíen a través de la accesibilidad. Cuanto más robustos 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 se mantengan al día con el cambiante umbral de accesibilidad.
•••
La Administración de Servicios Generales de los Estados Unidos publicó recientemente suPlan de acción sobre equidad, especificando centrarse en la accesibilidad más allá de lo mínimo imprescindible para todos los servicios gubernamentales digitales. Este paso de una agencia federal indica a las empresas que tendrán que seguir su ejemplo y esforzarse por lograr una accesibilidad que supere los cambios inclusivos básicos. Pero superar lo mínimo exige una mentalidad diferente por parte de los desarrolladores. Muchas de las personas que tienen la tarea de volver a imaginar el listón de la accesibilidad dependen demasiado de un conjunto pequeño de herramientas que les dan una visión de túnel cuando construyen. Todos React, Vue y Svelte tienen la accesibilidad integrada, pero los desarrolladores que utilizan solo lo que está disponible se arriesgan a centrarse demasiado en lo único. Muchas herramientas priorizan los elementos visuales de la accesibilidad porque son los más visibles, 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 que los guíen a través de la accesibilidad. Cuanto más robustos sean los comprobadores de accesibilidad de los desarrolladores, mejor servirán a las personas con necesidades diversas. Llevo casi una década trabajando en el desarrollo y he dedicado los dos últimos años a esforzarme por crear herramientas que ayuden a los diseñadores y desarrolladores de software a incorporar la accesibilidad a su oficio. Así es como los desarrolladores pueden evitar recurrir a herramientas y directrices de accesibilidad inadecuadas y mantenerse al día con el cambiante umbral de accesibilidad. ## Mezcle y combine sus herramientas de accesibilidad. Cada plataforma de desarrollo tiene su propio conjunto de normas y requisitos de accesibilidad. Por ejemplo, los estándares de accesibilidad (a11y) de la Web se detallan en laPautas de accesibilidad al contenido web (WCAG), Apple usa Pautas de interfaz humana (HIG), y Android tiene el suyo propio conjunto de directrices. Bibliotecas web como Reaccionar yVue tienen secciones sobre las mejores prácticas de accesibilidad, al igual que bibliotecas de componentes específicos, comoReact Select yVue Select. Pero si los desarrolladores se limitan a seguir los parámetros de accesibilidad de la plataforma en la que están creando, es inevitable que dejen algunos vacíos de accesibilidad sin cubrir. Usar un solo conjunto de directrices es como esperar que una tabla de contenido le cuente toda la historia. La mejor manera de evitar este problema es mezclar y combinar herramientas y directrices. Si su marco se inclina más hacia la navegación visual, combínelo con el de Googleárbol de accesibilidad o de FirefoxInspector de accesibilidad, que ayudan a los desarrolladores a entender cómo se expone el contenido a la tecnología de asistencia. Si sus necesidades son principalmente para personas con problemas auditivos, pruebe los Orca lector de pantalla para escritorios como MATE, GNOME y Unity. ElSonar GNU/Linux el proyecto es ideal 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.Linteros son geniales para comprobar el código, aunquecomplementos a11y puede permitir escribir 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 únicamente herramientas de desarrollo: debates en RedditAccesibilidad web comunidad,Desbordamiento de pila y el de Slackcanal de accesibilidad puede indicarle los lugares que sus directrices originales no cubren. ## Aprenda de la legislación de accesibilidad localizada. Los desarrolladores deben adoptar una mentalidad global a la hora de crear productos y, a su vez, deben reconocer que el cumplimiento de la accesibilidad cambia según la ubicación. La accesibilidad es mucho más que traducir texto y copiar y pegar desde un marco que funcionaba en otros lugares. Lo que puede cumplir con la ley o ser inclusivo en un país probablemente sea diferente en otro. Por ejemplo, elLey de accesibilidad para los ontarianos con discapacidades (AODA) no tiene las mismas especificaciones que el Norma europea de accesibilidad digital (EN 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 que cumplan con las normas consultando exclusivamente 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 en tecnología— no mencionan la biometría. Es inevitable que algunos lugares tengan normas de accesibilidad más estrictas, 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 cumpla deben ser los mínimos que incorpore en toda su obra. No es solo un deber moral, sino una decisión empresarial inteligente. En algún momento, las normas van a evolucionar y lo que ahora se considera estricto pasará a ser 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 dediquen tiempo y dinero a solucionar los problemas de forma retroactiva. ## Descubra las áreas grises de los marcos independientes mediante pruebas con los usuarios. No existe un certificado de aptitud para la accesibilidad. Cuantos más productos o funciones introduzca, más tendrá que probar y más tendrá que ir más allá de las herramientas que utiliza para supervisar su accesibilidad. Incluso si no está publicando activamente, siempre hay margen de mejora, especialmente en los 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 se pueda acceder a los componentes básicos, pero eso no garantiza que el producto final lo sea. Los desarrolladores tienen la responsabilidad de probar el producto a medida que lo crean, 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 los productos y funciones repetidamente en persona o de forma remota con un grupo diverso de usuarios de diferentes capacidades, edades y orígenes. En Stark, hacemos las pruebas en persona siempre que es posible, pero también utilizamos Zoom para llevar a cabo sesiones de comentarios y asegurarnos de que se cumplen los subtítulos, la interpretación en lengua de signos y otras necesidades de los usuarios.Fábula es una plataforma brillante para involucrar a las personas con discapacidades 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 con los usuarios mostraron que los marcos no impiden que los desarrolladores tengan un orden de enfoque configurado incorrectamente para los usuarios del teclado. Solo aprendimos hablando con personas que utilizan la navegación por teclado para los sitios web. No hay un solo 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 tomarse como exhaustivos. Tienen que usarse junto con otras herramientas y pruebas para mantenerse al día (y seguir esforzándose por lograr) un listón de accesibilidad más alto.