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.

Durante años, muchos equipos de frontend han basado sus decisiones en tres preguntas: “¿Se puede hacer?”, “¿queda moderno?” y “¿existe una librería para esto?”. Sin embargo, este enfoque suele priorizar la novedad sobre la calidad, resultando en productos innecesariamente complejos.

Como respuesta, surge el enfoque «Baseline-first». No es una moda, sino una metodología madura que propone:

1. Aprovechar la plataforma: Empezar por lo que el navegador ya resuelve de forma nativa.
2. Validar la compatibilidad: Usar capacidades que ya son seguras en los navegadores principales.
3. Justificar la complejidad: Añadir capas extra solo cuando aportan un valor real al usuario.

Adoptar el «Baseline-first» reduce la incertidumbre técnica y el coste de mantenimiento. Un ejemplo claro es el combobox: a menudo nos complicamos creando soluciones personalizadas con ARIA y filtrados complejos, cuando un <select> nativo ofrecería una mejor experiencia, con menos riesgo y menor carga cognitiva.

En definitiva, el corazón de esta filosofía no es preguntarse «qué podemos programar», sino «qué necesita el usuario y qué nos ofrece ya la web».

Qué es exactamente Baseline y por qué cambia la conversación

Baseline es el estándar de referencia que nos permite saber qué funciones de la web funcionan de forma uniforme en todos los navegadores principales. Para facilitar la toma de decisiones, la documentación oficial clasifica las tecnologías en dos etapas clave:

• Newly available (Recién disponible): La función ya es compatible con todos los motores de búsqueda principales (Chrome, Firefox, Safari y Edge). Es el momento de empezar a experimentar.
• Widely available (Ampliamente disponible): Han pasado 30 meses desde que la función alcanzó el estado anterior. En este punto, se considera totalmente segura para la mayoría de los sitios web, permitiéndonos usarla sin preocuparnos por fallos de soporte o falta de compatibilidad.

Actualmente, esta definición abarca el conjunto esencial de navegadores, tanto en sus versiones de escritorio como móviles, ofreciendo una visión real de la web moderna.

Diferenciando disponibilidad de madurez

Una de las claves del éxito para un equipo es entender que Newly available no es sinónimo de «úsalo mañana en cualquier contexto». Esta etiqueta indica que una función ya es interoperable en los navegadores principales, pero el estado Widely available aporta la capa de madurez necesaria. Esos 30 meses de diferencia garantizan un soporte sólido para la gran mayoría de las audiencias. De hecho, la propia documentación de web.dev lo recomienda como la opción por defecto cuando no existen requisitos técnicos excepcionales.

Baseline-first no es miedo a la innovación

Es importante aclarar que este enfoque no implica desarrollar como si estuviéramos en 2016; significa innovar con estrategia. Se trata de distinguir entre una mejora real y una «fantasía de implementación».

Si una capacidad está en Baseline y resuelve un problema, el camino es claro. Si aún no lo está, pero tu contexto permite una estrategia de mejora progresiva (progressive enhancement), adoptarla puede tener sentido. El cambio es el orden mental: primero la plataforma, luego la mejora funcional y, finalmente, la librería. Nunca al revés.

Lo que cambia de verdad dentro del equipo

Cuando un equipo adopta esta forma de trabajar, cambia la conversación en PRs, en diseño y en refinamientos técnicos.

Ya no se debate solo si un componente “queda mejor” customizado. Se debate:

• si el control nativo ya cubre el caso,
• si la mejora es interoperable hoy,
• si compensa el coste de accesibilidad,
• si la experiencia mejora también con teclado,
• y si el usuario decide más rápido sin entender menos.

Ese último punto importa muchísimo. Porque una interfaz puede reducir el tiempo de interacción y, aun así, aumentar la carga cognitiva. Y eso nos lleva al ejemplo estrella.

El caso perfecto para entenderlo: combobox accesible frente a select nativo

Un combobox no es “un select bonito”. Según la guía de patrones ARIA de WAI, es un widget de entrada con un popup asociado que puede mostrar una listbox, un grid, un tree o incluso un dialog. Puede ser editable, permitiendo escribir, o select-only, donde solo eliges de una colección. MDN también lo describe como un widget compuesto que combina un campo o botón con un popup de valores posibles.

