WCAG 2.2.4: Interrupciones

Qué significa esta regla

WCAG 2.2.4: Interrupciones es un criterio de éxito de Nivel AAA bajo la Pauta 2.2 (Tiempo suficiente). Establece: «Las interrupciones pueden ser pospuestas o suprimidas por el usuario, excepto las interrupciones que impliquen una emergencia.» En términos prácticos, esto significa que cualquier contenido, alerta, notificación, diálogo o actualización que aparezca sin haber sido iniciado directamente por el usuario debe ofrecer a ese usuario un mecanismo para aplazarlo o desactivarlo, a menos que la interrupción comunique una emergencia real, como una alarma de incendio, una alerta médica que ponga en peligro la vida o un fallo crítico del sistema.

Una interrupción, en el sentido de las WCAG, es cualquier evento que ocurre de forma independiente de la acción actual del usuario y desvía la atención de lo que el usuario está haciendo. Esto incluye, entre otros: notificaciones tipo “toast”, alertas push, widgets de chat que se abren automáticamente, banners de estado que se actualizan o cambian, contenido multimedia que se reproduce automáticamente, anuncios de regiones en vivo inyectados por JavaScript, diálogos modales activados por un temporizador y banners de consentimiento de cookies que aparecen a mitad de la sesión. El criterio no prohíbe estos patrones de forma absoluta; exige que se dé a los usuarios control sobre ellos.

Una página cumple con 2.2.4 cuando cada interrupción que no sea de emergencia tiene al menos uno de los siguientes elementos: una configuración accesible para el usuario que desactive la interrupción antes de que se produzca, un mecanismo dentro de la propia interrupción para descartarla o posponerla, o una preferencia global a nivel de sitio que suprima por completo dichas interrupciones. Una página no cumple cuando las interrupciones aparecen automáticamente, no ofrecen ningún mecanismo para descartarlas o posponerlas y no están relacionadas con una emergencia. Por ejemplo, una burbuja de chat en vivo que se expande automáticamente después de 10 segundos sin botón de cierre, o un banner de notificación que rota mensajes de marketing y no puede detenerse, serían ambos casos de incumplimiento.

La única excepción definida explícitamente son las emergencias. Si el contenido debe interrumpir al usuario para comunicar un peligro para la salud, la seguridad o la vida —por ejemplo, un portal hospitalario que envía una alerta crítica de medicación—, esa interrupción puede pasar por encima de las preferencias del usuario. Esta excepción es intencionalmente estrecha; los mensajes de marketing rutinarios, las advertencias de expiración de sesión con tiempo suficiente restante y las actualizaciones de estado de baja prioridad no califican como emergencias.

Dado que WCAG 2.2.4 es de Nivel AAA, no se exige para las declaraciones de conformidad de base, pero es un estándar significativo para las organizaciones comprometidas con la inclusión plena. Se aplica a todo el contenido web: aplicaciones web de escritorio y móviles, aplicaciones de una sola página que usan notificaciones impulsadas por JavaScript y aplicaciones web progresivas que aprovechan la API de Web Notifications.

Por qué es importante

Las interrupciones inesperadas en una página web no son simplemente molestas: para muchas personas usuarias representan una barrera grave para completar tareas y, en algunos casos, un riesgo directo para la salud.

Las personas usuarias con discapacidades cognitivas y relacionadas con la atención, incluidas TDAH, lesión cerebral traumática, condiciones del espectro autista y demencia, dependen en gran medida de un entorno estable y predecible para mantener la concentración. Una notificación repentina o una alerta animada puede romper por completo su concentración, haciendo que pierdan el hilo de un proceso de varios pasos, como completar una solicitud de prestaciones, revisar una historia clínica o rellenar un formulario de impuestos. Reorientarse después de una interrupción puede llevar significativamente más tiempo a estas personas que a las personas neurotípicas y, en algunos casos, puede que no consigan recuperar su lugar en absoluto.

Las personas usuarias de lectores de pantalla se ven particularmente afectadas por las interrupciones dinámicas. Cuando se inyecta una región en vivo o una alerta ARIA en el DOM, lectores de pantalla como NVDA, JAWS y VoiceOver están diseñados para anunciarla de inmediato, interrumpiendo lo que la tecnología de apoyo estaba leyendo en ese momento. Si una persona está escuchando un párrafo largo de instrucciones importantes y una notificación de marketing tipo toast se dispara a mitad de frase, el lector de pantalla abandona el párrafo y anuncia la notificación. La persona usuaria debe entonces volver atrás, encontrar su lugar y volver a leer, un proceso mucho más gravoso de lo que parece para alguien que navega solo con teclado y audio.

