접근성 테스트, 배포 직전에 몰아서 하고 계신가요?

그러면 이미 늦어요. 코드가 쌓인 뒤에 접근성 문제를 고치는 건 — 렌더 이후에 레이아웃 다시 짜는 것만큼 힘들어요.

해답은 **"처음부터 자동으로 막는 것"**이에요. 컴포넌트 작성할 때, PR 올릴 때, 배포 전에. 각 단계마다 자동 검사가 붙으면 접근성 문제가 운영에 나갈 일이 없어요.

오늘은 HANUI 디자인 시스템에 적용한 접근성 자동화 파이프라인을 공유할게요.

3단계 자동화 파이프라인

각 단계마다 다른 종류의 문제를 잡아요. 겹치는 게 있어도 괜찮아요 — 그게 안전망이에요.

1단계: axe-core 단위 테스트

axe 테스트 붙이고 나서 발견한 것들이에요:

테스트 커버리지랑 접근성 검사를 같이 돌리면 어떤 컴포넌트가 빠졌는지 한눈에 보여요.

axe 테스트는 코드 레벨에서 잡는 거예요. 근데 **"실제로 어떻게 보이는가"**는 Storybook에서 봐야 해요.

a11y 탭에서 실시간으로 보여요:

색상 대비 문제는 axe 테스트에서는 잘 안 잡히는데 Storybook에서 시각적으로 확인하기 좋아요.

로컬에서 테스트 다 통과해도 PR에서 놓치는 경우가 있어요. CI에 붙이면 완전히 막을 수 있어요.

이렇게 하면 모든 Story를 자동으로 접근성 검사해요. 새 컴포넌트 추가할 때 Story만 작성하면 자동으로 검사 대상이 돼요.

실제로 이 파이프라인 붙이고 나서 운영에 접근성 문제가 나간 게 0건이에요. 개발 중에 다 잡히거든요.

자동화가 완벽하진 않아요. 놓치는 부분도 알고 있어야 해요.

4편에서 다룬 VoiceOver/NVDA 테스트는 자동화랑 병행해야 해요.

GitHub Actions에서 배지도 달 수 있어요:

PR 코멘트로 결과 자동 게시:

5편에 걸쳐 접근성 시리즈를 정리했어요.

1편 (KWCAG 자동 적용) → 2편 (금융 접근성 실무) → 3편 (키보드 네비게이션) → 4편 (스크린 리더 테스트) → 5편 (자동화)

이 순서대로 적용하면 접근성 인증을 준비할 수 있어요. HANUI는 이 파이프라인으로 만들어진 컴포넌트들이에요.

관련 링크

접근성 시리즈