수동 테스트 기본사항
수동 접근성 테스트는 키보드, 시각, 인지 테스트, 도구, 기술을 사용하여 자동 도구로 찾을 수 없는 문제를 찾습니다. 자동 도구는 WCAG에서 식별된 모든 성공 기준을 다루지 않으므로 자동 접근성 테스트를 실행하고 테스트를 계속 하는 것이 매우 중요합니다.
기술이 발전함에 따라 더 많은 테스트를 자동 도구만으로 다룰 수 있지만, 현재는 적용 가능한 모든 WCAG 체크포인트를 다루기 위해 테스트 프로토콜에 수동 및 보조 기술 검사를 모두 추가해야 합니다.
수동 접근성 테스트의 이점은 다음과 같습니다.
- 비교적 간단하고 빠르게 실행할 수 있습니다.
- 자동 테스트만으로는 찾을 수 없는 더 높은 비율의 문제를 발견할 수 있습니다.
- 성공에 필요한 도구와 전문 지식이 거의 없습니다.
수동 접근성 테스트의 단점은 다음과 같습니다.
- 자동 테스트보다 더 복잡하고 시간이 오래 걸립니다.
- 대규모로 반복하기 어려울 수 있습니다.
- 테스트를 실행하고 결과를 해석하려면 더 많은 접근성 전문 지식이 필요합니다.
자동 도구로 감지할 수 있는 접근성 요소와 세부정보를 감지할 수 없는 요소와 비교합니다.
수동 테스트 유형
웹페이지 또는 앱의 디지털 접근성을 살펴볼 때 고려해야 할 수동 도구와 기술은 다양합니다. 수동 테스트의 세 가지 주요 초점 영역은 키보드 기능, 시각 중심 검토, 일반 콘텐츠 검사입니다.
이 모듈에서는 이러한 각 주제를 대략적으로 다루지만, 다음 테스트는 실행할 수 있거나 실행해야 하는 모든 수동 테스트의 전체 목록이 아닙니다. 신뢰할 수 있는 소스의 수동 접근성 체크리스트로 시작하여 특정 디지털 제품 및 팀 요구사항에 맞는 자체 집중 수동 테스트 체크리스트를 개발하는 것이 좋습니다.
키보드 검사
모든 디지털 접근성 문제의 약 25% 가 키보드 지원 부족과 관련이 있는 것으로 추정됩니다. 키보드 포커스 모듈에서 살펴본 바와 같이 이는 시력이 있는 키보드 전용 사용자, 저시력/시각장애인 스크린 리더 사용자, 키보드 접근 가능한 콘텐츠에 의존하는 기술을 사용하는 음성 인식 소프트웨어를 사용하는 사람 등 모든 유형의 사용자에게 영향을 미칩니다.
키보드 테스트는 다음과 같은 질문에 답합니다.
- 웹페이지 또는 기능이 작동하려면 마우스가 필요한가요?
- 탭 순서가 논리적이고 직관적인가요?
- 키보드 포커스 표시기가 항상 표시되나요?
- 포커스를 트래핑하지 않아야 하는 요소에 갇힐 수 있나요?
- 포커스를 트래핑해야 하는 요소 뒤나 주변을 탐색할 수 있나요?
- 포커스를 받은 요소를 닫을 때 포커스 표시기가 논리적인 위치로 돌아갔나요?
키보드 기능의 영향은 크지만 테스트 절차는 매우 간단합니다. 마우스를 치워두거나 작은 JavaScript 패키지를 설치하고 키보드만 사용하여 웹사이트를 테스트하면 됩니다. 다음 명령어는 키보드 테스트에 필수적입니다.
시각적 검사
시각적 검사는 페이지의 시각적 요소에 초점을 맞추고 화면 확대 또는 브라우저 확대/축소와 같은 도구를 사용하여 웹사이트 또는 앱의 접근성을 검토합니다.
시각적 검사를 통해 다음을 확인할 수 있습니다.
- 자동 도구로 감지할 수 없는 색상 대비 문제(예: 그라데이션 또는 이미지 위에 있는 텍스트)가 있나요?
- 제목, 목록, 기타 구조적 요소처럼 보이지만 코딩되지 않은 요소가 있나요?
- 탐색 링크와 양식 입력이 웹사이트 또는 앱 전체에서 일관되나요?
- 권장사항을 초과하는 깜박임, 스트로빙, 애니메이션이 있나요?
- 콘텐츠에 적절한 간격이 있나요? 글자, 단어, 줄, 단락의 경우
- 화면 확대기 또는 브라우저 확대/축소를 사용하여 모든 콘텐츠를 볼 수 있나요?
콘텐츠 검사
레이아웃, 움직임, 색상에 초점을 맞추는 시각적 테스트와 달리 콘텐츠 검사는 페이지의 단어에 초점을 맞춥니다. 카피 자체를 살펴보는 것뿐만 아니라 다른 사용자에게 의미가 있는지 컨텍스트를 검토해야 합니다.
콘텐츠 검사는 다음과 같은 질문에 답합니다.
- 페이지 제목, 제목, 양식 라벨이 명확하고 설명적인가요?
- 이미지 대체 텍스트가 간결하고 정확하며 유용한가요?
- 색상만 의미 또는 정보를 전달하는 유일한 방법으로 사용되나요?
- 링크가 설명적인가요 아니면 '자세히 알아보기' 또는 '여기를 클릭하세요'와 같은 일반적인 텍스트를 사용하나요?
- 페이지 내에서 언어가 변경되나요?
- 일반 언어가 사용되고 모든 약어가 처음 참조될 때 철자가 표시되나요?
일부 콘텐츠 검사는 부분적으로 자동화할 수 있습니다. 예를 들어 '여기를 클릭하세요'를 확인하고 변경을 제안하는 JavaScript 린터를 작성할 수 있습니다. 하지만 이러한 맞춤 솔루션은 여전히 카피를 컨텍스트에 맞는 것으로 변경하는 데 사람이 필요한 경우가 많습니다.
데모: 수동 테스트
지금까지 데모 웹페이지에서 자동 테스트를 실행하고 8가지 문제 유형을 찾아 해결했습니다. 이제 수동 검사를 실행하여 더 많은 접근성 문제를 발견할 수 있는지 확인해 보겠습니다.
1단계
업데이트된 CodePen 데모에는 모든 자동 접근성 업데이트가 적용되어 있습니다.
디버그 모드에서 확인하여
다음 테스트를 진행합니다. 이는 일부 테스트 도구를 방해할 수 있는 데모 웹페이지를 둘러싸는 <iframe>을 삭제하므로 중요합니다. CodePen의 디버그 모드에 관해 자세히 알아보세요.
2단계
마우스 또는 트랙패드를 치워두고 키보드만 사용하여 DOM을 위아래로 탐색하여 수동 테스트 프로세스를 시작합니다.
문제 1: 표시되는 포커스 표시기
표시되는 포커스 표시기가 삭제되었으므로 첫 번째 키보드 문제가 바로 표시됩니다. 아니, 표시되지 않아야 합니다. 데모에서 CSS를 스캔하면 코드베이스에 추가된 'outline: none'이 표시됩니다.
:focus {
outline: none;
}
해결해 보겠습니다.
키보드 포커스 모듈에서 살펴본 바와 같이 웹브라우저에서 사용자에게 표시되는 포커스를 추가하려면 이 코드 줄을 삭제해야 합니다. 한 단계 더 나아가 디지털 제품의 미적 감각에 맞는 스타일의 포커스 표시기를 만들 수 있습니다.
:focus {
outline: 3px dotted #008576;
}
문제 2: 포커스 순서
포커스 표시기를 수정하고 표시되면 페이지를 탭하세요. 이렇게 하면 뉴스레터 구독에 사용되는 양식 입력란에 포커스가 표시되지 않습니다. 음수 tabindex로 인해 자연스러운 포커스 순서에서 삭제되었습니다.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
사용자가 이 입력란을 사용하여 뉴스레터를 신청하도록 하려면 음수 tabindex를 삭제하거나 0으로 설정하여 입력이 다시 키보드 포커스 가능하도록 하면 됩니다.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
3단계
키보드 포커스를 확인한 후 시각적 검사 및 콘텐츠 검사로 이동합니다.
문제 3: 링크 색상 대비
데모 페이지를 위아래로 탭하여 키보드 테스트를 진행하면서 다양한 질병에 관한 단락에서 시각적으로 숨겨진 세 개의 링크에 키보드 포커스가 맞춰진 것을 확인했을 것입니다.
페이지에 접근할 수 있으려면 링크가 주변 텍스트와 눈에 띄게 구분되어야 하며 마우스 오버 및 키보드 포커스 시 색상이 아닌 스타일 변경이 포함되어야 합니다.
해결해 보겠습니다.
빠른 해결책은 단락 내 링크에 밑줄을 추가하여 눈에 띄게 만드는 것입니다. 이렇게 하면 접근성 문제가 해결되지만 달성하려는 전반적인 디자인 미적 감각에 맞지 않을 수 있습니다.
밑줄을 추가하지 않으려면 배경과 카피 모두의 요구사항을 충족하도록 색상을 수정해야 합니다.
링크 대비 검사기 도구를 사용하여 데모를 살펴보면 링크 색상이 일반 크기 텍스트와 배경 간의 4.5:1 색상 대비 요구사항을 충족하는 것을 확인할 수 있습니다. 하지만 밑줄이 없는 링크도 주변 텍스트에 대해 3:1 색상 대비 요구사항을 충족해야 합니다.
한 가지 방법은 링크 색상을 페이지의 다른 요소와 일치하도록 변경하는 것입니다. 하지만 링크 색상을 녹색으로 변경하면 링크, 배경, 주변 텍스트의 세 가지 요소 간의 전반적인 색상 대비 요구사항을 충족하도록 본문 카피도 수정해야 합니다.
문제 4: 아이콘 색상 대비
놓친 또 다른 색상 대비 문제는 소셜 미디어 아이콘입니다. 색상 및 대비 모듈에서 필수 아이콘은 배경에 대해 3:1 색상 대비를 충족해야 한다고 배웠습니다. 하지만 데모에서 소셜 미디어 아이콘의 대비율은 1.3:1입니다.
해결해 보겠습니다.
3:1 색상 대비 요구사항을 충족하기 위해 소셜 미디어 아이콘이 더 어두운 회색으로 변경됩니다.
문제 5: 콘텐츠 레이아웃
단락 콘텐츠의 레이아웃을 살펴보면 텍스트가 완전히 양쪽 정렬되어 있습니다. 서체 모듈에서 살펴본 바와 같이 이렇게 하면 '공간의 강'이 생성되어 일부 사용자가 텍스트를 읽기 어려울 수 있습니다.
p.bullet {
text-align: justify;
}
데모에서 텍스트 정렬을 재설정하려면 코드를 text-align: left;로 업데이트하거나 CSS에서 해당 줄을 완전히 삭제하면 됩니다. 왼쪽이 브라우저의 기본 정렬이기 때문입니다. 다른 상속된 스타일이 기본 텍스트 정렬을 삭제하는 경우를 대비하여 코드를 테스트해야 합니다.
p.bullet {
text-align: left;
}
4단계
이전 단계에서 설명한 모든 수동 접근성 문제를 식별하고 해결하면 페이지가 스크린샷과 비슷하게 표시됩니다.
이 모듈에서 다룬 것보다 더 많은 접근성 문제가 수동 검사에서 발견될 수 있습니다. 이러한 문제는 다음 모듈에서 많이 발견될 것입니다.
다음 단계
수고하셨습니다 자동 및 수동 테스트 모듈을 완료했습니다. 자동 및 수동 접근성 수정사항이 모두 적용된 업데이트된 CodePen을 볼 수 있습니다.