Las personas usuarias con trastornos de ansiedad y TEPT pueden experimentar respuestas físicas de estrés —aumento de la frecuencia cardíaca, pérdida de concentración o pánico— desencadenadas por cambios visuales o auditivos repentinos e inesperados. La imprevisibilidad de un entorno de interrupciones sin control puede hacer que algunos sitios web sean prácticamente inutilizables para estos grupos.

Las personas usuarias con epilepsia o trastornos vestibulares pueden verse perjudicadas por ciertos tipos de interrupciones, especialmente las que implican destellos o movimientos rápidos. Aunque la Pauta 2.3 aborda específicamente los riesgos de convulsiones, los banners de notificación animados y las notificaciones de vídeo que se reproducen automáticamente y aparecen de forma inesperada se cruzan con ambos criterios.

Considere un escenario concreto: una persona con TDAH está utilizando un portal de banca en línea para transferir dinero entre cuentas. Está revisando cuidadosamente el importe de la transferencia y el número de la cuenta de destino. Una notificación de oferta promocional se desliza desde la esquina inferior derecha, activando un anuncio del lector de pantalla y una animación de entrada. La persona pierde su lugar, no puede encontrar el botón de descartar porque la animación ha desviado la atención, y envía accidentalmente el importe equivocado. Esto no es un caso hipotético extremo: es un resultado previsible de ignorar este criterio.

Más allá de la discapacidad, las interrupciones sin control también perjudican la usabilidad para todas las personas usuarias, aumentan las tasas de rebote (las personas simplemente abandonan los sitios que las bombardean) y pueden reducir la conversión en las mismas acciones que las interrupciones pretendían promover. Desde la perspectiva del SEO, las altas tasas de rebote y las sesiones de corta duración se correlacionan con señales de posicionamiento de búsqueda más pobres, lo que significa que la accesibilidad y el rendimiento empresarial están alineados en este punto.

Reglas relacionadas de Axe-core

WCAG 2.2.4 requiere pruebas manuales. Las herramientas automatizadas, incluido axe-core, no pueden detectar de forma fiable si un sitio produce interrupciones incontrolables, porque hacerlo requeriría que la herramienta: observara todo el contenido dinámico inyectado durante una sesión de usuario, evaluara si cada inyección fue iniciada por el usuario, comprobara si existe un mecanismo para descartar o posponer y si es accesible, y determinara si el contenido califica como una emergencia. Estos son juicios contextuales y de comportamiento que quedan fuera del alcance del análisis estático del DOM.

• Pruebas manuales requeridas — Control de interrupciones: Las personas evaluadoras deben interactuar manualmente con la página durante un periodo de tiempo para observar si algún contenido, actualización, notificación, diálogo o medio comienza sin iniciación por parte del usuario. Para cada interrupción observada, la persona evaluadora debe verificar que existe un mecanismo accesible para posponerla o suprimirla, que este mecanismo en sí mismo es accesible por teclado y anunciado por el lector de pantalla, y que la interrupción no vuelve a producirse después de descartarla sin que la persona usuaria la vuelva a habilitar.
• Pruebas manuales requeridas — Evaluación de regiones en vivo: Las páginas que usan aria-live, role='alert' o role='status' deben revisarse manualmente para determinar si los anuncios se desencadenan por acciones del usuario (aceptable) o por eventos basados en tiempo o en envíos del servidor (potencialmente no conformes). Una herramienta automatizada puede señalar la presencia de regiones en vivo, pero no puede determinar si producen interrupciones inesperadas durante una sesión real de usuario.
• Pruebas manuales requeridas — Uso de la API de notificaciones: Las aplicaciones web que solicitan permiso para enviar notificaciones push a nivel de navegador deben ofrecer un mecanismo claro para que la persona usuaria gestione o suprima estas notificaciones desde la propia aplicación web, y no solo confiar en los controles a nivel de navegador. Esto requiere una inspección manual del flujo de permisos de notificación y de la disponibilidad de preferencias de notificación dentro de la aplicación.

Cómo hacer las pruebas

