WCAG 3.3.4: Prevención de errores (legal, financiera, datos)

Qué significa esta regla

El Criterio de Conformidad 3.3.4 de las WCAG, titulado Prevención de errores (Legales, financieros, de datos), es un requisito de Nivel AA bajo el Principio 3 (Comprensible) y la Pauta 3.3 (Asistencia de entrada). Se aplica específicamente a las páginas web donde las personas usuarias pueden generar compromisos legales o transacciones financieras, o donde la persona usuaria modifica o elimina datos controlables por el usuario en un sistema de almacenamiento de datos.

El criterio exige que se proporcione al menos una de las siguientes tres salvaguardas para cualquier envío de este tipo:

• Reversible: El envío puede deshacerse después de haberse realizado. Por ejemplo, un pedido puede cancelarse dentro de una ventana de tiempo definida, o un registro eliminado puede restaurarse.
• Comprobado: Los datos introducidos por la persona usuaria se comprueban en busca de errores de entrada, y se le da la oportunidad de corregir esos errores antes de que el envío se finalice.
• Confirmado: Se proporciona un mecanismo para revisar, confirmar y corregir la información antes del envío final. Esto suele adoptar la forma de un paso de resumen o revisión antes de que un botón de envío complete la transacción.

Es importante señalar que solo es necesario satisfacer una de estas tres condiciones para aprobar. Proporcionar únicamente un paso de revisión y confirmación es suficiente, al igual que ofrecer una ventana de cancelación posterior al envío, o una validación robusta en tiempo real con oportunidad de corrección. Sin embargo, la mejor práctica es combinar múltiples salvaguardas.

Alcance del criterio: La regla se aplica a tres categorías de transacción. En primer lugar, abarca compromisos legales como suscribirse a una suscripción, aceptar un contrato o enviar un formulario legal vinculante. En segundo lugar, abarca transacciones financieras, incluidas compras, transferencias de fondos, solicitudes de préstamos y pagos de facturas. En tercer lugar, abarca cualquier acción que modifique o elimine datos controlados por la persona usuaria en un sistema de almacenamiento de datos — por ejemplo, actualizar información de perfil, eliminar archivos de un servicio en la nube o editar registros en un panel administrativo.

Un cumplimiento se ve así: un proceso de compra en un comercio electrónico que presenta un resumen del pedido con un enlace "Editar" y un botón "Realizar pedido" como paso final. Un incumplimiento se ve así: un formulario de compra de una sola página donde al hacer clic en "Comprar ahora" se carga inmediatamente la tarjeta sin pantalla de revisión, sin opción de cancelación y sin paso de validación.

El criterio tiene una excepción definida: no se aplica a formularios en los que enviar información incorrecta no tiene consecuencias y el envío puede repetirse de forma trivial. Los formularios de contacto simples o las suscripciones a boletines informativos generalmente quedan fuera del alcance, aunque las buenas prácticas siguen recomendando la validación en esos formularios.

Por qué es importante

Los errores durante transacciones de alto riesgo pueden tener consecuencias graves, a veces irreversibles: dinero transferido a la cuenta equivocada, un acuerdo legal firmado bajo falsos supuestos, historiales médicos actualizados con información incorrecta o una suscripción comprada en el nivel equivocado. Para las personas sin discapacidad, detectar y corregir estos errores suele ser sencillo. Para muchos grupos de personas con discapacidad, puede ser extremadamente difícil o incluso imposible sin las salvaguardas que exige este criterio.

Las personas con discapacidades cognitivas, incluidas aquellas con dislexia, TDAH, deterioro de la memoria o discapacidades intelectuales, tienen más probabilidades de cometer errores de introducción de datos y menos probabilidades de detectarlos antes de hacer clic en enviar. Una pantalla de revisión les da el tiempo y la claridad que necesitan para detectar errores. 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, neurológica o de salud mental que afecta el funcionamiento diario.

Las personas con discapacidades motoras que dependen de acceso por pulsadores, dispositivos de seguimiento ocular o teclados alternativos son propensas a activaciones accidentales y pulsaciones involuntarias. Un paso de confirmación actúa como un amortiguador crítico: incluso si "Enviar" se activa por error, la persona usuaria tiene otra oportunidad de cancelar antes de que la transacción se complete. Sin esta salvaguarda, un solo toque accidental podría desencadenar una transacción financiera que la persona usuaria no puede revertir.

Las personas usuarias de lectores de pantalla que navegan formularios largos de forma lineal pueden no tener una visión global de lo que han introducido. Un resumen hablado en la etapa de confirmación — leyendo los valores introducidos — les permite detectar errores que no podrían escanear visualmente.

