WCAG 2.2.3: Sin límite de tiempo

Qué Significa Esta Regla

WCAG 2.2.3 — Sin temporización se sitúa en el nivel de conformidad AAA bajo la Pauta 2.2: Tiempo suficiente. Su requisito es directo: el tiempo no debe ser una parte esencial de ningún evento o actividad presentada a la persona usuaria. En otras palabras, si tu contenido o funcionalidad implica un límite de tiempo, una fecha límite o una interacción sensible al tiempo de cualquier tipo, esa dependencia temporal debe poder eliminarse o ser completamente irrelevante para la tarea en cuestión, salvo que se aplique alguna de las excepciones limitadas.

Este criterio va más allá del criterio de Nivel A 2.2.1 (Tiempo ajustable) y del criterio de Nivel AA 2.2.2 (Pausar, detener, ocultar). Mientras que esos criterios anteriores permiten límites de tiempo ajustables o que se puedan pausar, 2.2.3 exige que el tiempo simplemente no exista como una restricción significativa en absoluto. Una persona usuaria que tarda diez segundos o diez minutos en rellenar un formulario, navegar por un menú o completar un flujo de trabajo debe llegar al mismo resultado que una persona usuaria que termina al instante.

Qué se considera un cumplimiento: Contenido en el que no existe ningún límite de tiempo, o en el que cualquier límite de tiempo presente es puramente cosmético y no tiene incidencia en el resultado (por ejemplo, una animación que se repite en bucle pero no impide la interacción). El contenido que es plenamente funcional independientemente del tiempo que la persona usuaria tarde cumple este criterio.

Qué se considera un incumplimiento: Caducidades de sesión que cierran la sesión de las personas usuarias tras inactividad; cuestionarios o evaluaciones cronometrados en los que la puntuación o la finalización dependen de terminar dentro de una ventana de tiempo; temporizadores de caducidad del carrito de compra que eliminan artículos; interfaces de pujas en subastas con relojes de cuenta atrás que cierran las pujas; campos de contraseñas de un solo uso (OTP) que caducan; desafíos CAPTCHA con límites de tiempo; y cualquier elemento interactivo que deje de estar disponible o se envíe automáticamente en función del tiempo transcurrido.

Excepciones oficiales definidas por WCAG: El criterio exime explícitamente dos categorías. En primer lugar, las excepciones en tiempo real: eventos en los que el tiempo es absolutamente inherente a la actividad, como una subasta en vivo, una retransmisión en directo o un juego multijugador en tiempo real. En segundo lugar, las excepciones esenciales: situaciones en las que eliminar el límite de tiempo alteraría de forma fundamental la actividad. Por ejemplo, una prueba de mecanografía de velocidad mide intrínsecamente la rapidez, por lo que el tiempo es esencial. Sin embargo, las personas desarrolladoras y responsables de producto deben ser rigurosas: la conveniencia, la herencia técnica o las preferencias empresariales no califican como “esenciales”. El listón está en si la actividad perdería su significado o propósito central sin la restricción temporal.

Es importante señalar que los medios sincronizados —como un vídeo pregrabado con subtítulos— también están excluidos, porque el tiempo en la reproducción de medios está controlado por el propio reproductor de la persona usuaria y no impone una restricción sobre la capacidad de interactuar con el resto de la página.

Por Qué Importa

Los límites de tiempo en la web perjudican de forma desproporcionada a personas usuarias con una amplia variedad de discapacidades. El impacto no es abstracto: para muchas personas, una interfaz cronometrada es, en la práctica, inaccesible.

Personas usuarias con discapacidades motoras, incluidas aquellas que utilizan dispositivos de acceso por pulsador, punteros bucales, software de seguimiento ocular u otros métodos de entrada alternativos, operan a un ritmo fundamentalmente distinto al de quienes usan ratón y teclado. Completar un formulario de varios pasos o navegar por un menú desplegable puede llevar varias veces más tiempo. Una caducidad de sesión o un carrito que caduque automáticamente puede borrar en un instante minutos de trabajo cuidadoso y esforzado.

Personas usuarias con discapacidades cognitivas, incluidas la dislexia, el TDAH, los trastornos del procesamiento y las lesiones cerebrales adquiridas, pueden necesitar significativamente más tiempo para leer instrucciones, comprender opciones o redactar respuestas. La investigación recopilada por la Iniciativa de Accesibilidad Web estima que las discapacidades cognitivas y de aprendizaje afectan de alguna forma a aproximadamente el 15–20% de la población mundial. Para estas personas, un temporizador de cuenta atrás no solo es estresante: perjudica activamente el procesamiento cognitivo necesario para completar la tarea.

