자동화된 접근성 테스트

지금까지 이 과정에서는 디지털 접근성의 개인적, 비즈니스적, 법적 측면과 디지털 접근성 적합성의 기본사항에 관해 배웠습니다. ARIA와 HTML을 사용해야 하는 경우, 색상 대비를 측정하는 방법, 자바스크립트가 필수적인 경우 등 포용적인 디자인 및 코딩과 관련된 특정 주제를 살펴봤습니다.

나머지 모듈에서는 설계 및 빌드에서 접근성 테스트로 전환합니다. 자동화, 수동, 보조 기술 테스트 도구 및 기법이 포함된 3단계 테스트 프로세스를 활용합니다. 이러한 테스트 모듈 전체에서 동일한 데모를 사용하여 웹페이지를 액세스할 수 없는 수준에서 액세스 가능하게 진행합니다.

각 테스트(자동, 수동, 보조 기술)는 가능한 한 접근성이 가장 높은 제품을 달성하는 데 매우 중요합니다.

Google의 테스트는 웹 콘텐츠 접근성 가이드라인 (WCAG) 2.1 적합 수준 A 및 AA를 기준으로 합니다. 업계, 제품 유형, 현지/국가의 법률 및 정책 또는 전반적인 접근성 목표에 따라 따라야 할 가이드라인과 충족해야 할 수준이 결정됩니다. 프로젝트에 특정 표준이 필요하지 않다면 최신 버전의 WCAG를 따르는 것이 좋습니다. 접근성 감사, 적합성 유형/수준, WCAG, POUR에 관한 일반적인 정보는 '디지털 접근성은 어떻게 측정되나요?'를 참고하세요.

아시다시피 접근성 적합성은 장애인 지원 측면에서 그 모든 것이 전부가 아닙니다. 하지만 테스트할 수 있는 측정항목을 제공하므로 좋은 출발점이 됩니다 접근성 적합성 테스트 외에도 장애인을 대상으로 사용성 테스트를 실행하거나, 팀에서 일하는 데 장애인을 고용하거나, 디지털 접근성 전문 지식을 갖춘 개인이나 회사에 상담을 통해 보다 포용적인 제품을 만드는 데 도움이 되는 추가 조치를 취하는 것이 좋습니다.

자동 테스트 기본사항

자동화된 접근성 테스트는 소프트웨어를 사용하여 사전 정의된 접근성 적합성 표준을 기준으로 디지털 제품에 접근성 문제가 있는지 검사합니다.

자동화된 접근성 테스트의 장점:

• 제품 수명 주기의 여러 단계에서 테스트를 쉽게 반복 가능
• 몇 단계만 거치면 빠르게 성과를 얻을 수 있습니다.
• 테스트를 실행하거나 결과를 이해하는 데 접근성에 관한 지식이 거의 없습니다.

자동화된 접근성 테스트의 단점:

• 자동화된 도구로 제품의 접근성 오류를 모두 포착하지는 못합니다.
• 보고된 거짓양성 (실제 WCAG 위반이 아닌 문제가 보고됨)
• 제품 유형 및 역할에 따라 여러 도구가 필요할 수 있음

자동 테스트는 웹사이트 또는 앱의 접근성을 확인하는 좋은 첫 단계이지만 모든 확인을 자동화할 수 있는 것은 아닙니다. 수동 접근성 테스트 모듈에서 자동화할 수 없는 요소의 접근성을 확인하는 방법을 자세히 알아보겠습니다.

자동화 도구 유형

최초의 온라인 자동화된 접근성 테스트 도구 중 하나는 1996년 응용특수기술센터 (CAST)에서 'The Bobby Report'라는 제목으로 개발했습니다. 현재 100개 이상의 자동 테스트 도구 중에서 선택할 수 있습니다.

자동화된 도구 구현은 접근성 브라우저 확장 프로그램부터 코드 린터, 데스크톱 및 모바일 애플리케이션, 온라인 대시보드는 물론 자동화된 도구를 빌드하는 데 사용할 수 있는 오픈소스 API까지 다양합니다.

사용할 자동화 도구는 다음과 같은 다양한 요인에 따라 달라질 수 있습니다.

