WCAG 2.2, 무엇이 새로워졌나.

몇 해 전, 시각장애가 있는 사용자에게 우리가 만든 폼을 써보게 한 적이 있습니다. 그분은 키보드만으로 칸을 옮기다가 어느 순간 멈췄습니다. “지금 제가 어디 있는 거죠?” 화면에는 분명 파란 포커스 테두리가 떴는데, 우리가 자랑하던 ‘고정 헤더’가 그 테두리를 덮고 있었습니다. 그날 저는 깨달았습니다. 접근성은 명세서를 통과하는 일이 아니라, 사람이 길을 잃지 않게 하는 일이라는 걸요. 공교롭게도 그 문제는 WCAG 2.2가 새로 못 박은 기준 중 하나였습니다.

WCAG 2.2는 대체 무엇이고, 왜 또 바뀌었나?

WCAG(웹 콘텐츠 접근성 가이드라인)는 ‘누구나 웹을 쓸 수 있게’ 하는 국제 표준입니다. 2.2는 2018년의 2.1을 버리는 게 아니라 그대로 품으면서 위에 얹은 버전입니다. 2023년 10월 5일 W3C 권고안이 됐고, 모바일·터치·인지 부담처럼 그동안 현실에서 사람들을 막아온 문제 9가지를 ‘성공기준’으로 새로 추가했습니다. 동시에, 현대 브라우저에서는 의미가 사라진 4.1.1 Parsing 기준은 깔끔하게 제거됐습니다. 즉 항목이 무작정 늘기만 한 게 아니라, 쓸모없는 건 빼고 진짜 문제를 더한 정리에 가깝습니다.

가장 먼저 챙겨야 할 새 기준은 무엇인가? — 포커스 가시성

제 경험상 실무에서 가장 자주 어기는 신규 기준이 바로 2.4.11 포커스 가려짐(Focus Not Obscured, AA)입니다. 키보드로 Tab을 눌러 이동했을 때, 지금 포커스된 요소가 화면에서 적어도 일부는 보여야 한다는 뜻입니다. 고정 헤더·쿠키 배너·채팅 위젯이 포커스된 버튼을 통째로 가리면 안 됩니다(완전히 다 보여야 한다는 더 엄격한 2.4.12는 AAA입니다). 그리고 ‘포커스가 보인다’는 것 자체의 품질을 다루는 게 2.4.13 포커스 모양(Focus Appearance, AAA)으로, 포커스 표시가 충분히 크고 대비가 분명해야 한다는 기준입니다.

말로는 와닿지 않으니, 직접 해보세요.

‘링 끄기’를 켜는 순간 어디가 선택됐는지 알 수 없어집니다. 마우스 없이 키보드만 쓰는 사람에게는 이게 매일의 현실입니다. outline:none 한 줄이 누군가를 길 잃게 만든다는 걸, 한 번 체험하면 다시는 가볍게 지우지 못합니다.

모바일에서 가장 와닿는 변화는? — 24px 타깃과 드래그 대안

2.5.8 타깃 크기(Target Size, AA) — 24×24 픽셀이라는 바닥선

클릭·터치할 수 있는 대상은 최소 24×24 CSS 픽셀이거나, 그보다 작다면 주변 대상과 충분히 떨어져 있어야 합니다. “버튼이 분명 보이는데 안 눌린다”, “옆 링크가 눌린다” 같은 모바일의 흔한 짜증이 여기서 옵니다. 흔히 권장되는 44×44px와 헷갈리기 쉬운데, 24px는 ‘반드시 넘겨야 할 최저선(WCAG의 의무)’이고 44px는 ‘손가락 터치를 위해 지향하는 더 넉넉한 목표’입니다. 충돌이 아니라 바닥과 목표의 관계입니다.

2.5.7 드래그 대안(Dragging Movements, AA) — 끌지 않고도 되게

드래그로만 되는 기능에는, 드래그 없이도 같은 일을 할 단일 포인터 방법을 함께 둬야 합니다. 슬라이더에는 +/− 버튼이나 입력칸을, 카드 정렬에는 ‘위로/아래로’ 버튼을 같이 주는 식입니다. 손 떨림이 있거나 음성으로 포인터를 움직이는 분에게 정밀한 드래그는 사실상 통과 불가의 벽이기 때문입니다. 멋진 드래그 인터랙션을 만들수록, 저는 항상 ‘끌지 않는 길’을 하나 더 깔아둡니다.

