사이트의 접근성 문제를 검토하는 방법
웹사이트 또는 애플리케이션의 액세스 가능 여부를 판단하는 것은 쉬운 일이 아닙니다. 접근성을 처음 접하는 경우에는 이 주제가 너무 광범위해 어디서부터 시작해야 할지 막막할 수 있습니다. 결국 다양한 능력을 수용하기 위해 노력하는 것은 그에 따라 고려해야 할 문제 범위도 다양하다는 것을 의미합니다.
이 게시물에서는 이러한 문제를 논리적인 단계별 프로세스로 나누어 기존 사이트의 접근성을 검토하겠습니다.
키보드로 시작
마우스를 사용할 수 없거나 사용하지 않기로 선택하는 사용자의 경우 키보드 탐색은 화면의 모든 항목에 도달하기 위한 주요 수단입니다. 이 대상에는 반복 스트레스 부상 (RSI) 또는 마비와 같은 운동 장애가 있는 사용자와 스크린 리더 사용자가 포함됩니다. 좋은 키보드 환경을 위해서는 논리적인 탭 순서와 쉽게 눈에 띄는 포커스 스타일을 유지하는 것을 목표로 합니다.
핵심 사항
탭을 탐색하여 사이트를 탐색하세요. 요소에 포커스가 있는 순서는 DOM 순서를 따르는 것이 좋습니다. 어떤 요소에 포커스를 받아야 할지 잘 모르겠다면 포커스 기본사항을 참고하여 복습하세요. 일반적으로 사용자가 상호작용하거나 입력을 제공할 수 있는 모든 컨트롤은 포커스 가능하게 만들고 포커스 표시기 (예: 포커스 링)를 표시하는 것을 목표로 합니다. CSS에서
outline: none
를 사용하여 대안을 제공하지 않고 포커스 스타일을 사용 중지하는 것이 일반적이지만 이는 피해야 할 패턴입니다. 키보드 사용자가 포커스가 있는 항목을 볼 수 없는 경우 페이지와 상호작용할 방법이 없습니다. 스타일 지정을 위해 마우스와 키보드 포커스를 구분해야 한다면 what-input과 같은 라이브러리를 추가해 보세요.맞춤 양방향 컨트롤은 초점을 맞출 수 있어야 합니다. JavaScript를 사용하여
<div>
을 멋진 드롭다운으로 전환하면 탭 순서에 자동으로 삽입되지 않습니다. 맞춤 컨트롤을 포커스 가능하게 만들려면tabindex="0"
를 지정합니다.tabindex
> 0인 컨트롤을 사용하지 않습니다. 이러한 컨트롤은 DOM에서의 위치에 관계없이 탭 순서의 다른 모든 항목보다 먼저 건너뜁니다. 이는 선형 방식으로 DOM을 탐색하는 경향이 있기 때문에 스크린 리더 사용자에게 혼란을 줄 수 있습니다.비대화형 콘텐츠 (예: 제목)는 포커스 가능하지 않아야 합니다. 개발자가 중요하다고 생각하여 제목에
tabindex
를 추가하는 경우도 있습니다. 이는 화면을 볼 수 있는 키보드 사용자의 효율성이 떨어질 수 있으므로 피해야 할 패턴이기도 합니다. 스크린 리더 사용자의 경우 스크린 리더가 이미 제목을 알려주므로 포커스 가능하게 만들 필요가 없습니다.페이지에 새로운 콘텐츠가 추가되면 사용자가 조치를 취할 수 있도록 사용자의 포커스가 해당 콘텐츠로 연결되도록 하세요. 예를 보려면 페이지 수준에서 포커스 관리를 참고하세요.
어느 시점에서든 포커스를 완전히 가두지 않도록 주의하세요. 키보드 포커스가 멈출 수 있는 자동 완성 위젯에 주의하세요. 사용자가 페이지의 나머지 부분과 상호작용하고 싶지 않은 경우 모달 표시와 같은 특정 상황에서 포커스가 일시적으로 트래킹될 수 있지만 키보드로 액세스할 수 있는 모달을 이스케이프하는 방법도 제공해야 합니다. 예는 모달 및 키보드 트랩 가이드를 참고하세요.
포커스 가능하다는 것이 사용 가능하다는 의미는 아닙니다.
맞춤 컨트롤을 빌드한 경우 사용자가 키보드만 사용하여 컨트롤의 모든 기능에 액세스할 수 있도록 하세요. 키보드 액세스를 개선하는 기법은 구성요소의 포커스 관리를 참고하세요.
화면 밖 콘텐츠에 유의
반응형 창 메뉴 내의 링크 또는 아직 표시되지 않은 모달 창 내부의 버튼과 같이 DOM에는 있지만 표시되지 않는 화면 밖 콘텐츠가 있는 사이트가 많습니다. 이러한 요소를 DOM에 그대로 두면 특히 스크린 리더에서 화면 밖 콘텐츠를 페이지 일부인 것처럼 알려 키보드 사용 환경에 혼란이 발생할 수 있습니다. 이러한 요소를 처리하는 방법에 관한 팁은 화면 밖 콘텐츠 처리를 참고하세요.
스크린 리더로 사용해 보기
일반 키보드 지원을 개선하면 다음 단계를 위한 기초가 마련됩니다. 적절한 라벨 지정 및 의미 체계와 스크린 리더 탐색에 방해가 되는 요소가 있는지 페이지를 확인할 수 있습니다. 보조 기술이 시맨틱 마크업을 해석하는 방법을 잘 모르는 경우 시맨틱 소개를 참고하여 다시 살펴보세요.
핵심 사항
모든 이미지에서 올바른
alt
텍스트를 확인하세요. 이미지가 주로 표시용이고 필수 콘텐츠가 아닌 경우에는 이 관행의 예외입니다. 스크린 리더에서 이미지를 건너뛰어야 함을 나타내려면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"
를 사용하여 스크린 리더에 요소를 숨겨도 되지만 이 요소의 포커스 동작은 변경되지 않습니다. 오프스크린 상호작용 콘텐츠의 경우 키보드 흐름에서 완전히 삭제되도록 aria-hidden="true"
및 tabindex="-1"
를 결합해야 하는 경우가 많습니다. 제안된 inert 속성은 두 속성의 동작을 결합하여 이를 더 쉽게 하는 것을 목표로 합니다.
링크, 버튼과 같은 상호작용 요소는 용도와 상태를 나타내야 합니다.
컨트롤의 기능에 관한 시각적 힌트를 제공하면 사용자가 사이트를 운영하고 탐색하는 데 도움이 됩니다. 이러한 힌트를 어포던스라고 합니다. 어포던스를 제공하면 사용자가 다양한 기기에서 사이트를 사용할 수 있습니다.
핵심 사항
링크 및 버튼과 같은 양방향 요소는 비대화형 요소와 구분할 수 있어야 합니다. 요소의 클릭 가능 여부를 사용자가 알 수 없는 경우 사이트 또는 앱을 탐색하기가 어렵습니다. 이 목표를 달성하는 데 유효한 여러 가지 방법이 있습니다. 한 가지 일반적인 방법은 링크를 주변 텍스트와 구분하도록 링크에 밑줄을 긋는 것입니다.
포커스 요구사항과 마찬가지로 링크 및 버튼과 같은 상호작용 요소에는 마우스 사용자가 클릭 가능한 항목 위에 마우스를 가져가고 있는지 알 수 있도록 마우스 오버 상태가 필요합니다. 하지만 상호작용 요소는 여전히 그 자체로는 구별 가능해야 합니다. 클릭 가능한 요소를 표시하기 위해 마우스 오버 상태만 사용하는 것은 터치 스크린 기기에 도움이 되지 않습니다.
제목과 랜드마크 활용
제목과 랜드마크 요소는 페이지에 시맨틱 구조를 더해주고 보조 기술 사용자의 탐색 효율성을 크게 높입니다. 많은 스크린 리더 사용자가 낯선 페이지를 처음 방문하면 일반적으로 제목을 따라 탐색하려고 한다고 신고합니다.
마찬가지로 스크린 리더는 <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, Polymer 및 Web Components용 a11ysuite가 있습니다. 시간을 낭비하지 않도록 가능한 한 가용 도구를 활용하세요.
프로그레시브 웹 앱을 빌드하고 있다면 Lighthouse를 사용해 보세요.
Lighthouse는 프로그레시브 웹 앱의 성능을 측정하는 데 도움이 되는 도구이지만 axe-core 라이브러리를 사용하여 일련의 접근성 테스트를 지원하기도 합니다. 이미 Lighthouse를 사용 중인 경우 보고서에서 접근성 테스트가 실패했는지 확인합니다. 이러한 문제를 해결하면 사이트의 전반적인 사용자 환경을 개선하는 데 도움이 됩니다.
결론
접근성 검토를 팀 프로세스의 정기적인 일부로 설정하고 이러한 검사를 조기에 자주 수행하면 전반적인 사이트 사용 환경을 개선할 수 있습니다. 우수한 접근성은 훌륭한 UX라는 사실을 기억하세요.