• 어떤 적합성 표준 및 수준을 테스트하나요? 여기에는 WCAG 2.1, WCAG 2.0, U.S. Section 508 또는 수정된 접근성 규칙 목록이 포함될 수 있습니다.
• 어떤 유형의 디지털 제품을 테스트하시나요? 웹사이트, 웹 앱, 네이티브 모바일 앱, PDF, 키오스크 또는 기타 제품일 수 있습니다.
• 소프트웨어 개발 수명 주기에서 제품을 테스트하는 것은 무엇입니까?
• 도구를 설정하고 사용하는 데 시간이 얼마나 걸리나요? 개인, 팀 또는 회사의 경우
• 디자이너, 개발자, 품질보증 등 테스트는 누가 수행하나요?
• 얼마나 자주 접근성을 확인하고 싶으신가요? 보고서에 어떤 세부정보를 포함해야 하나요? 문제를 티켓팅 시스템에 직접 연결해야 하나요?
• 현재 환경에서 가장 효과적인 도구는 무엇인가요? 팀을 이끌기 위해서라면

이 외에도 고려해야 할 요소도 많습니다. 나와 내 팀에 가장 적합한 도구를 선택하는 방법에 관한 자세한 내용은 WAI의 '웹 접근성 평가 도구 선택' 문서를 참고하세요.

데모: 자동 테스트

자동화된 접근성 테스트 데모에는 Chrome의 Lighthouse를 사용합니다. Lighthouse는 성능, 검색엔진 최적화, 접근성과 같은 다양한 유형의 감사를 통해 웹페이지 품질을 개선하기 위해 개발된 오픈소스 자동화 도구입니다.

이 데모는 만들어진 조직인 Medical Mysteries Club을 위해 제작된 웹사이트입니다. 이 사이트는 데모를 위해 의도적으로 액세스할 수 없도록 설정되었습니다. 이러한 접근성 중 일부는 개발자에게 표시될 수 있으며 일부는 자동 테스트에서 포착됩니다.

1단계

Chrome 브라우저를 사용하여 Lighthouse 확장 프로그램을 설치합니다.

테스트 워크플로에 Lighthouse를 통합하는 방법에는 여러 가지가 있습니다. 이 데모에서는 Chrome 확장 프로그램을 사용하겠습니다.

2단계

CodePen에 데모를 빌드했습니다. 다음 테스트를 진행하려면 디버그 모드에서 확인하세요. 이 작업은 데모 웹페이지를 둘러싸고 있는 <iframe>를 삭제하여 일부 테스트 도구를 방해할 수 있으므로 중요합니다. CodePen의 디버그 모드를 자세히 알아보세요.

3단계

Chrome DevTools를 열고 Lighthouse 탭으로 이동합니다. '접근성'을 제외한 모든 카테고리 옵션을 선택 해제합니다. 모드를 기본값으로 유지하고 테스트를 실행할 기기 유형을 선택합니다.

4단계

'페이지 로드 분석' 버튼을 클릭하고 Lighthouse에서 테스트를 실행할 시간을 줍니다.

테스트가 완료되면 Lighthouse에 테스트 중인 제품의 액세스 가능 여부를 측정하는 점수가 표시됩니다. Lighthouse 점수는 문제 수, 문제 유형, 감지된 문제가 사용자에게 미치는 영향을 기준으로 계산됩니다.

Lighthouse 보고서에는 점수 외에도 감지된 문제에 관한 자세한 정보와 해결 방법을 자세히 알아볼 수 있는 리소스 링크가 포함됩니다. 보고서에는 통과했거나 적용할 수 없는 테스트와 수동으로 확인할 추가 항목 목록도 포함됩니다.

5단계

이제 발견된 각 자동화된 접근성 문제의 예를 살펴보고 관련 스타일과 마크업을 수정해 보겠습니다.

문제 1: ARIA 역할

첫 번째 문제에는 다음과 같이 표시됩니다. "하위 요소에 특정 [role] 을 포함해야 하는 ARIA [role] 의 요소에 일부 또는 모든 필수 하위 요소가 누락되었습니다. 일부 ARIA 상위 역할은 의도한 접근성 기능을 실행하려면 특정 하위 역할을 포함해야 합니다. ARIA 역할 규칙 자세히 알아보기

데모에서 뉴스레터 구독 버튼을 찾을 수 없습니다.

<button role="list" type="submit" tabindex="1">Subscribe</button>

수정해 보겠습니다.

입력란 옆에 있는 '구독' 버튼에 잘못된 ARIA 역할이 적용되었습니다. 이 경우 역할을 완전히 삭제할 수 있습니다.