Personas usuarias de lectores de pantalla que son ciegas o tienen baja visión navegan el contenido de forma lineal y deben escuchar o leer los elementos de la interfaz de manera secuencial. Comprender la estructura y las opciones en una página compleja lleva más tiempo que a una persona vidente que hojea visualmente. Un flujo de pago cronometrado que caduca mientras una persona ciega revisa cuidadosamente el resumen de su pedido es una barrera directa al comercio.

Personas usuarias con trastornos de ansiedad pueden encontrar que la mera presencia de un temporizador de cuenta atrás genera suficiente carga cognitiva y emocional como para impedir la finalización de la tarea, incluso si técnicamente disponen de tiempo suficiente. Eliminar el tiempo como factor elimina por completo esta barrera.

Un escenario concreto del mundo real: Considera un portal de banca en línea que utiliza una caducidad por inactividad de cinco minutos combinada con una OTP que caduca en sesenta segundos. Una persona usuaria con enfermedad de Parkinson que necesita tecnología de apoyo para escribir, o una persona mayor que no está familiarizada con cambiar rápidamente entre aplicaciones, puede encontrar físicamente imposible recibir el SMS, cambiar de aplicación, leer el código, volver a cambiar y escribirlo dentro del tiempo asignado. Queda bloqueada de su propia cuenta, no por una necesidad de seguridad, sino por una restricción temporal arbitraria. Diseñar la OTP para que siga siendo válida durante un periodo más largo (o eliminar la caducidad estricta en favor de un mecanismo de reenvío) resuelve el problema sin comprometer la seguridad.

Más allá de la accesibilidad, eliminar las restricciones de tiempo innecesarias mejora la usabilidad general y reduce las tasas de abandono. Un proceso de pago de comercio electrónico que no caduca a mitad del flujo retiene a más clientes, aumenta la conversión y reduce la carga de soporte, lo que convierte este cambio en algo positivo para el negocio además de una obligación ética.

Reglas Relacionadas de Axe-core

WCAG 2.2.3 requiere pruebas manuales. Ninguna regla automatizada de axe-core se asigna directamente a este criterio, y esta es una realidad arquitectónica importante que hay que entender.

• Se requieren pruebas manuales — Temporización de sesión e interacción: Las herramientas automatizadas no pueden detectar si una aplicación web impone un límite de tiempo porque la lógica de temporización se implementa en la gestión de sesiones del lado del servidor, en temporizadores de JavaScript o en respuestas de API de back-end, nada de lo cual es visible en un análisis estático del DOM. Una herramienta como axe-core inspecciona el HTML renderizado y el árbol accesible; no puede observar que una petición fetch devolverá un 401 tras cinco minutos de inactividad, o que un setTimeout de JavaScript redirigirá a la persona usuaria a una página de cierre de sesión. Solo una persona evaluadora que interactúe con la aplicación lentamente y observe lo que ocurre puede determinar si existen restricciones temporales y si afectan a la finalización de la tarea.
• Se requieren pruebas manuales — Caducidad de OTP y CAPTCHA: Las contraseñas de un solo uso y los desafíos de verificación limitados en el tiempo aparecen en el DOM como campos de entrada ordinarios. El temporizador de cuenta atrás, si es visible, puede ser un simple nodo de texto o un elemento animado con CSS. Axe no puede deducir que introducir un valor en este campo después de noventa segundos dará lugar a un estado de error. Una persona evaluadora debe esperar deliberadamente más allá de la ventana de caducidad e intentar enviar para confirmar si se aplica la temporización.
• Se requieren pruebas manuales — Formularios que se envían o avanzan automáticamente: Algunas interfaces avanzan automáticamente al siguiente paso o envían un formulario tras un periodo de inactividad o después de una duración determinada (por ejemplo, una encuesta que pasa a la siguiente pregunta después de treinta segundos). Axe-core no marcará esto porque la estructura del DOM parece válida; el comportamiento problemático solo se manifiesta durante la interacción real a lo largo del tiempo.
• Se requieren pruebas manuales — Caducidad en comercio y reservas: Los temporizadores de reserva del carrito de compra, las retenciones de reserva de entradas y los bloqueos de franjas de citas se implementan mediante lógica del servidor y se reflejan en la interfaz de usuario solo como una visualización de cuenta atrás. Las herramientas automatizadas ven un número que se actualiza en pantalla pero no pueden determinar si provoca pérdida de datos o denegación de acceso cuando llega a cero.

