수동 접근성 테스트

수동 테스트 기본사항

수동 접근성 테스트는 키보드, 시각적, 인지 테스트, 도구, 자동화 도구에서 찾을 수 없는 문제를 찾을 수 있습니다. 자동화됨 도구가 WCAG에서 식별된 모든 성공 기준을 다루지는 않지만 중요합니다.

기술이 발전함에 따라 자동화 도구만으로도 더 많은 테스트를 처리할 수 있게 되지만, 오늘날에는 적용 가능한 WCAG 체크포인트를 모두 다루기 위해 수동 및 보조 기술 검사를 테스트 프로토콜에 추가해야 합니다.

수동 접근성 테스트의 장점:

• 상당히 간단하고 실행 속도도 빠름
• 자동 테스트만 사용할 때보다 더 많은 문제를 포착합니다.
• 성공에 필요한 도구와 전문 지식이 거의 없음

수동 접근성 테스트의 단점:

• 자동 테스트보다 더 복잡하고 시간이 많이 소요됨
• 대규모로 반복하기 어려울 수 있음
• 테스트를 실행하고 결과를 해석하려면 더 많은 접근성 전문 지식 필요

현재 감지할 수 있는 접근성 요소와 세부정보를 비교해 보겠습니다. 감지되지 않는 공격과 감지되지 않는 취약점을 구별할 수 있습니다

수동 테스트 유형

보고서를 검토할 때 고려할 수 있는 수동 도구와 기법은 디지털 접근성을 위한 웹페이지 또는 앱을 만드는 것이 좋습니다 Google 뉴스 이니셔티브의 가장 큰 세 가지 중점 분야는 수동 테스트는 키보드 기능, 시각적 중심 검토 일반적인 콘텐츠 검사

이 모듈에서는 이러한 각 주제를 개략적으로 다루지만 다음 테스트는 모든 수동 테스트의 전체 목록이 아닙니다. 실행할 수 있거나 실행해야 합니다 먼저 수동 접근성 체크리스트 공신력 있는 소스에서 선별하여 자체적인 수동 테스트 체크리스트를 개발합니다. 팀 요구사항에 맞게 맞춤설정할 수 있습니다

키보드 확인

모든 디지털 접근성 문제의 약 25% 는 문제가 발생할 수 있습니다. 키보드 포커스 모듈에서 배운 것처럼 키보드만 사용하는 사용자, 저시력/시각장애인 스크린 리더 사용자, 키보드로 액세스할 수 있는 콘텐츠에 의존하는 기술을 사용하는 음성 인식 소프트웨어를 사용하는 사용자 등 모든 유형의 사용자에게 영향을 미칩니다.

키보드 테스트를 통해 다음과 같은 질문에 답할 수 있습니다.

• 웹페이지 또는 기능이 작동하려면 마우스가 필요한가요?
• 탭 순서가 논리적이고 직관적인가요?
• 키보드 포커스 표시기가 항상 표시되나요?
• 초점을 잡으면 안 되는 요소에 갇혀 있지 않나요?
• 포커스를 가두어야 하는 요소 뒤 또는 주변을 탐색할 수 있나요?
• 포커스를 받은 요소를 닫을 때 포커스 표시기가 논리적 위치로 돌아왔나요?

키보드 기능의 영향은 크지만 테스트 절차는 매우 간단합니다. 마우스를 가져가거나 소형 자바스크립트 패키지를 설치한 후 키보드만 사용하여 웹사이트를 테스트하면 됩니다. 다음 명령어는 키보드 테스트에 필수적입니다.

시각적 검사

시각적 검사는 페이지의 시각적 요소에 중점을 두고 화면 확대 또는 브라우저 확대/축소와 같은 도구를 활용하여 웹사이트나 앱의 접근성을 검토합니다.

시각적 검사를 통해 다음을 확인할 수 있습니다.

