WCAG 2.2.3: 시간 제한 없음

WCAG 2.2.3 (레벨 AAA)는 비대화형 동기화 미디어와 실시간 이벤트를 제외하고, 콘텐츠가 제시하는 이벤트나 활동에서 시간이 필수적인 요소가 아니어야 한다고 요구합니다. 이는 더 많은 시간이 필요해 읽거나 상호작용하거나 반응하는 장애가 있는 사용자가 시간에 의존하는 디자인 때문에 결코 배제되지 않도록 보장합니다.

이 규칙의 의미

WCAG 2.2.3 — No Timing(시간 제한 없음)은 지침 2.2: 충분한 시간(Enough Time) 아래의 AAA 적합 수준에 속합니다. 이 기준의 요구 사항은 매우 직접적입니다. 사용자에게 제공되는 어떤 이벤트나 활동에서도 시간이 본질적인 요소가 되어서는 안 됩니다. 다시 말해, 콘텐츠나 기능에 시간 제한, 마감, 어떤 형태로든 시간에 민감한 상호작용이 포함되어 있다면, 그 시간 의존성은 제거 가능해야 하거나, 해당 과업을 수행하는 데 완전히 무관해야 합니다. 단, 몇 가지 좁은 예외에 해당하는 경우는 제외됩니다.

이 기준은 레벨 A 기준 2.2.1(시간 조정 가능)과 레벨 AA 기준 2.2.2(일시 정지, 중지, 숨기기)보다 더 나아갑니다. 앞선 기준들은 시간 제한을 조정하거나 일시 정지할 수 있도록 허용하지만, 2.2.3은 애초에 시간 자체가 의미 있는 제약으로 존재하지 않도록 요구합니다. 어떤 사용자가 양식을 작성하거나, 메뉴를 탐색하거나, 워크플로를 완료하는 데 10초를 쓰든 10분을 쓰든, 즉시 끝낸 사용자와 동일한 결과에 도달해야 합니다.

통과로 인정되는 경우: 시간 제한이 전혀 존재하지 않는 콘텐츠, 또는 존재하는 시간 제한이 순전히 장식적이며 결과에 아무런 영향을 미치지 않는 경우(예: 상호작용을 방해하지 않고 반복 재생되는 애니메이션). 사용자가 얼마의 시간을 들이든 완전히 동일하게 기능하는 콘텐츠는 이 기준을 충족합니다.

실패로 인정되는 경우: 비활성 상태가 일정 시간 지속되면 사용자를 로그아웃시키는 세션 타임아웃, 점수나 완료 여부가 특정 시간 안에 끝내는 것에 의존하는 시간 제한 퀴즈나 평가, 장바구니의 상품을 삭제하는 만료 타이머, 입찰을 마감하는 카운트다운 시계가 있는 경매 입찰 인터페이스, 만료되는 일회용 비밀번호(OTP) 입력란, 시간 제한이 있는 CAPTCHA 과제, 경과 시간에 따라 자동으로 사용할 수 없게 되거나 자동 제출되는 모든 인터랙티브 요소 등이 있습니다.

WCAG가 정의한 공식 예외: 이 기준은 두 가지 범주를 명시적으로 예외로 둡니다. 첫째, 실시간 예외 — 라이브 경매, 생방송, 실시간 멀티플레이어 게임처럼 시간 요소가 활동에 절대적으로 내재된 이벤트입니다. 둘째, 본질적 예외 — 시간 제한을 제거하면 활동 자체가 근본적으로 달라지는 상황입니다. 예를 들어, 속기 능력 시험은 본질적으로 속도를 측정하므로 시간은 필수적입니다. 그러나 개발자와 제품 책임자는 매우 엄격해야 합니다. 편의성, 기술적 레거시, 비즈니스 선호는 “본질적”으로 간주될 수 없습니다. 기준은 시간 제약이 없으면 활동이 핵심 의미나 목적을 상실하는지 여부입니다.

또한 동기화된 미디어 — 예를 들어 자막이 있는 사전 녹화 영상 — 역시 예외에 해당한다는 점이 중요합니다. 미디어 재생의 타이밍은 사용자의 미디어 플레이어가 제어하며, 페이지의 나머지 부분과 상호작용하는 사용자의 능력에 제약을 가하지 않기 때문입니다.

왜 중요한가

