도입 스토리
"첫 번째 접근성 감사를 맡게 됐어요." 김개발이 박멘토에게 말했습니다. "어디서 시작해야 하죠?"
"감사는 순서가 있어요." 박멘토가 체크리스트를 열었습니다. "자동화 도구로 빠르게 전체를 훑고, 키보드로 주요 흐름을 테스트하고, 스크린리더로 심층 확인해요. 그리고 결과를 심각도와 영향도로 분류해서 우선순위를 정하는 거예요."
"얼마나 걸려요?"
"소규모 사이트면 하루, 대규모면 일주일. 먼저 범위를 정하는 게 중요해요."
핵심 개념 설명
감사 범위 정의
모든 페이지를 감사하기는 어렵습니다. 핵심 사용자 여정을 중심으로 범위를 정합니다.
## 감사 범위 (예: 쇼핑몰)
### 필수 페이지 (반드시 감사)
- 홈 페이지
- 로그인 / 회원가입
- 상품 목록
- 상품 상세
- 장바구니
- 결제 (3단계 폼)
- 주문 완료
### 대표 컴포넌트
- 메인 내비게이션
- 상품 카드
- 검색 자동완성
- 모달 (일반 / 결제)
### 제외 (범위 외)
- 관리자 페이지
- 서드파티 결제 페이지
감사 체크리스트
1단계 — 자동화 도구 (30분):
□ axe DevTools: 전체 페이지 스캔
□ Lighthouse: 각 페이지 접근성 점수
□ WAVE: 시각적 구조 확인
□ 색상 대비: 주요 색상 조합 Contrast Checker
□ HTML 유효성: W3C Validator
2단계 — 키보드 테스트 (1~2시간):
□ Tab 키로 전체 페이지 탐색 — 포커스가 항상 보이는가
□ 모달 열기/닫기 — 포커스 트랩 및 복원
□ 드롭다운 메뉴 — 방향키로 이동 가능
□ 폼 완료 — 키보드만으로 제출까지
□ 건너뛰기 링크 — Tab 첫 번째 요소 확인
□ 에러 상태 — 오류 발생 후 폼 탐색
3단계 — 스크린리더 테스트 (2~3시간):
□ NVDA + Chrome: 헤딩 구조, 랜드마크 탐색
□ VoiceOver + Safari: 동일 시나리오
□ 이미지 대체 텍스트 청취
□ 폼 레이블과 오류 메시지 청취
□ 동적 콘텐츠 (알림, 업데이트) 청취
□ 링크 목록 확인 — 모호한 링크 없는가
4단계 — 추가 점검:
□ 200% 확대 — 레이아웃 깨짐 없는가
□ 색각이상 시뮬레이션 — Chrome DevTools
□ 모션 줄이기 — prefers-reduced-motion 적용 확인
□ 자동 재생 콘텐츠 — 5초 이상 자동 재생 없는가
□ 언어 설정 — lang 속성 확인
발견 사항 기록 형식
## 접근성 감사 발견 사항
### [A-001] 이미지 대체 텍스트 누락
- **페이지**: 홈 (`/`)
- **요소**: 메인 배너 이미지 (`img#hero-banner`)
- **WCAG**: 1.1.1 텍스트 대안 (Level A)
- **심각도**: Critical
- **영향**: 시각장애인이 배너 내용을 전혀 알 수 없음
- **현재 코드**: `<img src="hero.jpg">`
- **개선 방안**: `<img src="hero.jpg" alt="2026 봄 신상품 — 최대 50% 할인">`
- **예상 공수**: 15분
### [A-002] 포커스 스타일 제거
- **페이지**: 전체
- **요소**: `a, button, input` 전체
- **WCAG**: 2.4.7 포커스 가시성 (Level AA)
- **심각도**: Serious
- **영향**: 키보드 사용자가 현재 포커스 위치를 알 수 없음
- **현재 코드**: `* { outline: none; }`
- **개선 방안**: `:focus-visible { outline: 3px solid #005FCC; }`
- **예상 공수**: 30분
심각도 분류
| 심각도 | 기준 | 대응 |
|---|---|---|
| Critical | 접근 자체 불가능 | 즉시 수정 |
| Serious | 우회 방법이 없거나 매우 어려움 | 다음 스프린트 |
| Moderate | 불편하지만 접근 가능 | 분기 내 수정 |
| Minor | 미세한 개선 가능 | 백로그 관리 |
단계별 실습
따라하기: 공개 사이트 감사 실습
실제 공개 웹사이트를 대상으로 간단한 감사를 수행합니다.
- 정부 또는 공공기관 웹사이트를 선택합니다.
- axe DevTools로 홈 페이지를 스캔합니다.
- 발견된 오류 3가지를 선택하고 위의 형식으로 기록합니다.
- 각 오류에 심각도와 개선 방안을 작성합니다.
변형하기: 감사 보고서 자동화
axe 결과를 감사 보고서 형식으로 변환하는 스크립트를 작성합니다.
// axe 결과 → 감사 보고서 변환function generateReport(axeResults, pageUrl) { const report = { page: pageUrl, date: new Date().toISOString().split('T')[0], summary: { critical: 0, serious: 0, moderate: 0, minor: 0, }, violations: [] }; axeResults.violations.forEach((v, i) => { report.summary[v.impact]++; report.violations.push({ id: `A-${String(i + 1).padStart(3, '0')}`, description: v.description, wcag: v.tags.filter(t => t.startsWith('wcag')).join(', '), impact: v.impact, count: v.nodes.length, helpUrl: v.helpUrl, }); }); return report;}정리와 확인
핵심 내용 요약
- 감사 범위: 핵심 사용자 여정 중심으로 페이지 선정
- 4단계 감사: 자동화 → 키보드 → 스크린리더 → 추가 점검
- 발견 사항 기록: WCAG 항목, 심각도, 영향, 개선 방안, 예상 공수
- 심각도 분류: Critical(즉시) → Serious(다음 스프린트) → Moderate(분기) → Minor(백로그)
확인 문제
문제 1. 접근성 감사에서 자동화 도구만으로 충분하지 않은 이유는?
자동화 도구는 코드 구조적 오류(alt 누락, label 연결)를 탐지합니다.
실제 사용자 경험(읽기 순서, 레이블 내용의 의미, 포커스 흐름)은
키보드와 스크린리더로 직접 사용해봐야 알 수 있습니다.
문제 2. 감사 범위를 전체 페이지 대신 핵심 사용자 여정으로 좁히는 이유는?
시간과 리소스의 한계로 모든 페이지를 감사하기 어렵습니다.
로그인 → 상품 선택 → 결제처럼 핵심 여정이 접근 가능하면
대부분의 사용자 요구를 충족합니다.
다음 챕터에서는 개선 구현과 검증을 다룹니다. 발견된 오류를 실제로 수정하고 Before/After를 비교하는 실습을 진행합니다.