접근성 점검 중에 가장 값싸고 가장 많이 잡히는 것이 Tab 키로 한 바퀴 도는 것입니다. 도구도, 설치도, 전문 지식도 필요 없습니다. 마우스에서 손을 떼고 Tab 을 계속 누르면서 두 가지만 봅니다 — 지금 어디 있는지 보이는가, 그리고 그 이동이 화면에서 자연스러운 순서인가.
순서는 화면이 아니라 문서를 따릅니다
초점이 이동하는 순서는 우리가 보는 배치가 아니라 HTML 에 적힌 순서를 따릅니다. 평소에는 둘이 같아서 문제가 드러나지 않습니다. 갈라지는 것은 CSS 가 시각적 순서를 바꿨을 때입니다.
마지막 줄이 특히 조용한 사고입니다. 오프캔버스 메뉴를 화면 밖으로 밀어 두기만 하고 닫힌 상태를 제대로 감추지 않으면, 메뉴는 닫혀 있는데 그 안의 링크들이 여전히 초점을 받습니다. 사용자 눈에는 Tab 을 열 번 눌러도 아무 데도 가지 않는 것처럼 보입니다.
디자이너가 결정하는 부분
이 문제는 구현 실수처럼 보이지만, 시작점은 대개 시안입니다. 데스크톱과 모바일에서 블록의 순서를 다르게 그리면 구현은 CSS 로 순서를 바꿀 수밖에 없고, 그 순간 두 순서가 갈라집니다.
그래서 시안을 만들 때 읽는 순서를 먼저 정합니다. 이 화면을 위에서 아래로 한 줄로 읽는다면 어떤 순서인가 — 그것이 문서 순서가 되고, 반응형 배치는 그 순서를 흔들지 않는 선에서 만듭니다. 순서를 꼭 바꿔야 한다면 그 사실을 핸드오프에 적어 두면 됩니다. 미리 말한 예외는 사고가 아닙니다.
갇히는 자리와 건너뛰는 자리
한 바퀴 도는 동안 두 가지를 더 봅니다. 갇히는 곳과 건너뛰어지는 곳입니다.
마지막 줄의 “본문으로 건너뛰기” 링크는 시안에서 거의 그려지지 않지만 효과가 큽니다. 메뉴 항목이 스무 개인 사이트에서, 페이지를 옮길 때마다 스무 번씩 Tab 을 눌러 본문에 도달하는 상황을 없애 줍니다. 평소에는 보이지 않다가 초점을 받으면 나타나게 만들면 디자인을 해치지도 않습니다.
레이아웃 구조가 만드는 문제들은 테마 · 플러그인 아카이브에서 더 다루고, 이미 운영 중인 사이트의 이런 문제를 한 번에 정리하고 싶다면 최적화 지원 사업의 점검 범위에 포함돼 있습니다.
다음 회차
키보드로 가장 오래 머무는 화면이 폼입니다. 다음 회차는 라벨과 오류 메시지인데, 플레이스홀더로 라벨을 대신한 폼이 왜 중간에 사람을 잃는지부터 봅니다.