Cómo Probar

1. Exploración automatizada de referencia: Ejecuta axe DevTools o Lighthouse en la página para identificar cualquier infracción de temporización de nivel inferior relacionada (como las cubiertas por 2.2.1 o 2.2.2) que pueda orientarte hacia áreas que requieran una inspección manual más profunda. Aunque ninguna regla de axe prueba directamente 2.2.3, los hallazgos relacionados con advertencias de límites de tiempo o autoactualización pueden guiar el alcance de tu auditoría manual. En Lighthouse, revisa la sección “Accessibility” para ver cualquier alerta relacionada con el tiempo.
2. Inventariar todas las funciones dependientes del tiempo: Antes de probar, cataloga de forma sistemática todas las funciones de la aplicación que puedan implicar temporización. Esto incluye: gestión de sesiones y caducidades por inactividad; campos de OTP y códigos de verificación; retenciones de carritos de compra o reservas; cuestionarios, evaluaciones o encuestas cronometrados; interfaces de subastas o pujas; desafíos CAPTCHA; mecanismos de guardado automático con ventanas de envío; y cualquier temporizador visible de cuenta atrás o progreso.
3. Probar el comportamiento de caducidad de sesión: Abre la aplicación y comienza una tarea que abarque varios pasos (por ejemplo, rellenar un formulario de varias páginas o completar un proceso de pago). No interactúes durante un periodo que supere la ventana de caducidad sospechada. Luego intenta continuar. Observa si tu progreso se conserva, si recibes una advertencia y se te da la posibilidad de extender tu sesión, o si se cierra tu sesión o pierdes datos. Para cumplir se requiere que o bien no exista caducidad, o bien la caducidad sea puramente precautoria y los datos se conserven tras la nueva autenticación, o bien se proporcione a la persona usuaria una advertencia y control adecuados.
4. Probar la caducidad de OTP y códigos: Activa un flujo de OTP o código de verificación. Espera hasta después del tiempo de caducidad indicado del código (o más si no se muestra ningún tiempo). Intenta introducir el código. Si el sistema lo rechaza únicamente debido al tiempo, esto es un incumplimiento de 2.2.3. Nota: un mecanismo de “reenviar” por sí solo no corrige 2.2.3: la caducidad del código original sigue imponiendo temporización.
5. Pruebas con lector de pantalla (NVDA + Firefox): Usando NVDA con Firefox, navega por cualquier interfaz cronometrada utilizando solo el teclado y el lector de pantalla. Observa cuánto tiempo lleva cada paso con la sobrecarga de navegación de la tecnología de apoyo. Procede deliberadamente a un ritmo lento: haz pausas para escuchar todas las instrucciones, explora todas las opciones con el cursor virtual y luego intenta enviar o continuar. Verifica que la navegación lenta no desencadena una caducidad o pérdida de estado.
6. Pruebas con lector de pantalla (VoiceOver + Safari en macOS): Repite la misma prueba de navegación lenta usando VoiceOver en macOS con Safari. Presta especial atención a los temporizadores de cuenta atrás dinámicos: ¿anuncia VoiceOver el tiempo restante de una forma que crea urgencia, y la interfaz falla cuando se agota el tiempo?
7. Pruebas con lector de pantalla (JAWS + Chrome): Usando JAWS con Chrome, prueba los mismos flujos. Las personas usuarias de JAWS representan una parte significativa de las personas usuarias profesionales de lectores de pantalla; los problemas de temporización que afectan a quienes usan NVDA normalmente afectarán por igual a quienes usan JAWS.
8. Verificar la legitimidad de las excepciones: Para cualquier temporización que el equipo de desarrollo afirme que es “esencial” o “en tiempo real”, documenta la justificación y evalúa si el tiempo es realmente inherente al propósito de la actividad, o si podría relajarse, ampliarse o eliminarse sin cambiar la naturaleza fundamental de la tarea.

Cómo Corregir

Caducidad de sesión — Incorrecto

<!-- Session expires after 5 minutes of inactivity with no warning.
     User data is lost and they are redirected to login. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

Caducidad de sesión — Correcto

