대부분의 개발자는 최신 웹의 표준 마크업 언어인 HTML (HyperText Markup Language)에 익숙합니다. 하지만 접근 가능한 리치 인터넷 애플리케이션 (ARIA) (이전에는 WAI-ARIA라고 함)에 대해서는 잘 모를 수 있습니다. ARIA가 무엇인지, 어떻게 사용되는지, 언제 사용해야 하는지, 언제 사용하지 말아야 하는지 등을 알아봅니다.
HTML과 ARIA는 디지털 제품을 접근 가능하게 만드는 데 중요한 역할을 하며, 특히 화면 읽기 프로그램과 같은 보조 기술 (AT)의 경우 더욱 그렇습니다. 둘 다 콘텐츠를 점자 또는 텍스트 음성 변환 (TTS)과 같은 대체 형식으로 변환하는 데 사용됩니다.
ARIA의 간략한 역사, ARIA가 중요한 이유, ARIA를 가장 잘 사용하는 시기와 방법을 검토합니다.
ARIA 소개
ARIA는 인터넷을 관리하고 규제하는 포괄적인 W3C (World Wide Web Consortium)의 하위 집합인 WAI (Web Accessibility Initiative) 그룹에서 2008년에 처음 개발했습니다.
ARIA는 실제 프로그래밍 언어가 아니라 접근성을 높이기 위해 HTML 요소에 추가할 수 있는 속성 집합입니다. 이러한 속성은 최신 브라우저에 있는 접근성 API를 사용하여 보조 기술에 역할, 상태, 속성을 전달합니다. 이 통신은 접근성 트리를 통해 이루어집니다.
"WAI-ARIA, 접근 가능한 리치 인터넷 애플리케이션 모음인 장애가 있는 사용자가 웹 콘텐츠와 웹 애플리케이션에 더 쉽게 접근할 수 있는 방법을 정의합니다. 특히 HTML, JavaScript, 관련 기술로 개발된 동적 콘텐츠와 고급 사용자 인터페이스 컨트롤에 도움이 됩니다."
WAI 그룹
접근성 트리
ARIA는 접근성 트리의 일부를 변경, 노출, 보강하여 AT를 사용하는 사용자의 환경을 개선하기 위해 잘못되거나 불완전한 코드를 수정합니다.
접근성 트리는 브라우저에서 생성되며 표준 DOM (문서 객체 모델) 트리를 기반으로 합니다. DOM 트리와 마찬가지로 접근성 트리에는 모든 마크업 요소, 속성, 텍스트 노드를 나타내는 객체가 포함되어 있습니다. 접근성 트리는 플랫폼별 접근성 API에서도 보조 기술이 이해할 수 있는 표현을 제공하는 데 사용됩니다.
ARIA 자체는 요소의 기능이나 시각적 모양을 변경하지 않습니다. 즉, AT 사용자만 ARIA가 있는 디지털 제품과 ARIA가 없는 디지털 제품 간의 차이점을 알 수 있습니다. 또한 개발자만이 요소를 최대한 접근 가능하게 만들기 위해 적절한 코드 및 스타일 변경을 할 책임이 있습니다.
ARIA의 세 가지 주요 기능은 역할, 속성, 상태/값입니다.
역할 은 페이지 또는 앱에서 요소가 무엇인지 또는 어떤 작업을 하는지 정의합니다.
<div role="button">Self-destruct</div>
속성 은 객체의 특성 또는 관계를 표현합니다.
<div role="button" aria-describedby="more-info">Self-destruct</div>
<div id="more-info">This page will self-destruct in 10 seconds.</div>
상태 및 값 은 요소와 연결된 현재 조건 또는 데이터 값을 정의합니다.
<div role="button" aria-describedby="more-info" aria-pressed="false">
Self-destruct
</div>
<div id="more-info">
This page will self-destruct in 10 seconds.
</div>
ARIA의 세 가지 요소를 모두 한 줄의 코드에서 사용할 수 있지만 필수는 아닙니다. 대신 최종 접근성 목표를 달성할 때까지 ARIA 역할, 속성, 상태 또는 값을 레이어링합니다. ARIA를 코드베이스에 올바르게 통합하면 AT 사용자가 웹사이트, 앱 또는 기타 디지털 제품을 성공적이고 공정하게 사용하는 데 필요한 모든 정보를 얻을 수 있습니다.
최근 Chrome DevTools에서는 전체 접근성 트리를 볼 수 있는 방법 을 만들어 개발자가 코드가 접근성에 미치는 영향을 더 쉽게 이해할 수 있도록 했습니다.
ARIA를 사용해야 하는 경우
2014년에 W3C는 HTML5 권장사항을 공식적으로 게시했습니다. 이와 함께 <main>와 같은 랜드마크 요소와 hidden 및 required와 같은 속성이 추가되는 등 몇 가지 큰 변화가 있었습니다.<header><footer><aside><nav> 이러한 새로운 HTML5 요소와 속성은 브라우저 지원 증가와 함께 ARIA의 특정 부분을 덜 중요하게 만듭니다.
브라우저가 ARIA와 동일한 암시적 역할이 있는 HTML 태그를 지원하는 경우 일반적으로 요소에 ARIA를 추가할 필요가 없습니다. 하지만 ARIA에는 HTML 버전에서 사용할 수 없는 역할, 상태, 속성이 여전히 많이 포함되어 있습니다. 이러한 속성은 현재 유용합니다.
이제 궁극적인 질문으로 넘어갑니다. 언제 ARIA를 사용해야 할까요? 다행히 WAI 그룹은 요소를 접근 가능하게 만드는 방법을 결정하는 데 도움이 되는 ARIA의 5가지 규칙을 개발했습니다.
규칙 1: ARIA를 사용하지 마세요
네, 맞습니다. 요소에 ARIA를 추가해도 접근성이 향상되지는 않습니다. WebAIM Million 연간 접근성 보고서 에 따르면 ARIA가 있는 홈페이지는 ARIA가 없는 홈페이지보다 감지된 오류가 평균 70% 더 많았는데, 이는 주로 ARIA 속성의 잘못된 구현 때문입니다.
이 규칙에는 예외가 있습니다. HTML 요소에 접근성 지원이 없는 경우 ARIA가 필요합니다. 이는 디자인에서 특정 HTML 요소를 허용하지 않거나 HTML에서 원하는 기능 또는 동작을 사용할 수 없기 때문일 수 있습니다. 하지만 이러한 상황은 드물어야 합니다.
하지 말아야 할 일: 역할 할당
<a role="button">Submit</a>
해야 할 일: 시맨틱 요소 사용
<button>Submit</button>
잘 모르겠다면 시맨틱 HTML 요소를 사용하세요.
규칙 2: HTML에 (불필요한) ARIA를 추가하지 마세요
대부분의 경우 HTML 요소는 있는 그대로 잘 작동하며 추가 ARIA를 추가할 필요가 없습니다. 실제로 ARIA를 사용하는 개발자는 대화형 요소의 경우 요소를 작동하도록 추가 코드를 추가해야 하는 경우가 많습니다.
하지 말아야 할 일: 오해의 소지가 있는 역할 할당
<h2 role="tab">Heading tab</h2>
해야 할 일: 역할을 올바르게 할당
<div role="tab"><h2>Heading tab</h2></div>
HTML 요소를 의도한 대로 사용하면 작업을 줄이고 코드를 더 잘 실행할 수 있습니다.
규칙 3: 항상 키보드 탐색 지원
모든 대화형 (사용 중지되지 않은) ARIA 컨트롤은 키보드로 접근할 수 있어야 합니다. 일반적으로 키보드 포커스를 받지 않는 포커스가 필요한 요소에 tabindex= '0'을 추가할 수 있습니다. 잠재적인 키보드 포커스 순서 문제를 방지하려면 가능한 한 양의 정수가 있는 탭 색인을 사용하지 마세요.
하지 말아야 할 일: tabindex 추가
<span role="button" tabindex="1">Submit</span>
해야 할 일: tabindex를 `0`으로 설정
<span role="button" tabindex="0">Submit</span>
물론 이 경우 실제 <button> 요소를 사용할 수 있다면 사용하세요.
규칙 4: 포커스 가능한 요소 숨기지 않기
포커스가 필요한 요소에 role= "presentation" 또는 aria-hidden= "true"를 추가하지 마세요. 여기에는 tabindex= "0"가 있는 요소도 포함됩니다. 이러한 역할과 상태를 요소에 추가하면 AT에 이러한 요소가 중요하지 않으며 건너뛰어야 한다는 메시지가 전송됩니다. 이로 인해 혼란이 발생하거나 요소와 상호작용하려는 사용자가 방해를 받을 수 있습니다.
하지 말아야 할 일: 포커스 가능한 요소 숨기기
<div aria-hidden="true"> <button>Submit</button> </div>
해야 할 일: 포커스 가능한 요소 노출
<div> <button>Submit</button> </div>
규칙 5: 대화형 요소에 접근 가능한 이름 사용
대화형 요소의 목적은 사용자가 요소와 상호작용하는 방법을 알기 전에 사용자에게 전달되어야 합니다. 모든 요소에 AT 기기를 사용하는 사용자를 위한 접근 가능한 이름이 있는지 확인하세요.
액세스 가능한 이름은 요소로 둘러싸인 콘텐츠 (<a>의 경우), 대체 텍스트 또는 라벨일 수 있습니다.
다음 각 코드 샘플에서 액세스 가능한 이름은 '빨간색 가죽 부츠'입니다.
<!-- A plain link with text between the link tags. -->
<a href="shoes.html">Red leather boots</a>
<!-- A linked image, where the image has alt text. -->
<a href="shoes.html"><img src="shoes.png" alt="Red leather boots"></a>
<!-- A checkbox input with a label. -->
<input type="checkbox" id="shoes">
<label for="shoes">Red leather boots</label>
Chrome DevTools를 사용하여 접근성 트리를 검사하거나 스크린 리더로 테스트하는 등 요소의 액세스 가능한 이름을 확인하는 방법은 다양합니다.
HTML의 ARIA
HTML 요소를 자체적으로 사용하는 것이 권장사항이지만 특정 상황에서는 ARIA 요소를 추가할 수 있습니다. 예를 들어 환경 제약으로 인해 더 높은 수준의 AT 지원이 필요한 패턴에서 ARIA를 HTML과 페어링하거나 모든 브라우저에서 완전히 지원되지 않는 HTML 요소의 대체 방법으로 ARIA를 HTML과 페어링할 수 있습니다.
물론 HTML에서 ARIA를 구현하기 위한 권장사항이 있습니다. 가장 중요한 것은 기본 HTML 역할을 재정의하지 않고, 중복을 줄이고, 의도하지 않은 부작용을 인식하는 것입니다.
몇 가지 예를 살펴보겠습니다.
하지 말아야 할 일: 잘못된 역할 할당
<a role="heading">Read more</a>
해야 할 일: 올바른 역할과 추가 링크 설명 사용
<a aria-label="Read more about some awesome article title">Read More</a>
하지 말아야 할 일: 중복 역할 추가
<ul role="list">...</ul>
해야 할 일: 중복 줄이기
<ul>...</ul>
하지 말아야 할 일: 잠재적인 부작용 놓치기
<details> <summary role="button">more information</summary> ... </details>
해야 할 일: 부작용 해결
<details> <summary>more information</summary> ... </details>
ARIA의 복잡성
ARIA는 복잡하므로 항상 주의해서 사용해야 합니다. 이 강의의 코드 예시는 비교적 간단하지만 접근 가능한 맞춤 패턴을 만드는 것은 빠르게 복잡해질 수 있습니다.
키보드 상호작용, 터치 인터페이스, AT/브라우저 지원, 번역 요구사항, 환경 제약, 기존 코드, 사용자 환경설정 등 주의해야 할 사항이 많습니다. 코딩 지식이 약간이라도 잘못 사용하면 해로울 수 있고, 단순히 짜증날 수도 있습니다.
이러한 경고를 제외하고 디지털 접근성은 전부 아니면 전무한 상황이 아니라 이와 같은 회색 영역을 허용하는 스펙트럼입니다. 상황에 따라 여러 코딩 솔루션을 '올바른' 것으로 볼 수 있습니다. 중요한 것은 계속 배우고, 테스트하고, 디지털 세계를 모든 사람에게 더 개방적으로 만들기 위해 노력하는 것입니다.