이 새 기준들 중 CSS만으로 절반은 막을 수 있습니다. 24px 타깃(2.5.8)과 ‘고정 헤더가 포커스를 덮지 않게’(2.4.11 포커스 가려짐)는 제가 모든 프로젝트의 베이스에 깔아두는 코드입니다.

/* 2.5.8 타깃 크기(AA) — 누를 수 있는 건 최소 24×24px */
a, button, [role="button"], label, summary {
  min-block-size: 24px;
  min-inline-size: 24px;
}

/* 2.4.11 포커스 가려짐(AA) — 고정 헤더가 포커스 요소를 덮지 않게
   scroll-margin-top 으로 헤더 높이만큼 미리 띄워 스크롤 */
:target, :focus-visible {
  scroll-margin-top: 84px; /* = 고정 헤더 높이 + 여유 */
}

/* 2.4.13 포커스 모양(AAA 지향) — 충분히 크고 대비 분명한 링 */
:focus-visible { outline: 2px solid var(--signal); outline-offset: 3px; }

그리고 출시 전, 새 9개 기준을 체크리스트로 한 줄씩 직접 확인합니다.

$ WCAG 2.2 점검: 신규 성공기준 9개
$ ✓ 2.5.8 타깃 24px 미만 0개 · 2.5.7 드래그 슬라이더에 +/− 대안 있음
$ ✓ 2.4.11 고정 헤더에 포커스 가려짐 0건 (scroll-margin 적용)
$ ✓ 3.3.7 중복 입력 없음 · 3.3.8 비밀번호 붙여넣기 허용

눈에 안 보이지만 큰 차이를 만드는 기준은? — 인지 부담 줄이기

2.2의 또 다른 축은 ‘머리를 덜 쓰게’ 하는 것입니다. 3.2.6 일관된 도움(Consistent Help, A)은 도움(문의·챗·연락처) 위치를 페이지마다 같은 자리에 두라는 기준입니다. 3.3.7 중복 입력 방지(Redundant Entry, A)는 한 과정 안에서 이미 입력한 정보를 또 묻지 말라는 것(예: 배송지=청구지 자동 채움). 3.3.8 쉬운 인증(Accessible Authentication, AA)은 로그인에 ‘기억력 시험’ 같은 인지 테스트를 강요하지 말고 대안을 두라는 기준입니다 — 비밀번호 붙여넣기 허용, 이메일 링크 로그인처럼요(더 엄격한 3.3.9는 AAA). 화려하지 않지만, 가장 많은 사람이 매일 부딪히는 벽들입니다.

그래서 9가지를 한눈에 보면?

2.2가 새로 더한 성공기준 9개입니다. 레벨(A/AA/AAA)이 낮을수록 더 기본적인 의무라고 보면 됩니다.

접근성이 왜 SEO와 신뢰에도 이득인가?

이게 제가 가장 하고 싶은 말입니다. 접근성을 위해 하는 일은 검색·AI 노출을 위해 하는 일과 거의 겹칩니다. 명확한 제목 구조(h1→h2), 의미 있는 HTML, 이미지 대체 텍스트, 키보드로 도달 가능한 메뉴 — 이건 스크린리더만 쓰는 게 아니라 검색엔진과 AI 답변엔진이 페이지를 이해하는 데 그대로 쓰입니다. 게다가 누구나 막힘없이 쓰는 사이트는 이탈이 줄고, “이 회사 꼼꼼하다”는 신뢰를 남깁니다. 접근성·SEO·전환은 서로 다른 일이 아니라, 하나의 좋은 설계가 보여주는 세 얼굴입니다.

접근성을 이렇게 보는 사람이, 사이트 전체를 만듭니다

포커스 하나, 터치 영역 24px 하나를 진지하게 보는 사람이라면 색 대비도, 폼도, 카피도 같은 태도로 다룹니다. Findable에서는 이런 디테일이 ‘추가 옵션’이 아니라 기본값입니다. 당신의 사이트, 지금 키보드만으로 끝까지 쓸 수 있나요?