이 페이지는 Cloud Translation API를 통해 번역되었습니다.

웹 개발자를 위한 접근성

접근성을 개선하면 모든 사용자가 사이트를 더 유용하게 사용할 수 있습니다.

Addy Osmani

누구나 이용할 수 있고 포용적인 사이트를 구축하는 것이 중요합니다. 최적화할 수 있는 주요 장애 영역은 6가지 이상(시각, 청각, 이동성, 인지, 음성, 신경)이 있습니다. 웹 접근성이 처음이더라도 다양한 도구와 리소스가 도움이 될 수 있습니다

10억 명 이상이 일종의 장애를 가지고 살아가고 있습니다.

사이트에 액세스할 수 있으려면 사이트는 화면 크기와 스크린 리더와 같은 여러 종류의 입력을 사용하는 여러 기기에서 작동해야 합니다. 또한 장애를 가진 사용자를 포함하여 가장 광범위한 사용자 그룹이 사이트를 사용할 수 있어야 합니다.

사용자가 가질 수 있는 몇 가지 장애는 다음과 같습니다.

Vision	청력	이동 보조기기
저시력 시각장애 색맹 백내장 햇빛 반사	난청 청각장애 소음 귀 감염	척수 손상 민첩성 제한 손이 가득 참
인지	음성	신경
학습 장애 졸림 또는 주의 산만 편두통 자폐증 압류, 압수	주변 소음 인후통 언어 장애 말할 수 없음	우울증 아동 성적 학대 이미지 양극성 장애 불안

시각적 문제는 색상을 구별할 수 없는 것에서부터 전혀 눈이 보이지 않는 것에 이르기까지 다양합니다.

텍스트 콘텐츠가 최소 명암비 기준을 충족하는지 확인합니다.
색상만 사용하여 정보를 전달하지 말고 모든 텍스트의 resizable할 수 있는지 확인하세요.
모든 사용자 인터페이스 구성요소를 스크린 리더, 돋보기, 점자 디스플레이와 같은 보조 기술과 함께 사용할 수 있는지 확인합니다. 이를 위해서는 접근성 API가 프로그래매틱 방식으로 요소의 역할, 상태, 값, 제목을 확인할 수 있도록 UI 구성요소가 마크업되었는지 확인해야 합니다.

Chrome DevTools의 요소 검사 도움말 스크린샷

저는 개인적으로 시력이 안 좋고 사이트, DevTools, 터미널을 자주 확대합니다. 확대/축소 지원이 개발자의 할 일 목록에 가장 높은 것은 거의 없지만 저와 같은 사용자에게는 큰 차이를 만들 수 있습니다.

청각 문제는 페이지에서 나는 소리를 들을 때 문제가 발생할 수 있음을 의미합니다.

텍스트 이외의 모든 콘텐츠에 대체 텍스트를 제공하세요.
UI 구성요소가 사운드 없이도 계속 작동하는지 테스트합니다.

웹페이지를 읽는 ChromeVox 스크린 리더의 스크린샷

이동성 문제에는 마우스, 키보드 또는 터치스크린을 작동할 수 없는 것이 포함될 수 있습니다.

마우스를 사용하는 모든 작업에서 UI 구성요소의 콘텐츠에 키보드를 통해 기능적으로 액세스할 수 있도록 합니다.
스크린 리더, 음성 제어 소프트웨어, 물리적 스위치 제어 등 동일한 API를 사용하는 보조 기술에 대해 페이지가 올바르게 마크업되었는지 확인합니다.

인지 문제는 사용자가 텍스트를 읽는 데 도움이 되는 보조 기술이 필요할 수 있음을 의미하므로 텍스트 대체가 존재하는지 확인하는 것이 중요합니다.

애니메이션을 사용할 때 주의하세요. 반복되거나 플래시되는 동영상 및 애니메이션은 일부 사용자에게 문제를 일으킬 수 있으므로 사용하지 마세요.

prefers-reduced-motion CSS 미디어 쿼리를 사용하면 모션을 줄여주는 사용자를 위해 애니메이션 및 자동재생 동영상을 제한할 수 있습니다.
```
/*
If the user expresses a preference for reduced motion, don't use animations on buttons.
*/
@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}
```
타이밍 기반 상호작용은 피하세요.

