접근성은 “법 때문에 하는 일”로만 두면 비용이 뒤늦게 폭발하기 쉽습니다. 반대로 처음부터 기본선만 잡아 두면, 디자인·개발·QA가 같은 언어로 말할 수 있어요. 이 글은 스펙 전체를 나열하지 않고, WCAG 2.2를 염두에 둔 개발자 관점의 흐름과 PR 직전에 돌려 보는 짧은 체크리스트만 담았습니다.
POUR를 한 줄로 기억하기
WCAG는 Perceivable(인지 가능), Operable(조작 가능), Understandable(이해 가능), Robust(견고) 네 덩어리로 설명됩니다. 화면이 예쁜지보다 먼저, 정보가 감각과 보조기기에 닿는지, 키보드로 끝까지 갈 수 있는지, 문장으로 이해 가능한지, 표준에 가까운 마크업인지를 묻는 구조예요.
PR 전에 6가지만
완벽한 감사 리포트 대신, 막히는 장애부터 줄이는 순서입니다. 아래 도식은 팀에 그대로 붙여 넣기 좋게 짧게 적었어요.
추가로 팀에 공유하면 좋은 습관은 두 가지입니다.
- 자동 검사를 CI에 한 번:
axe-core, Lighthouse accessibility score는 완벽하지 않지만 회귀 방지에는 충분히 값어치가 있습니다. - 수동은 “대표 시나리오”만: 회원가입, 결제, 검색처럼 매출·이탈과 연결된 플로우 위주로 키보드만 쥐고 한 번씩 밟아 보기.
정리
접근성은 품질의 일부이고, WCAG 2.2는 그 품질을 말로 설명하기 위한 공통 어휘에 가깝습니다. 처음부터 조금씩 맞춰 두면 나중에 “전면 수정”을 피할 수 있고, 검색·전환·브랜드 신뢰에도 도움이 되는 경우가 많아요. 이 블로그도 같은 기준으로 계속 다듬고 있습니다.