Guía Completa de Formularios e Interfaces de Entrada Accesibles

Diseño de etiquetas, mensajes de error, campos obligatorios, asistencia de entrada, interacción móvil y requisitos prácticos de WCAG 2.1 AA

Resumen (puntos clave primero)

• Entre todas las experiencias web, los formularios son donde más a menudo se producen fallos de accesibilidad.
• Las etiquetas deben ser siempre explícitamente visibles y comprensibles mediante vista, audio y teclado; los placeholders no deben usarse como sustitutos de las etiquetas.
• Los mensajes de error deben comunicar “dónde, por qué y cómo arreglarlo” usando pistas visuales, auditivas y estructurales.
• Los asistentes de entrada (por ejemplo, autocomplete, inputmode, pattern) son como una “atención clínica” que reduce la carga en entornos muy diversos.
• En móvil, necesitas aún más cuidado que en escritorio: tamaño de los objetivos táctiles, tipo de teclado, no bloquear el zoom por pellizco, etc.

Público objetivo (ejemplos concretos):

• Ingenieros y diseñadores UI/UX que trabajen en formularios web
• Personal de administraciones públicas / sector público
• Operadores de comercio electrónico
• Desarrolladores de sistemas financieros / de reservas
• Personal de educación y reclutamiento
• Editores web corporativos

Nivel de accesibilidad objetivo: conformidad con WCAG 2.1 AA
(con foco en los criterios de éxito 1.3.1, 2.4.6 y 3.3.x)

1. Introducción: los formularios son “la puerta entre las personas y los servicios”

Si no puedes introducir datos en un formulario, no puedes continuar.
Si no puedes corregir un error, no puedes completar el proceso.

Eso convierte a los formularios en la interfaz más estresante de un sitio.

Quienes usan estas “puertas” incluyen personas con:

• discapacidades visuales, diferencias de visión del color
• diferencias cognitivas
• movilidad o destreza limitadas
• y también distintos niveles educativos y antecedentes lingüísticos

Por eso, los formularios deben ser especialmente amables, cuidadosos e inequívocos.

Este artículo recorre pasos prácticos para construir formularios accesibles que realmente funcionen en proyectos reales.

2. Diseño de etiquetas: el salvavidas de los formularios

2.1 Las etiquetas deben ser visibles y conectarse mediante <label> y for

<label for="email">Dirección de correo electrónico</label>
<input id="email" type="email" autocomplete="email">

• Los lectores de pantalla usan la etiqueta como nombre accesible del control.
• Al hacer clic en la etiqueta, el foco se mueve al campo, lo que mejora la usabilidad.

2.2 Por qué no debes usar placeholders como sustitutos de etiquetas

• El placeholder desaparece mientras el usuario escribe.
• El texto a menudo tiene poco contraste (viola WCAG 1.4.3).
• Ejemplos poco claros pueden fomentar entradas incorrectas.

2.3 Obligatorio / opcional debe indicarse en la etiqueta

Ejemplo malo:
Confiar solo en el color y en un * para indicar “obligatorio”.

Ejemplo bueno:

<label for="name">
  Nombre completo <span aria-hidden="true">(obligatorio)</span>
</label>

Para lectores de pantalla, te aseguras de que se anuncie como:

“Nombre completo, obligatorio”

(Los detalles de implementación pueden variar: por ejemplo, usar texto solo visible para lectores de pantalla o aria-required="true".)

3. Mensajes de error: el mayor requisito de accesibilidad en formularios

3.1 Los errores deben incluir siempre “ubicación, motivo y solución”

<div id="email-error" class="error" role="alert">
  El formato de la dirección de correo electrónico no es válido. Usa el formato nombre@ejemplo.com.
</div>

<input
  id="email"
  aria-invalid="true"
  aria-describedby="email-error">

• Dónde: el campo con aria-invalid="true"
• Por qué: texto del mensaje (por ejemplo, “el formato no es válido”)
• Cómo arreglarlo: idealmente incluido (por ejemplo, “Usa el formato nombre@ejemplo.com”)

3.2 Proporciona un “resumen de errores” en la parte superior del formulario

• Muestra todos los errores en una lista.
• Cada elemento de la lista debe ser un enlace que mueva el foco al campo correspondiente al activarlo.

Ejemplo:

