Dropdown, menú, select y combobox: cuál usar y cuándo (sin romper a11y)

Posted on by marta

Elegir entre dropdown select y combobox no debería depender solo de cómo se ve el componente. La decisión tiene que partir de algo más importante: qué acción necesita realizar la persona usuaria.

Aunque muchas veces usamos la palabra dropdown como comodín, no todos los componentes desplegables resuelven el mismo problema. Un menú, un select y un combobox pueden parecer similares a simple vista, pero tienen comportamientos, propósitos e implicaciones de accesibilidad muy diferentes.

En diseño de interfaces, esta confusión es bastante habitual. Llamamos dropdown a un selector de opciones, a un menú de acciones, a una navegación con subniveles, a un filtro con búsqueda o a un campo con autocompletado. El problema es que, aunque visualmente puedan compartir ciertos rasgos, su semántica y su comportamiento no son equivalentes.

Cuando mezclamos estos patrones, el resultado suele ser el de siempre: componentes que “se ven bien”, pero fallan cuando se usan con teclado, lector de pantalla, foco visible, validación o mensajes de ayuda. Y esto no afecta solo a la accesibilidad. También impacta en la experiencia de usuario, en la claridad mental y en el tiempo que tarda una persona en tomar una decisión.

La regla base es sencilla: no es lo mismo elegir un valor de una lista que ejecutar una acción. Y si además necesitas búsqueda, autocompletado o filtrado, la decisión cambia todavía más.

La Web ya ofrece controles nativos muy sólidos para muchos casos. Por eso, antes de crear un componente personalizado, conviene preguntarse si HTML ya cubre esa necesidad. Las guías de WAI-ARIA también insisten en esta idea: los widgets personalizados deberían usarse solo cuando el control nativo no es suficiente.

En este artículo vamos a ordenar esta confusión con criterio técnico y ejemplos reales. Veremos cuándo conviene usar un select, cuándo tiene sentido un combobox accesible, cuándo un menú está bien planteado y por qué muchas “navegaciones con dropdown” en realidad funcionan mejor con otros patrones.

También conectaremos todo esto con formularios accesibles, mensajes de ayuda, aria-describedby y gestión del foco, porque un componente no vive aislado: forma parte de un flujo completo.

El problema real: llamar “dropdown” a todo

La palabra “dropdown” describe una apariencia, no una semántica. El navegador, el lector de pantalla y el teclado no interpretan “cosas que caen hacia abajo”; interpretan roles, estados, nombres accesibles y comportamientos esperados. Por eso dos componentes visualmente parecidos pueden exigir implementaciones totalmente distintas.

Un select nativo representa una elección de valor dentro de un formulario. Un menú representa una lista de acciones o comandos. Un menu button es un botón que abre ese menú. Un combobox es un control que combina un campo o trigger con un popup de sugerencias o selección, y ese popup puede ser una listbox, una grid, un tree o incluso un dialog, según el patrón.

Dicho de forma directa: si el usuario elige “España” para guardar un dato, eso no es un menú de acciones. Si pulsa “Editar, duplicar, archivar” sobre una fila de tabla, eso no es un select. Y si escribe en una caja para encontrar una ciudad entre miles de opciones, probablemente ya no te basta con un selector clásico: ahí empieza a tener sentido pensar en un combobox accesible.

Qué es cada patrón, sin humo

select

El elemento HTML <select> representa un control que muestra un conjunto de opciones, puede asociarse a un <label>, soporta atributos nativos como required, disabled, multiple o size, y viene con una base de accesibilidad y comportamiento que el navegador ya resuelve.

Menú / menu button

El patrón de menu button es un botón que abre un menú de acciones. No está pensado para capturar un valor de formulario, sino para ofrecer comandos. En APG, menu y menubar se acercan más a la lógica de aplicaciones de escritorio que a la navegación web común.

Combobox

El combobox accesible identifica un elemento —normalmente un input o a veces un botón— que controla la aparición de un popup dinámico para ayudar a establecer un valor. Puede ser editable o de solo selección. Cuando hay autocompletado, aria-autocomplete describe si la sugerencia se presenta en lista, inline o ambas.

Disclosure para navegación

Muchas navegaciones con submenús en web no necesitan menu ni menubar. WAI muestra ejemplos donde el patrón disclosure resulta más adecuado para mostrar y ocultar listas de enlaces, y señala además que, para la mayoría de sitios web, disclosure suele ser mejor opción que menubar porque evita una complejidad de teclado que rara vez aporta valor real.

Primer criterio rápido

Hazte esta pregunta antes de maquetar nada: ¿la persona usuaria está eligiendo un valor o ejecutando una acción?
Si elige un valor, piensa en select, radio, listbox o combobox accesible.
Si ejecuta una acción, piensa en botón, menu button o disclosure.
Si navega a otra página, piensa en enlaces y en arquitectura de navegación, no en “menús tipo app”. Esto conecta muy bien con tu post sobre Links accesibles: la semántica del destino importa tanto como la interacción.

Tiempo de decisión vs. carga cognitiva: la comparación que de verdad importa

En producto solemos obsesionarnos con la velocidad. “Que encuentre antes”, “que filtre más rápido”, “que elija en menos pasos”. Bien. Pero hay una trampa: reducir el tiempo de decisión no siempre reduce la carga cognitiva. A veces pasa justo lo contrario.

Un select nativo puede parecer más lento en listas largas, sí. Pero también es extremadamente predecible. Su comportamiento ya es conocido por personas usuarias, navegadores y tecnologías de asistencia. No requiere aprender un patrón nuevo, no sorprende y casi nunca necesita ayuda extra para entenderse. Eso significa menor carga cognitiva inicial y menos superficie de error.

Un combobox accesible, en cambio, puede reducir mucho el tiempo de decisión cuando la lista es extensa y la persona ya sabe lo que busca. Ejemplos clásicos: país, ciudad, idioma, framework, cliente, etiqueta o usuario asignado. En esos casos, escribir dos o tres letras puede ser más eficiente que recorrer cien opciones. Pero esa ganancia no sale gratis: introduces reglas de teclado, estados expandidos/colapsados, sugerencias activas, coincidencias parciales, mensajes de ayuda, vacío de resultados y, muchas veces, asincronía. Todo eso añade carga cognitiva si el diseño no es cristalino.

