수동 테스트 기본사항
수동 접근성 테스트는 키보드, 시각, 인지 테스트, 도구, 기법을 사용하여 자동화된 도구로는 해결할 수 없는 문제를 찾습니다. 자동화된 도구는 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을 확인할 수 있습니다.
이제 지원 기술 테스트에 중점을 둔 마지막 테스트 모듈로 이동합니다.
학습 내용 확인하기
수동 접근성 테스트에 관한 지식 테스트
WCAG 색상 대비 표준을 충족해야 하는 요소는 무엇인가요?