WCAG 1.3.5: Identificar la finalidad de la entrada

Qué significa esta regla

WCAG 1.3.5 — Identify Input Purpose es un criterio de nivel AA introducido en WCAG 2.1 y mantenido en WCAG 2.2. Exige que cualquier elemento <input>, <select> o <textarea> que recopile información sobre la persona usuaria tenga su propósito comunicado de forma programática, de modo que los navegadores y las tecnologías de apoyo puedan identificar ese propósito y actuar en consecuencia de forma automática.

El mecanismo para cumplir este criterio es el atributo autocomplete, combinado con el valor de token correcto de la lista oficial definida en la especificación HTML. Cuando un campo recopila el nombre, la dirección de correo electrónico, el número de teléfono, la dirección postal, el número de tarjeta de crédito u otros datos personales similares de la persona usuaria, el atributo autocomplete debe llevar un valor que describa con precisión el propósito de ese campo — por ejemplo, autocomplete="given-name" para un campo de nombre de pila, o autocomplete="email" para un campo de correo electrónico.

El criterio se aplica específicamente a entradas que recopilan información sobre la propia persona usuaria. No se aplica a campos en los que una persona introduce datos sobre otra (por ejemplo, un formulario de reserva de viaje que pide el nombre de la persona pasajera cuando la persona usuaria reserva en nombre de otra), ni se aplica a campos en los que el autocompletado supondría un riesgo de seguridad — como contraseñas de un solo uso o desafíos tipo CAPTCHA, que legítimamente pueden usar autocomplete="off" o autocomplete="one-time-code".

Para aprobar se requiere que: (1) cada campo de entrada dentro del alcance tenga un atributo autocomplete; y (2) el valor de ese atributo sea un token válido y reconocido de la especificación de autocompletado de HTML — no una cadena arbitraria, no un valor vacío cuando se requiere uno significativo, y no un token mal escrito. Se produce un fallo cuando una entrada dentro del alcance no tiene atributo autocomplete, tiene autocomplete="off" sin justificación, o tiene un token no válido como autocomplete="firstname" (el token correcto es given-name) o autocomplete="phone" (el token correcto es tel).

La lista completa de tokens de autocompletado válidos la mantiene el WHATWG HTML Living Standard e incluye valores para nombres (given-name, family-name, additional-name), direcciones (street-address, address-line1, postal-code, country-name), información de contacto (email, tel, tel-national), credenciales (username, current-password, new-password), detalles de pago (cc-name, cc-number, cc-exp, cc-csc) y más. Los tokens también pueden llevar prefijos con identificadores de sección (por ejemplo, section-billing) y palabras clave de envío o facturación para gestionar varios grupos de direcciones en una sola página.

Por qué es importante

Este criterio existe principalmente para beneficiar a personas con discapacidades cognitivas, incluidas personas con dislexia, deterioros de memoria, trastornos por déficit de atención y dificultades de aprendizaje. Para estas personas, rellenar correctamente un formulario de pago complejo — con campos separados para nombre de pila, apellido, dirección, ciudad, código postal, teléfono y datos de pago — puede suponer una carga cognitiva considerable. Cuando los tokens de autocomplete son correctos, los navegadores pueden rellenar previamente los campos a partir del perfil guardado de la persona usuaria con una sola interacción, reduciendo drásticamente la fricción y el riesgo de errores.

Las personas con discapacidades motoras — incluidas personas con función limitada de las manos que usan acceso por pulsadores, software de seguimiento ocular o dispositivos de soplo y succión — se benefician por igual. Escribir es lento, requiere esfuerzo y a veces es doloroso para estas personas. Un autocompletado que funcione de forma fiable puede transformar una tarea de diez minutos en una tarea casi instantánea. Según la Organización Mundial de la Salud, aproximadamente 1,3 mil millones de personas en todo el mundo viven con alguna forma de discapacidad significativa, y las discapacidades motoras que afectan al control fino de las manos se encuentran entre las más comunes.