Esto importa porque, en muchos equipos, se mete todo en el mismo saco: dropdown, select custom, autocomplete, buscador de opciones, multiselect… y no, no es lo mismo.

Cuándo gana claramente un select

Hay muchos casos reales donde el select nativo sigue siendo la mejor solución:

Casos donde un select suele ser mejor que un combobox

Elegir una opción cerrada y relativamente acotada.
País, rango de edad, talla, prioridad, orden de resultados, tipo de documento, provincia, departamento, idioma. Si la lista no es absurda y el usuario no necesita buscar por texto libre, un select suele resolver el problema con menos fricción.

Cuando la tarea es confirmar, no explorar.
Si la persona ya sabe que solo tiene que escoger una opción válida dentro de un conjunto cerrado, introducir autocompletar puede añadir trabajo mental innecesario. Ahora tiene que pensar qué escribir, si la opción aparecerá, cómo filtra el sistema y si hay coincidencias parciales.

Cuando la accesibilidad no puede ser negociable.
El HTML semántico ya aporta muchísimo. MDN insiste en que usar el elemento correcto para el propósito correcto da al navegador “hooks” de accesibilidad incorporados. Además, una interfaz accesible debe funcionar con teclado, algo que los controles nativos suelen resolver mucho mejor de serie que muchos componentes custom.

Cuando no quieres mantener un mini-sistema operativo dentro de un campo.
Porque eso es, en el fondo, un combobox mal planteado: foco, popup, opciones activas, selección, autocompletado, anuncios para lector de pantalla, cierre con Escape, navegación con flechas, sincronización entre valor visual y valor real, soporte móvil, estados vacíos, carga asíncrona…

Y aquí entra una regla de oro de ARIA: “No ARIA is better than Bad ARIA”. La propia guía APG lo dice de forma muy directa: si ARIA se aplica mal, puede falsear la experiencia no visual y generar consecuencias graves para quienes usan lector de pantalla.

Cuándo sí merece la pena construir un combobox accesible

Ahora bien, tampoco se trata de prohibirlos. Un combobox accesible sí puede ser la mejor opción cuando se cumplen condiciones concretas:

• la lista es muy larga,
• el usuario necesita buscar dentro de las opciones,
• hay sinónimos o coincidencias parciales útiles,
• el sistema debe sugerir resultados mientras se escribe,
• se trabaja con datos remotos,
• o se permite un valor libre además de sugerencias.

En esos casos, el autocompletar sí reduce esfuerzo. Pero solo si está bien hecho. Porque un combobox mal implementado no reduce fricción: la redistribuye. Quita scroll, pero añade ambigüedad. Quita listado visible, pero añade incertidumbre.

Qué implica de verdad el patrón ARIA de un combobox

Aquí está el punto donde muchas implementaciones se quedan cortas. Un combobox accesible no es solo poner role="combobox" y abrir una cajita.

Según MDN y la guía APG, normalmente tienes que contemplar, como mínimo, estos aspectos:

• aria-expanded para indicar si el popup está abierto o cerrado,
• aria-controls para relacionar el control con el popup,
• aria-autocomplete si existe comportamiento de sugerencias,
• aria-activedescendant cuando el foco DOM permanece en el input pero la opción activa está dentro del popup,
• etiquetado correcto mediante label, aria-labelledby o aria-label,
• y un popup con rol adecuado, como listbox, grid, tree o dialog.

Además, la guía APG explica que, en comboboxes con listbox, el foco puede quedarse en el propio combobox mientras la opción activa se comunica con aria-activedescendant, y que aria-autocomplete debe reflejar el comportamiento real: none, list o both. También recomienda usar aria-controls frente al viejo aria-owns en implementaciones actuales.

Eso ya te da una pista muy práctica: si tu caso no necesita toda esa maquinaria, probablemente no necesita un combobox.

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

Muchas interfaces modernas optimizan una métrica superficial: que el usuario haga algo “más rápido”. Pero rapidez no siempre significa claridad.

El tiempo de decisión puede bajar mientras la carga cognitiva sube

