WCAG 3.3.6: Prevención de errores (Todos)

Qué Significa Esta Regla

WCAG 3.3.6 — Prevención de errores (Todos) es un criterio de éxito de nivel AAA bajo el principio de Comprensible. Amplía los requisitos de 3.3.4 (Prevención de errores: legales, financieros, datos) para abarcar todas las páginas que requieren que una persona usuaria envíe información, independientemente de si ese envío implica compromisos legales, transacciones financieras o datos de identificación personal.

En esencia, el criterio exige que, para cualquier página web en la que una persona usuaria envíe información, se cumpla al menos una de las siguientes tres condiciones:

• Reversible: Los envíos son reversibles a posteriori. La persona usuaria puede deshacer, cancelar o retractar una acción dentro de un plazo razonable. Por ejemplo, se puede recuperar un mensaje enviado o se puede cancelar un formulario enviado desde una cola de confirmación.
• Comprobado: Los datos introducidos por la persona usuaria se comprueban en busca de errores de entrada antes del envío final, y se le da la oportunidad de corregir esos errores. Esto implica validación en línea, resúmenes previos al envío o flujos de revisión paso a paso.
• Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes de que el envío se finalice. Esto puede ser una pantalla de revisión, un cuadro de diálogo de confirmación o un asistente de varios pasos con un paso final de revisión.

La diferencia clave entre 3.3.4 y 3.3.6 es el alcance. El criterio 3.3.4 se aplica solo a acuerdos legales, transacciones financieras, respuestas de pruebas y eliminaciones de datos controlados por la persona usuaria. El criterio 3.3.6 amplía esto a todas las páginas que requieren cualquier tipo de envío de datos por parte de la persona usuaria, incluidos formularios de contacto, suscripciones a boletines, secciones de comentarios, respuestas a encuestas, actualizaciones de perfil, configuraciones de búsqueda y cualquier otra entrada de datos controlada por la persona usuaria.

Qué se considera un cumplimiento: Un formulario cumple si implementa de forma consistente al menos uno de los tres mecanismos anteriores. Una página de confirmación antes del envío final, una pantalla de resumen con una opción de "Editar", validación del lado del cliente o del servidor con oportunidades de corrección de errores, o una ventana de deshacer claramente comunicada satisfacen el criterio.

Qué se considera un incumplimiento: Un formulario de un solo paso que envía los datos inmediatamente al hacer clic en el botón, sin validación, sin pantalla de revisión y sin mecanismo de deshacer, incumple este criterio. Del mismo modo, un formulario que valida pero no ofrece la oportunidad de corregir errores antes de volver a enviar también incumple.

La especificación WCAG no exige los tres mecanismos simultáneamente: basta con cumplir cualquiera de ellos. Sin embargo, combinar dos o tres mecanismos proporciona una defensa en profundidad y sirve a un abanico más amplio de personas usuarias y contextos.

Por Qué Importa

La prevención de errores no es simplemente una mejora de usabilidad: es un requisito fundamental de accesibilidad para las personas usuarias que afrontan un riesgo elevado de errores de entrada debido a una discapacidad o a limitaciones situacionales.

Discapacidades cognitivas y de aprendizaje: Las personas con dislexia, TDAH o problemas de memoria cometen con frecuencia errores tipográficos, invierten dígitos o pierden el hilo en formularios complejos con múltiples campos. Sin un mecanismo de revisión, una dirección de correo mal escrita en un formulario de contacto puede suponer una respuesta perdida, o una dirección introducida incorrectamente en un formulario de entrega puede provocar paquetes extraviados. No se trata de casos aislados: según la Organización Mundial de la Salud, aproximadamente 1.000 millones de personas en todo el mundo viven con algún tipo de condición cognitiva o neurológica que afecta a su funcionamiento diario.

Discapacidades motoras: Las personas con temblores, control motor fino limitado o que dependen de acceso por pulsadores o software de entrada por voz suelen activar envíos de formularios accidentalmente o introducir caracteres no deseados. Una persona con enfermedad de Parkinson que navega por un formulario complejo con una interfaz de pulsadores puede enviar sin querer un formulario incompleto o incorrecto. Sin pasos de reversibilidad o confirmación, estos errores se vuelven permanentes.

Personas usuarias de lectores de pantalla: Las personas ciegas que navegan con JAWS, NVDA o VoiceOver pueden no tener la misma visión de conjunto de un formulario completado que disfrutan las personas videntes antes de enviarlo. Una pantalla de confirmación o un resumen leído en voz alta por un lector de pantalla les ofrece una última oportunidad de verificar sus datos antes de que se envíen de forma irreversible.

