올해가 KWCAG 2.2 공공기관 의무 적용 연도라는 걸 기억하는 프론트엔드 개발자가 몇이나 될까. "접근성은 퍼블리셔 일"이라고 넘기기엔, 2.2에서 추가된 9개 검사항목이 꽤나 JS 컴포넌트 레벨의 수정을 요구한다. 특히 React나 Vue 기반 SPA를 운영하는 팀이라면, 라우팅 전환 시 포커스 관리부터 동적 콘텐츠 알림까지 손봐야 할 곳이 한두 군데가 아니다.
24개에서 33개로
KWCAG 2.1까지 24개이던 검사항목이 33개로 늘었다. 핵심은 모바일·터치 환경 반영. 웹을 폰으로 보는 게 디폴트인 세상에 지침이 겨우 따라온 셈이다. 프론트엔드가 실제로 손대야 할 건 크게 세 카테고리다.
참고로 WCAG 2.2(국제 기준)는 2023년 10월에 W3C 권고안이 됐고, KWCAG 2.2는 이걸 한국 상황에 맞게 로컬라이즈한 버전이다. 국제 기준과 거의 동일하지만 인증 심사 방식이나 평가 기준서의 해석이 다른 부분이 있어서, WCAG 원문만 읽고 "우리는 이미 대응했다"고 착각하면 곤란하다.
포커스 가시성 — outline: none은 진짜 안 된다
2.1에서도 "초점 이동" 항목은 있었는데, 2.2는 포커스 표시의 최소 면적과 대비까지 규정한다. 구체적으로 포커스 인디케이터의 면적이 최소 2px 두께의 둘레선 이상이어야 하고, 인접 배경과의 대비가 3:1을 넘겨야 한다. 리셋 CSS에 *:focus { outline: none } 박아두는 그 관행, 인증 심사에서 바로 탈락이다.
/* 이거 아직도 쓰고 있으면 지금 당장 지워라 */
*:focus { outline: none; }
/* 대신 이렇게 */
*:focus-visible {
outline: 2px solid #005fcc;
outline-offset: 2px;
}:focus-visible은 키보드 탐색일 때만 포커스 링을 보여준다. 디자이너 눈치 안 봐도 되고 심사도 통과한다. Chrome, Firefox, Safari 전부 지원 끝났으니까 변명 거리가 없다.
실무에서 까다로운 건 커스텀 컴포넌트다. MUI의 Button이나 Ant Design의 Select처럼 라이브러리가 자체 포커스 스타일을 가진 경우, 글로벌 리셋이 그걸 덮어쓰는 일이 흔하다. 디자인 시스템을 쓰는 팀이라면 리셋 CSS와 컴포넌트 라이브러리의 포커스 스타일이 충돌하는지 한번 점검해볼 필요가 있다.
터치 타겟 최소 크기
모바일 터치 대상의 최소 크기가 명시됐다. WCAG 2.2 기준 최소 24×24px(AA), 권장 44×44px. 리스트 안에 16px짜리 아이콘 버튼 넣어두고 "잘 눌리는데요?"라던 시절이 끝났다.
시각적 크기가 작더라도 터치 영역은 확보해야 한다. min-width: 44px이든 투명 패딩이든, 방법은 상관없다. 실제로 자주 걸리는 케이스를 보면:
테이블 행 안의 편집/삭제 아이콘 — 시각적으로 16px인데 터치 영역도 16px인 경우가 대부분
태그 칩의 X 닫기 버튼 — 칩 자체는 32px인데 X는 12px짜리 SVG에 별도 패딩 없음
페이지네이션의 숫자 버튼 — 글자 크기에만 맞춰서 터치 영역이 20px 이하
Apple의 HIG는 최소 44pt, Material Design은 48dp를 권장한다. 플랫폼 가이드라인을 따르면 KWCAG도 자연스럽게 통과한다. 반대로 "우리 앱 유저는 젊어서 괜찮다"는 논리는 심사에서 통하지 않는다. 접근성은 특정 사용자층이 아니라 모든 사용자를 위한 기준이다.
드래그 전용 UI 금지
드래그로만 동작하는 UI에 대체 수단이 필수가 됐다. 칸반 보드 카드 이동? 키보드로도 가능해야 한다. 퍼즐 드래그 CAPTCHA? 시각장애인은 어떻게 통과하나. 대체 인증 없으면 불합격이다.
슬라이더, 컬러 피커, 정렬 순서 변경 — 생각보다 많은 곳에서 걸린다. 구체적으로 대응 방법을 나누면:
| UI 패턴 | 드래그 동작 | 대체 수단 예시 |
|---|---|---|
| 칸반 보드 | 카드를 다른 열로 드래그 | 컨텍스트 메뉴에서 "상태 변경" 선택 |
| 이미지 크롭 | 영역 드래그로 선택 | 좌표값 수치 입력 필드 |
| 리스트 정렬 | 항목 드래그로 순서 변경 | 위/아래 화살표 버튼 |
| 범위 슬라이더 | 핸들 드래그 | 숫자 input과 연동 |
@dnd-kit이나 react-beautiful-dnd 같은 라이브러리는 키보드 지원을 내장하고 있다. 직접 구현한 드래그 로직이 문제인 경우가 많으므로, 커스텀 mousedown/mousemove 핸들러를 쓰고 있다면 keydown 핸들러도 반드시 짝으로 구현해야 한다.
Lighthouse 100점으로는 부족하다
Lighthouse 접근성 검사가 커버하는 건 전체 KWCAG 항목의 40%도 안 된다. "키보드만으로 모든 기능을 조작할 수 있는가"는 사람이 직접 탭 키 눌러봐야 안다. axe 돌려서 초록불 뜨면 안심하는 건 좀 순진하다.
자동화 도구가 잡는 건 주로 HTML 레벨의 문제다. alt 누락, label 미연결, 색 대비 부족 같은 것들. 하지만 2.2에서 새로 추가된 항목 대부분은 동작(behavior) 레벨이라 정적 분석으로는 검출이 안 된다. 모달이 열렸을 때 포커스가 모달 안에 갇히는지, 닫았을 때 트리거 버튼으로 돌아가는지 — 이건 실제로 키보드로 조작해봐야 안다.
팀 내 QA 프로세스에 접근성 체크리스트를 넣는 게 현실적이다. 스프린트마다 전수검사를 하라는 게 아니라, 새 컴포넌트를 만들 때 키보드 탐색과 스크린 리더 테스트를 PR 체크리스트에 넣는 정도면 된다. macOS의 VoiceOver, Windows의 NVDA — 둘 다 무료고, 기본 사용법 익히는 데 30분이면 충분하다.
공공기관 SI만의 이야기가 아니다. 금융, 이커머스, 대기업도 자발적 인증이 늘고 있고, 한번 떨어지면 재심사까지 몇 달이다. 장애인차별금지법에 따른 손해배상 소송도 미국만의 이야기가 아니게 됐다. 2025년 국내 접근성 관련 민원 건수가 전년 대비 2배 이상 늘었다는 NIA 통계가 나와 있다. React든 Vue든, div에 onClick 거는 습관부터 고치자. <button>이 있는데 굳이 <div role="button" tabindex="0">를 쓸 이유가 없다.