• 그라데이션 또는 이미지 위에 있는 텍스트와 같이 자동화 도구로 포착할 수 없는 색상 대비 문제가 있나요?
• 제목, 목록 및 기타 구조적 요소와 비슷해 보이지만 제대로 코딩되지 않은 요소가 있나요?
• 탐색 링크와 양식 입력이 웹사이트 또는 앱 전체에서 일관적인가요?
• 권장사항 범위를 초과하는 플래시, 섬광 또는 애니메이션이 있나요?
• 콘텐츠에 적절한 띄어쓰기가 있나요? 글자, 단어, 줄, 단락의 검색 유형
• 화면 돋보기나 브라우저 확대/축소를 사용하여 모든 콘텐츠를 볼 수 있나요?

콘텐츠 확인

레이아웃, 움직임, 색상에 중점을 둔 시각적 테스트와 달리 콘텐츠 확인은 페이지에 있는 단어에 초점을 맞춥니다. 문구 자체를 살펴봐야 할 뿐만 아니라 맥락을 검토하여 다른 사람에게도 의미가 있는지 확인해야 합니다.

콘텐츠 체크를 통해 다음과 같은 질문에 답할 수 있습니다.

• 페이지 제목, 제목, 양식 라벨이 명확하고 설명적인가?
• 대안 이미지가 간결하고 정확하며 유용한가요?
• 색상만이 의미나 정보를 전달하는 유일한 방법으로 사용되나요?
• 링크가 설명을 제공합니까? 아니면 '자세히 알아보기' 또는 '여기를 클릭'과 같은 일반적인 텍스트를 사용하나요?
• 페이지 내 언어에 변경사항이 있나요?
• 평이한 언어가 사용되고 있으며 처음 언급될 때 모든 약어의 철자가 표기되나요?

일부 콘텐츠 확인은 부분적으로 자동화할 수 있습니다. 예를 들어, '여기를 클릭'을 확인하는 JavaScript 린터를 작성할 수 있습니다. 변경할 것을 제안합니다. 그러나 이러한 맞춤 솔루션에는 문구를 문맥에 맞게 변경하려면 여전히 사람이 필요한 경우가 많습니다.

데모: 수동 테스트

지금까지 데모 웹페이지에서 자동 테스트를 실행하고 8가지 문제 유형을 찾아 해결했습니다. 이제 더 많은 접근성 문제를 발견할 수 있는지 수동으로 검사를 실행할 준비가 되었습니다.

1단계

업데이트된 CodePen 데모는 적용된 자동 접근성 업데이트의 수입니다.

디버그 모드에서 확인하고 다음 테스트를 실행합니다. 이 메서드는 요소를 둘러싸는 <iframe>를 삭제하므로 중요합니다. 데모 웹페이지로 인해 일부 테스트 도구에 지장을 줄 수 있습니다. 다음에 대해 자세히 알아보기 CodePen의 디버그 모드

2단계

마우스나 트랙패드를 옆에 두고 수동 테스트 프로세스를 시작하고 키보드만 사용하여 DOM을 위아래로 탐색합니다.

문제 1: 포커스 표시기 표시

첫 번째 키보드 문제는 보이는 포커스 표시기가 제거되었기 때문에 즉시 표시되거나 아예 보이지 않습니다. 데모의 CSS를 살펴보면 코드베이스에 'outline: none'이 추가되어 있다는 것을 알 수 있습니다.

  :focus {
    outline: none;
  }

</ph> 문제를 해결해 보세요.

키보드 포커스 모듈에서 배운 것처럼 웹브라우저에서 사용자에게 표시되는 포커스를 추가할 수 있도록 이 코드 줄을 삭제해야 합니다. 여기서 한 걸음 더 나아가 디지털 제품의 미학에 맞는 스타일의 포커스 표시기를 만들 수 있습니다.

:focus {
  outline: 3px dotted #008576;
}

문제 2: 포커스 순서

포커스 표시기를 수정한 후 해당 표시기가 나타나면 영향을 미칩니다. 그러면 양식 입력란에 포커스되지 않습니다. 삭제되었습니다. 음의 tabindex로 삭제하겠습니다.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>

</ph> 문제를 해결해 보세요.

사용자가 이 입력란을 사용하여 뉴스레터에 가입하도록 하려면 음수 tabindex를 삭제하거나 0으로 설정하여 입력에 다시 포커스를 맞출 수 있도록 하기만 하면 됩니다.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>

3단계

키보드 포커스를 확인한 후 시각적 및 콘텐츠 확인으로 넘어갑니다.

