스크린 리더 테스트 실전 — VoiceOver/NVDA로 내 앱 검증하기
접근성 시리즈
(5편)접근성 자동 검사 도구로 테스트하면 "문제 0건"이 나와요. 그런데 스크린 리더로 직접 써보면? 전혀 다른 세상이에요.
axe, Lighthouse 같은 자동 도구는 전체 접근성 문제의 30% 정도만 잡아요. 나머지 70%는 사람이 직접 써봐야 발견할 수 있는 문제예요. "버튼이라고 읽히긴 하는데 뭘 하는 버튼인지 모르겠다", "폼을 제출했는데 결과가 어디 있는지 모르겠다" 같은 것들이요.
오늘은 VoiceOver와 NVDA로 직접 앱을 테스트하는 방법을 공유할게요.
스크린 리더, 왜 직접 써봐야 하나
자동 검사 vs 수동 검사
자동 도구가 "이미지에 alt가 있다"는 확인할 수 있지만, "이 alt가 사용자에게 의미 있는 정보를 전달하는가"는 판단할 수 없어요.
VoiceOver 기본 조작 (Mac)
Mac을 쓰고 있다면 바로 테스트할 수 있어요. 별도 설치 없이 내장되어 있거든요.
시작과 종료
핵심 단축키
VoiceOver에서 VO는 Control + Option 키 조합이에요.
처음 VoiceOver 켰을 때
처음 켜면 당황스러워요. 모든 걸 다 읽으니까요. 이렇게 시작해보세요:
NVDA 기본 조작 (Windows)
Windows에서는 NVDA를 추천해요. 무료이고, 한국 사용자 점유율도 높아요.
설치
nvaccess.org에서 다운로드. 설치형과 포터블 모두 지원.
NVDA 핵심 단축키
NVDA에서 NVDA 키는 기본적으로 Insert 또는 Caps Lock이에요.
브라우저 모드 vs 포커스 모드
이게 NVDA의 가장 헷갈리는 부분이에요.
실전 테스트 시나리오
이제 실제로 테스트해볼게요. 아래 시나리오대로 해보면 대부분의 문제를 발견할 수 있어요.
시나리오 1: 페이지 구조 확인
// ❌ 스타일 때문에 헤딩 레벨을 바꿈
<h4 className="text-2xl font-bold">계좌 목록</h4>
// ✅ 올바른 레벨 + 스타일은 CSS로
<h2 className="text-lg">계좌 목록</h2>
헤딩 레벨은 문서 구조예요. 글자 크기를 바꾸고 싶으면 CSS를 쓰세요.
시나리오 2: 폼 입력 테스트
placeholder는 label이 아니에요. 입력을 시작하면 placeholder가 사라지면서 필드명을 잊게 되고, 스크린 리더에 따라 placeholder를 안 읽어주는 경우도 있어요.
시나리오 3: 동적 콘텐츠 알림
시나리오 4: 모달과 포커스
시나리오 5: 이미지와 아이콘
자주 발견되는 문제 TOP 10
실무에서 스크린 리더 테스트하면 반복적으로 나오는 문제들이에요.
| 순위 | 문제 | 증상 | 해결 |
|---|---|---|---|
| 1 | label 없는 입력 필드 | "편집 텍스트"로만 읽힘 | <Label> 연결 |
| 2 | <div onClick> 버튼 | Tab으로 도달 불가 | <button> 사용 |
| 3 | 무의미한 alt | "이미지", "사진" 등 | 내용 설명하는 alt |
| 4 | 모달 포커스 미관리 | 모달 뒤에 포커스 남음 | 포커스 트랩 구현 |
| 5 | 동적 업데이트 무알림 | 결과 바뀌어도 모름 | aria-live 사용 |
| 6 | "여기를 클릭하세요" 링크 | 링크 목록에서 구분 불가 | 목적지 설명하는 텍스트 |
| 7 | 헤딩 레벨 뒤죽박죽 | 구조 파악 불가 | 논리적 계층 유지 |
| 8 | display: none 콘텐츠 | 숨겼는데 읽힘/안 읽힘 | aria-hidden 적절 사용 |
| 9 | 커스텀 Select | Arrow 탐색 안 됨 | WAI-ARIA listbox 패턴 |
| 10 | 자동 재생 미디어 | 스크린 리더 음성을 덮음 | 자동 재생 금지 |
테스트 환경 세팅 팁
브라우저 조합
스크린 리더마다 궁합이 좋은 브라우저가 있어요.
음성 속도 조절
처음에는 느린 속도로 시작해요:
익숙해지면 속도를 올려보세요. 실제 스크린 리더 사용자는 2~3배속으로 듣는 경우가 많아요.
결과 기록 템플릿
이런 식으로 기록하면 개발자가 바로 수정할 수 있어요.
마무리
스크린 리더 테스트는 처음에 어색하지만, 30분만 투자하면 기본은 할 수 있어요. 그리고 한 번이라도 해보면 "아, 이래서 접근성이 중요하구나"가 체감이 돼요.
자동 검사 도구를 돌려서 "문제 0건"이 나오더라도, 스크린 리더로 한 번만 더 확인해보세요. 진짜 문제는 거기서 나와요.
다음 편에서는 이런 테스트 과정을 자동화하는 방법을 다뤄볼게요. axe + Storybook + CI 파이프라인으로 접근성을 디자인 시스템 레벨에서 관리하는 방법이에요.
관련 링크
시리즈
- 이전 편: 키보드 네비게이션 완전 가이드
- 다음 편: 디자인 시스템에서 접근성 자동화하기
HANUI
KRDS 기반 React 컴포넌트 라이브러리. 공공 웹 개발을 더 쉽게.