Dicho de forma muy práctica: el combobox acelera la búsqueda cuando el objetivo está claro; el select simplifica cuando el contexto importa más que la velocidad. Si la persona necesita explorar opciones y comparar tranquilamente, el select o incluso radios pueden ganar. Si sabe exactamente lo que quiere y la lista es grande, el combobox accesible suele ganar. La elección no va solo de “más moderno” o “más bonito”, sino de fricción mental.

Casos donde select gana, y gana de verdad

El select sigue siendo mejor opción cuando:

  • el conjunto de opciones es cerrado y estable;
  • la lista no es enorme;
  • el usuario necesita revisar opciones visibles y compararlas;
  • el dato forma parte de un formulario clásico;
  • quieres soporte robusto con el menor coste de mantenimiento.

Además, <select> se integra de forma natural con etiquetas, validación nativa y estados como required o disabled, lo que reduce bastante el riesgo de implementar mal mensajes, asociaciones o nombres accesibles.

Ejemplos claros: “Motivo de contacto”, “Talla”, “Mes”, “Provincia” si son pocas, “Tipo de documento”, “Número de personas” o “Ordenar por” cuando el listado de criterios es corto. Aquí meter un combobox es, muchas veces, sobrediseño.

Casos donde el combobox sí compensa

El combobox accesible compensa cuando hay una necesidad real de:

  • autocompletar;
  • filtrar una lista larga;
  • mostrar sugerencias dinámicas;
  • permitir escritura más selección;
  • reducir scroll y exploración lineal.

Esto encaja especialmente bien en buscadores internos, asignación de usuarios, catálogos extensos, taxonomías, ciudades, aeropuertos, bibliotecas de componentes o filtros complejos en e-commerce y SaaS. APG contempla distintos comportamientos de autocompletado y navegación con teclado, precisamente porque no todos los combobox hacen lo mismo.

Y ahora la verdad incómoda: muchos falsos “dropdowns” deberían ser otra cosa

Un botón “Acciones” dentro de una tabla no debería abrir un select, sino un menú de acciones. Una navegación superior con secciones desplegables no debería copiar el patrón de una app de escritorio si en realidad lo que muestra son enlaces. WAI incluso indica que el patrón disclosure suele estar mejor alineado con la navegación web que menubar, porque este último exige una interacción de teclado adicional que pocas webs necesitan.

Native first: antes de tocar ARIA, prueba a no necesitarlo

Uno de los errores más comunes en accesibilidad es pensar que ARIA “mejora” cualquier componente. No. ARIA sirve para describir widgets personalizados cuando el HTML nativo no basta, no para reemplazar alegremente controles que ya existen. MDN y WAI insisten una y otra vez en el valor del HTML semántico como base de accesibilidad. Y APG recuerda algo crucial: cuando construyes widgets ARIA personalizados, el soporte de teclado lo tienes que programar tú. El navegador ya no te salva.

Por eso, si un select cumple el caso de uso, es muy difícil justificar un combobox custom. Un widget “bonito” que falla con ArrowDown, Escape, Enter, foco visible o lector de pantalla nunca es una mejora. Es deuda técnica disfrazada de UI.

Qué necesita un combobox accesible de verdad

Según ARIA 1.2 y APG, un combobox suele requerir como mínimo una relación clara con su popup y estados como aria-expanded; además, el popup puede ser una listbox u otra estructura según el diseño. Si el control es editable y muestra predicciones, aria-autocomplete comunica el tipo de ayuda que recibe la persona usuaria.

Pero lo importante no es memorizar atributos sueltos. Lo importante es entender el comportamiento esperado:

Teclado

Cuando el foco está en el combobox, ArrowDown puede abrir o mover el foco al popup, Enter acepta la opción enfocada y Escape cierra el popup y devuelve el foco al control. APG detalla además diferencias entre combobox editable, selección automática y navegación dentro del popup.

Gestión de foco

No basta con “abrir la cajita”. Hay que decidir si el foco se mantiene en el input mientras la opción activa se anuncia mediante aria-activedescendant, o si se mueve físicamente dentro del popup según el patrón elegido. Cualquiera de las dos estrategias exige coherencia y pruebas reales.

Nombre accesible, ayuda y errores

El control necesita una etiqueta clara. La ayuda contextual o instrucciones pueden asociarse mediante aria-describedby, que enlaza el widget con texto descriptivo adicional. WAI también recuerda que los formularios deben proporcionar labels o instrucciones suficientes para que la persona sepa qué se espera de ella.

Aquí enlaza muy bien con el mundo de formularios accesibles: si tu combobox requiere “Escribe al menos 2 caracteres”, “Selecciona una opción de la lista” o “Puedes usar las flechas para navegar”, ese texto no debería perderse visualmente ni en el árbol de accesibilidad.

El error típico: copiar roles sin copiar comportamiento

Hay equipos que convierten un div en “combobox” solo porque le ponen role="combobox" y dos atributos ARIA. Eso no crea un combobox accesible. Crea una ilusión. APG existe precisamente porque los roles no sustituyen la interacción. Si el teclado, el foco, la selección, el anuncio de estado y la relación con el popup no funcionan como se espera, el patrón está roto aunque el inspector “se vea bonito”.

Diseño de interacción: ejemplos reales donde cada patrón encaja

Vamos a bajar esto al terreno donde realmente duele: decisiones de producto.

Selector de país en un formulario

Si tienes 15 o 20 países frecuentes y contexto regional claro, un select nativo puede ser suficiente y hasta preferible. Si tienes un catálogo global con más de 200 países y la mayoría de personas saben cuál van a seleccionar, un combobox accesible con búsqueda puede reducir bastante el tiempo de decisión.

La clave no es “lista larga = combobox” de forma automática. La clave es si el usuario busca o explora. Si explora, select. Si busca un objetivo conocido, combobox.

