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.