1 de cada 4 adultos estadounidenses vive con algún tipo de discapacidad. Si tu formulario no es accesible, estás dejando fuera a una cuarta parte de tu público potencial antes de que llegue al botón de enviar.
Un formulario accesible funciona para todos. Eso incluye a quienes usan solo el teclado. A quienes escuchan con un lector de pantalla. A quienes tienen baja visión. A quienes tienen temblores y necesitan más tiempo para rellenar los campos. Sin un diseño especial ni complejidad extra. Solo un formulario construido para que todas estas personas puedan usarlo de verdad.
Etiquetas claras. Navegación con teclado. Mensajes de error que un lector de pantalla puede anunciar. Contraste suficiente para que las personas con baja visión lean el texto. No son funciones extra. Son el mínimo que exigen WCAG 2.1 AA y la ley de Estadounidenses con Discapacidades (ADA) a partir de abril de 2026.
Qué hace distintos a los formularios accesibles
Mira cualquier formulario de contacto y encontrarás los mismos errores. Un campo de texto con un placeholder pero sin etiqueta visible. Una casilla sin explicación de lo que hace. Un mensaje de error en texto rojo que un lector de pantalla no puede anunciar.
La mayoría de los formularios se construyen para usuarios de ratón y la accesibilidad se añade después, como un parche. Un formulario accesible funciona al revés. Parte de la base de que la gente lo usará de formas distintas. Unos con ratón, otros solo con teclado. Unos leyéndolo, otros escuchando con un lector de pantalla.
Eso cambia cómo construyes el formulario. Los placeholders no sirven sin etiquetas. Los asteriscos rojos no sirven sin texto. Una disposición visual que funciona con ratón puede atrapar a quien usa teclado. Un formulario accesible no es más difícil de construir. Solo exige pensar en formas de interacción más allá del ratón.
Por qué importa
Plazo legal. El Título II de la ADA exige WCAG 2.1 AA antes del 24 de abril de 2026. Incumplirlo ya no es un riesgo. Es una responsabilidad actual.
Impacto en el negocio. Los visitantes con discapacidad gastan dinero real. Un formulario accesible aumenta las tasas de finalización de todos, porque las etiquetas claras ayudan a todos los usuarios, no solo a quienes tienen una discapacidad. Gente con prisa que escanea desde el móvil a las 6 de la mañana. Usuarios avanzados que navegan con teclado. Todos.
Beneficio SEO. Los buscadores favorecen las páginas cuyos elementos interactivos están etiquetados y se pueden recorrer con el teclado. Los formularios accesibles posicionan mejor.
Qué necesitan de verdad los formularios accesibles
Etiquetas visibles en cada campo
Cada campo necesita una etiqueta. No un placeholder que desaparece. No un atributo title. Una etiqueta real, ahí, en la página.
Un lector de pantalla lee primero la etiqueta y luego anuncia el tipo de campo. "Nombre, campo de texto." El usuario sabe qué hacer. Sin etiqueta, oye "campo de texto" y nada más. No tiene idea de qué escribir.
Para quienes ven, las etiquetas funcionan como en el papel. Dicen qué va en cada hueco. Además amplían el área en la que se puede hacer clic. Vincula la etiqueta al campo con el atributo for y los usuarios podrán hacer clic en la etiqueta o en el campo para enfocarlo. En el móvil, esta zona de clic más grande importa.
Que funcione solo con teclado
Mucha gente nunca toca un ratón. Discapacidades motoras, baja visión, lectores de pantalla. Estos usuarios navegan solo con el teclado. Si tu formulario necesita un ratón, no es accesible.
Pruébalo. Desenchufa el ratón. Recorre el formulario solo con la tecla Tab, las flechas y Enter. Deberías poder llegar a cada campo, elegir cada opción y pulsar enviar sin mover las manos.
El contorno de foco debe verse en cada paso. Nada de estados de foco invisibles. Los usuarios necesitan saber dónde están en el formulario. Y el orden del tabulador importa. Los campos deben fluir de izquierda a derecha y de arriba abajo, como se lee el formulario. Si tu diseño salta de un sitio a otro o esconde campos, el orden del tabulador se rompe y los usuarios de teclado quedan atrapados.
Mensajes de error que se anuncian solos
El texto rojo en la parte superior del formulario no significa nada para quien usa un lector de pantalla. Envía, oye silencio y lo intenta otra vez. Luego se rinde.
Vincula el error con el campo concreto donde ocurrió. Cuando un usuario de lector de pantalla llega con el tabulador a ese campo, el error se anuncia. Y haz que el mensaje diga qué corregir, no solo "No válido". En lugar de "Entrada no válida", di "El email debe incluir el símbolo @".
Usa atributos ARIA como aria-describedby para conectar el mensaje de error con el campo. Cuando el foco llega al campo, el lector de pantalla anuncia el error automáticamente. Sin adivinar.
Texto legible para personas con baja visión
Las etiquetas en gris claro sobre fondo blanco son invisibles para alguien con baja visión. WCAG 2.1 AA exige una relación de contraste de 4.5:1 para el texto normal. Texto oscuro sobre fondo claro, o texto claro sobre fondo oscuro. El contraste tiene que ser evidente.
El texto grande (18 puntos o más) puede usar un contraste de 3:1. Todo lo demás necesita 4.5:1. Una herramienta de comprobación de contraste tarda 5 segundos. Pasa cada etiqueta, botón y mensaje de error por una antes de lanzar.
Nunca uses solo el color para indicar los campos obligatorios. Un asterisco rojo no significa nada para una persona daltónica. Añade la palabra "obligatorio" junto al campo. Los lectores de pantalla la anuncian. Quienes ven la leen. Todos entienden el texto.
Guía campo por campo para formularios accesibles
Campos de texto y áreas de texto
Nombre, email, teléfono: todos necesitan una etiqueta justo encima o al lado. Usa el elemento HTML <label> con un atributo for que coincida con el id del campo.
Si el campo espera un formato concreto, dilo. "Formato: 555-123-4567" ayuda a todos, sobre todo a quienes trabajan mejor con instrucciones explícitas.
Las áreas de texto deben parecer que admiten respuestas más largas. Una caja de una línea con la etiqueta "Mensaje" se lee como una respuesta rápida. Una caja más alta indica "cuéntame más". El tamaño importa.
Desplegables y botones de opción
Cada desplegable necesita una etiqueta. "Selecciona una opción" y "Sí/No" sin contexto no sirven. Un usuario de lector de pantalla no sabe qué pregunta le haces. Deja claro en la etiqueta del desplegable qué se está eligiendo.
Los botones de opción deben ir dentro de un fieldset con una leyenda. La leyenda hace la pregunta. Las opciones la responden. "¿Qué describe mejor tu caso de uso?" con opciones como "Tienda online", "Medios", "SaaS". Un lector de pantalla anuncia la leyenda y luego cada opción. El usuario entiende que elige dentro de un grupo y para qué sirve ese grupo.
Casillas de verificación
La etiqueta de una casilla debe leerse con naturalidad. "Acepto los términos del servicio" como etiqueta, con la casilla al lado. No una casilla desnuda sin texto que obliga a adivinar qué hace.
Si hay información de apoyo, como un enlace a los términos completos, ponla justo al lado de la casilla. No la escondas. Los usuarios necesitan saber a qué se comprometen antes de marcar la casilla.
Los grupos de casillas funcionan como los grupos de botones de opción. Una leyenda da nombre al grupo y cada opción tiene su propia etiqueta.
Botones
El texto del botón debe decir qué pasa. "Enviar." "Mandar." "Aceptar" sirve para confirmaciones. "Ir" no. Nada de etiquetas genéricas.
Si tienes varios botones, haz que se distingan. "Cancelar" y "Enviar" son claros. Dos botones que dicen "Siguiente" no lo son: un usuario de lector de pantalla oye "botón siguiente, botón siguiente" y no sabe cuál es cuál.
Dónde van los formularios en tu web
Formularios de contacto en ventanas emergentes. Suscripciones a la newsletter en el pie de página. Formularios de donación en páginas de misión. Formularios de encuesta en el pago. Cualquier formulario, en cualquier sitio, tiene que ser accesible.
Los formularios emergentes crean una trampa de foco si no los gestionas. Cuando se abre una ventana modal, el foco salta a ella. Cuando se cierra, el foco vuelve al botón que la abrió. Sin esto, los usuarios de teclado se quedan atascados recorriendo con el tabulador la página de fondo.
En páginas largas con formularios más abajo, añade un enlace de salto. Los usuarios de teclado no deberían tener que recorrer 50 elementos de navegación para llegar a tu formulario.
Errores comunes
Confiar en el placeholder en lugar de en etiquetas
Un placeholder que dice "Escribe tu email" desaparece en cuanto alguien empieza a escribir. Ahora el usuario no sabe para qué era el campo. Los lectores de pantalla ni siquiera lo ven.
Usa una etiqueta real. Si quieres un placeholder para pistas de formato, bien. Pero nunca lo uses como etiqueta.
Usar solo el color para los campos obligatorios
Un asterisco rojo es invisible para las personas daltónicas. Un icono es invisible para los lectores de pantalla. Usa la palabra "obligatorio" en texto. Todos entienden el texto.
Saltarse las pruebas manuales
Que la estructura HTML sea correcta sobre el papel no significa que tu formulario funcione en la realidad. Las etiquetas pueden estar demasiado lejos de los campos. Los contornos de foco pueden ser invisibles. Los mensajes de error pueden anunciarse sin mover el foco al campo.
Prueba con un teclado. Prueba con un lector de pantalla. Hay lectores de pantalla gratuitos y otros de uso estándar en el sector, y el integrado en iOS si pruebas en ese sistema. Los comprobadores automáticos detectan los problemas evidentes. Las pruebas reales detectan el resto.
Añadir límites de tiempo
Una persona con temblores escribe despacio. Un usuario de lector de pantalla necesita tiempo para escuchar todas las etiquetas e instrucciones. Un límite de 5 minutos atrapa a quien necesita 10.
Quita los límites de tiempo si puedes. Si tienes que ponerlos, deja que los usuarios amplíen el tiempo dos veces antes de que termine la sesión.
Cómo crea WEMASY formularios accesibles
Los formularios de WEMASY se crean accesibles desde el principio, no como un parche. Cada plantilla incluye etiquetas correctas. El foco se gestiona automáticamente. Los errores se anuncian a los lectores de pantalla. El contraste de color cumple WCAG 2.1 AA por defecto.
Personaliza sin romper la accesibilidad. Añade campos, cambia etiquetas, reorganiza la disposición. La estructura de fondo sigue siendo accesible. La validación integrada anuncia los errores a los lectores de pantalla.
Descubre más en nuestra guía completa sobre formularios o consulta qué incluye cada plan de WEMASY.