4월 24일이 뭐냐고? ADA Title II 디지털 접근성 규정의 준수 마감일이다. 미국 공공기관과 그 파트너사가 WCAG 2.1 Level AA를 의무적으로 맞춰야 하는 날짜. "우리는 한국 회사니까 상관없다"고? 글로벌 서비스 하나라도 걸려 있으면 이야기가 달라진다. 게다가 WCAG 2.2가 올해 안에 ISO 40500:2026으로 승격될 예정이라, 이건 곧 미국만의 문제가 아니게 된다.

근데 진짜 무서운 건 법이 아니다. WCAG 2.2에서 새로 추가된 성공 기준들이 프론트엔드 코드에서 흔히 보이는 패턴을 정조준하고 있다는 사실이다. sticky 헤더, 16px 아이콘 버튼, 드래그 전용 칸반 보드, autocomplete="off" — 다 걸린다.

sticky 헤더가 포커스를 삼키는 문제

2.4.11 Focus Not Obscured (Minimum). Level AA, 법적 준수 대상.

Tab 키로 페이지를 탐색할 때 포커스된 요소가 sticky 헤더나 쿠키 동의 배너 뒤에 완전히 가려지면 실패다. "완전히"가 핵심인데, 일부만 가려지는 경우 AA에서는 통과한다. AAA 등급인 2.4.12가 그걸 잡는다.

고치는 데 JavaScript 한 줄도 필요 없다:

html {
  scroll-padding-top: 80px; /* sticky 헤더 높이 + 여유분 */
}

브라우저가 scrollIntoView나 앵커 이동, Tab 포커스 시 스크롤 위치를 잡을 때 이 패딩을 참고한다. 놀라울 정도로 많은 프로젝트에서 이 한 줄이 빠져 있다. Next.js 프로젝트라면 globals.css에 넣으면 끝이다.

쿠키 배너는 더 골치 아프다. 대부분 position: fixed; bottom: 0에 z-index: 9999로 띄워놓는데, 페이지 하단의 링크나 폼 필드에 포커스가 갈 때 배너가 통째로 덮어버린다. 해법 두 가지:

  • 배너 렌더링 시 body에 padding-bottom을 배너 높이만큼 동적으로 추가

  • 배너 자체를 position: sticky로 바꿔서 문서 흐름 안에 편입

두 번째가 더 깔끔하지만, 기존 쿠키 라이브러리와 충돌할 수 있어서 상황 따라 판단해야 한다. 어느 쪽이든 수정 분량은 10줄 이내다.

24px — 터치 타겟의 새 기준선

2.5.8 Target Size (Minimum). 역시 AA.

모든 인터랙티브 요소의 클릭/탭 가능 영역이 최소 24×24 CSS 픽셀이어야 한다. 요소의 시각적 크기가 아니라 실제 히트 영역이 기준이다. 그래서 padding으로 해결 가능한 경우가 많다.

흔한 패턴 문제 수정
16×16 아이콘 버튼 터치 영역 부족 padding: 4px 추가하면 24px 확보
테이블 안 액션 링크 빽빽하게 붙어있음 요소 간 gap: 8px 이상 확보
폼 체크박스 커스텀 실제 히트 영역 축소 label의 클릭 영역을 24px 이상으로

예외 조항도 있다. 문단 속 인라인 텍스트 링크, 브라우저 네이티브 컨트롤, 같은 기능을 수행하는 다른 컨트롤이 24px 이상인 경우. 하지만 아이콘 버튼으로 도배된 어드민 패널이나 데이터 테이블의 행 액션 버튼? 거의 다 걸린다.

한 가지 짚고 넘어갈 점: Lighthouse가 이 기준을 아직 자동으로 감지하지 못한다. axe-core 4.10에서 실험적 룰로 들어갔지만 기본값은 꺼져 있다. 손으로 잡아야 한다.

드래그 전용이면 탈락

2.5.7 Dragging Movements. AA.

세 줄 요약: 드래그로만 조작 가능한 UI가 있으면, 반드시 클릭이나 키보드로 같은 결과를 낼 수 있는 대안을 제공해야 한다.

칸반 보드의 카드 이동, 정렬 가능 리스트, 이미지 크롭 슬라이더 전부 해당. @dnd-kit/core나 구 react-beautiful-dnd 쓰고 있다면 키보드 지원이 이미 내장되어 있을 가능성이 높다. 문제는 onPointerDown + onPointerMove로 직접 구현한 커스텀 드래그. 여기엔 "위로 이동" / "아래로 이동" 같은 버튼을 별도로 달거나, 위치를 직접 입력할 수 있는 UI를 만들어야 한다.

autocomplete 속성 하나면 되는 인증 기준

3.3.8 Accessible Authentication (Minimum). AA.

비밀번호를 기억하는 것, CAPTCHA 퍼즐을 푸는 것, 특정 패턴을 그리는 것 — 이런 인지 기능 테스트가 인증의 유일한 수단이면 안 된다. 다음 중 최소 하나를 제공해야 한다:

  • 비밀번호 관리자가 작동할 수 있는 autocomplete 속성

  • OAuth, 패스키 같은 대안 인증 경로

  • 이메일/SMS 인증 코드

실무에서 가장 많이 놓치는 건 autocomplete="current-password"다. 커스텀 로그인 폼 만들면서 autocomplete="off" 때려놓은 코드 본 적 있을 거다 — 브라우저 자동완성이 디자인 깨뜨린다는 이유로. 그 한 줄이 WCAG 위반이 된다. new-password, username, email 속성도 빠짐없이 확인하자.

14일 안에 끝내는 우선순위

접근성 라이브러리를 전부 교체할 시간은 없다. 투입 대비 효과 순서:

  1. scroll-padding-top 추가 — CSS 한 줄, 5분. 가장 확실한 승리.

  2. 로그인/가입 폼 autocomplete 점검 — 폼 2~3개만 보면 된다.

  3. 아이콘 버튼 터치 타겟 감사 — DevTools에서 요소 크기 찍어보고 24px 미만인 것에 padding 추가.

  4. 드래그 UI 대안 조작 수단 확인 — 키보드로 같은 동작이 되는지 Tab → Enter로 테스트.

React Aria, Radix UI, Headless UI처럼 접근성 우선으로 설계된 라이브러리를 쓰고 있다면 1~3번은 이미 처리돼 있을 확률이 꽤 높다. 진짜 위험한 건 팀에서 직접 만든 컴포넌트다. 그 커스텀 드롭다운, 그 자체 제작 모달, 그 손수 짠 날짜 선택기.

마감까지 14일.