접근성

docs.scrimba.com

사람들은 다양한 방식으로 웹에 접근합니다. 어떤 사람은 화면을 보고 마우스를 움직이고, 어떤 사람은 화면을 볼 수 없어 음성으로 읽히는 것을 듣습니다. 어떤 사람은 마우스를 절대 만지지 않고 키보드, 음성, 또는 누르는 스위치를 통해 페이지를 이동합니다. 접근성은 모든 사람이 사용할 수 있는 페이지를 만드는 관행이며, 대부분은 HTML을 의도된 대로 작성하는 것에 다다를 것입니다.

접근성이 중요한 이유

**접근성**은 모든 사람이 어떤 상황과 어떤 방식으로 든 페이지를 사용할 수 있도록 하는 것을 의미합니다. 어떤 사람은 화면을 볼 수 없어 페이지를 음성으로 읽어주는 소프트웨어를 통해 들어야 할 수도 있습니다. 어떤 사람은 마우스를 사용하지 않고 키보드로 페이지를 이동할 수도 있습니다. 어떤 사람은 편하게 읽기 위해 더 큰 텍스트나 더 강한 색상이 필요할 수도 있습니다.

계단 옆에 경사로가 있는 건물을 생각해 보세요. 경사로는 계단을 올라갈 수 없는 사람을 도우면서 다른 누구에게도 아무것도 빼앗지 않습니다. 접근 가능한 HTML은 같은 개념입니다: 페이지를 더 많은 사람에게 열어주면서 누구도 더 나쁘게 만들지 않습니다.

안심할 수 있는 부분은 HTML은 처음부터 접근 가능하다는 것입니다. 각 콘텐츠에 올바른 요소를 사용함으로써 대부분의 길을 무료로 얻을 수 있습니다.

접근성은 종종 a11y (a, 11글자, y)로 줄여집니다. 이는 사람들이 웹에 접근하는 모든 방식에서 페이지가 작동하는 것에 관한 것입니다: 페이지를 음성으로 읽어주는 스크린 리더, 키보드만으로의 탐색, 음성 제어, 화면 확대, 색상 감소 또는 고대비 디스플레이 모드입니다.

가장 도움이 되는 실무적 틀: HTML은 접근성을 시작점으로 제공하며, 끝에 추가하는 것이 아닙니다. 대부분의 작업은 올바른 요소를 선택하고 브라우저가 이미 하고 있는 것을 취소하지 않는 것입니다. 실패는 작은 원인 집합에서 나타나는 경향이 있습니다: 일반 요소에서 재구축된 사용자 정의 위젯, 레이블이 없는 양식 필드, 약한 색상 대비, 그리고 마우스에만 응답하는 동작입니다.

접근성은 보조 기술 (누군가가 컴퓨터를 작동하도록 돕는 소프트웨어 또는 하드웨어, 예를 들어 페이지를 음성으로 읽어주는 스크린 리더, 클릭 대신 누르는 스위치 장치 또는 음성 제어)을 사용하는 사람들이 페이지를 인지하고, 작동하고, 이해할 수 있는지 여부입니다. 참조 표준은 WCAG(웹 콘텐츠 접근성 지침)이며, 네 가지 원칙으로 구성됩니다: 콘텐츠는 인지 가능하고, 작동 가능하고, 이해 가능하며, 견고해야 합니다.

두 가지 결과는 기억할 가치가 있습니다. 첫째, 보조 기술이 의존하는 것과 같은 구조가 검색 엔진과 다른 기계가 DOM(페이지의 브라우저 메모리 내 모델)에서 읽는 것이기도 하므로 접근성과 SEO는 시간을 두고 경쟁하는 대신 같은 방향으로 당깁니다. 둘째, 많은 장소에서 접근성은 좋으면 좋을 기능이 아니라 공개 면한 사이트의 법적 요구사항입니다. 모든 것을 생각하는 데 유용한 방법: 접근 가능한 페이지는 대부분 올바르게 구축된 것입니다. 이 장의 거의 모든 것은 의도된 대로 사용되는 표준 HTML입니다.