문제 3: 링크 색상 대비

데모 페이지에서 위아래로 Tab 키를 눌러 키보드 테스트를 수행하면서 키보드가 화면에 숨겨진 세 개의 링크에 초점을 맞추는 것을 알아차렸을 것입니다. 다양한 질병에 대한 단락을 살펴보겠습니다.

페이지에 액세스할 수 있으려면 링크가 주변 텍스트와 눈에 띄어야 합니다. 마우스 오버 및 키보드 포커스 시 색상 외 스타일 변경을 포함합니다.

</ph> 문제를 해결해 보세요.

간단한 해결책은 단락 내부의 링크에 밑줄을 추가하여 눈에 띄게 만드는 것입니다. 이렇게 하면 접근성 문제를 해결할 수 있지만 달성하고자 하는 전반적인 디자인 미학에는 적합하지 않을 수 있습니다.

밑줄을 추가하지 않으려면 배경과 사본 모두에 대한 요구사항을 충족하도록 색상을 수정해야 합니다.

링크 대비 검사기 도구를 사용하여 데모를 보면 링크 색상이 일반 크기의 텍스트와 배경 간의 4.5:1 색상 대비 요구사항을 충족하는 것을 확인할 수 있습니다. 하지만 밑줄이 없는 링크는 주변 텍스트와 3:1 색상 대비 요구사항을 충족해야 합니다.

한 가지 방법은 링크 색상을 페이지의 다른 요소와 일치하도록 변경하는 것입니다. 그러나 링크 색상을 녹색으로 변경하는 경우 링크, 배경, 주변 텍스트 세 가지 요소 간의 전반적인 색상 대비 요구사항을 충족하도록 본문 문구도 수정해야 합니다.

<ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">를 통해 개인정보처리방침을 정의할 수 있습니다.

를 통해 개인정보처리방침을 정의할 수 있습니다. <ph type="x-smartling-placeholder">

</ph> <ph type="x-smartling-placeholder">

문제 4: 아이콘 색상 대비

또 다른 놓친 색상 대비 문제는 소셜 미디어 아이콘입니다. 색상 및 대비 모듈에서는 필수 아이콘이 배경과 3:1 색상 대비를 충족해야 한다고 배웠습니다. 그러나 데모에서 소셜 미디어 아이콘의 명암비는 1.3:1입니다.

</ph> 문제를 해결해 보세요.

3:1 색상 대비 요구사항을 충족하기 위해 소셜 미디어 아이콘이 더 진한 회색으로 변경됩니다.

</ph>

문제 5: 콘텐츠 레이아웃

단락 콘텐츠의 레이아웃을 보면 텍스트가 완전히 양쪽 맞춤됨 이 과정에서 서체 모듈 이것은 "우주의 강"을 만들어 냅니다. 이렇게 하면 일부 사람들이 텍스트를 이해하기 어려울 수 있으며 읽을 수 있습니다.

p.bullet {
   text-align: justify;
}

</ph> 문제를 해결해 보세요.

데모에서 텍스트 정렬을 재설정하려면 코드를 다음과 같이 업데이트하면 됩니다. text-align: left;하거나 CSS에서 해당 줄을 완전히 삭제하세요. 기본 정렬을 설정할 수 있습니다. 다른 문제가 있을 경우 코드를 테스트해야 합니다. 상속된 스타일은 기본 텍스트 정렬을 삭제합니다.

p.bullet {
   text-align: left;
}

4단계

</ph> <ph type="x-smartling-placeholder">

이전 단계에서 설명한 모든 수동 접근성 문제를 확인하고 해결하면 페이지가 스크린샷과 비슷하게 표시됩니다.

수동 검사에서 이 모듈에서 다룬 것보다 더 많은 접근성 문제를 발견할 수 있습니다. 이러한 문제의 대부분은 다음 모듈에서 살펴보겠습니다.

다음 단계

훌륭합니다. 자동 및 수동 테스트 모듈을 완료했습니다. 업데이트된 CodePen과 를 참조하세요.

이제 '주목하는 방법'에 초점을 맞춘 마지막 테스트 모듈로 지원 기술 테스트입니다.

이해도 확인

수동 접근성 테스트에 관한 지식 테스트