왜 ARIA인가?

ARIA란?

보다 정확히 말하면 WAI-ARIA라고 하는데, Web Accessibility Initiative - Accessible Rich Internet Applications의 약자다. 

웹 콘텐츠와 웹 어플리케이션(그 중에서도 특히 Ajax와 JavaScript를 사용하여 개발한 것들)을 제작할 때, 장애인(이를테면 screen reader 등을 이용하는)을 위한 접근성 향상 방법을 정의한 것이다(MDN 참조). 

웹 개발자는 native HTML로는 제어할 수 없는 accessibility 이슈를 WAI-ARIA를 통해 관리할 수 있다. 즉 html element가 accessibility tree로 표현되는 방식을 WAI-ARIA를 이용해 수정하고(외관 상의 차이는 전혀 없이!), screen reader 등의 도움을 받는 이용자들에게 추가적인 정보를 제공하도록 할 수 있다. native HTML 코드에 semantic 요소들을 추가하는 과정이다.

다음의 코드들을 살펴보자.

1)

<label>

<input type="checkbox">

Receive promotional offers

</label>

위의 코드는 이름이 "Receive promotional offers"이고 role이 "checkbox"인 체크박스를 생성하고, 만약 체크되어 있다면 그 checkbox의 state는 "checked" 일 것이다.

2)

<div role="checkbox"

aria-checked="true">

Receive promotional offers

</div>

위의 코드는 앞서 작성한 코드와 외견상 똑같다. 하지만 Accessibility Tree 상으로는 차이가 생긴다. 즉 "기본 DOM + ARIA"을 통해, 개발자가 원하는 role과 state를 가진 node를 Accessibility Tree에 포함시킨 것이다. 또한 role="checkbox"가 의미하는 것은, 해당 element가 checkbox pattern을 따라야 한다고 assistive technology에게 알려주는 것이다. 만약 ARIA가 적용되지 않은 1번 코드를 screen reader를 통해 접근하면, 체크박스가 체크되었는지 아닌지 등의 유용한 정보를 얻어낼 수 없다.

주의) 키보드 상호작용은 굉장히 자주 사용되므로, custom widget을 만들 때 role attribute는 tabindex attribute와 항상 같은 곳에서 적용되어야 한다! 그래야만 설정된 role이 의도된 element에서 정확히 수행될 수 있다.

ARIA를 통해 바꿀 수 있는 것은 오직, "Accessibility Tree" 뿐이다! element의 외형, 동작, focusability, keyboard event handling 등등 다른 것은 아무것도 바뀌지 않는다.

위에서 제시된 체크박스 뿐만 아니라, 수많은 UI 패턴들을(기본 HTML에서 제공되지 않는 것 까지도!) ARIA를 통해 만들 수 있다. 

위와 같은 구조의 tree widget을 만든다고 하자. ARIA attribute를 적용해 다음과 같은 코드를 작성한다.

<ul role="tree">

<li role="treeitem" aria-expanded="true">

Accessibility course

</li>

<ul role="group">

<li role="treeitem" aria-expanded="false">

Introduction

</li>

<li role="treeitem" aria-expanded="false">

Focus

</li>

// ...

"tree", "treeitem" 등의 role attribute들이 사용되었다. 이 외에도 수많은 ARIA role 및 State & property들이 존재하는데, MDN 문서와 ARIA 1.1 roles (draft)를 참조하자.

https://www.w3.org에서 'radio' role에 대한 설명은 다음과 같이 되어있다.

표를 보면 superclass role이 input이므로, "radio" role은 "input" role으로부터 property들을 전부 상속받는 것이며, 상속받은 States & Properties를 표에서 확인할 수 있다. 중요한 것은, 그 중 Required States and Properties라고 표시 된 "aria-checked"는 반드시! 적용해야 한다.

더불어 WAI-ARIA Authoring Practices 1.1에 가면, ARIA attribute를 적용할 때 알아야 할 각종 디자인 패턴도 확인할 수 있다.

(lesson5-semantics-aria/06-radio-group/radiogroup.js 파일 참조)

ARIA 레이블과 관계

Google Developers 참조

ARIA는 element에 label과 description을 추가하는 몇가지 매커니즘을 제공한다. ARIA는 Accessible Label과 description text를 더할 수 있는 유일한 방법이다. 관련하여 사용할 property에는 세 가지가 있다.

aria-label    /    aria-labelledby    /    aria-describedby

1. aria-label

텍스트 대신 그래픽을 사용하는(ex. 버튼) 요소의 목적을 시각적으로 표시할 때 aria-label 속성을 사용할 수 있다. 하지만 이미지만으로 목적을 표시하는 버튼과 같은 요소들을 인식할 수 없는 사용자를 위해서, 다른 방법으로 요소의 목적을 명확히 표시해야만 한다. 이를 위한 것이 바로 aria-label이며, accessible label로 string을 직접 사용할 수 있도록 한다. 

