Un selector personalizable no convierte un dropdown en accesible
Los navegadores ya permiten estilizar partes de un select nativo que antes empujaban a los equipos hacia componentes hechos a mano. El marco de Mintec conserva el control nativo como base, usa mejora progresiva con intención y deja los dropdowns propios para comportamientos que el navegador no resuelve.
Un selector personalizable no convierte un dropdown en accesible
Para un campo donde la persona elige una opción de una lista conocida, el sistema de diseño debería partir de <select> nativo. Las nuevas APIs para personalizarlo sirven para mejorar su encaje visual sin reescribir teclado, formulario y semántica desde cero. No vuelven seguro a un dropdown hecho con divs y JavaScript.
El selector parece un detalle menor hasta que llega la maqueta. Un plan necesita un icono. Una región pide una bandera. Un estado requiere color. El control del navegador se ve demasiado simple y alguien propone reemplazarlo por un componente de una librería. Ahí comienza una deuda que rara vez aparece en el presupuesto: apertura y cierre, foco, Escape, scroll, type-ahead, errores, zoom, lector de pantalla, valores enviados por el formulario y comportamiento táctil.
En Mintec usamos una regla más útil: primero decidimos si el comportamiento de selección que da el navegador sirve para el problema. Solo después definimos cuánto estilo necesita el control. MDN clasifica los selects personalizables como funciones experimentales y advierte que el HTML y CSS implicados aún tienen soporte limitado.[1] La documentación de Chrome explica la oportunidad: appearance: base-select coloca al select nativo en un modo configurable, y los motores que no lo entienden pueden seguir presentando el control común.[2] Ese es exactamente el terreno de la mejora progresiva. No es una excusa para lanzar un widget sin fallback.
El costo de reemplazar el control no está en el CSS
Un dropdown propio casi siempre luce bien en la demo. La demo usa mouse, cuatro opciones cortas, una pantalla perfecta y ninguna validación. Un formulario real tiene otra clase de visitantes. Hay gente que navega con teclado. Hay quien amplía la pantalla. Hay quien vuelve a un campo para corregirlo. Hay listas largas, mensajes de error y lectores de pantalla.
El select nativo ya responde a gran parte de eso. Su valor pertenece al formulario. Su etiqueta se expone. Sus opciones tienen comportamiento de teclado conocido. El navegador participa en la interacción en vez de que el equipo construya una carcasa visual sobre divs.
Esto no obliga a conservar la estética del control de hace veinte años. La propiedad appearance controla la presentación de ciertas piezas de interfaz nativa, y el modo base-select amplía las partes que se pueden estilizar en navegadores compatibles.[2][3] Lo que sí obliga es a no convertir una preferencia visual en una reimplementación silenciosa del comportamiento del navegador.
Es el mismo criterio detrás de Declarative Shadow DOM: entregar estructura útil antes de agregar código de cliente.
La decisión pasa por tres puertas
Un selector debería atravesar tres decisiones, en ese orden. Mientras más código propio agregue el equipo, más comportamiento tendrá que mantener durante toda la vida del sistema.
| Puerta | Úsala cuando | Qué conserva el sistema | Qué hay que rechazar |
|---|---|---|---|
| Select nativo | El campo elige un valor de una lista conocida y no necesita interacción rica | Etiqueta, valor, validación, teclado y envío | Reconstruirlo porque la flecha no combina con la marca |
| Select con mejora progresiva | La misma elección normal necesita más jerarquía visual en navegadores compatibles | Comportamiento nativo y capas visuales opcionales | Convertir el marcado mejorado en el único camino funcional |
| Componente propio | El campo no es un select: busca datos remotos, permite varios valores, crea opciones o contiene acciones | Toda la interacción, contrato de accesibilidad, integración de formulario y fallback | Llamar "select estilizado" a un autocompletado o un menú de comandos |
La primera puerta cubre más casos de los que parece: país, tamaño de empresa, paquete de servicio, sede, rango de presupuesto o idioma. Un icono de color dentro de la opción no basta para saltar a la tercera.
La segunda puerta es donde el cambio del navegador resulta interesante. Un selector de planes puede mostrar una marca visual; uno de idioma puede tener un identificador; una herramienta interna puede sumar un estado. Cuando el navegador no reconoce el detalle extra, el campo sigue siendo un select con texto y valores correctos.
La tercera puerta también es válida, pero exige llamarla por su nombre. Un selector de cliente con búsqueda, inventario asíncrono, múltiples opciones con chips removibles o acciones de comando necesita otra interacción. Si se disfraza de select desde el inicio, el equipo empieza con el patrón equivocado. Hay que elegir la semántica y el patrón ARIA adecuados, y presupuestar sus pruebas antes de prometer la interfaz.
Diseña una mejora que pueda desaparecer sin romper nada
El fallback no es el plan B. Es el producto base.
Empieza con HTML que funcione solo: etiqueta visible, name para envío, texto real dentro de las opciones y valores que no dependan de un script. Después encierra el tratamiento visual en detección de capacidades. Este CSS ilustra el patrón:
.plan-select {
inline-size: 100%;
min-block-size: 2.75rem;
font: inherit;
}
@supports (appearance: base-select) {
.plan-select,
.plan-select::picker(select) {
appearance: base-select;
}
.plan-select::picker(select) {
border: 1px solid var(--color-border);
border-radius: 0.75rem;
box-shadow: 0 0.75rem 2rem rgb(0 0 0 / 0.14);
}
}
La API seguirá cambiando, así que el contrato no puede ser "el picker luce idéntico en todo navegador". Debe ser "el campo funciona en todo navegador; donde existe soporte recibe detalle adicional". Chrome muestra que un motor sin appearance: base-select puede omitir contenido visual enriquecido y aun así renderizar el select normal.[2] Si el icono comunica algo imprescindible, debe existir también en texto.
El valor elegido debe ser claro; el contenido de la opción, honesto
La sintaxis enriquecida permite estructura adicional, incluido un botón de select y selectedcontent. Puede ser útil, pero también invita a meter una mini-interfaz dentro de un campo de formulario.
Marcamos dos límites en la revisión de diseño.
Primero, el control cerrado debe expresar el valor en lenguaje simple. Un paquete puede mostrar una marca, pero "Plan Growth, USD 1,200 al mes" necesita texto si el icono no carga o no se anuncia. En un sitio bilingüe, la longitud de etiqueta es una restricción del componente, no una decisión para una captura de pantalla.
Segundo, las opciones eligen valores. No son contenedores para enlaces, botones secundarios o argumentos de venta. MDN señala que el botón del select es inerte por defecto, así que los hijos interactivos se tratan como parte de un único botón y no como controles independientes.[1] El enlace para "comparar planes" debe ir junto al campo. La explicación debe ir debajo. El selector queda más claro y también más fácil de probar.
Este criterio está alineado con nuestra guía para prepararse para WCAG 3.0: un componente no se vuelve accesible por aprobar aislado. Etiqueta, valor, error e instrucciones tienen que funcionar juntos en el formulario donde la persona los encuentra.
El selector también tiene reglas de contenido
Muchos sistemas de diseño modelan un select con colores, radios y una flecha. Ese modelo se rompe cuando el negocio pide nombres de idioma, precios, disponibilidad o estado de inventario. El campo tiene reglas de contenido, no solo reglas de CSS.
Para cada variante de selector, documentamos estas decisiones junto al componente:
- Longitud máxima visible de la etiqueta en cada idioma soportado.
- Alternativa textual de toda marca visual.
- Si precio, disponibilidad o estado debe vivir en el texto de la opción.
- Redacción para estado vacío y error.
- Si la lista puede crecer hasta requerir búsqueda. Si la respuesta es sí, quizá el control correcto ya no sea un select.
Aquí se encuentran el modelo de contenido bilingüe y la arquitectura frontend. En nuestra comparación de arquitectura multilingüe con Astro y Next.js explicamos por qué la traducción no se resuelve al final con reemplazo de strings: cambia las restricciones de los componentes.
Incluye el fallback en las pruebas de aceptación
Diseño e ingeniería deben compartir una matriz breve.
| Prueba | Resultado esperado | Falla que debe bloquear el lanzamiento |
|---|---|---|
| Teclado | Tab llega al campo; teclas estándar cambian la opción; Escape tiene un resultado predecible | El foco se pierde, queda atrapado o exige mouse |
| Formulario | El valor elegido se envía y el error requerido identifica el campo | Lo visible no coincide con lo enviado |
| Tecnología asistiva | Etiqueta, valor, requisito y error tienen nombres útiles | Se anuncia como control genérico sin etiqueta |
| Navegador sin soporte | El select común sigue siendo usable y el texto comunica la opción | El formulario muestra una carcasa vacía o no seleccionable |
| Zoom y traducción | Etiquetas y errores largos siguen visibles a 200% y en todos los idiomas | El texto se corta o el significado depende solo del icono |
La fila del navegador sin soporte revela si la función se añadió como mejora o como dependencia. Si el select estándar es aceptable, una API limitada tiene poco riesgo. Si rompe el formulario, la paridad visual desplazó la calidad de producto.
El estándar que conviene dejar escrito
Los selects personalizables permiten explorar detalle visual nativo sin importar de inmediato una librería. Las reglas duraderas no cambian: controles nativos para trabajos nativos, información imprescindible en texto, soporte probado y componentes propios solo cuando el producto necesita una interacción que la plataforma no ofrece.
Sources
[1] https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Forms/Customizable_select — MDN: Customizable select elements [2] https://developer.chrome.com/blog/a-customizable-select — Chrome for Developers: A customizable select [3] https://developer.mozilla.org/en-US/docs/Web/CSS/Reference/Properties/appearance — MDN: appearance
Preguntas Frecuentes
¿Qué es un select personalizable?
Es un select nativo que usa funciones emergentes como appearance: base-select y ::picker(select) para estilizar partes del control sin perder la semántica de formulario. Como el soporte sigue siendo limitado, debe conservar un fallback de select estándar.
¿Debo reemplazar los selects nativos por dropdowns propios?
Solo si el comportamiento de producto no cabe en un select nativo. Para una elección única y conocida, la base debe seguir siendo el select; los detalles visuales se pueden añadir como mejora progresiva.
¿Cómo se prueba un select personalizable?
Se prueban teclado, nombre para lector de pantalla, envío del formulario, zoom, estado de error y el fallback en navegadores que no soportan la mejora.
