웹사이트 또는 애플리케이션에 액세스할 수 있는지 확인하는 작업은 부담스러울 수 있습니다. 접근성 관련 작업을 처음 시작하는 경우 주제의 범위가 너무 광범위하여 어디서부터 시작해야 할지 막막할 수 있습니다. 다양한 능력을 수용하기 위해 노력한다는 것은 그에 상응하는 다양한 문제를 고려해야 한다는 의미입니다.
이 게시물에서는 이러한 문제를 기존 사이트의 접근성 검토를 위한 논리적 단계별 절차로 분류합니다.
키보드로 시작하기
마우스를 사용할 수 없거나 사용하지 않는 사용자의 경우 키보드 탐색이 화면의 모든 항목에 도달하는 기본 수단입니다. 이 사용자 집단에는 반복적 스트레스 부상 (RSI)이나 마비와 같은 운동 장애가 있는 사용자와 스크린 리더 사용자가 포함됩니다.
우수한 키보드 환경을 제공하려면 논리적인 탭 순서와 명확하게 구분할 수 있는 포커스 스타일을 사용하는 것이 좋습니다.
먼저 사이트를 탭하여 이동합니다. 요소에 포커스가 설정되는 순서는 DOM 순서를 따라야 합니다. 포커스를 받을 요소를 잘 모르겠다면 접근성 학습 과정의 포커스 관련 모듈을 참고하세요. 사용자가 상호작용하거나 입력을 제공할 수 있는 모든 컨트롤은 포커스를 받을 수 있어야 하며 포커스 표시기 (예: 포커스 링)를 표시해야 합니다.
맞춤 대화형 컨트롤은 포커스를 받을 수 있어야 합니다. JavaScript를 사용하여
<div>를 멋진 드롭다운으로 변환하면 탭 순서에 자동으로 삽입되지 않습니다. 맞춤 컨트롤에 포커스를 설정하려면tabindex="0"를 지정합니다. 0보다 큰tabindex값은 탭 순서를 변경하며 화면 리더 사용자에게 혼란을 줄 수 있습니다.대화형 콘텐츠만 포커스를 받을 수 있도록 합니다. 제목과 같이 상호작용이 불가능한 요소에
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을 사용하는 경우 Mac OS와 함께 제공되는 스크린 리더인 VoiceOver에 관한 동영상을 확인하세요. PC를 사용하는 경우 기부를 통해 운영되는 Windows용 오픈소스 스크린 리더인 NVDA에 관한 동영상을 확인하세요.
aria-hidden가 키보드 포커스를 방지하지 않음
ARIA는 요소의 시맨틱스에만 영향을 미칠 수 있으며 요소의 동작에는 영향을 미치지 않습니다. aria-hidden="true"를 사용하여 요소를 화면 리더에 숨길 수 있지만 이로 인해 해당 요소의 포커스 동작은 변경되지 않습니다. 화면 밖에 있는 대화형 콘텐츠의 경우 inert 속성을 사용하여 키보드 흐름에서 실제로 삭제되었는지 확인합니다. 이전 브라우저의 경우 aria-hidden="true"를 tabindex="-1"와 결합합니다.
대화형 요소는 목적과 상태를 나타내야 함
컨트롤이 어떤 기능을 하는지에 관한 시각적 힌트 또는 어포던스를 제공하면 다양한 기기에서 다양한 사용자가 사이트를 운영하고 탐색하는 데 도움이 됩니다.
- 링크 및 버튼과 같은 상호작용 요소는 상호작용이 불가능한 요소와 구별되어야 합니다. 사용자가 요소를 클릭할 수 있는지 여부를 알 수 없으면 사이트나 앱을 탐색하기가 어렵습니다. 양방향 요소를 나타내는 유효한 방법은 많습니다. 일반적인 방법 중 하나는 링크에 밑줄을 긋고 주변 텍스트와 구분하는 것입니다.
- 포커스 요구사항과 마찬가지로 링크 및 버튼과 같은 상호작용 요소에는 마우스 사용자가 클릭 가능한 항목 위에 있을 때 이를 알리는
hover상태가 필요합니다. 그러나 이러한 요소에 다른 입력 방법이 액세스할 수 있도록 하려면hover상태 없이 구분할 수 있어야 합니다.
제목 및 랜드마크 활용하기
제목과 랜드마크 요소는 페이지에 시맨틱 구조를 부여하고 보조 기술 사용자의 탐색 효율성을 크게 높입니다. 익숙하지 않은 페이지에 처음으로 도달할 때 일반적으로 제목을 사용하여 탐색하려고 한다고 말하는 화면 리더 사용자의 신고가 많습니다.
마찬가지로 스크린 리더는 <main> 및 <nav>와 같은 중요한 랜드마크로 이동하는 기능도 제공합니다. 이러한 이유로 페이지 구조를 사용하여 사용자 환경을 안내하는 방법을 고려하는 것이 중요합니다.
h1-h6계층 구조를 사용합니다. 제목은 페이지의 개요를 만드는 도구라고 생각하면 됩니다. 제목의 내장 스타일을 사용하지 마세요. 대신 모든 콘텐츠가 동일한 크기인 것처럼 처리하고 기본, 보조, 3차 콘텐츠에 의미론적으로 적절한 수준을 사용하세요. 그런 다음 CSS를 사용하여 제목이 디자인과 일치하도록 합니다.- 사용자가 반복되는 콘텐츠를 건너뛸 수 있도록 랜드마크 요소와 역할을 사용하세요. 많은 보조 기술은
<main>또는<nav>요소로 정의된 것과 같이 페이지의 특정 부분으로 이동하는 바로가기를 제공합니다. 이러한 요소에는 암시적 랜드마크 역할이 있습니다. ARIArole속성을 사용하여<div role="search">와 같이 페이지의 영역을 명시적으로 정의할 수도 있습니다. 자세한 예는 시맨틱 및 콘텐츠 탐색을 참고하세요. role="application"를 사용해 본 경험이 없다면 사용하지 마세요.application랜드마크 역할은 보조 기술에 단축키를 사용 중지하고 모든 키 누르기를 페이지에 전달하도록 지시합니다. 즉, 스크린 리더 사용자가 일반적으로 페이지를 이동하는 데 사용하는 키가 더 이상 작동하지 않으며 모든 키보드 처리를 직접 구현해야 합니다.
스크린 리더로 제목 및 랜드마크 검토
VoiceOver 및 NVDA와 같은 스크린 리더는 페이지의 중요한 영역으로 건너뛰는 컨텍스트 메뉴를 제공합니다. 접근성을 테스트할 때 이러한 메뉴를 사용하여 페이지 개요를 확인하고 제목 수준이 적절한지, 어떤 랜드마크가 사용 중인지 확인할 수 있습니다.
자세한 내용은 VoiceOver 및 NVDA의 기본사항에 관한 안내 동영상을 참고하세요.
프로세스 자동화
사이트의 접근성을 수동으로 테스트하는 것은 번거롭고 오류가 발생하기 쉽습니다. 최대한 테스트를 자동화하는 것이 좋습니다. 브라우저 확장 프로그램과 명령줄 접근성 테스트 모음을 사용할 수 있습니다.
- 페이지가 aXe 또는 WAVE 브라우저 확장 프로그램의 모든 테스트를 통과하나요? 사용할 수 있는 다른 옵션도 있지만 이러한 확장 프로그램은 대비율 실패, ARIA 속성 누락과 같은 미묘한 문제를 포착할 수 있으므로 수동 테스트 프로세스에 유용하게 추가할 수 있습니다.
- 명령줄에서 작업하려면 axe-cli를 사용하세요. aXe 브라우저 확장 프로그램과 동일한 기능을 제공하지만 터미널에서 실행할 수 있습니다.
- 특히 연속 통합 환경에서 회귀를 방지하려면 axe-core와 같은 라이브러리를 자동화된 테스트 모음에 통합하세요. axe-core는 aXe Chrome 확장 프로그램을 지원하는 것과 동일한 엔진이지만 명령줄 유틸리티로 제공됩니다.
- 프레임워크나 라이브러리를 사용하는 경우 자체 접근성 도구를 제공하나요? 예를 들어 Angular의 protractor-accessibility-plugin 가능하면 사용 가능한 도구를 활용하세요.
Lighthouse를 사용하여 PWA 테스트
Lighthouse는 프로그레시브 웹 앱 (PWA)의 성능을 측정하는 도구입니다. 또한 axe-core 라이브러리를 사용하여 접근성 테스트를 실행합니다.
이미 Lighthouse를 사용하고 있다면 보고서에서 실패한 접근성 테스트를 찾습니다. 오류를 수정하여 사이트의 전반적인 사용자 환경을 개선하세요.