● Dirección de correo electrónico: el formato no es válido.
● Número de teléfono: utiliza solo dígitos.

Esto ayuda a los usuarios de teclado y lectores de pantalla a saltar rápidamente a cada campo problemático.

3.3 No muestres errores inmediatamente mientras el usuario escribe

• Usa on blur (focusout) o después del envío para la mayoría de validaciones.
• Hacer parpadear texto rojo mientras las personas están escribiendo incrementa el estrés y la carga cognitiva.

4. Asistencia de entrada: el arma más práctica para reducir la carga cognitiva

4.1 Usa autocomplete de forma agresiva

<input id="postal" name="postal" autocomplete="postal-code">

Esto reduce drásticamente el esfuerzo y los errores de los usuarios.

4.2 Usa inputmode y type para mostrar el mejor teclado en móvil

<input type="tel" inputmode="numeric">

• type="tel" indica semántica de número de teléfono.
• inputmode="numeric" hace que aparezca un teclado numérico en muchos navegadores móviles.

4.3 pattern ayuda más a los desarrolladores que a los usuarios

• Es útil para validación, pero si se abusa de él, puede impedir que los usuarios introduzcan datos reales válidos.
• Ejemplo: no permitir guiones en un número de teléfono → peor usabilidad / accesibilidad.

4.4 Campos de fecha: cuidado con type="date"

• La interfaz es dependiente del sistema operativo y del navegador.
• Para casos como introducir fechas en formatos específicos locales, o cuando los usuarios deben escribir libremente, suele ser más usable un campo de texto más una interfaz auxiliar.

5. Reglas especiales para formularios móviles

5.1 Los objetivos táctiles deben ser de al menos 44px

Botones, casillas y selects deben tener un área táctil de unos 44px como mínimo en ambas dimensiones (o equivalente en unidades CSS).

5.2 No bloquees el zoom por pellizco

<meta name="viewport" content="width=device-width, initial-scale=1">

Nunca uses user-scalable=no u otros ajustes que impidan el zoom.
Los usuarios deben poder ampliar cuando lo necesiten.

5.3 Añade espacio vertical entre campos

Dale a los campos suficiente separación vertical para:

• evitar toques accidentales
• mejorar la legibilidad y la capacidad de escaneo

5.4 Evita selects complejos de varios niveles en móvil

Para tres o más niveles de jerarquía, usa una interfaz paso a paso.
Ejemplo:

• Paso 1: seleccionar provincia / estado
• Paso 2: seleccionar ciudad / municipio dentro de esa provincia

Esto es más fácil y seguro que un único desplegable gigantesco.

6. Radios, casillas de verificación y selects

6.1 Agrupa los botones de opción con fieldset + legend

<fieldset>
  <legend>Género</legend>
  <label>
    <input type="radio" name="gender" value="male">
    Hombre
  </label>
  <label>
    <input type="radio" name="gender" value="female">
    Mujer
  </label>
</fieldset>

• legend describe el grupo en su conjunto.
• Los lectores de pantalla anuncian este contexto de grupo antes de cada opción.

6.2 Errores para grupos de casillas

Cuando varias casillas pertenecen a una misma pregunta:

• Muestra los errores en el grupo, no solo en opciones individuales.
• Usa textos como “Selecciona al menos una opción”.

6.3 Haz que los selects largos o agrupados sean más fáciles de usar

<select>
  <optgroup label="Hokkaidō y Tōhoku">
    <option>Hokkaidō</option>
    <option>Aomori</option>
  </optgroup>
</select>

• optgroup ayuda a los usuarios a recorrer listas largas.
• Asegúrate de que las etiquetas de grupo sean claras y concisas.

7. Gestión del foco: una experiencia de formulario sin perderse

7.1 Tras un envío fallido, mueve el foco al primer error

Cuando el usuario envía y hay errores:

• Mueve el foco mediante código a:
  • el resumen de errores, o
  • el primer campo con error

Sin esto, las personas pueden no saber por dónde empezar a corregir.

7.2 Formularios dentro de modales

• Implementa un focus trap dentro del modal.
• El resumen de errores también debe estar dentro del modal.
• Asegúrate de que al cerrar el modal el foco vuelve a un lugar lógico (por ejemplo, el botón que lo abrió).

7.3 Formularios de varios pasos