Juno접근성이 중요한 이유 접근성은 모든 사람이 페이지를 사용할 수 있다는 것을 의미하며, 그들이 누구든 어디서 왔든 상관없습니다. 좋은 부분은 올바른 요소를 선택하는 순간 HTML이 대부분을 무료로 제공한다는 것입니다. 계단 옆에 경사로를 그려보세요: 더 많은 사람들이 들어가고, 누구도 더 나쁘지 않습니다.

Juno접근성이 중요한 이유 접근성은 스크린 리더, 키보드, 확대기 등 모든 것을 위해 작동하는 페이지입니다. HTML이 기본적으로 접근 가능하기 때문에 좋은 위치에서 시작하므로 대부분의 실패는 사용자 정의 위젯과 누락된 레이블로 인한 것입니다. 올바른 요소를 사용하여 구축하면 이미 대부분의 길을 갔습니다.

Juno접근성이 중요한 이유 표준은 WCAG이고 네 가지 원칙은: 인지 가능, 작동 가능, 이해 가능, 견고함입니다. 스크린 리더를 돕는 것과 같은 구조가 검색 크롤러가 DOM을 읽도록 돕기 때문에 이것은 시간에 대한 별도의 세금이 아닙니다. 나머지 장을 의도된 대로 사용되는 일반적인 HTML로 취급하세요. 왜냐하면 대부분이 그것이기 때문입니다.

기초로서의 의미론적 HTML

접근성을 위해 할 수 있는 가장 효과적인 단일 작업은 일반적인 요소로 스타일링된 것이 아니라 콘텐츠의 의미와 일치하는 요소를 사용하는 것입니다.

**의미론적 HTML**은 콘텐츠가 어떻게 보이는지가 아니라 무엇 인지를 위해 태그를 선택하는 것을 의미합니다. 제목은 <h1>부터 <h6>까지 사용합니다. 버튼은 <button>을 사용합니다. 링크는 <a>를 사용합니다. 목록은 <ul> 또는 <ol>을 사용합니다. 이들 각각은 이미 스크린 리더가 알릴 수 있는 의미를 담고 있으므로, 청취자는 "이것은 버튼입니다" 또는 "이것은 제목입니다"를 보지 않고도 알 수 있습니다.

이사할 때 상자에 레이블을 붙이는 것과 같습니다. "부엌"으로 표시된 상자는 그것을 포장한 사람뿐만 아니라 그것을 옮기는 모든 사람을 돕습니다. 의미론적 태그는 같은 방식으로 콘텐츠에 레이블을 붙이므로 브라우저와 보조 기술은 각 부분이 무엇인지 알 수 있습니다.

실제로 이것은 버튼이 필요할 때 <button>을 사용하는 것을 의미합니다. 스타일링한 <div>가 아닙니다. <div>는 동일하게 보이도록 만들 수 있지만 그것이 무엇인지는 아무것도 말하지 않습니다. 의미론적 HTML 장은 전체 집합을 살펴봅니다.

의미론적 요소는 이미 첨부된 동작과 의미를 가지고 옵니다. <button>은 포커스 가능하고 Enter와 Space에 응답하며 버튼으로 발표됩니다. <nav>는 탐색 영역을 표시합니다. 제목 <h1>부터 <h6>까지는 스크린 리더 사용자가 점프할 수 있는 개요를 형성합니다, 이는 시각적 독자가 섹션에 대해 훑는 방식과 같습니다.

가장 많은 문제를 해결하는 규칙: 자신을 구축하기 전에 기본 요소를 사용하세요. <div role="button" tabindex="0">과 클릭 핸들러는 작동하도록 만들 수 있지만 포커스, 키보드 지원 및 역할을 직접 다시 구현하고 있으며, 이 중 하나의 조각이 빠지는 경향이 있습니다. 실제 <button>은 모든 것을 한 번에 제공합니다. 랜드마크 요소(<header>, <nav>, <main>, <aside>, <footer>)는 페이지 규모에서 같은 일을 합니다: 스크린 리더 사용자가 위의 모든 것을 들을 대신 바로 영역으로 건너뛸 수 있습니다. 의미론적 HTML 장은 각각을 다룹니다.