Las personas con ansiedad o dificultades de atención se benefician enormemente de saber que existe una red de seguridad. La investigación muestra de forma consistente que cuando las personas perciben un proceso como tolerante a errores, interactúan con más confianza y abandonan las transacciones con menor frecuencia. Esto beneficia directamente las tasas de conversión y la satisfacción de las personas usuarias, haciendo que el cumplimiento del 3.3.4 sea una ventaja empresarial además de una obligación ética.

Escenario del mundo real: Una usuaria con discapacidad visual en Estambul está reservando un vuelo nacional usando un lector de pantalla. Selecciona una fecha pero navega accidentalmente más allá del campo de número de pasajeros, dejándolo en su valor predeterminado de dos pasajeros en lugar de uno. Si el sitio de reservas carga su tarjeta en el momento en que activa "Confirmar", habrá comprado dos billetes y puede enfrentarse a penalizaciones por tarifas no reembolsables. Una pantalla de revisión que lea en voz alta "1 pasajero: Ayşe Yılmaz, Ankara a Estambul, 14 de marzo, Turista — Total: ₺850" le permitiría detectar el error de inmediato.

Reglas relacionadas de Axe-core

WCAG 3.3.4 requiere pruebas manuales. Ninguna regla automatizada de axe-core se asigna directamente a este criterio porque las salvaguardas que exige — reversibilidad, validación con oportunidad de corrección y pasos de confirmación — son cuestiones de flujo de aplicación y lógica de negocio, no de estructura de marcado o atributos del DOM. Las herramientas automatizadas pueden analizar HTML y ARIA, pero no pueden determinar si un botón "Pagar ahora" desencadena un cargo irreversible, si existe una política de cancelación o si los datos mostrados en una pantalla de revisión reflejan con precisión lo que se introdujo.

• Por qué la automatización no puede detectar esto: Un escáner automatizado ve un elemento <button> con el texto "Submit" y un marcado válido. No tiene forma de saber si al activar ese botón se inicia una transacción financiera vinculante, si aparecerá un cuadro de diálogo de confirmación o si la transacción puede deshacerse después. Estas son decisiones de arquitectura y UX que existen por encima del nivel de nodos individuales del DOM y requieren una persona evaluadora que entienda todo el recorrido de la persona usuaria.
• Señales parciales a buscar durante los análisis automatizados: Aunque axe-core no marca directamente infracciones del 3.3.4, las personas auditoras a veces usan axe para identificar problemas relacionados que agravan el riesgo, como la ausencia de atributos autocomplete en campos de pago (relevante para 1.3.5), mensajes de error ausentes (relevante para 3.3.1 y 3.3.3) o etiquetas faltantes en controles de formulario (relevante para 1.3.1 y 4.1.2). Estos fallos relacionados hacen que la prevención de errores sea aún más difícil de lograr.
• Enfoque de auditoría manual recomendado: Las personas evaluadoras deben mapear cada recorrido de usuario que implique un envío legal, financiero o de modificación de datos y luego evaluar cada recorrido frente a los tres criterios: ¿Hay alguna forma de deshacerlo? ¿Hay validación en línea con oportunidad de corrección? ¿Hay un paso de revisión y confirmación? El incumplimiento de los tres en cualquier recorrido de este tipo constituye un fallo del 3.3.4.

Cómo probar