Baja alfabetización digital y población envejecida: Las personas mayores y quienes son nuevas en las interfaces digitales son especialmente vulnerables a los envíos accidentales. Un paso de confirmación con resúmenes en lenguaje sencillo proporciona una red de seguridad que reduce drásticamente los costes de soporte y la frustración de las personas usuarias.

Escenario del mundo real: Considérese un portal de administración electrónica turco en el que una persona ciudadana rellena un largo formulario burocrático para registrar un negocio. Si la persona omite accidentalmente un campo obligatorio o introduce su número de identificación fiscal de forma incorrecta y el formulario se envía inmediatamente sin un paso de revisión, puede que no se dé cuenta del error hasta recibir una notificación formal de rechazo días después. Una simple pantalla de confirmación que muestre todos los datos introducidos antes del envío final habría evitado esto por completo.

Beneficios de SEO y usabilidad: Las páginas que implementan una prevención de errores sólida tienden a tener menores tasas de abandono de formularios, mayores tasas de conversión y mejores índices de satisfacción de las personas usuarias. Los motores de búsqueda tienen cada vez más en cuenta las señales de experiencia de usuario en las clasificaciones, y las páginas con altas tasas de rebote debido a errores en formularios sufren indirectamente en visibilidad orgánica.

Reglas Relacionadas de Axe-core

WCAG 3.3.6 requiere pruebas manuales porque ninguna herramienta automatizada puede determinar si un flujo de envío de formulario dado cumple los requisitos de reversibilidad, comprobación de errores o confirmación de este criterio. Los escáneres de accesibilidad automatizados como axe-core pueden verificar la presencia de atributos ARIA individuales, etiquetas y mensajes de error, pero no pueden evaluar la lógica general del flujo de envío, la existencia de un paso de confirmación o si un mecanismo de deshacer es realmente funcional. El criterio se refiere fundamentalmente al diseño de la interacción y al flujo de experiencia de usuario, no al marcado estático.

• No existe una regla específica de axe-core para 3.3.6. Axe-core y motores similares prueban elementos individuales del DOM frente a requisitos específicos de atributos o roles. Determinar si un formulario de varias páginas incluye un paso de revisión antes del envío final requiere comprender el flujo de navegación de la aplicación y el comportamiento del lado del servidor, información a la que las herramientas de análisis estático no pueden acceder. Una persona evaluadora debe recorrer todo el proceso de envío para evaluar el cumplimiento.
• Reglas relacionadas que apoyan la calidad general de los formularios (aunque no específicamente 3.3.6): Reglas como label (cada campo de entrada tiene una etiqueta asociada), aria-required-attr (los atributos ARIA obligatorios están presentes) y form-field-multiple-labels (las entradas no tienen etiquetas contradictorias) contribuyen a la base de formularios accesibles. Garantizar que estas se superan es un requisito previo para una prevención de errores significativa, pero superarlas no garantiza el cumplimiento de 3.3.6.
• Por qué la automatización se queda corta: Un análisis automatizado de una página de pago puede confirmar que todos los campos de entrada tienen etiquetas y que los mensajes de error están asociados programáticamente a las entradas. Pero no puede determinar si al hacer clic en "Enviar" se lleva a la persona usuaria a una pantalla de revisión, si existe una opción de "Cancelar" o si el sistema envía un correo de confirmación con un enlace de cancelación. Estas son cuestiones de comportamiento y de proceso que solo la evaluación humana puede responder.

Cómo Probar