의미론적 HTML이 기초인 이유는 브라우저가 각 의미론적 요소를 접근성 트리 (보조 기술이 읽는 페이지의 축약된 버전, 아래 ARIA 섹션에서 완전히 설명됨)의 역할에 매핑하기 때문입니다. <button>은 당신의 작업 없이 버튼 역할, 포커스 동작 및 키보드 처리를 받습니다. <div>에서 다시 구축하면 그 중 아무것도 상속하지 않습니다: 이제 당신은 포커스 가능성, 키 처리 및 발표된 역할을 직접 소유하고 있으며, 모든 간격은 누군가의 결함입니다.

두 가지 습관이 대부분의 무게를 전달합니다. 제목 레벨에 실제 구조를 제공하세요: 페이지에 대해 하나의 <h1>, 그 다음 수준을 건너뛰지 않고 중첩된 <h2>와 <h3> (스크린 리더 사용자가 제목으로 탐색하고 <h2>에서 <h4>로의 점프는 누락된 섹션으로 읽혀집니다). 그리고 랜드마크 요소(<main>, <nav>, <header>, <footer>, <aside>)를 사용하여 페이지가 탐색 가능한 영역을 노출하도록 합니다. 인식할 실패 모드는 "div 수프"이며, 거의 전적으로 <div>와 <span>으로 조립된 페이지입니다: 완벽하게 렌더링되고 보조 기술에 거의 아무것도 노출하지 않습니다. 왜냐하면 이 두 요소는 전혀 역할을 갖지 않기 때문입니다.

Juno기초로서의 의미론적 HTML 태그를 어떻게 보이는지가 아니라 콘텐츠가 무엇인지를 위해 선택하세요: <button>은 버튼용, <h1>은 제목용, <a>은 링크용입니다. 각각은 이미 스크린 리더에게 그것이 무엇인지 알려주므로 당신은 그것을 무료로 얻습니다. 스타일링된 <div>는 같게 보일 수 있지만 여전히 아무것도 말하지 않습니다.

Juno기초로서의 의미론적 HTML 기본 요소는 이미 연결된 포커스, 키보드 지원 및 음성 역할을 가지고 있으므로 <button>은 하나인 척하는 <div>를 이깁니다. 다시 구축하기 전에 실제 요소를 사용하고 사람들이 건너뛸 수 있도록 <nav>과 <main>과 같은 랜드마크에 의존하세요. 그것이 대부분의 일입니다.

Juno기초로서의 의미론적 HTML 모든 의미론적 요소는 접근성 트리의 역할에 매핑되므로 <button>은 세 개 모두의 역할, 포커스 및 키를 제공하는 반면 <div>는 세 가지 모두의 청구서를 제공합니다. 수준을 건너뛰지 않고 순서대로 제목을 유지하세요, 사람들이 그것들로 탐색하기 때문입니다. Div 수프는 멋지게 렌더링되고 보조 기술에 아무것도 말하지 않으며, 그것이 전체 문제입니다.

텍스트 대체, 레이블, 포커스, 키보드

일부 콘텐츠는 자신을 위해 말할 수 없습니다. 이미지는 설명할 때까지 스크린 리더에 보이지 않습니다. 양식 필드는 레이블이 지정될 때까지 추측입니다. 그리고 마우스에만 응답하는 페이지는 하나를 사용하지 않는 모든 사람을 제외합니다. 이 네 가지 영역은 조금의 관심이 먼 길을 가는 곳입니다.

몇 가지 신뢰할 수 있는 습관은 대부분을 포함합니다:

• 이미지에는 alt 텍스트가 필요합니다. alt 특성은 그림을 볼 수 없는 사람을 위해 설명합니다. 이미지가 장식용일 뿐이면, 빈 alt=""은 스크린 리더에게 건너뛰도록 알려줍니다.

<img src="red-fox.jpg" alt="snow에 말려 있는 빨간 여우">

