Actualizado: .

HTML comunica al navegador y a las tecnologías de apoyo qué hay en la página y cómo interactuar con ello. Primero elija un elemento con el comportamiento adecuado. Después asegure nombres claros, foco visible y una maquetación que se adapte de forma fiable.

La acción determina si hace falta un botón o un enlace

Un enlace con href lleva a un recurso o a un lugar del documento. Un botón realiza una acción: abrir un diálogo, cambiar un estado o enviar un formulario. El aspecto no cambia su función. Un enlace puede parecer un botón grande y seguir siendo un enlace.

<!-- Enlace a una sección de este artículo -->
<a href="#focus">Ir a la comprobación del foco</a>

<!-- Acción que no envía el formulario -->
<button type="button">Abrir filtros</button>

<!-- Envío del formulario -->
<button type="submit">Enviar solicitud</button>

Un div con un manejador de click no obtiene automáticamente el rol de botón, un lugar en la secuencia de Tab ni la activación esperada mediante teclas. Añadir role="button" no basta: hay que implementar el comportamiento por separado. Un button nativo evita buena parte de ese trabajo.

La semántica ayuda a orientarse

Utilice main para el contenido principal, nav para una región de navegación y encabezados para la estructura del documento. No convierta cada grupo de enlaces en una región de navegación independiente. Si hay varias, asígneles nombres diferentes, como «Navegación principal» y «Secciones del artículo».

nav tiene el rol implícito navigation. Por eso <nav role="navigation"> suele ser redundante. Asignar el mismo rol a un div no hace que todos los elementos HTML sean intercambiables: la semántica nativa es más fácil de mantener y depende menos de añadidos manuales.

ARIA complementa la interfaz, pero no la arregla automáticamente

El texto visible de un botón normalmente ya proporciona su nombre accesible. Un botón que solo contiene un icono necesita un nombre; para un campo, es preferible un label asociado. No sustituya una etiqueta visible clara por un aria-label completamente distinto: a una persona que usa control por voz le costará dirigirse al elemento con las palabras que ve.

aria-expanded comunica si un elemento está desplegado y debe coincidir con su estado real. aria-hidden="true" excluye contenido del árbol de accesibilidad, pero no lo oculta visualmente ni lo elimina automáticamente de la secuencia del teclado. No lo aplique a un control que pueda recibir el foco ni a sus antecesores.

El foco debe ser visible y predecible

Eliminar outline «porque no encaja con el diseño» es un mal punto de partida. Primero diseñe un indicador de foco claramente distinguible y compruébelo sobre todos los fondos. Box-shadow no es un sustituto universal: puede desaparecer en el modo de colores forzados. Conserve un outline funcional.

/* Ejemplo para una superficie clara verificada */
.action:focus-visible {
  outline: 3px solid #1239a6;
  outline-offset: 3px;
}
@media (forced-colors: active) {
  .action:focus-visible {
    outline-color: Highlight;
  }
}

:focus-visible no significa «solo Tab». El navegador decide cuándo mostrar el foco mediante heurísticas; por ejemplo, un campo de texto puede conservarlo después de un clic. Hover no sustituye al foco: ambos estados cumplen funciones distintas.

Revise la cabecera fija, el aviso de cookies y los paneles flotantes. WCAG 2.4.11 AA exige que el contenido creado por el autor no oculte completamente el componente enfocado. Un objetivo de diseño más cómodo es mantener visibles todo el elemento y su indicador.

Tab es solo una parte de la navegación

Complete las tareas principales con teclado: Tab y Mayús+Tab desplazan el foco, Intro activa enlaces y botones, y Espacio activa botones; los componentes compuestos necesitan las teclas adecuadas a su patrón. No obligue a Tab a visitar cada opción de una lista si el patrón prevé usar las flechas.

Un lector de pantalla no equivale a un teclado. Puede navegar por encabezados, regiones y texto corriente; en el teléfono se utilizan gestos. Probar el teclado y probar con un lector de pantalla son trabajos distintos. Pulsar Tab diez veces sin problemas no demuestra accesibilidad para una persona ciega.

Ampliación: el 150% no basta

Para 1.4.4, el texto debe poder ampliarse hasta el 200% sin pérdida de contenido o funcionalidad, con las excepciones del criterio. Por separado, 1.4.10 evalúa la redistribución a una anchura equivalente a 320 CSS px para contenido que se desplaza verticalmente. Una forma habitual es usar un zoom del 400% desde una anchura inicial de la ventana de visualización de 1280 CSS px. Son dos comprobaciones distintas.

Las líneas de texto no deberían exigir desplazarse constantemente en dos direcciones. Hay excepciones para contenido que necesita una estructura bidimensional, como determinadas tablas y mapas. No justifican el desplazamiento horizontal de toda la página porque un botón sea demasiado ancho.

Aumente también el interlineado a 1,5 veces el tamaño de fuente, el espacio después del párrafo a 2 veces, entre letras a 0,12 y entre palabras a 0,16. Se comprueba que no se pierda contenido cuando la persona realiza esos ajustes, no que esos valores deban ser los predeterminados para todo el mundo.

El alt depende de la función de la imagen

Una imagen informativa necesita transmitir su significado; una decorativa necesita alt="". Un icono dentro de un botón ya etiquetado normalmente no debe repetir su nombre. Un alt breve no basta para un gráfico complejo: añada la explicación de las conclusiones y los datos accesibles junto a él.

El resultado práctico de una buena semántica es que la persona entiende dónde está, qué puede hacer y qué cambiará después de actuar. Eso se comprueba mediante una tarea, no contando atributos nuevos.

Fuentes y estado de los estándares verificados el 5 de noviembre de 2026.

Aplicar estas prácticas con un asistente de IA

A partir de esta investigación, creamos skills abiertos para Codex y Claude Code que ayudan a analizar y mejorar sitios web y aplicaciones. Accessible UI guía la revisión de la semántica, el teclado, el foco, los formularios y el contraste; Adaptive Interfaces ayuda a adaptar la interfaz al tamaño de la ventana, la escala del texto, el teclado y los dispositivos plegables. El agente examina el proyecto real, propone mejoras fundamentadas y verifica los cambios acordados. Estos skills no sustituyen las pruebas con usuarios y tecnologías de asistencia.

Las prácticas de esta serie están reunidas en el skill Accessible UI en GitHub: semántica, teclado, foco, formularios, contraste y verificación. Las instrucciones están en inglés. Consulte las instrucciones de instalación y los ejemplos de uso en el primer artículo.