WCAG 2.2.6: 시간 제한

WCAG 2.2.6은 사용자가 비활성 상태로 인한 타임아웃 때문에 데이터가 손실될 수 있다는 경고를 받아야 하며, 데이터가 보존되지 않는 한 이러한 타임아웃은 최소 20시간 이상 지속되어야 한다고 요구합니다. 이는 인지 장애, 운동 장애가 있는 사용자와 작업을 완료하는 데 더 많은 시간이 필요한 다른 사용자들을 보호합니다.

이 규칙의 의미

WCAG 2.2.6 Timeouts (Level AAA)는, 사용자 비활성 상태가 데이터 손실을 초래할 수 있는 경우, 데이터가 사용자 비활성 상태 20시간을 초과하여 보존되는 경우를 제외하고, 그 비활성 상태의 지속 시간에 대해 사용자에게 경고할 것을 요구합니다. 실질적으로 이는, 웹 애플리케이션이나 서비스가 일정 시간 동안 사용자가 비활성 상태였다는 이유로 사용자의 데이터를 잃을 수 있다면 — 예를 들어 폼 입력, 쇼핑 카트, 진행 중인 거래 등 — 데이터가 손실되기까지 사용자가 정확히 얼마나 시간이 남았는지 알려야 한다는 뜻입니다.

이 기준은 타임아웃이 데이터 손실을 초래하는 모든 상황에 적용됩니다. 일반적인 예로는, 폼 데이터를 지우는 은행 또는 정부 포털의 세션 만료, 일정 시간 비활성 상태 후 비워지는 쇼핑 카트, 세션 쿠키가 만료되면 초기화되는 다단계 마법사나 폼, 부분 응답을 폐기하는 온라인 시험 또는 예약 시스템 등이 있습니다. 핵심 트리거는 비활성 상태(작업 완료에 대한 절대 시간 제한은 2.2.1에서 다룹니다)와 그 결과로서의 데이터 손실이 결합된 경우입니다.

통과로 인정되는 경우: 페이지는 세션 시작 시점 — 또는 사용자가 데이터를 입력하기 시작하기 전에 — 데이터 손실을 초래하는 특정 비활성 타임아웃 지속 시간을 명확히 사용자에게 알리면 2.2.6을 통과합니다. 또는, 사용자가 얼마나 오래 비활성 상태이든 데이터 손실이 발생하지 않는 경우(예: 서버가 모든 폼 데이터를 20시간을 초과하여, 또는 무기한 보존하는 경우)에도 통과합니다. 세션이 이미 만료된 후에만 경고를 표시하는 것은 이 기준을 충족하지 못합니다.

실패로 인정되는 경우: 페이지가 비활성 상태가 일정 시간 지속된 후 사용자에게 이 위험을 전혀 알리지 않은 채 조용히 사용자 데이터를 잃는다면 실패입니다. 또한, 경고가 존재하더라도 데이터 손실 시점에만 제시되어(사용자가 행동하기에는 너무 늦게) 있거나, 경고가 모호한 경우 — 예를 들어, 타임아웃을 유발하는 실제 비활성 지속 시간을 명시하지 않고 "세션이 만료될 수 있습니다"라고만 말하는 경우 — 역시 실패입니다.

공식 예외: 이 기준은 비활성 상태 20시간을 초과하여 데이터가 보존되는 상황을 명시적으로 예외로 둡니다. 20시간 기준은 사용자가 하루에 작업을 시작하고 다음 날에 다시 이어서 할 수 있도록 하기 위해 선택되었습니다. 시스템이 사용자에게 별도의 조치 없이도 서버 측에서 입력된 모든 데이터를 최소 20시간 동안 안정적으로 저장한다면, 경고를 표시할 의무는 없습니다. 또한, 이 기준은 보안에 필수적인 타임아웃에는 적용되지 않습니다 — 예를 들어, 사용자 행동과 무관하게 일정 시간이 지나면 세션을 종료해야 한다는 법률 또는 규제상의 강제 요구가 있는 경우입니다. 이러한 경우에도 이 기준은 공개를 권장하지만, 법적 제약이 있음을 인정합니다.

