Una lista de comprobación breve y opinada para botones web accesibles

El problema con los consejos sobre accesibilidad de botones

La mayor parte de la orientación sobre accesibilidad de botones cae en dos extremos: o es una interpretación de WCAG de 40 páginas que nadie lee, o es una sugerencia vaga de "hacer que los botones sean accesibles" sin pasos accionables. Ninguna ayuda cuando tienes que publicar una funcionalidad el jueves.

Esta lista de comprobación cubre los cinco fallos de accesibilidad en botones más comunes que vemos en producción. No te convertirá en experto en WCAG, pero detectará los problemas que realmente afectan a los usuarios.

1. Usa el elemento button para los botones

Si actúa como un botón, debería ser un elemento <button>. No un <div> con onclick, no un <span> con role="button", no un <a> con href="#" y preventDefault.

El elemento <button> te da navegación por teclado, gestión del foco y anuncios para lectores de pantalla sin coste adicional. Cuando usas un <div>, estás reconstruyendo todo eso desde cero — y lo harás mal.

La única excepción: si la acción navega a una página nueva o cambia la URL, usa un elemento <a>. Los enlaces y los botones son semánticamente diferentes. Los usuarios de lectores de pantalla navegan por tipo de elemento, y esperan que los botones realicen acciones y que los enlaces naveguen.

2. Haz que el área de interacción sea de al menos 44×44 píxeles

WCAG 2.5.5 (Nivel AAA) exige que los elementos interactivos tengan un tamaño mínimo de objetivo de 44×44 píxeles CSS. No se trata del tamaño visual — se trata del área clicable.

Puedes tener un botón visualmente pequeño con suficiente padding, o puedes ampliar el área de interacción con un pseudoelemento. Lo importante es que el usuario no tenga que apuntar con precisión.

Los usuarios móviles, las personas con dificultades motoras y cualquiera que use un dispositivo en movimiento fallarán con objetivos pequeños. Un botón de icono de 24×24 píxeles puede verse limpio, pero es un fallo de usabilidad.

3. Proporciona estados de foco visibles que no sean solo los valores predeterminados del navegador

El anillo de foco predeterminado del navegador es mejor que nada, pero es inconsistente entre navegadores y a menudo resulta invisible sobre ciertos fondos. Necesitas un estado de foco personalizado que funcione en tu sistema de diseño.

Un buen indicador de foco tiene tres cualidades:

• Alto contraste: al menos 3:1 frente a los colores adyacentes
• Desplazamiento visible: no queda oculto por el borde o el fondo del propio botón
• Forma consistente: los usuarios deberían reconocerlo como indicador de foco en toda tu interfaz

No uses outline: none sin sustituirlo por algo mejor. Y no hagas que los estados de foco sean tan sutiles que solo tú puedas verlos en condiciones de iluminación perfectas.

4. Escribe etiquetas de botones que tengan sentido fuera de contexto

Los usuarios de lectores de pantalla a menudo navegan saltando entre botones. Cuando lo hacen, escuchan una lista de etiquetas de botones sin contexto alrededor.

Un botón etiquetado como "Más información" es inútil en esa lista. También lo son "Haz clic aquí" o "Enviar". La etiqueta debería describir la acción: "Descargar la lista de comprobación de accesibilidad", "Suscribirse a las actualizaciones", "Eliminar este comentario".

Si tu diseño requiere una etiqueta visual corta, usa aria-label para proporcionar una alternativa descriptiva. Pero la mejor solución es escribir etiquetas que funcionen para todos.

Para botones solo con icono, aria-label es obligatorio. Un botón con solo un icono de lupa necesita aria-label="Search" o un texto equivalente. El icono no es accesible para los lectores de pantalla.

5. Asegura suficiente contraste de color

WCAG 2.1 exige una relación de contraste de al menos 4.5:1 para texto normal y 3:1 para texto grande (18pt o 14pt en negrita). Las etiquetas de los botones suelen ser texto normal.

Texto gris claro sobre un botón blanco falla. Azul pálido sobre un fondo azul claro falla. Estas combinaciones pueden parecer sofisticadas, pero excluyen a usuarios con baja visión, daltonismo o a cualquiera que vea la pantalla bajo luz solar intensa.

Usa un comprobador de contraste durante el diseño, no después del lanzamiento. Corregir problemas de contraste en producción es caro porque a menudo requiere cambios en el sistema de diseño.

Si trabajas con herramientas de procesamiento de imágenes, el procesamiento del lado del cliente puede ayudar a preservar la privacidad al generar recursos visuales accesibles — especialmente al probar combinaciones de colores o generar estados de vista previa.

Lo que esta lista de comprobación no cubre

Esta lista es deliberadamente incompleta. No cubre la semántica de los estados deshabilitados, los estados de carga, la gestión de errores ni patrones de botones complejos como botones divididos o activadores de menús desplegables. Esos patrones necesitan su propia orientación.

Tampoco cubre la pregunta más amplia de cuándo usar un botón frente a otros elementos interactivos. Para eso, necesitas entender el HTML semántico y el árbol de accesibilidad — temas que merecen sus propios artículos.

