WCAG 2.1.3: 키보드 (예외 없음)

WCAG 2.1.3은 웹 페이지나 애플리케이션의 모든 기능이 키보드 인터페이스를 통해 조작 가능해야 한다고 요구하며, 경로 의존 작업이나 자유형식(프리핸드) 그리기 작업조차도 예외 없이 포함한다. 이 AAA 기준은 WCAG 2.1.1에 존재하던 허점을 보완하여, 마우스를 사용할 수 없는 사용자에게 완전한 키보드 접근성을 보장한다.

이 규칙의 의미

WCAG 2.1.3 — Keyboard (No Exception)은 WCAG 2.1 및 2.2에서 레벨 AAA 성공 기준으로, 모든 예외를 제거함으로써 WCAG 2.1.1(Keyboard, 레벨 A)을 확장한 것입니다. 구체적으로 다음과 같이 명시합니다: 콘텐츠의 모든 기능은 개별 키 입력에 대해 특정한 타이밍을 요구하지 않는 키보드 인터페이스를 통해 조작 가능해야 한다. 2.1.1과의 중요한 차이는, 기저 기능이 단순한 끝점이 아니라 사용자의 움직임 경로에 의존하는 입력을 요구하는 경우 그 기능을 예외로 인정하던 조항이 사라졌다는 점입니다.

2.1.1에서는, 사용자의 정확한 포인터 경로가 출력 결과를 결정하기 때문에, 자유형 드로잉 캔버스, 제스처 기반 페인팅 도구, 경로에 민감한 드래그 인터페이스 같은 기능을 키보드 지원 대상에서 정당하게 제외할 수 있습니다. WCAG 2.1.3은 이 예외를 완전히 제거합니다. 이 기준에서는 모든 단일 기능—드로잉, 드래깅, 경로 의존 제스처, 그리고 역사적으로 포인터 움직임에 의존해 온 모든 상호작용—이 키보드로 접근 가능해야 합니다. 이는 개발자가 자유형 또는 경로 의존 작업에 대해서도, 예를 들어 도형 도구가 있는 접근 가능한 툴바, 키보드로 제어되는 드로잉 모드, 폼 기반 입력 대안과 같은 키보드 대체 메커니즘을 제공해야 함을 의미합니다.

통과하려면 페이지의 모든 작업이 오직 키보드만으로 시작, 탐색, 완료될 수 있어야 합니다. 여기에는 포커스 관리, 모달 다이얼로그, 드래그 앤 드롭 재정렬, 커스텀 슬라이더, 캔버스 드로잉 도구, 지도 상호작용, 캐러셀 내비게이션, 비디오 재생 컨트롤이 포함됩니다. 키보드 트랩(2.1.2에서도 다룸)이 없어야 하고, 클릭, 호버, 터치 기반 제스처로만 트리거되고 동등한 키보드 경로가 없는 기능이 없어야 하며, 마우스 포인터 경로에 의존해서도 안 됩니다.

실패는, 얼마나 틈새적이거나 부차적으로 보이든 상관없이, 어떤 기능이든 키보드만으로는 도달하거나 완료할 수 없을 때 발생합니다. 이 기준에는 예외가 전혀 없기 때문에, 키보드로 접근할 수 없는 기능이 단 하나라도 있으면 전체 실패에 해당하며, WCAG에서 가장 요구 수준이 높은 기준 중 하나가 됩니다.

왜 중요한가

키보드 접근성은 포인팅 장치를 사용할 수 없는 운동 장애 사용자에게 근본적인 요소입니다. 파킨슨병, 사지마비, 뇌성마비, 반복성 긴장 손상, 사지 차이와 같은 상태를 가진 사람들은 종종 물리적 키보드, 스위치 장치, sip-and-puff 컨트롤러, 키보드 입력을 에뮬레이션하는 시선 추적 기술에 전적으로 의존합니다. 세계보건기구(WHO)에 따르면 전 세계 약 13억 명이 어떤 형태로든 중대한 장애를 가지고 있으며, 그중 상당 부분이 운동 또는 신체적 장애에 해당합니다. 터키만 보더라도, 터키 통계청(TÜİK) 자료에 따르면 850만 명이 넘는 사람이 최소 한 가지 형태의 기능 제한을 보고하고 있습니다.

