도입 스토리
"팀장한테 접근성 개선 결과를 보고해야 해요." 김개발이 말했습니다.
"단순히 '오류 37개 → 6개'로는 부족해요." 박멘토가 말했습니다. "비즈니스 언어로 번역해야 해요. '법적 리스크 감소', 'SEO 점수 개선', '잠재 사용자 접근성 향상'으로요. 그리고 앞으로 어떻게 유지할 계획인지도요."
"기술적인 내용인데 비즈니스 언어로 바꾸는 게 어렵네요."
"연습이 필요해요. 하지만 그 능력이 있어야 팀 전체가 접근성을 문화로 받아들여요."
핵심 개념 설명
접근성 보고서 구조
# 접근성 감사 보고서
**프로젝트**: [사이트명]
**감사 기간**: 2026년 4월 1일 ~ 7일
**감사자**: 김개발, 박멘토
**기준**: WCAG 2.2 Level AA, KWCAG 2.2
---
## 1. 요약
**현황 점수**: Lighthouse 접근성 평균 62점 / 100점
**위반 건수**: 37건 (Critical 11, Serious 15, Moderate 8, Minor 3)
**법적 위험**: 장애인차별금지법 제20조 위반 가능성
**핵심 발견 사항**:
- 이미지 5개에 alt 텍스트 없음 → 시각장애인 정보 접근 불가
- 전체 포커스 스타일 제거 → 키보드/스위치 사용자 탐색 불가
- 주요 폼 레이블 미연결 → 회원가입, 결제 접근 불가
**비즈니스 영향**:
- 등록 장애인 265만 명 중 일부가 서비스를 사용할 수 없는 상태
- KWCAG 미준수 시 공공/기업 계약 탈락 리스크
- SEO: 구조 개선 시 검색 순위 영향 예상
---
## 2. 위반 상세 목록
| ID | 페이지 | 설명 | WCAG | 심각도 |
|----|--------|------|------|--------|
| A-001 | 홈 | 메인 배너 alt 없음 | 1.1.1 | Critical |
| A-002 | 전체 | 포커스 스타일 없음 | 2.4.7 | Serious |
...
---
## 3. 개선 권고
### 즉시 (1~2주)
1. 이미지 alt 텍스트 추가 (공수: 4시간)
2. CSS 포커스 스타일 복원 (공수: 1시간)
3. 폼 레이블 연결 (공수: 8시간)
### 단기 (1개월)
4. 모달 포커스 관리 구현 (공수: 1일)
5. 색상 대비 개선 (공수: 2일)
6. 스킵 내비게이션 추가 (공수: 2시간)
### 중기 (분기)
7. CI/CD 접근성 자동화 통합 (공수: 3일)
8. 스크린리더 정기 테스트 프로세스 수립
---
## 4. 개선 효과 예측
| 지표 | 현재 | 개선 후 예측 |
|------|------|------------|
| Lighthouse 접근성 | 62점 | 90점 이상 |
| axe Critical 오류 | 11건 | 0건 |
| 키보드 전체 탐색 | 불가 | 가능 |
---
## 5. 유지 방안
- ESLint jsx-a11y 도입 (코드 작성 시 즉시 경고)
- PR 체크리스트에 접근성 항목 추가
- Lighthouse CI 90점 이하 PR 차단
- 분기 1회 스크린리더 테스트
비즈니스 언어로 전환
| 기술 용어 | 비즈니스 언어 |
|---|---|
| "alt 텍스트 누락" | "시각장애인 고객이 제품 이미지 정보를 받지 못함" |
| "포커스 스타일 없음" | "키보드 사용자(손 부상, 운동 장애)가 사이트 이용 불가" |
| "WCAG AA 미준수" | "공공기관 납품 요건 미충족, 계약 탈락 리스크" |
| "색상 대비 미흡" | "저시력 사용자 및 강한 햇빛 아래 모든 사용자의 가독성 저하" |
| "자동화 테스트 없음" | "배포마다 회귀 오류 수동 확인 필요" |
팀 접근성 교육
기술적 수정만으로는 지속적인 접근성 유지가 어렵습니다.
개발팀 교육 (2시간):
- 접근성 이유 (법적/비즈니스/인간적)
- 자주 하는 실수 10가지
- 개발 중 확인하는 습관 (axe, 키보드 테스트)
디자인팀 교육 (2시간):
- 색상 대비 원칙
- 포커스 스타일 디자인
- 터치 타겟 크기
- 접근성 있는 컴포넌트 명세 작성법
기획팀 교육 (1시간):
- 어떤 사용자가 접근성이 필요한가
- 요구사항에 접근성 포함하는 방법
접근성 챔피언 제도
팀 내 접근성을 담당하는 "접근성 챔피언"을 지정합니다.
## 접근성 챔피언 역할
담당자: 김개발 (2026년 2분기)
### 책임
- 주간 axe 스캔 결과 검토
- 접근성 관련 PR 리뷰
- 분기 스크린리더 테스트 주도
- 팀 접근성 교육 자료 업데이트
### 권한
- 접근성 기준 미충족 PR 차단 권한
- 접근성 개선 공수를 스프린트에 포함할 수 있는 권한
단계별 실습
따라하기: 감사 보고서 작성
이전 챕터의 감사 결과를 바탕으로 보고서를 작성합니다.
- 5개 이상의 발견 사항 기록
- 비즈니스 영향 서술
- 단기/중기 개선 권고 작성
- 팀원에게 발표 자료로 변환
응용하기: KWCAG 2.2 적합성 선언
법적 준수를 위한 적합성 선언문 초안을 작성합니다.
## 접근성 적합성 선언
**기관명**: (회사명)
**웹사이트**: https://example.com
**선언일**: 2026년 4월 27일
이 웹사이트는 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2를
준수하기 위해 노력하고 있습니다.
### 준수 수준
- 부분 준수 (Level AA 기준)
- 알려진 미준수 항목: [목록]
- 개선 계획: [일정]
### 연락처
접근성 관련 불편 사항: [email protected]
정리와 확인
핵심 내용 요약
- 보고서 구조: 요약 → 위반 목록 → 권고 → 효과 예측 → 유지 방안
- 비즈니스 언어: 기술 용어를 사용자 영향과 비즈니스 리스크로 번역
- 팀 교육: 개발/디자인/기획 팀별 맞춤 교육
- 접근성 챔피언: 팀 내 접근성 담당자 지정
- 적합성 선언: 법적 요건 충족을 위한 공식 선언
확인 문제
문제 1. "aria-label 없는 아이콘 버튼"을 비즈니스 언어로 표현하면?
"이름 없는 버튼은 스크린리더 사용자가 버튼의 기능을 알 수 없어
시각장애인 고객이 해당 기능을 사용할 수 없습니다."
문제 2. 접근성 챔피언 제도의 장점은?
담당자가 명확하면 책임이 분산되지 않고 접근성 유지가 일관됩니다.
또한 접근성 지식이 팀 내에 축적되고 교육이 지속됩니다.
PART 10을 마쳤습니다. 다음 PART에서는 교재의 마무리로 웹접근성의 미래와 김개발의 성장을 마무리합니다.