많은 내용으로 보일 수 있지만 UI 구성요소의 접근성을 평가하고 개선하는 과정을 살펴보겠습니다.

GOV.UK 접근성팀에서는 추가적인 시각적 지원을 위해 일련의 접근성 권장사항 및 금지사항 디지털 포스터를 만들었으며 이를 사용하여 팀과 권장사항을 공유할 수 있습니다.

접근성 관련 권장사항과 주의사항을 보여주는 디지털 포스터 — 접근성 권장사항을 나열한 6개의 포스터 전체 텍스트를 읽어 보세요.

UI 구성요소 접근성 측정

페이지의 UI 구성요소를 감사할 때 다음과 같이 스스로에게 질문해 보세요.

UI 구성요소는 키보드로만 사용할 수 있나요?

구성요소가 포커스를 관리하고 포커스 트랩을 피하나요? 적절한 키보드 이벤트에 응답할 수 있나요?
스크린 리더로 UI 구성요소를 사용할 수 있나요?

시각적으로 표시되는 정보에 대해 대체 텍스트를 제공했나요? ARIA를 사용하여 의미 정보를 추가했나요?
UI 구성요소가 소리 없이 작동할 수 있나요?

스피커를 끄고 사용 사례를 살펴봅니다.
색상 없이 UI 구성요소를 작동할 수 있나요?

색상을 볼 수 없는 사용자도 UI 구성요소를 사용할 수 있도록 합니다. 색맹을 시뮬레이션하는 데 유용한 도구로 색맹론이라는 Chrome 확장 프로그램이 있습니다. (4가지 형태의 색맹 시뮬레이션을 모두 시도해 보세요.) 마찬가지로 유용한 Daltonize 확장 프로그램도 살펴보실 수 있습니다.
고대비 모드가 사용 설정된 상태에서 UI 구성요소가 작동할 수 있나요?

모든 최신 운영체제는 고대비 모드를 지원합니다. 고대비가 도움이 될 수 있는 Chrome 확장 프로그램입니다.

표준화된 컨트롤 (예: <button> 및 <select>)에는 브라우저에 접근성이 내장되어 있습니다. Tab 키를 사용하여 포커스 가능하고, 키보드 이벤트 (예: Enter, Space, 화살표 키)에 응답하며 접근성 도구에서 사용하는 시맨틱 역할, 상태, 속성을 가지고 있습니다. 기본 스타일 지정도 나열된 접근성 요구사항을 충족해야 합니다.

맞춤 UI 구성요소 (<button>와 같은 표준 요소를 확장하는 구성요소는 제외)에는 접근성을 비롯한 기본 제공 기능이 없으므로 이를 제공해야 합니다. 접근성을 구현할 때는 구성요소를 유사한 표준 요소 (또는 구성요소의 복잡성에 따라 여러 표준 요소 조합)와 비교하는 것이 좋습니다.

대부분의 브라우저 개발자 도구는 페이지의 접근성 트리 검사를 지원합니다. Chrome DevTools의 경우 요소 패널의 접근성 탭에서 이 기능을 사용할 수 있습니다.

Chrome DevTools의 접근성 트리 뷰 스크린샷

Firefox에는 접근성 패널도 있습니다.

FireFox DevTools의 접근성 트리 보기 스크린샷

Safari는 요소 패널의 노드 탭에 접근성 정보를 표시합니다.

다음은 UI 구성요소의 접근성을 높이려고 할 때 스스로에게 물어볼 수 있는 질문 목록입니다.

키보드 포커스 개선

키보드를 사용하여 UI 구성요소의 모든 기능에 액세스할 수 있는 것이 좋습니다. 사용자 환경을 디자인할 때 키보드만으로 요소를 어떻게 사용할 것인지 생각해 보고 일관된 키보드 상호작용을 파악해 보세요.

먼저, 각 구성요소에 적절한 포커스 타겟이 있는지 확인합니다. 예를 들어 메뉴와 같은 복잡한 구성요소는 페이지 내의 하나의 포커스 타겟일 수 있지만, 활성 메뉴 항목이 항상 포커스를 받도록 하려면 그 자체 내에서 포커스를 관리해야 합니다.

