NVDA 스크린 리더 실습 — 브라우즈·포커스 모드, 검증 시나리오 6종, 포커스·레이블·대체 텍스트·라이브 리전 결함 보고

개념

왜 직접 켜 보는가

레슨 5에서 성공 기준을 판정값 네 종류로 나누고, 자동 도구가 커버하는 항목과 사람이 봐야 하는 항목을 갈랐다. 오른쪽 목록 — 대체 텍스트가 의미를 전달하는가, 포커스 순서가 의미 순서와 맞는가 — 은 판정 도구가 필요하다. 그 도구가 스크린 리더다.

이유는 단순하다. 화면에 보이는 것과 보조기술에 전달되는 것이 다르기 때문이다.

[화면]        [ 장바구니 담기 ]  ← 사람은 버튼으로 읽는다
[DOM]         <div class="btn" onclick="...">장바구니 담기</div>
[NVDA 낭독]   "장바구니 담기"    ← 역할이 없다. 버튼인지 모르고, Tab 으로 닿지도 않는다

세 줄이 다르다는 사실은 화면을 들여다봐도 안 보인다. 스크린 리더를 켜면 세 번째 줄이 문자열로 나오고, 그 문자열이 결함 리포트의 증거가 된다.

왜 NVDA인가, 그리고 이 레슨의 범위

데스크톱 선택지는 넷이다. NVDA(Windows, 무료·오픈소스, NV Access) 는 팀 전체가 같은 환경을 맞추기 쉬워 정본 조합으로 쓰기 좋다. JAWS(Windows, 상용) 는 국내 공공·금융 실사용자 비중이 있어 2차 확인 대상이 되고, 내레이터(Windows 내장) 는 설치 없이 급히 볼 때, VoiceOver(macOS) 는 Safari 조합 확인에 쓴다.

이 레슨은 NVDA + Chrome 조합 으로 절차를 고정한다. 모바일 플랫폼 특성 — TalkBack·VoiceOver의 제스처 체계, 접근성 서비스 동작, 터치 대상 크기 — 은 모듈 52(모바일 접근성)에서 다룬다. 여기서 모바일을 흉내 내면 둘 다 얕아진다.

검증 환경을 먼저 고정한다

결함 리포트가 재현되지 않는 가장 흔한 원인이 환경 불일치다. 리포트 상단에 네 줄을 고정한다.

스크린 리더   NVDA 2026.x (버전 숫자를 그대로 적는다)
브라우저      Chrome 1xx
OS            Windows 11 23H2
설정          기본 설정 / 키보드 배열: 데스크톱(Desktop)

설정 줄이 특히 중요하다. NVDA는 설정 프로파일에 따라 낭독 내용이 달라진다. 팀 검증용 프로파일을 공유하거나 "설치 직후 기본 설정" 을 기준으로 못 박는다. 낭독 내용을 글자로 남기려면 음성 뷰어(Speech Viewer) 를 켠다 — NVDA+N 메뉴의 도구(Extra Tools) 안에 있고, 출력된 줄을 그대로 복사해 결함 리포트의 "실제 낭독" 칸에 붙이면 증거가 완성된다.

NVDA 키 — 모디파이어와 두 가지 배열

기본 NVDA 모디파이어 키는 Insert 와 숫자패드 Insert 다(CapsLock 은 설정에서 추가 지정할 수 있으나 기본값이 아니다). 키보드 배열은 데스크톱(Desktop)이 기본 이고 숫자패드를 많이 쓴다 — 숫자패드가 없는 노트북이라면 랩톱(Laptop) 배열로 바꾼다.

브라우즈 모드와 포커스 모드 — 여기서 갈린다

이 구분을 모르면 검증이 전부 어긋난다.

전환은 NVDA+Space 이지만 보통은 자동으로 전환된다 — 입력창에 포커스가 들어가면 포커스 모드로, 빠져나오면 브라우즈 모드로 바뀐다.