Más allá del autocompletado, los tokens correctos de autocomplete permiten que los navegadores y las tecnologías de apoyo presenten iconos personalizados, etiquetas o interfaces de entrada aumentadas — por ejemplo, mostrar automáticamente un teclado telefónico para un campo tel en un dispositivo móvil, o mostrar un gráfico de tarjeta de crédito para un campo cc-number. Los gestores de contraseñas, que son herramientas de accesibilidad fundamentales para personas con deterioros de memoria, también dependen de estos tokens para identificar y rellenar correctamente los campos de credenciales.

Considere un escenario real: una persona con parálisis cerebral está completando una solicitud de prestaciones públicas. El formulario tiene doce campos que abarcan nombre, dirección, documento nacional de identidad y datos de contacto. Sin valores correctos de autocomplete, cada campo debe escribirse manualmente. Un solo token mal escrito — por ejemplo, autocomplete="surname" en lugar de autocomplete="family-name" — basta para impedir que el navegador reconozca el campo, obligando a la persona a escribir su apellido carácter por carácter. Con tokens correctos, todo el formulario puede rellenarse automáticamente en segundos, reduciendo tanto el esfuerzo como las tasas de error.

También hay beneficios de usabilidad y de tasa de conversión para las organizaciones: la investigación muestra de forma consistente que los formularios compatibles con autocompletado tienen menores tasas de abandono y mayores tasas de finalización, lo que significa que corregir los tokens de autocompletado no solo es una mejora de accesibilidad, sino también una mejora directa para el negocio.

Reglas relacionadas de Axe-core

• autocomplete-valid — Esta es la regla principal de axe-core para WCAG 1.3.5. Inspecciona cada elemento <input>, <select> y <textarea> que tenga un atributo autocomplete y comprueba si el valor del atributo es un token válido y reconocido de la especificación de autocompletado de HTML. La regla marca elementos en los que el token está mal escrito (por ejemplo, given name con un espacio en lugar de un guion), en los que se ha usado un valor propietario no estándar (por ejemplo, autocomplete="first-name"), o en los que el orden de los tokens en un valor con varios tokens es incorrecto (por ejemplo, colocar el nombre del campo antes de un prefijo de sección obligatorio). La regla no marca campos a los que les falta por completo el atributo autocomplete — esa situación requiere revisión manual — porque axe-core no puede determinar de forma programática si un campo dado está dentro del alcance del criterio (es decir, si recopila información sobre la persona usuaria).
• Por qué también se requiere prueba manual — Las herramientas automatizadas como axe-core solo pueden validar que un valor de autocomplete presente sea sintácticamente correcto; no pueden determinar si el token elegido describe con precisión el propósito del campo. Por ejemplo, un campo de teléfono de facturación con autocomplete="email" pasaría la regla automatizada (ya que email es un token válido) pero incumpliría el criterio porque el token no coincide con el propósito real del campo. Del mismo modo, las herramientas automatizadas no pueden identificar campos a los que les falta un atributo autocomplete pero deberían tenerlo, porque determinar si un campo recopila información personal sobre la persona usuaria requiere juicio humano basado en el contexto. Por lo tanto, la revisión manual de cada campo de formulario que recopila datos específicos de la persona usuaria es esencial para el cumplimiento completo de 1.3.5.

Cómo hacer las pruebas