왜 중요한가

충분한 경고 없이 발생하는 타임아웃은 인지 장애, 운동 장애가 있는 사람들, 그리고 시각장애인이나 저시력 사용자에게 불균형적으로 큰 영향을 미칩니다. 난독증, ADHD, 외상성 뇌손상과 같은 인지 장애가 있는 사용자는, 폼을 제출하기 전에 지침을 읽고, 텍스트를 작성하고, 정보를 검토하는 데 훨씬 더 많은 시간이 필요할 수 있습니다. 세션이 조용히 타임아웃되는 동안 그들이 여전히 작업 중이라면, 그동안의 모든 노력이 사라지고 처음부터 다시 시작해야 합니다 — 이는 매우 낙담스러운 경험이며, 결국 작업을 완전히 포기하게 만들 수 있습니다.

스위치 액세스, 시선 추적 장치, 기타 대체 입력 방법에 의존하는 운동 장애가 있는 사람들은 마우스 사용자보다 훨씬 느린 속도로 인터페이스와 상호작용합니다. 긴 보험 청구 폼이나 다중 페이지의 정부 신청서를 완료하는 데는 기본 세션 타임아웃이 가정하는 시간보다 훨씬 더 오래 걸릴 수 있습니다. 카운트다운을 알지 못하면, 진행 상황을 저장하거나 연장을 요청하는 등 데이터가 사라지기 전에 취할 수 있는 조치를 취할 기회가 없습니다.

스크린 리더 사용자도 복합적인 어려움에 직면합니다. 각 필드를 소리 내어 읽고 키보드로 확인해야 하므로 복잡한 폼을 탐색하는 데 더 오래 걸립니다. 사용자가 긴 폼을 차근차근 진행하는 동안 세션이 만료되는 것은 단순히 불편한 수준이 아니라 — 수 시간의 노력이 사라질 수 있으며, 필수 서비스에 접근하는 데 상당한 장벽이 될 수 있습니다.

다음과 같은 실제 시나리오를 생각해 보십시오. 다발성 경화증이 있는 한 사용자가 정부 포털을 통해 장애 급여를 신청하고 있습니다. 이 폼은 12개 섹션으로 구성되어 있으며, 증빙 서류 업로드를 요구합니다. 세션은 15분간 비활성 상태가 지속되면 만료되지만, 사용자는 7번 섹션 중간에서 다른 방에 있는 문서를 가져오기 위해 잠시 자리를 비웠습니다. 돌아와 보니 모든 데이터가 지워졌고, 아무런 사전 경고 없이 처음부터 다시 시작해야 합니다. 2.2.6에 따르면, 이 포털은 비활성 상태가 15분을 초과하면 데이터가 손실된다는 사실을 처음부터 사용자에게 알려, 사용자가 이에 맞춰 계획할 수 있도록 해야 합니다.

접근성을 넘어, 타임아웃 동작을 선제적으로 공개하는 것은 모든 사용자의 사용자 경험을 개선하고, 체크아웃, 회원가입, 신청 폼과 같은 고가치 전환 흐름에서 이탈률을 줄여 줍니다. 또한, 사용자가 왜 자신의 데이터가 사라졌는지 의문을 갖지 않게 함으로써 신뢰를 구축합니다.

테스트 방법

