키보드와 포커스 관리

포커스를 받는 요소

키보드 사용자는 Tab과 Shift+Tab으로 포커스를 옮기고, Enter·Space·방향키로 조작합니다. 화면낭독기 사용자, 운동 장애로 마우스를 쓰기 어려운 사용자, 스위치 장치 사용자도 결국 키보드 포커스에 의존합니다. WCAG 2.1.1 키보드는 모든 기능을 키보드로 쓸 수 있을 것을 요구합니다.

다음 HTML 요소는 기본으로 포커스를 받고 키보드 동작도 내장되어 있습니다.

• <a href>, <area href>
• <button>, <input>(type="hidden" 제외), <select>, <textarea> — disabled가 아닐 때
• <summary>(<details> 안), <iframe>, controls가 있는 <audio>·<video>
• contenteditable 요소, 스크롤 가능한 영역(일부 브라우저)

<div>나 <span>에 role="button"을 주어도 포커스와 키보드 동작은 생기지 않습니다. ARIA는 의미만 바꾸고 동작은 바꾸지 않기 때문입니다. 가능하면 네이티브 요소를 쓰고, 부득이 커스텀 위젯을 만들면 tabindex와 키 이벤트를 직접 구현해야 합니다.

<div class="btn" role="button" onclick="save()">저장</div>

<button type="button" onclick="save()">저장</button>

tabindex 값의 의미

<!-- 커스텀 위젯을 Tab 순서에 넣기 -->
<div role="slider" tabindex="0" aria-valuemin="0" aria-valuemax="100" aria-valuenow="40" aria-label="볼륨"></div>

<!-- Tab 순서에는 없지만 스크립트로 포커스를 보낼 제목 -->
<h1 id="page-title" tabindex="-1">주문 완료</h1>

포커스를 받지 않아야 할 정적 요소(문단, 제목, 카드 전체)에 tabindex="0"을 넣지 마세요. Tab을 누를 때마다 조작할 수 없는 요소에 멈추게 되어 키보드 사용자가 피곤해지고, 화면낭독기 사용자는 그 요소를 조작할 수 있는 것으로 오해합니다.

복합 위젯: 로빙 tabindex와 aria-activedescendant

툴바·탭 목록·라디오 그룹·리스트박스·메뉴·트리·그리드처럼 여러 항목으로 이루어진 복합 위젯은 Tab 한 번으로 위젯에 들어가고, 안에서는 방향키로 항목을 옮기는 것이 APG 키보드 인터페이스 원칙입니다. 이렇게 하면 항목이 수십 개여도 Tab 한 번으로 위젯을 지나갈 수 있습니다. 위젯 안의 “현재 항목”을 관리하는 방법은 두 가지입니다.

데모 1: 로빙 tabindex 툴바

Tab으로 툴바에 들어간 뒤 ←/→ 방향키, Home/End로 버튼을 옮겨 보세요. 실시간 코드에서 tabindex 값이 따라 바뀝니다. 툴바를 나갔다 다시 들어오면 마지막으로 머문 버튼에 포커스가 돌아옵니다.

var items = toolbar.querySelectorAll('button');
function move(to) {
  items.forEach(function (b) { b.tabIndex = -1; });
  items[to].tabIndex = 0;   // 현재 항목만 Tab 순서에 남김
  items[to].focus();        // 실제 포커스 이동
}
toolbar.addEventListener('keydown', function (e) {
  var i = Array.prototype.indexOf.call(items, document.activeElement);
  if (e.key === 'ArrowRight') move((i + 1) % items.length);
  else if (e.key === 'ArrowLeft') move((i - 1 + items.length) % items.length);
  else if (e.key === 'Home') move(0);
  else if (e.key === 'End') move(items.length - 1);
  else return;
  e.preventDefault();
});

데모 2: aria-activedescendant 리스트박스

Tab으로 목록에 들어가 ↑/↓, Home/End로 옵션을 옮기고 Enter 또는 Space로 선택해 보세요. DOM 포커스는 목록(ul)에 머물고 aria-activedescendant 값만 바뀝니다.

포커스 이동과 복귀

화면 일부가 바뀔 때 포커스를 어디에 둘지 정하는 것이 키보드 접근성의 핵심입니다. 원칙은 “사용자가 다음에 할 일이 있는 곳으로 옮기고, 끝나면 원래 자리로 돌려 놓는다”입니다.

• 대화상자를 열 때: 대화상자 안의 첫 번째 조작 요소(또는 내용이 길면 제목이나 첫 문단, tabindex="-1")로 포커스를 옮깁니다.
• 대화상자를 닫을 때: 대화상자를 연 버튼으로 포커스를 돌려 줍니다. 그 버튼이 사라졌다면 논리적으로 이어지는 요소로 보냅니다.
• 요소를 삭제할 때: 포커스가 있던 요소가 DOM에서 사라지면 포커스가 <body>로 떨어져 사용자가 페이지 처음으로 돌아간 것처럼 됩니다. 삭제 전에 다음 항목이나 목록 제목으로 포커스를 옮깁니다.
• 폼 제출 오류: 오류 요약이나 첫 번째 오류 필드로 이동합니다(폼 접근성).
• SPA 화면 전환: 새 화면의 <h1> 등으로 이동합니다(동적 콘텐츠와 SPA).