1. Inventariar los formularios de alto riesgo: Antes de comenzar las pruebas, cree una lista de todos los formularios o flujos interactivos del sitio que impliquen transacciones financieras (compra, pago, facturación), compromisos legales (firma de contratos, alta de suscripciones, formularios de consentimiento) o modificación/eliminación de datos (edición de perfil, eliminación de archivos, eliminación de cuentas). Estos son los únicos flujos dentro del alcance del 3.3.4.
2. Ejecutar un análisis automatizado para detectar problemas relacionados: Use axe DevTools o Lighthouse para identificar fallos de accesibilidad a nivel de formulario en cada página dentro del alcance. Aunque estas herramientas no marcarán directamente el 3.3.4, resolver problemas como etiquetas faltantes, atributos de autocompletado ausentes y ausencia de anuncios de error establece una base de calidad del formulario antes de evaluar la salvaguarda de prevención de errores.
3. Probar la salvaguarda "Comprobado": Envíe deliberadamente cada formulario dentro del alcance con errores intencionales — dígitos transpuestos en un número de tarjeta, una fecha no válida, un campo de confirmación de correo electrónico que no coincide. Observe si el sistema detiene el envío, identifica el error específico, describe cómo solucionarlo (según 3.3.3) y mantiene a la persona usuaria en el formulario para hacer correcciones. Si el formulario se envía silenciosamente o solo muestra un error genérico sin identificar qué campo falló, esta salvaguarda no se cumple.
4. Probar la salvaguarda "Confirmado": Complete cada formulario dentro del alcance con datos válidos y recorra el flujo completo. Identifique si se presenta un paso de revisión antes del envío final. Verifique que el paso de revisión muestre todos los datos introducidos en un formato legible, incluya un mecanismo para volver atrás y editar, y requiera una acción final deliberada para completar el envío. Usando NVDA con Firefox y JAWS con Chrome, navegue este paso de revisión con un lector de pantalla para confirmar que se anuncian todos los valores y que los controles de edición y confirmación son alcanzables mediante teclado.
5. Probar la salvaguarda "Reversible": Complete un envío y luego intente deshacerlo. Para comercio electrónico, busque un enlace de cancelación en el correo electrónico de confirmación o en la página de historial de pedidos. Para eliminación de datos, busque un mecanismo de restauración o papelera de reciclaje. Evalúe si la ventana de reversión se comunica claramente a la persona usuaria antes de que envíe, no solo después.
6. Recorrido con lector de pantalla (VoiceOver + Safari en macOS/iOS): Navegue todo el flujo de compra o envío usando solo el teclado y VoiceOver. Confirme que la pantalla de revisión lee todos los valores introducidos en un orden lógico, que los enlaces de edición se anuncian con contexto suficiente (por ejemplo, "Editar dirección de envío" y no solo "Editar") y que el propósito del botón de confirmación final es inequívoco.
7. Comprobación de carga cognitiva: Evalúe si el paso de revisión se presenta en lenguaje sencillo. Un resumen que enumera nombres de campos de base de datos sin procesar o utiliza jerga legal sin explicación puede calificar técnicamente como pantalla de revisión, pero fallar en la práctica para las personas con discapacidades cognitivas.

Cómo corregir

Proceso de compra de un solo paso sin revisión — Incorrecto

<!-- Problemático: hacer clic en "Complete Purchase" carga inmediatamente la tarjeta -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

Proceso de compra de un solo paso con paso de revisión añadido — Correcto

<!-- Paso 1: el formulario recopila datos y se envía a la página de revisión (no final) -->
<form action='/checkout/review' method='post'>
  <!-- campos de pago y envío -->
  <button type='submit'>Review Order</button>
</form>

<!-- Paso 2: la página de revisión resume todos los datos introducidos y ofrece enlaces de edición -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- El botón final está claramente etiquetado como la acción vinculante -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

Eliminación irreversible de datos sin confirmación — Incorrecto

<!-- Problemático: el botón de eliminación envía directamente sin cuadro de diálogo de confirmación -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

Eliminación irreversible de datos con cuadro de diálogo de confirmación — Correcto

<!-- El botón disparador abre un cuadro de diálogo de confirmación, no la acción destructiva -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

Formulario financiero sin validación en línea — Incorrecto

<!-- Problemático: sin validación, IBAN incorrecto aceptado silenciosamente -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

Formulario financiero con validación y revisión — Correcto

<!-- Validación en línea con aria-describedby para asociar el error -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Se envía a la página de revisión, no a la ejecución directa -->
  <button type='submit'>Review Transfer</button>
</form>

Errores comunes