웹상의 시간 제한은 매우 다양한 장애를 가진 사용자들에게 불균형적인 피해를 줍니다. 그 영향은 추상적인 수준이 아니라, 많은 사용자에게 시간 제한이 있는 인터페이스는 사실상 접근 불가능한 인터페이스가 됩니다.

운동 장애가 있는 사용자 — 스위치 접근 장치, 마우스 스틱, 시선 추적 소프트웨어, 기타 대체 입력 방식을 사용하는 사람들을 포함 — 는 마우스와 키보드를 사용하는 사용자와 근본적으로 다른 속도로 작업합니다. 여러 단계의 양식을 완료하거나 드롭다운 메뉴를 탐색하는 데 몇 배의 시간이 걸릴 수 있습니다. 세션 타임아웃이나 자동 만료되는 장바구니는 몇 분 동안 공들여 수행한 작업을 한순간에 지워 버릴 수 있습니다.

인지 장애가 있는 사용자 — 난독증, ADHD, 처리 장애, 외상성 뇌 손상 등을 포함 — 는 지침을 읽고, 옵션을 이해하고, 응답을 작성하는 데 훨씬 더 많은 시간이 필요할 수 있습니다. 웹 접근성 이니셔티브(Web Accessibility Initiative)가 정리한 연구에 따르면, 인지 및 학습 장애는 전 세계 인구의 약 15–20%에 어떤 형태로든 영향을 미칩니다. 이 사용자들에게 카운트다운 타이머는 단지 스트레스를 주는 수준을 넘어, 과업을 완료하는 데 필요한 인지 처리 자체를 방해합니다.

스크린 리더 사용자 — 시각장애인 또는 저시력 사용자 — 는 콘텐츠를 선형적으로 탐색하며, 인터페이스 요소를 순차적으로 듣거나 읽어야 합니다. 복잡한 페이지의 구조와 옵션을 이해하는 데는 시각적으로 훑어보는 사용자보다 더 많은 시간이 걸립니다. 시각장애 사용자가 주문 요약을 꼼꼼히 검토하는 동안 만료되는 결제 흐름은 상거래에 대한 직접적인 장벽입니다.

불안 장애가 있는 사용자는 카운트다운 타이머가 존재한다는 사실만으로도 인지적·정서적 부담이 커져, 실제로는 시간이 충분하더라도 과업을 완료하지 못할 수 있습니다. 시간 요소를 제거하면 이 장벽은 완전히 사라집니다.

구체적인 실제 시나리오: 5분 비활성 타임아웃과 60초 만료 OTP를 함께 사용하는 온라인 뱅킹 포털을 생각해 보십시오. 파킨슨병으로 인해 보조 입력 기술이 필요한 사용자나, 앱 간 빠른 전환에 익숙하지 않은 고령 사용자는 SMS를 받고, 앱을 전환하고, 코드를 읽고, 다시 전환해 입력하는 일을 주어진 시간 안에 물리적으로 수행하지 못할 수 있습니다. 이들은 보안상 필연이 아니라 임의의 시간 제약 때문에 자신의 계정에서 사실상 차단됩니다. OTP를 더 긴 기간 동안 유효하게 유지하거나(예: 만료를 없애고 재전송 메커니즘만 두는 방식) 하면 보안을 훼손하지 않고도 문제를 해결할 수 있습니다.

접근성을 넘어, 불필요한 시간 제약을 제거하면 전반적인 사용성이 향상되고 이탈률이 감소합니다. 중간에 만료되지 않는 전자상거래 결제 흐름은 더 많은 고객을 유지하고, 전환율을 높이며, 지원 부담을 줄입니다. 이는 윤리적 의무일 뿐 아니라 비즈니스 측면에서도 긍정적인 변화입니다.

테스트 방법

