키보드·리모컨·스위치로 인터랙티브 필름을 동등하게 조작하는 방법
클릭 전용 선택을 키보드, TV 리모컨, 스위치 제어로 같은 결과에 도달하는 과업으로 바꾸고 이동·확인·취소·오입력·기기 전환을 검수합니다.

들어가며
키보드, 리모컨, 스위치를 서로 다른 부가 기능으로 만들지 않습니다. 선택에 도달하기, 확인하기, 뒤로 가기, 재생 제어라는 네 과업을 먼저 정의하고 모든 방식이 같은 이야기 결과를 내게 합니다.
인터랙티브 필름 접근성은 공개 직전에 자막만 확인한다고 끝나지 않습니다. 선택 화면, 재생 제어, 분기 상태, 영상과 음향이 하나의 경험을 이룹니다. 어느 한 층이라도 인지하거나 조작하거나 이해할 수 없으면 시청자는 이야기를 계속할 방법을 잃습니다. WCAG 2.2는 웹 콘텐츠를 인식 가능하고, 운용 가능하고, 이해 가능하고, 견고하게 만드는 원칙을 제시합니다. 이 글은 관련 지침을 인터랙티브 필름 제작 방법으로 옮긴 것입니다. 글 하나를 따랐다고 적합성이 증명되는 것은 아니며, 배포 플랫폼과 대상 시장, 장애인 사용자 테스트 요구를 별도로 확인해야 합니다.
합격과 불합격을 판정할 수 있는 경험 약속을 쓴다
브라우저에서는 마우스, TV에서는 방향키, 스위치 사용자는 순차 스캔으로 첫 선택을 조작합니다. 공통 포커스 시작점, 순환, 확인 규칙이 없으면 같은 노드가 기기마다 다른 조작성으로 나타납니다.
예시는 가상의 단편 영화 《안개 항구에서 온 편지》를 사용합니다. 시청자는 밤의 항구에서 바뀐 편지를 조사하고 창고, 대합실, 등대 중 어디로 갈지 선택합니다. 인물, 경로, 테스트 기록, 자산 ID는 모두 교육용 창작물입니다. 실제 사용자 사례나 완료된 테스트 결과가 아니며 DramaFork가 자동으로 제공하는 기능도 아닙니다.
먼저 경험 약속과 실패 조건을 한 문장씩 씁니다. 약속에는 누가 어떤 기기와 상황에서 어떤 일을 완료해야 하는지 포함합니다. 실패 조건은 출시를 멈출 지점입니다. “키보드만으로 모든 선택을 완료할 수 있다”는 검증할 수 있지만 “키보드 친화적이다”는 검증하기 어렵습니다. 방향 입력은 이동, 확인은 실행, 뒤로는 메뉴 닫기로 정합니다. 스캔 방식에는 명확한 정지와 한 개 스위치 확인을 둡니다. 기기를 바꿔도 현재 포커스를 유지하고 길게 누르기, 반복, 실수 입력의 처리도 정의합니다.
요구사항, 구현, 증거를 한 표로 연결한다
| 항목 | 확인할 질문 | 증거 |
|---|---|---|
| 시청자 과업 | 무엇을 인지하고 결정하고 제어해야 하는가 | 과업과 사용 상황을 적은 문장 |
| 상호작용 규칙 | 기본 방식과 대체 방식이 같은 결과에 도달하는가 | 입력, 포커스, 시간, 표현 규칙 |
| 분기 영향 | 설정 변경, 되돌리기, 재진입이 이야기 상태를 보존하는가 | 진입, 종료, 유지 상태 기록 |
| 검수 | 누가 어떤 기기에서 검사하고 실패를 어디로 돌려보내는가 | 경로 ID, 조작 기록, 담당자 |
H02에는 창고와 대합실 선택이 있습니다. 키보드는 Tab이나 화살표, 리모컨은 좌우, 스캔은 고정 순서로 이동합니다. 세 방식 모두 같은 destination 상태를 기록하고 같은 선택 접수 피드백을 받습니다.
네 항목은 같은 버전을 참조해야 합니다. 화면 시안만 바꾸면 이전 결함이 해결됐는지 알 수 없고, 코드만 바꾸면 “컨트롤이 반응한다”를 “시청자가 이해했다”로 잘못 해석할 수 있습니다. 편집, 상호작용 설계, 개발, QA가 인수하는 것은 정지 화면이 아니라 반복해서 재현할 수 있는 경험입니다.
다섯 단계로 제작 흐름에 넣는다
첫째, 주요 경로, 짧은 경로, 되돌아가는 경로, 무입력 경로를 목록화하고 모든 선택과 재생 제어, 필수 정보를 표시합니다. 둘째, 각 과업에 기본 방식과 대체 방식을 지정하고 같은 서사 결과에 도달하게 합니다. 셋째, 규칙을 안정적인 장면 ID, 자산 ID, 상태 필드에 연결해 문구 수정으로 추적성이 깨지지 않게 합니다.
넷째, 마무리 작업 전에 저비용 검사를 합니다. 키보드만 사용하기, 글자 확대하기, 움직임 줄이기, 일시 정지 후 돌아오기를 각각 실행합니다. 다섯째, 여러 기기와 보조 기술로 확인하면서 단계, 예상 결과, 실제 결과, 증거 위치를 남깁니다. 기기, 행동, 반복 입력, 취소 방식, 피드백을 입력 맵에 적습니다. 마우스를 분리하고 각 방식만으로 결말까지 진행합니다. 중간에 두 번 기기를 바꾸며 포커스, 일시 정지, 선택 경로가 유지되는지 확인합니다.
좋은 기록은 “문제없어 보임”이라고 쓰지 않습니다. “H02로 진입해 대체 설정을 켜고 왼쪽 행동을 선택한 뒤 clue_letter=true가 기록되고 H03 첫 대사가 이를 반영하는지 확인한다”라고 씁니다. 진입, 행동, 피드백, 종료를 함께 다루므로 실패가 입력, 표현, 이야기 상태 중 어디에 있는지 찾을 수 있습니다.
실패는 시스템 경계에서 자주 발생한다
포커스 관리 없이 키 이벤트만 넣으면 실행은 되지만 찾을 수 없는 컨트롤이 됩니다. 화면 순서와 반대인 리모컨 이동, 일시 정지나 취소가 없는 스캔도 실패입니다. 사용자 실수가 아니라 입력 경로 결함으로 기록합니다.
접근성 설정이 깊은 메뉴에 숨겨져 있으면 필요한 시청자가 그곳까지 도달하지 못할 수 있습니다. 시작 화면, 첫 선택, 일시 정지 메뉴에 발견하기 쉬운 진입점을 둡니다. 설정을 바꾸면 즉시 인지 가능한 피드백을 주고 다음 노드에서도 유지합니다. 다시 불러올 때 사라진다면 공개 전에 고치거나 제한을 분명히 알립니다.
자동 검사는 이름 누락, 일부 대비 문제, 일부 포커스 결함을 찾을 수 있습니다. 그러나 선택 문구가 이해하기 쉬운지, 음성 해설이 다른 분기의 비밀을 누설하는지, 일시 정지가 서사 이해를 해치는지는 판단할 수 없습니다. 경로 단위 수동 검사와 장애인 사용자의 참여가 필요합니다. 콘텐츠 문제는 편집, 미디어 문제는 음향이나 후반 작업, 상태 문제는 개발, 범위 충돌은 책임자에게 돌려보냅니다.
출시 기준은 전체 절차를 포함해야 한다
각 방식으로 도입, 선택, 일시 정지, 재개, 결말을 완료하고 키보드 함정이 없으며 기기 전환이 이야기 상태를 바꾸지 않고 선택 피드백을 시각과 음향 또는 보조 기술로 확인할 수 있어야 합니다.
최소 출시 자료에는 기능 범위, 경로 목록, 설정 기본값, 다섯 언어의 인터페이스 문구, 검사한 기기와 입력 방식, 알려진 제한, 결함 담당자, 시작부터 결말까지의 전체 기록을 포함합니다. W3C 자료는 표준과 해설을 제공합니다. 이 글의 표와 노드 이름, 가상 사례는 편집 방법이며 W3C가 요구하는 고정 양식이 아닙니다.
브라우저, TV 시스템, 적응형 스위치는 서로 다른 이벤트를 보냅니다. 이 방법은 공통 과업과 증거를 정의할 뿐 범용 키 맵을 보장하지 않습니다. 실제 검사한 하드웨어와 버전을 기록합니다.
마지막으로 제작에 참여하지 않은 사람이 기록만 보고 경험을 재현하게 합니다. 무엇을 눌러야 하는지, 시간이 얼마나 남았는지, 신호가 무엇을 뜻하는지, 재개하면 어디서 시작하는지 다시 물어야 한다면 인수인계가 끝나지 않은 것입니다. 답을 규칙과 증거에 반영한 뒤 공개합니다.
참고 자료: W3C Understanding SC 2.1.1: Keyboard, W3C Understanding SC 2.5.8: Target Size (Minimum).