• Usar un tooltip como mecanismo de "revisión": Mostrar los valores introducidos en un tooltip al pasar el cursor antes del botón de envío no constituye un paso de revisión, porque los tooltips no son accesibles para personas que solo usan teclado o lector de pantalla y desaparecen antes de que la persona usuaria pueda actuar sobre ellos.
• Etiquetar el botón final como "Continuar" en lugar de describir la acción: Un botón que dice "Continuar" en una página de revisión no deja claro que al hacer clic se completará una transacción financiera. El botón debe describir de forma inequívoca la acción vinculante, como "Realizar pedido y pagar ₺850" o "Firmar contrato".
• Proporcionar una política de cancelación solo en los términos de servicio: Enterrar el mecanismo de reversión en un documento legal enlazado que la mayoría de las personas no leerá no satisface el requisito de reversibilidad. La posibilidad de cancelar y la ventana de tiempo en la que está disponible deben comunicarse en el propio flujo de la transacción.
• Usar window.confirm() como único mecanismo de confirmación: Los cuadros de diálogo de confirmación nativos del navegador tienen un soporte deficiente en algunas tecnologías de asistencia, no pueden estilizarse para mejorar la legibilidad y se bloquean en ciertas configuraciones del navegador. No deben usarse como la única salvaguarda para envíos de alto riesgo.
• Restablecer el formulario al fallar la validación sin conservar los valores de los campos válidos: Cuando un formulario falla la validación, borrar todos los campos obliga a las personas — especialmente a quienes tienen discapacidades motoras — a volver a introducir todos los datos. Solo el campo no válido debe borrarse o resaltarse; todas las entradas válidas deben conservarse.
• Colocar el enlace "Editar" en la página de revisión sin asociación programática: Un enlace "Editar" junto a cada grupo de datos debe tener un nombre accesible descriptivo (por ejemplo, aria-label='Edit billing address'). Un simple "Edit" repetido varias veces es ambiguo para las personas usuarias de lectores de pantalla que navegan por enlaces.
• No anunciar el paso de revisión a los lectores de pantalla: Si la página de revisión se carga sin mover el foco al encabezado o a una región de resumen, las personas usuarias de lectores de pantalla pueden no darse cuenta de que están en una página de revisión y pueden activar el botón de envío sin leer el resumen.
• Tratar el criterio como si solo se aplicara a páginas de pago: El alcance incluye cualquier compromiso legal (alta de suscripción, formularios de consentimiento, aceptación de contratos) y cualquier modificación de datos de usuario (eliminación de archivos, actualización de historiales médicos, cambio de configuraciones de cuenta). Las personas desarrolladoras a menudo pasan por alto los paneles administrativos y las páginas de configuración.
• Ofrecer reversión solo por teléfono o correo electrónico: Si la cancelación requiere llamar a una línea de soporte, las personas con discapacidades del habla o de la audición pueden no poder acceder al mecanismo de reversión. La vía de reversión debe ser en sí misma accesible — preferiblemente un flujo de cancelación dentro de la propia aplicación.
• Omitir el criterio en vistas web móviles: Algunos equipos implementan un paso de revisión en escritorio pero usan un flujo condensado de un solo paso en móvil para reducir el espacio en pantalla. El criterio se aplica por igual a todos los tamaños de ventana gráfica y no debe omitirse en implementaciones web adaptables o móviles.

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 un marco nacional integral de accesibilidad que hace referencia a las WCAG 2.2 como su estándar técnico. La Circular exige que los servicios digitales cumplan al menos con la conformidad de Nivel AA de las WCAG 2.2, que incluye el Criterio 3.3.4 Prevención de errores (Legales, financieros, de datos).

Las entidades cubiertas explícitamente por la Circular abarcan una amplia gama de sectores. Las instituciones y organismos públicos están obligados a hacer accesibles todos los servicios digitales dirigidos a la ciudadanía, incluidos las solicitudes en línea, los portales de gobierno electrónico y los servicios de identidad digital, todos los cuales implican con frecuencia compromisos legales y modificación de datos. Los bancos e instituciones financieras regulados por la BDDK (Agencia de Regulación y Supervisión Bancaria) deben cumplir, lo que hace que el 3.3.4 sea directamente relevante para cada transacción de banca en línea, transferencia de fondos y solicitud de préstamo que ofrezcan. Los hospitales e instituciones de salud que operan portales digitales para pacientes, sistemas de reserva de citas e historiales clínicos electrónicos deben garantizar que cualquier introducción o modificación de datos en esos sistemas cumpla las normas de prevención de errores. Los proveedores de telecomunicaciones con 200,000 o más abonados, incluidos Turkcell, Vodafone TR y Türk Telekom, deben garantizar que la gestión de suscripciones, los cambios de plan y los flujos de pago estén cubiertos. Las plataformas de comercio electrónico, las agencias de viajes, las empresas de transporte privado y las escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE) también están dentro del alcance, cubriendo una parte sustancial de los servicios web transaccionales de alto volumen en el mercado turco.

El cumplimiento del 3.3.4 no es simplemente una casilla técnica que marcar dentro de este marco. Las organizaciones que busquen el Erişilebilirlik Logosu (Logotipo de Accesibilidad) emitido por el Ministerio de Familia y Servicios Sociales deben demostrar plena conformidad con WCAG 2.2 AA. El logotipo actúa como una señal de confianza pública y es cada vez más esperado por las personas consumidoras y los organismos de contratación. No implementar salvaguardas de prevención de errores en flujos financieros o legales puede dar lugar tanto a la denegación del logotipo como a posibles acciones administrativas en virtud de las disposiciones de aplicación de la Circular.

Para las organizaciones turcas de los sectores de comercio electrónico y fintech específicamente, el 3.3.4 se alinea estrechamente con los requisitos existentes de protección de las personas consumidoras en virtud de la legislación turca. La Ley de Protección del Consumidor (n.º 6502) y la normativa de comercio electrónico asociada ya exigen información precontractual clara y derechos de cancelación para los contratos a distancia. Implementar un paso de revisión y confirmación conforme al 3.3.4 de las WCAG satisface simultáneamente tanto el requisito de accesibilidad como la obligación de derecho del consumidor de presentar resúmenes de pedido antes de vincular a la persona compradora. Esta doble conformidad convierte la inversión en una experiencia de usuario de prevención de errores adecuada en un esfuerzo de alto valor y baja duplicación para los proveedores de servicios digitales turcos.