보조 기술 테스트

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

수정해 보겠습니다.

스크린 리더 사용자를 위해 이 문제를 해결하기 위해 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: 장식 이미지

Google의 자동 테스트 모듈에서 Lighthouse는 데모 페이지의 기본 스플래시 이미지 역할을 하는 인라인 SVG를 선택할 수 없었습니다. 하지만 스크린 리더가 인라인 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>

수정해 보겠습니다.

앞서 설명한 장식용 이미지 예와 마찬가지로 글머리기호 클래스와 함께 role="presentation"를 HTML에 추가하여 스크린 리더에서 숨길 수 있습니다. 마찬가지로 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에서 이러한 변경사항을 모두 확인할 수 있습니다.

이제 배운 내용을 바탕으로 자체 웹사이트와 앱의 접근성을 검토할 수 있습니다.

이 접근성 테스트의 모든 목표는 사용자에게 발생할 수 있는 문제를 최대한 많이 해결하는 것입니다. 하지만 단계를 완료한다고 해서 웹사이트나 앱에 완벽하게 액세스할 수 있는 것은 아닙니다. 프로세스 전반에 걸쳐 접근성을 고려하여 웹사이트나 앱을 설계하고 이러한 테스트를 다른 사전 출시 테스트와 통합하면 가장 큰 성공을 거둘 수 있습니다.

학습 내용 확인하기

자동화된 접근성 테스트에 관한 지식 테스트