developers.google.com/web/fundamentals/accessibility/semantics-aria?hl=ko
native HTML 요소가 포커스, 키보드 지원, 기본 제공 의미 체계를 제공하기 때문에, 지금까지는 네이티브 HTML 요소 사용을 권장해왔다.
하지만 단순한 레이아웃과 네이티브 HTML로는 작업을 수행하지 못할 때가 있다.
예를 들어서, 현재는 매우 일반적인 UI 구조인 팝업 메뉴에 대해 표준화된 HTML 요소가 없다.
또한, '사용자가 가급적 빨리 이 점에 대해서 알아야 함'과 같은 의미 체계상 특성을 제공하는 HTML 요소 역시 없다.
그럼 HTML이 단독으로 표현할 수 없는 의미 체계를 표현은 어떻게 해야할까?
Web Accessibility Initiative(www.w3.org/TR/wai-aria/)의 Accessible Rich Internet Applications (이른 바 ARIA)
는 native HTML로 관리할 수 없는 접근성 문제가 있는 영역을 연결하기에 적합하다.
ARIA는 요소가 접근성 트리로 변환되는 방식을 수정하는 속성을 지정할 수 있도록 허용하는 방식으로 작동한다.
<li tabindex="0" class="checkbox" checked>
Receive promotional offers
</li>
위 코드를 살펴보자.
이렇게 하면 시력이 정상인 사용자에게는 알맞지만, 스크린 리더는 이 요소가 확인란이라는 점을 알려주지 못하므로 시력이 나쁜 사용자가 이 요소를 완전히 놓칠 수 있다.
하지만 ARIA 속성을 사용하면 요소에 누락된 정보를 부여할 수 있으므로, 스크린 리더가 올바로 해석할 수 있다.
여기서는 요소를 확인란으로 명시적으로 식별하고 확인란이 기본적으로 선택되어 있음을 나타내기 위해서 role, aria-checked 속성을 추가하면된다.
그러면 접근성 트리에 목록 항목이 추가되고 스크린 리더가 확인란이라고 올바르게 알려준다.
<li tabindex="0" class="checkbox" role="checkbox" checked aria-checked="true">
Receive promotional offers
</li>
ARIA는 표준 DOM 접근성 트리를 변경하고 증가시키는 방식으로 작동한다.
ARIA를 사용하면 페이지에서 임의의 요소에 대한 접근성 트리를 미세하게 수정하거나 아예 근본적으로 수정할 수 있지만,
그게 바로 ARIA가 변경하는 유일한 것이기도 하다.
하지만 ARIA는 요소의 고유동작을 증가시키지는 않는다.
즉, 요소를 포커스 가능하게 한다거나, 요소에 키보드 이벤트 리스너를 제공하지는 않는다는 뜻이다. (개발 중이라고 한다)
또한 ARIA를 사용하려고 기본 의미 체계를 재정의할 필요는 없다.
<input type="checkbox">
<input type="text">
위와 같은 경우에는 role='checkbox'등의 어떤 역할이나 속성도 추가해주지 않아도 된다는 뜻이다.
'개발 > Web Programming' 카테고리의 다른 글
[웹 접근성] 웹 접근성이란? (0) | 2021.03.12 |
---|---|
[웹 접근성] ARIA의 기능 (0) | 2021.03.11 |
[웹 접근성] aria-label (0) | 2021.03.11 |
[CSS] box-sizing (content-box, border-box) (0) | 2021.03.07 |
Debounce, Throttling (0) | 2021.03.07 |