운동 장애를 넘어, 키보드 접근성은 NVDA, JAWS, VoiceOver와 같은 스크린 리더로 탐색하는 시각장애 및 저시력 사용자에게도 이롭습니다. 이들 도구는 모두 웹 콘텐츠를 탐색하고 상호작용하기 위해 키보드 명령에 의존합니다. 광과민성 질환이 있는 사용자는 터치스크린을 피할 수 있고, 인지 장애가 있는 사용자는 키보드 상호작용이 제공하는 예측 가능하고 선형적인 내비게이션으로부터 종종 큰 도움을 받습니다.

구체적인 실제 시나리오를 생각해 봅시다. 자유형 벡터 드로잉 도구를 제공하는 그래픽 디자인 플랫폼이 있다고 가정합니다. WCAG 2.1.1에서는 포인터 경로가 도형을 정의하기 때문에 이 기능이 예외로 인정될 수 있습니다. WCAG 2.1.3에서는 플랫폼이 대안을 제공해야 합니다. 예를 들어 도형 라이브러리, 키보드로 제어되는 앵커 포인트 시퀀스, 텍스트 기반 SVG 경로 편집기 등을 제공하여, 운동 장애가 있는 사용자가 마우스 없이도 벡터 아트를 제작할 수 있어야 합니다. 이를 제공하지 않으면 키보드만 사용하는 상당수의 창작 전문가를 배제하게 됩니다.

사용성과 SEO 관점에서, 적절히 키보드 접근 가능한 인터페이스는 일반적으로 더 깔끔한 포커스 관리, 더 논리적인 탭 순서, 잘 구조화된 DOM 계층을 특징으로 하며, 이는 모두 더 나은 크롤링 가능성과 모든 사용자—특히 속도를 위해 키보드 단축키를 선호하는 파워 유저—에게 더 높은 품질의 사용자 경험을 제공하는 데 기여합니다.

테스트 방법

자동화된 기본 스캔 실행: axe DevTools(브라우저 확장 또는 CLI)나 Google Lighthouse를 사용해 페이지를 검사하여, 포커스를 받을 수 없는 요소, 키보드 트랩, 인터랙티브해야 하는데 pointer-events: none이 적용된 요소 등, 쉽게 발견 가능한 키보드 접근성 실패를 식별합니다. 이 도구들이 2.1.3 위반을 직접적으로 잡아내지는 못하지만, 관련 문제를 드러내고 수동 테스트 전에 깨끗한 기본 상태를 마련해 줍니다.
모든 인터랙티브 기능 목록화: 테스트 전에 페이지의 모든 인터랙티브 컴포넌트—버튼, 링크, 폼, 모달, 아코디언, 캐러셀, 지도, 캔버스 도구, 드래그 앤 드롭 영역, 커스텀 드롭다운, 날짜 선택기, 비디오 플레이어, 마우스나 터치 이벤트에 반응하는 모든 위젯—를 전부 인벤토리로 만듭니다. 이 인벤토리가 테스트 체크리스트가 됩니다.
키보드 전용 내비게이션 테스트: 마우스를 분리하거나 비활성화합니다. Tab과 Shift+Tab으로 포커스를 이동하고, Enter와 Space로 컨트롤을 활성화하며, 복합 위젯(메뉴, 슬라이더, 탭, 라디오 그룹)에는 화살표 키를, 다이얼로그 닫기에는 Escape를 사용합니다. 인벤토리 목록의 모든 기능을 완료해 보십시오. 키보드만으로는 시작, 완료, 종료할 수 없는 기능을 모두 기록합니다.
NVDA + Firefox로 스크린 리더 테스트: Windows에서 NVDA를 실행하고 Firefox를 사용합니다. 가상 커서로 탐색하며(H는 헤딩, B는 버튼, F는 폼 필드, Tab은 인터랙티브 요소), 각 기능을 시도합니다. 안내되는 role, name, state를 듣고, 도달할 수 없거나 음성 안내가 전혀 나오지 않는 인터랙티브 영역을 식별합니다.
JAWS + Chrome으로 스크린 리더 테스트: Windows에서 JAWS와 Chrome을 사용합니다. JAWS 가상 커서와 Forms Mode( Enter로 토글)를 사용합니다. 모든 기능이 조작 가능하고, 특히 모달 다이얼로그가 열리거나 AJAX 콘텐츠가 로드된 후에 각 상호작용 뒤에 포커스가 올바르게 관리되는지 확인합니다.
VoiceOver + Safari(macOS/iOS)로 스크린 리더 테스트: VoiceOver를 활성화합니다(macOS에서는 Command + F5). Control + Option + 화살표로 탐색합니다. iOS에서는 스와이프 제스처를 사용합니다. 모든 기능에 도달하고 조작할 수 있는지 확인합니다. 데스크톱 버전에서 키보드 동등 기능이 없을 수 있는 커스텀 터치 기반 위젯에 특히 주의를 기울입니다.
경로 의존 기능 감사: 드로잉 캔버스, 지도 상호작용, 제스처 기반 컴포넌트에 대해, 대체 키보드 메커니즘이 존재하는지 확인합니다. 키보드 컨트롤만으로 도형을 만들거나, 리스트 항목을 재정렬하거나, 지도를 패닝해 보십시오. 키보드 경로가 없다면 이는 직접적인 2.1.3 실패입니다.
포커스 가시성 확인: 키보드만으로 탐색하는 동안, 포커스가 항상 화면에 보이고 논리적인 순서로 이동하는지 확인합니다. 보이지 않는 포커스나 예상치 못한 위치로 점프하는 포커스는 사용성 실패이며, 2.4.7과 2.4.3 위반일 가능성이 큽니다.