¿Y qué pasa con errores y validación?

Si el campo es obligatorio, el error debe explicarse de forma clara y vincularse al control. En formularios complejos, llevar el foco al primer error tras el envío puede ayudar mucho, pero sin convertir cada error en un secuestro de foco durante la escritura. Para eso conviene apoyarse en una etiqueta visible, texto de ayuda asociado y mensajes consistentes. aria-describedby resulta útil para enlazar instrucciones y errores descriptivos al control.

Menú de acciones en una fila de tabla

“Editar”, “Duplicar”, “Ver historial”, “Archivar”. Aquí no estamos eligiendo un valor para guardar en un formulario. Estamos lanzando acciones. Por tanto, lo correcto suele ser un menu button o, en casos simples, una lista de acciones visible o un popover con botones y enlaces bien marcados. Lo que no tiene sentido es usar un select para acciones del tipo “elige una y luego ejecuta”. Eso añade un paso mental absurdo.

Filtros en un e-commerce

Aquí está uno de los escenarios donde más se abusa del término dropdown. “Talla”, “Color”, “Marca”, “Precio”, “Disponibilidad”, “Envío rápido”… No todo merece el mismo patrón.

  • Talla: si el conjunto es pequeño y cerrado, suele ganar radio o select.
  • Marca: si hay muchas, un combobox accesible o una lista filtrable puede ahorrar tiempo.
  • Ordenar por: casi siempre gana select.
  • Filtros por navegación lateral: a menudo basta con disclosure para expandir bloques, no con menús ARIA complejos.

El patrón correcto cambia según la naturaleza del dato, no según la estética del diseño.

Navegación principal con subcategorías

Si al desplegar muestras enlaces a secciones o páginas, estás en terreno de navegación. WAI ofrece ejemplos de disclosure navigation y deja claro que menubar suele ser excesivo para webs corrientes. Traducido a castellano llano: no conviertas tu header en una falsa app de escritorio si solo necesitas mostrar sublinks. Esto además enlaza directamente con tu artículo Links accesibles: un enlace debe seguir siendo un enlace, con nombre claro y destino predecible.

Patrones ARIA, autocompletar y filtros: dónde se suelen romper

La parte más delicada del combobox accesible no es el CSS. Es la coherencia entre lo visual, lo semántico y lo interactivo.

Autocompletar no es lo mismo que sugerir

aria-autocomplete existe porque no todas las ayudas funcionan igual. Puedes sugerir resultados sin autocompletar inline, puedes completar dentro del texto o combinar ambos comportamientos. Eso afecta a la expectativa de la persona usuaria y al modo en que navega con teclado.

Si cada pulsación reordena opciones, cambia el elemento activo, borra coincidencias previas y además desplaza el layout, el supuesto ahorro de tiempo se convierte en saturación mental.

“Sin resultados” también es parte del patrón

Un combobox bien hecho no solo resuelve el caso feliz. También resuelve:

  • cero coincidencias;
  • carga remota;
  • error de red;
  • opción previamente seleccionada;
  • recuperación al pulsar Escape;
  • estado colapsado vs expandido;
  • limpieza del valor.

No hace falta que todos esos estados sean sofisticados, pero sí que sean comprensibles y consistentes.

Ojo con datalist

<datalist> puede parecer una solución rápida para sugerencias, pero MDN advierte de consideraciones de accesibilidad y además indica que no es Baseline en todos los navegadores más usados. Es decir, puede servir en contextos concretos, pero no es la salida universal que a veces parece.

La pregunta incómoda que deberías hacerte

Si un filtro se puede resolver con checkboxes, radios o un select, ¿de verdad necesitas un combobox?
Y si la respuesta es “porque queda más moderno”, probablemente la respuesta real es no.

Cómo decidir bien: una guía práctica sin postureo

Antes de implementar, responde estas cuatro preguntas:

1. ¿Es una acción o un valor?

Acción = botón o menú.
Valor = select, radios, listbox o combobox accesible.

2. ¿La persona necesita buscar o explorar?

Buscar = combobox.
Explorar = select o radios.

3. ¿Hay un control nativo suficiente?

Si sí, úsalo. HTML semántico primero.

4. ¿Puedes implementar teclado, foco y mensajes de forma completa?

Si no puedes garantizarlo, no inventes un widget custom. APG deja claro que en ARIA personalizado la responsabilidad de teclado recae en quien implementa.

Relación con otros componentes accesibles de tu sistema

Este tema no vive aislado. Un combobox suele compartir problemas con modales, tabs, accordions y toasts: foco, anuncio de cambios, relación entre trigger y contenido, y consistencia de teclado. Aquí encaja muy bien un enlace interno hacia tu artículo Componentes UI accesibles, porque todo forma parte de la misma conversación de diseño de sistemas.

Y del lado del contenido, la claridad del label, del texto de ayuda y del destino final conecta con Links accesibles. La accesibilidad no se rompe solo por ARIA mal puesta; también se rompe cuando la interfaz obliga a adivinar.

Preguntas frecuentes (FAQs)

¿Un select nativo es siempre más accesible que un combobox?

No siempre, pero sí suele ser más robusto por defecto. Si cubre el caso de uso, normalmente es la opción más segura y mantenible. El combobox accesible solo merece la complejidad añadida cuando hay una necesidad real de búsqueda, autocompletado o filtrado avanzado.

¿Puedo usar un menú para navegar entre páginas?

Puedes, pero muchas veces no deberías. Si lo que muestras son enlaces de navegación web, WAI propone con frecuencia disclosure como patrón más apropiado que menu o menubar, porque estos últimos añaden una interacción más propia de aplicaciones de escritorio.

¿Qué atributo uso para asociar ayuda o instrucciones a un combobox?

Normalmente aria-describedby, siempre que exista texto descriptivo visible o identificado por id y ese texto aporte contexto útil. Es especialmente útil para indicar formato, instrucciones de uso o mensajes de error relacionados con el control.

Diseñar con criterio, no por apariencia

