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.