접근성 검토 방법

Rob Dodson

웹사이트 또는 애플리케이션에 액세스할 수 있는지 여부를 판단하는 것은 매우 복잡합니다. 접근성을 처음 접하는 경우 어떻게 시작해야 할지 막막할 수 있습니다. 결국 다양한 역량을 수용하기 위해 노력한다는 것은 다양한 범위의 문제를 고려해야 합니다

이 게시물에서는 이러한 문제를 문제 해결 프로세스를 위한 논리적인 단계별 프로세스로 기존 사이트의 접근성 여부 검토

키보드로 시작하기

마우스를 사용할 수 없거나 사용하지 않기로 선택하는 사용자의 경우 키보드 탐색은 모든 것에 도달하는 주요 수단입니다. 이 잠재고객에는 다음이 포함됩니다. 반복적 스트레스 상해 (RSI) 또는 스크린 리더 사용자에게 도움이 될 것입니다

키보드 환경을 개선하려면 논리적인 탭 순서를 만들고 명확하게 뚜렷하게 구분되는 포커스 스타일입니다.

  • 먼저 사이트에서 Tab 키를 눌러 탐색하세요. 요소에 포커스가 맞춰지는 순서 DOM 순서를 따라야 합니다. 어떤 요소를 받아야 하는지 잘 모르는 경우 포커스에 관한 접근성 알아보기 과정의 모듈을 참고하세요. 최고 실제로 사용자가 상호작용하거나 입력받을 수 있는 모든 컨트롤은 포커스 가능해야 하며 포커스 표시기 (예: 포커스 링)를 표시해야 합니다.

  • 맞춤 상호작용 컨트롤은 포커스 가능해야 합니다. JavaScript를 사용하여 <div>를 멋진 드롭다운에 추가하면 자동으로 탭 순서를 지정합니다. 맞춤 컨트롤을 포커스 가능하게 만들려면 tabindex="0"를 지정하세요. tabindex 값이 0보다 크면 탭 순서가 변경되므로 도움이 될 수 있습니다

  • 대화형 콘텐츠만 포커스 가능하게 만듭니다. tabindex이(가) 아닌 키보드 사용자는 제목과 같은 상호작용형 요소를 사용해 스크린 리더 사용자에게 도움이 되지 않습니다 이미 알고 있습니다.

  • 페이지에 새 콘텐츠를 추가하는 경우 사용자가 해당 콘텐츠에 집중하도록 하세요. 조치를 취할 수 있습니다 자세한 내용은 페이지 수준에서 포커스 관리 를 참조하세요.

  • 사용자가 사이트를 방문할 때 항상 다음 요소에 집중할 수 있도록 선택할 수 있습니다 자동 완성 위젯 및 기타 컨텍스트에 트랩이 발생할 수 있으니 주의하세요 키보드 포커스 사용자가 포커스를 두도록 할 때 모달과 상호작용하고 페이지의 나머지 부분과 상호작용하지 않을 수 있지만, 키보드로 모달을 이스케이프할 수 있는 방법을 제공합니다. 자세한 내용은 모달 및 키보드 트랩 예로 들겠습니다.

초점 제어를 사용 가능하게 만들기

맞춤 컨트롤을 만든 경우 사용자가 컨트롤의 모든 기능에 접근할 수 있도록 하세요. 키보드만 사용해 볼 수 있습니다. 읽기 구성요소에서 포커스 관리 을 참조하세요.

화면 밖 콘텐츠 관리

많은 사이트에 DOM에는 있지만 표시되지 않는 화면 밖 콘텐츠가 있습니다. 반응형 창 메뉴 내부의 링크 또는 모달 창 내부의 버튼과 같은 확인할 수 있습니다 이러한 요소를 DOM에 그대로 두면 특히 스크린 리더의 경우 키보드의 편리함을 느낄 수 있습니다. 화면 밖 콘텐츠를 마치 페이지의 일부인 것처럼 알릴 수 있습니다.

화면 밖 콘텐츠 처리를 참고하세요. 을 참조하세요.

스크린 리더로 테스트

일반 키보드 지원을 개선하면 다음 단계를 위한 토대가 마련됩니다. 페이지에서 적절한 라벨 지정 및 의미 체계를 확인하고 스크린 리더 탐색을 지원합니다.