• 양식 필드에는 레이블이 필요합니다. <label>은 방문자와 스크린 리더 모두에게 필드에 무엇을 입력할지 알려줍니다.

<label for="email">이메일 주소</label>
<input id="email" type="email">

• 버튼과 링크에는 명확한 텍스트가 필요합니다. "더 읽기"는 맥락 밖에서 읽을 때 불명확합니다. "티켓 가격에 대해 더 읽기"는 독자적으로 이해됩니다.
• 키보드 순서는 읽기 순서와 일치해야 합니다. Tab을 누르는 사람은 HTML에 나타나는 순서대로 페이지를 이동하므로 그 순서를 합리적으로 유지하세요.

이미지와 미디어 그리고 양식과 입력 장은 alt 텍스트와 레이블을 더 깊이 있게 다룹니다.

모든 양식 컨트롤을 <label>과 연결하세요. 신뢰할 수 있는 방법은 레이블의 for 특성을 입력의 id와 일치시키는 것입니다:

<label for="postcode">우편번호</label>
<input id="postcode" type="text" name="postcode">

이제 레이블을 클릭하면 필드에 포커스가 지정되고, 스크린 리더는 필드가 포커스를 얻을 때 레이블을 발표합니다. 양식과 입력 장은 변형을 다룹니다.

**Alt 텍스트**의 경우, 픽셀이 아니라 목적을 설명하세요: 색상과 모양의 목록보다 alt="회사 로고"가 더 좋으며, 장식 이미지는 파일 이름으로 읽히지 않도록 건너뛰도록 빈 alt=""을 가져갑니다.

포커스 순서는 DOM의 요소 순서를 따르므로 소스 순서를 시각적 읽기 순서와 일치시킵니다. 양수 tabindex 값(tabindex="1" 이상)을 피하세요; 그들은 올바르게 유지하기 어려운 별도의 탭 시퀀스를 발명합니다. tabindex="0"을 사용하여 사용자 정의 컨트롤을 자연스러운 순서에 추가하고 tabindex="-1"을 사용하여 스크립트로는 포커스할 수 있지만 Tab으로는 불가능하게 만듭니다.

키보드 작동성의 규칙은 짧습니다: 마우스로 할 수 있는 모든 것은 키보드로도 작동해야 합니다. 클릭이 메뉴를 열면 Enter도 해야 합니다. 그리고 보이는 포커스 윤곽선을 유지하여 키보드 사용자가 자신이 어디에 있는지 볼 수 있도록 합니다. 색상 대비도 여기에서 중요합니다: WCAG는 일반 텍스트와 배경 사이의 대비 비율이 최소 4.5:1이어야 하며, 모든 사람이 같은 색상을 구별하지는 않으므로 의미를 전달하기 위해 색상만 의존하지 마세요.

이 네 가지 영역은 모두 DOM이 시각적 레이아웃이 시각적 마우스 사용자를 위해 전달하는 의미를 전달해야 하는 장소입니다.

레이블. for/id에 의해 컨트롤에 묶이거나 입력을 래핑하여 묶인 <label>은 그 컨트롤에 접근 가능한 이름을 제공합니다 (보조 기술이 요소에 대해 발표하는 텍스트). 레이블이 없으면 스크린 리더는 필드의 유형만 읽고 그 목적에 대해서는 아무것도 읽지 않습니다. 자리 표시자 텍스트는 레이블이 아닙니다: 입력할 때 사라지고 일관되지 않게 발표됩니다.

텍스트 대체. alt는 <img>의 접근 가능한 이름입니다. 외관이 아니라 목적으로 작성하세요. 장식 이미지는 alt="" (비어 있음, 있지만 공백)을 가져갑니다. 그래서 접근성 트리에서 삭제됩니다; alt를 완전히 생략하는 것은 다르며, 일부 스크린 리더는 파일 이름 읽기로 돌아가는데, 이는 누구도 돕지 않습니다.

