Actualizado: .

Un select nativo es un punto de partida razonable para una elección sencilla. Un componente personalizado debe responder a una necesidad del producto; junto con su aspecto, usted asume su semántica, manejo por teclado, foco, estados y compatibilidad con tecnologías de apoyo.

Empiece por un campo que ya sabe comportarse como tal

<label for="topic">Tema de la consulta (obligatorio)</label>
<select id="topic" name="topic" required>
  <option value="">Elija un tema</option>
  <option value="design">Diseño de interfaces</option>
  <option value="development">Desarrollo</option>
</select>

Es una base completa para elegir una opción, no un elemento provisional que deba ocultarse al lector de pantalla. Sigue necesitando una buena disposición, contraste, opciones claras y gestión de errores, pero la plataforma proporciona el modelo básico de interacción.

Por qué alternar entre dos select no es fiable

A veces se propone mostrar el select nativo con :focus-visible y mantener uno personalizado para el clic. Así se crean dos versiones del mismo campo sin garantizar que ninguna sea accesible. El método de entrada no determina la presencia de una tecnología de apoyo: el lector de pantalla del teléfono funciona con gestos y una persona puede alternar entre ratón y teclado.

opacity: 0 no elimina el elemento del árbol de accesibilidad ni del orden de foco. pointer-events: none cambia el manejo del puntero, pero no resuelve las demás cuestiones. aria-hidden oculta la semántica, pero no impide por sí solo recibir el foco. El resultado puede ser un elemento invisible que recibe el foco o dos representaciones del campo con valores diferentes.

Un híbrido solo es viable como arquitectura diseñada y probada específicamente. Necesita una única fuente del valor y un funcionamiento correcto de reset, disabled, required, la validación y el envío. La presencia de un campo nativo oculto no demuestra la accesibilidad de la parte personalizada.

Qué debe cumplir un selector personalizado

Antes de escribir manejadores de eventos, elija el patrón exacto. Seleccionar en una lista sin escribir no es lo mismo que un combobox con búsqueda. No mezcle los roles menu, listbox y combobox simplemente porque todos se despliegan visualmente.

  • El nombre accesible, el rol y el valor actual deben resultar comprensibles.
  • El estado desplegado y la relación con la lista deben exponerse mediante programación.
  • La opción seleccionada y la activa son estados diferentes; no deben confundirse.
  • Las teclas para abrir, desplazarse, confirmar, cancelar y buscar deben corresponder al patrón elegido.
  • El foco se desplaza siguiendo un modelo coherente o permanece en el control con un aria-activedescendant correcto.
  • El envío, el restablecimiento, los errores y las opciones no disponibles deben coincidir con la interfaz visible.

Utilice el patrón combobox de APG como especificación de comportamiento. No garantiza que cualquier ejemplo copiado funcione igual con todos los navegadores y lectores de pantalla: APG exige expresamente comprobar la compatibilidad.

El error debe explicar cómo corregirlo

«Valor incorrecto» obliga a adivinar. «Introduzca un correo con el formato [email protected]» propone una acción. No sustituya label por un placeholder, que desaparece al escribir. Conserve los datos introducidos después de un envío fallido y asocie la explicación al campo correspondiente.

<!-- Ejemplo de estado después de detectar un error -->
<label for="email">Correo electrónico</label>
<input id="email" name="email" type="email" value="name@"
  autocomplete="email" aria-invalid="true"
  aria-describedby="email-error">
<p id="email-error">Introduzca un correo con el formato [email protected].</p>

No marque previamente con aria-invalid todos los campos vacíos. Cuando se corrija el error, retire el estado incorrecto y actualice el mensaje. Si hay varios errores, resulta útil un resumen con enlaces a los campos; cuando el envío tiene éxito, una confirmación clara que no obligue a buscar visualmente.

Un diálogo modal controla más que su aspecto

Al abrir un diálogo, el foco inicial debe tener sentido. En un estado modal, Tab no debe pasar al fondo y este no debe seguir siendo interactivo. Hacen falta un nombre claro y una forma accesible de cerrar el diálogo. Después de cerrarlo, el foco suele volver al elemento que lo abrió, o al siguiente lugar lógico si aquel ya no existe.

No asigne aria-modal="true" a una ventana que solo parezca modal. El atributo no mantiene el foco dentro ni bloquea el fondo. En un diálogo largo no siempre conviene enfocar inmediatamente el primer campo: la persona podría pasar por alto el encabezado y las instrucciones.

La autenticación también forma parte de la accesibilidad

No bloquee el pegado de contraseñas ni los gestores de contraseñas. Para códigos de un solo uso, compruebe el pegado completo y el autocompletado: seis casillas decorativas no deberían exigir seis esfuerzos separados. El criterio 3.3.8 AA limita las pruebas cognitivas obligatorias durante la autenticación, pero incluye condiciones y excepciones; no prohíbe de forma absoluta todos los CAPTCHA ni las contraseñas.

Compruebe las transiciones entre estados

Un solo campo necesita al menos los estados «vacío», «rellenado», «error», «corregido», «enviando» y «completado». Para una lista se añaden «abierta», «sin resultados» y «opción seleccionada». En cada uno compruebe qué se ve, qué se anuncia, dónde está el foco, qué valor se enviará y cómo cancelar.

Esta matriz de estados detecta más defectos reales que comparar un select cerrado con una maqueta. Preste especial atención a la latencia: si desaparece el botón de envío, el foco puede perderse, y activarlo repetidamente puede duplicar solicitudes. La solución debe conservar un estado claro y un manejo predecible.

Fuentes y estado de los estándares verificados el 5 de noviembre de 2026.

Aplicar estas prácticas con un asistente de IA

A partir de esta investigación, creamos skills abiertos para Codex y Claude Code que ayudan a analizar y mejorar sitios web y aplicaciones. Accessible UI guía la revisión de la semántica, el teclado, el foco, los formularios y el contraste; Adaptive Interfaces ayuda a adaptar la interfaz al tamaño de la ventana, la escala del texto, el teclado y los dispositivos plegables. El agente examina el proyecto real, propone mejoras fundamentadas y verifica los cambios acordados. Estos skills no sustituyen las pruebas con usuarios y tecnologías de asistencia.

Las prácticas de esta serie están reunidas en el skill Accessible UI en GitHub: semántica, teclado, foco, formularios, contraste y verificación. Las instrucciones están en inglés. Consulte las instrucciones de instalación y los ejemplos de uso en el primer artículo.