<!-- No automatic session expiry on inactivity.
     Server session is maintained as long as the browser tab is open.
     If a timeout is legally required (e.g. banking regulation),
     warn the user well in advance and offer to extend the session
     without time pressure on the extension dialog itself. -->
<div role='dialog' aria-modal='true' aria-labelledby='session-dialog-title' aria-describedby='session-dialog-desc' id='session-warning' hidden>
  <h2 id='session-dialog-title'>Your session is about to expire</h2>
  <p id='session-dialog-desc'>For your security, your session will expire due to inactivity. Would you like to stay signed in?</p>
  <button type='button' id='extend-session'>Stay signed in</button>
  <button type='button' id='end-session'>Sign out now</button>
</div>
<!-- The "Stay signed in" button itself has no expiry —
     the user can take as long as they need to find and activate it. -->

Campo de OTP que caduca — Incorrecto

<!-- OTP expires in 60 seconds. After expiry, form submission
     returns an error and the user must restart the entire flow. -->
<label for='otp'>Enter the code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p aria-live='assertive'>Code expires in: <span id='countdown'>60</span> seconds</p>
<button type='submit'>Verify</button>

Campo de OTP que caduca — Correcto

<!-- OTP does not expire within a short user-facing window.
     A longer server-side validity period (e.g. 15-30 minutes) is used.
     A resend option is available but the original code remains valid.
     No countdown timer is shown, removing false urgency. -->
<label for='otp'>Enter the 6-digit code sent to your phone</label>
<input type='text' id='otp' name='otp' autocomplete='one-time-code' inputmode='numeric' maxlength='6'>
<p>The code is valid for 30 minutes. <button type='button' id='resend-otp'>Send a new code</button></p>
<button type='submit'>Verify</button>
<!-- Server invalidates the code after first successful use,
     not after a short time window. -->

Cuestionario cronometrado — Incorrecto

<!-- Quiz auto-submits when the 10-minute timer reaches zero,
     regardless of whether the user has finished answering. -->
<div id='quiz-timer' aria-live='polite'>Time remaining: <span id='time-left'>10:00</span></div>
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>

Cuestionario cronometrado — Correcto

<!-- Quiz has no time limit unless timing is the explicit
     subject being assessed (e.g. a certified speed test).
     If an optional time indicator is shown for user reference,
     it does not trigger auto-submission or penalise slow completion. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- If a time reference is genuinely needed, it is informational only:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

Errores Comunes

• Suponer que la seguridad de la sesión requiere una caducidad estricta: Muchos equipos implementan caducidades cortas por inactividad alegando requisitos de seguridad, pero la mayoría de los estándares de seguridad (incluidos PCI-DSS y OWASP) permiten la extensión de sesión controlada por la persona usuaria. Un cierre de sesión estricto sin advertencia ni oportunidad de extensión es un fallo de accesibilidad, no una necesidad de seguridad.
• Mostrar un temporizador de cuenta atrás sin ofrecer una forma de detenerlo o ampliarlo: Añadir una región aria-live a una cuenta atrás lo empeora para las personas usuarias de lectores de pantalla —anuncia cada segundo— sin solucionar el problema de temporización subyacente. La solución es eliminar la restricción, no anunciarla de forma más accesible.
• Tratar “reenviar código” como solución a la caducidad de OTP: Proporcionar un botón de reenvío permite a las personas usuarias obtener un nuevo código pero no aborda el hecho de que el código original caducó debido a la temporización. El límite de tiempo sigue presente. La solución correcta es ampliar la ventana de validez para eliminar la presión temporal.
• Avanzar automáticamente pasos de carrusel o asistente tras inactividad: Los formularios de varios pasos o asistentes que avanzan automáticamente al siguiente paso después de un tiempo determinado imponen una restricción temporal. Las personas que están leyendo instrucciones o considerando su respuesta se ven penalizadas. Los pasos solo deben avanzar mediante una acción explícita de la persona usuaria.
• Temporizadores de carrito de compra que eliminan artículos sin conservarlos: Los temporizadores de reserva en comercio electrónico (“Tu carrito caduca en 15 minutos”) incumplen 2.2.3 cuando los artículos se pierden de forma permanente al caducar en lugar de simplemente liberarse de la reserva. Como mínimo, los artículos deberían guardarse en una lista de deseos o la sesión debería poder restaurarse.
• Aplicar la “excepción en tiempo real” de forma demasiado amplia: Etiquetar una interfaz como “en tiempo real” para justificar restricciones temporales cuando no es realmente en vivo. Una repetición de subasta pregrabada, una interfaz de pujas estática o un cuestionario que simplemente se asemeja a un concurso televisivo no califican para la excepción en tiempo real.
• Ignorar la temporización en las respuestas de API de back-end: Los equipos corrigen los temporizadores del front-end pero pasan por alto que la propia API rechaza las solicitudes realizadas después de una determinada ventana. La persona usuaria no ve ninguna cuenta atrás pero su envío falla silenciosamente. La gestión de sesiones en el back-end debe alinearse con la experiencia del front-end.
• Usar setTimeout para cierre de sesión automático sin conservar el estado del formulario: Cuando un cierre de sesión automático es inevitable (por ejemplo, debido a requisitos normativos), no guardar los datos del formulario de la persona usuaria antes de redirigir significa que se pierde todo el trabajo. Como mínimo, el estado del borrador debería guardarse y restaurarse tras la nueva autenticación.
• Confundir el cumplimiento de 2.2.1 con el de 2.2.3: Proporcionar un control para “desactivar, ajustar o ampliar” (como exige 2.2.1 Nivel A) no satisface 2.2.3. El Nivel AAA exige que el tiempo no sea esencial, no solo manejable. Un límite de tiempo con una ampliación generosa sigue siendo un límite de tiempo.
• Pasar por alto la temporización en componentes incrustados de terceros: Widgets de chat incrustados, procesadores de pago, SDK de verificación de identidad y servicios de mapas pueden introducir sus propias restricciones temporales. El origen de terceros no exime a estos componentes de la aplicabilidad de WCAG cuando se integran en tu interfaz.

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 de accesibilidad web que hace referencia a WCAG 2.2 como su base técnica. La Circular exige el cumplimiento a una amplia gama de entidades que operan servicios digitales en Turquía.