<button type="submit" tabindex="1">Subscribe</button>

문제 2: ARIA 숨김

"[aria-hidden="true"] 요소에는 포커스 가능한 하위 요소가 포함되어 있습니다. [aria-hidden="true"] 요소 내 포커스 가능한 하위 요소를 사용하면 스크린 리더와 같은 보조 기술 사용자가 이러한 상호작용 요소를 사용할 수 없습니다. aria-hidden 규칙 자세히 알아보기

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

수정해 보겠습니다.

입력란에 aria-hidden="true" 속성이 적용되었습니다. 이 속성을 추가하면 요소와 그 아래에 중첩된 모든 항목이 보조 기술로부터 숨겨집니다.

<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>

이 경우 보조 기술을 사용하는 사용자가 정보에 액세스하여 양식 필드에 입력할 수 있도록 입력에서 이 속성을 삭제해야 합니다.

문제 3: 버튼 이름

버튼에 액세스 가능한 이름이 없습니다. 버튼에 액세스 가능한 이름이 없으면 스크린 리더가 버튼을 '버튼'으로 읽기 때문에 스크린 리더에 의존하는 사용자는 버튼을 사용할 수 없게 됩니다. 버튼 이름 규칙 자세히 알아보기

<button role="list" type="submit" tabindex="1">Subscribe</button>

수정해 보겠습니다.

문제 1의 버튼 요소에서 부정확한 ARIA 역할을 삭제하면 '구독'이라는 단어가 액세스 가능한 버튼 이름이 됩니다. 이 기능은 시맨틱 HTML 버튼 요소에 내장되어 있습니다. 더 복잡한 상황에서는 고려할 추가 패턴 옵션이 있습니다.

<button type="submit" tabindex="1">Subscribe</button>

문제 4: 이미지 대체 속성

이미지 요소에 [alt] 속성이 누락되었습니다. 정보 요소는 짧아야 하며 설명을 제공하는 대체 텍스트를 목표로 해야 합니다. 장식 요소는 빈 Alt 속성을 사용하여 무시할 수 있습니다. 이미지 대체 텍스트 규칙 자세히 알아보기

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>

수정해 보겠습니다.

로고 이미지도 링크이므로 이미지 모듈에서 실행 가능한 이미지라고 하며 이미지 용도에 관한 대체 텍스트 정보가 필요하다는 것을 알 수 있습니다. 일반적으로 페이지의 첫 번째 이미지는 로고이므로 AT 사용자가 이를 알고 있다고 합리적으로 추측할 수 있으므로 이미지 설명에 이러한 추가 문맥 정보를 추가하지 않을 수 있습니다.

<a href="index.html">
  <img src="https://upload.wikimedia.org/wikipedia/commons/….png"
    alt="Go to the home page.">
</a>

문제 5: 링크 텍스트

링크에 식별 가능한 이름이 없습니다. 눈에 띄고 고유하며 포커스 가능한 링크 텍스트 (및 이미지로 사용되는 경우 이미지의 대체 텍스트)는 스크린 리더 사용자의 탐색 환경을 개선합니다. 링크 텍스트 규칙에 대해 자세히 알아보기

<a href="#!"><svg><path>...</path></svg></a>

수정해 보겠습니다.

페이지의 모든 실행 가능 이미지에는 링크를 통해 사용자를 보내는 위치에 관한 정보가 포함되어야 합니다. 이 문제를 해결하는 한 가지 방법은 위 예의 로고 이미지에서와 마찬가지로, 목적에 관한 대체 텍스트를 이미지에 추가하는 것입니다. 이는 <img> 태그를 사용하는 이미지에서 효과적이지만 <svg> 태그에서는 이 메서드를 사용할 수 없습니다.

<svg> 태그를 사용하는 소셜 미디어 아이콘의 경우 SVG를 타겟팅하는 다른 대체 설명 패턴을 사용하고, <a> 태그와 <svg> 태그 사이에 정보를 추가한 다음 사용자에게 시각적으로 숨기거나, 지원되는 ARIA 또는 기타 옵션을 추가할 수 있습니다. 환경 및 코드 제한사항에 따라 한 방법이 다른 방법보다 선호될 수 있습니다. 가장 도움이 되는 기술 적용 범위와 함께 가장 간단한 패턴 옵션을 사용해 보겠습니다. role="img"를 <svg> 태그에 추가하고 <title> 요소를 포함하는 것입니다.

