Hablar de Baseline-first se ha vuelto cada vez más útil porque por fin nos da un lenguaje más claro para responder una pregunta muy cotidiana en front-end: ¿esto ya es suficientemente seguro como para usarlo en producción sin montar medio circo de polyfills, hacks o dependencias?
Ahora bien, cuando entran patrones de interacción complejos, la conversación no debería quedarse solo en la compatibilidad del navegador.
Un combobox accesible no es un select maquillado ni una mejora automática por parecer más moderno. En una estrategia Baseline-first, la pregunta importante no es solo si puede hacerse con tecnología nativa, sino si realmente mejora la claridad, reduce la carga cognitiva y resuelve mejor la interacción.
Baseline, en esencia, sirve para eso: aportar claridad sobre la compatibilidad de las features de la plataforma web. Pero una cosa es saber si algo funciona entre navegadores y otra muy distinta decidir si esa solución encaja bien en una experiencia real.
Puedes ampliar este marco en la documentación oficial de Baseline en web.dev y en MDN, donde se insiste en que la compatibilidad no equivale por sí sola a calidad de uso.
Y justo por eso este tema encaja tan bien con el debate sobre el combobox accesible. Muchas veces un equipo adopta una estrategia Baseline-first y saca una conclusión demasiado rápida: si la plataforma ya cubre tanto, entonces la librería sobra.
Pero no siempre.
Hay contextos en los que una librería sigue teniendo sentido, no porque la web nativa “no valga”, sino porque la complejidad real del problema está en la interacción, el foco, la navegación por teclado, el autocompletar, los filtros o la consistencia del sistema.
Si quieres una base más amplia sobre esta forma de decidir en front-end, aquí encaja muy bien Desarrollar Baseline-first: qué es y por qué cada vez más equipos lo aplican.
Baseline-first no significa “nativo a toda costa”
Una estrategia Baseline-first bien entendida no consiste en rechazar librerías por principio. Consiste en dejar de instalarlas por reflejo.
Si una feature ya es interoperable en los navegadores clave, seguramente no necesitas añadir una abstracción enorme solo para “tener soporte”. En la documentación de Baseline se explica que una feature pasa a Newly available cuando ya funciona en todos los navegadores base, y a Widely available cuando han pasado 30 meses desde ese momento, lo que la convierte en una apuesta todavía más segura para la mayoría de proyectos. MDN también especifica el conjunto de navegadores que se considera para Baseline: Safari en iOS y macOS, Chrome en Android y escritorio, Edge en escritorio y Firefox en Android y escritorio.
Lo que sí te resuelve Baseline
Baseline te ayuda a bajar ansiedad técnica. Te permite decidir con más serenidad si una API, una propiedad CSS o una capacidad del lenguaje JavaScript ya es una base razonable para construir sin depender de soluciones externas. Para un equipo, eso reduce bastante el ruido mental de revisar tablas de compatibilidad a cada rato.
Lo que no te resuelve Baseline
Lo que no te resuelve es si el patrón que estás diseñando es cognitivamente claro, accesible en la práctica o fácil de mantener dentro de un design system. Y esto es decisivo. Un componente puede estar construido sobre features totalmente “seguras” y seguir siendo una mala idea si obliga a aprender una interacción innecesariamente compleja, si rompe flujos de teclado o si añade más carga mental de la que ahorra. MDN insiste en que Baseline no sustituye pruebas con tecnologías asistivas, y también recuerda que los controles HTML nativos ya traen accesibilidad de teclado integrada; cuando se simulan con divs y JavaScript, esa robustez puede empeorar.
Compatibilidad no equivale a calidad de interacción
Este matiz cambia mucho la conversación. En una estrategia Baseline-first, la pregunta madura no es solo “¿puedo hacerlo sin librería?”, sino también:
“¿sin librería sigo resolviendo bien el problema de interacción?”
Si la respuesta es sí, perfecto: menos dependencias, menos peso mental, menos superficie de error.
Si la respuesta es no, una librería puede ser una decisión totalmente coherente con un enfoque Baseline-first.
El punto ciego más común: un combobox accesible no es solo un input bonito
El patrón oficial de WAI-ARIA define el combobox como un widget de entrada con un popup asociado que permite elegir un valor de una colección. Ese popup puede ser un listbox, grid, tree o incluso un dialog. Además, el patrón distingue entre combobox select-only y combobox editable, y describe cuatro comportamientos de autocompletado: sin autocompletado, lista con selección manual, lista con selección automática y lista con autocompletado inline.
Esto ya te da una pista importante: cuando hablas de combobox accesible, no estás hablando de “un select con esteroides”. Estás hablando de un patrón con bastantes decisiones de comportamiento, foco y semántica. Y cada una de esas decisiones afecta tanto a la accesibilidad como a la carga cognitiva.
Tiempo de decisión vs carga cognitiva
Aquí está uno de los criterios más útiles para decidir si conviene un select, un combobox accesible o una librería.
Un combobox puede reducir el tiempo de decisión cuando:
- hay muchísimas opciones,
- la persona necesita buscar por texto,
- existen sinónimos o coincidencias parciales,
- el filtrado dinámico ahorra desplazamiento y esfuerzo.
Pero también puede aumentar la carga cognitiva porque obliga a entender varias cosas a la vez:
- si el campo es editable o no,
- si escribir filtra o crea un valor libre,
- cómo se confirma una opción,
- qué pasa al pulsar
Escape, - si la opción destacada ya está seleccionada o solo enfocada,
- y cómo se navega por teclado dentro del popup.
Ese coste mental no siempre compensa. De hecho, muchas veces no compensa para nada.
Cuando el ahorro de tiempo es real
Un autocompletar bien implementado ayuda muchísimo en un buscador de ciudades, un selector de usuarios, una búsqueda de productos internos o un filtro avanzado con cientos de términos. Ahí sí tiene sentido pagar complejidad a cambio de velocidad.
Pero en formularios sencillos, filtros acotados o elecciones con pocas opciones, el supuesto “ahorro” suele ser más estético que real. La persona acaba pensando más sobre cómo funciona el componente que sobre qué opción necesita.
Casos reales donde select gana
Aquí conviene decir algo sin rodeos: en muchos escenarios, el select gana. No porque sea más “básico”, sino porque resuelve la tarea con menos ambigüedad.
MDN recuerda que el elemento <select> ya soporta atributos y comportamientos muy útiles como required, disabled, autofocus, multiple, size, agrupación con <optgroup> y hasta pistas para autocomplete. Además, en el patrón oficial de combobox se menciona que, en algunos navegadores, un <select> con size="1" puede exponerse a tecnologías asistivas como un combobox.
1. Formularios con pocas opciones y baja ambigüedad
Provincia, talla, franja horaria, método de contacto, cantidad, antigüedad, estado de una incidencia.
Si la lista es corta o moderada y la persona no necesita explorar por texto, un select suele ofrecer una interacción más directa.
No hay que adivinar si el campo filtra.
No hay que interpretar resaltados temporales.
No hay que aprender un mini-sistema dentro del formulario.
2. Filtros donde la prioridad es claridad, no velocidad extrema
En una interfaz de filtros, mucha gente añade un combobox accesible simplemente porque “queda más moderno”. Pero si el filtro contiene 8, 10 o 15 valores previsibles, un select o incluso un grupo de radios puede generar mucha menos fricción.
Esto es especialmente cierto cuando el objetivo principal no es acelerar a un usuario experto, sino hacer que cualquiera entienda el filtro al primer vistazo.
3. Selecciones cerradas donde no debe existir entrada libre
Si la persona no puede inventar un valor, forzar un campo que parece editable puede ser contraproducente. Un combobox editable transmite una expectativa: “aquí puedo escribir”. Si en realidad el sistema solo acepta una lista cerrada, a menudo es mejor usar un select y evitar señales confusas.
4. Contextos donde móvil y accesibilidad pesan más que el estilismo
Los controles nativos siguen teniendo una ventaja enorme: el navegador y el sistema operativo ya resuelven muchas cosas por ti. Y MDN insiste en un principio clave: los elementos nativos incorporan accesibilidad de teclado, mientras que las imitaciones con JavaScript suelen degradarla si no están muy bien hechas.
Regla práctica
Cuando el usuario solo necesita elegir y no buscar, el select suele ganar.
Cuando necesita buscar, filtrar, refinar o autocompletar, empieza a abrirse la puerta al combobox accesible.
Cuándo una librería sí sigue teniendo sentido
Aquí viene la parte importante del artículo: sí, hay escenarios en los que una librería sigue siendo una decisión sensata dentro de una estrategia Baseline-first.
1. Cuando necesitas un combobox accesible editable de verdad
Un combobox accesible bien hecho no se limita a abrir una lista al teclear. El patrón oficial contempla teclado, expansión y colapso del popup, navegación entre opciones, diferencias entre foco DOM y foco visual, y manejo de aria-activedescendant. En el ejemplo select-only de WAI, además, se explica que el script debe mantener visible la opción activa al cambiarla, algo especialmente relevante para personas que usan zoom del navegador.
Eso significa que construir uno bien desde cero no es imposible, pero sí es caro.
Caro en tiempo.
Caro en pruebas.
Caro en mantenimiento.
Si tu producto necesita:
- búsqueda con autocompletar,
- datasets grandes,
- coincidencias parciales,
- resultados remotos,
- navegación robusta por teclado,
- y soporte razonable con lector de pantalla,
entonces una librería madura puede ahorrarte errores muy serios.
2. Cuando el problema real es de datos, no de presentación
Una cosa es estilizar un control. Otra muy distinta es resolver una interacción de búsqueda con:
- debounce,
- peticiones remotas,
- cancelación,
- estados de carga,
- resultados vacíos,
- agrupación,
- resaltado de coincidencias,
- persistencia de selección,
- y feedback accesible cuando el contenido cambia.
MDN recuerda que para contenido dinámico cambiante pueden hacer falta mecanismos como aria-live, precisamente porque los lectores de pantalla no siempre anuncian bien actualizaciones constantes.
Si tu combobox accesible funciona como un pequeño motor de búsqueda dentro del formulario, la complejidad ya no es “hacer un dropdown”; la complejidad es orquestar una conversación accesible entre input, resultados, foco, red y estado visual. Ahí una buena librería puede tener mucho sentido.
3. Cuando tu design system necesita consistencia transversal
En un producto aislado, quizá puedes permitirte una solución artesanal. En un ecosistema con varios equipos, varias apps y muchos formularios, a veces lo más valioso no es que el componente sea 100% nativo, sino que sea consistente, testeado y gobernable.
Una librería o componente interno bien mantenido puede aportar:
- una API estable,
- un patrón de interacción uniforme,
- menos decisiones repetidas,
- y menos riesgo de que cada equipo implemente “su versión” de un combobox accesible.
Y eso también es reducir carga cognitiva, aunque esta vez del lado del equipo.
4. Cuando la plataforma aún no te cubre el caso con suficiente estabilidad
Hoy ya existen avances interesantes para personalizar <select>, pero MDN marca los customizable select elements como Limited availability, aclara que no forman parte de Baseline y advierte de soporte parcial, uso de features experimentales e incluso posibles fallos de hidratación con SSR en algunos frameworks.
Esta es una paradoja interesante: en una estrategia Baseline-first, podrías querer apostar por la plataforma… y aun así decidir que todavía no es el momento para cierto enfoque nativo avanzado en producción. En esos casos, una librería sigue siendo una solución razonable mientras la capacidad nativa madura de verdad.
La clave no es “nativo vs librería”, sino “claridad vs complejidad”
Ese es el marco más útil.
Una librería tiene sentido cuando compra una mejora real en:
- comprensión,
- velocidad,
- accesibilidad,
- consistencia,
- o mantenibilidad.
Si solo compra decoración, probablemente sobra.
Cómo decidir bien en un proyecto real
Te propongo un criterio simple y bastante honesto.
Usa select cuando…
El conjunto es cerrado, las opciones son comprensibles, la persona no necesita escribir, no hay búsqueda remota y el coste de aprender una interacción más compleja sería mayor que el beneficio.
Considera un combobox accesible con librería cuando…
Hay muchas opciones, el filtrado reduce fricción de verdad, necesitas autocompletar, el contenido cambia dinámicamente o el patrón debe integrarse en un design system robusto con pruebas de teclado y lector de pantalla.
Desconfía de la librería cuando…
Promete “accesibilidad” pero:
- rompe comportamiento nativo sin motivo,
- no explica su modelo de foco,
- no documenta bien teclado,
- no permite etiquetado y mensajes de error claros,
- o convierte algo que era una elección simple en una miniaplicación.
WAI advierte además algo que conviene grabarse: un ejemplo APG no debe copiarse sin más a producción, hay que probarlo con tecnologías asistivas, y sigue vigente la idea de que no ARIA is better than bad ARIA.
Dos enlaces internos que encajan muy bien aquí
En este artículo tiene muchísimo sentido enlazar, dentro del flujo natural del texto, a Componentes UI accesibles cuando hables de foco, estados, teclado y semántica de componentes complejos.
Y cuando el combobox muestre resultados que llevan a otra vista, a una ficha o a una página de detalle, también encaja enlazar a Links accesibles, porque ahí entran en juego el texto del enlace, la previsibilidad del destino y el contexto semántico de cada opción.
Preguntas frecuentes sobre Baseline-first, librerías y combobox accesible
¿Baseline-first significa dejar de usar librerías de UI?
No. Significa dejar de depender de ellas por costumbre. Si la plataforma ya resuelve bien el caso, probablemente no la necesitas. Si el problema real está en la interacción compleja, la accesibilidad avanzada o la consistencia del sistema, una librería puede seguir estando plenamente justificada.
¿Un select es siempre mejor que un combobox accesible?
Tampoco. Un select suele ser mejor cuando solo hay que elegir entre opciones claras y cerradas. Un combobox accesible tiene más sentido cuando hay búsqueda, autocompletar, filtros dinámicos o listas largas donde escribir reduce esfuerzo real.
¿Se puede construir un combobox accesible desde cero sin librería?
Se puede, pero no conviene banalizarlo. El patrón oficial contempla bastante complejidad de teclado, popup, foco y atributos ARIA, y además exige pruebas reales con tecnologías asistivas. Si vas a hacerlo desde cero, necesitas tiempo, criterio y testing serio.
Cuando una librería aporta valor de verdad
La madurez de una estrategia Baseline-first no se nota cuando un equipo dice “ya no usamos librerías”.
Se nota cuando sabe cuándo no hacen falta y cuándo sí siguen teniendo sentido.
Ese matiz importa.
Porque el objetivo no es demostrar pureza técnica. El objetivo es construir interfaces que se entiendan mejor, fallen menos y exijan menos esfuerzo mental.
Y en esa conversación, el combobox accesible es un excelente detector de madurez.
Si lo eliges porque de verdad mejora búsqueda, filtros y autocompletar, probablemente estás tomando una buena decisión de producto.
Si lo eliges solo porque “se ve más moderno que un select”, probablemente estás aumentando complejidad sin ganar claridad.
Una estrategia Baseline-first bien aplicada no te obliga a renunciar a las librerías.
Te obliga a justificarlas mejor.