Los tipos de entidades cubiertas incluyen instituciones públicas y organismos gubernamentales, plataformas de comercio electrónico, bancos y servicios financieros, hospitales y proveedores de atención sanitaria, empresas de telecomunicaciones con 200,000 o más abonados, agencias de viajes, empresas de transporte privado y escuelas privadas autorizadas por el Ministerio de Educación Nacional (MoNE). Estas organizaciones deben cumplir las normas de accesibilidad definidas en la Circular o a las que esta hace referencia cuando prestan servicios digitales al público.

WCAG 2.2.3 — Sin temporización es un criterio de Nivel AAA, y la Circular Presidencial 2025/10, al igual que la norma europea EN 301 549 con la que se alinea, exige la conformidad de Nivel A y Nivel AA como mínimo legal. El cumplimiento de Nivel AAA no es una obligación legal directa en este marco. Sin embargo, alcanzar el Nivel AAA —y en concreto implementar 2.2.3— se reconoce como un indicador de un nivel de madurez de accesibilidad de primera clase y demuestra un compromiso genuino con el diseño inclusivo más allá de los umbrales legales mínimos.

Para ciertos tipos de entidades cubiertas, en particular bancos y servicios financieros que operan bajo la supervisión de BDDK, y plataformas de comercio electrónico con altos volúmenes de transacciones, las restricciones temporales como la caducidad de OTP, la gestión de sesiones y los temporizadores en los flujos de pago son características muy extendidas. Incluso cuando 2.2.3 no es un requisito legal, no abordar las barreras de temporización en estos flujos crea un riesgo real de discriminación, especialmente a medida que los mecanismos de aplicación de la accesibilidad en Turquía maduran y los procedimientos de reclamación se consolidan.

Las instituciones públicas y los proveedores de atención sanitaria que atienden a personas usuarias con discapacidad, personas mayores y personas con baja alfabetización digital tienen un argumento ético especialmente sólido para eliminar por completo las restricciones temporales. Eliminar los límites de tiempo de los servicios digitales gubernamentales y de los portales de salud se alinea con los objetivos más amplios de inclusión del gobierno electrónico de Turquía y reduce el riesgo de exposición regulatoria futura a medida que la adopción de AAA en la contratación pública se vuelve más común.

Las organizaciones que busquen posicionar sus productos digitales como plenamente inclusivos —ya sea para liderazgo nacional, acceso a mercados internacionales o ventajas en la contratación en contextos de la Unión Europea (donde se aplican EN 301 549 y la Ley Europea de Accesibilidad)— deberían tratar el cumplimiento de WCAG 2.2.3 como una inversión estratégica más que como una mejora opcional.