포커스. 포커스 순서는 DOM 순서이며, 당신이 그것을 재정의하지 않는 한, 그리고 양수 tabindex는 거의 항상 실수입니다. 왜냐하면 그것은 시각적 레이아웃에 대해 유지해야 하는 두 번째 탭 시퀀스를 구축하기 때문입니다. tabindex="0"을 사용하여 사용자 정의 컨트롤을 자연스러운 순서로 폴드하고 tabindex="-1"을 사용하여 요소를 스크립트로만 포커스할 수 있게 만드세요. 이는 동작 후 포커스를 이동할 때 필요합니다. 보이는 포커스 표시기를 유지하세요: 대체 제공 없이 outline: none을 설정하지 마세요. 또는 키보드 사용자가 자신의 위치를 추적하지 못합니다. 또한 키보드 트랩 (키보드 사용자가 입력할 수 있지만 빠져나올 수 없는 포커스)을 주시하세요. WCAG는 특별히 이를 언급합니다.

키보드와 대비. 모든 작업은 논리적 순서로 키보드로 도달하고 작동 가능해야 합니다. 대비의 경우 WCAG AA는 본문 텍스트에서 4.5:1을 묻고 큰 텍스트와 컨트롤의 시각적 경계에서 3:1을 묻습니다. 그리고 의미는 절대 색상만으로 이동해야 합니다. 빨간색으로만 표시된 필수 필드는 그 차이를 인지하지 못하는 사람에게 보이지 않습니다; 텍스트 또는 아이콘과 쌍을 이루세요.

Juno텍스트 대체, 레이블, 포커스, 키보드 네 가지 작은 습관이 대부분을 전달합니다: 이미지에 alt를 주고, 양식 필드에 <label>을 주고, 독자적으로 의미가 있는 버튼과 링크 텍스트를 작성하고, 탭 순서를 읽기 순서와 일치시키세요. 그들 중 어느 것도 오래 걸리지 않습니다. 장식 이미지는 건너뛰도록 빈 alt=""을 받습니다.

Juno텍스트 대체, 레이블, 포커스, 키보드 일치하는 for과 id로 모든 입력을 <label>에 연결하고, 목적으로 alt를 작성하고, 장식용으로 비우세요. 포커스 순서를 DOM 순서로 유지하고 양수 tabindex를 건너뛰세요. 기억할 선: 마우스로 할 수 있는 모든 것은 키보드도 해야 하며, 대비가 4.5:1에 도달하는지 확인하세요.

Juno텍스트 대체, 레이블, 포커스, 키보드 레이블과 alt는 요소의 접근 가능한 이름을 설정하므로 자리 표시자는 레이블이 아니고 누락된 alt는 빈 것이 아닙니다. DOM 순서로 포커스를 둡니다. 양수 tabindex를 피합니다. 대체 없이 포커스 윤곽선을 제거하지 마세요. 텍스트에서 4.5:1에 도달하고 색상이 유일한 신호가 되도록 하지 마세요. 또는 빨강 전용 필수 마커는 빨강을 볼 수 없는 누구에게도 도달하지 않습니다.

ARIA, 그리고 먼저 손을 뻗지 말아야 할 이유

접근성을 위해 특별히 만든 HTML 특성 집합이 있으며, 이를 ARIA라고 합니다. 올바른 위치에서 유용하며 플랫폼의 가장 오용되는 부분 중 하나이므로 그것이 하는 것과 언제 혼자 둘지 모두 이해할 가치가 있습니다.

**ARIA**는 Accessible Rich Internet Applications의 약자입니다. 요소에 추가할 수 있는 추가 특성 집합으로 보조 기술에 그것에 대해 더 알려줍니다. 이름은 첫 번째로 손을 뻗을 도구처럼 들리며 보통 마지막입니다.

이유는 간단합니다: ARIA가 설명할 수 있는 대부분의 것은 HTML이 이미 그 자체로 말합니다. <button>은 이미 버튼으로 발표됩니다. role="button"을 추가하는 것은 아무것도 변경하지 않습니다. 요소가 무엇인지를 설명하기 위해 ARIA를 추가하는 자신을 발견한다면, 그것은 보통 그것이 무엇인지를 이미 말하는 일반 HTML 요소를 교환할 신호입니다.