var opener = null;
function openDialog(dlg) {
  opener = document.activeElement;          // 연 요소 기억
  dlg.showModal();                          // <dialog>는 첫 조작 요소로 포커스를 자동 이동
}
function closeDialog(dlg) {
  dlg.close();
  if (opener && document.contains(opener)) opener.focus();   // 원래 자리로 복귀
}

포커스 트랩과 inert

모달 대화상자가 열려 있는 동안에는 Tab 포커스가 대화상자 밖으로 나가면 안 됩니다. 뒤쪽 페이지는 시각적으로 가려졌으므로, 포커스가 그곳에 가면 사용자는 보이지 않는 요소를 조작하게 됩니다. 이렇게 포커스를 특정 영역 안에서만 돌게 하는 것을 포커스 트랩이라고 합니다.

반면, 사용자가 빠져나올 방법이 없는 트랩은 심각한 접근성 문제입니다. WCAG 2.1.2 키보드 트랩 없음은 키보드로 들어간 곳에서 키보드로 나올 수 있어야 한다고 요구합니다. 모달은 Esc와 닫기 버튼으로 반드시 닫을 수 있어야 합니다.

현재 가장 권장하는 방법은 네이티브 기능을 쓰는 것입니다.

• <dialog> + showModal(): 대화상자 밖의 콘텐츠를 자동으로 비활성(inert) 상태로 만들고, Esc 닫기와 포커스 이동을 기본 제공합니다. dialog 역할과 aria-modal 의미도 브라우저가 처리합니다.
• inert 속성: 요소와 그 하위 전체를 포커스·클릭·찾기(Ctrl+F)·접근성 트리에서 제외합니다. 커스텀 모달을 만들 때 대화상자 밖의 형제 요소(<header>, <main>, <footer>)에 inert를 주면 별도의 Tab 순환 스크립트 없이 트랩이 만들어집니다.

<body>
  <header inert>...</header>
  <main inert>...</main>
  <div role="dialog" aria-modal="true" aria-labelledby="dlg-h">
    <h2 id="dlg-h">로그아웃할까요?</h2>
    <button type="button">로그아웃</button>
    <button type="button">취소</button>
  </div>
</body>

<main aria-hidden="true">
  <a href="/cart">장바구니</a>  <!-- 여전히 Tab으로 포커스됨 -->
</main>

<main inert>
  <a href="/cart">장바구니</a>  <!-- 포커스·클릭 불가, 트리에서도 제외 -->
</main>

각 숨김 방법의 차이는 콘텐츠 숨기기 문서에서 비교합니다. 전체 구현은 대화상자 패턴을 참고하세요.

포커스 표시

키보드 사용자는 포커스 표시(보통 외곽선)를 보고 지금 어디에 있는지 압니다. WCAG 2.4.7 초점 표시(Focus Visible, AA)는 키보드로 조작할 수 있는 모든 요소에 포커스 표시가 보일 것을 요구합니다. 가장 흔한 위반은 디자인을 이유로 outline: none을 주고 대체 스타일을 넣지 않는 것입니다.

*:focus { outline: none; }

:focus-visible {
  outline: 3px solid #1a5fd0;
  outline-offset: 2px;
}

:focus-visible은 브라우저가 “포커스 표시가 필요하다”고 판단할 때(주로 키보드 조작)만 적용되므로, 마우스 클릭 시 외곽선이 거슬린다는 디자인 요구와 접근성을 함께 만족시킬 수 있습니다.

WCAG 2.2에서는 관련 기준이 추가되었습니다.

• 2.4.11 초점이 가려지지 않음(최소, AA) — WCAG 2.2 신규. 포커스를 받은 요소가 고정 헤더·쿠키 배너·채팅 버튼 같은 작성자 콘텐츠에 완전히 가려지면 안 됩니다. scroll-padding-top으로 고정 헤더 높이만큼 여백을 주면 도움이 됩니다.
• 2.4.12 초점이 가려지지 않음(향상, AAA) — 일부도 가려지면 안 됩니다.
• 2.4.13 초점 모양(AAA) — 포커스 표시의 크기(2px 두께 외곽선 이상의 면적)와 대비(3:1 이상)를 요구합니다.
• 1.4.11 비텍스트 대비(AA) — 포커스 표시처럼 상태를 나타내는 시각 요소는 주변과 3:1 이상 대비가 필요합니다.

html { scroll-padding-top: 80px; }   /* 고정 헤더 높이만큼 */
:focus-visible { outline: 3px solid #1a5fd0; outline-offset: 2px; }
@media (forced-colors: active) {
  :focus-visible { outline-color: Highlight; }   /* 고대비 모드 */
}

점검 방법

1. 마우스를 치우고 Tab만으로 페이지 처음부터 끝까지 이동합니다. 모든 조작 요소에 도달하는지, 순서가 화면 읽기 순서와 맞는지 확인합니다.
2. 포커스가 갈 때마다 위치가 눈에 보이는지, 고정 헤더 등에 가려지지 않는지 확인합니다.
3. 각 위젯을 Enter, Space, 방향키, Esc로 조작해 봅니다. 위젯별 키 동작은 탭, 메뉴 버튼 등 패턴 문서를 참고합니다.
4. 대화상자·메뉴를 열고 닫은 뒤 포커스가 원래 자리로 돌아오는지 확인합니다.
5. 포커스가 빠져나올 수 없는 곳(키보드 트랩)이 없는지 확인합니다.