WCAG 3.3.7: Entrada redundante

Qué significa esta regla

WCAG 3.3.7 Entrada redundante es un criterio de éxito de Nivel A introducido en WCAG 2.2. Establece: «La información previamente introducida por el usuario o proporcionada a este, que se requiere volver a introducir en el mismo proceso, se rellena automáticamente o está disponible para que el usuario la seleccione.» En términos sencillos, si un usuario ya ha escrito su dirección de correo electrónico, dirección de envío, fecha de nacimiento o cualquier otra información durante una sesión, tu interfaz no debe obligarle a escribirla de nuevo dentro del mismo proceso o flujo.

El criterio se aplica de forma amplia a cualquier formulario de varios pasos, proceso de pago, asistente de registro, flujo de reserva de citas o secuencia similar en la que los datos recopilados en un paso puedan ser necesarios de nuevo en un paso posterior. Los comportamientos afectados incluyen campos de texto, menús desplegables, casillas de verificación, botones de opción y cualquier otro control de formulario que recopile datos proporcionados por el usuario. Cuando se requiere de nuevo la misma información, esta debe estar o bien pre-rellena automáticamente usando el valor proporcionado anteriormente, o bien ofrecida como una opción seleccionable para que el usuario pueda confirmarla en lugar de volver a introducirla.

Un cumplimiento de este criterio se ve así: un formulario de dirección de facturación que se pre-rellena con la dirección de envío que el usuario introdujo en la pantalla anterior, o un paso de confirmación que muestra la dirección de correo electrónico introducida previamente por el usuario en un campo de solo lectura. Otro patrón conforme es una casilla de verificación etiquetada «Mi dirección de facturación es la misma que mi dirección de envío» que, al marcarse, copia los valores automáticamente. Un incumplimiento se ve así: un flujo de registro de varios pasos que pide una dirección de correo electrónico en el paso 1 y de nuevo en el paso 3 sin pre-rellenar el segundo campo, o un formulario de reclamación de seguro que pide el nombre de la persona reclamante y el número de póliza en varias pantallas separadas sin autocompletado.

WCAG 3.3.7 define dos excepciones oficiales. La primera excepción se aplica cuando volver a introducir la información es esencial para el proceso; por ejemplo, un campo «Confirma tu nueva contraseña» pide intencionadamente a los usuarios que escriban la misma contraseña dos veces como salvaguarda contra errores tipográficos, y esto se considera una comprobación de seguridad esencial. La segunda excepción se aplica cuando la información introducida previamente ya no es válida; por ejemplo, si una sesión ha caducado o un producto se ha agotado y el usuario debe reiniciar un proceso con datos nuevos. Fuera de estas excepciones, la entrada redundante constituye un incumplimiento de conformidad.

Por qué es importante

La entrada redundante recarga de forma desproporcionada a las personas cuyas condiciones hacen que escribir sea lento, doloroso, propenso a errores o cognitivamente exigente. Entender quién se ve afectado ayuda a desarrolladores y diseñadores a apreciar por qué este criterio es más que una función de comodidad: es una barrera real para muchas personas.

Personas con discapacidades motoras, como quienes tienen temblores, lesiones medulares o condiciones como ELA o esclerosis múltiple, pueden depender de acceso por pulsadores, punteros bucales, software de seguimiento ocular o control por voz para introducir texto. Para estas personas, escribir incluso una dirección corta puede llevar varios minutos y un esfuerzo físico considerable. Que se les exija repetir esa entrada no es simplemente molesto: puede causar dolor físico o hacer que la tarea sea prácticamente imposible en una sola sesión.

Personas con discapacidades cognitivas, incluidas la dislexia, los trastornos por déficit de atención, las lesiones cerebrales traumáticas y las condiciones relacionadas con la demencia, pueden tener dificultades para recordar lo que introdujeron tres pasos atrás. Transcribir información con precisión desde la memoria o desde un documento en papel varias veces aumenta enormemente las tasas de error y abandono. Según la Organización Mundial de la Salud, más de 1 mil millones de personas en todo el mundo viven con alguna forma de discapacidad, y las discapacidades cognitivas representan uno de los segmentos más grandes y desatendidos en la planificación de la accesibilidad.

Personas con diferencias en las extremidades superiores, incluidas quienes nacieron con o han adquirido diferencias en las extremidades, escriben mucho más despacio y pueden usar dispositivos de entrada alternativos. Cada pulsación de tecla adicional requerida multiplica la carga para estas personas.

Considera un escenario del mundo real: una persona con artritis reumatoide está reservando una cita médica a través del portal en línea de un hospital. En la pantalla 1 introduce su número de identificación nacional, nombre, fecha de nacimiento y número de teléfono de contacto. En la pantalla 3 el portal vuelve a pedir su nombre y fecha de nacimiento para confirmar el registro de paciente. Esta persona debe volver a escribir laboriosamente información que proporcionó apenas dos pantallas antes, arriesgando errores tipográficos que podrían desajustar los registros y experimentando un esfuerzo físico innecesario. Un simple pre-relleno o autocompletado de esos campos eliminaría por completo la barrera.