수정 방법

캔버스 드로잉 도구 — 잘못된 예

<!-- Freehand canvas with no keyboard alternative -->
<canvas id='drawingBoard' width='800' height='600'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'>
</canvas>

캔버스 드로잉 도구 — 올바른 예

<!-- Canvas with keyboard-accessible shape toolbar as alternative -->
<div role='toolbar' aria-label='Drawing tools'>
  <button id='addRect' onclick='insertShape("rectangle")'>Add Rectangle</button>
  <button id='addCircle' onclick='insertShape("circle")'>Add Circle</button>
  <button id='addLine' onclick='insertShape("line")'>Add Line</button>
  <label for='shapeColor'>Color</label>
  <input type='color' id='shapeColor' value='#000000'>
</div>
<canvas id='drawingBoard' width='800' height='600'
  aria-label='Drawing canvas — use toolbar above to add shapes'
  tabindex='0'
  onmousedown='startDraw(event)'
  onmousemove='draw(event)'
  onmouseup='endDraw()'
  onkeydown='handleCanvasKey(event)'>
</canvas>
<!-- handleCanvasKey enables arrow-key movement and Enter to place shapes -->

드래그 앤 드롭 리스트 재정렬 — 잘못된 예

<!-- List that only supports mouse drag for reordering -->
<ul id='sortableList'>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item One</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Two</li>
  <li draggable='true' ondragstart='dragStart(event)' ondragover='dragOver(event)'>Item Three</li>
</ul>

드래그 앤 드롭 리스트 재정렬 — 올바른 예

<!-- List with ARIA listbox pattern and keyboard reordering via arrow keys -->
<p id='reorderInstructions'>Tab to an item, press Space to grab it, use Up/Down arrows to move, press Space again to drop.</p>
<ul id='sortableList' role='listbox' aria-labelledby='reorderInstructions'>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item One</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Two</li>
  <li role='option' tabindex='0' aria-selected='false'
    draggable='true'
    ondragstart='dragStart(event)'
    ondragover='dragOver(event)'
    onkeydown='handleReorderKey(event)'>Item Three</li>
</ul>
<!-- handleReorderKey: Space = grab/drop, ArrowUp/Down = move, Escape = cancel -->

인터랙티브 지도 컨트롤 — 잘못된 예

<!-- Map that only responds to mouse pan and scroll-to-zoom -->
<div id='mapContainer' style='width:100%;height:400px;'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'>
</div>

