대부분의 개발자는 최신 웹인 HyperText Markup Language (HTML)의 표준 마크업 언어에 익숙합니다. 그러나 액세스 가능한 리치 인터넷 애플리케이션 (ARIA)(이전 명칭: WAI-ARIA)은 무엇이고 어떻게 사용하는지, 언제 그리고 언제 사용하는지를 모르는 것은 잘 알지 못할 수 있습니다.
HTML 및 ARIA는 특히 스크린 리더와 같은 보조 기술 (AT)의 경우 디지털 제품의 접근성을 높이는 데 중요한 역할을 합니다. 둘 다 콘텐츠를 점자 또는 TTS (텍스트 음성 변환)와 같은 대체 형식으로 변환하는 데 사용됩니다.
ARIA의 간략한 역사와 ARIA가 중요한 이유, ARIA를 언제 어떻게 사용하는 것이 가장 좋은지 검토해 보겠습니다.
ARIA 소개
ARIA는 인터넷을 통제하고 규제하는 중요한 W3C (World Wide Web Consortium)의 일부인 웹 접근성 이니셔티브 (WAI) 그룹이 2008년에 처음 개발했습니다.
ARIA는 진정한 프로그래밍 언어는 아니지만 HTML 요소에 추가하여 접근성을 높일 수 있는 속성의 집합입니다. 이러한 속성은 최신 브라우저에 있는 접근성 API를 통해 역할, 상태, 속성을 보조 기술에 전달합니다. 이 통신은 접근성 트리를 통해 이루어집니다.
'액세스 가능한 리치 인터넷 애플리케이션 제품군인 WAI-ARIA는 장애인이 웹 콘텐츠와 웹 애플리케이션에 보다 쉽게 액세스할 수 있는 방법을 정의합니다. 특히 HTML, 자바스크립트, 관련 기술로 개발된 동적 콘텐츠와 고급 사용자 인터페이스 컨트롤에 도움이 됩니다."
WAI 그룹
접근성 트리
ARIA는 부정확하거나 불완전한 코드를 수정하여 접근성 트리의 일부를 변경, 노출 및 강화하여 AT 사용자에게 더 나은 환경을 제공합니다.
접근성 트리는 브라우저에서 만들며 표준 문서 객체 모델 (DOM) 트리를 기반으로 합니다. DOM 트리와 마찬가지로 접근성 트리에도 모든 마크업 요소, 속성, 텍스트 노드를 나타내는 객체가 포함됩니다. 접근성 트리는 보조 기술이 이해할 수 있는 표현을 제공하기 위해 플랫폼별 접근성 API에서도 사용됩니다.
ARIA 자체는 요소의 기능이나 시각적인 모양을 변경하지 않습니다. 즉, ARIA가 있는 디지털 제품과 ARIA가 없는 디지털 제품의 차이점은 AT 사용자만 알아차릴 수 있습니다. 즉, 요소에 가능한 한 쉽게 액세스할 수 있도록 적절한 코드를 적용하고 스타일을 변경할 책임은 전적으로 개발자에게 있습니다.
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>, <header>, <footer>, <aside>, <nav> 등의 랜드마크 요소와 hidden, required 등의 속성을 추가하는 등 큰 변화가 있었습니다. 이러한 새로운 HTML5 요소 및 속성 및 향상된 브라우저 지원으로 인해 ARIA의 특정 부분이 덜 중요해졌습니다.
브라우저에서 ARIA와 동등한 암시적 역할을 가진 HTML 태그를 지원하는 경우 일반적으로 요소에 ARIA를 추가할 필요가 없습니다. 하지만 ARIA에는 여전히 어떤 버전의 HTML에서도 사용할 수 없는 많은 역할, 상태 및 속성이 포함되어 있습니다. 당분간은 이러한 속성을 유용하게 사용할 수 있습니다.
이것은 궁극적인 질문으로 이어집니다. 'ARIA를 언제 사용해야 합니까?' 다행히 WAI 그룹은 요소의 접근성을 개선하는 방법을 결정하는 데 도움이 되도록 ARIA의 5가지 규칙을 개발했습니다.
규칙 1: ARIA를 사용하지 말 것
네, 맞습니다. 요소에 ARIA를 추가한다고 해서 기본적으로 접근성이 높아지는 것은 아닙니다. WebAIM Million 연례 접근성 보고서에 따르면 ARIA를 사용하는 홈페이지보다 감지된 오류가 평균 70% 더 높은 것으로 나타났습니다. 이는 주로 ARIA 속성이 잘못 구현되었기 때문입니다.
이 규칙에는 예외가 있습니다. ARIA는 HTML 요소에 접근성이 지원되지 않는 경우 필요합니다. 디자인에서 특정 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"을 추가할 수 있습니다. 키보드 포커스 순서 문제를 방지하려면 가능하면 양의 정수가 포함된 탭 색인을 사용하지 마세요.
<span role="button" tabindex="1">Submit</span>
<span role="button" tabindex="0">Submit</span>물론 가능하면 이 경우 실제
<button> 요소를 사용하세요.
규칙 4: 포커스 가능 요소를 숨기지 말 것
tabindex= "0"이 있는 요소를 포함하여 포커스가 있어야 하는 요소에는 role= "presentation" 또는 aria-hidden= "true"를 추가하지 마세요. 이러한 역할/상태를 요소에 추가하면 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 요소의 대체 방법으로 사용할 수 있습니다.
물론 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/브라우저 지원, 변환 필요 여부, 환경 제약 조건, 기존 코드, 사용자 환경설정을 포함하되 이에 국한되지 않는 여러 사항에 주의해야 합니다. 약간의 코딩 지식은 잘못 사용할 경우 해를 끼치거나 짜증 나게 할 수 있습니다. 코드는 단순하게 유지해야 합니다.
이러한 경고 외에도 디지털 접근성은 '전부 아니면 전무' 조건이 아닙니다. 이와 같은 모호한 영역을 허용하는 스펙트럼입니다. 상황에 따라 여러 코딩 솔루션이 '정답'으로 보일 수 있습니다. 중요한 것은 계속 학습하고 테스트하며 모두에게 더 열린 디지털 세상을 만들기 위해 노력하는 것입니다.
학습 내용 확인하기
ARIA 및 HTML에 대한 지식 테스트
다음 중 액세스 가능한 버튼을 빌드하기 위한 권장사항은 무엇인가요?
<div id="saveChanges" aria-role="button" aria-pressed="false" tabindex="0">Go to shop</div><a id="saveChanges" aria-label="Some awesome article title">Go to shop</a><button id="saveChanges" type="button">Go to shop</button>