Más allá de la accesibilidad, eliminar la entrada redundante mejora las tasas de conversión, reduce el abandono de formularios y disminuye los tickets de soporte causados por errores de introducción de datos, aportando un valor empresarial medible junto con un diseño inclusivo.

Reglas relacionadas de Axe-core

WCAG 3.3.7 es un criterio que requiere pruebas manuales. Actualmente no existe ninguna regla automatizada de axe-core que pueda detectar de forma fiable infracciones de entrada redundante, porque las herramientas automatizadas no pueden entender la relación semántica entre los datos introducidos a lo largo de varios pasos o páginas en un proceso dinámico. No tienen conocimiento de qué información se recopiló en un paso anterior, qué información se está solicitando en el paso actual o si esas dos piezas de información son lógicamente idénticas. Solo una persona evaluadora que recorra el flujo completo puede observar y evaluar si se está pidiendo dos veces la misma información sin pre-relleno.

• Se requieren pruebas manuales (nuevo en WCAG 2.2): axe-core y otros escáneres automatizados de accesibilidad analizan el DOM de un único estado de página cada vez. No pueden rastrear valores introducidos por el usuario a través de múltiples cargas de página o pasos de formulario, no pueden comparar etiquetas de campos entre pasos para identificar duplicación semántica y no pueden evaluar si un mecanismo de pre-relleno funciona correctamente. Las personas evaluadoras deben recorrer manualmente los procesos de varios pasos, registrar qué datos introducen en cada paso y verificar en cada paso posterior si los datos proporcionados previamente están pre-rellenos o son seleccionables. Cualquier herramienta que afirme detectar automáticamente infracciones de 3.3.7 produciría una tasa de falsos negativos extremadamente alta y no debería utilizarse como único método de prueba.

Cómo probar

1. Escaneo automatizado como punto de partida: Ejecuta axe DevTools, Lighthouse o el auditor de Accsible en cada paso individual de tu proceso de varios pasos. Aunque estas herramientas no marcarán directamente infracciones de 3.3.7, sí sacarán a la luz problemas relacionados como atributos de autocompletado ausentes, campos de formulario sin etiquetar y otros incumplimientos de criterios 3.3.x que suelen coexistir. Documenta todos los campos de formulario que encuentres en cada paso.
2. Mapear los requisitos de datos entre pasos: Antes de las pruebas manuales, crea una tabla o hoja de cálculo sencilla que liste cada paso del proceso y todos los campos de datos que recopila. Luego identifica cualquier etiqueta de campo o tipo de dato que aparezca en más de un paso. Este ejercicio de mapeo saca a la luz posibles infracciones incluso antes de que abras un navegador.
3. Recorrido manual — escritorio: Usando un ratón y teclado estándar, completa todo el proceso de varios pasos (por ejemplo, pago, registro, presentación de reclamaciones). Introduce valores realistas en cada campo. Cuando llegues a un paso que aparezca en tu mapa como campo duplicado, comprueba si el campo está pre-relleno con tu entrada anterior o si hay disponible una opción seleccionable que presente tu entrada anterior. Si no se da ninguno de los dos casos, registra un incumplimiento. Repite esta prueba con un lector de pantalla (NVDA con Firefox, JAWS con Chrome, VoiceOver con Safari) para confirmar que los valores pre-rellenos se anuncian correctamente y que los controles de selección para valores introducidos previamente son accesibles mediante teclado.
4. Recorrido manual — móvil: Completa el mismo flujo en iOS (VoiceOver + Safari) y Android (TalkBack + Chrome). Presta atención a si la aplicación suprime las funciones nativas de autocompletado o autofill, lo que podría crear inadvertidamente barreras de entrada redundante incluso si la persona desarrolladora pretendía que el autocompletado ayudara.
5. Probar las excepciones: Identifica cualquier campo que pida intencionadamente una entrada duplicada (por ejemplo, confirmación de contraseña, volver a introducir el correo electrónico). Verifica que estos califican como comprobaciones esenciales de seguridad o validación según la excepción de WCAG y que no son simplemente campos redundantes que deberían eliminarse o pre-rellenarse.
6. Probar con el autocompletado desactivado: Algunas personas usuarias desactivan el autocompletado del navegador por motivos de privacidad. Prueba si el propio mecanismo de pre-relleno de la aplicación (del lado del servidor o impulsado por JavaScript) sigue funcionando correctamente cuando el autocompletado del navegador está desactivado, garantizando que el criterio se cumple independientemente del comportamiento del navegador.

Cómo corregir

Pago de varios pasos — misma dirección requerida en dos pantallas — Incorrecto

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

Pago de varios pasos — misma dirección requerida en dos pantallas — Correcto

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

Asistente de registro que pide el correo electrónico dos veces sin justificación — Incorrecto

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

Asistente de registro — correo electrónico pre-relleno a partir de datos de sesión — Correcto

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

Reserva de cita — datos de paciente solicitados de nuevo en el paso de resumen — Incorrecto

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

