Cómo crear formularios web accesibles que todos puedan completar
Casi todo un formulario accesible es HTML nativo haciendo su trabajo. Dale a cada campo una etiqueta visible y asociada de forma programática (un placeholder no es una etiqueta); marca los campos obligatorios con el atributo required y no con un asterisco solo; usa los tipos de input correctos y el atributo autocomplete para que el navegador ayude; y agrupa los campos relacionados con fieldset y legend. Maneja bien los errores, que es donde fallan la mayoría de los formularios: el mensaje debe identificar el problema y sugerir el arreglo, estar ligado a su campo con aria-describedby y aria-invalid, nunca depender solo del color, anunciarse por una región viva, y llevar el foco al primer error al enviar. Mantén cada control operable por teclado con un anillo de foco visible y un orden lógico, nunca deshabilites el botón de enviar, y nunca envíes de forma automática al cambiar un valor. Después pruébalo de la única manera que encuentra problemas reales — con un teclado y un lector de pantalla. Haz esto y el formulario funciona igual para un usuario ciego, uno que navega por teclado y uno de baja visión, que es justo el público que la ley ahora espera que atiendas.
Por qué los formularios son la superficie que más importa
En todo el resto de un sitio, la accesibilidad es sobre leer; en un formulario, es sobre hacer. Los formularios son donde los usuarios se registran, compran, postulan y te contactan, así que cuando un formulario es inaccesible no se limita a crear una mala experiencia: bloquea a la persona de completar la acción esencial, lo que para un negocio significa clientes perdidos y responsabilidad legal (WCAGKit, 2026). Dado que una de cada cuatro personas adultas en EE. UU. vive con una discapacidad, esto no es un caso marginal (UXPin, 2025).
La parte alentadora es que los fallos se concentran en dos lugares fáciles. WebAIM reporta que más del 60% de los problemas de accesibilidad de formularios vienen de un etiquetado y un manejo de errores incorrectos (UXPin, 2025). Son también de los fallos más comunes en la web en general — un análisis del sector halló que el 94,8% de los sitios no pasa las verificaciones de accesibilidad, con el etiquetado de formularios y la identificación de errores cerca del tope de la lista (beAccessible, 2026). Y las herramientas automáticas por sí solas no te salvan: se pierden cerca del 70% de los fallos, por lo que el trabajo manual del final de esta guía no es opcional (508Blueprint, 2026).
Etiqueta cada campo — y no, un placeholder no es una etiqueta
Las etiquetas son la piedra angular. Cada input, select y textarea necesita una etiqueta programática, creada con un elemento label cuyo for coincide con el id del input, o envolviendo el input dentro del label (508Blueprint, 2026). Sin ella, un lector de pantalla anuncia el campo como “edit text” sin contexto, dejando que la persona adivine qué escribir (TestParty, 2025).
El atajo tentador —usar el texto de placeholder como etiqueta— falla por dos motivos: el placeholder desaparece en cuanto alguien empieza a escribir, rompiendo la WCAG 3.3.2, y no se anuncia de forma consistente entre lectores de pantalla, rompiendo la 4.1.2, así que un solo input sin etiqueta puede fallar tres criterios a la vez (508Blueprint, 2026). Mantén las etiquetas visibles, ubicadas de forma consistente arriba o al lado del campo, y concisas — “Correo” gana a “Por favor ingresa aquí tu correo” (TestParty, 2025). También ayuda mantener iguales la etiqueta visible y el nombre accesible, lo que deja a los usuarios de voz decir lo que ven.
Marca los campos obligatorios y agrupa los relacionados
Indica los campos obligatorios de las dos formas. De modo programático, usa el atributo required para que los lectores de pantalla anuncien “obligatorio” como parte del campo; de modo visual, añade un asterisco o la palabra al lado, con una nota cerca del formulario que explique qué significa el asterisco — y nunca dejes que el color cargue ese significado (508Blueprint, 2026). Un asterisco solo es una convención visual que la tecnología de asistencia no interpreta.
Los controles relacionados van en un grupo. Envuelve los conjuntos de radio buttons, los grupos de casillas y los campos de varias partes como una dirección en un fieldset con un legend, para que un lector de pantalla anuncie el propósito del grupo antes de cada control dentro de él (Yale, 2026). Una advertencia: no anides fieldsets uno dentro de otro, ya que algunos lectores de pantalla lo manejan de forma impredecible (reciteme, 2026).
Usa los tipos de input correctos y autocomplete
El atributo type hace trabajo real de accesibilidad. Usar email, tel, number, url, date y search le da a los usuarios móviles el teclado en pantalla correcto y le da al navegador un manejo integrado sensato (TestParty, 2025). Cada uno sigue necesitando su propia etiqueta — los inputs especializados no se autodescriben (reciteme, 2026).
El atributo autocomplete no es un lujo, es un requisito: el criterio de éxito 1.3.5 de la WCAG lo exige en campos que recogen datos personales comunes, con valores como autocomplete="name", "email", "street-address" y "cc-number" (WCAGKit, 2026). Permite que navegadores y gestores de contraseñas rellenen los campos de forma automática, recortando el esfuerzo cognitivo y motor que exige un formulario — una ayuda concreta para usuarios con discapacidad motora o cognitiva, y menos abandono para todos (getAccessGuard, 2026).
Los errores son donde se caen los formularios accesibles
La validación es la etapa donde se rompen los formularios por lo demás decentes. Empieza por la redacción: un error debe identificar el problema y sugerir el arreglo, así que “Ingresa un correo válido” en vez de “Entrada inválida” (UXPin, 2025). Luego conéctalo para que la tecnología de asistencia lo pueda percibir — asocia el mensaje con su campo usando aria-describedby, y pon aria-invalid="true" en el campo para que su estado se exponga más allá de la señal visual (getAccessGuard, 2026).
Dos piezas más lo completan. Nunca señales un error solo con color — un borde rojo por sí solo incumple la WCAG 1.4.1, así que acompáñalo con texto y un icono que un usuario daltónico o de lector de pantalla pueda percibir (WCAGKit, 2026). Y anúncialo: pon el mensaje en una región aria-live o usa role="alert", y al enviar mueve el foco al primer error, o a un resumen de errores al inicio del formulario que enlace a cada campo inválido (getAccessGuard, 2026). Ese movimiento de foco es lo que le avisa a un usuario de teclado o de lector de pantalla que algo pasó, en vez de dejarlo preguntándose por qué se recargó la página.
Teclado, foco y la trampa de los widgets a medida
Cada control debe ser alcanzable y operable solo con el teclado, en un orden que coincida con la disposición visual — y la forma más simple de lograrlo es usar elementos nativos, porque input, select, textarea y button son accesibles por teclado por defecto (getAccessGuard, 2026). Los problemas empiezan cuando un formulario se reconstruye con elementos div y span estilizados para parecer controles, que no tienen soporte de teclado hasta que un desarrollador lo añade a mano — trabajo que se salta con frecuencia (Yale, 2026). Mantén el orden del DOM igual al orden visual en vez de reordenar con CSS, ya que los usuarios de teclado encuentran los campos en el orden del código, y dale a cada control un anillo de foco claramente visible (WCAGKit, 2026).
Dos hábitos rompen formularios en silencio. Atenuar el botón de enviar hasta que cada campo sea válido crea confusión, así que déjalo activo y muestra errores claros al enviar (WCAGKit, 2026). Y no envíes de forma automática ni cambies el contexto cuando cambia un valor — la WCAG 3.2.2 lo trata como desorientador para usuarios de teclado y de lector de pantalla salvo que se les advierta (getAccessGuard, 2026). Este instinto de “primero lo nativo” es el mismo de nuestra guía sobre accesibilidad por teclado y foco: el control integrado ya hace la parte difícil.
Los formularios de alto impacto necesitan una red de seguridad
Cuando un envío carga peso real —un pago, un acuerdo legal, borrar datos— la WCAG pide un respaldo contra los errores. Al menos una de tres protecciones debe estar presente: la acción es reversible, el envío se revisa en busca de errores y la persona puede corregirlos, o la persona puede revisar y confirmar la información antes de que sea final (Yale, 2026). Un paso de revisar-y-confirmar es el patrón más común, y protege a todos, y no únicamente a los usuarios con discapacidad.
Pruébalo de la única manera que funciona
Los escáneres automáticos valen la pena — detectan rápido etiquetas faltantes y ARIA inválido — pero no te dicen si un formulario de verdad funciona para una persona real, y se pierden cerca del 70% de los fallos (508Blueprint, 2026). Las pasadas que encuentran problemas reales son manuales. Completa todo el formulario solo con el teclado, confirmando que cada campo se alcanza en un orden lógico; navégalo con un lector de pantalla como NVDA, VoiceOver o TalkBack para oír cómo se anuncian etiquetas y errores; y dispara a propósito cada error de validación para comprobar que cada uno se anuncia y se liga a su campo (WCAGKit, 2026). Presupuestado con honestidad, un formulario estándar de registro o contacto lleva unos 30 minutos de prueba así (508Blueprint, 2026).
Por qué nuestros formularios son accesibles por defecto
Relee esta lista y emerge un patrón: casi todo requisito se satisface usando el control HTML nativo y dejándolo hacer su trabajo. No es casualidad, y es por lo que construimos los formularios como lo hacemos. Un control nativo es operable por teclado, expone su función y su estado a la tecnología de asistencia, y necesita casi nada de JavaScript — así que la opción accesible y la opción ligera resultan ser la misma opción, justo como en todo lo demás que construimos. El widget a medida basado en div que rompe un formulario es el mismo tipo de atajo pesado y guiado por scripts que evitamos por rendimiento.
También vale la pena decir lo que un formulario deja en evidencia: este es precisamente el tipo de problema que un overlay de accesibilidad no puede arreglar. Un widget añadido al cargar la página no puede aportar la etiqueta que tu input nunca tuvo ni reescribir tu manejo de errores para que se anuncie — eso tiene que estar construido en el formulario, que es el argumento de nuestra guía sobre por qué los overlays de accesibilidad son una trampa legal. Acierta con el formulario en la fuente y habrás manejado la superficie donde la accesibilidad, las conversiones y la exposición legal se cruzan a la vez — el corazón práctico de nuestro pilar sobre si la accesibilidad web es obligatoria.
Frequently asked
- ¿Puedo usar el texto de placeholder en vez de una etiqueta?
- No. El texto de placeholder desaparece en cuanto alguien empieza a escribir, lo que incumple la WCAG 3.3.2 (Etiquetas o instrucciones), y no se anuncia de forma consistente entre lectores de pantalla, lo que incumple la 4.1.2 (Nombre, función, valor). Un input sin etiqueta puede fallar tres criterios a la vez. Cada input, select y textarea necesita una etiqueta visible y asociada de forma programática con un elemento label ligado al id del input, o el input envuelto dentro del label. Si el espacio es escaso, un patrón de etiqueta flotante la mantiene visible tras escribir; un placeholder es a lo sumo un complemento, nunca un reemplazo.
- ¿Cómo hago accesibles los mensajes de error de un formulario?
- Cuatro cosas juntas. El mensaje debe identificar el problema y sugerir el arreglo — 'Ingresa un correo válido', no 'Entrada inválida'. Debe estar ligado de forma programática al campo con aria-describedby, y el campo marcado con aria-invalid='true'. No debe depender solo del color — un borde rojo por sí solo incumple la WCAG 1.4.1, así que añade texto y un icono. Y debe anunciarse: pon el mensaje en una región aria-live o usa role='alert', y al enviar mueve el foco al primer error o a un resumen de errores al inicio del formulario.
- ¿El atributo autocomplete es obligatorio para la accesibilidad?
- Sí, en los campos que recogen información personal común. El criterio de éxito 1.3.5 de la WCAG (Identificar el propósito de la entrada, nivel AA) exige el atributo autocomplete en inputs como nombre, correo, teléfono, dirección, código postal y tarjeta. Más allá del cumplimiento, permite que los navegadores y gestores de contraseñas rellenen los campos de forma automática, lo que reduce el esfuerzo cognitivo y motor que exige un formulario — una ayuda real para usuarios con discapacidad motora o cognitiva, y menos abandono para todos.
- ¿Por qué los controles de formulario HTML nativos son mejores para la accesibilidad?
- Porque los elementos nativos input, select, textarea y button son operables por teclado y exponen su nombre, función y estado a la tecnología de asistencia por defecto. Los problemas de accesibilidad aparecen cuando un formulario se reconstruye con elementos div y span estilizados para parecer controles, porque esos no tienen soporte de teclado ni semántica para lectores de pantalla salvo que un desarrollador la añada a mano, y ese trabajo se salta o se hace a medias con frecuencia. Usar el control nativo y luego estilizarlo te da accesibilidad gratis — que es también por lo que necesita mucho menos JavaScript.
- ¿Cómo pruebo si mi formulario es accesible?
- Combina pruebas automáticas y manuales, porque los escáneres automáticos se pierden cerca del 70% de los fallos. Corre una herramienta como Axe o WAVE para detectar etiquetas faltantes y ARIA inválido, y luego haz las pasadas manuales que de verdad importan: completa todo el formulario solo con el teclado, comprobando que cada campo se alcanza en un orden lógico con un anillo de foco visible; navégalo con un lector de pantalla (NVDA, VoiceOver o TalkBack) para oír cómo se anuncian etiquetas y errores; y dispara a propósito cada error de validación para confirmar que cada uno se anuncia y se liga a su campo. Un formulario estándar lleva unos 30 minutos.