La discusión entre dropdown, menú, select y combobox accesible no va de nomenclatura fina para puristas. Va de algo mucho más importante: hacer que la interfaz se comporte como promete.

Cuando usas un select para acciones, obligas a pensar donde no hacía falta. Cuando conviertes una navegación en un falso menubar, importas complejidad sin beneficio real. Y cuando montas un combobox custom sin resolver foco, teclado, autocompletado y mensajes, rompes justo aquello que pretendías mejorar.

A nivel de producto, la mejor decisión no es la más vistosa, sino la que mejor equilibra tiempo de decisión, carga cognitiva, claridad semántica y mantenibilidad técnica. Y a nivel de accesibilidad, casi siempre hay una verdad incómoda pero útil: menos invento y más criterio.

Un select que funciona bien puede ser mejor UX que un componente espectacular lleno de microinteracciones inútiles. Un disclosure honesto puede ser mejor navegación que un pseudo-menú “premium”. Y un combobox accesible solo es una mejora cuando ayuda de verdad a encontrar antes, entender mejor y equivocarse menos.

Ahí está la diferencia entre decorar una interfaz y diseñarla con intención.

Focus visible y teclado: el 90% de los bugs de accesibilidad están aquí

Posted on by marta
Ilustración con estilo editorial que muestra una ventana de navegador y navegación por teclado: un botón “Saltar al contenido principal”, tarjetas y un botón “Ver detalle” con contornos de foco resaltados. Alrededor aparecen iconos de Tab, Skip links, Cards clicables y una alerta de “trampas típicas”, junto al título “Focus visible y teclado: el 90% de los bugs de accesibilidad están aquí” y la URL martagonzalez.dev.

Si tu interfaz “se ve bien” pero al navegar con Tab se vuelve un laberinto, no es mala suerte: es el patrón más repetido de bugs de accesibilidad. Y lo peor es que suele pasar incluso en equipos con buen nivel técnico, porque el teclado no se “prueba” con la misma seriedad que el responsive o el rendimiento.

En este artículo vamos a atacar el núcleo: focus visible, orden de tab, skip links, cards clicables y las trampas típicas (modales, menús, overlays, estados, formularios). Te lo cuento de tú a tú, con tono profesional y con ejemplos de diseño e interacción que puedes aplicar hoy.

Importante: muchas auditorías automáticas te dirán “casi ok”. Pero el teclado se valida con manos humanas. Y ahí aparecen los fantasmas.

Por qué el foco es el epicentro (y por qué te rompe la UX si falla)

Cuando navegas con ratón, tu “cursor” es obvio. Con teclado, el cursor es el foco. Si no ves dónde estás, la interfaz deja de ser una interfaz: es una adivinanza.

Aquí es donde entra la comparación clave: tiempo de decisión vs. carga cognitiva.

  • Tiempo de decisión: cuánto tardas en decidir “¿qué hago ahora?”.
  • Carga cognitiva: cuánta energía mental gastas para entender “¿dónde estoy, qué puedo hacer, qué va a pasar?”.

Un focus visible claro reduce ambos:

  • Te ubica en milisegundos (menos tiempo de decisión).
  • Evita que tengas que “reconstruir” el contexto mentalmente (menos carga cognitiva).

Cuando el foco no se ve o el orden de tabulación es caótico, obligas a la persona a:

  1. buscar (¿dónde está el foco?),
  2. inferir (¿qué elemento es este?),
  3. corregir (me pasé, vuelvo con Shift+Tab),
  4. dudar (¿si pulso Enter… rompo algo?).

Y eso en UI complejas (dashboards, filtros, cards, menús) es un multiplicador de frustración.

:focus vs :focus-visible (y cómo dejar de pelearte con los estilos)

Qué es exactamente :focus-visible

  • :focus se activa cuando un elemento recibe foco, venga de teclado, mouse o script.
  • :focus-visible intenta mostrarse solo cuando tiene sentido para la persona usuaria, típicamente cuando navega con teclado.

La consecuencia práctica: puedes diseñar un anillo de foco potente para teclado sin que “moleste” a quien usa ratón.

Regla de oro de CSS (y el pecado mortal del outline: none)

Si has visto esto en un proyecto, es una red flag:

*:focus {
  outline: none;
}

Eso es como apagar el foco. Y sí: mucha gente lo hace “para que no se vea feo”. El resultado es que tu UI se vuelve inaccesible por teclado.

La alternativa moderna y segura:

/* Base: dejamos el outline por defecto como fallback */
:focus {
  outline: 2px solid transparent;
  outline-offset: 2px;
}/* Teclado: anillo visible y consistente */
:focus-visible {
  outline: 3px solid currentColor;
  outline-offset: 3px;
}/* Opcional: si usas Tailwind, esto suele mapear a ring utilities */

Consejo pro: usa outline (no box-shadow) como primera opción. outline no afecta layout y suele ser más consistente.

El anillo de foco no es “decoración”, es señalización

Un buen focus visible tiene:

  • Contraste suficiente contra el fondo (y también contra el propio componente).
  • Grosor visible (no “una línea finita” que desaparece).
  • Offset para que no se confunda con el borde del botón.
  • Consistencia: mismo estilo en botones, links, inputs, chips, cards.

El problema de “no se ve en fondos con imagen / gradiente”

Si tu UI tiene hero con imagen, tarjetas con fotos o fondos con ruido visual, el foco necesita doble capa:

:focus-visible {
  outline: 3px solid #fff;
  outline-offset: 3px;
  box-shadow: 0 0 0 6px rgba(0,0,0,.6);
}

No es para “embellecer”: es para que el foco sobreviva en fondos complejos.

Orden de tab: si el DOM y el layout no cuentan la misma historia, pierdes

El orden de tabulación sigue el orden del DOM (con matices), no el orden visual de tu grid. Por eso, cuando haces layouts con CSS (grid, flex, reorder), puedes crear un recorrido por teclado completamente surrealista.

