Hay una escena que se repite en muchos primeros proyectos web: alguien descubre ARIA, añade varios atributos a un componente construido con <div> y siente que la accesibilidad quedó resuelta. El resultado puede tener más código y seguir siendo más difícil de usar. La razón no es que ARIA sea inútil. Es que se está intentando reparar con una capa descriptiva un problema que comenzó al elegir el elemento equivocado.
La tesis de esta guía es concreta: la accesibilidad web empieza por la estructura y el comportamiento nativos de HTML; después se verifica con teclado, foco, contraste y tecnología asistiva; solo entonces se añade ARIA cuando el HTML no expresa por sí solo el patrón que necesitas. Esta secuencia coincide con la orientación de MDN sobre ARIA y se puede contrastar con los criterios normativos de WCAG 2.2 del W3C. No es una preferencia estética: es una forma de reducir reparaciones frágiles.
El primer experimento: dos elementos que parecen botones
Compara estos dos fragmentos:
<div class="button" onclick="enviarFormulario()">Enviar</div>
<button type="submit">Enviar</button>Visualmente puedes hacer que ambos parezcan idénticos con CSS. Semánticamente y en la interacción, no son equivalentes. El elemento button ya participa en el orden de teclado, expone su función al navegador y puede integrarse con un formulario. El div es un contenedor genérico: para convertirlo en un control tendrías que reconstruir foco, teclado, estados y comportamiento, y aun así podrías olvidar un detalle.
Este ejemplo no significa que cada div sea un error. Los contenedores son útiles para agrupar contenido. El problema aparece cuando un elemento genérico recibe una responsabilidad que HTML ya sabe expresar de forma más completa. La página de accesibilidad de MDN parte de una idea similar: muchas mejoras importantes consisten en usar correctamente las capacidades que ya existen en la plataforma.
Capa 1: deja que el documento cuente su propia historia
Un lector de pantalla, un navegador y una persona que navega rápidamente no leen una página de la misma manera. Los encabezados, landmarks y controles nativos proporcionan señales que permiten orientarse. Un <nav> comunica navegación; un <main> identifica el contenido principal; un <button> anuncia una acción; un <label> conecta una instrucción con un campo.
El orden de los encabezados también importa. No tienes que usar un encabezado solo porque el diseño lo hace grande, ni saltar de h2 a h4 para conseguir un tamaño visual. La jerarquía debe reflejar la relación entre ideas. Si ya trabajaste con etiquetas HTML esenciales, puedes revisar cada sección preguntando qué función cumple y qué elemento nativo la expresa con menos código.
La semántica no arregla todo. Una página con HTML correcto todavía puede tener un contraste insuficiente, un foco invisible o un flujo de teclado imposible. Pero comenzar con estructura nativa reduce el número de problemas que tendrás que resolver manualmente. Es una inversión en comportamiento heredado del navegador.
Capa 2: el teclado revela lo que el mouse oculta
Haz una prueba sencilla: cierra el mouse y navega con Tab, Shift+Tab, Enter y la barra espaciadora. ¿Puedes llegar a cada control? ¿El foco se mueve en un orden que tiene sentido? ¿Puedes abrir y cerrar el menú? ¿Puedes abandonar un diálogo sin quedarte atrapado? Si una función solo existe al pasar el cursor, una parte de las personas usuarias no tiene acceso a ella.
El foco no es un detalle decorativo. Es la posición actual de la interacción. Quitar el contorno con outline: none sin reemplazarlo puede hacer que la persona pierda la referencia de dónde está. Cambiar el foco de forma intencional puede ser correcto en un diálogo o una navegación dinámica, pero debe seguir el modelo mental de quien utiliza la interfaz.
La navegación por teclado también descubre un problema de orden. Si el DOM coloca el botón de compra antes de la explicación que lo justifica, la lectura puede resultar confusa aunque el diseño visual los coloque al revés. Antes de usar tabindex positivo para “arreglar” la secuencia, revisa el orden real del HTML. Los valores positivos suelen crear una segunda ruta difícil de mantener; el orden del documento suele ser una solución más robusta.
Capa 3: texto, imágenes y formularios deben aportar contexto
El texto alternativo no es una descripción automática de cada píxel. Su objetivo es transmitir el propósito de la imagen en ese contexto. Una foto decorativa puede tener un alt vacío para que la tecnología asistiva no interrumpa la lectura. Una imagen que explica un gráfico necesita comunicar la información relevante, quizá junto con una descripción más extensa. Copiar el nombre del archivo o escribir “imagen de imagen” no ayuda.
Los formularios presentan un patrón muy común de pérdida de contexto. Un placeholder no sustituye a una etiqueta: desaparece cuando escribes y puede tener un contraste bajo. Usa label asociado al campo, explica el formato esperado y anuncia el error junto al control correspondiente. Si el campo es obligatorio, no dependas solo de un color o de un asterisco cuyo significado nunca explicaste.
Un error útil responde tres preguntas: qué ocurrió, dónde ocurrió y cómo corregirlo. “Campo inválido” deja demasiado trabajo a la persona. “Escribe un correo con formato nombre@dominio.com” es más accionable. La accesibilidad y la calidad de la interfaz convergen aquí, pero el motivo principal sigue siendo que una persona pueda completar la tarea sin adivinar.
Capa 4: el contraste no se arregla con intuición
El contraste se suele evaluar tarde, cuando la paleta visual ya está aprobada. Es mejor tratarlo como una restricción desde el comienzo. El texto gris claro sobre un fondo blanco puede parecer elegante en tu monitor y resultar ilegible para otra persona, para alguien en una pantalla con reflejos o para quien tiene una discapacidad visual. WCAG 2.2 define criterios de contraste y otros requisitos verificables; no basta con declarar que “se ve bien”.
Las herramientas automáticas pueden detectar muchas combinaciones problemáticas, pero no reemplazan la prueba de contenido real. Comprueba el estado de foco, los mensajes de error, los botones deshabilitados y los textos sobre imágenes. Un color puede cumplir en una tarjeta y fallar cuando el contenido cambia de longitud o aparece junto a una fotografía.
En proyectos pequeños, crea una lista de colores con su uso: texto principal, texto secundario, borde, foco, éxito y error. Después revisa si cada color comunica algo que también aparece en texto o en estructura. Si el único indicador de error es que el borde se vuelve rojo, la interfaz depende de una señal que no todas las personas perciben.
Capa 5: ARIA complementa; no borra el HTML incorrecto
ARIA permite comunicar roles, propiedades y estados cuando una interfaz personalizada necesita información que HTML nativo no ofrece directamente. Un componente de pestañas, un árbol de navegación o un diálogo dinámico pueden requerir atributos y relaciones específicas. Pero añadir role="button" a un div no le entrega automáticamente el comportamiento completo de un botón. Todavía tendrías que programar activación con teclado, foco, estados y respuesta coherente.
Por eso la pregunta no debería ser “¿qué atributo ARIA falta?”. Debería ser “¿existe un elemento nativo que ya expresa esta función?”. Si la respuesta es sí, usa ese elemento. Si no, estudia el patrón y sus obligaciones. La documentación de MDN sobre ARIA es útil precisamente porque describe ARIA como un conjunto de semánticas para mejorar la accesibilidad de widgets y aplicaciones, no como una decoración universal para cualquier nodo.
También evita agregar roles que contradicen el comportamiento nativo. Un elemento con una semántica incorrecta puede confundir a lectores de pantalla y a las herramientas de prueba. El atributo debe describir lo que el componente realmente hace, y el código debe mantener ese estado cuando la interacción cambia. ARIA sin comportamiento es una promesa que la interfaz no cumple.
Un orden de prueba que evita falsos positivos
Una auditoría automática es un punto de partida, no un certificado de accesibilidad. Para un componente nuevo, sigue una secuencia que empiece por lo más barato de comprobar y avance hacia la experiencia.
- Inspecciona el HTML: confirma que el elemento elegido corresponde a su función, que existe una jerarquía de encabezados y que los campos tienen etiquetas.
- Usa solo el teclado: recorre el flujo, activa controles, cierra overlays y observa el foco visible.
- Amplía el texto: aumenta el zoom y comprueba que no se corta información ni desaparecen controles.
- Prueba estados: carga, vacío, error, éxito, deshabilitado y contenido largo suelen revelar problemas ausentes en la pantalla ideal.
- Ejecuta una herramienta automática: úsala para encontrar contrastes, nombres accesibles, relaciones y otros patrones que puede verificar.
- Haz una prueba con tecnología asistiva cuando sea posible: escucha el nombre, rol y estado de los controles, no solo si aparecen en el DOM.
Esta lista no es un sustituto de una evaluación formal, pero cambia la relación con las herramientas. En lugar de perseguir una puntuación, obtienes hipótesis de trabajo. La guía de web.dev sobre accesibilidad reúne prácticas y pruebas que pueden complementar este recorrido, especialmente cuando quieras pasar de un ejemplo aislado a una página completa.
Cuatro reparaciones que conviene hacer antes de añadir atributos
| Problema visible | Primera solución a intentar | Por qué no empezar por ARIA |
|---|---|---|
| Elemento clicable sin teclado | Usar button o a según la acción | El elemento nativo ya trae interacción y semántica |
| Campo sin nombre | Asociar un label visible | Un placeholder desaparece y no sustituye la etiqueta |
| Menú sin estructura | Ordenar el DOM y usar nav cuando corresponda | Un rol no corrige un flujo de foco confuso |
| Error indicado solo con rojo | Añadir mensaje de texto y relación con el campo | El color aislado no comunica a todas las personas |
Si la base está bien y todavía falta describir un estado, entonces ARIA tiene un lugar claro. Documenta qué estado representa cada atributo y qué acción lo modifica. Esa trazabilidad es más útil que copiar una receta desde un componente distinto.
Qué significa “accesible” en un proyecto de principiante
No necesitas construir un lector de pantalla para empezar a trabajar con accesibilidad. Necesitas dejar de tratarla como una fase posterior y observar si la persona puede completar la tarea. Un formulario de contacto pequeño ya permite practicar nombres, etiquetas, foco, mensajes de error, contraste y orden. Una navegación permite practicar landmarks, encabezados y escape del menú. Un modal obliga a pensar en foco y cierre.
También debes aceptar que ninguna herramienta te dirá todo. Un informe automático puede marcar un contraste, pero no entender que el texto principal es ambiguo. Puede confirmar que existe un alt, pero no si comunica el propósito. Puede detectar un nombre accesible, pero no si el foco salta de forma desconcertante. La verificación humana no es un lujo opcional; es la parte que conecta el código con la experiencia.
Para seguir construyendo una base, puedes revisar nuestras guías de propiedades CSS esenciales y diseño responsivo. La accesibilidad no vive en una etiqueta aislada: depende de la relación entre contenido, presentación, interacción y estados.
La decisión correcta suele ser la menos espectacular
Usar HTML nativo no produce una captura llamativa. No añade una lista larga de atributos y no parece una técnica avanzada. Sin embargo, ofrece un punto de partida que el navegador y las tecnologías asistivas ya entienden. La mejor pregunta para cada componente es sencilla: ¿puedo expresar esta función con un elemento nativo, mantener un orden de teclado lógico y comprobar sus estados? Si la respuesta es no, investiga la solución adicional. Si la respuesta es sí, no introduzcas complejidad solo para demostrar que conoces ARIA.
El próximo paso puede ser pequeño: reemplaza un div que actúa como botón, prueba el formulario solo con teclado y revisa un mensaje de error con el zoom aumentado. Esas observaciones valen más que una promesa genérica de “hacer la web inclusiva”. La accesibilidad mejora cuando la interfaz deja de pedirle a la persona que adivine.
Respuestas para no convertir la accesibilidad en una checklist ciega
¿ARIA mejora cualquier elemento HTML? No. ARIA puede aportar semántica a patrones que HTML no cubre, pero no añade automáticamente teclado, foco ni comportamiento. Siempre que exista un elemento nativo adecuado, suele ser el primer camino.
¿Puedo confiar solo en Lighthouse u otra herramienta automática? No. Las herramientas encuentran problemas verificables automáticamente, pero no juzgan toda la claridad del contenido, el orden mental del flujo o la calidad de una descripción. Combina automatización con teclado, zoom y pruebas de estados.
¿El texto alternativo debe describir cada detalle de una imagen? Debe comunicar el propósito de la imagen en su contexto. Una imagen decorativa puede usar un alt vacío; una imagen informativa necesita transmitir el dato relevante, no una lista indiscriminada de detalles.
Martin Rojas escribe sobre tecnología, programación y desarrollo web. En Skydutz Academy comparte explicaciones prácticas sobre herramientas digitales, conceptos de programación y recursos para aprender de forma progresiva. Su objetivo es hacer que los temas técnicos sean más claros, útiles y accesibles para lectores de distintos niveles.