QA가 이걸 알아야 하는 이유는 자동 전환이 역할(role)을 근거로 일어나기 때문이다. <div> 로 만든 커스텀 콤보박스에 역할이 없으면 포커스 모드로 전환되지 않고, 화살표 키로 항목을 고르려 해도 NVDA가 그 키를 탐색 명령으로 먹어 버린다. 마우스로는 잘 동작하는 위젯이 스크린 리더에서만 조작 불가 가 되는 전형적 결함이고, 4.1.2 Name, Role, Value 부적합이다.

단일 문자 탐색 — 구조를 빠르게 검증하는 수단

브라우즈 모드에서 글자 하나로 같은 유형의 다음 요소로 점프한다. Shift 를 더하면 역방향이다.

h 제목   1~9 해당 레벨 제목   l 목록   i 목록 항목   t 표   d 랜드마크   g 그래픽
k 링크   u 방문 안 한 링크    v 방문한 링크        n 링크 아닌 텍스트   p 문단
f 폼 컨트롤   e 편집창   b 버튼   x 체크박스   c 콤보박스   r 라디오 버튼
q 인용문   s 구분선   o 임베디드 객체   a 주석   w 맞춤법 오류
쉼표(,) 컨테이너 끝으로 / Shift+쉼표 컨테이너 시작으로

실무에서 가장 많이 쓰는 건 h, b, f, g, d 다섯 개다. 이 다섯 개로 한 화면을 훑으면 구조 결함의 대부분이 10분 안에 드러난다.

NVDA+F7 의 요소 목록 은 링크·제목 등을 종류별로 모아 보여 준다. 제목 목록이 곧 문서의 목차이므로, 목차가 말이 되지 않으면 1.3.1 Info and Relationships 부적합 이다.

검증 시나리오 6종

각 시나리오는 "무엇을 누르고, 무엇을 듣고, 무엇을 판정하는가" 세 줄로 고정한다.

시나리오 1 — 구조 훑기 (1.3.1, 2.4.6)

누른다  NVDA+F7 → 제목 목록. 이어서 h 를 반복해 문서를 위에서 아래로 훑는다
듣는다  제목 레벨과 텍스트. "제목 레벨 1 주문 상세" 형태
판정    레벨 건너뜀(h1 다음 h3), 시각적으로 제목인데 목록에 없음,
        "제목"이라는 이름의 제목, 목차가 화면 구조와 다름 → 부적합

시나리오 2 — 포커스 순서와 가시성 (2.4.3, 2.4.7, 2.4.11)

누른다  주소창에서 F6 또는 페이지 클릭 후 Tab 을 끝까지 반복
듣는다  이동할 때마다 NVDA+Tab 으로 현재 포커스 확인
판정    순서가 시각 순서와 어긋남 → 2.4.3
        포커스 표시가 화면에 안 보임 → 2.4.7
        고정 헤더·쿠키 배너에 가려짐 → 2.4.11
        Tab 으로 닿지 않는 조작 요소가 있음 → 2.1.1

이 시나리오는 스크린 리더 없이도 절반은 돌아간다. Tab 순회만으로 걸리는 결함이 큰 몫이라 가장 먼저 한다.

시나리오 3 — 이름·역할·값 (4.1.2, 3.3.2, 2.5.3)

누른다  b 와 f 로 버튼·폼 컨트롤을 순회. 각 지점에서 NVDA+Tab
듣는다  "이름, 역할, 상태" 순서의 문자열. 예: "장바구니 담기 버튼"
판정    이름이 없음("버튼"만 낭독) → 4.1.2
        역할이 없음(이름만 낭독되고 Tab 으로 닿지 않음) → 4.1.2
        입력창에 레이블이 연결 안 됨("편집창"만 낭독) → 3.3.2
        화면에 보이는 문구가 접근 가능한 이름에 포함되지 않음 → 2.5.3 Label in Name

마지막 줄을 놓치기 쉽다. 화면에 "검색" 이라고 쓰여 있는데 aria-label="돋보기" 면 음성 명령 사용자가 "검색 누르기" 라고 말해도 동작하지 않는다.

시나리오 4 — 대체 텍스트 (1.1.1)

