Componente de entrada personalizado

¿Qué es un componente de entrada personalizado?

Un componente de entrada personalizado es un control de formulario que construyes tú en lugar de usar el nativo del navegador: un selector de rango de fechas, un campo de etiquetas, un combobox, un campo de teléfono con máscara o un deslizador con estilo propio. Para el usuario debe parecer y comportarse como un input, y para el código debe participar en el formulario como uno: con nombre, valor, etiqueta, validación y soporte de teclado. Si falta alguna de esas cosas, es un widget con aspecto de input, no un input.

Primero lo nativo, lo personalizado solo si hace falta

MDN lista muchos tipos de input nativos: text, email, url, tel, number, range, date, time, datetime-local, month, week, color y file, además de los atributos inputmode, autocomplete, required, pattern y min/max. Aportan comportamiento de teclado, teclados móviles, autocompletado y validación sin esfuerzo. La guía ARIA Authoring Practices (APG) del W3C deja claro el coste de la alternativa: a diferencia de los inputs HTML, los roles ARIA no dan al navegador comportamiento de teclado ni estilos, así que hay que construirlo todo, y «ningún ARIA es mejor que un mal ARIA». Construye un componente propio solo cuando ningún control nativo sirva, por ejemplo un combobox con búsqueda o un campo de varios valores.

Cómo construir uno que funcione

• Parte de un elemento nativo siempre que puedas. Un contenedor con estilo alrededor de un <input> o <select> real conserva casi todo el comportamiento.
• Sigue el patrón de la APG para tu widget (combobox, listbox, slider, etc.). Define los roles, estados y teclas que los usuarios esperan. Un rol es una promesa: si pones role="combobox", debes cumplir lo que implica.
• Dale una etiqueta visible asociada al control y no uses el placeholder como etiqueta. Según MDN desaparece al escribir y no siempre se anuncia.
• Hazlo operable con teclado, con un orden de foco razonable, un estilo de foco visible y las teclas que pide el patrón. Pruébalo sin ratón.
• Expón el estado con ARIA donde falte la semántica nativa: nombre, rol, expandido, inválido, obligatorio.
• Intégralo en el formulario. Un web component puede asociarse al formulario: define static formAssociated = true, llama a attachInternals() y usa setFormValue() para el valor enviado y setValidity() para la validación. El mismo objeto ElementInternals puede fijar el rol por defecto y propiedades ARIA. MDN lo marca como ampliamente disponible en los navegadores desde marzo de 2023. Sin esto, el valor de tu componente no se envía con el formulario.
• Mantén la alternativa nativa. Si JavaScript falla, un input simple debería seguir funcionando.

Errores habituales

• Un <div> con un manejador de clic y sin rol, etiqueta ni soporte de teclado.
• Reimplementar un control nativo (un campo de fecha, un selector de archivos) con peor accesibilidad que la del propio navegador.
• Mostrar la validación solo con color, o con un mensaje de error que los lectores de pantalla nunca leen.
• Romper pegar, autocompletar, deshacer o la selección de texto con una máscara de entrada agresiva.
• Probar con un solo navegador y sin tecnología de apoyo. La propia APG pide probar cada combinación de navegador y tecnología de apoyo antes de pasar a producción.

Inputs personalizados, estándares y monitorización

Los inputs personalizados afectan de lleno a las pautas de accesibilidad para el contenido web (WCAG): etiquetas, acceso por teclado e identificación de errores forman parte de ellas y condicionan la experiencia de usuario en conjunto. Un editor de texto enriquecido es un ejemplo habitual y de los más difíciles de hacer accesible. Además, el código pesado de un widget cuesta velocidad. La monitorización de velocidad de página de LoadFocus ejecuta auditorías de Lighthouse programadas, incluida la categoría de accesibilidad y los Core Web Vitals, así que un formulario lento o con avisos se nota tras una versión nueva. Las comprobaciones automáticas solo detectan una parte de los problemas, por eso conviene mantener las pruebas manuales con teclado y lector de pantalla.

Preguntas frecuentes sobre componentes de entrada

¿Cuándo uso un input personalizado en lugar de uno nativo?

Cuando ningún control nativo encaja, como un combobox con búsqueda, un campo de etiquetas o un rango de fechas. Para texto, números, fechas, colores y archivos, un input nativo es más accesible y más barato de mantener.

¿Los inputs personalizados se envían con el formulario?

Solo si están conectados a él. Un custom element asociado al formulario con ElementInternals puede fijar el valor de envío y la validez. Si no, mantén sincronizado un input nativo oculto o envía el valor tú mismo.

¿Siempre necesito ARIA?

No. Un control basado en un input real necesita poco o nada. ARIA sirve para cubrir huecos semánticos en widgets propios, y un ARIA incorrecto es peor que ninguno.

¿Cómo pruebo la accesibilidad de un input personalizado?

Úsalo solo con el teclado, comprueba que un lector de pantalla anuncia la etiqueta y el estado, y pasa una auditoría automática. Después, prueba con los navegadores y tecnologías de apoyo que usan tus usuarios de verdad.