제품 테스트하기

제품의 접근성을 테스트하는 가이드예요. 접근성 문제와 개선 기회를 찾기 위해 제품의 접근성을 견고하게 테스트하는 데 쓸 수 있는 지침과 권장사항을 담고 있어요. 이 가이드가 모든 시나리오를 다루지는 않는다는 점을 명심하세요.

출처: Test Your Product

본문

표준 테스트 절차

많은 접근성 문제는 몇 가지 표준 검사만으로도 발견할 수 있어요.

HTML 검증하기

좋은 접근성 관행은 구조적이고 의미론적인 HTML에서 시작돼요. 스크린 리더(또는 어떤 종류의 보조 기술이든)가 웹 페이지를 스캔할 때, 그것은 DOM(Document Object Model), 즉 페이지의 HTML 구조에 대한 정보를 얻어요. 스타일이나 JavaScript는 스크린 리더가 읽지 않습니다.

스크린 리더(VoiceOver(VO), NVDA, JAWS 등)는 텍스트를 음성으로 바꿔주기만 하는 게 아니에요. HTML의 정보를 사용해 페이지의 모든 제목을 나열하고, 데이터 테이블에 추가 탐색 컨트롤을 제공하며, 목록에 항목이 몇 개인지 알려주는 등 다양한 일을 해요. 이 때문에 의미론적 HTML이 필수적입니다.

W3C의 markup validation service 같은 HTML 검증 도구로 제품을 테스트할 수 있어요.

감사 도구로 접근성 위반 확인하기

PatternFly를 사용할 때는 aXe: The Accessibility Engine(aXe DevTools, Chrome 확장 프로그램, 또는 Firefox 확장 프로그램 사용)으로 로컬에서 접근성 위반을 확인하는 것을 권장해요. 배포 전에 테스트하고 싶다면 aXe를 Cypress와 통합할 수 있어요.

patternfly-a11y 스크립트로 대량 테스트하기

우리는 대량 테스트용 patternfly-a11y 스크립트를 제공하며, 이 스크립트는 페이지 집합에서 발생하는 aXe 접근성 위반을 보고해요. 인증을 포함하고, 특정 항목(로딩 스피너 같은)이 로드 완료될 때까지 기다리거나, 사용 사례와 관련된 다른 항목을 처리하는 구성 파일을 만들어 스크립트를 필요에 맞게 조정할 수 있어요. 이 스크립트는 surge를 통해 접근성 보고서를 전달합니다.

이 스크립트를 사용하기 전에 CI 워크플로우에서 UI를 빌드해야 해요. 빌드가 완료되면 그 빌드에 대해 스크립트를 실행하는 작업(job)을 만드세요. 스크립트는 웹 서버가 실행 중이고 스크립트가 도달할 수 있는 곳(예: localhost:8000)에서 제품을 서빙하고 있다고 가정해요.

키보드 접근성 테스트하기

키보드는 필수적인 접근성 도구이므로 다음 요구사항이 충족되는지 확인해야 해요:

모든 기능이 키보드로 접근 가능하다.
HTML과 레이아웃의 요소가 논리적 순서를 따른다.
포커스가 있는 요소가 명확히 보인다.

스타일 없이 테스트하기

스크린 리더는 스타일 정보에 접근할 수 없으므로, 제품의 스타일을 비활성화하고 정보 아키텍처가 효과적인지, 요소에 적절한 텍스트 라벨이 있는지 테스트해야 해요.

사용 중인 브라우저에서 이 기능을 사용할 수 없다면, WebAIM의 WAVE 브라우저 확장 프로그램으로 스타일을 비활성화할 수 있어요.

스크린 리더로 테스트하기

운영체제에서 사용할 수 있는 어떤 스크린 리더로든 테스트할 수 있어요. PatternFly에서는 다음을 대상으로 해요:

JAWS + Chrome, Windows (JAWS 키보드 단축키).
VoiceOver + Safari, Mac (VoiceOver 키보드 단축키).
NVDA + Firefox, Windows (NVDA 키보드 단축키).

색상 대비 확인하기

UI의 색상은 다음 대비 검사를 통과해, 시각 스펙트럼 전반의 사용자가 제품을 이해할 수 있도록 해야 해요:

배경색에 대한 텍스트 색상 (Understanding WCAG 1.4.3).
링크 색상에 대한 텍스트 색상 (WCAG Technique G183).
인접한 배경색에 대한 버튼과 폼 요소의 보이는 경계 (Understanding WCAG 1.4.11).

