Fundamentos de accesibilidad web que todo desarrollador debe conocer

Has creado un sitio web elegante con frameworks modernos, pero cuando un usuario que depende de un lector de pantalla intenta navegar, se pierde. O alguien que no puede usar un ratón encuentra que tu menú desplegable personalizado es imposible de abrir. La accesibilidad no es solo una casilla que marcar: es una parte fundamental del desarrollo web de calidad. En este artículo, aprenderás los principios básicos y las técnicas prácticas para que tus sitios sean usables por todos.

Por qué importa la accesibilidad

La accesibilidad (a menudo abreviada como a11y) garantiza que las personas con discapacidad puedan percibir, comprender, navegar e interactuar con la web. Esto incluye a personas con discapacidades visuales, auditivas, motoras y cognitivas. Más allá del imperativo ético, los sitios accesibles suelen posicionarse mejor en los motores de búsqueda, llegar a más audiencias y cumplir con requisitos legales como la ADA o las WCAG.

Además, las mejoras de accesibilidad benefician a todos los usuarios. Los encabezados claros, los atajos de teclado y el alto contraste ayudan a las personas bajo luz solar intensa, con conexiones lentas o con lesiones temporales en las manos. Se trata de diseño universal.

Principios fundamentales: POUR

Las Pautas de Accesibilidad para el Contenido Web (WCAG) se basan en cuatro principios, recordados fácilmente como POUR (por sus siglas en inglés):

• Perceptible: La información debe presentarse de manera que todos los usuarios puedan percibirla. Proporciona alternativas textuales para imágenes, subtítulos para videos y suficiente contraste de color.
• Operable: Los usuarios deben poder operar la interfaz. Asegúrate de que toda la funcionalidad esté disponible mediante teclado y da a los usuarios suficiente tiempo para leer el contenido.
• Comprensible: El contenido y la operación deben ser comprensibles. Usa un lenguaje claro, navegación predecible y asistencia para la entrada de datos.
• Robusto: El contenido debe funcionar con tecnologías de asistencia actuales y futuras. Escribe HTML válido y semántico.

Comienza con HTML semántico

La base de la accesibilidad es usar los elementos HTML correctos para cada propósito. Los lectores de pantalla dependen de la semántica de los elementos para transmitir significado. Un <button> se anuncia como botón y es enfocable por defecto; un <div> con un manejador de clic no lo es.

Elementos semánticos comunes que deberías usar:

• <nav> para bloques de navegación
• <main> para el contenido principal
• <h1>–<h6> para encabezados, en orden lógico
• <button> para acciones clicables
• <a> para enlaces
• <ul>, <ol>, <li> para listas
• <label> asociado con campos de formulario

Por ejemplo, en lugar de:

<div>Enviar</div>

Usa:

<button type="button">Enviar</button>

Este simple cambio hace que el control sea enfocable, anuncia su rol y permite la activación mediante teclado.

Navegación por teclado y gestión del foco

Muchos usuarios no pueden usar un ratón. Dependen de la tecla Tab para moverse por los elementos interactivos. Asegúrate de que:

• Todos los elementos interactivos sean accesibles mediante Tab.
• El orden de tabulación siga una secuencia lógica.
• El foco siempre sea visible (no elimines los contornos sin un reemplazo).
• Los widgets personalizados (como modales o menús desplegables) atrapen el foco adecuadamente y lo devuelvan al cerrarse.

Prueba tu sitio desconectando el ratón y navegando solo con el teclado. ¿Puedes acceder a todas las funciones?

ARIA: úsalo con precaución

Los atributos ARIA (Accessible Rich Internet Applications) pueden mejorar la accesibilidad cuando el HTML nativo no es suficiente. Sin embargo, la primera regla de ARIA es: no uses ARIA si puedes usar HTML nativo en su lugar. Por ejemplo, usa <button> en lugar de <div role="button">.

Cuando realmente necesites ARIA, los atributos comunes incluyen:

• aria-label para proporcionar una etiqueta cuando no hay texto visible disponible.
• aria-expanded para indicar si una sección plegable está abierta.
• aria-hidden="true" para ocultar elementos decorativos de los lectores de pantalla.
• role para definir el propósito de un elemento cuando no existe una etiqueta semántica.

Un ARIA incorrecto puede empeorar las cosas, así que prueba siempre con tecnologías de asistencia.

Color y contraste

Un contraste de color suficiente garantiza que el texto sea legible para personas con baja visión o daltonismo. Las WCAG recomiendan 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). Usa herramientas como el WebAIM Contrast Checker para verificarlo.

Además, nunca dependas solo del color para transmitir información. Por ejemplo, si usas rojo para indicar un error, incluye también un icono o un mensaje de texto.

Alternativas textuales para imágenes

Toda imagen debe tener un atributo alt. El valor depende del contexto:

• Si la imagen transmite información, descríbela de forma concisa: alt="Un triángulo rojo de advertencia".
• Si es decorativa, usa un alt vacío: alt="".
• Si es un gráfico complejo, proporciona una descripción más larga cerca o mediante aria-describedby.

La falta de texto alternativo es uno de los fallos de accesibilidad más comunes. También es fácil de solucionar.

Cómo probar la accesibilidad de tu sitio

Las herramientas automatizadas pueden detectar alrededor del 30% de los problemas. Las pruebas manuales son cruciales. Aquí tienes un flujo de trabajo práctico:

1. Ejecuta una auditoría automatizada: Usa axe DevTools, Lighthouse o WAVE para encontrar problemas obvios.
2. Prueba de teclado: Navega por tu sitio usando solo Tab, Shift+Tab, Enter y las teclas de flecha.
3. Prueba con lector de pantalla: Prueba VoiceOver (Mac), NVDA (Windows) u Orca (Linux). Escucha cómo se anuncia el contenido.
4. Zoom y contraste: Amplía al 200% y comprueba si el contenido sigue siendo usable. Verifica las relaciones de contraste.
5. Pruebas con usuarios: Siempre que sea posible, incluye a personas con discapacidad en las pruebas de usabilidad.

Errores comunes que debes evitar

• Usar div o span para botones y enlaces.
• Eliminar los contornos de foco sin proporcionar una alternativa.
• Añadir aria-hidden="true" a elementos enfocables.
• Usar texto de marcador de posición como única etiqueta para los campos de entrada.
• Reproducir medios automáticamente con sonido.
• Contraste de color insuficiente.

Referencia rápida: qué hacer y qué no

Preguntas frecuentes

¿Cuál es la diferencia entre WCAG A, AA y AAA?

Los niveles de conformidad de las WCAG indican una accesibilidad creciente. El nivel A es el mínimo, el AA es el estándar al que hacen referencia la mayoría de las leyes, y el AAA es el nivel más alto, a menudo poco práctico para todo el contenido. Apunta al AA.

¿Puedo usar ARIA para solucionar todos los problemas de accesibilidad?

No. ARIA solo debe usarse cuando el HTML nativo no puede proporcionar la semántica necesaria. Un ARIA incorrecto puede perjudicar la accesibilidad. Prioriza siempre el HTML semántico.

¿Cómo pruebo la accesibilidad de mi sitio web?

Combina herramientas automatizadas (como axe o Lighthouse) con comprobaciones manuales: navegación por teclado, pruebas con lector de pantalla y análisis de contraste de color. Involucra a usuarios con discapacidad cuando sea posible.

¿Listo para mejorar la accesibilidad de tu sitio? Empieza validando la estructura de tu HTML y comprobando problemas comunes. Para formatear y validar JSON rápidamente, prueba nuestro Formateador JSON para asegurarte de que tus datos estén limpios y bien estructurados.