UX 감사원의 실제 업무: 체크리스트를 넘어선 심층 분석 프로세스
서론: UX 감사원은 단순한 체크리스트 검사원이 아니다
많은 사람들이 UX 감사원을 ‘체크리스트를 돌리는 검사원’으로 생각한다. 하지만 실제 UX 감사원의 업무는 훨씬 복잡하고 심층적이다. 이 글은 실제 UX 감사원이 어떤 프로세스로 업무를 수행하는지, 특히 접근성 감사에 초점을 맞춰 상세히 다룬다. 특히 최근 EAA가 강력한 Accessibility requirement를 반영하는 legislation을 발효하면서 전 세계의 웹 생태계들도 이를 간접적으로 영향이 받을 것이니 더욱 자세하고 정확히 UX Audit을 실행할 필요성이 앞으로 더욱 증가할 것이다.
접근성? 그냥 ALT 텍스트 넣으면 되는 거 아닌가요?
처음 웹 접근성 감사 의뢰를 받았을 때 내 생각이었다. “어차피 이미지에 ALT 텍스트 몇 개 추가하고, 색상 대비 좀 조절하면 끝나는 일 아닌가?”
하지만 WCAG 2.1 기준으로 실제 감사를 진행하면서 깨달았다. 이건 단순한 체크리스트 작업이 아니라 인간의 다양성을 이해하는 복잡한 엔지니어링 문제였다는 걸 말이다.
Phase 1: 진단 및 범위 설정 (Scoping & Diagnostics)
1.1 착수 회의 (Kick-off Meeting)
목적: 프로젝트의 맥락과 목표를 명확히 이해하고, 감사 범위를 설정한다.
핵심 질문들:
- 클라이언트의 비즈니스 목표는 무엇인가? (예: NSW 정부 입찰 통과)
- 대상 제품의 범위는 어디까지인가? (웹앱/플랫폼/모바일 앱)
- 핵심 사용자 여정(Key User Journeys)은 무엇인가?
- 예상되는 사용자 그룹은 누구인가? (장애 유형별)
산출물:
- 프로젝트 범위 문서
- 감사 계획서
- 일정 및 마일스톤
1.2 문서 검토 및 준비
검토 대상:
- EN 301 549 (또는 AS EN 301 549) 표준 문서
- 현재 디자인 파일 (Figma, Sketch)
- 코드 저장소 접근 권한 (Git)
- 기존 접근성 관련 문서
준비 사항:
- 감사 도구 설정 (Axe, WAVE, Lighthouse)
- 스크린 리더 환경 구성 (VoiceOver, Narrator, NVDA)
- 키보드 네비게이션 테스트 환경
Phase 2: 다층적 감사 실행 (Multi-Layered Audit Execution)
2.1 자동화 감사 (Automated Scan)
목적: 명백한 접근성 위반 사항을 빠르게 식별하고 전체적인 현황을 파악한다.
사용 도구:
- Axe DevTools: Chrome 확장 프로그램으로 실시간 감사
- WAVE: 웹 접근성 평가 도구
- Lighthouse: Google의 자동화 감사 도구
- pa11y: 커맨드라인 기반 자동화 도구
검사 항목:
graph TD
A[자동화 감사] --> B[명암비 검사]
A --> C[대체 텍스트 검사]
A --> D[시맨틱 HTML 검사]
A --> E[ARIA 속성 검사]
A --> F[키보드 접근성 검사]
B --> G[색상 대비 4.5:1 이상]
C --> H[alt 속성 누락 확인]
D --> I[의미있는 HTML 태그 사용]
E --> J[ARIA 속성 유효성]
F --> K[키보드 포커스 가능]
산출물:
- 자동화 감사 보고서
- 우선순위별 이슈 목록
- Low-hanging fruit 식별
2.2 수동 전문가 감사 (Manual Heuristic & AT Audit)
목적: 자동화 도구가 잡지 못하는 맥락적, 경험적 문제를 발견한다.
검사 방법:
1. 키보드 네비게이션 테스트
## 키보드 테스트 체크리스트
### 기본 네비게이션
- [ ] Tab 키로 모든 인터랙티브 요소에 접근 가능
- [ ] Shift+Tab으로 역방향 네비게이션 가능
- [ ] Enter/Space로 버튼, 링크 활성화 가능
- [ ] 화살표 키로 드롭다운, 메뉴 조작 가능
### 포커스 관리
- [ ] 포커스가 시각적으로 명확히 표시됨
- [ ] 포커스 순서가 논리적임
- [ ] 모달 열릴 때 포커스가 모달로 이동
- [ ] 모달 닫힐 때 포커스가 원래 위치로 복귀
### 키보드 단축키
- [ ] Esc 키로 모달, 팝업 닫기 가능
- [ ] Ctrl+M으로 메뉴 접근 가능
- [ ] Ctrl+F로 검색 기능 접근 가능
2. 스크린 리더 테스트
## 스크린 리더 테스트 시나리오
### VoiceOver (macOS)
1. 페이지 로드 후 제목 확인
2. 네비게이션 메뉴 탐색
3. 주요 콘텐츠 영역으로 이동
4. 폼 필드 입력 및 오류 메시지 확인
5. 버튼 및 링크의 목적 이해
### Narrator (Windows)
1. 페이지 구조 파악
2. 랜드마크 역할 확인
3. 헤딩 계층 구조 확인
4. 테이블 데이터 이해
5. 동적 콘텐츠 변경 감지
3. 시각적 접근성 테스트
- 색맹 사용자 관점에서 색상만으로 정보 전달되는지 확인
- 고대비 모드에서의 가독성 테스트
- 확대/축소 시 레이아웃 깨짐 현상 확인
2.3 디자인 시스템 감사 (Design System & Figma Review)
목적: 개별 페이지의 문제를 넘어 문제의 근원을 해결한다.
검사 항목:
1. 컬러 시스템 검토
/* 컬러 대비 계산 예시 */
:root {
--primary-text: #333333;
--primary-bg: #FFFFFF;
/* 대비율: 12.63:1 (AA 기준 충족) */
--secondary-text: #666666;
--secondary-bg: #F5F5F5;
/* 대비율: 4.5:1 (AA 기준 충족) */
--error-text: #D32F2F;
--error-bg: #FFEBEE;
/* 대비율: 3.2:1 (AA 기준 미달) */
}
2. 타이포그래피 시스템 검토
/* 접근성 고려한 타이포그래피 */
:root {
--font-size-base: 16px; /* 최소 16px */
--line-height-base: 1.5; /* 최소 1.4 */
--font-weight-normal: 400;
--font-weight-bold: 700;
}
/* 사용자 설정 존중 */
@media (prefers-reduced-motion: reduce) {
* {
animation-duration: 0.01ms !important;
transition-duration: 0.01ms !important;
}
}
3. 컴포넌트 상태 디자인 검토
## 컴포넌트 상태 체크리스트
### 버튼 컴포넌트
- [ ] Default 상태: 명확한 시각적 표현
- [ ] Hover 상태: 포인터 커서 변경
- [ ] Focus 상태: 명확한 아웃라인 (2px 이상)
- [ ] Active 상태: 클릭 피드백
- [ ] Disabled 상태: 비활성화 표시
- [ ] Loading 상태: 로딩 인디케이터
### 입력 필드
- [ ] Label과 필드 연결 (for/id)
- [ ] Placeholder 텍스트 (보조 정보)
- [ ] Error 상태: 오류 메시지 표시
- [ ] Success 상태: 성공 피드백
- [ ] Required 표시: 필수 필드 명시
2.4 프론트엔드 코드 감사 (Frontend Code Review)
목적: 디자이너가 의도한 접근성이 코드로 실제로 구현되었는지 검증한다.
검사 항목:
1. 시맨틱 HTML 구조
<!-- 잘못된 예시 -->
<div class="button" onclick="submit()">제출</div>
<!-- 올바른 예시 -->
<button type="submit" class="btn btn-primary">제출</button>
2. ARIA 속성 검토
<!-- 동적 콘텐츠 예시 -->
<div class="modal" role="dialog" aria-labelledby="modal-title" aria-describedby="modal-description">
<h2 id="modal-title">확인</h2>
<p id="modal-description">정말 삭제하시겠습니까?</p>
<button aria-label="삭제 확인">확인</button>
<button aria-label="삭제 취소">취소</button>
</div>
3. 키보드 이벤트 핸들링
// 키보드 접근성 고려한 이벤트 핸들링
const handleKeyDown = (event) => {
if (event.key === 'Enter' || event.key === ' ') {
event.preventDefault();
handleClick();
}
};
const handleClick = () => {
// 클릭 로직
};
// 마우스와 키보드 모두 지원
element.addEventListener('click', handleClick);
element.addEventListener('keydown', handleKeyDown);
Phase 3: 보고 및 컨설팅 (Reporting & Advisory)
3.1 Gap Analysis & Action Plan 보고서 작성
보고서 구조:
1. Executive Summary
## 접근성 준수 현황 요약
### 전체 준수율: 67% (AA 기준)
- ✅ 충족: 23개 항목
- ⚠️ 부분 충족: 8개 항목
- ❌ 미충족: 12개 항목
### 시급 개선 필요 항목 (Top 3)
1. 색상 대비 부족 (12개 요소)
2. 키보드 네비게이션 불가능 (5개 요소)
3. 스크린 리더 호환성 문제 (8개 요소)
### 예상 개선 효과
- 접근성 준수율: 67% → 95%
- 사용자 만족도: 15% 향상 예상
- 법적 리스크: 80% 감소 예상
2. Detailed Findings
## 상세 발견사항
### EN 301 549 Section 9.1.1.1 (키보드 접근성)
**문제 현상**:
- 모달 다이얼로그에서 Tab 키로 배경 요소에 접근 가능
- 키보드 포커스가 시각적으로 표시되지 않음
**사용자 영향**:
- 키보드 사용자가 모달 외부로 포커스가 이동하여 혼란
- 스크린 리더 사용자가 현재 위치 파악 불가
**개선 권장**:
```css
/* 포커스 트랩 구현 */
.modal {
position: fixed;
z-index: 1000;
}
.modal:focus-within {
outline: 2px solid #007bff;
}
// 키보드 포커스 관리
const trapFocus = (element) => {
const focusableElements = element.querySelectorAll(
'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
);
const firstElement = focusableElements[0];
const lastElement = focusableElements[focusableElements.length - 1];
element.addEventListener('keydown', (e) => {
if (e.key === 'Tab') {
if (e.shiftKey) {
if (document.activeElement === firstElement) {
e.preventDefault();
lastElement.focus();
}
} else {
if (document.activeElement === lastElement) {
e.preventDefault();
firstElement.focus();
}
}
}
});
};
**3. Prioritized Roadmap**
```mermaid
graph TD
A[접근성 이슈] --> B[영향도 분석]
A --> C[수정 용이성 분석]
B --> D[높음: 사용자 경험 중대 영향]
B --> E[중간: 부분적 사용성 저하]
B --> F[낮음: 미미한 영향]
C --> G[높음: 1-2일 내 수정 가능]
C --> H[중간: 1주 내 수정 가능]
C --> I[낮음: 1개월 내 수정 가능]
D --> J[P0: 즉시 수정]
E --> K[P1: 1주 내 수정]
F --> L[P2: 1개월 내 수정]
3.2 결과 보고 및 워크숍
워크숍 구성:
1. 발견사항 공유 (30분)
- 주요 이슈 3-5개 선별하여 시연
- 실제 사용자 관점에서의 문제점 설명
- 개선 후 예상 효과 시연
2. 솔루션 워크숍 (60분)
- 디자이너와 함께 Figma에서 수정 작업
- 개발자와 함께 코드 수정 실습
- 접근성 테스트 방법 교육
3. Q&A 및 다음 단계 (30분)
- 팀원들의 질문 응답
- 개선 로드맵 논의
- 후속 지원 계획 수립
KR-Memo-WCAG-Audit-theQA-process-gap-from-Expert
실제 업무 시나리오: NSW 정부 입찰 프로젝트
시나리오: 정부 웹사이트 접근성 감사
클라이언트: NSW 정부 기관
목표: EN 301 549 준수를 통한 정부 입찰 통과
기간: 2주
실제 감사 과정:
Week 1: 진단 및 분석
- 착수 회의: 정부 표준 요구사항 확인
- 자동화 감사: 전체 사이트 스캔
- 수동 감사: 핵심 서비스 5개 페이지 심층 분석
- 디자인 시스템 검토: Figma 라이브러리 분석
Week 2: 보고 및 컨설팅
- 상세 보고서 작성 (50페이지)
- 정부 담당자 대상 결과 발표
- 개발팀 대상 기술 워크숍 진행
- 개선 로드맵 수립
주요 발견사항:
- 전체 준수율: 45% → 목표: 95%
- 시급 개선 항목: 23개
- 예상 개선 기간: 3개월
결론: UX 감사원의 진정한 가치
UX 감사원은 단순한 체크리스트 검사원이 아니다. 그들은 사용자 경험의 전문가로서, 기술적 문제를 넘어서 실제 사용자들이 겪는 어려움을 이해하고 해결책을 제시하는 컨설턴트다.
특히 접근성 감사에서는 자동화 도구의 한계를 인식하고, 실제 사용자의 관점에서 문제를 발견하며, 디자인과 개발 팀이 즉시 행동할 수 있는 구체적인 솔루션을 제공하는 것이 핵심이다.
이러한 다층적 접근법을 통해 UX 감사원은 단순한 문제 발견을 넘어서, 조직의 디지털 포용성(Digital Inclusion) 향상에 실질적으로 기여할 수 있다.
부록: UX 감사 도구 및 템플릿
A. 자동화 도구 체크리스트
# 자동화 감사 도구 설정
## 필수 도구
- [ ] Axe DevTools (Chrome 확장)
- [ ] WAVE (웹 접근성 평가)
- [ ] Lighthouse (성능 + 접근성)
- [ ] pa11y (커맨드라인)
## 설정 사항
- [ ] 브라우저 확장 프로그램 설치
- [ ] 커맨드라인 도구 설치
- [ ] CI/CD 파이프라인 통합
- [ ] 정기적 자동 감사 스케줄링
B. 수동 감사 템플릿
# 수동 접근성 감사 템플릿
## 페이지 정보
- URL:
- 감사 날짜:
- 감사자:
## 키보드 네비게이션
- [ ] 모든 인터랙티브 요소 접근 가능
- [ ] 포커스 순서 논리적
- [ ] 포커스 시각적 표시
- [ ] 키보드 단축키 작동
## 스크린 리더 호환성
- [ ] 페이지 제목 명확
- [ ] 랜드마크 역할 적절
- [ ] 헤딩 계층 구조
- [ ] 링크 목적 명확
- [ ] 이미지 대체 텍스트
## 시각적 접근성
- [ ] 색상 대비 충족
- [ ] 색상만으로 정보 전달 안함
- [ ] 고대비 모드 지원
- [ ] 확대/축소 시 레이아웃 유지
이러한 체계적인 접근법을 통해 UX 감사원은 단순한 검사원을 넘어서, 조직의 디지털 포용성 향상에 실질적으로 기여할 수 있다.