이동 상자에 붙인 포스트잇을 그려보세요. 상자가 이미 "부엌"으로 인쇄되어 있다면, "부엌"을 읽는 포스트잇은 어지러움만 추가합니다. 아무런 레이블이 없는 상자를 위해 메모를 저장하세요. ARIA는 HTML에 요소가 없는 페이지의 부분을 위한 것이며, 그것이 들릴 수 있는 것보다 더 드뭅니다.

ARIA는 요소에 세 가지 종류의 정보를 추가합니다: 역할 (무엇인가, role="dialog" 같은), 상태 (그 현재 조건, aria-expanded="false" 같은), 그리고 속성 (일부 도움말 텍스트를 가리키는 aria-describedby 같은 추가 관계). 스크린 리더는 네이티브 HTML 동등 항목이 없는 탭 패널 또는 슬라이더와 같은 사용자 정의 위젯을 발표하기 위해 이들을 사용합니다.

선도할 지침은 ARIA의 첫 번째 규칙입니다: 네이티브 요소가 이미 일을 하면 ARIA를 사용하지 마세요. 네이티브 <button>은 <div role="button">을 매번 이깁니다, 왜냐하면 네이티브 요소는 동작을 가져오고 ARIA 특성은 레이블만 가져오기 때문입니다. 더 나쁜 것은, 잘못되었거나 오래된 ARIA 특성은 없는 것보다 더 나쁩니다, 왜냐하면 그것은 브라우저가 다른 경우에 말할 것을 재정의하기 때문입니다. 잘못된 요소에 aria-hidden="true"를 놓으세요. 그리고 당신은 스크린 리더 사용자로부터 실제 콘텐츠를 숨깁니다. 한편 그것은 화면에 표시됩니다. HTML이 요소가 없는 위젯을 구축할 때 ARIA에 손을 뻗으세요. 그 다음 특성을 처음부터 발명하는 대신 확립된 패턴을 따르세요.

ARIA가 편집하는 것으로 시작하세요. 접근성 트리는 브라우저가 DOM 옆에 구축하는 평행 구조입니다. 각 요소에 대해 그것은 역할 (요소가 무엇인가: 버튼, 링크, 제목)을 기록합니다, 그것의 상태와 속성 (조건과 관계, aria-expanded, aria-checked, 또는 disabled 같은), 그리고 그것의 접근 가능한 이름과 설명 (발표되는 텍스트). 보조 기술은 이 트리를 읽으며, CSS도 아니고 원시 HTML도 아닙니다.

ARIA는 그 트리를 직접 편집하기 위한 어휘입니다: 역할 (role="tablist"), 시간에 따라 변하는 상태 (aria-selected="true"), 더 안정적인 관계를 설명하는 속성 (aria-labelledby, aria-controls). **ARIA의 첫 번째 규칙**은 네이티브 HTML 요소 또는 특성이 이미 필요한 역할, 상태 또는 속성을 제공하면, 그것을 사용하고 ARIA를 추가하지 않는 것입니다. 이유는 ARIA가 접근성 트리만 변경하고 그 자체로는 동작을 추가하지 않기 때문입니다. <div>에 role="button"을 사용하면 스크린 리더가 그것을 버튼이라고 부르게 합니다, 하지만 그것은 포커스 가능성, Enter 또는 Space 처리, 그리고 비활성 지원을 부여하지 않습니다. 당신은 이들 각각을 직접 추가하게 되고, 당신이 하나를 잊는 날은 버튼이라고 발표하지만 행동하지 않는 컨트롤을 가져갑니다, 이는 정직한 <div>보다 더 나쁩니다.