시맨틱 마크업이 보조 기능을 통해 해석되는 방식을 잘 모르는 경우 자세한 내용은 콘텐츠 구조를 참조하세요.

  • 모든 이미지에 올바른 alt 텍스트가 있는지 확인합니다. 이 관행의 예외로, 이미지는 주로 프레젠테이션용이며 있습니다. 스크린 리더가 이미지를 건너뛰도록 표시하려면 값을 빈 문자열(alt="")로 변경합니다.
  • 라벨의 모든 컨트롤을 확인합니다. 맞춤 컨트롤의 경우 aria-label 또는 aria-labelledby를 사용합니다. 자세한 내용은 ARIA 라벨과 관계 를 참조하세요.
  • 모든 맞춤 컨트롤에서 적절한 role 및 필수 ARIA 확인 상태를 전달하는 속성입니다. 예를 들어 맞춤 체크박스에는 role="checkbox" 및 aria-checked="true|false"를 호출하여 있습니다. 일반적인 내용은 ARIA 소개를 참고하세요. ARIA가 맞춤 컨트롤에 누락된 의미 체계를 제공하는 방법에 관한 개요
  • 페이지를 통한 정보의 흐름이 적절해야 합니다. 화면 독자가 DOM 순서로 페이지를 탐색할 때 말이 안 되는 순서로 CSS를 사용하여 시각적으로 재배치됩니다. 필요한 경우 DOM에서 물리적으로 더 일찍 이동해야 합니다.
  • 페이지의 모든 콘텐츠에 스크린 리더 탐색을 지원하는 것을 목표로 합니다. 사이트의 섹션이 영구적으로 숨겨지거나 화면에서 차단되지 않습니다. 액세스할 수 있습니다
    • 스크린 리더에서 콘텐츠를 숨겨야 하는 경우(예: 화면 밖에 있거나 프레젠테이션만 보려면 콘텐츠를 aria-hidden="true"로 설정하세요. 자세한 내용은 콘텐츠 숨기기.

스크린 리더에 익숙해지기

스크린 리더를 배우는 것이 어렵게 보일 수도 있지만, 스크린 리더는 제공합니다. 일반적으로 대부분의 개발자는 몇 가지 간단한 실행할 수 있습니다

Mac을 사용하는 경우 VoiceOver Mac OS와 함께 제공되는 스크린 리더입니다. PC를 사용 중이라면 NVDA 관련 동영상 기부를 장려하는 Windows용 오픈 소스 스크린 리더입니다.

aria-hidden에서 키보드 포커스를 차단하지 않음

ARIA는 애플리케이션의 의미에만 영향을 줄 수 있다는 점을 element; 요소의 동작에는 영향을 미치지 않습니다. 다음과 같은 작업을 할 수 있습니다. aria-hidden="true"를 사용하여 스크린 리더에 숨겨지지만 요소 해당 요소의 포커스 동작을 변경할 수 없습니다. 화면 밖 상호작용 콘텐츠의 경우 화면 밖 상호작용 콘텐츠의 경우 inert 속성을 사용합니다. 키보드 흐름에서 확실히 제거되는지 확인합니다. 이전 브라우저의 경우 aria-hidden="true"와 tabindex="-1"를 결합합니다.

상호작용 요소는 용도와 상태를 나타내야 함

컨트롤의 기능에 대한 시각적 힌트, 즉 어포던스를 제공하면 도움이 됩니다. 다양한 기기를 사용하는 다양한 사람들이 웹사이트를 운영하고 탐색합니다. 사이트

  • 링크나 버튼과 같은 상호작용 요소는 요소가 없습니다. 사용자가 사이트 또는 앱을 탐색할 수 없을 때 요소가 클릭 가능한지 알 수 없습니다. 여러 가지 유효한 방법이 는 상호작용 요소를 나타냅니다. 일반적인 관행 중 하나는 주변 텍스트와 구별할 수 있어야 합니다.
  • 포커스 요구사항과 마찬가지로 링크, 버튼과 같은 상호작용 요소가 있음 마우스 포인터가 무언가 위에 있을 때 사용자에게 알리려면 hover 상태가 필요합니다. 있습니다. 그러나 다른 입력 방법에서 이러한 요소에 액세스할 수 있도록 하려면 hover 상태 없이 구별 가능해야 합니다.

제목과 랜드마크를 활용하세요.

제목 및 랜드마크 요소는 페이지에 의미론적 구조를 제공합니다. 이를 통해 보조 기술 사용자의 탐색 효율성을 크게 높일 수 있습니다. 여러 항목 스크린 리더 사용자는 낯선 페이지를 처음 방문했을 때 그들은 일반적으로 제목별로 탐색

마찬가지로 스크린 리더는 중요한 랜드마크로 바로 이동할 수 있는 기능을 제공합니다. <main>, <nav> 등 따라서 이러한 상황에서 사용자 경험을 안내하는 데 사용할 수 있습니다.

  • h1-h6 계층 구조를 사용합니다. 제목은 제목의 개요를 작성하는 도구라고 있습니다. 기본 제공되는 제목 스타일에 의존하지 마세요. 대신 모두 같은 크기인 것처럼 보이게 하고 의미상 적절한 수준을 1차, 2차, 3차 콘텐츠에서 사용할 수 있습니다 그런 다음 CSS를 사용하여 제목이 디자인과 일치해야 합니다.
  • 사용자가 반복적인 콘텐츠를 우회할 수 있도록 랜드마크 요소와 역할을 사용합니다. 여러 항목 보조 기술은 페이지의 특정 부분으로 바로 이동할 수 있는 <main> 또는 <nav> 요소로 정의된 객체를 예로 들 수 있습니다. 이러한 요소는 암시적 랜드마크 역할을 지정합니다. 또한 ARIA role 속성을 사용하여 <div role="search">에서와 같이 페이지에서 리전을 명시적으로 정의합니다. 자세한 내용은 자세한 내용은 시맨틱 및 콘텐츠 탐색을 참고하세요. 예로 들 수 있습니다
  • 사용해 본 경험이 없다면 role="application"를 사용하지 않는 것이 좋습니다. application 랜드마크 역할은 보조 기술에 단축키를 사용하여 모든 키 누름을 페이지로 전달합니다. 즉, 사용자가 일반적으로 페이지에서 이동하는 데 사용하는 스크린 리더가 더 이상 작동하지 않습니다. 모든 키보드 처리를 직접 구현해야 합니다.

스크린 리더로 제목과 랜드마크를 검토하세요

VoiceOver 및 NVDA와 같은 스크린 리더는 다음 단계로 건너뛸 수 있는 컨텍스트 메뉴를 제공합니다. 중요한 부분을 차지합니다. 접근성을 테스트할 때는 이 메뉴를 사용하여 페이지 개요를 확인하고 제목이 어떤 랜드마크가 사용 중인지 알 수 있습니다.

자세히 알아보려면 VoiceOver 및 NVDA를 사용합니다.

프로세스 자동화

사이트의 접근성을 수동으로 테스트하는 것은 지루하고 오류가 발생하기 쉽습니다. 테스트를 자동화하면 개선할 수 있습니다 브라우저 확장 프로그램과 명령줄 접근성 기능을 사용할 수 있습니다. 테스트할 수 있습니다

  • 페이지가 aXe 또는 WAVE 브라우저 확장 프로그램 다른 옵션도 있지만, 이러한 확장 프로그램은 모든 수동 테스트 프로세스에 유용하게 추가할 수 있습니다. 명암비 실패 및 ARIA 누락과 같은 미묘한 문제 해결 속성
    • 명령줄에서 작업하는 것을 선호한다면 axe-cli는 동일한 기능을 제공합니다. aXe 브라우저 확장 프로그램으로 표시되지만 터미널에서 실행할 수 있습니다.
  • 특히 지속적 통합 환경에서 회귀를 방지하려면 axe-core 테스트할 수 있습니다 액셀러레이티드 코어는 aXe Chrome 확장 프로그램이지만 명령줄 유틸리티에서 실행됩니다.
  • 프레임워크 또는 라이브러리를 사용하는 경우 자체 접근성을 제공하나요? 어떻게 해야 할까요? 예를 들어 protractor-accessibility-plugin 사용할 수 있습니다. 가능하면 사용 가능한 도구를 활용하세요.

Lighthouse를 사용하여 PWA 테스트

Lighthouse는 프로그레시브 웹 앱 (PWA)의 성능을 측정합니다. 또한 axe-core 라이브러리를 사용하여 접근성 테스트를 구동합니다.

이미 Lighthouse를 사용 중인 경우 접근성 장애가 있는지 확인 테스트할 수 있습니다. 오류를 수정하여 전반적인 사용자 환경을 개선하세요. 확인할 수 있습니다.

추가 리소스