1. Ejecutar un análisis automatizado con axe DevTools o Lighthouse. Abra la página que contiene el formulario en Chrome o Firefox. En axe DevTools, haga clic en "Analyze" y filtre los resultados por el ID de regla autocomplete-valid. En Lighthouse, ejecute una auditoría de accesibilidad y busque infracciones que hagan referencia a autocomplete. Anote cada elemento marcado y registre los valores de token no válidos que se informen. Resuelva cada elemento marcado y vuelva a analizar para confirmar la corrección.
2. Identificar manualmente todos los campos de entrada dentro del alcance. Revise el formulario y enumere cada campo que recopile información sobre la persona usuaria actual — campos de nombre, campos de dirección, correo electrónico, teléfono, datos de pago, credenciales. Para cada campo, verifique que haya un atributo autocomplete presente y que su token coincida con el propósito real del campo según la lista de tokens de autocompletado de HTML. Los campos que recopilan información sobre otras personas están fuera del alcance y pueden excluirse.
3. Probar el comportamiento de autocompletado del navegador. En Chrome o Firefox, asegúrese de que el navegador tenga un perfil guardado (Settings > Autofill). Navegue a la página del formulario y haga clic en el primer campo de información personal. Confirme que el navegador presenta una sugerencia de autocompletado y que al seleccionarla se rellenan los campos correctos con los valores correctos. Repita para los campos de dirección, campos de pago y campos de credenciales. Si el autocompletado no sugiere valores o rellena campos incorrectos, es probable que los tokens de autocompletado sean incorrectos.
4. Probar con una combinación de lector de pantalla y navegador. Con NVDA y Firefox, navegue a cada campo del formulario usando la tecla Tab. NVDA debería anunciar la etiqueta y el propósito del campo; algunas combinaciones de lector de pantalla y navegador también anunciarán el propósito de autocompletado. Con VoiceOver en macOS (Safari), navegue por los campos usando Tab y escuche si VoiceOver anuncia la disponibilidad de autocompletado. Con JAWS y Chrome, del mismo modo, recorra los campos con Tab y confirme que JAWS anuncia el contexto esperado del campo. Aunque los lectores de pantalla no siempre anuncian explícitamente los tokens de autocompletado, confirmar que el autocompletado funciona correctamente en combinación con la navegación por teclado valida que el propósito programático está expuesto.
5. Inspeccionar los atributos de autocompletado en las DevTools del navegador. Haga clic con el botón derecho en cada campo del formulario y seleccione "Inspect". En el panel Elements, confirme que el atributo autocomplete está presente y que su valor coincide exactamente con un token válido. Preste especial atención a los valores con varios tokens — por ejemplo, autocomplete="shipping street-address" — y confirme que el orden de los tokens sigue la especificación (nombre de sección, luego "shipping" o "billing", luego nombre del campo).

Cómo corregir

Campos de nombre — Incorrecto

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

Campos de nombre — Correcto

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

Formulario de dirección con secciones de facturación y envío — Incorrecto

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

Formulario de dirección con secciones de facturación y envío — Correcto

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

Campo de teléfono — Incorrecto

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

Campo de teléfono — Correcto

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

Credenciales de inicio de sesión — Incorrecto

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='off'>

Credenciales de inicio de sesión — Correcto

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

Errores comunes

• Usar autocomplete="firstname" o autocomplete="first-name" en lugar del token correcto given-name". Estos valores no estándar no son reconocidos por los navegadores ni por las tecnologías de apoyo aunque parezcan lógicos. Utilice siempre los tokens exactos de la especificación de autocompletado de HTML.
• Usar autocomplete="phone" en lugar de autocomplete="tel". La palabra "phone" no es un token válido. La especificación utiliza tel para un número de teléfono completo, y tel-national, tel-area-code, tel-local para subpartes de un número de teléfono.
• Configurar autocomplete="off" en campos de credenciales como una medida de seguridad equivocada. Los navegadores modernos y la especificación WCAG reconocen que impedir el autocompletado en formularios de inicio de sesión crea barreras reales para las personas con discapacidad y no mejora de forma significativa la seguridad. Utilice autocomplete="username" y autocomplete="current-password" en su lugar.
• Omitir por completo el atributo autocomplete en campos de datos personales, suponiendo que el navegador inferirá el propósito a partir del nombre o la etiqueta del campo. Los navegadores usan heurísticas para adivinar el propósito del campo, pero estas son poco fiables e inconsistentes entre navegadores. Se requieren tokens explícitos para garantizar una experiencia accesible.
• Usar autocomplete="address" en lugar de los sub-tokens específicos de dirección. No existe un token address en la especificación. Debe usar street-address, address-line1, address-line2, address-level1 (estado/provincia), address-level2 (ciudad) y postal-code individualmente.
• Colocar las palabras clave de envío o facturación en el orden incorrecto en valores con varios tokens. El orden correcto es: prefijo de sección opcional (por ejemplo, section-billing), luego la palabra clave opcional de envío/facturación, luego el token del nombre del campo. Escribir autocomplete="street-address billing" no es válido; la forma correcta es autocomplete="billing street-address".
• Aplicar autocomplete solo a campos visibles e ignorar campos ocultos o revelados dinámicamente. Los campos que están ocultos inicialmente pero se muestran mediante la interacción de la persona usuaria (como líneas de dirección adicionales o campos opcionales) también deben llevar tokens de autocompletado correctos cuando se activan.
• Usar JavaScript para eliminar o sobrescribir dinámicamente el atributo autocomplete después de la carga de la página. Algunas bibliotecas de formularios o frameworks de interfaz de usuario restablecen los atributos de entrada cuando los componentes se montan o se vuelven a renderizar, eliminando inadvertidamente los tokens de autocompletado. Verifique siempre que el atributo persista en el DOM en vivo después de que todo el JavaScript se haya ejecutado.
• Suponer que type="email" o type="tel" en una entrada es suficiente para comunicar el propósito sin autocomplete. Aunque type proporciona cierta información, el atributo autocomplete es una señal separada y explícita requerida por WCAG 1.3.5 y utilizada de forma diferente por los navegadores y las tecnologías de apoyo.
• Usar el mismo token de autocomplete en dos campos diferentes que recopilan datos distintos. Por ejemplo, etiquetar tanto un campo de correo electrónico del trabajo como un campo de correo electrónico personal con autocomplete="email" confunde a los navegadores y puede dar lugar a un autocompletado incorrecto. Utilice prefijos de sección (por ejemplo, section-work email frente a section-personal email) para desambiguar.