Reserva de cita — fecha de nacimiento mostrada como confirmación de solo lectura — Correcto

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

Errores comunes

• Crear formularios de varios pasos como páginas independientes sin estado de sesión compartido, de modo que no haya ningún mecanismo para trasladar los valores introducidos en pasos anteriores; este es el error arquitectónico más fundamental que conduce a incumplimientos de 3.3.7.
• Proporcionar una casilla «igual que la dirección de envío» pero no rellenar realmente los campos de facturación cuando se marca, obligando a las personas usuarias a seguir escribiendo los datos de la dirección manualmente incluso después de indicar que deberían coincidir.
• Pre-rellenar campos al cargar la página pero luego vaciarlos al producirse un error de validación, de modo que una persona que comete un error en un paso posterior deba volver a introducir todos los datos proporcionados previamente cuando regrese para corregirlo.
• Almacenar datos de sesión de forma insegura y optar por desactivarlos en lugar de corregir el problema de seguridad, lo que da lugar a una experiencia de pre-relleno defectuosa que técnicamente constituye un incumplimiento de 3.3.7.
• Usar la excepción de confirmación de contraseña como justificación para obligar a las personas usuarias a volver a introducir direcciones de correo electrónico, cuando la confirmación del correo electrónico no es una comprobación de seguridad esencial y no califica según la excepción de WCAG.
• No pasar los valores arrastrados a través de campos ocultos en formularios renderizados del lado del servidor, lo que provoca que los valores pre-rellenos se pierdan cuando una persona usuaria navega hacia atrás y hacia adelante entre pasos usando los botones de historial del navegador.
• Confiar únicamente en el autocompletado del navegador para cumplir este criterio, sin implementar un pre-relleno a nivel de aplicación; las personas que desactivan el autocompletado por motivos de privacidad se quedan entonces sin una ruta conforme a través del proceso.
• Pre-rellenar un campo pero configurarlo como disabled en lugar de readonly, lo que hace que el valor se excluya del envío del formulario en la mayoría de los navegadores, rompiendo el proceso y potencialmente obligando a volver a introducirlo.
• No probar el flujo completo de extremo a extremo con personas que usan software de entrada por voz como Dragon NaturallySpeaking, donde los campos redundantes pueden requerir repetir varias veces el mismo comando de dictado verbal, una carga significativa que es fácil pasar por alto en las pruebas de desarrollo.
• Tratar este criterio como si solo se aplicara a campos de dirección, cuando se aplica por igual a cualquier dato repetido, incluidos nombres, números de teléfono, números de identificación nacional, números de póliza, fechas y cualquier otra información proporcionada por la persona usuaria que se solicite más de una vez en el mismo proceso.

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, exige la conformidad en accesibilidad web para una amplia gama de entidades públicas y privadas que operan en Turquía. WCAG 3.3.7 Entrada redundante es un criterio de Nivel A en WCAG 2.2, y la conformidad de Nivel A es la base obligatoria según esta circular. Esto significa que cualquier entidad cubierta que opere un sitio web, aplicación web o servicio digital no debe exigir a las personas usuarias que vuelvan a introducir información que ya han proporcionado dentro del mismo proceso —sin excepción— o se arriesga a no cumplir la normativa.

La circular establece un calendario de implementación por fases: las instituciones públicas deben lograr la conformidad en el plazo de un año desde la publicación de la circular, mientras que las entidades del sector privado en las categorías cubiertas disponen de dos años para cumplirla.

Los tipos de entidades cubiertas por la circular son amplios e incluyen plataformas y mercados de comercio electrónico, todas las instituciones públicas y organismos gubernamentales, bancos y proveedores de servicios financieros, hospitales y portales de atención sanitaria (tanto públicos como privados), empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Para todas estas entidades, los procesos digitales de varios pasos —flujos de pago en sitios de comercio electrónico, registro de pacientes en portales hospitalarios, apertura de cuentas en plataformas bancarias, formularios de inscripción en sitios web de escuelas— deben auditarse y corregirse para eliminar cualquier caso de entrada redundante.

En la práctica, esta regulación sitúa el cumplimiento de WCAG 3.3.7 directamente dentro del ámbito de los equipos de compras, producto y jurídico en toda la economía digital de Turquía. Por ejemplo, una plataforma turca de comercio electrónico que opere un proceso de pago de varios pasos que pide una dirección de entrega en una pantalla y una dirección de facturación en la siguiente sin ofrecer una opción de pre-relleno o copia está en violación directa tanto de WCAG 2.2 Nivel A como de la Circular Presidencial. Del mismo modo, el portal de reserva de citas de un hospital estatal que pide a las personas pacientes que vuelvan a introducir su número de identidad o fecha de nacimiento en varias pantallas es no conforme. Las organizaciones sujetas a la circular deberían priorizar una auditoría de extremo a extremo de todos los procesos de varios pasos como parte de su hoja de ruta de conformidad, tratando la eliminación de la entrada redundante como una tarea de ingeniería obligatoria, no como una mejora opcional.