자동화된 기본 스캔: axe DevTools 또는 Lighthouse를 페이지에 실행해, 더 깊은 수동 검사가 필요한 영역을 가리킬 수 있는 관련 하위 수준 시간 관련 위반(예: 2.2.1 또는 2.2.2에 해당하는 항목)을 식별합니다. axe 규칙 중 2.2.3을 직접 테스트하는 것은 없지만, 시간 제한 경고나 자동 새로고침 관련 발견 사항은 수동 감사 범위를 정하는 데 도움이 됩니다. Lighthouse에서는 “접근성(Accessibility)” 섹션에서 시간 관련 플래그를 확인합니다.
모든 시간 의존 기능 인벤토리 작성: 테스트 전에, 애플리케이션에서 시간과 관련될 수 있는 모든 기능을 체계적으로 목록화합니다. 여기에는 세션 관리 및 비활성 타임아웃, OTP 및 인증 코드 입력란, 장바구니 또는 예약 홀드, 시간 제한 퀴즈·평가·설문조사, 경매·입찰 인터페이스, CAPTCHA 과제, 제출 시간 창이 있는 자동 저장 메커니즘, 눈에 보이는 카운트다운 또는 진행 타이머 등이 포함됩니다.
세션 타임아웃 동작 테스트: 애플리케이션을 열고 여러 단계를 거치는 과업(예: 다중 페이지 양식 작성, 결제 완료)을 시작합니다. 예상되는 타임아웃 시간을 넘길 때까지 아무 상호작용도 하지 않습니다. 그 후 계속 진행을 시도합니다. 진행 상황이 보존되는지, 경고를 받고 세션을 연장할 수 있는지, 아니면 로그아웃되거나 데이터를 잃는지 관찰합니다. 통과하려면 타임아웃이 없거나, 타임아웃이 순전히 예방적이며 재인증 후 데이터가 보존되거나, 사용자에게 충분한 경고와 제어권이 제공되어야 합니다.
OTP 및 코드 만료 테스트: OTP 또는 인증 코드 흐름을 트리거합니다. 코드에 명시된 만료 시간 이후까지(또는 시간이 표시되지 않는 경우 더 오래) 기다립니다. 코드를 입력해 봅니다. 시스템이 시간만을 이유로 코드를 거부한다면 이는 2.2.3 실패입니다. 참고: “코드 재전송” 메커니즘만으로는 2.2.3이 해결되지 않습니다. 원래 코드의 만료 자체가 여전히 시간 제약을 부과하기 때문입니다.
스크린 리더 테스트(NVDA + Firefox): NVDA와 Firefox를 사용해 키보드와 스크린 리더만으로 모든 시간 관련 인터페이스를 탐색합니다. 보조 기술 사용으로 인해 각 단계에 얼마나 시간이 걸리는지 기록합니다. 의도적으로 천천히 진행하며 — 모든 지침을 끝까지 듣고, 가상 커서를 사용해 모든 옵션을 탐색한 뒤 — 제출 또는 다음 단계로 진행을 시도합니다. 느린 탐색이 타임아웃이나 상태 손실을 유발하지 않는지 확인합니다.
스크린 리더 테스트(VoiceOver + macOS의 Safari): macOS의 VoiceOver와 Safari를 사용해 동일한 느린 탐색 테스트를 반복합니다. 특히 동적 카운트다운 타이머에 주의를 기울입니다. VoiceOver가 남은 시간을 긴박하게 느껴지도록 알리는지, 그리고 시간이 다 되었을 때 인터페이스가 실패하는지 확인합니다.
스크린 리더 테스트(JAWS + Chrome): JAWS와 Chrome을 사용해 동일한 흐름을 테스트합니다. JAWS 사용자는 전문 스크린 리더 사용자 중 상당 비율을 차지하며, NVDA 사용자에게 영향을 미치는 시간 관련 문제는 대개 JAWS 사용자에게도 동일하게 영향을 미칩니다.
예외의 정당성 검증: 개발팀이 “본질적” 또는 “실시간”이라고 주장하는 모든 시간 제약에 대해, 그 근거를 문서화하고, 시간이 정말로 활동 목적에 내재된 것인지, 아니면 과업의 본질을 바꾸지 않고도 완화·연장·제거할 수 있는지 평가합니다.

해결 방법

세션 타임아웃 — 잘못된 예

<!-- 5분 비활성 후 경고 없이 세션이 만료됨.
     사용자 데이터는 손실되고 로그인 페이지로 리디렉션됨. -->
<script>
  setTimeout(function() {
    window.location.href = '/logout?reason=timeout';
  }, 300000);
</script>

세션 타임아웃 — 올바른 예

<!-- 비활성 상태만으로 자동 세션 만료 없음.
     브라우저 탭이 열려 있는 동안 서버 세션 유지.
     타임아웃이 법적으로 요구되는 경우(예: 은행 규제),
     충분한 사전 경고를 제공하고 세션 연장 옵션을 제공하되,
     연장 대화 상자 자체에는 시간 압박이 없어야 함. -->
