마우스 없이 써보면, 보입니다.

입사하고 얼마 안 됐을 때, QA 담당자분이 손목 부상으로 한동안 마우스를 못 쓰셨습니다. 키보드만으로 우리 관리자 화면을 쓰시다가 “이 버튼은 어떻게 누르냐”고 물어보셨는데, 저는 한참을 대답 못 했습니다. 제가 만든 모달의 닫기 버튼에 Tab으로 도달할 방법이 없었거든요. 그날 이후로 저는 새 화면이 나오면 마우스를 서랍에 넣고 키보드만으로 끝까지 써봅니다. 그게 제 첫 번째 테스트입니다.

포커스 링을 끄면, 무슨 일이 벌어질까요?

말로 하면 잘 안 와닿습니다. 아래 위젯을 직접 써보세요. ‘다음 요소로 포커스’를 누르면 포커스가 한 칸씩 이동합니다. 그다음 ‘링 끄기’를 켜고 다시 눌러보세요. 똑같이 포커스는 움직이는데, 내가 지금 어디에 있는지 보이지 않습니다.

링을 끈 상태가 바로, outline:none 한 줄이 만들어내는 세상입니다. 디자이너는 “파란 테두리가 지저분하다”고 하고, 저도 그 마음을 압니다. 하지만 마우스 없이 Tab으로만 사이트를 쓰는 사람에게 포커스 링은 ‘내가 지금 여기 있다’는 유일한 표시입니다. 그래서 저는 지우는 대신 :focus-visible로 브랜드 색에 맞춰 다시 그립니다. 그러면 마우스로 클릭할 때는 안 보이고, 키보드로 이동할 때만 깔끔하게 나타납니다. 멋과 배려를 둘 다 가져가는 방법입니다.

마우스가 없는 사람도 전 기능을 쓸 수 있나요?

이게 접근성의 1번입니다. 메뉴·모달·탭·드롭다운·슬라이더, 마우스로 되는 모든 것이 키보드로도 돼야 합니다. Tab으로 도달하고, Enter·Space로 실행하고, Esc로 닫히고, 화살표로 이동합니다. 제가 가장 자주 잡는 버그가 ‘열리는데 안 닫히는 모달’과 ‘Tab이 화면 밖으로 새는 팝업’입니다. 포커스가 갇혀야 할 곳에서 새면 사용자는 그대로 미아가 됩니다. 그래서 모달을 만들 때는 포커스 트랩과 Esc 닫기를 항상 같이 넣습니다.

스크린리더는 제 코드를 어떻게 읽을까요?

스크린리더는 화면의 ‘모양’이 아니라 HTML의 ‘의미’를 읽습니다. 그래서 저는 <div onclick> 대신 <button>, 메뉴는 <nav>, 본문은 <main>, 제목은 순서대로 h1·h2·h3를 씁니다. 시각적으로 똑같아 보여도, 시맨틱 태그를 쓰면 스크린리더 사용자는 ‘버튼 4개가 있는 내비게이션’이라고 듣고, 표제만 훑어서 원하는 곳으로 점프할 수 있습니다. div로 쌓은 화면은 그들에게 그냥 ‘텍스트 덩어리’입니다.

이미지와 색은 어떻게 다뤄야 할까요?

이미지에는 alt를 답니다. 단, ‘이미지’ 같은 말이 아니라 그 이미지가 전하는 정보를요. 장식용 이미지는 일부러 alt=""로 비워서 스크린리더가 건너뛰게 합니다. 그리고 저는 색만으로 정보를 전달하지 않습니다. ‘빨간 글씨는 오류’ 같은 표시는 색각 이상 사용자나 흑백 화면에서 사라집니다. 그래서 색에 더해 아이콘이나 텍스트(“오류:”)를 항상 같이 둡니다. 명도 대비도 챙깁니다. 본문은 배경 대비 4.5:1, 큰 글씨는 3:1 이상을 맞춰서, 연한 회색 글씨로 멋 부리다 못 읽는 일을 막습니다.

제가 포커스 링을 지우지 않고 ‘다시 그릴 때’ 쓰는 코드는 사실 몇 줄 안 됩니다. 이게 제 출발점입니다.

/* outline:none 으로 지우지 말고, 키보드 때만 다시 그린다 */
:focus-visible {
  outline: 2px solid var(--signal);
  outline-offset: 3px;
  border-radius: 4px;
}
/* 마우스 클릭으로 들어온 포커스는 링을 숨긴다 */
:focus:not(:focus-visible) { outline: none; }

/* 스크린리더 전용 안내문(화면엔 안 보이고 음성으로만) */
.sr-only {
  position: absolute; width: 1px; height: 1px;
  padding: 0; margin: -1px; overflow: hidden;
  clip: rect(0 0 0 0); white-space: nowrap; border: 0;
}

그리고 화면을 넘기기 전에는 키보드만으로 한 바퀴 돌고, 자동 점검 도구(axe)를 한 번 돌려 ‘위반 0’을 눈으로 확인합니다.

$ npx @axe-core/cli https://find-ables.com/ --tags wcag2a,wcag2aa
$ ✓ 색 대비 위반 0 · 라벨 없는 폼 컨트롤 0 · 이미지 alt 누락 0
$ ✓ 키보드 탭 순서: 메뉴 → 서비스 → 문의 → 자료받기 (가로채기 없음)

ARIA는 많이 붙일수록 좋은 거 아닌가요?

여기서 많이들 헷갈립니다. ARIA는 최소로, 정확히 써야 합니다. 업계에 “No ARIA is better than bad ARIA(잘못된 ARIA보다 차라리 없는 게 낫다)”는 말이 있을 정도예요. 잘못 붙은 role이나 깨진 aria-label은 스크린리더에 거짓 정보를 줍니다. 그래서 저는 먼저 시맨틱 HTML로 풀고, 네이티브 요소로 표현이 안 되는 경우(커스텀 토글, 라이브 영역 등)에만 ARIA를 보조로 씁니다. 가장 좋은 ARIA는 ‘안 써도 되게 만든 ARIA’입니다.

움직임이 누군가를 아프게 할 수도 있나요?

네, 의외로 많은 분이 모릅니다. 전정기관이 민감한 사람에게 큰 패럴랙스, 화면을 가로지르는 모션, 자동재생 캐러셀은 어지럼증과 멀미를 유발합니다. 그래서 저는 prefers-reduced-motion을 켠 사용자에게는 큰 움직임을 끄거나 부드러운 페이드로 바꿉니다. 운영체제에서 ‘동작 줄이기’를 켜둔 사람의 의사를, 코드가 존중하는 거죠. 접근성은 화려함을 버리는 게 아니라, 끌 수 있게 만드는 일입니다.

다른 담당자와의 연결 — 접근성은 모두의 일입니다

접근성은 저 혼자 챙긴다고 되는 게 아닙니다. 화면의 모든 디테일에 스며들어 있어요. 명도 대비와 색 사용은 컬러를 맡은 사람과, 폼 라벨·검증 메시지의 접근성은 폼을 맡은 사람과, 시맨틱 구조와 성능은 개발 전반과 함께 맞춰야 비로소 완성됩니다. 같은 기준을 공유하는 팀이라야, 어느 한 곳도 새지 않습니다.