WCAG 감사 전문가의 진짜 일상: 접근성 지옥에서 살아남기
– UXaudit
POUR: 접근성의 4대 기둥이 무너질 때
WCAG 2.1의 핵심은 POUR 원칙이다.
🔍 Perceivable (인지 가능): 보이지 않으면 존재하지 않는다
❌ 문제 상황
<img src="important-chart.png" alt="2024년 매출 증가율 15% 보여주는 막대그래프. 1분기 5%, 2분기 12%, 3분기 18%, 4분기 예상 20%">
→ 스크린 리더: “차트” → 사용자: “뭔 차트? 뭘 보여주는 차트?”
✅ 개선 후
<img src="important-chart.png" alt="2024년 매출 증가율 15% 보여주는 막대그래프. 1분기 5%, 2분기 12%, 3분기 18%, 4분기 예상 20%">
→ 스크린 리더: 실제 의미 있는 정보 전달
가장 많이 만나는 문제가 색상만으로 정보를 전달하는 경우다.
| 일반적인 실수 | 올바른 방법 | 추가 고려사항 |
|---|---|---|
| 🔴 빨간색 = 에러 | 🔴❌ 빨간색 + X 아이콘 | 색맹 사용자 대응 |
| 📊 그래프 색상으로만 구분 | 📊 색상 + 패턴 + 레이블 | 프린트 시에도 구분 가능 |
| 💚 녹색 링크 | 💚굵은 녹색 밑줄 링크 | 저시력 사용자 고려 |
⚡ Operable (조작 가능): 마우스뿐만 아니라 키보드 옵션도 가능한가?
키보드 내비게이션 테스트를 처음 해봤을 때… 마우스 없이 웹사이트를 사용하는 게 이렇게 어려운 일인지 몰랐다.
🎯 키보드 테스트 시나리오
1. Tab으로 모든 요소 접근 가능한가? 2. Focus 순서가 논리적인가? 3. Focus indicator가 명확하게 보이는가? 4. 키보드 트랩은 없는가? 5. Skip link가 제공되는가?
특히 모달 창에서 문제가 많이 발생한다.
// ❌ 접근성 문제 있는 모달
function openModal() {
document.getElementById('modal').style.display = 'block';
// 포커스가 모달 밖으로 빠져나갈 수 있음
}
// ✅ 접근성 고려한 모달
function openModal() {
const modal = document.getElementById('modal');
modal.style.display = 'block';
modal.setAttribute('aria-modal', 'true');
modal.setAttribute('role', 'dialog');
// 첫 번째 포커스 가능한 요소로 이동
const firstFocusable = modal.querySelector('button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])');
firstFocusable?.focus();
// 배경 클릭 시 모달 닫기
modal.addEventListener('click', (e) => {
if (e.target === modal) closeModal();
});
}
🧠 Understandable 이해 가능도: 직관적인가?
가장 까다로운 영역이다. 기술적으로는 완벽해도 인지적으로 이해하기 어려우면 접근성이 떨어진다.
📝 폼 레이블의 함정
❌ 모호한 레이블 → “성명? 닉네임? 회사명?”
✅ 명확한 레이블
✅ 추가 도움말
🛡️ Robust (견고함): “모든 환경에서 작동해야 한다”
다양한 보조 기술과의 호환성을 테스트하는 부분이다. 시맨틱 HTML이 얼마나 중요한지 절실히 깨닫게 된다.
사용자 테스트
🎧 스크린 리더 사용자
처음 스크린 리더 사용자와 테스트를 진행했을 때 참 일부 장애가 있는 삶이란 얼마나 라이프 퀄리티가 차이나고 우리의 웹 환경이 배제적인가 다시 생각해보게 된다.
💡 스크린 리더 사용자 관찰 포인트
-
네비게이션 패턴
- 헤딩(H1, H2, H3)으로 빠르게 스캔
- 랜드마크 영역(main, nav, aside)으로 점프
- 링크 목록으로 페이지 구조 파악
-
인터랙션 방식
- Tab/Shift+Tab으로 순차 이동
- 화살표 키로 세부 내용 탐색
- 단축키 조합 활용 (NVDA: Insert+F7 링크 목록)
-
정보 처리 방식
- 순서대로 들어야 하므로 콘텐츠 구조가 중요
- 불필요한 정보는 건너뛰기 기능 필수
- 상태 변화는 즉시 음성으로 알림 필요
실제 테스트에서 발견한 문제들:
제품명
가격: 50,000원
할인가: 40,000원
제품명
50,000원
40,000원
📋 사용자 연구 질문의 기술
중립적이고 개방형 질문이 중요하다.
❌ 유도 질문 “이 버튼이 명확하게 보이나요?” → 답변 유도, 진짜 문제 파악 어려움
✅ 중립적 질문
“이 화면에서 다음 단계로 넘어가려면 어떻게 하시겠어요?”
→ 실제 사용 패턴과 어려움 파악 가능
✅ 추가 탐색 질문 “이 내용을 친구에게 설명한다면 어떻게 표현하시겠어요?” → 정보 전달의 명확성 확인
감사 도구들: 자동화의 한계와 인간의 필요성
다양한 자동화 도구를 써봤지만, 자동화만으로는 한계가 명확했다.
| 도구 | 장점 | 한계 | 추천 용도 |
|---|---|---|---|
| Axe-core | 빠른 스캔, 개발자 친화적 | 맥락 이해 불가 | 초기 스크리닝 |
| WAVE | 시각적 피드백 우수 | 동적 콘텐츠 한계 | 정적 페이지 분석 |
| Lighthouse | 성능과 함께 종합 진단 | 표면적 체크만 가능 | 전반적 품질 확인 |
| Color Oracle | 색맹 시뮬레이션 정확 | 색상 외 요소 무시 | 색상 접근성 전용 |
// 자동화 도구가 놓치는 예시 // ✅ 자동화: “버튼 있음” // ❌ 현실: 사용자가 “뭘 위한 버튼인지” 모름
// ✅ 자동화: “ALT 텍스트 있음”
// ❌ 현실: “무슨 그래프인지” 정보 없음
🎨 색상 대비 도구의 딜레마
WCAG 2.1의 4.5:1 비율을 기계적으로 적용하다 보면 때로는 디자인과 충돌한다.
/* WCAG 2.1 기준 통과하지만... */
.text-primary {
color: #004085; /* 진한 파란색 */
background: #ffffff; /* 흰색 */
/* 대비비: 9.64:1 (AA 통과) */
}
/* 하지만 브랜드 가이드라인은... */
.brand-text {
color: #6c63ff; /* 브랜드 보라색 */
background: #ffffff; /* 흰색 */
/* 대비비: 3.14:1 (AA 실패) */
}
이럴 때는 APCA(Accessible Perceptual Contrast Algorithm) 같은 차세대 기준을 참고하거나, 다른 방법으로 접근성을 확보해야한다.
/* 해결책: 색상 외 추가 단서 제공 */
.brand-text {
color: #6c63ff;
background: #ffffff;
font-weight: 600; /* 굵기로 가독성 보강 */
text-decoration: underline; /* 밑줄로 강조 */
}
감사 보고서: 개발자가 실제로 쓸 수 있는 문서 만들기
우선순위화의 기술
모든 문제를 나열하면 개발팀이 어디서부터 손댈지 모른다. 영향도와 구현 난이도로 매트릭스를 만든다.
🎯 접근성 이슈 우선순위 매트릭스
높은 영향도 + 쉬운 구현
├─ ALT 텍스트 누락 → 1순위
├─ 버튼 레이블 명확화 → 1순위
└─ 색상 대비 개선 → 1순위
높은 영향도 + 어려운 구현
├─ 키보드 내비게이션 전면 개편 → 2순위
├─ ARIA 라이브 영역 구현 → 2순위
└─ 복잡한 위젯 접근성 개선 → 2순위
낮은 영향도 + 쉬운 구현 ├─ HTML 유효성 오류 수정 → 3순위 └─ 메타 태그 개선 → 3순위
📝 실행 가능한 권장사항 작성
❌ 모호한 권장사항 “접근성을 개선하세요” “사용자 경험을 향상시키세요”
✅ 구체적인 액션 아이템
문제: 로그인 버튼에 키보드로 접근할 수 없음
위치: 헤더 네비게이션 영역
해결방법:
-
<div class="login-btn">을<button type="button">으로 변경 - CSS에서
:focus스타일 추가 - 테스트: Tab 키로 접근 후 Enter/Space로 동작 확인
예상 소요시간: 30분 테스트 방법: 마우스 연결 해제 후 키보드만으로 로그인 과정 진행
🔄 후속 감사의 중요성
처음 감사할 때 “한 번 하면 끝”이라고 생각했는데, 후속 감사가 더 중요하다
📅 감사 사이클
1차 감사 (초기 진단)
├─ 전체적인 문제 파악
├─ 우선순위 설정
└─ 개선 계획 수립
↓ (2-4주 개발 기간)
2차 감사 (개선사항 검증) ├─ 수정된 항목 재테스트 ├─ 새로 발견된 문제 추가 └─ 사용자 테스트 실시
↓ (지속적인 개선)
정기 감사 (품질 유지) ├─ 새로운 기능의 접근성 검증 ├─ 가이드라인 업데이트 반영 └─ 팀 교육 및 프로세스 개선
접근성 감사의 진짜 어려움들
주관적 판단의 영역
기술적 기준은 명확하지만, 사용성과 직관성은 주관적이다.
🤔 애매한 판단 상황들
-
복잡한 데이터 테이블
- 모든 셀에 헤더 연결 vs. 단순화된 구조
- 정확성 vs. 사용편의성의 트레이드오프
-
인터랙티브 위젯
- 표준 HTML vs. 커스텀 ARIA 위젯
- 익숙함 vs. 혁신의 균형
-
멀티미디어 콘텐츠
- 상세한 설명 vs. 간결한 요약
- 정보 전달 vs. 인지 부하의 고려
🏢 조직 문화와의 충돌
가장 큰 장벽은 기술적 문제가 아니라 조직의 우선순위
💼 현실적 제약들
개발팀: “접근성 개선하면 일정 늦어져요”
디자인팀: “브랜드 가이드라인과 맞지 않아요”
기획팀: “사용자 중에 그런 분들이 얼마나 될까요?”
경영진: “ROI가 명확하지 않네요”
→ 접근성 전문가의 역할 = 기술적 해결책 + 비즈니스 설득 + 교육
배운 것들: 접근성은 기술이 아니라 철학
🌍 포용적 디자인의 관점 전환
접근성을 **“장애인을 위한 특별한 배려”**로 보는 게 아니라, **“모든 사용자를 위한 더 나은 경험”**으로 접근
🎯 접근성 개선의 부수 효과
키보드 내비게이션 개선 ├─ 장애인: 마우스 없이 사용 가능 ├─ 파워유저: 단축키로 빠른 조작 └─ 모바일: 터치 정확도 향상
명확한 레이블과 설명
├─ 시각장애인: 스크린 리더 이해 향상
├─ 인지장애인: 명확한 지시사항
├─ 비네이티브: 쉬운 언어로 이해
└─ 모든 사용자: 직관적인 인터페이스
📚 지속적인 학습의 필요성
웹 기술과 보조 기술이 계속 발전하면서 새로운 패턴과 기준이 등장한다.
🔄 변화하는 접근성 환경
WCAG 2.1 → WCAG 2.2 → WCAG 3.0 (진행중)
├─ 모바일 접근성 강화 ├─ 인지 접근성 확대 └─ 새로운 평가 방법론 (APCA 등)
새로운 보조 기술
├─ 음성 인터페이스 (Alexa, Siri) ├─ 눈동자 추적 기술 └─ AI 기반 자동 설명 생성
접근성 감사를 고려하고 있다면? 자동화 도구만 믿지 말고, 실제 사용자와의 테스트를 반드시 포함시켜라. 그리고 한 번의 감사로 끝나는 게 아니라 지속적인 개선 프로세스로 접근하는 게 중요하다.