키보드로 페이지 쓰기

마우스를 빼고 Tab 키를 눌러 보세요. 링크, 버튼, 입력 칸이 읽는 순서대로 하나씩 표시되어야 합니다.

키보드로 웹을 쓰는 사람들

마우스를 한 번도 만지지 않고 웹을 쓰는 사람이 많습니다. 손이 떨려 마우스를 안정되게 쥐기 어려운 사람이 있고, 스위치나 입에 무는 막대를 쓰는 사람, 말을 하면 키 입력을 대신 보내 주는 음성 인식을 쓰는 사람도 있습니다. 그리고 화면 낭독기 사용자도 대부분 키보드로 페이지 안을 이동합니다. WCAG 2.2 성공 기준 2.1.1 「키보드」(A 수준)는 페이지에 있는 모든 기능이 키보드만으로도 작동해야 한다고 정합니다. 2.1.2 「키보드 함정 없음」은 키보드 초점이 페이지의 어떤 부분 안으로 들어갈 수 있다면, 키보드로 그 부분에서 다시 빠져나올 수도 있어야 한다고 덧붙입니다.

이미 제대로 작동하는 요소를 쓰기

href가 있는 링크, button, input, select, textarea는 따로 손대지 않아도 처음부터 초점을 받을 수 있고, 알맞은 키를 누르면 반응합니다. 클릭 처리기를 단 div는 그렇지 않습니다. Tab 키로는 닿지 않고, Enter를 눌러도 아무 일도 일어나지 않으며, 화면 낭독기도 그것을 버튼이라고 알려 주지 않습니다. 이에 대한 MDN의 조언은 아주 분명합니다. tabindex로 div를 버튼처럼 만들지 말고, 역할과 키보드 동작이 들어 있는 button 요소를 그대로 쓰라는 것입니다.

초점 순서와 tabindex

Tab 키로 이동하는 순서는 HTML 소스 안에 요소들이 놓인 순서를 그대로 따릅니다. 2.4.3 「초점 순서」는 이 순서가 페이지의 뜻과 쓰임새를 해치지 않아야 한다고 하므로, 이동 순서가 이상하다면 HTML 안의 배치를 바꾸는 것이 가장 간단한 해결책입니다. MDN은 tabindex 값을 세 가지 갈래로 나눠 설명합니다. 0은 요소를 보통의 Tab 순서 안에 넣습니다. 음수(보통 -1)는 요소를 Tab 순서에서 빼 버리지만 스크립트로 focus()를 부를 수는 있게 해서, 대화 상자나 오류 메시지를 만들 때 쓸모가 있습니다. 양수는 그 요소를 다른 모든 것보다 앞에 억지로 세웁니다. 그런데 양수는 순서를 따라가기 어렵게 하므로 MDN은 0과 -1만 쓰라고 권합니다.

지금 어디에 있는지 보이게

키보드 사용자는 지금 어느 요소에 초점이 있는지 눈으로 볼 수 있어야 합니다. 2.4.7 「초점 표시」(AA 수준)는 초점 표시가 보이기를 요구하므로, 그 자리를 대신할 다른 표시 없이 outline: none만 쓴 스타일 규칙은 미달입니다. WCAG 2.2는 이와 관련된 기준 두 가지를 새로 넣었습니다. 2.4.11 「초점이 가려지지 않음(최소)」(AA 수준)은 초점을 받은 항목이 고정된 바닥글이나 쿠키 안내처럼 페이지를 만든 사람이 넣은 것에 완전히 가려지면 안 된다고 합니다. 역시 AA인 2.5.8 「대상 크기(최소)」는 클릭하거나 손가락으로 누르는 대상이 가로세로 24 CSS 픽셀 이상이거나 주위에 충분한 간격이 있기를 요구합니다.

큰 도움이 되는 방법이 한 가지 더 있습니다. 바로 「건너뛰기 링크」입니다. 메뉴가 긴 사이트에서는 키보드 사용자가 어느 페이지에 가든 메뉴 항목을 하나하나 Tab으로 지나가야 합니다. 페이지 맨 앞에 본문으로 가는 링크를 두면 키를 한 번만 눌러 메뉴 전체를 건너뛸 수 있습니다. 이 링크는 초점을 받기 전까지는 화면에서 보이지 않게 숨겨 둘 수 있습니다.

키보드 시험을 하는 데는 2분이면 충분합니다. 먼저 주소창을 누른 다음, Tab 키를 계속 눌러 페이지 맨 끝까지 가 봅니다. 모든 컨트롤에 빠짐없이 닿는지, 순서가 읽는 순서와 같은지, 초점 위치가 언제나 보이는지, Enter와 Space가 마우스 클릭과 같은 일을 하는지 확인합니다. 그다음 Shift+Tab을 눌러 거꾸로 돌아와 봅니다. 끝까지 닿지 않는 컨트롤이 있거나 초점이 사라져 버리는 자리가 있다면, 그것은 고쳐야 할 결함입니다.