인터랙티브 지도 컨트롤 — 올바른 예

<!-- Map with keyboard controls and accessible zoom/pan buttons -->
<div id='mapContainer' tabindex='0'
  role='application'
  aria-label='Interactive map. Use arrow keys to pan, plus and minus to zoom.'
  onwheel='zoomMap(event)'
  onmousedown='startPan(event)'
  onmousemove='pan(event)'
  onkeydown='handleMapKey(event)'>
</div>
<div role='group' aria-label='Map controls'>
  <button onclick='zoomIn()'>Zoom In</button>
  <button onclick='zoomOut()'>Zoom Out</button>
  <button onclick='panMap("north")'>Pan North</button>
  <button onclick='panMap("south")'>Pan South</button>
  <button onclick='panMap("east")'>Pan East</button>
  <button onclick='panMap("west")'>Pan West</button>
</div>
<!-- Arrow keys pan, + / - zoom, handleMapKey dispatches these actions -->

흔한 실수

WCAG 2.1.1의 경로 의존 예외가 여전히 적용된다고 가정함: 레벨 A에 익숙한 개발자는 자유형 드로잉이나 제스처 도구를 키보드 대체 수단 없이 구현하면서, 2.1.3이 이 예외를 명시적으로 제거했다는 사실을 인지하지 못하는 경우가 있습니다. 이 레벨에서는 경로에 민감한 기능을 포함해 모든 기능에 키보드 동등 기능이 있어야 합니다.
커스텀 인터랙티브 요소에 onclick과 onmousedown 핸들러만 연결함: <div>나 <span> 요소로 만든 커스텀 위젯이 마우스 이벤트만 수신하면 키보드로는 전혀 접근할 수 없습니다. 항상 마우스 이벤트 리스너와 함께 onkeydown 또는 onkeyup 핸들러를 추가하고, 요소에 tabindex='0'와 적절한 ARIA role을 부여해야 합니다.
탭 순서에 포함되어야 할 요소에 tabindex='-1' 사용: tabindex='-1'을 설정하면 요소가 순차적인 탭 순서에서 제거됩니다. 이는(로빙 tabindex를 사용하는 복합 위젯 내부처럼) 프로그램적으로 관리되는 요소에만 적합합니다. 독립적인 인터랙티브 컨트롤에 이를 적용하면 키보드로 접근할 수 없게 됩니다.
키보드 기반 재정렬 메커니즘 없이 드래그 앤 드롭 구현: SortableJS 같은 라이브러리나 커스텀 드래그 구현은 기본적으로 키보드 대체 수단을 제공하지 않는 경우가 많습니다. 개발자는 ARIA 드래그 앤 드롭 패턴을 구현하거나, 리스트 재정렬이 완전히 키보드로 조작 가능하도록 위/아래 화살표 키 재정렬 기능을 제공해야 합니다.
인터랙티브 컨트롤 표시를 위해 :hover CSS에만 의존: 드롭다운 서브메뉴, 툴팁 기반 액션 버튼, 호버 시에만 나타나는 컨트롤은 :focus와 :focus-within 상태도 처리하지 않는 한 키보드 사용자에게 접근할 수 없습니다. 키보드 사용자는 호버를 할 수 없으므로, 호버 전용 콘텐츠는 사실상 그들에게 숨겨진 것입니다.
동적 콘텐츠 변경 후 포커스를 관리하지 않음: 모달이 열리거나, 인라인 알림이 나타나거나, AJAX로 로드된 위젯이 기존 콘텐츠를 대체할 때, 포커스는 element.focus()를 사용해 새 콘텐츠로 프로그램적으로 이동해야 합니다. 이를 하지 않으면 키보드 사용자는 변화를 트리거한 위치에 그대로 남게 되고, 새 콘텐츠가 존재한다는 사실을 인지하지 못합니다.
onmousemove만 사용하는 커스텀 슬라이더 구현: 값 변경을 위해 마우스 위치를 추적하는 <div> 기반 범위형 슬라이더는 ARIA 슬라이더 패턴에 따라 ArrowLeft, ArrowRight, Home, End 키 처리를 구현해야 하며, 현재 값을 aria-valuenow, aria-valuemin, aria-valuemax로 노출해야 합니다.
iframe 내부에 키보드 포커스를 두고 빠져나올 방법을 제공하지 않음: 특히 지도, 결제 폼, 채팅 도구 같은 서드파티 위젯을 포함하는 임베디드 iframe은, 임베디드 콘텐츠 자체가 키보드 접근 가능하지 않고 Escape 키로 포커스를 부모 문서로 되돌리는 기능을 지원하지 않는 경우, 키보드 포커스를 가둬 버릴 수 있습니다.
캔버스 기반 데이터 시각화에 키보드 지원을 생략함: <canvas>에 렌더링된 차트와 그래프는, 캔버스 요소와 함께 접근 가능한 대안(데이터 테이블, ARIA가 적용된 SVG, 키보드로 탐색 가능한 데이터 포인트 등)이 제공되지 않는 한 키보드와 스크린 리더에 보이지 않습니다.
복합 위젯 키 패턴을 무시하고 Tab과 Enter로만 키보드 접근성을 테스트함: 메뉴, 트리, 그리드, 탭패널, 리스트박스 같은 많은 ARIA 위젯 패턴은 위젯 내부에서 화살표 키 내비게이션을 요구하며, 컴포넌트 전체에 탭 정지는 하나만 있어야 합니다(로빙 tabindex). Tab과 Enter만 테스트하면 이러한 복합 패턴의 실패를 발견하지 못하고, 잘못된 준수 인식을 낳게 됩니다.

