이 모듈에서는 접근성 테스트에 보조 기술(AT)을 사용하는 방법을 중점적으로 다룹니다. 장애인은 AT를 사용하여 작업 수행 능력을 높이거나 유지하거나 개선할 수 있습니다.
디지털 공간에서 AT는 다음과 같은 역할을 할 수 있습니다.
- 기술이 없거나 낮음: 머리 및 입 막대, 휴대용 돋보기, 큰 버튼이 있는 기기
- 첨단 기술: 음성 인식 기기, 눈 추적 기기, 적응형 키보드 및 마우스
- 하드웨어: 스위치 버튼, 인체공학 키보드, 자동 새로고침 점자 기기
- 소프트웨어: 텍스트 음성 변환 프로그램, 실시간 자막, 스크린 리더
전반적인 테스트 워크플로에서 여러 유형의 AT를 사용하는 것이 좋습니다.
스크린 리더 테스트 기본사항
이 모듈에서는 가장 인기 있는 디지털 AT 중 하나인 스크린 리더에 중점을 둡니다. 스크린 리더는 웹사이트 또는 앱의 기본 코드를 읽는 소프트웨어입니다. 그런 다음 이 정보를 사용자를 위해 음성 또는 점자 출력으로 변환합니다.
스크린 리더는 맹인과 청각장애인에게 필수적이지만 저시력, 읽기 장애, 인지 장애가 있는 사용자에게도 도움이 될 수 있습니다.
브라우저 호환성
여러 스크린 리더 옵션을 사용할 수 있습니다. 가장 많이 사용되는 스크린 리더는 데스크톱 컴퓨터의 경우 JAWS, NVDA, VoiceOver, 휴대기기의 경우 VoiceOver 및 TalkBack입니다.
운영체제(OS), 즐겨 사용하는 브라우저, 사용하는 기기에 따라 스크린 리더 중 하나가 가장 적합할 수 있습니다. 대부분의 화면 리더는 특정 하드웨어와 웹브라우저를 염두에 두고 빌드됩니다. 화면 리더가 보정되지 않은 브라우저에서 화면 리더를 사용하면 더 많은 '버그' 또는 예기치 않은 동작이 발생할 수 있습니다. 스크린 리더는 다음과 같은 조합으로 사용할 때 가장 효과적입니다.
| 스크린 리더 | OS | 브라우저 호환성 |
|---|---|---|
| Job Access With Speech(JAWS) | Windows | Chrome, Firefox, Edge |
| 비시각적 데스크톱 액세스 (NVDA) | Windows | Chrome 및 Firefox |
| 내레이터 | Windows | Edge |
| VoiceOver | macOS | Safari |
| Orca | Linux | Firefox |
| Talkback | Android | Chrome 및 Firefox |
| VoiceOver(모바일용) | iOS | Safari |
| ChromeVox | ChromeOS | Chrome |
스크린 리더 명령어
데스크톱 또는 휴대기기의 스크린 리더 소프트웨어를 적절하게 설정한 후에는 스크린 리더 문서(위 표에 링크)를 살펴보고 몇 가지 필수 스크린 리더 명령어를 실행하여 이 기술에 익숙해져야 합니다. 이전에 스크린 리더를 사용해 본 적이 있다면 새로운 스크린 리더를 사용해 보세요.
접근성 테스트에 스크린 리더를 사용할 때는 스크린 리더 사용자의 환경을 에뮬레이션하는 것이 아니라 웹사이트 또는 앱 사용을 방해하는 코드의 문제를 감지하는 것이 목표입니다. 따라서 몇 가지 기본 지식, 몇 가지 화면 리더 명령어, 약간의 연습만으로도 많은 작업을 할 수 있습니다.
화면 리더 및 기타 AT를 사용하는 사용자의 사용자 환경을 자세히 이해해야 하는 경우 여러 조직 및 개인과 소통하여 이러한 유용한 정보를 얻을 수 있습니다. AT를 사용하여 일련의 규칙에 따라 코드를 테스트하고 사용자에게 경험에 관해 물어보면 종종 다른 결과가 나오는 점에 유의하세요. 둘 다 완전히 포용적인 제품을 만드는 데 중요한 요소입니다.
데스크톱 스크린 리더용 주요 명령어
| 요소 | NVDA(Windows) | VoiceOver(macOS) |
|---|---|---|
| 일반 명령어 키 | 삽입 | Control+Option |
| 오디오 중지 | 제어 | 제어 |
| 다음/이전 읽기 | ↓ 또는 ↑ | Control+Option+→ 또는 ← |
| 읽기 시작 | 삽입↓ | Control+옵션+A |
| 요소 목록/로터 | NVDA + F7 | Control+Option+U |
| 명소 | D | Control+Option+U |
| 제목 | H | Control+Option+Command+H |
| 링크 | K | Control+Option+Command+L |
| 양식 컨트롤 | F | Control+옵션+Command+J |
| 테이블 | T | Control+OptionCommand+T |
| 테이블 내 | 삽입Alt + ↓ ↑ ← → | Control+Option+↓ ↑ ← → |
모바일 스크린 리더용 주요 명령어
| 요소 | TalkBack(Android) | VoiceOver(iOS) |
|---|---|---|
| 탐색 | 한 손가락을 사용해 화면을 드래그합니다. | 한 손가락을 사용해 화면을 드래그합니다. |
| 선택 또는 활성화 | 두 번 탭 | 두 번 탭 |
| 위 또는 아래로 이동 | 두 손가락을 사용해 위 또는 아래로 스와이프합니다. | 세 손가락을 사용해 위 또는 아래로 스와이프합니다. |
| 페이지 변경 | 두 손가락을 사용해 왼쪽 또는 오른쪽으로 스와이프 | 세 손가락을 사용해 왼쪽 또는 오른쪽으로 스와이프하세요. |
| 다음/이전 | 한 손가락을 왼쪽 또는 오른쪽으로 스와이프 | 한 손가락을 사용해 왼쪽 또는 오른쪽으로 스와이프 |
스크린 리더 테스트 데모
데모를 테스트하기 위해 macOS를 실행하는 노트북에서 Safari를 사용하고 사운드를 캡처했습니다. 스크린 리더를 사용하여 단계를 진행할 수 있지만 오류가 발생하는 방식은 이 모듈에서 설명하는 방식과 다를 수 있습니다.
1단계
모든 자동 및 수동 접근성 업데이트가 적용된 업데이트된 CodePen으로 이동합니다.
디버그 모드에서 확인한 후 다음 테스트를 진행합니다. 이는 데모 웹페이지를 둘러싸는 <iframe>를 삭제하므로 중요합니다. 이 <iframe>는 일부 테스트 도구와 충돌할 수 있습니다. CodePen의 디버그 모드에 대해 자세히 알아보세요.
2단계
원하는 스크린 리더를 활성화하고 데모 페이지로 이동합니다. 특정 문제에 집중하기 전에 전체 페이지를 위에서 아래로 탐색해 보는 것이 좋습니다.
데모에 수정사항이 적용되기 전후에 문제별로 스크린 리더를 기록했습니다. 자체 스크린 리더를 사용하여 데모를 실행해 보시기 바랍니다.
문제 1: 콘텐츠 구조
제목과 랜드마크는 사용자가 스크린 리더를 사용하여 탐색하는 주요 방법 중 하나입니다. 이러한 내용이 없으면 스크린 리더 사용자는 맥락을 파악하기 위해 전체 페이지를 읽어야 합니다. 이 방법은 시간이 오래 걸리고 불편을 끼칠 수 있습니다.
데모의 요소 중 하나로 탐색하려고 하면 해당 요소가 존재하지 않음을 빨리 알게 됩니다.
- 명소 예:
<div class="main">...</div> - 제목 예:
<p class="h1">Join the Club</p>
모든 항목을 올바르게 업데이트했다면 시각적으로는 아무런 변화가 없지만 스크린 리더 환경이 크게 개선됩니다.
문제를 해결해 보겠습니다.
액세스할 수 없는 일부 요소는 사이트를 보는 것만으로는 확인할 수 없습니다. 콘텐츠 구조 모듈에서 제목 수준과 의미론적 HTML의 중요성을 기억하실 것입니다. 콘텐츠가 제목처럼 보이지만 실제로는 스타일이 지정된 <div>로 래핑되어 있습니다.
제목 및 랜드마크 관련 문제를 해결하려면 먼저 마크업해야 하는 각 요소를 식별하고 관련 HTML을 업데이트해야 합니다. 관련 CSS도 업데이트해야 합니다.
- 명소 예:
<main>...</main> - 제목 예:
<h1>Join the Club</h1>
모든 항목을 올바르게 업데이트했다면 시각적으로는 아무런 변화가 없지만 스크린 리더 환경이 크게 개선됩니다.
문제 2: 링크 컨텍스트
스크린 리더 사용자에게 링크의 목적과 링크가 웹사이트 또는 앱 외부의 새 위치로 리디렉션되는지 여부에 관한 콘텐츠를 제공하는 것이 중요합니다.
데모에서는 활성 이미지 대체 텍스트를 업데이트할 때 대부분의 링크를 수정했지만, 특히 새 위치로 리디렉션되므로 추가 컨텍스트를 활용할 수 있는 다양한 희귀 질병에 관한 추가 링크가 몇 가지 있습니다.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
스크린 리더 사용자의 이 문제를 해결하기 위해 Google은 시각적 요소에 영향을 주지 않으면서 더 많은 정보를 추가하도록 코드를 업데이트합니다. 또는 읽기 및 인지 장애가 있는 사용자와 같은 더 많은 사용자를 지원하기 위해 대신 시각적 텍스트를 추가할 수도 있습니다.
링크 정보를 추가하는 데 고려할 수 있는 다양한 패턴이 있습니다. 하나의 언어만 지원하는 환경을 고려할 때 이 상황에서는 ARIA 라벨이 간단한 옵션입니다. ARIA 라벨이 원래 링크 텍스트를 재정의할 수 있으므로 업데이트에 이 정보를 포함해야 합니다.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease"
aria-label="Learn more about Maple syrup urine disease on the Rare Diseases website.">
Maple syrup urine disease (MSUD)
</a>
문제 3: 장식용 이미지
자동 테스트 모듈에서 Lighthouse가 데모 페이지의 기본 스플래시 이미지 역할을 하는 인라인 SVG를 선택할 수 없었습니다. 하지만 스크린 리더는 이 텍스트를 찾아서 추가 정보 없이 '이미지'로 알립니다.
SVG에 role="img" 속성을 명시적으로 추가하지 않아도 마찬가지입니다.
<div class="section-right">
<svg>...</svg>
</div>
이 문제를 해결하려면 먼저 이미지가 정보 제공 이미지인지 아니면 장식 이미지인지 결정해야 합니다. 이 결정에 따라 적절한 이미지 대체 텍스트를 추가하거나(정보 제공 이미지) 스크린 리더 사용자에게 이미지를 숨겨야 합니다(장식용 이미지).
이미지를 가장 잘 분류하는 방법의 장단점을 고려한 결과, 장식용이라고 판단했습니다. 즉, 이미지를 숨기기 위한 코드를 추가하거나 수정해야 합니다. 빠른 방법은 role="presentation"를 SVG 이미지에 직접 추가하는 것입니다. 이렇게 하면 스크린 리더에 이 이미지를 건너뛰고 이미지 그룹에 표시하지 않도록 신호를 보냅니다.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
문제 4: 글머리기호 장식
스크린 리더가 희귀 질환 섹션 아래의 CSS 글머리기호 이미지를 읽는 것을 확인했을 수 있습니다. 이미지 모듈에서 다룬 기존 이미지 유형은 아니지만 콘텐츠의 흐름을 방해하고 스크린 리더 사용자의 주의를 분산시키거나 혼란을 줄 수 있으므로 이미지를 수정해야 합니다.
<p class="bullet">...</p>
앞에서 설명한 장식 이미지 예와 마찬가지로 글머리기호 클래스로 HTML에 role="presentation"를 추가하여 스크린 리더에서 숨길 수 있습니다. 마찬가지로 role="none"도 작동합니다. 단, aria-hidden: true를 사용하면 스크린 리더 사용자에게 모든 단락 정보가 숨겨집니다.
<p class="bullet" role="none">...</p>
문제 5: 양식 입력란
양식 모듈에서는 모든 양식 필드에 시각적 및 프로그래매틱 라벨도 있어야 한다고 배웠습니다. 이 라벨은 항상 표시되어야 합니다.
이 데모에서는 뉴스레터 가입 이메일 입력란에 시각적 라벨과 프로그래매틱 라벨이 모두 누락되어 있습니다. 텍스트 자리표시자 요소가 있지만 시각적으로 지속되지 않고 일부 스크린 리더와 완전히 호환되지 않으므로 라벨을 대체하지는 않습니다.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
이 문제를 해결하려면 텍스트 자리표시자를 유사한 라벨 요소로 대체하세요. 라벨 요소는 양식 필드에 프로그래매틱 방식으로 연결되며, 내용이 필드에 추가될 때도 라벨이 계속 표시되도록 이동이 자바스크립트를 통해 추가되었습니다.
<form>
<div class="form-group">
<input type="email" required id="youremail" name="youremail" type="text">
<label for="youremail">Enter your e-mail address</label>
<button type="submit" aria-label="Subscribe to our newsletter">Subscribe</button>
</div>
</form>
마무리
축하합니다. 이 데모의 모든 테스트를 완료했습니다. 이 데모용으로 업데이트된 Codepen에서 이러한 변경사항을 모두 확인할 수 있습니다.
이제 배운 내용을 사용하여 자체 웹사이트와 앱의 접근성을 검토할 수 있습니다.
이러한 모든 접근성 테스트의 목표는 사용자에게 발생할 수 있는 가능한 한 많은 문제를 해결하는 것입니다. 그러나 작업을 완료한다고 해서 웹사이트나 앱에 완벽하게 액세스할 수 있는 것은 아닙니다. 프로세스 전반에서 접근성을 고려하여 웹사이트 또는 앱을 설계하고 이러한 테스트를 다른 출시 전 테스트와 통합하면 가장 효과적입니다.
이해도 확인
자동화된 접근성 테스트에 대한 지식 테스트
접근성 테스트에 가장 적합한 스크린 리더는 무엇인가요?
보조 기술을 사용하여 테스트하는 목적은 무엇인가요?