수동 테스트 기본사항
수동 접근성 테스트에서는 키보드, 시각, 인지 테스트, 도구, 기법을 사용하여 자동 도구로는 찾을 수 없는 문제를 찾습니다. 자동화된 도구는 WCAG에서 식별된 모든 성공 기준을 다루지 않으므로 자동 접근성 테스트를 실행하고 계속 테스트하는 것이 중요합니다.
기술이 발전함에 따라 자동 도구만으로 더 많은 테스트를 실행할 수 있게 될 수도 있지만, 현재는 적용 가능한 모든 WCAG 체크포인트를 다루려면 테스트 프로토콜에 수동 및 보조 기술 검사를 모두 추가해야 합니다.
수동 접근성 테스트의 이점:
- 비교적 간단하고 빠르게 실행할 수 있음
- 자동 테스트만으로는 잡을 수 없는 문제를 더 많이 포착
- 성공에 필요한 도구와 전문 지식이 거의 없음
수동 접근성 테스트의 단점:
- 자동 테스트보다 더 복잡하고 시간이 오래 걸림
- 대규모로 반복하기 어려울 수 있음
- 테스트를 실행하고 결과를 해석하려면 접근성 전문 지식이 더 필요함
자동화된 도구에서 감지할 수 있는 접근성 요소와 세부정보와 감지할 수 없는 요소를 비교합니다.
수동 테스트 유형
디지털 접근성을 위해 웹페이지나 앱을 살펴볼 때 고려해야 할 수동 도구와 기법이 많이 있습니다. 수동 테스트의 세 가지 주요 중점 분야는 키보드 기능, 시각적 리뷰, 일반 콘텐츠 확인입니다.
이 모듈에서는 이러한 각 주제를 개략적으로 다루지만 다음 테스트가 실행할 수 있거나 실행해야 하는 모든 수동 테스트의 전체 목록은 아닙니다. 신뢰할 수 있는 소스의 수동 접근성 체크리스트로 시작하여 특정 디지털 제품 및 팀 요구사항에 맞는 집중적인 수동 테스트 체크리스트를 개발하는 것이 좋습니다.
키보드 확인
모든 디지털 접근성 문제의 약 25% 가 키보드 지원 부족과 관련이 있는 것으로 추정됩니다. 키보드 포커스 모듈에서 살펴본 것처럼 이는 시력이 있는 키보드 전용 사용자, 저시력/시각 장애인 스크린 리더 사용자, 콘텐츠가 키보드로 액세스할 수 있는 기술을 사용하는 음성 인식 소프트웨어를 사용하는 사람 등 모든 유형의 사용자에게 영향을 미칩니다.
키보드 테스트는 다음과 같은 질문에 답합니다.
- 웹페이지 또는 기능이 작동하려면 마우스가 필요한가요?
- 탭 순서가 논리적이고 직관적인가요?
- 키보드 포커스 표시기가 항상 표시되나요?
- 포커스를 트래핑해서는 안 되는 요소에 갇힐 수 있나요?
- 포커스를 트래핑해야 하는 요소 뒤나 주변으로 이동할 수 있나요?
- 포커스를 받은 요소를 닫을 때 포커스 표시기가 논리적 위치로 돌아갔나요?
키보드 기능의 영향은 매우 크지만 테스트 절차는 매우 간단합니다. 마우스를 치우거나 작은 JavaScript 패키지를 설치하고 키보드만 사용하여 웹사이트를 테스트하면 됩니다. 다음 명령어는 키보드 테스트에 필수적입니다.
시각적 확인
시각적 검사는 페이지의 시각적 요소에 중점을 두며 화면 확대 또는 브라우저 확대/축소와 같은 도구를 사용하여 웹사이트 또는 앱의 접근성을 검토합니다.
시각적 검사를 통해 다음을 알 수 있습니다.
- 자동화된 도구에서 포착할 수 없는 색상 대비 문제가 있나요(예: 그라데이션이나 이미지 위에 있는 텍스트)?
- 제목, 목록, 기타 구조적 요소처럼 보이지만 이러한 요소로 코딩되지 않은 요소가 있나요?
- 탐색 링크와 양식 입력이 웹사이트 또는 앱 전체에서 일관되나요?
- 권장사항을 초과하는 깜박임, 스트로브 또는 애니메이션이 있나요?
- 콘텐츠의 간격이 적절한가요? 글자, 단어, 행, 단락의 경우
- 화면 돋보기 또는 브라우저 확대/축소를 사용하여 모든 콘텐츠를 볼 수 있나요?
콘텐츠 확인
레이아웃, 움직임, 색상에 중점을 두는 시각적 테스트와 달리 콘텐츠 확인은 페이지의 단어에 중점을 둡니다. 카피 자체를 살펴볼 뿐만 아니라 다른 사람에게도 의미가 있는지 맥락을 검토해야 합니다.
콘텐츠 확인을 통해 다음과 같은 질문에 대한 답을 얻을 수 있습니다.
- 페이지 제목, 머리말, 양식 라벨이 명확하고 이해하기 쉬운가요?
- 이미지 대체 텍스트가 간결하고 정확하며 유용한가요?
- 색상만 의미나 정보를 전달하는 유일한 방법으로 사용되나요?
- 링크에 설명이 포함되어 있나요? 아니면 '자세히 알아보기' 또는 '여기를 클릭하세요'와 같은 일반적인 텍스트를 사용하나요?
- 페이지 내 언어가 변경되나요?
- 쉬운 언어를 사용하고 약어를 처음 언급할 때 모두 철자로 표기했나요?
일부 콘텐츠 검사는 부분적으로 자동화할 수 있습니다. 예를 들어 '여기를 클릭하세요'를 확인하고 변경을 제안하는 JavaScript 린터를 작성할 수 있습니다. 하지만 이러한 맞춤 솔루션에서는 여전히 사람이 광고 문구를 상황에 맞는 내용으로 변경해야 하는 경우가 많습니다.
데모: 수동 테스트
지금까지 데모 웹페이지에서 자동 테스트를 실행하여 8가지 문제 유형을 발견하고 수정했습니다. 이제 더 많은 접근성 문제를 발견할 수 있는지 수동으로 확인할 준비가 되었습니다.
1단계
업데이트된 CodePen 데모에는 자동 접근성 업데이트가 모두 적용되어 있습니다.
디버그 모드에서 확인하여 다음 테스트를 진행하세요. 데모 웹페이지를 둘러싸고 있는 <iframe>가 삭제되므로 이는 중요합니다. <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: 링크 색상 대비
데모 페이지에서 탭을 위아래로 이동하여 키보드 테스트를 진행할 때 키보드가 다양한 질병에 관한 단락에서 시각적으로 숨겨진 링크 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을 확인하세요.
이제 보조 기술 테스트에 중점을 둔 마지막 테스트 모듈로 이동하세요.