aria-label은 label 요소처럼 다른 네이티브 labeling 메커니즘을 모두 무시하는데, 예를 들어, button에 text 콘텐츠와 aria-label이 모두 있는 경우 aria-label 값만 사용된다.

2. aria-labelledby

aria-labelledby를 사용하면 어떤 요소의 label로서 DOM에 있는 다른 요소의 ID를 지정할 수 있다.

label요소와의 주요 차이점은 다음과 같다.

1. aria-labelledby는 label 지정 가능한 요소 뿐 아니라 어떤 요소에든 사용할 수 있다.
2. label 요소는 자신이 label을 지정하는 대상을 참조하지만, aria-labelledby의 경우에는 관계가 뒤바뀐다. 즉, label을 지정하는 대상이 label을 지정하는 주체를 참조한다.
3. 한 label 요소만 label 지정 가능한 요소와 연결할 수 있지만, aria-labelledby는 IDREF 목록을 선택하여 여러 요소에서 label을 작성할 수 있다. label은 IDREF가 지정되는 순서대로 연결된다.
4. aria-labelledby를 사용하여 숨겨져 있거나 접근성 트리에 없는 요소를 참조할 수 있다. 예를 들어, label을 지정하려는 요소 옆에 숨겨진 span을 추가하고 aria-labelledby로 참조할 수 있다.
5. 하지만 ARIA는 접근성 트리에만 영향을 주므로, aria-labelledby를 사용하면 label 요소를 사용할 때처럼 친숙한 label 클릭 동작을 구현할 수는 없다.

중요한 점은, aria-labelledby가 한 요소에 대한 다른 모든 이름 소스를 재정의한다는 점이다. 예를 들어, 어떤 요소에 aria-labelledby와 aria-label이 모두 있거나, aria-labelledby와 native HTML label이 있는 경우에는 aria-labelledby label이 항상 우선한다.

ARIA 관계

관계 속성은 DOM 관계와는 무관하게, 페이지에 있는 요소들 사이의 의미 체계의 관계를 생성한다. aria-labelledby의 경우, '이 element가 저 element에 레이블을 지정한다'는 의미이다.

ARIA 사양에는 8가지 관계 속성이 나와 있는데, 그 중 6가지인 aria-activedescendant, aria-controls, aria-describedby, aria-labelledby, aria-owns는 하나 또는 그 이상의 element를 참조하여 페이지에 있는 element들 사이에 새로운 링크를 생성한다. 각각의 경우에 있어 그 링크의 의미와 사용자에게 표시되는 방식에 차이가 있다.

aria-owns

aria-owns는 가장 널리 사용되는 ARIA 관계 중 하나다. 이 속성을 사용하여 DOM에 있는 어떤 요소를 현재 요소의 하위 요소로 처리해야 한다고 assistive technology에 알려주거나, 기존 하위 요소를 다른 순서로 재정렬할 수 있다. 예를 들어, 외관 상으로는 어떤 팝업 하위 메뉴가 상위 메뉴 근처에 배치되어 있지만, 시각적 표시에 영향을 주므로 DOM 상위 항목의 하위 항목일 수는 없는 경우에는 aria-owns를 사용하여 특정 메뉴를 상위 메뉴의 하위 메뉴로 스크린 리더에 표시할 수 있다. 

aria-activedescendent

aria-activedescendant는 관련된 역할을 수행한다. 페이지 내부의 active element는 focus를 가진다. 마찬가지로, 요소의 active descendent 항목을 설정함으로써, 어떤 항목에 실제로 focus가 있을 때 그 항목의 자식 요소를 사용자에게 foucs 된 요소로 표시해야 함을 assistive technology에 알려줄 수 있다.

aria-describedby

aria-describedby는 aria-labelledby가 label을 제공하는 것과 같은 방식으로 accessible한 설명을 제공하며, aria-describedby는 DOM에서 숨겨지거나 assistive technology로부터 숨겨졌는지 여부와 상관없이 다른 방법으로는 보이지 않는 요소를 참조할 수 있다. 이는 assistive technology 사용자에게만 적용되든 모든 사용자에게 적용되든 상관없이, 사용자에게 추가적인 설명문이 필요할 때 유용한 기법이다.

일반적인 예로, 최소 비밀번호 요건을 설명하는 텍스트가 함께 제공되는 비밀번호 입력란이 있다. 이런 설명은 레이블과는 달리 사용자에게 표시될 수도, 표시되지 않을 수도 있다. 이런 설명에 액세스할지 선택권을 부여하거나, 다른 모든 정보 다음에 나오도록 하거나, 다른 내용이 먼저 그 자리에 표시되도록 할 수도 있다. 예를 들어, 사용자가 정보를 입력하면 입력 정보가 다시 에코되어 요소의 설명을 가로막을 수 있는데, 따라서 설명은 필수 정보가 아니라 보충 정보를 전달하기에 훌륭한 방법이며, 요소의 역할과 같이 더욱 중요한 정보를 전달하는 데 방해되지 않는다.

aria-posinset & aria-setsize

(상단 링크 참조)

콘텐츠 숨기기 및 업데이트

Google Developers 참조