스크린 리더로 테스트하기

스크린 리더 테스트란

스크린 리더는 화면 내용을 음성이나 점자로 내보내는 보조 기술이다. 브라우저가 만든 접근성 트리를 읽으므로, 스크린 리더로 들어 보면 눈으로는 놓치는 문제가 드러난다.

스크린 리더 테스트는 접근성 평가의 마지막 단계다. 자동 검사와 키보드 점검을 먼저 끝내고 들어간다.

스크린 리더 사용자는 어떻게 읽나

작성자는 사용자가 어떤 탐색 방법을 쓸지 고를 수 없다. 그래서 제목, 랜드마크, 링크 텍스트, 폼 라벨 모두가 제 역할을 해야 한다. 구조 설계는 접근 가능한 페이지 구조에 있다.

설문으로 본 실제 사용 (WebAIM 설문 #11, 2026)

WebAIM이 2026년 7~8월 스크린 리더 사용자 1,780명에게 받은 설문이다. 표본을 통제하지 않았으므로 경향으로 읽는다.

• 제목은 가장 중요한 탐색 수단이다. 긴 페이지에서 응답자의 67.8%가 제목 이동부터 쓴다.
• 여러 스크린 리더를 섞어 쓰는 사용자가 많다. 특정 제품의 동작에 맞추지 말고 표준 마크업을 따른다.
• 사용자 대부분이 AI로 이미지 설명을 보충하지만, 그것이 alt를 빼도 된다는 뜻은 아니다. PDF는 85.6%가 접근성 문제가 있을 가능성이 높다고 답했다.

무엇으로 테스트하나

스크린 리더는 함께 맞춰 만든 브라우저와 쓸 때 가장 잘 동작한다. 엉뚱한 조합으로 테스트하면 실제 사용자에게는 없는 버그를 만나거나 반대로 놓친다.

• 최소 구성: 데스크톱은 NVDA 또는 JAWS 하나, 모바일은 iOS VoiceOver. Android 사용자가 많은 서비스면 TalkBack을 더한다.
• 단순한 콘텐츠는 한두 개로 충분하다. JavaScript 위젯, PDF처럼 복잡한 콘텐츠는 여러 조합에서 차이가 난다.
• 대부분의 차이는 링크를 「링크」로 알리느냐 같은 표면적인 것이다. 지원 기술·버그 차이는 실제 사용자가 많이 쓰는 조합(위 설문)으로 확인한다.
• Narrator는 주 스크린 리더로는 거의 쓰이지 않지만 설치 없이 바로 쓸 수 있어 테스트에 쓸 만하다.
• 테스트의 목표는 사용자 경험을 흉내 내는 것이 아니라 코드 문제를 찾는 것이다. 실제 사용자와 이야기해서 얻는 통찰은 이것과 다르고, 둘 다 필요하다.
• 완벽히 익힐 필요는 없다. 아래 표의 단축키만으로 기본 점검이 된다. 오히려 숙련자는 초보 사용자가 막히는 곳을 놓치기도 한다. 다만 사용법을 모르는 채로 테스트하면, 조작 실수를 접근성 문제로 오판하기 쉽다.

데스크톱 단축키

수정 키는 스크린 리더마다 이름이 다르다. NVDA·JAWS·Narrator는 Insert 또는 Caps Lock(설정에서 Caps Lock으로 바꾸면 손이 편하다. Caps Lock 원래 기능은 두 번 눌러 쓴다), VoiceOver는 VO = Control + Option이다. 아래 표에서 NVDA, JAWS, Narrator, VO는 그 수정 키를 뜻한다.

두 가지 모드

Windows 스크린 리더는 읽기 모드와 입력 모드를 오간다. 이름은 다르지만 원리는 같다.

• 텍스트 입력란이나 위젯으로 Tab하면 자동으로 입력 모드가 되고, NVDA·JAWS는 높은 비프음으로 알린다. 나오면 낮은 비프음과 함께 읽기 모드로 돌아온다.
• tree, slider, grid, tabpanel, menu 같은 위젯 role은 스크린 리더를 입력(애플리케이션) 모드로 바꾼다. 그러면 H·F 같은 탐색 키가 페이지로 넘어가므로, 위젯이 role에 맞는 키 조작을 모두 구현했는지와 사용자가 모드가 바뀐 것을 알 수 있는지 확인한다. 위젯은 Windows 스크린 리더를 켠 상태와 끈 상태 모두로 시험한다.
• 잘 만든 위젯이라면 수동 전환이 필요 없다. 테스트 중에 모드를 직접 바꿔야만 조작된다면 위젯의 role이나 키보드 처리를 의심한다.

스크린 리더별 메모

• NVDA: Tools → Speech Viewer를 켜면 읽은 내용이 글자로 나와 기록·공유하기 좋다. 입력한 글자 읽기는 끄고, 문장부호 수준과 문서 서식 설정은 기본값을 둔다.
• JAWS: 노트북에서도 키보드 배치를 Desktop으로 둔다. Laptop 배치에서는 일부 명령이 동작하지 않는다. JAWS + F1은 현재 요소 도움말이다.
• VoiceOver: Safari와 가장 잘 맞는다. Safari 설정 → 고급에서 「Tab 키로 각 항목 강조」를 켠다. 로터(VO + U)에서 좌우 방향키로 제목·링크·폼 컨트롤 같은 목록을 고르고(페이지에 랜드마크가 있으면 랜드마크 목록도 나온다), 글자를 치면 목록이 걸러진다(예: 제목 목록에서 2를 치면 h2만). 표에서는 VO + C가 열 헤더, VO + R이 행 헤더를 읽는다. VO + Shift + F11 화면 가리개(Screen Curtain)로 화면을 끄고 소리만으로 테스트한다.
• Narrator: 설정(Win + Ctrl + N)에서 상세 수준은 바꾸지 않는다. alt가 없는 이미지는 「unlabeled graphic」으로 읽는다.
• Dolphin: 시작은 NumPad +, 중지는 Esc, 랜드마크는 ;, Dolphin + Tab이 요소 찾기(Item Finder)다. 링크 목록 Dolphin + 1, 제목 목록 Dolphin + 2.

모바일 제스처

• TalkBack의 세 손가락 제스처는 TalkBack 9.1 이상에서 된다. 세 손가락 탭으로 메뉴가 열리면 지원하는 기기다. 삼성 기기는 자체 TalkBack을 쓰므로 기기 안내를 따른다.
• iOS 로터에 넣을 항목은 설정 → VoiceOver → 로터에서 고른다. 테스트에는 제목, 링크, 폼 컨트롤, 표, 랜드마크, 버튼, 이미지, 줄, 말하기 속도를 켜 둔다.
• 손을 화면 위로 끌면 손가락 아래 항목을 읽는다(터치 탐색). 화면을 보지 않고 해 보면 실제 경험에 가깝다.
• 블루투스 키보드를 연결해 모바일에서도 키보드 접근을 확인한다. 모바일 입력 방식 기준(WCAG 2.5)도 함께 본다.

테스트 흐름

flowchart TB
  S1["1. 스크린 리더를 켜고 페이지를 새로 연다"] --> S2["2. 처음부터 읽기<br>페이지 제목, 읽는 순서, 대체 텍스트, 불필요한 반복을 듣는다"]
  S2 --> S3["3. 제목 목록<br>제목만으로 페이지 구성이 보이는가, 단계가 맞는가"]
  S3 --> S4["4. 랜드마크 이동<br>main·nav·search 등이 있고, 같은 종류가 여럿이면 이름이 다른가"]
  S4 --> S5["5. 링크 목록<br>문맥 없이도 목적을 알 수 있는가"]
  S5 --> S6["6. 폼<br>Tab으로 돌며 라벨·필수·그룹(legend)이 읽히는가, 오류를 내고 알림을 듣는다"]
  S6 --> S7["7. 위젯·동적 변화<br>펼침/접힘 상태, 대화상자 포커스, 라이브 영역 알림"]
  S7 --> S8["8. 표<br>셀을 이동할 때 행·열 헤더가 함께 읽히는가"]

이름이 이상하게 들리면 DevTools Accessibility 패널에서 계산된 이름을 확인한다(ARIA 기초). 라벨·오류 연결은 접근 가능한 폼에, 위젯 상태는 접근 가능한 위젯에 있다.

스크린 리더로만 드러나는 문제

자동 검사와 키보드·시각 점검을 모두 통과한 페이지에서도 귀로 들어야 나오는 문제가 있다.

실제 사용자와 테스트할 때

• 시각장애인 사용자의 피드백은 값지지만, 한 사람의 의견을 대표로 삼지 않는다. 숙련도, 개인 설정, 쓰는 제품이 제각각이다.
• 스크린 리더 사용자는 없는 콘텐츠를 알아채지 못할 수 있다. JavaScript 오류로 본문이 통째로 안 읽혀도 원래 없던 것으로 여긴다. 반대로 비장애인 테스터는 화면을 보느라 읽히지 않는 것을 놓친다. 둘을 함께 쓴다.
• 정식 사용자 연구는 비용이 크므로 사이트 개편, 새 인터페이스, 종합 감사 때 한다. 평소에는 동료나 커뮤니티에 주기적으로 짧은 피드백을 받는다. 진행 방법은 웹 접근성의 사용성 테스트 절을 본다.
• 스크린 리더 사용자만 보지 않는다. 저시력, 운동, 청각, 인지 장애 사용자의 요구도 같은 무게다(장애 유형과 웹 사용).

정리

• 스크린 리더 테스트는 읽는 순서, 이름, 구조, 동적 변화를 귀로 확인하는 단계다.
• 데스크톱 NVDA·JAWS 중 하나와 iOS VoiceOver면 기본 구성이 된다. 사용자 조합은 JAWS·NVDA + Chrome이 가장 많다.
• 익힐 것은 읽기 시작·중지, 제목·랜드마크·폼 이동, 요소 목록, 모드 전환 정도다.
• 테스트 중 모드를 수동으로 바꿔야 한다면 위젯이 잘못 만들어졌을 가능성이 크다.
• 사용자 대부분이 제목으로 길을 찾는다. 제목 구조가 스크린 리더 경험의 뼈대다.

관련 노트: 접근성 평가 방법과 도구, 웹 접근성, ARIA 기초, 접근 가능한 페이지 구조, 접근성 기반 테스트, 장애 유형과 웹 사용