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

웹 개발자를 위한 접근성

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

Addy Osmani

모든 사람이 포용적이며 액세스할 수 있는 사이트를 만드는 것이 중요합니다. 최적화할 수 있는 최소 6가지 주요 장애 영역은 다음과 같습니다. 시각적, 청각, 이동성, 인지, 음성, 신경과 같은 차원의 특징을 나타냅니다. 많은 도구와 리소스가 도움이 될 수 있습니다. 초보자도 사용할 수 있습니다.

10억 명 이상 장애를 가지고 살아요

액세스할 수 있으려면 사이트가 여러 기기에서 작동해야 함 다양한 화면 크기 및 다양한 입력 유형(예: 스크린 리더)을 사용할 수 있습니다. 또한 사이트는 가장 광범위한 사용자 그룹, 많은 사람들이 있습니다

사용자에게 발생할 수 있는 몇 가지 장애는 다음과 같습니다.

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

시각적 문제는 색상을 구별할 수 없는 문제부터 시각적으로 전혀 표시되지 않는 문제까지 다양합니다.

텍스트 콘텐츠가 최소 요건을 충족하는지 확인 명암비 기준.
정보를 전달하지 마세요. 색상만 사용하여 모든 텍스트가 resizable
모든 사용자 인터페이스 구성요소를 보조 기술과 함께 사용할 수 있는지 확인 점자 디스플레이와 같은 기능을 지원합니다. 그러려면 UI 구성요소가 마크업되었는지 확인해야 합니다. 그렇게 하면 접근성 API가 프로그래밍 방식으로 요소의 role, state, value, title입니다.

Chrome DevTools Inspect Element 도움말 스크린샷

저는 시력이 나빠서 살고 있는데, 사이트를 확대해서 보는 경우가 많습니다. 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 확장 프로그램인 색맹: 네 가지 형태의 색맹 시뮬레이션을 모두 사용해 보세요. 관련 콘텐츠 달토나즈 확장 프로그램을 사용할 수 있습니다.
고대비 모드가 사용 설정된 상태에서 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 값이 -1이면 요소가 프로그래매틱 방식으로 작동합니다. 포커스 가능하지만 탭 순서에는 없습니다.
tabindex 값이 0보다 크면 요소가 수동으로 탭 순서로 배치됩니다. 양수 tabindex 값을 갖는 페이지의 모든 요소를 방문함 순서, 순서, 즉 자연 탭 순서의 요소 앞에 오도록 해야 합니다.

도움말에서 tabindex 사용 사례를 찾아보세요. tabindex 사용.

기본 포커스 링을 사용하든 항상 포커스가 표시되는지 확인합니다. 눈에 띄는 맞춤 포커스 스타일을 적용하는 것입니다. 함정에 빠지지 않도록 키보드 사용자가 포커스를 요소로부터 이동할 수 있어야 함 키보드만 사용해 볼 수 있습니다.

자동 초점 사용

작성자는 HTML 자동 포커스 속성을 사용하여 특정 요소가 자동으로 포커스를 페이지가 로드될 때 렌더링됩니다. autofocus은(는) 다음에서 이미 지원되고 있습니다. 모든 웹 양식 컨트롤, 버튼을 포함합니다. 자체 맞춤 UI 구성요소의 요소에 자동으로 포커스를 맞추려면 focus() 메서드를 호출합니다. 포커스가 가능한 모든 HTML 요소에서 지원됨 (예: document.querySelector('myButton').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 속성(aria-valuenow, aria-valuemin, aria-valuemax)이 있습니다. 이러한 속성을 커스텀 구성요소의 관련 속성에 바인딩하면 보조 기술 사용자가 요소와 상호작용하도록 허용할 수 있습니다. 요소의 시각적 표현도 그에 따라 변경됩니다.

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

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

색상이 상태 표시, 사용자에게 응답 요청, 데이터 시각화 등이 있습니다. 예를 들어 원형 차트인 경우 각 슬라이스에 대한 라벨과 값을 입력합니다. 시각장애인 사용자가 정보를 이해할 수 있도록 슬라이스의 시작과 끝이 표시되지 않더라도

접근성을 보장하기 위한 라벨과 값이 있는 원형 차트 — 액세스 가능한 원형 차트 (출처: W3C 웹 접근성 이니셔티브).

대비가 충분한가요?

구성요소에 표시되는 모든 텍스트 콘텐츠는 최소 WCAG AA 수준 대비 임곗값. 배경과 잘 어울리는 고대비 테마를 AAA 기준점이 높아지면 사용자 에이전트 스타일 시트가 맞춤 대비 또는 다른 색상이 필요한 경우에 적합합니다. 이 색상 대비 검사기를 사용하면 됩니다. 구성요소를 설계할 때 참고 자료로 사용할 수 있습니다

움직이거나 플래시하는 콘텐츠는 중단할 수 있고 안전한가요?

사용자가 콘텐츠를 움직이거나, 스크롤하거나, 콘텐츠를 5초 이상 깜박임 일반적으로 콘텐츠를 플래시하지 마세요.

무언가가 깜박여야 하는 경우 초당 3회 이하로 깜박여야 합니다.

접근성 도구 및 테스트

100개가 넘는 도구를 사용하여 사이트의 접근성 평가 살펴보겠습니다 자동화된 도구도 있지만 수동 테스트가 필요한 도구도 있습니다.

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

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

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

보조 기술 사용

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

웹의 접근성을 개선하기 위해서는 아직 갈 길이 멉니다. 웹 연감을 참고하세요.

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

사람들이 더욱 쉽게 접근할 수 있는 환경을 구축하기 위해 있습니다.