Imagina un selector de país con autocompletar. Sobre el papel parece más eficiente: escribes “es” y aparece España. Perfecto.

Pero en la práctica, esa mejora solo existe si el usuario:

• entiende que se puede escribir,
• sabe cómo nombrar el valor,
• confía en que el sistema le sugerirá bien,
• interpreta correctamente el estado del popup,
• y puede corregir errores sin perder contexto.

En un select nativo, la interacción es menos “cool”, pero la intención suele ser más evidente. Hay un campo de elección, una lista de opciones y un comportamiento estable. En un combobox, la velocidad puede aumentar para usuarios expertos, pero la carga cognitiva también puede crecer porque el sistema exige más hipótesis mentales: “¿esto filtra o busca?”, “¿acepta texto libre?”, “¿qué pasa si no selecciono una sugerencia?”, “¿el primer resultado ya está activo?”

Esa es una comparación muy útil en diseño avanzado: no preguntarte solo cuánto tarda alguien en completar una acción, sino cuánto tiene que pensar para completarla sin dudas.

Un autocompletar no siempre simplifica

Esto se ve muchísimo en filtros de ecommerce, buscadores internos y formularios enterprise.

Hay equipos que convierten en combobox absolutamente cualquier control porque creen que escribir siempre es mejor que elegir. Pero no siempre es así:

• Para listas cortas o medianas, escribir puede costar más que reconocer.
• Para opciones conocidas pero poco distintivas, filtrar puede confundir más que ayudar.
• Para usuarios con teclado, lector de pantalla o menor familiaridad digital, una interacción más compleja puede volver el flujo menos predecible. La operabilidad por teclado es un requisito básico de accesibilidad, y cuanto más custom es el control, más fácil es romperla.

En otras palabras: menos tiempo de escritura no equivale automáticamente a menos esfuerzo mental.

Baseline-first en diseño de interacción: cómo decidir con criterio

Trabajar Baseline-first obliga a diseñar mejor, no solo a programar distinto. Te obliga a preguntarte qué patrón corresponde realmente al problema.

Primera pregunta: ¿necesito elección, búsqueda o ambas?

Antes de diseñar un componente, conviene separar estos tres escenarios:

Elección cerrada.
El usuario solo necesita escoger una opción válida. Aquí el select suele ser suficiente.

Búsqueda guiada.
El usuario necesita encontrar rápido entre muchas opciones. Aquí puede tener sentido un combobox con sugerencias.

Entrada libre con ayuda.
El usuario puede escribir valores propios, pero el sistema sugiere formatos o coincidencias. Aquí el combobox editable sí encaja mejor.

Confundir estas tres cosas genera componentes híbridos que parecen flexibles, pero son difíciles de entender.

Segunda pregunta: ¿qué me da la plataforma gratis?

Esta es muy Baseline-first. Antes de construir, mira qué te da el navegador:

• semántica nativa,
• foco,
• teclado,
• envío del formulario,
• comportamiento móvil razonable,
• integración con tecnologías de asistencia.

Cuanto más te apartas de eso, más piezas tienes que reconstruir tú. Y no basta con reconstruirlas “más o menos”. Tienes que reconstruirlas bien.

Tercera pregunta: ¿hay una mejora progresiva real?

Aquí entra la filosofía de progressive enhancement. Una buena arquitectura Baseline-first podría ser algo así:

1. Empiezas con un control nativo funcional.
2. Garantizas que el formulario funciona sin JavaScript.
3. Añades mejora solo si el caso lo pide de verdad.
4. Mantienes una experiencia equivalente con teclado y lector de pantalla.
5. Evitas romper el flujo base por querer una interacción más vistosa.

Ese enfoque no solo es más robusto. También suele ser más barato de mantener.

Ojo con datalist: parece una salida fácil, pero no siempre lo es

En este debate suele aparecer otra opción: “¿y si usamos datalist?”

Sobre el papel, parece tentador. Tiene sabor nativo y sugiere valores. Pero aquí conviene ir con cuidado. MDN indica que datalist presenta varios problemas de accesibilidad: el tamaño de fuente de las opciones no escala con el zoom, el estilado para alto contraste es muy limitado o inexistente, y algunas combinaciones de lector de pantalla y navegador no anuncian el contenido del autosuggest. Además, en la documentación de MDN en español aparece marcado como Limited availability, es decir, no forma parte de Baseline porque no funciona en algunos de los navegadores más usados.