포커스 관리가 필요한 메뉴 및 하위 메뉴의 스크린샷 — 복잡한 요소 내에서 포커스 관리

tabindex 사용

tabindex 속성을 사용하여 요소와 UI 구성요소의 키보드 포커스를 추가할 수 있습니다. 키보드 전용 및 보조 기술 사용자는 상호작용하기 위한 요소에 키보드 포커스를 배치할 수 있어야 합니다.

내장된 상호작용 요소 (예: <button>)는 암시적으로 포커스 가능하므로 탭 순서에서 위치를 변경해야 하는 경우가 아니라면 tabindex 속성이 필요하지 않습니다.

tabindex 값에는 세 가지 유형이 있습니다.

tabindex="0"이 가장 일반적이며 DOM 순서로 정의된 일반적인 탭 순서에 요소를 배치합니다.
tabindex 값이 0보다 크면 요소가 수동 탭 순서에 배치됩니다. 양수 tabindex 값을 가진 페이지의 모든 요소는 일반적인 탭 순서의 요소보다 먼저 숫자 순서로 방문됩니다.
tabindex 값이 -1과 같으면 요소에 프로그래매틱 방식으로 포커스 가능하지만 탭 순서에서는 포커스 가능하지 않습니다.

맞춤 UI 구성요소의 경우 항상 0 또는 -1의 tabindex 값을 사용하세요. 특정 페이지에서 요소의 순서를 미리 결정할 수 없기 때문입니다. tabindex 값이 -1인 경우 복잡한 구성요소 내에서 포커스를 관리하는 데 특히 유용합니다.

기본 포커스 링 스타일을 사용하거나 식별 가능한 맞춤 포커스 스타일을 적용하여 포커스가 항상 표시되도록 합니다. 키보드 사용자를 트랩하면 안 됩니다. 키보드만 사용하여 요소에서 포커스를 이동할 수 있어야 합니다.

자동 초점 사용

HTML 자동 초점 속성을 사용하면 작성자가 페이지가 로드될 때 특정 요소가 자동으로 포커스를 받도록 지정할 수 있습니다. autofocus는 버튼을 포함하여 모든 웹 양식 컨트롤에서 이미 지원됩니다. 자체 맞춤 UI 구성요소의 요소에 자동으로 포커스를 맞추려면 포커스를 맞출 수 있는 모든 HTML 요소(예: document.querySelector('myButton').focus())에서 지원되는 focus() 메서드를 호출합니다.

키보드 상호작용 추가

UI 구성요소에 포커스를 둘 수 있게 되면 적절한 키보드 이벤트를 처리하여 구성요소에 포커스가 맞춰질 때 좋은 키보드 상호작용 스토리를 제공합니다. 예를 들어 사용자가 화살표 키를 사용하여 메뉴 옵션을 선택하고 Space 또는 Enter를 사용하여 버튼을 활성화할 수 있도록 허용합니다. ARIA 디자인 패턴 가이드에서 몇 가지 안내를 확인할 수 있습니다.

마지막으로, 단축키를 검색할 수 있는지 확인합니다. 일반적인 방법은 단축키 범례 (화면상의 텍스트)를 표시하여 사용자에게 단축키가 존재함을 알리는 것입니다. 예를 들어 "Press ? 사용할 수 있습니다. 또는 이러한 도움말 힌트를 사용하여 사용자에게 바로가기에 관해 알릴 수도 있습니다.

포커스 관리의 중요성은 아무리 강조해도 지나치지 않습니다. 탐색 창을 예로 들 수 있습니다. 페이지에 UI 구성요소를 추가하는 경우 그 내부의 요소에 포커스를 전달해야 합니다. 그러지 않으면 사용자가 전체 페이지를 탭하며 이동해야 할 수도 있습니다. 이로 인해 불편할 수 있으므로 페이지에서 키보드로 탐색할 수 있는 모든 구성요소의 포커스를 테스트해야 합니다.

// Example for expanding and collapsing a category with the Space key
const category = await page.$(`.category`);

