Cómo dejar de adivinar al crear interfaces accesibles
¿Alguna vez te has preguntado por qué un botón ordinario en la web a veces se comporta de forma extraña cuando intentas hacer clic con el teclado? ¿O por qué un lector de pantalla de repente empieza a balbucear tonterías cuando abres un modal? Por lo general, el problema está en los atributos ARIA. Estamos acostumbrados a añadirlos "a ojo," esperando que aria-label o role="button" mágicamente corrijan los problemas de semántica. Pero la accesibilidad no es magia — son patrones de interacción estrictos.
En el repositorio w3c/aria-practices se encuentra lo que yo llamo la "biblia del desarrollador frontend." No es solo una especificación aburrida, sino una Guía de Prácticas de Creación (APG) viva que explica exactamente cómo deberían funcionar los menús desplegables, las pestañas, los deslizadores y los acordeones para que absolutamente cualquier persona pueda usarlos.
De qué trata este proyecto
El proyecto es dirigido por un grupo de trabajo del W3C. Esencialmente, estas son las personas que inventan los estándares web. En el repositorio, recopilan ejemplos de referencia de implementaciones de patrones de interfaz. Si no sabes si el foco debe volver al botón después de cerrar un modal, o qué teclas de flecha deberían cambiar las pestañas — aquí es donde debes buscar.
Muchos desarrolladores todavía consideran la accesibilidad (a11y) algo opcional. Pero cuando un proyecto crece, la falta de una navegación adecuada por teclado se convierte en deuda técnica. Este repositorio ayuda a eliminar esa deuda en la etapa de diseño de componentes.
Qué ofrece este repositorio
Dentro encontrarás no solo reglas secas, sino ejemplos de código funcionales. Aquí tienes algunas cosas a las que constantemente recurro en este proyecto.
Patrones de diseño listos para usar
Para cada elemento complejo (por ejemplo, Combobox o Vista de Árbol), hay una sección separada. Describe el comportamiento esperado del teclado y los roles requeridos. Esto elimina la necesidad de reinventar la rueda. Simplemente tomas la lista de requisitos y verificas tu componente contra ellos.
Ejemplos de código de referencia
En la carpeta examples, hay implementaciones en HTML, CSS y JavaScript puros. No hay abstracciones innecesarias, ni React, ni Vue — solo la lógica de accesibilidad sin procesar. Esto es útil cuando necesitas entender cómo enlazar elementos id a través de aria-controls o aria-labelledby para que el lector de pantalla anuncie correctamente el contexto.
Pruebas y linting
Curiosamente, los autores usan linting estricto. Validan HTML a través del NU HTML Validator, y JS y CSS a través de ESLint y Stylelint estándar. Si decides contribuir al proyecto, necesitarás instalar el JDK para el validador de HTML. Esto muestra el nivel de seriedad: incluso en los ejemplos de código, no se permite ni un solo error de validación.
Cómo usar esto en tu trabajo
Uso frecuentemente este repositorio como lista de verificación. Por ejemplo, estoy escribiendo un select personalizado. En lugar de buscar en Google "cómo hacer un select accesible," voy a APG y miro la sección de Combobox de solo selección.
Ahí encuentro:
- Qué atributos necesita el elemento padre.
- Cómo gestionar el estado
aria-expanded. - Qué debería pasar al presionar las teclas Inicio, Fin o RePág.
Por cierto, el repositorio tiene scripts para pruebas automatizadas de ejemplos. El comando npm test ejecuta pruebas que verifican el comportamiento de los elementos en el navegador. Este es un gran ejemplo de cómo puedes automatizar las pruebas de accesibilidad en tus propios proyectos.
El lado técnico
El proyecto funciona con Node.js. Para trabajar con él localmente, necesitarás:
- Node.js y npm para ejecutar linters y pruebas.
- JDK (Java Development Kit) para validación de HTML.
Punto interesante: el proyecto tiene corrección automática de errores configurada al hacer commit. Si arruaste los espacios en CSS u olvidaste camelCase en JavaScript, el linter intentará corregirlo por sí mismo antes de dejar que el código entre al repositorio.
Quién debería revisar aria-practices
En primer lugar — los desarrolladores de bibliotecas de componentes. Si estás escribiendo tu propio sistema de diseño, ignorar estas prácticas simplemente no es una opción. El proyecto también es útil para ingenieros de QA: aquí puedes encontrar exactamente cómo debería comportarse una interfaz al probar accesibilidad.
No diré que leer este repositorio sea un entretenimiento ligero por la noche. Los textos son secos, y hay muchos requisitos. Pero es la única forma de construir interfaces que realmente funcionen para todos, no solo para quienes usan un ratón.
Si estás cansado de que tus modales "vuelen" al final de la página cuando se cierran, o quieres finalmente entender para qué sirve aria-live, simplemente clona este repositorio y mira cómo lo hacen los profesionales del W3C. Enlace al proyecto: w3c/aria-practices.
Proyectos relacionados