Lección 5 de 10 · 10 min de lectura · Revisado el 26/10/2026
autocomplete, propósito de entrada (1.3.5) y entrada redundante (3.3.7)
Rellenar un formulario cuesta. Cuesta más si tienes dificultades de memoria, dislexia, movilidad reducida o simplemente estás en un móvil con una mano. Dos criterios de las WCAG atacan directamente ese esfuerzo: 1.3.5 Identificar el propósito de la entrada (AA), introducido en WCAG 2.1, y 3.3.7 Entrada redundante (A), nuevo en WCAG 2.2. El primero permite que el navegador rellene los datos personales por nosotros; el segundo prohíbe pedir dos veces lo mismo dentro de un proceso. Ambos son fáciles de cumplir si se conocen.
Qué pide 1.3.5
El criterio exige que, cuando un campo recoge información sobre la propia persona usuaria (nombre, dirección, correo, teléfono, fecha de nacimiento, datos de tarjeta…), su propósito pueda determinarse por programa. La forma de hacerlo en HTML es el atributo autocomplete con uno de los valores que la especificación define como «propósitos de entrada». Eso tiene dos efectos:
- El navegador o el gestor de contraseñas puede rellenar el campo automáticamente con los datos guardados, lo que elimina errores de tecleo y ahorra tiempo a todo el mundo.
- Las tecnologías de apoyo pueden personalizar la presentación del campo: por ejemplo, una extensión puede añadir un icono reconocible junto a cada campo de «teléfono» o «correo» para personas con dificultades de lectura.
El criterio solo se aplica a datos sobre la persona usuaria, no a cualquier campo. El importe de una transferencia, el número de expediente o el nombre de un tercero no tienen un propósito de entrada definido y no necesitan autocomplete.
Los valores correctos
Los valores más habituales, tal como los define la especificación HTML:
| Dato | Valor de autocomplete |
|---|---|
| Nombre completo | name |
| Nombre / apellidos | given-name / family-name |
| Correo electrónico | email |
| Teléfono | tel |
| Dirección (una línea / líneas) | street-address / address-line1, address-line2 |
| Código postal | postal-code |
| Localidad / provincia / país | address-level2 / address-level1 / country-name |
| Fecha de nacimiento | bday (o bday-day, bday-month, bday-year) |
| Organización / puesto | organization / organization-title |
| Usuario / contraseña | username / current-password / new-password |
| Código de un solo uso | one-time-code |
| Tarjeta | cc-name, cc-number, cc-exp, cc-csc |
Ejemplo
<label for="nombre">Nombre</label>
<input id="nombre" name="nombre" autocomplete="given-name">
<label for="apellidos">Apellidos</label>
<input id="apellidos" name="apellidos" autocomplete="family-name">
<label for="tel">Teléfono móvil</label>
<input id="tel" name="tel" type="tel" autocomplete="tel">
<label for="cp">Código postal</label>
<input id="cp" name="cp" inputmode="numeric" autocomplete="postal-code">Cuando un formulario tiene dos direcciones (envío y facturación), se distinguen con los prefijos shipping y billing: autocomplete="shipping postal-code", autocomplete="billing postal-code".
Error frecuente
Poner autocomplete="off" en todo el formulario «por seguridad» o para evitar sugerencias molestas. Eso incumple 1.3.5 en los campos de datos personales y, además, algunos navegadores ignoran off en ciertos campos, como los de inicio de sesión o los de dirección. También es un error inventar valores (autocomplete="dni", autocomplete="telefono"): un valor fuera de la lista oficial equivale a no tener nada. Ojo con un detalle de la especificación: los valores on y off no identifican ningún propósito, así que no sirven para cumplir el criterio.
El DNI, el NIE o el número de la Seguridad Social no tienen un valor específico en la lista. Para ellos no hay obligación bajo 1.3.5, aunque sí conviene usar inputmode y una etiqueta clara.
3.3.7 Entrada redundante
Este criterio de WCAG 2.2 dice que la información que la persona ya ha introducido o se le ha proporcionado en un mismo proceso no debe pedírsele otra vez, salvo que se rellene automáticamente o esté disponible para seleccionarla. Las excepciones: cuando volver a introducirla es esencial (por ejemplo, en un juego de memoria), cuando se necesita por seguridad (repetir una contraseña nueva que no se muestra en pantalla o volver a introducir la contraseña para una operación sensible) o cuando la información anterior ya no es válida.
El escenario clásico es una compra: se piden los datos de envío y, dos pantallas después, los datos de facturación completos de nuevo. La solución accesible es una casilla «Usar la misma dirección que para el envío» marcada por defecto, o precargar los campos con los valores ya introducidos dejando que la persona los edite.
<fieldset>
<legend>Dirección de facturación</legend>
<input type="checkbox" id="misma" name="misma" checked>
<label for="misma">Usar la misma dirección que para el envío</label>
<!-- Los campos de facturación se muestran solo si se desmarca,
precargados con los datos de envío -->
</fieldset>Otros casos que se suelen considerar incumplimientos de 3.3.7: un asistente de varios pasos que pide el correo en el paso 1 y de nuevo en el paso 4; un error de validación que vacía todo el formulario y obliga a rellenarlo de cero; un proceso que pide el número de expediente que la propia web acaba de mostrar. En todos ellos, la persona ya dio o recibió el dato dentro del mismo proceso.
Punto clave
Un «proceso» en 3.3.7 es una secuencia de pasos para completar una actividad, aunque cambie de página. Lo que se introdujo en el paso 1 debe estar disponible, rellenado o seleccionable, en el paso 5. Guardar el estado del formulario entre pasos y tras un error de validación es parte de la accesibilidad.
Beneficio para todo el mundo
Estos dos criterios son el ejemplo perfecto de cómo la accesibilidad mejora la tasa de conversión. Cada campo que el navegador rellena solo es un campo menos donde abandonar; cada dato que no se pide dos veces es un minuto menos de proceso. Las tiendas en línea que miden el abandono de carrito pueden ver mejoras medibles al implementar autocomplete correctamente y reutilizar la dirección de envío.
Cómo comprobarlo
- Inspecciona cada campo que pide datos personales y confirma que tiene un
autocompletecon un valor válido de la lista. - Guarda una dirección en el perfil del navegador y entra en el formulario: el navegador debería ofrecer rellenar los campos.
- Recorre el proceso completo anotando cada dato que se pide; si alguno se pide dos veces, verifica que esté precargado o sea seleccionable, o que entre en las excepciones.
- Provoca un error de validación y comprueba que los demás campos conservan su valor.
Resumen
- 1.3.5 exige
autocompletecon un valor de la lista oficial en los campos que recogen datos de la persona usuaria. on,offy los valores inventados no identifican ningún propósito y no sirven para cumplir el criterio.- 3.3.7 prohíbe pedir en un mismo proceso un dato ya introducido o mostrado, salvo que se rellene automáticamente, sea seleccionable o entre en las excepciones (esencial, seguridad, dato caducado).
- Precarga, casillas «usar la misma dirección» y conservación del estado tras errores son las soluciones habituales.
- Ambos criterios reducen el abandono y los errores de todo el mundo, no solo de personas con discapacidad.
Comprueba lo que has aprendido
Esta lección se puede leer libremente. Para hacer su test de 3 preguntas, los ejercicios prácticos con páginas reales, guardar tu avance y optar al examen y al certificado, matricúlate en el curso.