자동화된 접근성 테스트

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

나머지 모듈에서는 설계 및 빌드에서 테스트로 넘어갑니다. 제공합니다. Google은 다음과 같은 3단계 테스트 프로세스를 활용합니다. 자동화, 수동 및 보조 기술 테스트 도구 및 기법에 대한 것입니다. 이제 이러한 테스트 모듈 전체에서 동일한 데모를 사용하여 액세스할 수 없습니다.

자동, 수동, 보조 기술의 각 테스트가 가장 접근하기 쉬운 제품입니다.

테스트는 웹 콘텐츠 접근성 가이드라인 (WCAG) 2.1을 따릅니다. 적합성 수준 A 및 AA를 있습니다. 업계, 제품 유형, 현지/국가의 법률 및 정책이나 전반적인 접근성 목표에 따라 사용자에게 제공할 가이드라인을 만나게 될 것입니다. 운영 체제에 대한 특정 표준이 필요하지 않은 경우 최신 버전의 WCAG를 따르는 것이 좋습니다. 자세한 내용은 '디지털 접근성은 어떻게 측정하나요?'를 접근성 감사, 적합성 유형/수준 WCAG 및 POUR.

아시다시피 접근성 적합성은 모든 것을 갖추는 것이 아닙니다. 장애인 지원에 더욱 박차를 가합니다 하지만 데이터 애널리스트의 이는 테스트할 수 있는 측정항목을 제공하기 때문입니다. 또한 접근성 적합성 테스트 외의 추가 작업(예: 장애인을 대상으로 사용성 테스트를 진행하고, 장애가 있는 사람을 개인이나 회사와 협력하여 팀에서 일하거나 디지털 접근성 전문성을 기반으로 더 포괄적인 제품을 만들 수 있도록 지원합니다.

자동화된 테스트 기본사항

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

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

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

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

• 자동화된 도구로 제품의 모든 접근성 오류를 찾아낼 수는 없습니다.
• 보고된 거짓양성 (실제 WCAG 위반이 아닌 문제가 보고된 경우)
• 제품 유형 및 역할에 따라 여러 도구가 필요할 수 있음

자동 테스트는 웹사이트 또는 앱을 점검하는 효과적인 첫 단계입니다. 모든 검사를 자동화할 수 있는 것은 아닙니다. 다음 동영상에서 자동화될 수 없는 요소의 접근성을 확인하는 방법을 수동 접근성 테스트 모듈에 오신 것을 환영합니다.

자동화 도구 유형

최초의 온라인 자동화된 접근성 테스트 도구 중 하나는 1996년 응용 특수 기술 센터 (CAST)에서 "바비 리포트." 오늘날에는 100개가 넘는 자동 테스트 도구를 선택하여 시작

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

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

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

이외에도 고려해야 할 여러 가지 요인이 있습니다. WAI 도움말 확인 '웹 접근성 평가 도구 선택' 섹션을 참조하세요. 을 확인하세요.

데모: 자동 테스트

자동화된 접근성 테스트 데모에서는 Chrome의 Lighthouse. Lighthouse는 데이터의 품질을 개선하기 위해 만들어진 자동화된 오픈소스 도구입니다. 실적, 검색엔진 최적화(SEO), 검색엔진 최적화(SEO), 액세스할 수 있습니다

이 데모는 'Medical Mysteries'라는 가짜 조직을 위해 만든 웹사이트입니다. 클럽에서 일하고 있습니다. 이 사이트는 의도적으로 데모에서 액세스할 수 없도록 설정되었습니다. 이 중 일부 접근성이 좋지 않은 사용자에게 표시될 수 있으며, 모든 사용자가 아닌 일부 자동화 테스트를 실행합니다.

1단계

Chrome 브라우저를 사용하여 Lighthouse 확장 프로그램.

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

2단계

CodePen에 데모가 빌드되었습니다. 디버그 모드에서 확인하고 다음 테스트를 실행합니다. 이 메서드는 요소를 둘러싸는 <iframe>를 삭제하므로 중요합니다. 데모 웹페이지로 인해 일부 테스트 도구에 지장을 줄 수 있습니다. 다음에 대해 자세히 알아보기 CodePen의 디버그 모드

3단계

Chrome DevTools를 열고 Lighthouse 탭으로 이동합니다. 다음을 제외한 모든 카테고리 옵션을 선택 해제합니다. '접근성'입니다. 모드를 기본값으로 유지하고 사용하려는 기기 유형을 선택하세요. 실행할 수 있습니다

4단계

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

테스트가 완료되면 Lighthouse는 액세스할 수 있어야 합니다 이 Lighthouse 점수 문제의 수, 문제 유형, 사용자에게 미치는 영향을 기준으로 확인할 수 있습니다

Lighthouse 보고서에는 점수 외에도 문제 해결에 대해 자세히 알아볼 수 있는 리소스 링크 있습니다. 보고서에는 통과했거나 해당되지 않는 테스트와 수동으로 확인할 추가 항목의 목록입니다.

5단계

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

문제 1: ARIA 역할

첫 번째 문제는 "ARIA [역할] 이 포함되어 있고 하위 요소가 특정 [역할] 에 필수 하위 요소의 일부 또는 전부가 누락된 경우 일부 ARIA 상위 역할은 특정 하위 역할을 포함해야 제공합니다. ARIA 역할 규칙 자세히 알아보기

데모에서 뉴스레터 구독 버튼이 작동하지 않습니다.

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

</ph> 문제를 해결해 보세요.

'구독' 입력란 옆에 있는 버튼에 잘못된 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>

</ph> 문제를 해결해 보세요.

입력란에 aria-hidden="true" 속성이 적용되었습니다. 추가 중 이 속성은 요소 (및 그 아래에 중첩된 모든 항목)를 보조 기술.

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

이 경우 입력에서 이 속성을 삭제하여 다른 사람이 양식 입력란에 정보를 입력하고 보조 공학을 사용합니다.

문제 3: 버튼 이름

버튼에 액세스 가능한 이름이 없습니다. 버튼에 스크린 리더가 '버튼'이라고 알려주고 Kubernetes에서 사용자에게 더 많이 적합합니다. 버튼 이름 규칙 자세히 알아보기

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

</ph> 문제를 해결해 보세요.

애플리케이션의 버튼 요소에서 부정확한 ARIA 역할을 삭제하면 문제 1, '구독'이라는 단어 액세스할 수 있는 버튼이 됩니다. 있습니다. 이 기능은 시맨틱 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>

</ph> 문제를 해결해 보세요.

로고 이미지도 링크이므로 실행 가능한 이미지 모듈로 분류되며 이미지의 용도에 대한 대체 텍스트 정보가 필요합니다. 일반적으로 페이지의 첫 번째 이미지는 로고이므로 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>

</ph> 문제를 해결해 보세요.

페이지의 모든 실행 가능한 이미지에는 링크를 통해 사용자를 보낼 수 있습니다. 이 문제를 해결하는 한 가지 방법은 이미지에 대한 텍스트도 추가할 수 있습니다. 예로 들 수 있습니다 <img> 태그를 사용하는 이미지에는 적합하지만 <svg> 태그에서 이 메서드를 사용할 수 없습니다.

<svg> 태그를 사용하는 소셜 미디어 아이콘의 경우 다양한 대체 설명 패턴 <a> 및 <svg> 태그 사이에 정보를 추가한 다음 사용자에게 표시되지 않도록 숨기거나 지원되는 ARIA 또는 기타 옵션을 추가할 수 있습니다. 상황에 따라 환경 및 코드 제한에 따라 한 가지 방법이 있습니다. 가장 보조적인 값이 포함된 가장 간단한 패턴 옵션을 <svg> 태그에 role="img"를 추가하고 기술 적용 범위 (<title> 요소 포함)

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

문제 6: 색상 대비

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

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

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder">를 통해 개인정보처리방침을 정의할 수 있습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph>

</ph> 문제를 해결해 보세요.

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

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

이 경우 4.5:1을 충족시킬 만큼 어두운 청록색 색상을 찾을 수 있습니다. 버튼 텍스트의 크기를 18.5픽셀 굵게로 늘리고 청록색 값이 약간 있습니다. 두 방법 모두 디자인과 일치하도록 합니다. 있습니다.

흰색 배경의 회색 텍스트는 모두 색상 대비에도 실패합니다. 을 입력합니다. 이 텍스트를 어둡게 해야 4.5:1 색상 대비 요구사항을 충족해야 합니다.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder"></ph> <ph type="x-smartling-placeholder">를 통해 개인정보처리방침을 정의할 수 있습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder"></ph>

문제 #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>

</ph> 문제를 해결해 보세요.

이 데모에서는 CSS 클래스를 사용하여 순서가 지정되지 않은 목록을 <ul> 태그 사용 이 코드를 부적절하게 작성하면 내재된 의미론적 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

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

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

</ph> 문제를 해결해 보세요.

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

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

6단계

이제 자동화된 접근성 문제를 모두 해결했으므로 새 디버그 모드 페이지입니다. Lighthouse 접근성 감사를 다시 실행합니다. 내 점수 첫 번째 실행보다 훨씬 나아질 것입니다.

이렇게 자동화된 접근성 업데이트를 모두 새로운 CodePen과 같은 메서드를 사용합니다.

다음 단계

잘하셨습니다. 많은 업적을 달성하셨지만 아직 끝나지 않았습니다. 다음으로 다음 단계 설명처럼 수동 검사로 넘어가서 수동 접근성 테스트 모듈에 오신 것을 환영합니다.

이해도 확인

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