누른다  g 를 반복해 그래픽만 순회
듣는다  대체 텍스트 문자열
판정    의미 있는 이미지인데 낭독이 없음 → 부적합
        파일명이 낭독됨("img_0231_final.png") → 부적합
        장식 이미지가 낭독됨(alt="" 미적용) → 부적합
        아이콘 버튼이 "그래픽" 으로만 낭독됨 → 4.1.2 와 함께 부적합

자동 도구가 잡는 것은 alt 속성의 유무뿐이다. 판정 기준은 한 문장으로 족하다 — 이미지를 지우고 그 자리에 낭독된 문자열을 넣었을 때 문서가 같은 뜻이면 적합이다.

시나리오 5 — 라이브 리전과 상태 메시지 (4.1.3) — 동적 변화를 포커스 이동 없이 알려 주는가를 본다. 가장 많이 빠지는 항목이고 자동 도구가 거의 못 잡는다.

누른다  장바구니 담기 / 폼 제출 실패 / 검색 자동완성 / 토스트 알림 발생
듣는다  화면에 변화가 생긴 순간 낭독이 나오는가
판정    변화가 있었는데 아무 낭독이 없음 → 4.1.3 Status Messages 부적합
        낭독은 되는데 포커스를 강제로 빼앗아감 → 3.2.2 On Input 쪽으로 다시 판정
        토스트가 3초 뒤 사라져 낭독을 끝까지 못 들음 → 2.2.1 과 함께 검토

전형적 결함은 이렇게 적는다 — "장바구니 담기 후 화면 우상단 배지가 0에서 1로 바뀌지만 NVDA에서 아무 낭독도 나오지 않는다. 담겼는지 알 수 없다."

시나리오 6 — 모달과 키보드 트랩 (2.1.2, 2.4.3)

누른다  모달을 여는 버튼에서 Enter → Tab 반복 → Esc
듣는다  모달 제목이 낭독되는가, Tab 이 모달 안에서 순환하는가
판정    모달 열린 뒤 포커스가 배경 본문에 남음 → 2.4.3
        Tab 이 배경 콘텐츠로 빠져나감 → 모달 초점 가두기 미구현
        Esc 로 닫히지 않고 Tab 으로도 못 빠져나옴 → 2.1.2 키보드 트랩
        닫은 뒤 포커스가 문서 맨 처음으로 돌아감 → 2.4.3

결함 리포트 — 낭독 문자열을 그대로 인용한다

스크린 리더 결함 리포트가 다른 결함과 다른 점은 "기대 낭독"과 "실제 낭독" 칸이 있다 는 것이다. 이 두 줄이 있으면 개발자가 고친 뒤 스스로 재검증할 수 있다.

제목      [접근성] 4.1.2 — 배송지 선택 커스텀 콤보박스가 NVDA에서 조작 불가
환경      NVDA 2026.x / Chrome 1xx / Windows 11 / 기본 설정, 데스크톱 배열
기준      WCAG 2.2 4.1.2 Name, Role, Value (AA 기준 아님, A) / KWCAG 8.2.1
재현 절차 1) 주문서 진입  2) Tab 으로 "배송지 선택" 까지 이동
          3) 아래화살표를 눌러 항목 선택 시도
실제 낭독 "배송지 선택"  (역할·상태 낭독 없음)
          아래화살표를 누르면 다음 제목으로 이동해 버림(브라우즈 모드 유지)
기대 낭독 "배송지 선택 콤보 상자 접힘, 집"
          아래화살표로 포커스 모드 전환 후 항목이 하나씩 낭독된다

재현 절차에 키 이름과 횟수를 정확히 적는 것 이 핵심이다. "탐색했더니" 가 아니라 "Tab 3회 후 아래화살표 1회" 여야 개발자가 같은 상태를 만든다.

스크린 리더 검증의 한계를 먼저 말한다

