수동 테스트 기본사항
수동 접근성 테스트는 키보드, 시각적, 인지 테스트, 도구, 자동화 도구에서 찾을 수 없는 문제를 찾을 수 있습니다. 자동화됨 도구가 WCAG에서 식별된 모든 성공 기준을 다루지는 않지만 중요합니다.
기술이 발전함에 따라 자동화 도구만으로도 더 많은 테스트를 처리할 수 있게 되지만, 오늘날에는 적용 가능한 WCAG 체크포인트를 모두 다루기 위해 수동 및 보조 기술 검사를 테스트 프로토콜에 추가해야 합니다.
수동 접근성 테스트의 장점:
- 상당히 간단하고 실행 속도도 빠름
- 자동 테스트만 사용할 때보다 더 많은 문제를 포착합니다.
- 성공에 필요한 도구와 전문 지식이 거의 없음
수동 접근성 테스트의 단점:
- 자동 테스트보다 더 복잡하고 시간이 많이 소요됨
- 대규모로 반복하기 어려울 수 있음
- 테스트를 실행하고 결과를 해석하려면 더 많은 접근성 전문 지식 필요
현재 감지할 수 있는 접근성 요소와 세부정보를 비교해 보겠습니다. 감지되지 않는 공격과 감지되지 않는 취약점을 구별할 수 있습니다
수동 테스트 유형
보고서를 검토할 때 고려할 수 있는 수동 도구와 기법은 디지털 접근성을 위한 웹페이지 또는 앱을 만드는 것이 좋습니다 Google 뉴스 이니셔티브의 가장 큰 세 가지 중점 분야는 수동 테스트는 키보드 기능, 시각적 중심 검토 일반적인 콘텐츠 검사
이 모듈에서는 이러한 각 주제를 개략적으로 다루지만 다음 테스트는 모든 수동 테스트의 전체 목록이 아닙니다. 실행할 수 있거나 실행해야 합니다 먼저 수동 접근성 체크리스트 공신력 있는 소스에서 선별하여 자체적인 수동 테스트 체크리스트를 개발합니다. 팀 요구사항에 맞게 맞춤설정할 수 있습니다
키보드 확인
모든 디지털 접근성 문제의 약 25% 는 문제가 발생할 수 있습니다. 키보드 포커스 모듈에서 배운 것처럼 키보드만 사용하는 사용자, 저시력/시각장애인 스크린 리더 사용자, 키보드로 액세스할 수 있는 콘텐츠에 의존하는 기술을 사용하는 음성 인식 소프트웨어를 사용하는 사용자 등 모든 유형의 사용자에게 영향을 미칩니다.
키보드 테스트를 통해 다음과 같은 질문에 답할 수 있습니다.
- 웹페이지 또는 기능이 작동하려면 마우스가 필요한가요?
- 탭 순서가 논리적이고 직관적인가요?
- 키보드 포커스 표시기가 항상 표시되나요?
- 초점을 잡으면 안 되는 요소에 갇혀 있지 않나요?
- 포커스를 가두어야 하는 요소 뒤 또는 주변을 탐색할 수 있나요?
- 포커스를 받은 요소를 닫을 때 포커스 표시기가 논리적 위치로 돌아왔나요?
키보드 기능의 영향은 크지만 테스트 절차는 매우 간단합니다. 마우스를 가져가거나 소형 자바스크립트 패키지를 설치한 후 키보드만 사용하여 웹사이트를 테스트하면 됩니다. 다음 명령어는 키보드 테스트에 필수적입니다.
시각적 검사
시각적 검사는 페이지의 시각적 요소에 중점을 두고 화면 확대 또는 브라우저 확대/축소와 같은 도구를 활용하여 웹사이트나 앱의 접근성을 검토합니다.
시각적 검사를 통해 다음을 확인할 수 있습니다.
- 그라데이션 또는 이미지 위에 있는 텍스트와 같이 자동화 도구로 포착할 수 없는 색상 대비 문제가 있나요?
- 제목, 목록 및 기타 구조적 요소와 비슷해 보이지만 제대로 코딩되지 않은 요소가 있나요?
- 탐색 링크와 양식 입력이 웹사이트 또는 앱 전체에서 일관적인가요?
- 권장사항 범위를 초과하는 플래시, 섬광 또는 애니메이션이 있나요?
- 콘텐츠에 적절한 띄어쓰기가 있나요? 글자, 단어, 줄, 단락의 검색 유형
- 화면 돋보기나 브라우저 확대/축소를 사용하여 모든 콘텐츠를 볼 수 있나요?
콘텐츠 확인
레이아웃, 움직임, 색상에 중점을 둔 시각적 테스트와 달리 콘텐츠 확인은 페이지에 있는 단어에 초점을 맞춥니다. 문구 자체를 살펴봐야 할 뿐만 아니라 맥락을 검토하여 다른 사람에게도 의미가 있는지 확인해야 합니다.
콘텐츠 체크를 통해 다음과 같은 질문에 답할 수 있습니다.
- 페이지 제목, 제목, 양식 라벨이 명확하고 설명적인가?
- 대안 이미지가 간결하고 정확하며 유용한가요?
- 색상만이 의미나 정보를 전달하는 유일한 방법으로 사용되나요?
- 링크가 설명을 제공합니까? 아니면 '자세히 알아보기' 또는 '여기를 클릭'과 같은 일반적인 텍스트를 사용하나요?
- 페이지 내 언어에 변경사항이 있나요?
- 평이한 언어가 사용되고 있으며 처음 언급될 때 모든 약어의 철자가 표기되나요?
일부 콘텐츠 확인은 부분적으로 자동화할 수 있습니다. 예를 들어, '여기를 클릭'을 확인하는 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: 링크 색상 대비
데모 페이지에서 위아래로 Tab 키를 눌러 키보드 테스트를 수행하면서 키보드가 화면에 숨겨진 세 개의 링크에 초점을 맞추는 것을 알아차렸을 것입니다. 다양한 질병에 대한 단락을 살펴보겠습니다.
페이지에 액세스할 수 있으려면 링크가 주변 텍스트와 눈에 띄어야 합니다. 마우스 오버 및 키보드 포커스 시 색상 외 스타일 변경을 포함합니다.
<ph type="x-smartling-placeholder">간단한 해결책은 단락 내부의 링크에 밑줄을 추가하여 눈에 띄게 만드는 것입니다. 이렇게 하면 접근성 문제를 해결할 수 있지만 달성하고자 하는 전반적인 디자인 미학에는 적합하지 않을 수 있습니다.
밑줄을 추가하지 않으려면 배경과 사본 모두에 대한 요구사항을 충족하도록 색상을 수정해야 합니다.
링크 대비 검사기 도구를 사용하여 데모를 보면 링크 색상이 일반 크기의 텍스트와 배경 간의 4.5:1 색상 대비 요구사항을 충족하는 것을 확인할 수 있습니다. 하지만 밑줄이 없는 링크는 주변 텍스트와 3:1 색상 대비 요구사항을 충족해야 합니다.
한 가지 방법은 링크 색상을 페이지의 다른 요소와 일치하도록 변경하는 것입니다. 그러나 링크 색상을 녹색으로 변경하는 경우 링크, 배경, 주변 텍스트 세 가지 요소 간의 전반적인 색상 대비 요구사항을 충족하도록 본문 문구도 수정해야 합니다.
문제 4: 아이콘 색상 대비
또 다른 놓친 색상 대비 문제는 소셜 미디어 아이콘입니다. 색상 및 대비 모듈에서는 필수 아이콘이 배경과 3:1 색상 대비를 충족해야 한다고 배웠습니다. 그러나 데모에서 소셜 미디어 아이콘의 명암비는 1.3:1입니다.
<ph type="x-smartling-placeholder">3:1 색상 대비 요구사항을 충족하기 위해 소셜 미디어 아이콘이 더 진한 회색으로 변경됩니다.
<ph type="x-smartling-placeholder">문제 5: 콘텐츠 레이아웃
단락 콘텐츠의 레이아웃을 보면 텍스트가 완전히 양쪽 맞춤됨 이 과정에서 서체 모듈 이것은 "우주의 강"을 만들어 냅니다. 이렇게 하면 일부 사람들이 텍스트를 이해하기 어려울 수 있으며 읽을 수 있습니다.
p.bullet {
text-align: justify;
}
데모에서 텍스트 정렬을 재설정하려면 코드를 다음과 같이 업데이트하면 됩니다.
text-align: left;
하거나 CSS에서 해당 줄을 완전히 삭제하세요.
기본 정렬을 설정할 수 있습니다. 다른 문제가 있을 경우 코드를 테스트해야 합니다.
상속된 스타일은 기본 텍스트 정렬을 삭제합니다.
p.bullet {
text-align: left;
}
4단계
<ph type="x-smartling-placeholder">이전 단계에서 설명한 모든 수동 접근성 문제를 확인하고 해결하면 페이지가 스크린샷과 비슷하게 표시됩니다.
수동 검사에서 이 모듈에서 다룬 것보다 더 많은 접근성 문제를 발견할 수 있습니다. 이러한 문제의 대부분은 다음 모듈에서 살펴보겠습니다.
다음 단계
훌륭합니다. 자동 및 수동 테스트 모듈을 완료했습니다. 업데이트된 CodePen과 를 참조하세요.
이제 '주목하는 방법'에 초점을 맞춘 마지막 테스트 모듈로 지원 기술 테스트입니다.
이해도 확인
수동 접근성 테스트에 관한 지식 테스트
WCAG 색상 대비 표준을 충족해야 하는 요소는 무엇인가요?