Las reglas que casi nunca fallan

  1. No uses tabindex positivo (tabindex="1", 2, 3"...).
    • Es un imán de bugs.
    • Rompe expectativas y se vuelve inmantenible.
  2. Mantén el orden lógico en el DOM igual que el visual (siempre que puedas).
  3. Si necesitas reordenar visualmente, piensa si estás creando dos narrativas: una visual y otra para teclado/lectores.
  4. Evita esconder elementos focusables con display:none o visibility:hidden de forma que cambie el orden inesperadamente (especialmente en menús responsive).

El caso típico: filtros + resultados + sidebar

En un e-commerce o listado con filtros:

  • Lo visual suele ser: filtros a la izquierda, resultados a la derecha.
  • Pero si en móvil pones filtros arriba y luego en desktop los “mueves” visualmente sin cambiar el DOM, el tab puede ir: resultados → header → filtros → footer… un caos.

Solución recomendada: estructura DOM con un orden lógico y usa CSS para adaptarlo sin “teletransportar” secciones críticas.

Las skip links (enlace para “saltar al contenido”) son ese detalle que parece pequeño… hasta que tienes que tabular por:

  • logo,
  • navegación,
  • buscador,
  • botones,
  • banners,
  • cookie bar,
  • etc.

Cómo se implementa bien

En el primer foco de la página (normalmente el primer elemento del body), añade:

<a class="skip-link" href="#main-content">Saltar al contenido principal</a><header>...</header><main id="main-content" tabindex="-1">
  ...
</main>What is this?

Y el CSS clásico (oculta pero accesible, aparece al enfocar):

.skip-link {
  position: absolute;
  left: -999px;
  top: 1rem;
  padding: .75rem 1rem;
  background: #fff;
  border: 2px solid #000;
  z-index: 9999;
}.skip-link:focus-visible {
  left: 1rem;
}

Por qué tabindex="-1" en main: permite que el salto de foco sea confiable incluso si el navegador no enfoca el destino como esperas.

Si además usas landmarks (<header>, <nav>, <main>, <footer> y/o role="navigation"), ayudas a que la navegación sea más rápida en lectores de pantalla. No es “solo teclado”, es arquitectura.

Cards clicables: el patrón favorito de los bugs silenciosos

Las cards clicables son bonitas. Y peligrosas.

El problema típico:

  • Haces una card con div y onClick.
  • Visualmente parece un link.
  • Con teclado no es interactiva.
  • O lo es “a medias” con tabIndex=0 y role=button, pero luego Enter no navega o Space hace scroll.
  • Y si dentro hay links reales, creas elementos interactivos anidados (error UX + accesibilidad).

Lo más limpio:

<a class="card" href="/detalle">
  <h3>Título</h3>
  <p>Descripción</p>
</a>What is this?

Ventajas:

  • Tab funciona.
  • Enter funciona.
  • Semántica correcta.

Peeero: solo si la card realmente representa una única acción (ir al detalle).

Si la card tiene botones dentro (guardar, compartir, etc.), no conviertas todo en link. Haz esto:

<article class="card">
  <h3>
    <a href="/detalle">Título</a>
  </h3>  <p>Descripción</p>  <div class="actions">
    <button type="button">Guardar</button>
    <button type="button">Compartir</button>
  </div>
</article>What is this?

Y si quieres que al clicar en el “fondo” también navegue, hazlo con cuidado: sin romper teclado y sin anidar interactivos. Un truco visual común es usar un pseudo-elemento para ampliar el área clicable del link del título (sin envolverlo todo en un <a>).

Trampa típica — “div role=button” como solución rápida

Sí, se puede hacer accesible… pero es más fácil romperlo que hacerlo bien. Si aun así lo haces:

  • gestiona Enter y Space,
  • añade aria-label si no hay texto,
  • asegura estilos de foco,
  • y recuerda que un “botón que navega” suele ser peor que un link.

Formularios accesibles: foco, errores y mensajes que no se pierden

Ya que la keyword secundaria incluye formularios accesibles, aquí es donde el foco se vuelve crítico.

Error summary + foco al primer error

Cuando envías un formulario con errores:

  1. Muestra un resumen arriba (“Revisa los campos marcados”).
  2. Lleva el foco a ese resumen.
  3. Desde ahí, ofrece links a cada campo con error.

Ejemplo conceptual:

<div class="error-summary" role="alert" tabindex="-1" id="error-summary">
  <p><strong>Hay errores en el formulario</strong></p>
  <ul>
    <li><a href="#email">El email no es válido</a></li>
    <li><a href="#password">La contraseña es obligatoria</a></li>
  </ul>
</div>What is this?

Y al fallar validación:

document.getElementById("error-summary")?.focus();

aria-describedby para unir campo + ayuda + error

<label for="email">Email</label>
<input id="email" aria-describedby="email-hint email-error" /><p id="email-hint">Usa un correo real. Te enviaremos confirmación.</p>
<p id="email-error" role="status">Formato incorrecto.</p>What is this?

Clave: si el error aparece dinámicamente, asegúrate de que se anuncie y de que el foco no “salte” sin motivo.

Trampas típicas con teclado (las que más veo en UI reales)

Modales sin focus trap (o con focus trap agresivo)

Un modal accesible necesita:

  • foco inicial dentro (idealmente en el título o el primer control),
  • focus trap para que Tab no se vaya detrás,
  • cierre con Escape,
  • restaurar el foco al elemento que lo abrió.

Solución moderna: inert para el fondo

Cuando el modal está abierto, el resto de la página debería quedar “inactivo”. inert ayuda mucho (según soporte del navegador / polyfill si lo necesitas):

const main = document.querySelector("main");
main?.setAttribute("inert", "");
// al cerrar:
main?.removeAttribute("inert");

Menús desplegables que se cierran al perder foco

Si tu dropdown se cierra cuando “blur” ocurre, puedes crear un infierno:

  • tabulas al siguiente item y se cierra antes de poder interactuar,
  • o se cierra al intentar usar flechas.

Solución: define claramente el patrón (menú tipo navegación vs select vs combobox). Y si no estás segura, apóyate en patrones ARIA bien establecidos (y pruébalo con teclado real).

“Scroll jail”: foco dentro de contenedores con overflow

Cuando metes listas scrollables (overflow:auto) y no gestionas bien el foco:

  • el foco se mueve pero la lista no hace scroll para mostrarlo,
  • parece que “desapareció”.

Solución: al cambiar foco dentro de un contenedor scrollable, asegúrate de que el elemento se vea (element.scrollIntoView({ block: "nearest" }) con moderación).

Checklist de supervivencia: prueba manual que detecta el 90% de fallos

Recorrido mínimo (5 minutos por pantalla)

  1. Tab desde el inicio: ¿aparece focus visible siempre?
  2. ¿El foco se ve en botones, links, inputs, chips, icon buttons?
  3. ¿El orden de tab es lógico y coincide con el recorrido visual?
  4. ¿Hay skip link? ¿Funciona?
  5. ¿Puedes activar todo con Enter y/o Space cuando corresponde?
  6. ¿Hay algún “callejón sin salida” (no puedes salir de un componente)?
  7. En formularios: ¿al error te enteras, y sabes qué campo corregir?

Antipatrones que debes cazar como si fueran pokémon

  • outline: none sin alternativa.
  • tabindex="1" (o cualquier positivo).
  • Cards enteras clicables con div onClick sin semántica.
  • Modales que abren y el foco se queda detrás.
  • Componentes “bonitos” que solo funcionan con mouse.

Enlaces internos recomendados (para hilar la serie)

Para completar el mapa mental y reforzar SEO interno, enlaza desde aquí a:

  • Links accesibles: “haz click aquí” es un crimen → (añade tu URL final)
    Sugerencia de slug: /blog/links-accesibles-haz-click-aqui-es-un-crimen/
  • Componentes UI accesibles (patrones) → (añade tu URL final)
    Sugerencia de slug: /blog/componentes-ui-accesibles-patrones/

(Tip SEO: enlaza también de vuelta desde esos posts hacia este, usando el anchor “focus visible” o “navegación con teclado”.)

FAQs (preguntas frecuentes)

1) ¿focus-visible funciona en todos los navegadores?

