키보드 접근성과 포커스 관리

왜 키보드인가

키보드만으로 모든 콘텐츠와 기능에 닿을 수 있어야 한다(WCAG 2.1.1 Keyboard, A). 손 떨림이나 마비로 마우스를 정밀하게 못 쓰는 사람, 화면을 보지 않고 탐색하는 시각장애인, 스위치·음성 제어·한 손 키보드처럼 키보드 신호를 흉내 내는 장치 사용자가 모두 키보드 인터페이스에 기댄다. 효율 때문에 키보드를 쓰는 사람도 많다. 장애 유형별 사용 방식은 장애 유형별 웹 사용에 있다.

휴대폰·태블릿에 외장 키보드를 연결해 쓰는 사용자도 있으니 모바일에서도 키보드로 확인한다. 마우스가 고장 났거나 손목을 다친 사람처럼 일시적으로 키보드에 기대는 사용자도 있다.

포커스(focus)는 지금 키보드 입력을 받는 화면 요소다. 링크·버튼·폼 컨트롤처럼 원래 포커스되는 요소는 Tab 이동과 기본 키 처리가 내장돼 있다.

표준 키 조작

키보드 테스트는 아래 표가 기준이다. 커스텀 위젯도 이 관례를 따라야 사용자가 새로 배우지 않는다. 위젯별 세부 키는 W3C ARIA Authoring Practices Guide(APG)에 있다.

포커스 표시

Tab으로 닿은 요소는 키보드 포커스를 갖는다. 앞이 보이는 키보드 사용자에게 포커스 표시는 마우스 커서와 같다. 없으면 지금 어디 있는지 모른다.

관련 WCAG 기준

2.4.11에서 사용자가 옮길 수 있는 창은 처음 위치만 본다. 사용자가 직접 연 내용(펼친 메뉴 등)은 포커스를 옮기지 않고 닫을 수 있으면 가려도 된다.

CSS로 지키기

outline: none(또는 outline: 0)으로 기본 표시를 지우지 않는다. 디자인 때문에 바꾸고 싶으면 지우지 말고 더 잘 보이게 바꾼다. 기준은 :focus-visible이다. 브라우저가 「지금 포커스를 보여 줘야 하는가」를 판단해, 키보드로 이동할 때와 텍스트 입력 칸에는 맞고 마우스로 버튼을 누를 때는 맞지 않는다. 주요 브라우저가 모두 지원한다(Chrome 86, Firefox 85, Safari 15.4부터).

/* 기본 표시를 지우지 않고 바꾼다 */
:focus-visible {
  outline: 3px solid #1a5fff;
  outline-offset: 2px;
}
 
/* 마우스 클릭 때만 표시를 숨기고 싶다면 이렇게 좁힌다 */
:focus:not(:focus-visible) {
  outline: none;
}
 
/* 고정 헤더·푸터가 포커스를 가리지 않게 (2.4.11) */
html {
  scroll-padding-top: 72px;    /* 고정 헤더 높이 */
  scroll-padding-bottom: 56px; /* 고정 푸터 높이 */
}

• outline은 고대비 모드(forced-colors)에서도 남는다. box-shadow만으로 만든 포커스 표시는 고대비 모드에서 사라지니 투명 outline을 함께 둔다.
• outline은 박스 크기를 바꾸지 않고 margin 영역에 겹쳐 그려지며, 지금은 주요 브라우저에서 border-radius를 따라 둥글게 그려진다.
• 스킵 링크 대상 <main tabindex="-1">에 포커스 링이 보이는 것은 정상이다.
• 링크·버튼의 배경색을 바꾸는 식으로 표시를 더 키워도 좋다. 색만 바꾸지 말고 모양 변화를 함께 준다(색과 움직임의 접근성).
• 포커스 표시는 놓이는 배경에 맞춰 보이게 한다. 흰 바탕에는 파란 표시, 파란 바탕에는 흰 표시처럼 영역마다 바꿔도 된다.
• 요소 종류마다 모양을 달리해도 된다(본문 링크는 점선 밑줄, 버튼은 둥근 테두리). 다만 종류가 너무 많으면 헷갈리니 몇 가지로 정리한다.