1. Ejecute un escaneo automatizado como línea base. Abra la página en Chrome o Firefox y ejecute axe DevTools o Lighthouse. Aunque ninguna de las herramientas tiene una regla específica para 2.2.4, el escaneo automatizado señalará problemas relacionados: roles faltantes en contenido dinámico, regiones en vivo mal configuradas y problemas de gestión del foco en diálogos. Tome nota de cualquier región aria-live o elemento role='alert' señalado, ya que requerirán seguimiento manual.
2. Observe la página de forma pasiva durante al menos dos o tres minutos. Sin hacer clic en nada, observe y escuche cualquier contenido que cambie, aparezca o se anuncie. Use un lector de pantalla ejecutándose en segundo plano (NVDA con Firefox o VoiceOver con Safari en macOS) y escuche cualquier anuncio que no haya sido desencadenado por su acción. Anote cada interrupción, su momento y su contenido.
3. Pruebe flujos interactivos que comúnmente desencadenan notificaciones. Inicie sesión en la aplicación si corresponde, navegue hasta un formulario o proceso de varios pasos y comience a rellenarlo lentamente. Anote cualquier interrupción que se produzca: advertencias de expiración de sesión, invitaciones a chat, banners promocionales, actualizaciones de progreso o avisos de suscripción. Para cada una, intente descartarla o posponerla usando solo el teclado (Tab, Escape, Enter, Space). Verifique que el foco regresa a una ubicación lógica después de descartarla.
4. Pruebe con NVDA y Firefox. Active NVDA, abra Firefox y navegue por la página. Escuche con atención cualquier salida de voz que interrumpa su lectura actual. Si se dispara una notificación automatizada, intente descartarla usando controles de teclado y verifique que NVDA anuncia la confirmación de descarte o que el foco regresa de forma adecuada.
5. Pruebe con JAWS y Chrome. Repita las pruebas de observación pasiva y de flujos interactivos usando JAWS con Chrome. JAWS y NVDA manejan las regiones en vivo de forma diferente, por lo que es importante probar con ambos para asegurarse de que las interrupciones se anuncian de manera coherente y que los mecanismos de descarte funcionan en ambos lectores de pantalla.
6. Pruebe con VoiceOver y Safari en iOS. En un dispositivo móvil o simulador, use VoiceOver con Safari para navegar por la página. Deslice el dedo por el contenido y observe si se producen interrupciones. Pruebe el mecanismo de descarte usando gestos táctiles (doble toque para activar) y verifique que el foco regresa a una ubicación significativa.
7. Compruebe si existe una configuración de preferencias de notificación. Busque un perfil de usuario, panel de configuración o sección de preferencias de accesibilidad dentro de la aplicación. Verifique que existe un control para suprimir o configurar las notificaciones de forma global y pruebe que al habilitar esta configuración realmente se evita que se produzcan interrupciones durante una sesión posterior.
8. Revise el código fuente JavaScript o la actividad de red. En las DevTools del navegador, observe las pestañas Network y Console durante la sesión. Busque conexiones WebSocket, intervalos de sondeo o llamadas setTimeout/setInterval que inyecten contenido en el DOM. Cada una de estas es una fuente potencial de interrupciones y debe rastrearse para garantizar que se ha implementado el control por parte del usuario.

Cómo corregir

Widget de chat que se abre automáticamente — Incorrecto

<!-- Chat widget opens automatically after 10 seconds with no close button -->
<div id='chat-widget' role='dialog' aria-label='Live chat'>
  <p>Hi! Can we help you today?</p>
  <button>Start chat</button>
</div>

<script>
  setTimeout(function() {
    document.getElementById('chat-widget').style.display = 'block';
  }, 10000);
</script>

Widget de chat que se abre automáticamente — Correcto

<!-- Chat widget includes a dismiss button and respects a user preference -->
<div id='chat-widget' role='dialog' aria-label='Live chat' aria-modal='true'>
  <p>Hi! Can we help you today?</p>
  <button id='chat-start'>Start chat</button>
  <!-- Dismiss button allows user to postpone the interruption -->
  <button id='chat-dismiss' aria-label='Dismiss chat offer'>No thanks</button>
</div>

<script>
  // Check whether the user has previously dismissed the chat offer
  if (!sessionStorage.getItem('chat-dismissed')) {
    setTimeout(function() {
      var widget = document.getElementById('chat-widget');
      widget.removeAttribute('hidden');
      // Move focus into the dialog so screen reader users are aware of it
      document.getElementById('chat-dismiss').focus();
    }, 10000);
  }

  document.getElementById('chat-dismiss').addEventListener('click', function() {
    // Suppress for the remainder of the session
    sessionStorage.setItem('chat-dismissed', 'true');
    var widget = document.getElementById('chat-widget');
    widget.setAttribute('hidden', '');
    // Return focus to the element the user was on before the interruption
    document.getElementById('main-content').focus();
  });
</script>

Notificación de marketing tipo toast incontrolable — Incorrecto