En la mayoría de navegadores modernos, sí. Aun así, conviene dejar un fallback con :focus para no quedarte sin estilos si algo falla. La estrategia habitual es: focus como base + focus-visible como mejora.

2) ¿Por qué no debería usar tabindex positivo para “arreglar” el orden?

Porque es pan para hoy y deuda técnica para mañana. En cuanto cambias algo del DOM, el orden se vuelve impredecible y cuesta muchísimo mantenerlo. Lo correcto es arreglar el orden en el DOM y reservar tabindex para casos muy concretos (0 o -1).

3) ¿Cómo hago una card clicable sin romper accesibilidad?

Piensa primero si la card representa una única acción. Si sí, usa un <a> envolviendo el contenido. Si no (porque hay botones dentro), usa link principal (título) + acciones separadas. Evita anidar interactivos y evita div clicables como atajo.

Accesibilidad es bajar el volumen mental

Un buen focus visible no es un “detalle de a11y”. Es un contrato de claridad: “estás aquí, puedes hacer esto, y esto es lo que pasará”. Cuando ese contrato se rompe, sube el tiempo de decisión y explota la carga cognitiva. Y eso no afecta solo a personas con discapacidad: afecta a cualquiera que navegue rápido, con prisa, con fatiga, con una mano ocupada, o simplemente con preferencia por teclado.

Si quieres un criterio simple para priorizar: si una pantalla funciona perfecta con teclado, suele funcionar mejor para todo el mundo. Y además, te obliga a diseñar interacciones más honestas: menos trucos visuales, más intención semántica, más estructura.

La próxima vez que alguien diga “esto es solo accesibilidad”, prueba a responder:
“No: esto es usabilidad bajo presión.” Y el teclado es la prueba de fuego.

Formularios accesibles: labels, errores y validación sin frustrar a nadie

Posted on by marta
Ilustración de un formulario web con mensajes de error accesibles: aviso “El email no es válido”, resumen de errores y pistas como “aria-describedby” y “Focus al primer error”, con el título “Formularios accesibles: labels, errores y validación sin frustrar a nadie”.

Los formularios accesibles en HTML son una de las bases más importantes de cualquier interfaz usable. Un formulario puede parecer sencillo, pero si los labels no están bien asociados, los errores no se entienden o la validación llega demasiado tarde, la experiencia de usuario se rompe rápidamente.

Crear formularios accesibles en HTML no consiste solo en añadir atributos ARIA o cumplir una checklist técnica. También implica pensar en cómo una persona entiende cada campo, cómo recibe ayuda, cómo corrige un error y qué ocurre cuando navega con teclado o lector de pantalla.

La clave está en combinar buena semántica, instrucciones claras y validación comprensible. Un label bien asociado, un mensaje de error útil y una ayuda conectada con aria-describedby pueden marcar una gran diferencia entre un formulario frustrante y un flujo realmente accesible.

En este artículo veremos cómo diseñar formularios accesibles en HTML usando labels claros, mensajes de ayuda, errores bien comunicados y validaciones que acompañen a la persona usuaria sin bloquearla ni hacerle repetir pasos innecesarios.

La base no negociable: el “nombre accesible” y los labels bien hechos

Un formulario accesible empieza con una idea simple: cada control debe tener un nombre accesible claro. Ese nombre es lo que anuncia un lector de pantalla, lo que entiende el autocompletado, y lo que ayuda a cualquier persona (incluida la que no usa tecnologías de apoyo) a completar el formulario más rápido.

Label visible y asociado: lo más robusto

La opción más estable sigue siendo la de siempre:

<label for="email">Email</label>
<input id="email" name="email" type="email" autocomplete="email" />What is this?
  • Visible: reduce dudas (“¿qué se supone que va aquí?”).
  • Asociado con for/id: funciona con teclado, lectores de pantalla y click/tap.
  • Compatible con traducciones y QA (se testea fácil).

Cuándo agrupar: fieldset + legend

Si tienes opciones relacionadas (radio buttons, checkboxes en grupo), no uses un label “falso” arriba y ya. Agrupa:

<fieldset>
  <legend>Método de contacto preferido</legend>  <div>
    <input type="radio" id="contact-email" name="contact" value="email" />
    <label for="contact-email">Email</label>
  </div>  <div>
    <input type="radio" id="contact-phone" name="contact" value="phone" />
    <label for="contact-phone">Teléfono</label>
  </div>
</fieldset>What is this?

Esto mejora comprensión y reduce carga cognitiva: el usuario no tiene que deducir qué relación tienen esos controles.

No, el placeholder no es un label (y suele ser una trampa)

El placeholder:

  • desaparece al escribir (adiós referencia),
  • suele tener bajo contraste,
  • se confunde con “texto ya rellenado”,
  • y en móvil es aún peor.

Si quieres dar ejemplo o formato, usa texto de ayuda persistente.

Ayudas y ejemplos sin ensuciar: texto de hint

<label for="dni">DNI</label>
<p id="dni-hint">Formato: 12345678X</p>
<input id="dni" name="dni" aria-describedby="dni-hint" />What is this?

Aquí ya asoma el protagonista de este artículo: aria-describedby.

Errores que ayudan, no que castigan

Un error accesible no es “ponerlo en rojo”. Un error útil responde a tres preguntas:

  1. Qué pasó (qué está mal)
  2. Por qué importa (si aplica)
  3. Cómo lo arreglo (acción concreta)

Mensajes de error con microcopy que baja la frustración

Ejemplos malos:

  • “Valor inválido”
  • “Error”
  • “Campo incorrecto”

Ejemplos buenos:

  • “Introduce un email válido, por ejemplo: nombre@dominio.com”
  • “La contraseña debe tener al menos 10 caracteres y 1 número”
  • “Este campo es obligatorio”

Tip UX importante: evita el tono regañón. Un formulario no es una relación tóxica.

Dónde mostrar errores: inline + resumen (cuando el formulario es largo)

Para formularios cortos, suele bastar con error inline cerca del campo. Para formularios largos o con envío final, un resumen de errores arriba ahorra tiempo y reduce abandono.

  • Inline: repara el error en contexto.
  • Resumen: evita la “búsqueda del tesoro” cuando hay varios fallos.

Señales de error sin depender solo del color

Asegúrate de combinar:

  • color + icono + texto,
  • borde/outline suficiente,
  • mensaje explícito,
  • y, si puedes, un patrón consistente (siempre mismo lugar y estilo).

Esto impacta directamente en el equilibrio tiempo de decisión vs. carga cognitiva: si el usuario tiene que interpretar señales ambiguas, decide más lento y se cansa antes.

ARIA aplicada a formularios: aria-describedby, aria-invalid, mensajes y anuncios

ARIA no “arregla” un formulario mal construido, pero sí puede hacerlo entendible cuando la UI es dinámica o compleja.

aria-describedby: une el campo con su ayuda y su error

La idea: el input “apunta” a uno o varios elementos que amplían su explicación.

Caso 1: hint permanente

<label for="password">Contraseña</label>
<p id="password-hint">Mínimo 10 caracteres, con 1 número.</p>
<input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-hint"
/>What is this?

Caso 2: hint + error (cuando aparece)

<label for="password">Contraseña</label>
<p id="password-hint">Mínimo 10 caracteres, con 1 número.</p><p id="password-error" hidden>
  La contraseña debe tener al menos 10 caracteres e incluir 1 número.
</p><input
  id="password"
  name="password"
  type="password"
  aria-describedby="password-hint password-error"
  aria-invalid="false"
/>What is this?

Cuando validas y hay error:

  • quitas hidden,
  • pones aria-invalid="true".

Detalle clave: si el error se actualiza dinámicamente, asegúrate de que se anuncie (ahora vamos con eso).

aria-invalid y aria-errormessage

  • aria-invalid="true" marca el control como inválido.
  • aria-errormessage="id-del-error" puede usarse para apuntar al mensaje de error.

Ejemplo:

<p id="email-error" hidden>Introduce un email válido.</p><input
  id="email"
  type="email"
  aria-invalid="true"
  aria-errormessage="email-error"
  aria-describedby="email-error"
/>What is this?

En la práctica, aria-describedby sigue siendo el más compatible para “leer” el error en contexto. aria-errormessage puede complementar, pero no lo uses como “única vía”.

Cómo anunciar errores en tiempo real sin saturar

Si actualizas errores al vuelo, puedes usar un contenedor con aria-live:

<div id="form-status" aria-live="polite"></div>What is this?
  • polite: anuncia cuando pueda (mejor para no interrumpir).
  • assertive: interrumpe (úsalo solo para cosas críticas).

Regla de oro: no conviertas el formulario en una máquina de notificaciones. Si anuncias cada letra, creas ruido y subes la carga cognitiva.

Focus al primer error: menos vueltas, más claridad

“Focus al primer error” es un patrón muy citado porque reduce el tiempo de resolución: el usuario envía, hay errores, y en vez de dejarlo arriba del todo preguntándose qué pasó, lo llevas al primer campo inválido.

Cuándo es buena idea

  • Formulario con botón “Enviar” al final.
  • Errores que solo se detectan al submit (servidor / reglas complejas).
  • Formularios largos (checkout, alta, onboarding).

Cómo hacerlo sin romper la UX

Aquí tienes un patrón que suele funcionar mejor que “foco directo al input sin contexto”:

  1. Muestras resumen de errores arriba.
  2. Mueves foco al resumen (para anunciar lo que pasó).
  3. El resumen contiene enlaces a cada campo con error.
  4. Opcional: el primer enlace apunta al primer campo inválido.

Ejemplo de resumen:

<div
  id="error-summary"
  role="alert"
  tabindex="-1"
  aria-labelledby="error-summary-title"
  hidden
>
  <h2 id="error-summary-title">Revisa estos campos</h2>
  <ul>
    <li><a href="#email">El email no es válido</a></li>
    <li><a href="#password">La contraseña no cumple los requisitos</a></li>
  </ul>