<a href="#!">
  <svg role="img">
    <title>Connect on our Twitter page.</title>
    <path>...</path>
  </svg>
</a>

문제 6: 색상 대비

배경 및 전경 색상의 대비율이 충분하지 않습니다. 많은 사용자가 저대비 텍스트를 읽는 데 어려움을 겪거나 전혀 읽지 못합니다. 색상 대비 규칙 자세히 알아보기

2가지 예가 보고되었습니다.

문제 해결

웹페이지에서 여러 색상 대비 문제가 감지되었습니다. 색상 및 대비 모듈에서 배운 것처럼 일반 크기의 텍스트 (18pt / 24px 미만)의 색상 대비 요구사항은 4.5:1이고, 큰 텍스트 (최소 18pt / 24px 또는 14pt / 18.5px 굵게) 및 필수 아이콘은 3:1 요구사항을 충족해야 합니다.

페이지 제목의 경우 청록색 텍스트는 24px의 큰 텍스트이므로 3:1 색상 대비 요구사항을 충족해야 합니다. 그러나 청록색 버튼은 16px 굵게 일반 크기의 텍스트로 간주되므로 4.5:1 색상 대비 요구사항을 충족해야 합니다.

이 경우 4.5:1을 충족하도록 충분히 어두운 청록색을 찾거나 버튼 텍스트의 크기를 굵은 18.5픽셀로 늘리고 청록색 값을 약간 변경할 수 있습니다. 두 방법 모두 디자인 미학에 부합합니다.

페이지에서 가장 큰 두 가지 제목을 제외하고 흰색 배경의 모든 회색 텍스트도 색상 대비에 실패합니다. 4.5:1 색상 대비 요구사항을 충족하려면 이 텍스트를 어둡게 해야 합니다.

문제 7 - 목록 구조

목록 항목 (<li>)이 <ul> 또는 <ol> 상위 요소 내에 포함되지 않음 스크린 리더를 사용하려면 목록 항목 (<li>)이 상위 <ul> 또는 <ol> 내에 포함되어 있어야 제대로 읽을 수 있습니다.

목록 규칙 자세히 알아보기

<div class="ul">
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</div>

수정해 보겠습니다.

이 데모에서는 <ul> 태그를 사용하는 대신 CSS 클래스를 사용하여 순서가 지정되지 않은 목록을 시뮬레이션했습니다. Google은 이 코드를 부적절하게 작성했을 때 이 태그에 내장된 고유한 시맨틱 HTML 기능을 삭제했습니다. 이 클래스를 실제 <ul> 태그로 대체하고 관련 CSS를 수정하여 이 접근성 문제를 해결했습니다.

<ul>
  <li><a href="#">About</a></li>
  <li><a href="#">Community</a></li>
  <li><a href="#">Donate</a></li>
  <li><a href="#">Q&A</a></li>
  <li><a href="#">Subscribe</a></li>
</ul>

문제 #8 - tabindex

일부 요소는 0보다 큰 [tabindex] 값을 가집니다. 0보다 큰 값은 명시적인 탐색 순서를 의미합니다. 이는 기술적으로는 유효하지만 보조 기술에 의존하는 사용자에게 불편한 경험을 제공하는 경우가 많습니다. tabindex 규칙 자세히 알아보기

<button type="submit" tabindex="1">Subscribe</button>

수정해 보겠습니다.

웹페이지에서 자연스러운 탭 동작을 방해할 특별한 이유가 없는 한 tabindex 속성에 양의 정수를 사용할 필요는 없습니다. 탭 이동 순서를 자연스럽게 유지하려면 tabindex를 0로 변경하거나 속성을 완전히 삭제하면 됩니다.

<button type="submit">Subscribe</button>

6단계

자동화된 접근성 문제를 모두 수정했으므로 이제 새 디버그 모드 페이지를 엽니다. Lighthouse 접근성 감사를 다시 실행합니다. 첫 실행보다 점수가 훨씬 높습니다.

이러한 자동화된 접근성 업데이트를 모두 새 CodePen에 적용했습니다.

다음 단계

잘하셨습니다. 이미 많은 성과를 내셨지만, 아직 끝나지 않았습니다! 다음으로 수동 접근성 테스트 모듈에 설명된 수동 검사를 진행합니다.

학습 내용 확인하기

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