보조 기술 테스트

이 모듈에서는 접근성 테스트에 보조 기술 (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>

모든 항목을 올바르게 업데이트했다면 시각적 변경사항은 없지만 스크린 리더 환경이 크게 개선됩니다.

문제를 해결해 보겠습니다.

접근할 수 없는 일부 요소는 사이트를 보는 것만으로는 관찰할 수 없습니다. 콘텐츠 구조 모듈에서 제목 수준과 시맨틱 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>

문제를 해결해 보겠습니다.

스크린 리더 사용자를 위해 이 문제를 해결하려면 시각적 요소에 영향을 미치지 않고 더 많은 정보를 추가하도록 코드를 업데이트합니다. 또는 읽기 및 인지 장애가 있는 사용자와 같은 더 많은 사용자를 지원하기 위해 추가 시각적 텍스트를 추가할 수도 있습니다.

추가 링크 정보를 추가하기 위해 고려할 수 있는 다양한 패턴이 있습니다. 하나의 언어만 지원하는 환경을 기반으로 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>

문제를 해결해 보겠습니다.

이 문제를 해결하려면 먼저 이미지가 유용한 정보가 포함된 이미지인지 장식용 이미지인지 결정해야 합니다. 이 결정에 따라 적절한 이미지 대체 텍스트 (유용한 정보가 포함된 이미지)를 추가하거나 스크린 리더 사용자에게 이미지를 숨겨야 합니다 (장식용 이미지).

이미지를 가장 잘 분류하는 방법의 장단점을 고려한 결과 장식용 이미지로 결정했습니다. 즉, 이미지를 숨기도록 코드를 추가하거나 수정하려고 합니다. 빠른 방법은 SVG 이미지에 직접 role="presentation"을 추가하는 것입니다. 이렇게 하면 스크린 리더에 이 이미지를 건너뛰고 이미지 그룹에 나열하지 않도록 신호가 전송됩니다.

<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>

문제를 해결해 보겠습니다.

이 문제를 해결하려면 텍스트 자리표시자를 유사한 라벨 요소로 바꿉니다. 라벨 요소는 프로그래매틱 방식으로 양식 입력란에 연결되며 필드에 콘텐츠가 추가되더라도 라벨이 계속 표시되도록 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에서 이러한 모든 변경사항을 확인할 수 있습니다.

이제 학습한 내용을 사용하여 자체 웹사이트 및 앱의 접근성을 검토할 수 있습니다.

이러한 모든 접근성 테스트의 목표는 사용자가 잠재적으로 겪을 수 있는 가능한 많은 문제를 해결하는 것입니다. 그러나 완료한 후에도 웹사이트 또는 앱이 완벽하게 접근 가능하다고는 할 수 없습니다. 프로세스 전반에 걸쳐 접근성을 고려하여 웹사이트 또는 앱을 설계하고 이러한 테스트를 출시 전 다른 테스트와 통합하는 것이 가장 효과적입니다.