• Usa un encabezado como <h2> para el título de cada paso.
• Coloca claramente los botones de “Atrás” y “Siguiente/Continuar”, con un orden de tabulación lógico.
• Muestra el estado del paso actual (por ejemplo, “Paso 2 de 4”).

8. Ejemplos de entrada: informativos sin resultar agobiantes

Bueno:
Ejemplo: nombre@ejemplo.com (claro pero poco intrusivo)

Malo:
¡¡¡INTRODUCE SOLO NÚMEROS!!! (agresivo y poco preciso, alta carga cognitiva)

8.1 Usa aria-describedby para adjuntar pistas

<label for="tel">Número de teléfono</label>
<input id="tel" type="tel" aria-describedby="tel-hint">
<small id="tel-hint">Ejemplo: 600123456 (sin espacios ni guiones)</small>

• Los lectores de pantalla leerán tanto la etiqueta como la pista.
• Visualmente, la pista queda colocada de forma limpia junto al campo.

9. Formularios y soporte multilingüe

• Escribe mensajes de error como frases que puedan reformularse educadamente en otros idiomas.
• Ajusta opciones automáticamente según la configuración regional del usuario siempre que sea posible.
• Ten en cuenta que números, fechas y direcciones varían mucho según la región.

Ejemplos:

• EE. UU.: MM/DD/AAAA
• España / Latinoamérica (habitual): DD/MM/AAAA
• Algunos idiomas de Oriente Medio se escriben de derecha a izquierda (RTL), por lo que el diseño de tu formulario debe ser lo bastante flexible para admitir RTL.

10. Errores frecuentes y soluciones

11. Checklist de “smoke test” en cinco minutos

1. Cada campo tiene una etiqueta visible ligada mediante for/id.
2. Aparece un resumen de errores y el foco se mueve al primer error.
3. aria-invalid y aria-describedby se aplican correctamente.
4. Los asistentes de entrada (autocomplete, inputmode, etc.) están configurados adecuadamente.
5. Los usuarios pueden hacer zoom en móvil (sin bloqueo de zoom).
6. Botones y campos tienen un tamaño suficiente para el toque.
7. Los lectores de pantalla anuncian correctamente el nombre y el estado (obligatorio/error) de cada campo.

12. Valor concreto para cada tipo de público

• Personas con discapacidad visual:
  Etiquetas y mensajes de error claros les permiten completar formularios sin obstáculos.

• Personas con diferencias cognitivas:
  Buenas explicaciones, espacios en blanco y estructuras paso a paso reducen la carga.

• Personas mayores y principiantes:
  Objetivos móviles amigables y menos errores de entrada generan una experiencia más segura.

• Proveedores de servicios / empresas:
  Más formularios completados, menos abandonos y menos consultas al soporte.

• Todas las personas:
  Una experiencia de formulario tranquila, predecible y sin preocupaciones innecesarias.

13. Nivel de accesibilidad (qué pretende cubrir esta guía)

• Principales criterios de éxito WCAG 2.1 AA
  • 1.3.1 Información y relaciones (etiquetas / estructura)
  • 1.3.2 Secuencia significativa
  • 1.3.5 Identificar el propósito de la entrada (autocomplete)
  • 1.4.3 Contraste (mínimo)
  • 2.1.1 Teclado
  • 2.4.6 Encabezados y etiquetas
  • 3.3.1 Identificación de errores
  • 3.3.3 Sugerencia ante errores
  • 3.3.4 Prevención de errores (legal, financiero, datos)

14. Conclusión: el formulario es donde diseñas un “camino sin preocupaciones”

1. Proporciona siempre etiquetas explícitas; nunca confíes en los placeholders como etiquetas.
2. Ofrece mensajes de error con el trío ubicación, motivo y solución.
3. Trata los asistentes de entrada como herramientas para reducir esfuerzo y errores.
4. En móvil, respeta el tamaño de los objetivos táctiles y permite el zoom.
5. Trata radios, casillas y selects como grupos semánticos.
6. Institucionaliza estas reglas para que la calidad de los formularios sea consistente en toda la organización.

Un formulario es un pequeño espacio de comunicación donde apoyas el valor y las acciones de las personas.

Al hacer que esa “puerta” sea segura y acogedora para todo el mundo, ayudas a que más personas completen los recorridos que se han propuesto.
Refinemos esos diseños paso a paso para que nadie se quede atrás.