자동 사전 스캔: 폼, 체크아웃 흐름, 기타 데이터 입력 인터페이스가 포함된 페이지에 대해 axe DevTools 또는 Lighthouse를 실행합니다. 두 도구 모두 2.2.6 위반을 직접 표시하지는 않지만, 이 단계에서 경고 메커니즘의 일부일 수 있는 타임아웃 관련 ARIA 라이브 영역이나 대화 상자 컴포넌트를 식별하고, 이들 자체가 접근 가능한지(올바른 역할, 레이블, 포커스 관리) 확인합니다.
타임아웃 동작 파악: 개발 팀과 논의하거나 서버 측 구성을 검토하여 세션의 비활성 타임아웃 지속 시간을 파악합니다. 일반적인 위치로는 웹 서버 구성 파일, 애플리케이션 세션 미들웨어 설정, 인증 제공자 문서 등이 있습니다. 정확한 지속 시간을 분 단위로 기록합니다.
사전 공개 여부 확인: 페이지를 새로 로드하고, 데이터 입력이 시작되기 전에 사용자에게 제시되는 모든 콘텐츠를 읽습니다. 페이지 본문, 도입 단락, 배너, 모달 등에서, 정확한 비활성 타임아웃 지속 시간을 명시하고, 해당 기간 동안 비활성 상태일 경우 데이터가 손실된다고 밝히는 명확한 문구를 찾습니다. 공개 문구는 "15분"처럼 지속 시간을 명시적으로 언급해야 하며, "짧은 시간"과 같은 모호한 표현이어서는 안 됩니다.
스크린 리더로 테스트: NVDA+Firefox, VoiceOver+Safari, 또는 JAWS+Chrome을 사용하여 페이지의 맨 처음부터 탐색합니다. 타임아웃 공개 문구가, 사용자가 적극적으로 찾아 나서지 않아도 스크린 리더에 의해 도달 가능하고 읽히는지 확인합니다. 공개 문구가 시각적으로 눈에 띄는 배너에 있다면, 첫 번째 폼 필드보다 앞선 읽기 순서에 있는지 확인합니다.
비활성 상태 시뮬레이션: 폼 작성을 시작합니다. 그런 다음 타임아웃 기간보다 약간 짧은 시간 동안 페이지와 상호작용을 중단하고, 어떤 일이 일어나는지 관찰합니다. 이후 타임아웃 기간이 지난 후까지 기다려 이를 반복합니다. 데이터가 손실되는지, 데이터 손실이 발생하기 전에 경고가 표시되는지, 그리고 그 경고가 세션 시작 전에 전달되었는지 기록합니다.
20시간 예외 테스트: 팀이 데이터가 20시간을 초과하여 보존된다고 주장하는 경우, 폼을 부분적으로 작성한 뒤 최소 20시간을 기다렸다가 페이지로 돌아와 데이터가 여전히 존재하는지 확인하는 방식으로 이를 실증적으로 검증합니다. 또는 개발 팀과 함께 서버 측 세션 저장소 구성을 검토합니다.
키보드 및 포커스 테스트: 타임아웃 경고 대화 상자나 알림이 나타나는 경우, 키보드만으로 탐색하여 해당 요소가 자동으로 포커스를 받는지, 그 내용이 완전히 읽을 수 있는지, 그리고 마우스를 사용하지 않고도 사용자가 이를 닫거나(예: 세션 연장) 조치를 취할 수 있는지 확인합니다.

수정 방법

조용한 데이터 손실이 있는 세션 — 잘못된 예

<!-- A multi-step form with a 10-minute server session timeout.
     No warning is displayed anywhere on the page.
     After 10 minutes of inactivity, the session is destroyed
     and all entered data is lost. -->
<form action='/submit-application' method='post'>
  <h1>Benefit Application</h1>
  <label for='full-name'>Full Name</label>
  <input type='text' id='full-name' name='full-name'>
  <!-- ... many more fields ... -->
  <button type='submit'>Submit Application</button>
</form>

조용한 데이터 손실이 있는 세션 — 올바른 예

<!-- The timeout duration is disclosed clearly before any form fields.
     The disclosure is in the natural reading order so screen readers
     encounter it before the first input. -->
<main>
  <h1>Benefit Application</h1>
  <div role='note' aria-label='Session timeout notice'>
    <p>
      <strong>Important:</strong> This form will time out after
      <strong>10 minutes of inactivity</strong>, and any information
      you have entered will be lost. Please have all required documents
      ready before you begin, or save your progress regularly.
    </p>
  </div>
  <form action='/submit-application' method='post'>
    <label for='full-name'>Full Name</label>
    <input type='text' id='full-name' name='full-name'>
    <!-- ... many more fields ... -->
    <button type='submit'>Submit Application</button>
  </form>