Lo que sí cubre es lo más fácil de solucionar: los errores que aparecen en casi todas las revisiones de código, que afectan a más usuarios y que son más sencillos de corregir durante el desarrollo.

Cómo integrar esto en tu flujo de trabajo

Las listas de comprobación de accesibilidad solo funcionan si forman parte del proceso de desarrollo, no si se añaden después. Así es como puedes conseguirlo:

En diseño: añade estados de foco y anotaciones de área de interacción a tus archivos de diseño. No dejes que los desarrolladores tengan que adivinarlos.

En revisión de código: comprueba que haya elementos <button>, aria-label en botones de icono y CSS para estados de foco. Son cosas rápidas de detectar.

En pruebas: recorre tu interfaz con el teclado usando la tecla Tab. Si no puedes llegar a un botón o no puedes ver dónde está el foco, tus usuarios tampoco podrán.

En documentación: incluye los requisitos de accesibilidad de botones en tu biblioteca de componentes. Haz que sea más fácil hacer lo correcto que hacer lo incorrecto.

Si estás depurando problemas en producción, las herramientas para inspeccionar encabezados HTTP y redirecciones pueden ayudarte a entender cómo las tecnologías de asistencia interpretan tu marcado — especialmente al investigar problemas de gestión del foco después de la navegación.

El coste de saltarse este trabajo

Los botones inaccesibles no solo incumplen WCAG — rompen flujos de trabajo. Un usuario que no puede hacer clic en un botón de envío no puede completar un formulario. Un usuario que no puede ver los estados de foco no puede navegar con teclado. Un usuario que no puede distinguir el texto del botón del fondo no puede leer la etiqueta.

No son casos extremos. Aproximadamente el 15% de la población mundial tiene algún tipo de discapacidad, y las limitaciones temporales (ratón roto, luz solar intensa, sostener a un bebé) acaban afectando a todo el mundo.

La buena noticia es que la accesibilidad de botones está formada en su mayoría por problemas ya resueltos. No necesitas inventar patrones nuevos ni esperar soporte del navegador. Solo necesitas usar la plataforma correctamente y probar tu trabajo.

Puntos clave

• Usa elementos <button> para botones y elementos <a> para navegación — la diferencia semántica importa para la tecnología de asistencia
• Asegura que las áreas de interacción sean de al menos 44×44 píxeles CSS para adaptarse a personas con dificultades motoras y a usuarios móviles
• Proporciona estados de foco visibles y de alto contraste que funcionen en todo tu sistema de diseño
• Escribe etiquetas de botones que tengan sentido cuando se lean de forma aislada, y usa aria-label para botones solo con icono
• Comprueba el contraste de color durante el diseño, no después del lanzamiento, para evitar correcciones costosas

FAQ

P: ¿Puedo usar role="button" en un <div> si añado manejadores de teclado?

R: Puedes, pero no deberías. Tendrás que gestionar Enter, Space, la gestión del foco y los estados deshabilitados manualmente — e inevitablemente se te escapará algo. El elemento <button> hace todo esto correctamente de forma predeterminada. Úsalo.

P: ¿Qué pasa con los botones que alternan estado, como un botón de reproducir/pausar?

R: Usa aria-pressed="true" o aria-pressed="false" para indicar el estado actual. La etiqueta del botón también debería reflejar la acción que ocurrirá al hacer clic ("Pausar" cuando se está reproduciendo, "Reproducir" cuando está en pausa), no el estado actual. Los usuarios de lectores de pantalla necesitan saber qué hará el botón, no en qué estado está el sistema.

P: ¿Los botones deshabilitados deben cumplir los requisitos de contraste?

R: WCAG 2.1 exime a los controles deshabilitados de los requisitos de contraste (1.4.3), pero esto es controvertido. Los botones deshabilitados con poco contraste son difíciles de percibir para todo el mundo. Si vas a mostrar un botón deshabilitado, haz que sea legible. Mejor aún, ocúltalo o explica por qué está deshabilitado.

P: ¿Cómo pruebo la accesibilidad de botones sin un lector de pantalla?

R: Usa el teclado. Recorre la interfaz con Tab y verifica que puedes llegar a todos los botones, ver dónde está el foco y activar los botones con Enter o Space. Esto detecta la mayoría de los problemas. Para pruebas más profundas, usa el inspector de accesibilidad en Chrome o Firefox DevTools para comprobar el rol y la etiqueta calculados.

P: ¿Cuál es la diferencia entre aria-label y aria-labelledby?

R: aria-label proporciona una cadena de texto directamente. aria-labelledby referencia el ID de otro elemento cuyo contenido de texto se convierte en la etiqueta. Usa aria-labelledby cuando el texto de la etiqueta ya exista en otro lugar del DOM. Usa aria-label cuando necesites proporcionar una etiqueta que no sea visible en pantalla.

Fuentes

• Web Content Accessibility Guidelines (WCAG) 2.1 — W3C
• Inclusive Components: Toggle Buttons — Heydon Pickering
• The ARIA Button Pattern — W3C ARIA Authoring Practices Guide
• WebAIM: Keyboard Accessibility — WebAIM