// verify tabIndex, role and focus
expect(await page.evaluate(elem => elem.getAttribute(`role`), category)).toEqual(`button`);
expect(await page.evaluate(elem => elem.getAttribute(`tabindex`), category)).toEqual(`0`);
expect(await page.evaluate(elem => window.document.activeElement === elem, category)).toEqual(true);

// verify aria-expanded = false
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`false`);

// toggle category by pressing Space
await page.keyboard.press('Space');

// verify aria-expanded = true
expect(await page.evaluate(elem => elem.getAttribute(`aria-expanded`), category)).toEqual(`true`);

스크린 리더의 성공적인 사용 보장

사용자의 약 1% ~2% 가 스크린 리더를 사용합니다. 스크린 리더와 키보드만 사용하여 중요한 정보를 모두 이해하고 구성요소와 상호작용할 수 있나요?

다음 질문은 스크린 리더 접근성 문제를 해결하는 데 도움이 됩니다.

모든 구성요소와 이미지에 의미 있는 대체 텍스트가 있나요?

양방향 구성요소의 이름 또는 목적에 관한 정보가 시각적으로 전달될 때마다 접근성이 우수한 대체 텍스트를 제공하세요.

예를 들어 <fancy-menu> UI 구성요소에 설정 메뉴임을 나타내기 위해 톱니바퀴 아이콘만 표시되는 경우 동일한 정보를 전달하는 '설정'과 같이 액세스 가능한 대체 텍스트가 필요합니다. 컨텍스트에 따라 alt 속성, aria-label 속성, aria-labelledby 속성 또는 Shadow DOM에 일반 텍스트를 사용하여 대체 텍스트를 제공할 수 있습니다. WebAIM 빠른 참조에서 일반적인 기술 도움말을 확인할 수 있습니다.

이미지를 표시하는 모든 UI 구성요소는 alt 속성과 유사한, 이미지의 대체 텍스트를 제공하는 메커니즘을 제공해야 합니다.

구성요소가 시맨틱 정보를 제공하나요?

보조 기술은 시각장애인에게 표현되는 시맨틱 정보를 형식, 커서 스타일, 위치 등의 시각적 단서와 함께 전달합니다. 표준화된 요소에는 브라우저에서 기본으로 제공하는 이러한 시맨틱 정보가 있지만, 맞춤 구성요소의 경우 ARIA를 사용하여 정보를 추가해야 합니다.

일반적으로 마우스 클릭 또는 마우스 오버 이벤트를 수신하는 모든 구성요소에는 일종의 키보드 이벤트 리스너 및 ARIA 역할(ARIA 상태와 속성)이 있어야 합니다.

예를 들어 맞춤 <fancy-slider> UI 구성요소는 슬라이더의 ARIA 역할을 취할 수 있으며 이 역할에는 aria-valuenow, aria-valuemin, aria-valuemax와 같은 관련 ARIA 속성이 있습니다. 이러한 속성을 맞춤 구성요소의 관련 속성에 결합하면 보조 기술 사용자가 요소와 상호작용하고 값을 변경하며 요소의 시각적 표현이 그에 따라 변경되도록 할 수 있습니다.

<fancy-slider role="slider" aria-valuemin="1" aria-valuemax="5" aria-valuenow="2.5">
</fancy-slider>

사용자가 색상에 의존하지 않고 모든 것을 이해할 수 있나요?

색상이 상태 표시, 사용자에게 응답 요청 메시지 표시, 데이터 시각화와 같은 정보 전달 수단으로만 사용되어서는 안 됩니다. 예를 들어 원형 차트가 있는 경우 시각 장애가 있는 사용자가 슬라이스의 시작과 끝 위치를 알 수 없더라도 정보를 이해할 수 있도록 각 슬라이스의 라벨과 값을 제공합니다.

접근성을 보장하기 위한 라벨 및 값이 포함된 원형 차트 — 액세스 가능한 원형 차트 (W3C Web Accessibility Initiative 참고)

대비가 충분한가요?