</main>

모호한 경고가 있는 체크아웃 세션 — 잘못된 예

<!-- The warning exists but is vague — it does not state the actual
     timeout duration, making it impossible for users to plan. -->
<p class='notice'>Your session may expire due to inactivity.</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

모호한 경고가 있는 체크아웃 세션 — 올바른 예

<!-- The warning now states the exact duration so users can
     make an informed decision about when to begin the checkout. -->
<p class='notice'>
  For your security, your checkout session will expire after
  <strong>20 minutes of inactivity</strong>. Any payment information
  entered will need to be re-entered if the session expires.
</p>
<form action='/checkout' method='post'>
  <label for='card-number'>Card Number</label>
  <input type='text' id='card-number' name='card-number'
         autocomplete='cc-number'>
  <button type='submit'>Place Order</button>
</form>

서버 측에서 20시간을 초과해 데이터가 보존되는 경우 — 올바른 예(예외 적용)

<!-- When all form data is saved to the server continuously
     and preserved for at least 20 hours, no timeout warning
     is required by 2.2.6. This is the ideal UX pattern:
     autosave is indicated to the user for transparency. -->
<main>
  <h1>Job Application</h1>
  <p>
    Your progress is automatically saved as you type.
    You can leave and return to this form at any time within
    <strong>30 days</strong> and your answers will be preserved.
  </p>
  <form action='/apply' method='post'>
    <label for='cover-letter'>Cover Letter</label>
    <textarea id='cover-letter' name='cover-letter'></textarea>
    <p aria-live='polite' id='autosave-status'>Draft saved.</p>
    <button type='submit'>Submit Application</button>
  </form>
</main>

일반적인 실수

타임아웃 경고를 브라우저 콘솔이나 서버 로그 항목처럼 최종 사용자에게 보이지 않는 곳에만 표시하는 것 — 경고는 사용자 인터페이스에, 데이터 손실이 발생하기 전에 사용자가 접하게 될 위치에 제시되어야 합니다.
공개 문구를 폼 바로 위나 폼 자체가 아닌, 사용자가 데이터 입력을 시작하기 전에 읽을 가능성이 낮은 푸터, 개인정보 처리방침, 이용 약관 페이지 등에 배치하는 것.
세션 만료 임박을 경고하기 위해 모달 대화 상자를 사용하면서, 키보드 포커스를 해당 대화 상자로 이동시키지 않는 것 — 키보드 및 스크린 리더 사용자는 경고가 나타났다는 사실을 전혀 인지하지 못할 수 있습니다.
세션 길이(예: "세션은 30분 동안 유지됩니다")를 명시하면서 비활성 타임아웃(예: "15분 동안 비활성 상태이면 데이터가 손실됩니다")은 명시하지 않는 것 — 이는 서로 다른 개념이며, 2.2.6이 규율하는 것은 비활성 상태에 의해 촉발되는 데이터 손실뿐입니다.
시각 사용자용 타임아웃 경고 모달이 존재한다는 이유만으로 기준을 충족했다고 가정하는 것 — 모달이 키보드로 접근할 수 없거나, 접근 가능한 이름이 없거나, ARIA 라이브 영역이나 포커스 관리에 의해 알림이 전달되지 않는다면, 스크린 리더 사용자는 경고를 받지 못합니다.
서버 측 세션 타임아웃을 25시간으로 설정하고, 브라우저 측 또는 애플리케이션 수준 상태(예: Redux 스토어, localStorage)가 더 일찍 지워지는지 확인하지 않은 채 공개가 필요 없다고 결론 내리는 것 — 실질적인 타임아웃은 데이터가 먼저 손실되는 메커니즘에 의해 결정됩니다.
호버로만 트리거되는 툴팁에 타임아웃 지속 시간을 공개하는 것 — 키보드 탐색이나 터치 기기에 의존하는 사용자는 이 공개 문구를 전혀 접하지 못할 수 있습니다.
데이터 손실이 이미 발생한 후에 표시되는 "세션이 만료되었습니다"라는 일반적인 CMS 또는 프레임워크 경고에 의존하는 것 — 이는 사용자가 데이터를 입력하기 시작하기 전에 선제적으로 정보를 제공하는 것이 아닙니다.
백그라운드 탭에서 폼을 여는 사용자를 고려하지 않는 것: 세션 타이머가 탭이 비활성 상태인 동안에도 계속 진행된다면, 사용자가 폼과 상호작용할 기회조차 갖기 전에 데이터가 손실될 수 있습니다. 이는 백그라운드 탭을 적극적으로 일시 중지하는 모바일 브라우저에서 특히 문제가 됩니다.
데스크톱 버전에는 경고를 표시하면서 모바일 버전이나 PWA(Progressive Web App) 환경에서는 경고를 생략하여, 상당수 사용자를 대상으로 2.2.6을 충족하지 못하는 불일치한 경험을 만드는 것.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은, 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 구속력 있는 웹 접근성 의무를 설정합니다. 이 대통령령은 WCAG 2.2를 기술 표준으로 준수할 것을 명시하고 있으며, 해당 기관이 최소한 Level AA 적합성을 충족하도록 요구합니다. WCAG 2.2.6 Timeouts는 Level AAA 기준이므로, 대통령령의 기본 요구 사항에 의해 직접적으로 의무화되지는 않습니다. 그러나 대통령령의 범위와 취지는, 해당 기관이 2.2.6과 같은 기준에 대해 AAA 준수를 추구해야 할 강력한 실질적 이유를 형성합니다.