</div>What is this?
  • role="alert" ayuda a anunciar el bloque.
  • tabindex="-1" permite llevar el foco ahí con JS.
  • Los enlaces con href="#id" facilitan salto con teclado y lector.

Luego, en JS (concepto, no framework específico):

  • si hay errores → mostrar resumen → focus() al resumen.

Ojo con “robar foco” mientras el usuario escribe

No cambies el foco al primer error en medio de la escritura. Eso desespera. Una estrategia menos invasiva:

  • valida on blur (cuando sale del campo),
  • o después de un pequeño delay,
  • y deja el “focus al primer error” para el submit.

Validación sin frustración: interacción, prevención y accesibilidad real

Validar no es solo “bloquear”. Validar bien es prevenir errores.

Tiempo de decisión vs carga cognitiva: por qué tu formulario se siente “pesado”

  • Tiempo de decisión: cuánto tarda alguien en elegir qué hacer (qué opción, qué formato, qué respuesta).
  • Carga cognitiva: cuánta energía mental gasta entendiendo y recordando cosas.

Formularios que suben ambos:

  • demasiadas opciones sin jerarquía,
  • campos con requisitos ocultos,
  • formatos raros (teléfono, fechas) sin ayuda,
  • errores genéricos,
  • pasos que no explican “por qué te pido esto”.

Formularios que los reducen:

  • defaults inteligentes (sin ser tramposos),
  • progresive disclosure (mostrar solo lo necesario),
  • ejemplos claros (hint + aria-describedby),
  • validación amable (no punitiva),
  • feedback inmediato pero no ruidoso.

Prevención: input types, autocomplete, inputmode y máscaras con cuidado

  • type="email", type="tel", type="number" (con criterio), type="date" (ojo compatibilidad).
  • autocomplete="email", autocomplete="name", autocomplete="postal-code"… ayuda muchísimo.
  • inputmode="numeric" para móviles cuando quieres números (mejor que type="number" en algunos casos).
  • Máscaras: úsalas solo si no impiden editar. Si la máscara dificulta corregir, sube frustración.

Obligatorio no es lo mismo que “marcar con *”

Si usas asterisco:

  • acompáñalo de texto (“Campos obligatorios *”),
  • y no dependas solo del símbolo para que se entienda.

En HTML, puedes usar required y, si quieres, comunicarlo en el label:

  • “Email (obligatorio)”.

Ejemplos UI avanzados (con patrones que suelen posicionar bien)

1) Login simple: error inline + anuncio suave

  • Error debajo del campo.
  • aria-describedby enlaza a error cuando aparece.
  • aria-live="polite" para estados generales (por ejemplo, “credenciales incorrectas”).

2) Checkout: resumen arriba + foco al resumen + enlaces a campos

  • Reduce búsqueda visual.
  • Mejora navegación con teclado.
  • Disminuye el “¿qué demonios pasó?” tras pulsar pagar.

3) Newsletter: validación al salir del campo (blur), no en cada tecla

  • Evita spam de errores (“falta @” cuando aún estás escribiendo).
  • Más humano, menos robot.

4) Formulario en modal (si lo usas): no olvides el contexto

Si el formulario está dentro de un modal:

  • el foco debe quedar atrapado en el modal,
  • cerrar con Escape,
  • y los errores deben anunciarse dentro (aquí enlaza con tu post de Componentes UI accesibles, porque los modales son un mundo).

Checklist técnico para auditar “formularios accesibles” (nivel pro)

  • Cada input tiene label asociado (for/id) o nombre accesible equivalente.
  • Los grupos de radios/checkboxes usan fieldset + legend.
  • Los placeholders no sustituyen labels.
  • Los hints y errores están conectados con aria-describedby.
  • Cuando hay error: aria-invalid="true" (y mensaje visible).
  • Los errores no dependen solo del color (texto + patrón visual).
  • Existe un patrón claro de validación (on blur / on submit) sin bombardear.
  • Si hay varios errores: hay resumen arriba y es alcanzable por teclado.
  • Implementación de focus al primer error (preferiblemente foco al resumen primero).
  • Estados dinámicos anunciados con aria-live cuando corresponde (sin exceso).
  • Contraste suficiente en texto, borde y estados (focus/error/disabled).
  • Soporte móvil: autocomplete, inputmode, tamaños de tap cómodos.

Preguntas frecuentes (FAQs)

1) ¿aria-describedby debe apuntar al error, al hint o a ambos?

A ambos, si ambos aportan valor. Lo típico es hint siempre + error solo cuando aparece. Mantén los IDs estables y actualiza visibilidad/estado, para que el control siempre “arrastre” la información correcta.

2) ¿Es obligatorio mover el foco al primer error al enviar?

No es obligatorio, pero suele ser recomendable en formularios largos. En muchos casos, el patrón más amable es: foco al resumen de errores (para contexto) y desde ahí enlaces al primer error. Mover foco directamente al input puede desorientar si el usuario no entiende “qué pasó”.

3) ¿Valido en tiempo real o al submit?

Depende, pero una regla práctica es:

  • en tiempo real solo para ayudas útiles (fortaleza de contraseña, formato orientativo),
  • on blur para errores simples,
  • on submit para reglas complejas o validación de servidor.
    La prioridad es no interrumpir y no saturar: valida para ayudar, no para castigar.

La accesibilidad en formularios es empatía aplicada (y SEO del bueno)

Un formulario accesible no es “cumplir una checklist”. Es diseñar una conversación donde la otra persona se siente guiada, no examinada. Cuando etiquetas bien, reduces dudas. Cuando los errores explican y se anuncian, reduces frustración. Cuando gestionas el foco con intención, reduces vueltas. Y cuando equilibras tiempo de decisión vs carga cognitiva, reduces abandono.

La parte bonita: esto no solo beneficia a quien usa lector de pantalla. Beneficia a todo el mundo. Y además, en términos de posicionamiento, un artículo que baja a tierra patrones como aria-describedby, resumen de errores y focus management suele destacar porque responde exactamente a lo que la gente busca cuando escribe “formularios accesibles errores aria-describedby focus al primer error ejemplos UI”.