QA가 NVDA를 조작하는 것과 시각장애인 사용자가 NVDA를 쓰는 것은 같지 않다. 숙련 사용자는 훨씬 빠르게 훑고 익숙한 우회 경로를 알고 있으며, 반대로 QA가 화면을 보면서 검증하면 "들리지 않아도 보이니까 넘어가는" 편향이 생긴다. 대응은 두 가지다. 화면을 끄고 음성만으로 같은 과업을 한 번 더 돌고, 가능하면 실제 스크린 리더 사용자를 세션에 초대한다(레슨 2의 세션 설계를 그대로 쓴다). 스크린 리더 검증은 기준 판정이고 실사용자 세션은 사용성 판정이다 — 둘은 대체 관계가 아니다.

실무에서 왜 필요한가

첫째, 부적합 판정의 근거가 문자열이 되기 때문이다. 레슨 5에서 접근성은 협상 대상이 아니라고 했지만 회의에서는 "이게 정말 문제냐" 는 질문이 나온다. 이때 "NVDA에서 '편집창' 이라고만 낭독됩니다" 는 재현 가능한 사실이고, 화면 캡처로는 만들 수 없는 종류의 증거다.

둘째, 컴포넌트 단위 회귀를 막는 방법 이다. 접근성 결함은 대개 공용 컴포넌트에서 나오고 리팩터링될 때 조용히 되살아난다. 디자인 시스템의 버튼·모달·콤보박스·토스트 네 가지에 시나리오 3·5·6을 정기적으로 돌리면 화면 수십 개를 개별 검사하지 않아도 회귀가 잡힌다.

셋째, 국내 접근성 심사의 실제 검증 방식이 이것이다. KWCAG 6.1.1(키보드 사용 보장)·6.1.2(초점 이동과 표시)·5.1.1(적절한 대체 텍스트)·7.3.2(레이블 제공)는 심사원이 스크린 리더와 키보드로 직접 확인한다. 자동 도구 리포트 제출만으로는 심사가 통과되지 않는다.

실습 과제

과제 1 — 환경 고정과 조작 숙달 (20분)

NVDA를 설치하고 검증 환경 네 줄을 적는다. 그 다음 아무 공개 웹사이트에서 다음을 순서대로 수행하며 들은 문자열을 그대로 받아 적는다(음성 뷰어를 켜면 쉽다).

1) NVDA+T 로 창 제목 듣기
2) NVDA+F7 로 제목 목록 열고 문서 목차 적어 보기
3) h 를 10회 눌러 제목 레벨 흐름 기록 (h1 → h2 → h2 → h3 ...)
4) b 를 5회 눌러 버튼 이름 기록
5) 입력창에 들어갔다 나오며 포커스 모드 자동 전환이 일어나는지 확인
6) NVDA+Space 로 수동 전환을 해 보고 h 키의 동작이 어떻게 달라지는지 확인

6번이 이 과제의 목적이다. 같은 키가 모드에 따라 다르게 동작한다는 감각 이 없으면 결함과 조작 미숙을 구분하지 못한다.

과제 2 — 시나리오 6종으로 한 화면 판정하기 (30분)

담당 제품의 화면 하나(가능하면 폼과 모달이 있는 화면)를 골라 시나리오 1~6을 전부 돌리고 판정표를 채운다. 레슨 5의 판정값 네 종류를 그대로 쓴다.

시나리오 | 기준번호 | 판정 | 근거(들은 문자열 또는 관찰)
1 구조   | 1.3.1  | 부적합 | 요소 목록에 제목이 h1 1개뿐. 섹션 제목 4개가 div
3 이름   | 3.3.2  | 부적합 | 쿠폰 코드 입력창이 "편집창" 으로만 낭독됨
4 대체텍스트 | 1.1.1 | 해당 없음 | 표본 화면에 의미 있는 이미지 없음
6 모달   | 2.1.2  | 판정 불가 | 해당 화면에 모달 없음 → 다른 화면에서 재확인

시나리오 5에서 부적합이 안 나오면 의심해 본다. 라이브 리전이 제대로 구현된 제품은 드물다. 변화가 일어나는 지점을 충분히 찾았는지 다시 본다.

과제 3 — 재현 가능한 결함 리포트 2건 (20분)