포커스 순서

포커스 순서와 스크린 리더의 읽는 순서는 소스 코드 순서가 정한다(2.4.3 Focus Order, A). 화면 흐름(보통 위→아래, 왼쪽→오른쪽)과 같아야 한다.

긴 내비게이션을 매번 Tab으로 지나야 하면 운동 장애 사용자에게 특히 힘들다. 건너뛰기 링크, 제목 구조, 랜드마크로 지름길을 준다(접근 가능한 페이지 구조).

tabindex

• tabindex="0"을 줬다면 그 요소다운 키 조작을 함께 구현한다. 버튼처럼 보이면 Enter와 Space에 모두 반응해야 하고, role과 상태(aria-expanded 등)로 무엇인지 알려야 한다(ARIA와 접근 가능한 이름).
• 링크·버튼처럼 원래 포커스되는 요소에 -1을 주면 키보드 사용자가 닿을 수 없다. 마우스로 누를 수 있는 것에는 주지 않는다.

위젯 안의 포커스: 로빙 tabindex

탭 목록, 툴바, 라디오 그룹, 메뉴처럼 항목이 여럿인 위젯은 위젯 전체를 Tab 정지점 하나로 두고 안에서는 방향키로 움직인다. 지금 항목만 tabindex="0", 나머지는 -1로 두고 방향키를 누를 때마다 값을 옮기는 방식을 로빙 tabindex(roving tabindex)라 한다. 콤보박스·리스트박스처럼 포커스는 입력 칸에 두고 활성 항목만 가리키는 aria-activedescendant 방식도 있다. 탭 구현 예는 접근 가능한 위젯에 있다.

키보드 트랩과 모달

키보드로 들어간 곳에서는 키보드로 나올 수 있어야 한다(2.1.2 No Keyboard Trap, A). 화살표·Tab·Esc 같은 표준 방법이 아닌 키가 필요하면 그 방법을 알린다.

반대로 모달 대화 상자는 의도적으로 포커스를 가둔다. 뒤 페이지는 가려져 있으니 Tab이 그쪽으로 빠지면 안 된다. 그래도 Esc로 닫을 수 있어야 하고, 닫히면 연 버튼으로 포커스를 돌려준다.

<button id="open">설정 열기</button>
 
<dialog id="settings" aria-labelledby="settings-title">
  <h2 id="settings-title">설정</h2>
  …
  <button id="close">닫기</button>
</dialog>
 
<script>
  const dialog = document.getElementById('settings');
  const opener = document.getElementById('open');
  opener.addEventListener('click', () => dialog.showModal());
  document.getElementById('close').addEventListener('click', () => dialog.close());
  // Esc로 닫혀도 close 이벤트가 온다
  dialog.addEventListener('close', () => opener.focus());
</script>

inert는 오프캔버스 메뉴, 화면 밖으로 밀어 둔 패널, 로딩 중인 영역처럼 보이지 않거나 지금 쓰면 안 되는 영역에도 쓴다. 비모달 대화 상자는 포커스를 가두지 않고, 포커스를 잃으면 닫히는 편이 자연스럽다.

단축키

링크와 버튼을 가려 쓴다

마크업이 맞아도 스크립트가 마우스로만 되는 동작을 붙이면 키보드 사용자에게 기능이 사라진다. 가장 흔한 원인은 링크·버튼이 아닌 요소에 동작을 붙이는 것이다.

<!-- 나쁨: 포커스·키 처리·이름을 모두 직접 만들어야 한다 -->
<div role="button" tabindex="0" onclick="save()">저장</div>
 
<!-- 좋음 -->
<button type="button" onclick="save()">저장</button>

장치 독립 이벤트