Eso lo convierte en un ejemplo estupendo de pensamiento Baseline-first: algo puede parecer nativo y aun así no ser una apuesta sólida para todos los contextos.

Cómo adopta esto un equipo sin volverse lento

Una objeción habitual es: “todo esto suena muy bien, pero nos ralentiza”. En realidad, suele pasar lo contrario. Cuando un equipo tiene criterio para descartar complejidad innecesaria, gana velocidad de entrega y baja deuda técnica.

Un checklist útil para decisiones de UI

Antes de crear un componente custom, podéis revisar esto:

Checklist Baseline-first para componentes interactivos

1. ¿Qué problema resuelve el usuario?
No el diseñador, no el framework: el usuario.

2. ¿Existe ya un elemento HTML que resuelva la base semántica?
Si existe, empieza ahí.

3. ¿La mejora que queremos está en Baseline para nuestro target?
Hoy incluso puedes trasladar Baseline a tooling con consultas de Browserslist como baseline widely available, baseline newly available o un año concreto como baseline 2024. Eso permite alinear decisiones de compatibilidad con build, linting y transpilado.

4. ¿La mejora aporta valor real o solo libertad visual?
No es lo mismo resolver una necesidad que forzar una estética.

5. ¿Funciona con teclado?
Debe funcionar de verdad, no “más o menos”.

6. ¿Qué pasa si JavaScript falla o llega tarde?
Una base usable importa.

7. ¿Quién mantendrá este patrón dentro de 12 meses?
Porque alguien lo hará.

Errores muy comunes cuando se ignora este enfoque

• confundir un dropdown visual con un patrón ARIA completo,
• asumir que “más moderno” equivale a “más usable”,
• copiar atributos ARIA sin entender el modelo de foco,
• romper teclado por estilado o virtualización,
• esconder opciones detrás de autocompletado cuando reconocer sería más fácil que recordar.

Todo esto conecta muy bien con un enlace interno a Componentes UI accesibles, porque el problema rara vez es solo técnico: es de patrón, semántica y expectativas. Y también encaja con Links accesibles, porque al final una buena interacción depende de que la intención del sistema sea evidente desde el principio.

Preguntas frecuentes: Entendiendo el enfoque Baseline-first

1. ¿Significa esto renunciar a librerías o componentes headless?

No. Significa dejar de depender de ellos por defecto. Puedes usarlos, pero solo tras validar que el problema realmente lo requiere y que el aumento en la complejidad está justificado. El Baseline-first no es purismo técnico; es una estrategia de priorización inteligente.

2. ¿Entonces siempre debo elegir un <select> sobre un combobox?

Tampoco. Si tienes una lista de cientos de elementos, necesitas sugerencias dinámicas o permitir texto libre, un combobox es la solución adecuada. Lo importante es romper la inercia: no construyas un componente personalizado si un selector nativo resuelve el caso con menos riesgo y mejor rendimiento.

3. ¿Cómo empiezo a introducir Baseline-first en mi equipo?

No necesitas cambiarlo todo de la noche a mañana. Puedes empezar con estos dos pasos:

Integra Baseline en tu tooling: Ya existen formas de conectar estos estándares con herramientas como Browserslist. Esto permite que las decisiones de diseño y producto se traduzcan automáticamente en configuraciones reales de proyecto.

Cambia el criterio de conversación: En cada refinamiento o pull request, haz una pregunta básica: “¿Qué perdemos al abandonar lo nativo?”. Si la respuesta incluye accesibilidad, estabilidad, soporte de teclado o facilidad de mantenimiento, piénsalo dos veces.

---

Menos código, mejores productos

Adoptar Baseline como brújula no es una limitación creativa; es un ejercicio de madurez técnica. Nos permite centrar el esfuerzo del equipo donde realmente importa: en resolver problemas de negocio y mejorar la vida del usuario, en lugar de reinventar ruedas que la plataforma web ya hace girar con eficiencia.