이 모듈에서는 접근성 테스트에 보조 기술 (AT)을 사용하는 데 중점을 둡니다. 장애가 있는 사람은 AT를 사용하여 작업 수행 능력을 향상, 유지 또는 개선할 수 있습니다.
디지털 공간에서의 AT는 다음과 같을 수 있습니다.
- 비기술/낮은 기술: 머리/입 막대, 휴대용 돋보기, 큰 버튼이 있는 기기
- 하이테크: 음성 인식 기기, 안구 추적 기기, 적응형 키보드/마우스
- 하드웨어: 스위치 버튼, 인체 공학적 키보드, 점자 기기 자동 새로고침
- 소프트웨어: 텍스트 음성 변환 프로그램, 실시간 자막, 스크린 리더
전체 테스트 워크플로에서 여러 유형의 AT를 사용하는 것이 좋습니다.
스크린 리더 테스트 기본사항
이 모듈에서는 가장 인기 있는 디지털 AT 중 하나인 스크린 리더에 중점을 둡니다. 스크린 리더는 웹사이트나 앱의 기본 코드를 읽는 소프트웨어입니다. 그런 다음 이 정보를 음성 또는 점자 출력으로 변환합니다.
스크린 리더는 시각장애인 및 청각장애인에게 필수적이지만 저시력, 읽기 장애 또는 인지 장애가 있는 사용자에게도 도움이 될 수 있습니다.
브라우저 호환성
다양한 스크린 리더 옵션을 사용할 수 있습니다. 현재 가장 널리 사용되는 스크린 리더는 데스크톱 컴퓨터의 경우 JAWS, NVDA, VoiceOver이며 휴대기기에서는 VoiceOver 및 Talkback입니다.
운영체제 (OS), 자주 사용하는 브라우저, 사용하는 기기에 따라 스크린 리더 하나를 선택하는 것이 가장 적합할 수 있습니다. 대부분의 스크린 리더는 특정 하드웨어와 웹브라우저를 염두에 두고 제작됩니다. 보정되지 않은 브라우저에서 스크린 리더를 사용할 때 더 많은 '버그'가 발생할 수 있습니다. 예기치 않은 동작이 발생할 수 있습니다. 스크린 리더는 다음과 같은 조합에서 사용할 때 가장 잘 작동합니다.
스크린 리더 명령어
데스크톱이나 휴대기기에 맞게 스크린 리더 소프트웨어를 설정했다면 앞 표에 링크된 스크린 리더 문서를 살펴보고 필수 스크린 리더 명령어를 실행하여 기술을 익히세요. 이전에 스크린 리더를 사용한 적이 있다면 새로운 스크린 리더를 사용해 보세요.
접근성 테스트에 스크린 리더를 사용할 때 목표는 스크린 리더 사용자의 환경을 에뮬레이션하는 것이 아니라 웹사이트 또는 앱 사용을 방해하는 코드에서 문제를 감지하는 것입니다. 따라서 기본 지식과 몇 가지 스크린 리더 명령어, 약간의 연습을 통해 많은 작업을 할 수 있습니다.
스크린 리더 및 기타 AT를 사용하는 사람들의 사용자 경험을 더 자세히 이해해야 하는 경우 많은 조직 및 개인과 소통하여 유용한 정보를 얻을 수 있습니다. AT를 사용하여 일련의 규칙을 기준으로 코드를 테스트하고 사용자에게 사용 경험에 대해 질문하면 종종 다른 결과가 나오게 됩니다. 두 가지 모두 포괄적인 제품을 만드는 데 중요한 요소입니다.
데스크톱 스크린 리더용 주요 명령어
모바일 스크린 리더용 주요 명령어
스크린 리더 테스트 데모
데모를 테스트하기 위해 MacOS를 실행하는 노트북에서 Safari를 사용하여 사운드를 캡처했습니다. 모든 스크린 리더를 사용하여 단계를 진행할 수 있지만 오류가 발생하는 방식은 이 모듈에서 설명하는 것과 다를 수 있습니다.
1단계
업데이트된 CodePen으로 이동합니다. 접근성 업데이트의 모든 자동 및 수동 업데이트가 적용되었는지 확인합니다.
디버그 모드에서 확인하고
다음 테스트를 실행합니다. 이 메서드는 요소를 둘러싸는 <iframe>를 삭제하므로 중요합니다.
데모 웹페이지로 인해 일부 테스트 도구가 작동하지 않을 수 있습니다. 다음에 대해 자세히 알아보기
CodePen의 디버그 모드
2단계
원하는 스크린 리더를 활성화하고 데모 페이지로 이동합니다. 특정 문제에 집중하기 전에 전체 페이지를 위에서 아래로 탐색해 보세요.
데모에 수정사항이 적용되기 전후에 문제별로 스크린 리더를 기록했습니다. 나만의 스크린 리더를 사용해 데모를 실행해 보는 것이 좋습니다.
문제 1: 콘텐츠 구조
제목과 랜드마크는 사람들이 스크린 리더를 사용하여 탐색하는 기본적인 방법 중 하나입니다. 이러한 요소가 없으면 스크린 리더 사용자가 컨텍스트를 이해하기 위해 전체 페이지를 읽어야 합니다. 이 작업은 시간이 오래 걸리고 불만을 유발할 수 있습니다. 데모의 요소 중 하나로 탐색하려고 하면 존재하지 않는 것을 금방 알아차릴 수 있습니다.
- 랜드마크 예:
<div class="main">...</div> - 제목 예:
<p class="h1">Join the Club</p>
모두 올바르게 업데이트했다면 시각적인 변화는 없지만 스크린 리더 환경은 크게 개선되었을 것입니다.
<ph type="x-smartling-placeholder">
</ph>
문제를 해결해 보세요.
액세스할 수 없는 일부 요소는 사이트를 보는 것만으로는 관찰할 수 없습니다. 제목 수준 및 의미론적 HTML의 중요성은 콘텐츠 구조 모듈에서 기억하실 것입니다. 콘텐츠가 제목처럼 보일 수 있지만 실제로는 콘텐츠가 양식화된 <div>에 래핑됩니다.
제목과 랜드마크 문제를 해결하려면 먼저 그렇게 마크업되어야 하는 각 요소를 식별하고 관련 HTML을 업데이트해야 합니다. 관련 CSS도 업데이트해야 합니다.
랜드마크 예: <main>...</main>
제목 예: <h1>Join the Club</h1>
모두 올바르게 업데이트했다면 시각적인 변화는 없지만 스크린 리더 환경은 크게 개선되었을 것입니다.
<ph type="x-smartling-placeholder">문제 2: 링크 컨텍스트
스크린 리더 사용자에게 링크의 목적과 링크가 사용자를 웹사이트 또는 앱 외부의 새 위치로 리디렉션하는지 여부에 대한 콘텐츠를 제공하는 것이 중요합니다.
데모에서는 활성 이미지 대체 텍스트를 업데이트할 때 대부분의 링크를 수정했지만, 특히 새로운 위치로 리디렉션되므로 추가 컨텍스트가 있으면 도움이 될 수 있는 다양한 희귀 질환에 대한 추가 링크가 있습니다.
<a href="https://rarediseases.org/rare-diseases/maple-syrup-urine-disease">
Maple syrup urine disease (MSUD)
</a>
스크린 리더 사용자의 이 문제를 해결하기 위해 Google은 시각 요소에 영향을 주지 않으면서 더 많은 정보를 추가하도록 코드를 업데이트합니다. 또는 읽기 및 인지 장애가 있는 사람 등 더 많은 사용자에게 도움을 주기 위해 Google에서 대신 시각적 텍스트를 추가할 수도 있습니다.
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를 포착하지 못했지만 스크린 리더가 이를 찾아 '이미지'로 알려줍니다. 정보를 제공하지 않아도 됩니다 role="img" 속성을 SVG에 명시적으로 추가하지 않아도 마찬가지입니다.
<div class="section-right">
<svg>...</svg>
</div>
이 문제를 해결하려면 먼저 이미지가 유익한 이미지인지 장식용인지 결정해야 합니다. 이 결정에 따라 적절한 이미지 대체 텍스트 (정보 제공 이미지)를 추가하거나 스크린 리더 사용자에게 표시되지 않도록 이미지를 숨겨야 합니다 (장식용).
이미지를 분류하는 가장 좋은 방법의 장단점을 따져본 결과 장식용이라고 판단했습니다. 즉, 이미지를 숨기기 위해 코드를 추가하거나 수정해야 한다는 의미입니다. 빠른 방법은 role="presentation"를 SVG 이미지에 직접 추가하는 것입니다. 이렇게 하면 이미지를 건너뛰고 이미지 그룹에 표시하지 말라는 신호가 스크린 리더에 전송됩니다.
<div class="section-right">
<svg role="presentation">...</svg>
</div>
문제 4: 글머리기호 장식
스크린 리더는 텍스트 아래의 CSS 글머리기호 이미지를 읽고 희귀한 질병 섹션에 표시됩니다. Google은 기존의 이미지 유형은 아니지만 이미지 모듈에서 설명했듯이 이미지는 이미지를 방해하므로 여전히 수정되어야 합니다. 스크린 리더 사용자의 주의가 산만하거나 혼란스러울 수 있습니다.
<p class="bullet">...</p>
앞에서 설명한 장식 이미지 예와 마찬가지로 글머리기호 클래스로 HTML에 role="presentation"를 추가하여 스크린 리더에서 숨길 수 있습니다. 마찬가지로 role="none"도 작동합니다. aria-hidden: true는 사용하지 않도록 합니다. 사용하지 마세요. 사용하지 않는 경우 스크린 리더 사용자에게 모든 단락 정보가 숨겨집니다.
<p class="bullet" role="none">...</p>
문제 5: 양식 입력란
Forms 모듈에서는 모든 양식이 필드에는 시각적 및 프로그래매틱 라벨도 있어야 합니다. 이 라벨은 그대로 유지해야 합니다. 항상 표시됩니다.
데모의 뉴스레터 신청 이메일 필드에 시각적 및 프로그래매틱 라벨이 모두 없습니다. 텍스트 자리표시자 요소가 있지만 라벨을 대체하지는 않습니다. 시각적으로 영구적이지 않고 모든 스크린 리더와 완전히 호환되지 않기 때문입니다.
<form>
<div class="form-group">
<input type="email" placeholder="Enter your e-mail address" required>
<button type="submit">Subscribe</button>
</div>
</form>
이 문제를 해결하려면 텍스트 자리표시자를 유사한 라벨 요소로 바꿉니다. 라벨 요소는 양식 필드에 프로그래매틱 방식으로 연결되며, 내용이 필드에 추가되더라도 라벨이 계속 표시되도록 JavaScript를 통해 움직임이 추가되었습니다.
<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에서 모든 변경사항을 확인할 수 있습니다.
이제 배운 내용을 활용하여 자체 앱의 접근성을 검토할 수 있습니다. 웹사이트 및 앱을 사용하는 것이 좋습니다
이러한 모든 접근성 테스트의 목표는 사용자에게 발생할 수 있는 문제를 해결하는 것입니다 그렇다고 해서 웹사이트나 앱이 액세스할 수 있을 것입니다. 가장 큰 성공을 거두는 것은 프로세스 전반에 걸쳐 액세스할 수 있는 웹사이트 또는 앱을 디자인합니다. 다른 사전 출시 테스트와 통합하세요
이해도 확인
자동화된 접근성 테스트에 관한 지식 테스트
접근성 테스트에 가장 적합한 스크린 리더는 무엇인가요?
보조 기술을 사용하여 테스트하는 목적은 무엇인가요?