과제 2의 부적합 중 두 건을 본문의 리포트 템플릿으로 쓴다. 한 건은 포커스·구조 계열(1·2·6), 다른 한 건은 낭독 내용 계열(3·4·5)에서 고른다.

완성 후 검산한다 — 옆자리 사람에게 리포트만 주고 같은 상태를 만들게 한다. 재현되지 않으면 빠진 것은 거의 항상 환경 네 줄이거나 키 입력 횟수다.

자가 체크리스트

• 브라우즈 모드와 포커스 모드의 차이, NVDA+Space 전환, 자동 전환이 역할을 근거로 일어난다는 점을 설명할 수 있다
• NVDA 기본 모디파이어 키와 데스크톱·랩톱 배열 차이를 알고, 전체 읽기·현재 줄 읽기 키를 배열별로 말할 수 있다
• NVDA+F7 요소 목록으로 제목 구조를 뽑아 1.3.1 판정에 쓸 수 있다
• 단일 문자 탐색 h b f g d 다섯 개로 한 화면의 구조를 10분 안에 훑을 수 있다
• 이름·역할·값을 낭독 문자열에서 구분해 듣고, 대체 텍스트 적합성을 "이미지 자리에 문자열을 넣어도 뜻이 같은가" 로 판정할 수 있다
• 라이브 리전 결함을 4.1.3 으로 판정하고, 포커스를 빼앗는 구현과 구분할 수 있다
• 모달에서 초점 가두기·Esc 닫기·트리거 복귀를 검증하고 키보드 트랩을 2.1.2 로 보고할 수 있다
• 결함 리포트에 환경 네 줄, 키 입력 횟수, 기대 낭독과 실제 낭독을 모두 적을 수 있다
• QA의 스크린 리더 조작이 실사용자 경험과 다르다는 한계를 말하고 보완책을 댈 수 있다

흔한 실수

• 모드를 모른 채 "키가 안 먹는다"고 보고한다. 브라우즈 모드에서는 글자 키가 탐색 명령이다.
• 화면을 보면서만 검증한다. 보이니까 넘어가는 편향이 생긴다. 한 번은 화면을 끄고 같은 과업을 수행해 본다.
• 낭독 내용을 요약해서 적는다. "레이블이 이상함" 이 아니라 들린 문자열을 따옴표로 그대로 인용한다.
• 환경 정보를 빼먹는다. 스크린 리더·브라우저 조합에 따라 동작이 달라진다. 네 줄이 없으면 재현 논쟁이 시작된다.
• 라이브 리전을 검증 항목에서 뺀다. 자동 도구가 못 잡는 대표 항목이고, 결함이 가장 많이 남아 있는 곳이다.
• 키보드 트랩을 경미로 분류한다. 빠져나올 수 없다는 것은 페이지 전체를 포기해야 한다는 뜻이다.
• aria-* 속성이 붙어 있으면 적합으로 본다. 판정 근거는 속성 존재가 아니라 실제로 낭독된 문자열이다.
• 한 스크린 리더의 결과를 전체로 일반화한다. 정본 조합을 정하고, JAWS·VoiceOver와 다르면 조합별로 적는다.

참고 자료

• NVDA User Guide — NV Access — 모디파이어 키, 데스크톱·랩톱 배열, 브라우즈 모드 동작의 1차 출처
• NVDA Commands Quick Reference — NV Access — NVDA+Space, NVDA+F7, 단일 문자 탐색 전체 목록
• WebAIM — Using NVDA to Evaluate Web Accessibility — 검증 목적의 조작 절차와 확인 항목
• WAI-ARIA Authoring Practices — W3C — 위젯별 기대 키보드 동작과 낭독 내용
• Understanding SC 4.1.3 Status Messages — W3C — 라이브 리전 판정 기준
• Understanding SC 2.5.3 Label in Name — W3C — 보이는 문구와 접근 가능한 이름의 관계
• 레슨 s5-m49-l05 — 성공 기준 판정 절차와 판정값 네 종류(이 레슨의 판정표가 그 형식이다)
• 레슨 s5-m49-l02 — 실사용자 세션 설계(스크린 리더 사용자를 초대할 때 그대로 쓴다)