자동화 접근성 테스트 도구

도구 지형도

The Tool Landscape

주요 자동화 도구: axe(Deque Systems)는 업계 표준 엔진으로 브라우저 확장, API, CI 통합을 지원합니다. WAVE(WebAIM)는 페이지 위에 오류를 시각적으로 겹쳐 표시해 교육용으로 좋습니다. Lighthouse(Google)는 Chrome DevTools에 내장되어 접근성 외에 성능·SEO도 점검하며, 내부적으로 axe-core를 사용합니다. Pa11y는 커맨드라인 기반으로 CI/CD 통합에 강합니다.

Major automated tools: axe (Deque Systems) is the industry-standard engine with browser extensions, APIs, and CI integration. WAVE (WebAIM) overlays errors visually on the page — great for education. Lighthouse (Google), built into Chrome DevTools, checks performance and SEO alongside accessibility, and uses axe-core internally. Pa11y is command-line based with strong CI/CD integration.

도구 선택의 관점: 단발 점검엔 브라우저 확장(axe DevTools, WAVE), 회귀 방지엔 CI 통합(axe-core, Pa11y), 대규모 사이트 상시 모니터링엔 크롤링형 플랫폼(Siteimprove, Deque WorldSpace류)이 어울립니다. 어떤 도구든 같은 엔진 계열이면 결과가 비슷하므로, 도구 수를 늘리는 것보다 수동 테스트를 병행하는 것이 커버리지를 실제로 넓힙니다.

Choosing tools: browser extensions (axe DevTools, WAVE) suit spot checks; CI integrations (axe-core, Pa11y) suit regression prevention; crawling platforms (Siteimprove, Deque WorldSpace-class) suit continuous monitoring of large sites. Tools sharing the same engine family produce similar results — adding manual testing widens real coverage more than adding tools.

무엇을 잡고 무엇을 놓치는가

What Automation Catches — and Misses

자동화 도구는 전체 접근성 이슈의 약 30~40%만 발견합니다. 감지 가능: 누락된 alt 속성, 색상 대비 부족, 빈 링크·버튼, 중복 ID, 누락된 폼 레이블, 잘못된 ARIA 속성 값. 감지 불가: alt 텍스트의 적절성, 키보드 탐색 순서의 논리성, 포커스 관리 품질, 콘텐츠의 이해 가능성, 시각적 읽기 순서와 DOM 순서의 일치.

Automated tools find only about 30–40% of accessibility issues. Detectable: missing alt attributes, insufficient contrast, empty links and buttons, duplicate IDs, missing form labels, invalid ARIA attribute values. Not detectable: appropriateness of alt text, logical keyboard order, focus management quality, content understandability, and whether visual reading order matches DOM order.

거짓 양성(false positive)과 거짓 음성도 이해해야 합니다. 도구는 판단이 필요한 항목을 '검토 필요(needs review)'로 표시하는데(예: 배경 이미지 위 텍스트 대비), 이를 무시하면 실제 결함이 숨습니다. 반대로 규칙에 걸리지 않았다고 접근 가능한 것은 아닙니다 — '자동 검사 0건'은 시작점이지 합격증이 아닙니다.

Understand false positives and negatives too. Tools flag judgment-required items as 'needs review' (e.g., text contrast over background images) — ignoring these hides real defects. Conversely, passing the rules doesn't mean accessible: 'zero automated findings' is a starting point, not a pass certificate.

CI/CD 통합 패턴

CI/CD Integration Patterns

axe-core를 Jest(jest-axe), Cypress(cypress-axe), Playwright(@axe-core/playwright) 같은 테스트 프레임워크와 통합해 PR마다 자동 검사를 실행합니다. 자동화 테스트는 '게이트키퍼'로서 새 접근성 결함의 유입을 막고, 기존 이슈 발굴은 수동 감사가 담당합니다.

Integrate axe-core with test frameworks — Jest (jest-axe), Cypress (cypress-axe), Playwright (@axe-core/playwright) — to run checks on every PR. Automation acts as a gatekeeper against new defects, while manual audits surface existing issues.

실무 요령: 처음부터 전체 실패를 빌드 차단으로 걸면 기존 부채 때문에 도입이 좌초합니다. 새 코드·변경된 화면에만 엄격 기준을 적용하고 기존 부채는 베이스라인으로 관리하며 점진 상환하는 전략이 현실적입니다. 컴포넌트 단위 테스트(Storybook + axe)는 결함을 가장 이른 단계에서 잡습니다.

Practical tip: blocking builds on all failures from day one founders on existing debt. A realistic strategy applies strict rules to new code and changed screens while managing existing debt as a baseline paid down incrementally. Component-level testing (Storybook + axe) catches defects at the earliest possible stage.

자동화·수동·사용자 테스트의 상호보완

Automated, Manual, and User Testing Together

자동화 도구는 빠르고 반복 가능한 기술 검사에 강하고, 수동 테스트는 사용자 경험·맥락·의미의 정확성을 평가하며, 사용자 테스트는 실제 과업 수행 가능성을 검증합니다. 최선의 전략은 셋의 병행입니다: 자동화로 기본기를 상시 방어하고, 릴리스 주기마다 수동 감사를 돌리고, 주요 개편에는 장애인 사용자 테스트를 포함합니다.

Automation excels at fast, repeatable technical checks; manual testing evaluates experience, context, and semantic accuracy; user testing validates real task completion. The best strategy combines all three: automation defends the basics continuously, manual audits run each release cycle, and major redesigns include testing with disabled users.

ACT 규칙 — 테스트의 표준화

ACT Rules — Standardizing Tests

W3C의 ACT(Accessibility Conformance Testing) 규칙은 '무엇을 어떻게 검사하고 어떤 결과를 실패로 판정하는가'를 표준화한 테스트 규칙 형식입니다. 같은 페이지를 놓고 도구·감사자마다 판정이 갈리는 문제를 줄이기 위해, 각 규칙은 적용 대상(applicability), 기대 결과(expectations), 통과·실패 예제를 명시합니다. axe-core 등 주요 도구들이 자사 규칙을 ACT 규칙 형식에 매핑해 일관성을 검증합니다.

The W3C's ACT (Accessibility Conformance Testing) rules standardize what to test, how, and what counts as failure. To reduce divergent verdicts between tools and auditors on the same page, each rule specifies applicability, expectations, and passed/failed examples. Major tools such as axe-core map their rules to the ACT format to validate consistency.

실무 의미: 도구 간 결과가 다를 때 ACT 규칙과 그 예제가 중립적 판정 기준이 됩니다. 또한 각 규칙은 특정 성공 기준에 매핑되므로, '이 실패가 어느 SC 위반인가'를 근거 있게 문서화하는 데 유용합니다. 다만 모든 SC가 ACT 규칙으로 커버되는 것은 아니므로 수동 판단은 여전히 필요합니다.

In practice: when tools disagree, ACT rules and their examples serve as a neutral arbiter. Because each rule maps to specific success criteria, they also help document which SC a failure violates. Not every SC is covered by an ACT rule, though — manual judgment remains necessary.