1. Ejecutar un análisis automatizado como base: Utiliza axe DevTools, Lighthouse o el modo de auditoría integrado del widget de Accsible para analizar todas las páginas que contengan formularios. Aunque estas herramientas no señalarán directamente infracciones de 3.3.6, establecen una base al identificar etiquetas faltantes, ausencia de mensajes de error o retroalimentación de validación mal asociada. Resuelve todos los hallazgos automatizados antes de pasar a las pruebas manuales.
2. Identificar todos los formularios de envío del sitio: Crea un inventario completo de cada página que acepte y envíe datos de la persona usuaria: formularios de contacto, formularios de registro, formularios de inicio de sesión, formularios de preferencias de búsqueda, páginas de actualización de perfil, secciones de comentarios, suscripciones a boletines y cualquier asistente de varios pasos. Cada uno debe probarse de forma independiente.
3. Probar el camino feliz con errores intencionales: En cada formulario, introduce intencionadamente datos incorrectos, incompletos o mal formados (por ejemplo, una dirección de correo no válida, un número de teléfono con letras, dejar campos obligatorios vacíos). Envía el formulario y observa: ¿La página impide el envío y proporciona mensajes de error? ¿Los mensajes de error están asociados a los campos correctos? ¿La persona usuaria tiene una oportunidad clara de corregir y volver a enviar?
4. Probar mecanismos de confirmación o revisión: Para los formularios que superan la validación, complétalos con datos válidos y envíalos. Observa si aparece una pantalla de confirmación, un cuadro de diálogo de resumen o un paso de revisión antes de que los datos se envíen de forma irrevocable. Verifica que el paso de revisión permite a la persona usuaria volver atrás y editar las entradas.
5. Probar la reversibilidad tras el envío: Después de un envío correcto, comprueba si existe un mecanismo de cancelación, deshacer o retractación. Esto puede ser un enlace de "Cancelar envío" en un correo de confirmación, una pantalla de gestión de cola en un área de administración o una notificación dentro de la aplicación con una acción de deshacer. Verifica que el mecanismo funciona y se comunica claramente a las personas usuarias.
6. Pruebas con lector de pantalla usando NVDA + Firefox: Navega hasta cada formulario usando NVDA y Firefox. Recorre todos los campos con la tecla Tab, introduce datos y envía el formulario. Verifica que los mensajes de error se anuncian cuando aparecen, que la pantalla de revisión (si existe) se puede leer completamente en orden de documento y que todos los controles interactivos (botones de editar, confirmar, cancelar) en la pantalla de confirmación son accesibles con teclado y están correctamente etiquetados.
7. Pruebas con lector de pantalla usando VoiceOver + Safari (macOS/iOS): Repite el proceso anterior usando VoiceOver en Safari. Presta especial atención a las actualizaciones de contenido dinámico: si los errores de validación aparecen dinámicamente mediante JavaScript sin recarga de página, confirma que se muestran mediante regiones activas (aria-live) para que VoiceOver los anuncie sin que la persona usuaria tenga que explorar manualmente la página.
8. Pruebas solo con teclado: Sin ratón, navega por todo el flujo de envío del formulario usando solo las teclas Tab, Shift+Tab, Enter y Espacio. Confirma que todos los elementos interactivos —incluidos los botones de editar, atrás, confirmar y cancelar en las pantallas de revisión— son alcanzables y operables sin un dispositivo apuntador.

Cómo Corregir

Formulario de contacto sin validación ni revisión — Incorrecto

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

Formulario de contacto con validación y paso de confirmación — Correcto

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

Asistente de varios pasos sin paso de resumen — Incorrecto

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

Asistente de varios pasos con paso final de revisión — Correcto

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

Formulario con envío inmediato y sin deshacer — Incorrecto

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

Acción destructiva con cuadro de diálogo de confirmación — Correcto

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Errores Comunes