접근성 테스트 체크리스트

테스트 진행 상황을 추적하기 위해 다음 체크리스트를 참조하는 것을 권장해요.

이 체크리스트는 PatternFly 팀이 UI가 일관된 접근성 표준을 충족하는지 확인하기 위해 점검하는 주요 영역 중 일부를 포함해요. 특정 구현을 평가하려면 제품에서도 같은 영역을 점검하는 것을 권장합니다.

광범위한 접근성 기준

Rotor 탐색으로 모든 정보를 발견할 수 있다.
단축키 탐색으로 모든 정보를 발견할 수 있다. 예를 들어 페이지의 모든 제목 사이를 탐색하는 키보드 단축키는 의도된 모든 제목을 발견해야 해요.
커서 탐색으로 적용 가능한 모든 정보를 발견할 수 있다. 일부 보조 기술은 자체 탐색·포커스 관리 수단을 가질 수 있어요. 예를 들어 VoiceOver는 'VO' 키와 오른쪽·왼쪽 화살표 키를 사용해 페이지를 탐색해요. 이는 기존 키보드 탐색과 다를 수 있습니다.
키보드 Tab 키 탐색으로 모든 정보를 발견할 수 있다. 콘텐츠가 스크린 리더 같은 다른 보조 기술에서 숨겨져야 한다면, 대신 aria-hidden="true"를 전달해야 해요.
UI 요소가 이해하기 쉽고 사용 가능하다. 키보드나 다른 보조 기술로 요소에 탐색하면, 그 항목을 쉽게 이해하고 사용할 수 있어야 해요.
탐색 시 정보의 흐름이 이치에 맞다. 보조 기술(스크린 리더 등)은 DOM 순서대로 페이지를 탐색해요. CSS로 요소를 시각적으로 재배치하면, 요소가 비논리적인 순서로 발화될 수 있어요. 무언가가 페이지에 더 일찍 나타나야 한다면, DOM에서 그것을 더 일찍 물리적으로 이동해 보세요.

구조적 접근성 기준

구조: 시각적 정보 아키텍처가 기본적으로 존재하는 다양한 rotor 메뉴에 매핑된다.
Rotor에 서술적이고 간결한 제목·랜드마크·링크·폼 컨트롤·테이블·기타 요소가 있다.
제목 수준이 구조/콘텐츠를 전달하며 수준을 건너뛰지 않는다. 일반적인 관행은 페이지의 기본 헤드라인이나 로고에 단일 h1을, 주요 섹션을 지정하는 데 h2를, 보조 섹션에 h3를 사용하는 것입니다.
랜드마크(Landmarks)
링크(Links)
폼 컨트롤(Form controls)
테이블(Tables)
라벨(Labels):
- 링크 라벨은 서술적이고, 유익하며, 고유하다(같은 URL을 공유하지 않는 한).
- 버튼과 폼 컨트롤:
  - 모든 폼 컨트롤에 명확하고 서술적인 라벨이 있다.
  - 확장 가능한 버튼은 확장 컨트롤을 표시하고 aria-expanded를 사용해 버튼이 확장 가능함을 나타낸다. 버튼이 확장 가능하도록 의도된 경우 aria-expanded는 항상 불리언 값을 가져야 한다.
- 폼 입력에는 라벨이 있다(보이지 않더라도).
- 아이콘에는 스크린 리더용 텍스트가 있다(보이지 않더라도).
- 이미지에는 적절한 alt 텍스트가 있다. 이 관행의 예외는 이미지가 주로 보여주기용이고 필수 콘텐츠가 아닌 경우다. 스크린 리더가 이미지를 건너뛰도록 지정하려면 alt 속성 값을 빈 문자열로 설정하세요: alt="".
랜드마크 영역이 2종 이상이고 동일하지 않은 경우(navigation, main, form 등)에는 라벨이 있어야 한다. section 요소는 라벨이 없으면 사용하면 안 된다.
테이블과 테이블 콘텐츠는 명확히 설명된다. WebAIM에는 접근 가능한 테이블 만들기에 대한 추가 지침이 있다.
ARIA 라벨은 이미 있는 텍스트를 반복하거나 덮어쓰지 않고 스크린 리더 사용자에게 서술적 세부 정보를 제공한다. 보이는 텍스트가 있으면 ARIA 라벨이 필요하지 않다.

제품 테스트하기