요소를 맞게 골랐다면 이벤트도 장치 독립으로 고른다. 장치 독립 이벤트를 쓰거나, 장치 의존 이벤트를 쓸 때는 키보드 쪽도 함께 붙인다. 키 판정은 event.key로 한다(DOM 이벤트).

호버·포커스로 나타나는 내용은 WCAG 1.4.13 Content on Hover or Focus(AA)도 지킨다. Esc 등으로 닫을 수 있고, 포인터를 그 위로 옮겨도 사라지지 않고, 사용자가 치우기 전까지 유지돼야 한다.

깊은 드롭다운 메뉴는 키보드로 다 열 수 있게 만드는 대신, 상위 항목을 일반 링크로 두고 하위 목록이 있는 랜딩 페이지로 보내는 편이 더 쓰기 쉬울 때가 많다.

동적 콘텐츠와 포커스

SPA의 라우트 전환

SPA는 index.html 하나로 화면을 바꾸므로 브라우저가 새 페이지를 연 것처럼 처리해 주지 않는다. 스크린 리더 사용자는 페이지 제목이 바뀌는 것으로 이동을 알아채는데, 제목도 포커스도 그대로 남는다. 팀이 정해야 할 것은 두 가지다.

어느 쪽이 맞는지는 프레임워크와 화면 구성에 따라 다르다. 정했으면 사이트 전체에서 같게 한다. 라이브 영역 알림 도구는 ARIA와 접근 가능한 이름에 있다.

// 화면 전환 뒤
const heading = document.querySelector('main h1');
heading.setAttribute('tabindex', '-1');
heading.focus();

CSS만으로도 드롭다운·애니메이션 같은 동적 표현을 만들 수 있지만, 스크린 리더는 CSS를 대부분 무시한다. CSS로 내용이나 기능을 전달했다면 보조 기술로 꼭 확인한다.

JavaScript에 기대도 되나

WCAG 2는 JavaScript를 요구해도 된다. 대신 스크립트로 만든 화면 자체가 접근 가능해야 한다. 「장애인은 JavaScript를 끈다」는 오해다. 스크린 리더 사용자도 대부분 JavaScript를 켜 둔 채 쓴다.

스크립트 없이는 동작하지 않는데 동작하는 것처럼 보이는 버튼과 링크는 만들지 않는다.

스크립트로 화면을 바꿀 때 지킬 것도 있다.

키보드로 점검하기

1. 마우스를 치우고 Tab·Shift+Tab으로 페이지 끝까지 간다.
2. 포커스 표시가 늘 보이고, 고정 헤더·배너에 완전히 가려지는 곳이 없는지 본다.
3. 순서가 화면 흐름과 맞는지, 쓸모없는 정지점이 없는지 본다.
4. 마우스로 되는 모든 기능(메뉴, 툴팁, 드래그, 위젯)을 키보드로 해 본다.
5. 대화 상자를 열고 닫으며 포커스가 들어가고 돌아오는지, 갇히지 않는지 본다.

도구와 전체 평가 순서는 접근성 평가 방법과 도구에 있다.

정리

• 모든 기능은 키보드만으로 쓸 수 있고, 들어간 곳에서 나올 수 있어야 한다.
• 포커스 표시는 지우지 말고 :focus-visible로 바꾸며, 고정 요소에 가려지지 않게 scroll-padding을 둔다(2.4.11).
• 순서는 소스가 정한다. tabindex는 0과 -1만 쓰고, 위젯 안은 로빙 tabindex로 방향키 이동을 만든다.
• 모달은 <dialog>의 showModal()과 inert로 만들고, 닫으면 포커스를 돌려준다.
• 이벤트는 장치 독립으로, 화면이 바뀌면 포커스를 의도적으로 옮긴다.

관련 노트: ARIA와 접근 가능한 이름, 접근 가능한 위젯: 펼침·탭·캐러셀, 웹 접근성, WCAG와 POUR 원칙, 접근 가능한 페이지 구조, DOM 이벤트, 포커스 속성과 details·dialog, 커서와 포인터 입력, 마우스·포인터·키보드 이벤트