대통령령 2025/10의 적용 대상에는 공공 기관 및 부처, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 200,000명 이상의 가입자를 보유한 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립 학교 등이 포함됩니다. 이들 중 상당수는 2.2.6이 보호하려는 바로 그 유형의 데이터 입력 워크플로를 포함하는 온라인 포털을 운영합니다. 예를 들어, 대출 신청, 환자 접수 폼, 티켓 예약 시스템, 등록 신청, 정부 복지 신청 등이 있습니다.

특히 은행과 전자상거래 플랫폼의 경우, 세션 타임아웃은 일상적인 보안 조치이며, 보안 요구 사항과 접근성 의무 간의 상호작용은 매우 직접적으로 관련됩니다. 은행이 일정 시간이 지나면 유휴 세션을 종료해야 한다는 규제 의무를 가지고 있더라도, 타임아웃 지속 시간을 사전에 공개하는 방식으로 WCAG 2.2.6을 구현하는 것은 이러한 보안 요구와 충돌하지 않습니다 — 오히려 이를 보완합니다. 사용자는 제약 조건을 인지하게 되지만, 은행은 세션 보안 수준을 약화시킬 필요가 없습니다.

대통령령의 적용 대상인 의료 서비스 제공자와 병원은, 환자 병력 폼, 사전 승인 요청, 예약 시스템 등 상상할 수 있는 가장 중요한 데이터 입력 작업을 다룹니다. 이러한 맥락에서 인지 장애나 운동 장애가 있는 환자가 폼 작성 도중 데이터를 잃게 되면, 단순한 좌절을 넘어 진료 지연이라는 결과로 이어질 수 있습니다. 이 환경에서 2.2.6을 구현하는 것은 대통령령을 뒷받침하는 포용적 서비스 의무를 직접적으로 실천하는 것입니다.

Level AAA는 법적으로 요구되지는 않지만, 2.2.6처럼 구현 노력은 상대적으로 적으면서(폼에 정확한 공개 문구 한 줄을 추가하는 정도) 취약한 사용자 집단에 상당한 이익을 제공하는 기준에 대해 AAA를 달성하는 것은 최고 수준의 접근성 실천을 의미합니다. 터키 시장에서 디지털 포용에 대한 의지를 보여주고자 하는 조직이나, 향후 더 엄격한 규제를 예상하는 조직은, 2.2.6을 선택적 목표가 아닌 실질적인 구현 목표로 삼는 것이 바람직합니다.