Relación con la normativa de accesibilidad de Turquía

La Circular Presidencial 2025/10 de Turquía, publicada en el Boletín Oficial nº 32933 el 21 de junio de 2025, establece requisitos de accesibilidad vinculantes para una amplia gama de organizaciones que operan en Turquía. La Circular exige la conformidad con WCAG 2.2 en nivel AA como estándar base para los servicios digitales, lo que incluye directamente WCAG 1.3.5 — Identify Input Purpose.

Los tipos de entidades cubiertas por la Circular son muy amplios. Las instituciones públicas y los organismos gubernamentales están obligados a cumplir estas normas para todos los servicios digitales dirigidos a la ciudadanía. Las organizaciones del sector privado cubiertas incluyen plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y proveedores de atención sanitaria, operadores de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas privadas de transporte de pasajeros e instituciones educativas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). La implicación práctica es que prácticamente todos los principales productos digitales orientados a consumidores en Turquía — desde aplicaciones bancarias hasta procesos de pago en comercios en línea y portales de citas médicas — deben tener tokens de autocomplete correctamente implementados en todos los campos de entrada de datos personales.

Para WCAG 1.3.5 específicamente, esto significa que cualquier formulario turco de pago de comercio electrónico, formulario de apertura de cuenta bancaria, formulario de registro de pacientes de hospital o formulario de suscripción de telecomunicaciones que recopile información de la persona usuaria como nombre, dirección, número de teléfono o datos de pago debe incluir valores válidos de atributo autocomplete en cada campo de entrada pertinente. No hacerlo constituye una no conformidad de nivel AA y puede impedir que una organización obtenga o mantenga el Accessibility Logo (Erişilebilirlik Logosu), la marca oficial emitida por el Ministerio de Familia y Servicios Sociales que certifica que los servicios digitales de una organización cumplen las normas de accesibilidad.

El Accessibility Logo tiene peso reputacional y regulatorio, y las organizaciones en mercados de consumo competitivos — como el comercio electrónico y la banca — tienen fuertes incentivos para conseguirlo y mantenerlo. Dado que WCAG 1.3.5 es sencillo de implementar (añadir o corregir valores de atributo autocomplete no requiere cambios de arquitectura) y, sin embargo, proporciona un beneficio significativo a las personas con discapacidades cognitivas y motoras, representa una de las mejoras de accesibilidad de mayor valor y menor esfuerzo que una organización puede realizar en la búsqueda de la conformidad completa de nivel AA en virtud de la Circular 2025/10.

Las organizaciones deben auditar todos los formularios de sus propiedades digitales — incluidas las interfaces web móviles y los diseños responsivos — y establecer una política de desarrollo que exija tokens correctos de autocomplete como parte estándar de cualquier implementación de formulario. Esto debe hacerse cumplir mediante pruebas automatizadas en las canalizaciones de CI/CD utilizando herramientas como axe-core, de modo que las regresiones se detecten antes de que lleguen a producción.