• Implementar validación pero no exponerla a los lectores de pantalla: Mostrar mensajes de error visualmente mediante cambios de color en CSS o iconos sin asociarlos a la entrada usando aria-describedby o inyectarlos en una región aria-live significa que las personas ciegas nunca escuchan el error: el formulario parece haberse enviado correctamente cuando en realidad sigue incompleto.
• Tratar el cumplimiento de 3.3.4 como suficiente para AAA: Los equipos suelen implementar la prevención de errores solo para formularios financieros o legales (cumpliendo 3.3.4) y asumir que todos los formularios están cubiertos. El criterio 3.3.6 exige las mismas protecciones para todos los formularios del sitio, incluidas suscripciones a boletines, comentarios y actualizaciones de perfil.
• Proporcionar una pantalla de confirmación que es de solo lectura y sin ruta de edición: Una página de revisión que muestra los datos enviados pero ofrece solo un botón de "Confirmar", sin forma de volver y corregir errores, no satisface plenamente el espíritu del criterio y deja a las personas usuarias sin recursos si detectan un error durante la revisión.
• Usar window.confirm() como único mecanismo de confirmación: Los cuadros de diálogo de confirmación nativos del navegador no son accesibles para todas las personas usuarias y no se pueden diseñar ni estructurar para mayor claridad. Además, se comportan de forma inconsistente entre tecnologías de asistencia. Utiliza en su lugar un elemento <dialog> adecuado con los atributos ARIA correspondientes.
• Restablecer todo el formulario al fallar la validación en lugar de conservar las entradas válidas: Cuando una persona usuaria envía un formulario de 10 campos con un solo error y el formulario borra todos los campos, debe volver a introducir todos los datos. Esto es especialmente gravoso para personas con discapacidades motoras o fatiga cognitiva. Conserva siempre los datos válidos y centra la atención solo en los campos erróneos.
• Colocar los mensajes de resumen de errores fuera de la ventana de visualización o del orden de enfoque del teclado: Un banner de resumen de errores inyectado en la parte superior de la página tras un envío fallido no sirve de nada a las personas usuarias que están enfocadas a mitad del formulario. Usa aria-live='assertive' en el contenedor del resumen y mueve el foco a él de forma programática cuando falle el envío.
• Marcar los botones de confirmación con etiquetas vagas como "OK" o "Yes": En una pantalla de revisión, los botones deben comunicar claramente lo que ocurrirá. "Confirm and Send Message" es inequívoco; "OK" no lo es, especialmente para las personas usuarias de lectores de pantalla que pueden no disponer del contexto visual circundante.
• Suponer que la validación del lado del servidor por sí sola satisface el criterio: Si no hay validación del lado del cliente, cada envío requiere un viaje completo al servidor antes de que la persona usuaria se entere de un error. Las personas con conexiones lentas o que pierden la red en mitad del envío pueden quedar en un estado de incertidumbre sin una retroalimentación de error clara.
• No probar el mecanismo de reversibilidad en condiciones realistas: A veces los equipos implementan una opción de "cancelar" en un correo de confirmación pero nunca comprueban si el enlace de cancelación es accesible, si funciona después de que expire la ventana o si el enlace es utilizable por lectores de pantalla. Un mecanismo de deshacer inaccesible no satisface el criterio.
• No gestionar los casos límite de autocompletado en las pantallas de revisión: Cuando el navegador o el gestor de contraseñas autocompletan los campos del formulario, los valores mostrados en una pantalla de revisión pueden no coincidir con lo que realmente se envió si el JavaScript que rellena la revisión toma los datos del DOM antes de que el autocompletado termine. Extrae siempre los valores inmediatamente antes de renderizar la pantalla de revisión, no en la carga inicial de la página.

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 obligaciones obligatorias de accesibilidad digital para una amplia gama de entidades que operan en Turquía. La circular exige que las organizaciones cubiertas se ajusten a WCAG 2.2 en nivel AA como base. Las entidades explícitamente cubiertas incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos e instituciones financieras, hospitales y proveedores de atención sanitaria, empresas de telecomunicaciones con 200.000 o más abonados, agencias de viajes autorizadas, empresas de transporte privadas y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE).

WCAG 3.3.6 es un criterio de nivel AAA y, por tanto, no es un requisito legal directo en virtud de la Circular 2025/10. Sin embargo, no debe subestimarse su importancia en el contexto regulatorio turco. Varios de los tipos de entidades cubiertas —en particular bancos, plataformas de comercio electrónico y proveedores de atención sanitaria— operan formularios transaccionales de alto riesgo en los que la prevención de errores no es solo una buena práctica, sino una necesidad legal y ética. Un formulario de transferencia de dinero en línea de un banco turco, un sistema de reserva de citas de un portal sanitario o un flujo de pago de comercio electrónico que carezca de pasos de confirmación o mecanismos de corrección de errores puede no infringir 3.3.6 de forma jurídicamente exigible, pero crea un riesgo significativo de daño para las personas usuarias con discapacidad y expone a la organización a riesgos reputacionales y operativos.

Además, la circular señala una trayectoria clara hacia el aumento de los requisitos de accesibilidad con el tiempo, en consonancia con el marco del Acta Europea de Accesibilidad (EAA) con el que Turquía se ha ido alineando. Las organizaciones que implementan hoy criterios AAA como 3.3.6 están posicionadas de forma proactiva para futuros endurecimientos normativos y demuestran un compromiso con el diseño inclusivo que va más allá del cumplimiento mínimo. Para entidades como hospitales privados e instituciones financieras que atienden a poblaciones envejecidas o a personas con discapacidades cognitivas y motoras en tasas desproporcionadamente altas, implementar 3.3.6 en todos los formularios es una decisión sólida de gestión de riesgos, independientemente de su estatus legal. El SDK de superposición de Accsible puede ayudar a mostrar mensajes de error, reforzar estados de validación y proporcionar avisos de confirmación complementarios como una capa de protección mejorada para las organizaciones turcas que se esfuerzan por liderar en accesibilidad.