<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>
<!-- "Stay signed in" 버튼 자체에는 만료 시간이 없음 —
     사용자는 버튼을 찾고 활성화하는 데 필요한 만큼 시간을 쓸 수 있음. -->

만료되는 OTP 필드 — 잘못된 예

<!-- OTP는 60초 후 만료됨. 만료 후 양식을 제출하면
     오류가 반환되고 사용자는 전체 흐름을 다시 시작해야 함. -->
<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>

만료되지 않는 OTP 필드 — 올바른 예

<!-- OTP는 짧은 사용자 노출 시간 안에는 만료되지 않음.
     더 긴 서버 측 유효 기간(예: 15-30분)을 사용.
     재전송 옵션이 있지만 원래 코드는 계속 유효.
     카운트다운 타이머를 표시하지 않아 불필요한 긴박감을 제거. -->
<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>
<!-- 서버는 짧은 시간 창이 아니라
     첫 번째 성공적인 사용 후 코드를 무효화함. -->

시간 제한 퀴즈 — 잘못된 예

<!-- 10분 타이머가 0이 되면,
     사용자가 답변을 마쳤는지와 관계없이 퀴즈가 자동 제출됨. -->
<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>

시간 제한 없는 퀴즈 — 올바른 예

<!-- 퀴즈에는 시간 제한이 없음. 단, 시간 자체가
     평가의 명시적 대상(예: 공인 속도 테스트)인 경우는 예외.
     선택적 시간 표시가 제공되더라도,
     자동 제출을 유발하거나 느린 완료에 불이익을 주지 않음. -->
<form id='quiz-form'>
  <!-- quiz questions -->
  <button type='submit'>Submit Quiz</button>
</form>
<!-- 시간이 정말 필요하다면 정보 제공용으로만 사용:
<p>Most users complete this in about 10 minutes. Take as long as you need.</p> -->

자주 발생하는 실수

세션 보안에 하드 타임아웃이 필수라고 가정하는 것: 많은 팀이 보안 요구 사항을 이유로 짧은 비활성 타임아웃을 구현하지만, 대부분의 보안 표준(PCI-DSS, OWASP 포함)은 사용자 제어 세션 연장을 허용합니다. 경고나 연장 기회 없이 강제 로그아웃하는 것은 보안 필수가 아니라 접근성 실패입니다.
중지·연장 수단 없이 카운트다운 타이머만 표시하는 것: 카운트다운에 aria-live 영역을 추가하면 스크린 리더 사용자에게 매초 알림을 주어 오히려 더 나빠질 뿐, 근본적인 시간 문제를 해결하지 못합니다. 해결책은 제약을 더 접근성 있게 알리는 것이 아니라, 제약 자체를 제거하는 것입니다.
“코드 재전송”을 OTP 만료 해결책으로 간주하는 것: 재전송 버튼은 사용자가 새 코드를 받도록 해 주지만, 원래 코드가 시간 때문에 만료된 사실은 그대로입니다. 시간 제한은 여전히 존재합니다. 올바른 해결책은 유효 기간을 충분히 늘려 시간 압박을 없애는 것입니다.
비활성 후 자동으로 캐러셀이나 마법사 단계를 진행시키는 것: 일정 시간이 지나면 자동으로 다음 단계로 넘어가는 다단계 양식이나 마법사는 시간 제약을 부과합니다. 지침을 읽거나 답변을 고민 중인 사용자는 불이익을 받습니다. 단계 진행은 반드시 명시적인 사용자 행동에 의해서만 이루어져야 합니다.
장바구니 타이머가 상품을 보존하지 않고 삭제하는 것: 전자상거래의 예약 타이머(“장바구니는 15분 후 만료됩니다”)는 만료 시 상품이 단순히 예약 해제되는 것이 아니라 영구적으로 사라지는 경우 2.2.3을 위반합니다. 최소한 상품을 위시리스트에 저장하거나, 세션을 복원 가능하게 해야 합니다.
“실시간 예외”를 과도하게 적용하는 것: 실제로는 진정한 라이브가 아닌 인터페이스에 시간 제약을 정당화하기 위해 “실시간”이라는 라벨을 붙이는 경우입니다. 사전 녹화된 경매 재생, 정적인 입찰 인터페이스, 단지 퀴즈쇼를 흉내 낸 퀴즈 등은 실시간 예외에 해당하지 않습니다.
백엔드 API 응답의 시간 제약을 무시하는 것: 프런트엔드 타이머는 수정했지만, API 자체가 특정 시간 창 이후 요청을 거부하는 경우입니다. 사용자는 카운트다운을 보지 못하지만 제출이 조용히 실패합니다. 백엔드 세션 관리는 프런트엔드 경험과 일치해야 합니다.
폼 상태를 저장하지 않은 채 자동 로그아웃에 setTimeout을 사용하는 것: 자동 로그아웃이 불가피한 경우(예: 규제 요구 사항), 리디렉션 전에 사용자 양식 데이터를 저장하지 않으면 모든 작업이 사라집니다. 최소한 임시 상태를 저장해 재인증 후 복원해야 합니다.
2.2.1 준수를 2.2.3 준수와 혼동하는 것: (레벨 A인 2.2.1이 요구하는 대로) “끄기, 조정, 연장” 제어를 제공하는 것만으로는 2.2.3을 충족하지 못합니다. 레벨 AAA는 시간 제한이 “관리 가능”한 것이 아니라 “본질적이지 않은” 것을 요구합니다. 여유 있는 연장 기능이 있더라도 시간 제한은 여전히 시간 제한입니다.
서드파티 임베디드 컴포넌트의 시간 제약을 간과하는 것: 임베디드 채팅 위젯, 결제 프로세서, 신원 확인 SDK, 지도 서비스 등은 자체적인 시간 제약을 도입할 수 있습니다. 서드파티 출처라는 이유만으로, 인터페이스에 통합된 경우 WCAG 적용 대상에서 제외되지 않습니다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보(Official Gazette) 제32933호에 게재되었으며, WCAG 2.2를 기술적 기준으로 참조하는 국가 웹 접근성 프레임워크를 수립합니다. 이 대통령령은 터키에서 디지털 서비스를 운영하는 폭넓은 주체에 대해 준수를 의무화합니다.

