웹사이트 또는 애플리케이션의 액세스 가능 여부를 판단하는 것은 어려운 작업처럼 보일 수 있습니다. 접근성에 처음 접근하는 경우 이 주제의 범위가 너무 넓어서 어디서부터 시작해야 할지 막막할 수 있습니다. 결국 다양한 능력을 수용하기 위해 노력한다는 것은 그에 따라 고려해야 할 문제 범위도 다양하다는 것을 의미합니다.
이 게시물에서는 이러한 문제를 기존 사이트의 접근성을 검토하기 위한 논리적인 단계별 프로세스로 분류합니다.
키보드로 시작
마우스를 사용할 수 없거나 사용하지 않기로 선택하는 사용자의 경우 키보드 탐색이 화면의 모든 항목에 도달하기 위한 기본 수단입니다. 이 대상에는 반복성 스트레스 손상 (RSI)이나 마비와 같은 운동 장애가 있는 사용자와 스크린 리더 사용자가 포함됩니다.
좋은 키보드 환경을 위해서는 논리적인 탭 순서와 명확하게 식별할 수 있는 포커스 스타일을 설정하는 것을 목표로 합니다.
탭을 탐색하여 사이트를 탐색하세요. 요소에 포커스가 맞춰지는 순서는 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을 사용하는 경우 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를 사용하고 있다면 보고서에서 실패한 접근성 테스트를 찾습니다. 오류를 수정하여 사이트의 전반적인 사용자 환경을 개선합니다.