<!-- Toast fires every 30 seconds, no way to stop it -->
<div role='alert' id='promo-toast'>
  <p>Use code SAVE20 for 20% off your next order!</p>
</div>

<script>
  setInterval(function() {
    document.getElementById('promo-toast').style.display = 'block';
    setTimeout(function() {
      document.getElementById('promo-toast').style.display = 'none';
    }, 5000);
  }, 30000);
</script>

Notificación de marketing tipo toast incontrolable — Correcto

<!-- Toast fires once, includes a dismiss control, and respects a preference -->
<div role='status' id='promo-toast' hidden>
  <p>Use code SAVE20 for 20% off your next order!</p>
  <!-- Dismiss button suppresses future promos in this session -->
  <button id='promo-dismiss' aria-label='Dismiss promotion'>&times;</button>
</div>

<script>
  // Only show once, and only if the user has not opted out
  if (!localStorage.getItem('promos-suppressed')) {
    setTimeout(function() {
      document.getElementById('promo-toast').removeAttribute('hidden');
    }, 30000);
  }

  document.getElementById('promo-dismiss').addEventListener('click', function() {
    // Suppress all future promotional interruptions permanently
    localStorage.setItem('promos-suppressed', 'true');
    document.getElementById('promo-toast').setAttribute('hidden', '');
  });
</script>

Modal de expiración de sesión sin control por parte del usuario — Incorrecto

<!-- Modal fires automatically, traps focus with no postpone option -->
<div id='timeout-modal' role='dialog' aria-label='Session expiring'>
  <p>Your session will expire in 60 seconds.</p>
  <button id='logout-now'>Log out</button>
</div>

Modal de expiración de sesión sin control por parte del usuario — Correcto

<!-- Modal provides both a continue option and a postpone option,
     and announces itself clearly to screen readers -->
<div id='timeout-modal' role='alertdialog'
     aria-labelledby='timeout-heading'
     aria-describedby='timeout-description'
     aria-modal='true'>
  <h2 id='timeout-heading'>Session Expiring Soon</h2>
  <p id='timeout-description'>
    Your session will expire in <span id='countdown'>5 minutes</span>.
    Would you like to continue, or shall we log you out now?
  </p>
  <button id='continue-session'>Continue session</button>
  <button id='logout-now'>Log out now</button>
  <!-- Postpone option gives the user meaningful control -->
  <button id='remind-later'>Remind me in 5 more minutes</button>
</div>

Errores comunes