대상 주체에는 공공 기관 및 정부 기관, 전자상거래 플랫폼, 은행 및 금융 서비스, 병원 및 의료 서비스 제공자, 가입자 200,000명 이상인 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교 등이 포함됩니다. 이 조직들은 대중에게 디지털 서비스를 제공할 때 대통령령에 정의되거나 참조된 접근성 기준을 충족해야 합니다.

WCAG 2.2.3 — No Timing은 레벨 AAA 기준이며, 대통령령 2025/10은 정렬 대상인 유럽 표준 EN 301 549와 마찬가지로 레벨 A와 레벨 AA 적합을 법적 최소 기준으로 요구합니다. 레벨 AAA 준수는 이 프레임워크 하에서 직접적인 법적 의무는 아닙니다. 그러나 레벨 AAA, 특히 2.2.3을 구현하는 것은 최고 수준의 접근성 성숙도를 나타내며, 최소 법적 기준을 넘어서는 포괄적 설계에 대한 진정한 의지를 보여 줍니다.

특히 BDDK 감독을 받는 은행 및 금융 서비스와, 거래량이 많은 전자상거래 플랫폼과 같은 일부 대상 주체 유형에서는 OTP 만료, 세션 관리, 결제 흐름 타이머 등 시간 제약이 널리 사용되는 기능입니다. 2.2.3이 법적으로 요구되지 않는 경우에도, 이러한 흐름에서 시간 장벽을 방치하는 것은 실제 차별 위험을 초래합니다. 특히 터키의 접근성 집행 메커니즘이 성숙해지고, 민원·불만 제기 절차가 정착될수록 그 위험은 커집니다.

장애인, 고령자, 디지털 문해력이 낮은 사용자를 대상으로 하는 공공 기관과 의료 서비스 제공자는 시간 제약을 완전히 제거해야 할 윤리적 근거가 특히 강합니다. 디지털 정부 서비스와 의료 포털에서 시간 제한을 제거하는 것은 터키의 광범위한 전자정부 포용 목표와 부합하며, 공공 부문 조달에서 AAA 채택이 일반화될수록 향후 규제 리스크를 줄이는 데도 도움이 됩니다.

자국 내 선도적 위상 확보, 국제 시장 접근, 또는 유럽 접근성 법(European Accessibility Act)과 EN 301 549가 적용되는 유럽연합 맥락에서의 조달 경쟁력 확보 등, 디지털 제품을 완전히 포괄적인 것으로 포지셔닝하려는 조직은 WCAG 2.2.3 준수를 선택적 개선이 아닌 전략적 투자로 간주해야 합니다.