몇 가지 규칙은 ARIA가 방지하도록 의도된 피해를 일으키지 않게 합니다. 네이티브 요소를 선호합니다. 네이티브 의미론을 재정의하지 마세요 (<button>에 role="heading" 없음). aria-hidden="true"로 표시된 부분 트리 내에 대화형 요소를 배치하지 마세요. 또는 스크린 리더가 볼 수 없는 포커스 가능한 컨트롤을 만듭니다. 그리고 상태를 JavaScript와 동기화하세요, 오래된 aria-expanded는 사용자를 거짓말합니다. ARIA가 필요할 때, 특성을 처음부터 구성하는 대신 일반적인 위젯의 게시된 패턴인 WAI-ARIA Authoring Practices에서 구축하세요. 이것을 테스트하기 위해, 브라우저의 접근성 검사기는 주어진 요소에 대해 계산된 역할, 이름 및 상태를 보여 주므로, 그것이 보조 기술이 받을 정확히 것입니다.

JunoARIA, 그리고 먼저 손을 뻗지 말아야 할 이유 ARIA는 보조 기술에 요소를 설명하는 추가 특성 집합입니다. 첫 번째로 손을 뻗을 것처럼 들리고 보통 마지막이며, 왜냐하면 실제 <button>은 이미 버튼이라고 말하기 때문입니다. ARIA를 HTML이 요소가 없는 페이지의 드문 부분을 위해 저장하세요. 그리고 다른 모든 것을 순수하게 유지하세요.

JunoARIA, 그리고 먼저 손을 뻗지 말아야 할 이유 ARIA는 HTML이 요소가 없는 사용자 정의 위젯을 위해 역할, 상태 및 속성을 추가합니다. ARIA의 첫 번째 규칙은 네이티브 요소가 이미 일을 하면 그것을 건너뛰는 것입니다. 왜냐하면 잘못되었거나 오래된 특성은 없는 것보다 더 나빴습니다. 버튼이 되도록 <button>을 레이블링하는 자신을 발견한다면, 멈추고 버튼을 사용하세요.

JunoARIA, 그리고 먼저 손을 뻗지 말아야 할 이유 ARIA는 접근성 트리를 편집하고: 역할, 상태 및 속성, 그 외는 아무것도 아닙니다, 따라서 동작을 추가하지 않습니다. 그것이 ARIA의 첫 번째 규칙의 전체 이유입니다, 왜냐하면 <div>에 role="button"을 사용하면 포커스와 키 처리가 없을 때까지 버튼을 발표합니다. JavaScript와 상태를 동기화하세요. 그리고 위젯이 필요할 때, 특성을 발명하는 대신 게시된 패턴에서 복사하세요.

빠른 자가 감시

접근성 문제를 확인하기 위해 전문가 소프트웨어가 필요하지 않습니다. 당신의 기계에 이미 있는 도구로 몇 가지 확인은 대부분의 문제를 찾고 단 몇 분 밖에 걸리지 않습니다.

당신이 어떤 페이지에도 실행할 수 있는 짧은 체크리스트는 다음과 같습니다:

• 마우스를 놓고 Tab을 누르세요. 당신이 의미가 있는 순서로 모든 링크와 버튼에 도달할 수 있습니까? Enter로 활성화할 수 있습니까?
• 모든 이미지가 alt 특성을 가지고 있습니까?
• 모든 양식 필드가 <label>을 가지고 있습니까?
• 당신의 버튼과 링크는 여전히 독자적으로 읽을 때 의미가 있습니까?
• 텍스트가 배경에 대해 명확하게 읽기 쉽습니까?

당신의 자신의 페이지에서 이것을 실행하는 것은 빠르고, 사람들이 가장 자주 맞는 문제를 확인합니다. Tab 키가 어딘가에 붙거나 이미지가 alt를 가지지 않으면, 당신은 고칠 가치가 있는 것을 찾았습니다.

반복 가능한 통과를 당신의 워크플로우에 구축하세요:

1. 키보드. 전체 페이지를 Tab으로 스크롤하세요. 모든 대화형 요소는 도달 가능해야 하고, 합리적인 순서로, 보이는 포커스 표시기로, 그리고 Enter 또는 Space로 작동 가능해야 합니다. 포커스가 사라지거나 막히면, 다른 어느 것보다 먼저 고칩니다.
2. 제목과 랜드마크. 하나의 <h1>이 있고, 제목이 수준을 건너뛰지 않으며, 주요 영역이 <main>, <nav> 및 다른 랜드마크를 사용한다는 것을 확인하세요.
3. 이름. 모든 이미지가 alt를 가지고 있고, 모든 컨트롤이 레이블을 가지고 있으며, 모든 링크와 버튼이 맥락 밖에서 명확하게 읽혀집니다.
4. 대비. 브라우저의 dev tools에서 텍스트를 배경과 비교하고, 비율을 보고하고 실패하는 것을 표시하는지 확인하세요.