터키 접근성 규제와의 관계

터키의 대통령령 2025/10은 2025년 6월 21일자, 관보 제32933호에 게재되었으며, 터키에서 운영되는 광범위한 공공 및 민간 기관을 대상으로 포괄적인 웹 및 모바일 접근성 프레임워크를 수립합니다. 이 대통령령은 WCAG 2.1 및 2.2에 부합하는 표준 준수를 의무화하며, 해당 기관이 장애인을 포함한 모든 사용자를 위해 디지털 서비스를 지각 가능하고, 조작 가능하며, 이해 가능하고, 견고하게 만들 것을 요구합니다.

이 규제의 적용 대상에는 모든 수준의 정부 공공 기관 및 기관, 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 의료 기관, 200,000명 이상의 가입자를 보유한 통신 회사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받아 운영하는 사립 학교가 포함됩니다. 이들 기관에게 레벨 A 및 레벨 AA 성공 기준 준수는 최소한의 법적 기준입니다.

WCAG 2.1.3 — Keyboard (No Exception)은 레벨 AAA 기준이므로, 대통령령에서 기본 법적 요구사항으로 명시적으로 의무화되지는 않습니다. 그러나 터키의 수백만 장애인 사용자를 위한 공평한 디지털 접근을 보장한다는 이 규제의 취지는 이 기준의 의도와 강하게 맞닿아 있습니다. 운동 장애 사용자를 위한 특화 서비스를 제공하거나, 보조 기술에 의존하는 시민이 사용하는 정부 포털을 운영하는 규제 대상 기관은 키보드 접근성에 대해 AAA 수준 준수를 추구하는 것이 바람직합니다.

WCAG 2.1.3 준수 달성은 규제 최소 기준을 넘어서는 최고 수준의 접근성 의지를 보여 줍니다. 가능한 가장 넓은 사용자층을 서비스하고자 하거나, 사회적 책임을 입증하고자 하거나, 더 높은 접근성 기준이 적용될 수 있는 유럽연합 디지털 시장에 참여하고자 하는 터키 기관에게, 예외 없는 완전한 키보드 조작 가능성을 구현하는 것은 경쟁력 측면에서도, 윤리적 측면에서도 이점입니다. 터키의 규제 환경이 발전하고 집행 메커니즘이 성숙해짐에 따라, 2.1.3과 같은 AAA 수준 기준을 조기에 도입한 기관은 향후 규제가 강화되더라도 비용이 많이 드는 사후 개선 없이 대응할 수 있는 유리한 위치를 선점하게 될 것입니다.