Cuando una interfaz no funciona con teclado, la reacción habitual es buscar un atributo ARIA que “arregle” el componente. El orden correcto suele ser otro. Antes de describir un botón falso, conviene comprobar si puede ser un <button>; antes de añadir un nombre accesible manual, hay que revisar si el control ya tiene un texto visible; antes de ocultar un problema de foco, hay que observar el orden real de la página.
La accesibilidad web empieza por usar cada elemento HTML para el propósito que ya conoce el navegador. ARIA puede aportar semántica a patrones personalizados, pero no convierte automáticamente un div en un control completo. WCAG organiza la accesibilidad alrededor de contenido perceptible, operable, comprensible y robusto, y define criterios comprobables en niveles A, AA y AAA [1].
Semántica no es decoración
Un encabezado, una navegación, un formulario y un artículo no son solo cajas visuales. Comunican estructura a tecnologías de asistencia, herramientas de navegación y otros agentes que no interpretan la página como la ve una persona con mouse. El HTML semántico también ayuda a que el código revele la intención: <nav> identifica navegación, <main> delimita el contenido principal y <button> anuncia una acción.
| Necesidad | Primera opción | Pregunta de comprobación |
|---|---|---|
| Ir a otra URL | <a href> | ¿El usuario puede activar el enlace con teclado y entender su destino? |
| Ejecutar una acción | <button> | ¿El control recibe foco y responde a Enter o espacio según el navegador? |
| Introducir un dato | <label> asociado a un campo | ¿El nombre del campo se anuncia y se puede activar su control? |
| Agrupar contenido | <section>, <article> o listas | ¿La estructura representa una relación real? |
MDN resume esta idea como usar el elemento correcto para el trabajo correcto y destaca texto alternativo, enlaces claros, etiquetas de formularios, tablas con encabezados y accesibilidad por teclado [2]. No es una preferencia estética: es una forma de reducir problemas antes de añadir JavaScript.
El botón falso cobra una deuda
Este patrón puede parecer funcional:
<div class="boton" onclick="guardar()">Guardar</div>Con un mouse, quizás llame a la función. Pero el elemento no tiene de forma nativa el mismo comportamiento de teclado, semántica ni estados que un botón. La corrección más pequeña es:
<button type="button" onclick="guardar()">Guardar</button>Si el control envía un formulario, usa type="submit" y maneja el evento del formulario. Si abre una sección, el nombre debe explicar esa acción y el estado debe comunicarse. Añadir role="button" a un div puede describir una intención, pero no implementa por sí solo el comportamiento de teclado, foco, estados ni gestión de eventos que el control nativo ya ofrece.
El teclado revela el orden verdadero
Una página accesible no exige que el usuario encuentre una ruta alternativa escondida. Pulsa Tab desde el inicio y observa: ¿el foco aparece? ¿sigue una secuencia lógica? ¿entra en un menú que está visualmente cerrado? ¿se pierde dentro de un modal? La navegación por teclado es una prueba de comportamiento, no solo una comprobación de contraste.
- Recarga la página y no uses el mouse.
- Presiona Tab y Shift+Tab para recorrer los controles.
- Activa enlaces y botones con las teclas esperadas.
- Abre cualquier diálogo y comprueba dónde queda el foco.
- Cierra el diálogo y confirma que el foco vuelve a un lugar comprensible.
Evita quitar el contorno de foco con outline: none si no existe una alternativa visible. El usuario debe saber qué elemento está listo para recibir una acción. También conviene tener cuidado con tabindex: un valor positivo puede imponer un orden artificial que se vuelve difícil de mantener. En general, deja que el documento siga su orden natural.
Etiquetas: el nombre que el campo necesita
Un placeholder no reemplaza una etiqueta. Puede desaparecer cuando el usuario empieza a escribir y suele tener menor contraste. Una etiqueta visible permanece asociada al propósito del campo:
<label for="correo">Correo electrónico</label>
<input id="correo" name="correo" type="email" autocomplete="email">El valor de for debe coincidir con el id. En campos complejos, combina una descripción adicional con aria-describedby y comunica errores de forma visible. La regla no es agregar atributos porque una herramienta los sugiera: es hacer que la relación entre instrucción, campo, error y resultado sea entendible.
ARIA tiene un lugar, pero no es el primero
WAI-ARIA define una forma de aportar semántica a contenido y aplicaciones web, especialmente cuando se crean widgets que no tienen un equivalente nativo. El propio enfoque de buenas prácticas de accesibilidad favorece controles HTML nativos cuando resuelven la necesidad. Un componente personalizado exige más que un nombre: necesita roles, estados, propiedades, teclado, foco y cambios de estado coherentes.
| Orden de trabajo | Decisión | Resultado esperado |
|---|---|---|
| 1. HTML | ¿Existe un elemento nativo? | Usar su semántica y comportamiento. |
| 2. Estilo | ¿El control se ve y se distingue? | Conservar foco, contraste y estados visibles. |
| 3. Teclado | ¿Se puede operar sin mouse? | Definir activación, escape y movimiento del foco. |
| 4. ARIA | ¿Falta una relación o estado que el HTML no expresa? | Añadir solo la semántica necesaria y probarla. |
ARIA mal aplicada puede crear una descripción que contradice el comportamiento. Un elemento anunciado como botón, pero que no responde al teclado, da una promesa falsa. La accesibilidad no se mide por cuántos atributos aria-* aparecen en el inspector, sino por si la interacción es perceptible, operable, comprensible y robusta.
Imágenes, enlaces y tablas también forman la experiencia
Una imagen informativa necesita un texto alternativo que transmita su función o contenido. Una imagen puramente decorativa puede tener un texto alternativo vacío, no una frase repetitiva. Un enlace debe explicar su destino sin depender de “haz clic aquí”. Una tabla debe tener encabezados que hagan comprensible la relación entre filas y columnas.
Estas decisiones parecen pequeñas, pero cambian lo que una persona puede hacer con el contenido. En un tutorial dirigido a principiantes, además, hacen que el HTML sea más fácil de leer. Puedes conectar esta revisión con el significado de las etiquetas HTML y con la separación de responsabilidades entre HTML, CSS y JavaScript.
Un registro de riesgos para revisar una página
| Riesgo | Impacto | Mitigación inicial |
|---|---|---|
Control visual construido con div | Puede quedar fuera del teclado o sin semántica. | Sustituir por enlace o botón nativo. |
| Foco eliminado | El usuario no sabe dónde actuará. | Mantener un indicador visible y probar Tab. |
| Campo sin label | El propósito puede no anunciarse. | Asociar label, for e id. |
| Modal sin gestión de foco | La navegación se pierde en el fondo. | Enfocar el diálogo, limitar el recorrido y devolver el foco. |
| ARIA que contradice el control | La interfaz anuncia una promesa falsa. | Eliminar el atributo o implementar el patrón completo. |
La matriz no sustituye una evaluación completa de WCAG. Sirve para ordenar la primera inspección y evitar que el equipo salte directamente a una solución compleja.
Cómo encaja con responsive y estructura del proyecto
La accesibilidad no termina en el HTML, pero tampoco puede ser reparada por CSS. Un diseño responsivo debe conservar legibilidad, orden y controles operables cuando cambia el ancho de pantalla. Los breakpoints deberían aparecer cuando el contenido se rompe, como explica esta guía sobre diseño responsivo. La estructura de carpetas también importa cuando separa componentes y estilos sin esconder el comportamiento que hay que probar; revisa una ruta para organizar un proyecto web.
Una prueba manual en cuatro pasadas
Una revisión útil no empieza por perseguir una puntuación perfecta. Empieza por observar el recorrido que una persona debe completar. Divide la prueba en cuatro pasadas y anota el obstáculo, el elemento implicado y una corrección concreta.
- Contenido. Lee la página sin mirar el código. Comprueba que los encabezados describan las secciones, que los enlaces expliquen su destino y que las instrucciones no dependan solo del color, la posición o una imagen.
- Teclado. Repite el flujo con Tab, Shift+Tab, Enter, espacio y Escape cuando corresponda. Registra los controles que no reciben foco, los que aparecen fuera de orden y los que no ofrecen una forma clara de cerrar o volver.
- Estructura. Inspecciona si el HTML usa landmarks, encabezados y controles nativos. Un problema de estructura suele ser más barato de corregir antes de añadir una capa de JavaScript o una colección de atributos ARIA.
- Estado. Provoca un error, una carga, un mensaje de éxito y un cambio de contenido. Comprueba que el usuario pueda percibir qué ocurrió y qué debe hacer después, incluso si no estaba mirando el punto exacto que cambió.
Este procedimiento no certifica conformidad con WCAG ni sustituye pruebas con usuarios y tecnologías de asistencia. Sí crea una primera línea de control que un principiante puede repetir en cada ejercicio. También genera evidencia para decidir qué corregir primero: un botón que no puede operarse suele tener una prioridad distinta de una mejora cosmética.
Mensajes, estados y movimiento del foco
La accesibilidad también se rompe después del clic. Un formulario puede mostrar un error en rojo, pero si el mensaje no está relacionado con el campo o el foco queda perdido, la persona no recibe una ruta clara. Vincula las instrucciones y los errores con el control, mantén el texto visible y evita que un cambio de contenido elimine silenciosamente lo que el usuario estaba leyendo.
En un diálogo, define qué ocurre al abrir, mientras está abierto y al cerrarlo. El foco debe llegar a un elemento útil; el teclado no debería escapar accidentalmente a contenido que está detrás; al cerrar, la persona debería volver al control que abrió el diálogo o a una ubicación equivalente. Cuanto más personalizado sea el componente, más comportamiento debes implementar y probar.
Para un proyecto pequeño, escribe estos estados como una tabla de decisión: qué acción inicia el cambio, qué texto aparece, qué elemento recibe foco y cómo se deshace la operación. Esa documentación conecta la semántica con el comportamiento y evita que la accesibilidad quede reducida a una revisión al final del trabajo.
\n
Preguntas frecuentes
¿ARIA hace accesible cualquier elemento?
No. ARIA puede aportar semántica, pero no añade automáticamente teclado, foco, estados ni lógica. Si existe un elemento nativo adecuado, suele ser la primera opción.
¿Una página es accesible si pasa una herramienta automática?
No necesariamente. Las herramientas detectan algunos patrones, pero la navegación por teclado, la claridad de los textos y la coherencia de estados requieren pruebas humanas.
¿El placeholder reemplaza al label?
No. El placeholder es una pista temporal; la etiqueta identifica de manera estable el propósito del campo y facilita su uso.
¿WCAG obliga a usar siempre nivel AAA?
WCAG define niveles A, AA y AAA. La conformidad aplicable depende del contexto y de los requisitos del proyecto; este artículo no constituye asesoría legal ni determina obligaciones para un sitio específico en Chile.
Próximo paso: toma una página pequeña, reemplaza un control visual falso por el elemento nativo correspondiente y repite la prueba con Tab. Si la interfaz se vuelve más clara sin agregar ARIA, encontraste la mejora correcta.
Fuentes: W3C WAI: WCAG 2 Overview y MDN: HTML, una buena base para la accesibilidad.
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.