axe 브라우저 확장 또는 Chrome dev tools의 Lighthouse 패널과 같은 자동 검사기는 문제의 유용한 몫을 확인합니다, 하지만 오직 몫입니다. 그들은 alt 텍스트가 의미 있는지 또는 탭 순서가 의미가 있는지 판단할 수 없으므로, 수동 키보드 통과는 필수적입니다.

작업 감시는 자동 및 수동 통과를 결합합니다, 왜냐하면 자동화는 부분의 일부만 포함하기 때문입니다: 도구는 누락된 alt, 누락된 레이블 및 대비 실패를 안정적으로 찾습니다 (대략 WCAG 기준의 3분의 1), 그리고 alt 텍스트가 정확한지 또는 탭 순서가 논리적인지 판단할 수 없습니다.

• 자동화됨. 기계적 실패를 쓸기 위해 먼저 axe 또는 Lighthouse를 실행하세요.
• 키보드. 마우스를 놓고 Tab으로 스크롤하고, 도달 가능성, 논리적 순서, 보이는 포커스 링, 전체 작동 가능성 및 포커스가 빠져나올 수 없는 위치가 없음을 확인합니다. 이 통과 만으로도 대부분의 사용자 정의 위젯 결함을 표면화합니다.
• 스크린 리더. 하나를 켜고 (VoiceOver는 Cmd+F5를 통해 macOS와 함께 제공되며, NVDA는 Windows에서 무료 다운로드이며, TalkBack은 Android에 내장됨) 몇 가지 핵심 흐름을 듣습니다. 당신은 이름이 발표되고, 역할이 맞으며, 상태 변경이 실제로 음성으로 표현되는지 확인합니다.
• 접근성 트리. 브라우저의 dev tools는 모든 요소에 대해 계산된 역할, 이름 및 상태를 표시하므로, 그것이 보조 기술이 정말로 받을 것을 당신에게 알려줍니다. 요소가 어떻게 보이는지 독립적이면서요.

자동 도구가 녹색을 보고할 때도 키보드와 스크린 리더 통과를 실행하세요, 왜냐하면 그들이 확인할 수 없는 것들은 실제 사람이 페이지를 사용하는 것에 가장 영향을 미치기 때문입니다.

Juno빠른 자가 감시 마우스를 놓고 페이지를 Tab으로 스크롤하세요: 의미 있는 순서로 모든 것에 도달하고 사용할 수 있습니까? 그 다음 모든 이미지가 alt를 가지고 있고, 모든 필드가 <label>을 가지고 있으며, 텍스트가 배경에 대해 명확하게 읽혀집니다. 이 몇 분이 사람들이 가장 맞는 문제를 확인합니다.

Juno빠른 자가 감시 그것을 일상으로 만드세요: 도달 가능성과 순서를 위해 Tab으로 스크롤하고, 하나의 <h1>을 확인하고 제목을 건너뛰지 말고, 이미지와 컨트롤에 이름이 있는지 확인하고, dev tools에서 대비를 읽습니다. axe와 Lighthouse 같은 자동 도구는 도움이 되지만 일부만 확인하므로, 수동 키보드 통과를 계속하세요.

Juno빠른 자가 감시 자동화는 누락된 alt, 누락된 레이블 및 대비를 찾습니다, 대략 WCAG의 3분의 1, 그리고 의미 또는 순서에 대해 아무것도 판단하지 않습니다. 그래서 키보드 통과, 스크린 리더를 통한 청취, 그리고 접근성 검사기에서 계산된 역할과 이름을 살펴보세요. 도구가 실행할 수 없는 확인은 가장 중요하므로, 보고서가 녹색일 때도 직접 실행하세요.