• Usar role='alert' en mensajes promocionales o de baja prioridad. El rol alert indica urgencia a los lectores de pantalla y provoca una interrupción inmediata de la lectura. Los mensajes de marketing, consejos y anuncios de funcionalidades deberían usar role='status' o aria-live='polite' en su lugar, lo que anuncia el contenido solo después de que el lector de pantalla termine su salida actual.
• Proporcionar un botón de cierre que solo es visible al pasar el ratón o al enfocar, haciéndolo prácticamente inaccesible. Si el mecanismo de descarte requiere que la persona usuaria pase el ratón para revelarlo, las personas que solo usan teclado y las personas usuarias de lectores de pantalla no pueden verlo ni alcanzarlo. El botón de descarte debe ser siempre visible o, como mínimo, siempre alcanzable mediante el orden de tabulación del teclado.
• Devolver el foco a document.body después de descartar una notificación. Cuando se descarta una notificación o un diálogo, el foco debe regresar a un elemento significativo y apropiado en el contexto, normalmente el elemento con el que la persona usuaria estaba interactuando antes de que apareciera la interrupción. Dejar el foco en body obliga a las personas usuarias de lectores de pantalla a volver a navegar por toda la página.
• Disparar varias regiones aria-live simultáneamente. Cuando varias regiones en vivo se actualizan al mismo tiempo, los lectores de pantalla ponen en cola o descartan anuncios de forma impredecible. Cada interrupción debe gestionarse cuidadosamente para que solo una región en vivo se dispare a la vez y las actualizaciones se agrupen cuando sea posible.
• Considerar suficiente el cuadro de diálogo nativo del navegador para permisos de notificación. El cuadro de diálogo de permisos del navegador para la API de Web Notifications funciona a nivel del sistema operativo, no a nivel de la aplicación. WCAG 2.2.4 exige que las personas usuarias puedan gestionar las notificaciones desde la propia aplicación web, no solo bloqueando el sitio a nivel de navegador.
• Restablecer una notificación descartada en cada carga de página. Si una persona usuaria descarta una notificación y esta vuelve a aparecer la próxima vez que navega a la misma página u otra página del sitio, la acción de descarte fue inútil. Las preferencias deberían persistir al menos durante la sesión usando sessionStorage, o de forma permanente usando localStorage o una preferencia del lado del servidor.
• Usar setInterval para rotar banners o consejos sin un control de pausa. El contenido rotativo que se actualiza con un temporizador es una interrupción. Si el contenido cambia mientras una persona usuaria de lector de pantalla lo está leyendo, el anuncio se reiniciará. Estos carruseles y banners rotativos requieren un control de reproducción/pausa y no deben repetirse indefinidamente sin el consentimiento del usuario.
• Inyectar una notificación en el DOM en una posición que provoque saltos de desplazamiento inesperados. Si se inyecta un banner de notificación en la parte superior de la página y esta se desplaza hacia abajo, las personas usuarias pierden su posición de lectura visual. Las notificaciones deben inyectarse de manera que no afecten al diseño del contenido que la persona usuaria está viendo en ese momento, normalmente usando posicionamiento fijo o absoluto.
• Suponer que un temporizador de auto-descarte corto satisface el criterio. Un toast que desaparece después de cinco segundos no ofrece a las personas usuarias un control significativo: muchas no pueden leer, procesar o responder al contenido tan rápido, especialmente aquellas con discapacidades cognitivas o que usan lectores de pantalla. Proporcionar solo un temporizador de auto-descarte sin un botón de descarte controlado por el usuario no cumple el criterio.
• No probar el comportamiento de las interrupciones cuando el sistema operativo o el navegador del usuario tiene activadas preferencias de reducción de movimiento o de notificaciones. Algunas personas configuran preferencias a nivel de sistema operativo para reducir el movimiento o suprimir notificaciones. La aplicación debería respetar estas señales, y las personas desarrolladoras deberían probar con la media query prefers-reduced-motion: reduce activa para asegurarse de que las interrupciones animadas se suprimen adecuadamente.

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 vinculante de accesibilidad web para una amplia gama de organizaciones que operan en Turquía. La circular adopta WCAG 2.2 como su estándar técnico de referencia y exige la conformidad para las entidades cubiertas. Los tipos de entidades explícitamente cubiertos por la circular incluyen instituciones y organismos públicos, plataformas de comercio electrónico, bancos y proveedores de servicios financieros, hospitales y organizaciones de servicios de salud, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes autorizadas, empresas de transporte privado y escuelas privadas que operan bajo autorización del Ministerio de Educación Nacional (MoNE).

WCAG 2.2.4: Interrupciones es un criterio de Nivel AAA, lo que significa que no se encuentra entre los requisitos de conformidad de base bajo la Circular Presidencial 2025/10 para la mayoría de las entidades cubiertas. Las organizaciones que logran y declaran conformidad de Nivel A y Nivel AA se consideran legalmente conformes con los requisitos mínimos de la circular. Sin embargo, los criterios de Nivel AAA como 2.2.4 tienen un peso práctico y reputacional significativo en el contexto del mercado turco.

Varios de los tipos de entidades cubiertas —en particular hospitales, bancos e instituciones públicas— atienden a poblaciones de usuarios con tasas elevadas de condiciones cognitivas y neurológicas, trastornos de ansiedad y dificultades de atención relacionadas con la edad avanzada. Para estas organizaciones, las interrupciones sin control en las interfaces digitales representan no solo un fallo de accesibilidad, sino un posible riesgo de seguridad del paciente o de daño financiero. Un portal de pacientes de un hospital que lanza recordatorios de medicación o notificaciones de citas incontrolables durante un flujo crítico de cumplimentación de formularios, o una aplicación bancaria que muestra banners promocionales que no se pueden suprimir durante la revisión de una transacción, crea daños reales para las personas usuarias de estos grupos.

Para las organizaciones en Turquía que buscan demostrar liderazgo en accesibilidad digital —en particular aquellas que persiguen declaraciones voluntarias de WCAG 2.2 de Nivel AAA, responden a requisitos de accesibilidad en la contratación pública o se dirigen a mercados europeos donde la European Accessibility Act (EAA) establece un estándar más alto—, implementar 2.2.4 es un factor diferenciador significativo. El SDK de superposición Accsible ayuda a las organizaciones a cumplir estos estándares más altos proporcionando funciones configurables de gestión de notificaciones, persistencia de preferencias de usuario y comportamientos de widgets conscientes de la accesibilidad que se alinean tanto con las expectativas regulatorias turcas como con las mejores prácticas internacionales.