구성요소에 표시된 모든 텍스트 콘텐츠는 최소 WCAG AA 수준 대비 기준점을 충족해야 합니다. 더 높은 AAA 임곗값을 충족하는 고대비 테마를 제공하고 사용자가 맞춤 대비 또는 다른 색상이 필요한 경우 사용자 에이전트 스타일시트를 적용할 수 있는지 확인합니다. 이 색상 대비 검사기를 사용하여 구성요소를 디자인할 수 있습니다.

이동하거나 깜박이는 콘텐츠를 중지할 수 있고 안전한가요?

사용자는 5초 넘게 움직이거나 스크롤하거나 깜박이는 콘텐츠를 일시중지하거나 중지하거나 숨길 수 있어야 합니다. 일반적으로 콘텐츠를 플래시하지 마세요.

플래시가 발생해야 하는 경우에는 초당 3회 이하로 깜박이세요.

접근성 도구 및 테스트

사이트와 구성요소의 접근성을 평가하는 데 사용할 수 있는 도구는 100개가 넘습니다. 자동화된 도구도 있지만 수동 테스트가 필요한 도구도 있습니다.

다음은 고려해야 할 몇 가지 사항입니다.

Axe는 선택한 프레임워크 또는 브라우저의 자동화된 접근성 테스트를 제공합니다. Axe Puppeteer는 자동화된 접근성 테스트를 작성하는 데 사용할 수 있습니다.
Lighthouse 접근성 감사는 일반적인 접근성 문제를 발견하는 데 유용한 정보를 제공합니다. 접근성 점수는 Axe 사용자 영향 평가를 기반으로 하는 모든 접근성 검사의 가중 평균입니다. 지속적 통합을 통한 접근성 모니터링에 대해서는 Lighthouse CI를 참고하세요.
Tenon.io는 일반적인 접근성 문제를 테스트하는 데 유용합니다. Tenon은 빌드 도구, 브라우저 (확장 프로그램 사용), 텍스트 편집기까지 강력한 통합을 지원합니다.
구성요소의 접근성 문제를 강조표시하기 위한 라이브러리별 및 프레임워크별 도구가 많이 있습니다. 예를 들어 eslint-plugin-jsx-a11y를 사용하여 편집기에서 React 구성요소의 접근성 문제를 강조표시합니다.

Angular를 사용하는 경우 codelyzer가 편집기 내 접근성 감사도 제공합니다.

보조 기술 사용

Accessibility Inspector (Mac) 또는 Windows Automation API 테스트 도구 및 AccProbe (Windows)를 사용하여 보조 기술이 웹 콘텐츠를 보는 방법을 조사할 수 있습니다. 또한 about://accessibility로 이동하여 Chrome에서 생성한 전체 접근성 트리를 확인할 수 있습니다.
Mac에서 스크린 리더 지원을 테스트하는 가장 좋은 방법은 VoiceOver 유틸리티를 사용하는 것입니다. 접근성 트리를 사용 설정하거나 중지하려면 ⌘F5를 사용하고, 페이지를 탐색하려면 Ctrl+Option ←→를, 접근성 트리를 위아래로 이동하려면 Ctrl+Shift+Option + ↑↓를 사용합니다. 자세한 내용은 VoiceOver 명령어 전체 목록 및 VoiceOver 웹 명령어 목록을 참고하세요.
Windows에서 NVDA는 무료 오픈소스 스크린 리더입니다. 시력이 정상인 사용자에게는 학습 곡선이 가파릅니다.
ChromeOS에는 스크린 리더가 내장되어 있습니다.

웹 접근성을 개선하기 위해 갈 길이 멉니다. 웹 연감에 따라 다음 안내를 따르세요.

사이트 5곳 중 4곳은 배경과 섞여서 읽을 수 없는 텍스트를 사용합니다.
페이지의 49.91% 가 여전히 일부 이미지에 alt 속성을 제공하지 못하고 있습니다.
버튼이나 링크를 사용하는 페이지 중 24% 만이 라벨을 포함합니다.
22.33% 의 페이지만이 모든 양식 입력에 대해 라벨을 제공합니다.

모든 사용자가 더 쉽게 접근할 수 있는 환경을 구축하기 위해 Google이 할 수 있는 일은 많습니다.