WAI-ARIA
Web Accessibility Intiative
Accessible Rich Internet Applications
WAI-ARIA는 웹 페이지, 특히 동적 콘텐츠, Ajax, HTML, JS 및 관련 기술로 개발된 사용자
인터페이스 구성 요소의 접근성을 증가시키는 방법에 대해 규정한 W3C가 출판한 기술사양
역사
2008/09/15 - 작업 초안으로 SVG 1.2 Tiny가 WA-ARIA 지원을 추가함
2014/03/20 - WAI-ARIA 1.0은 완전한 W3C 권고안이 됨
RIA?
Rich Internet Applications
-
RIA는 웹 애플리케이션의 장점은 유지하며 기존 웹 브라우저 기반 인터페이스의 단점인
늦은 응답 속도, 데스크톱 애플리케이션에 비해 떨어지는 조작성 등을 개선하기 위한 기술의 통칭 -
별도의 설치없이 웹 브라우저 기반의 애플리케이션 배포 장점과 서버측 웹 서비스와의 연동
마크업 언어 기반의 선언적 애플맄이션 구성 등은 유지하며 데스크톱 애플리케이션과
대등한 사용자경험을 주는 것을 목표하는 기술 -
흔히 Adobe Flash 기반 플렉스나 MS Silverlight, 자바 FX 등 별도의 런타임 시스템을 가진
기술을 지칭하는 용어로 사용됨 -
Ajax, HTML5 등에 기반한 애플리케이션을 지칭하기도 함 (다소 모호하고 넓은 의미)
범위
ex
내비게이션 메뉴로써 링크목록을 식별할 수 있으며, 펼치기/접기 여부의 상태를 지시할 수 있음
-
웹 개발자들은 점차 서버의 처리 부담을 줄이기위해 혹은 보안에 민감한 데이터를 처리할 때
드는 암호화 소요를 줄일 수 있다는 장점으로 인해 클라이언트 사이트 스크립트를 사용하여
HTML만으로는 만들 수 없는 UI 컨트롤을 만듬 -
이런 RIA에서 특정 UI나 콘텐츠 업데이트들은 장애가 있는 사용자들, 특히 스크린리더 사용자,
마우스나 기타 포인팅 장치를 사용할 수 없는 사용자에게는 접근이 되지 않을 수도 있음 -
때문에 WAI-ARIA는 역할, 속성, 상태 정보를 동적 웹 애플리케이션에 추가함으로써 웹페이지가
스스로를 정적문서보다는 애플리케이션으로 선언할 수 있게 함 -
ARIA는 웹 애플리케이션, 웹 브라우저, 보조기술, 접근성 평가 도구의 개발자들이 사용하도록 고안됨
-
WAI-ARIA는 UI와 동적 컨텐츠를 더욱 잘 접근할 수 있도록 만들기 위해 시멘틱과 기타
메타데이터를 HTML 콘텐츠에 추가하는 방식을 의미함 -
원래는 HTML의 접근성 문제를 해결하기 위해 개발되었으나 WAI-ARIA는 HTML에만 국한되어
사용되지는 않음, SVG 등 다른 마크업 언어에도 사용할 수 있음
ARIA 기본 원칙
1. 역할(role)은 약속이다
해당
<div>의 작성자가 버튼에 기대되는 키보드 인터랙션을 제공하는 JS도 구현했다는 약속
<div role="button">Place Order</div>-
HTML 입력 요소와 달리 ARIA 역할(role)은 브라우저가 키보드 동작이나 스타일링을 제공하지 않음
-
이런 역할의 약속을 이행하지 않고 사용하는 것은 주문을 빼먹고 쇼핑 카트를 비우는 "주문하기" 버튼을 만드는 것과 유사함
-
이 지침의 목표 중 하나는 각 ARIA역할에 대해 기대되는 동작을 정의하는 것
2. ARIA는 은폐와 강화를 통해 힘과 위험 모두를 창출할 수 있다
ARIA의 힘
일부 ARIA는 가면과 같이 원래의 의미나 콘텐츠를 완전히 감추거나 덮어씌움
<a role="menuitem">보조 기술 사용자는 이 엘리먼트를 링크가 아니라 메뉴의 항목으로 인지합니다.</a>
<a aria-label="보조 기술 사용자는 링크 텍스트가 아니라 이 aria-label의 콘텐트만을 인식할 수 있습니다">링크 텍스트</a>또 다른 일부 ARIA는 멜빵이나 벨트같이 원본 콘텐츠에 필수적인 지원을 제공하는 의미를 추가함
<button aria-pressed="false">Mute</button>-
UI 요소들의 의미와 목적에 대해 필요한 정보 보조 기술을 접근성 의미론이라고 하는데, 보조기술의 관점에서 ARIA는 작성자에게 보조기술이 달리 확실하게 추론 할 수 없을 중요한 접근성 의미론으로 HTML과 SVG 요소를 꾸밀 수 있는 능력을 제공함
-
작성자가 보조 기술들이 확실하게 해석할 수 있는 방법으로 거의 모든 UI를 기술할 수 있게 하기에 보조 기술 사용자에게 컴포넌트를 접근 가능하게 할 수 있음
ARIA의 위험
작성자가 부주의하게 접근성의미를 덮어쓸 수도 있음
<table role="log">
<!--
보조 기술 사용자가 표로 인식하지 못하는 표.
log 역할(role)은 브라우저에게 이것이 표가 아니라 기록이라고 알립니다.
-->
</table>
<ul role="navigation">
<!-- 이것은 목록이 아니라 navigation 영역 입니다. -->
<li><a href="uri1">nav link 1</li>
<li><a href="uri2">nav link 2</li>
<!-- 오류! 위 목록 항목들은 목록에 없습니다! -->
</ul>3. ARIA의 대표적 3가지 기능
1. 역할(role)
특정 요소의 기능을 정의하는 것으로 페이지의 Search 영역인지, Nav영역인지, 특정 Section의 제목(Heading)인지 등의 명확한 기능을 부여할 수 있음
- Role의 종류
- Document Structure Role (문서구조 역할)
- Abstract Role (추상 역할)
- Landmark Role (랜드마크 역할)
- Widget Role (위젯 역할)
ex
버튼 컴포넌트를 제작시<a>tag를 사용하는 경우<a href="#" onclick="playApp()" role="button">재생</a>role="button"이 없는 경우 스크린리더의 해석 : 버튼을 링크의 용도로 이해
role="button"이 있는 경우 스크린리더의 해석 : 버튼의 용도로 이해
2. 속성(property)
요소가 기본적으로 갖고 있는 특징이나 상황을 의미함
form의 입력 상자가 읽기전용인지, 필수 항목인지, 사용자 입력에 대해 자동완성(Auto Complete)기능을 지원할 것인지, 드래그가 가능한지, 팝업이 뜨는지, 업데이트된 정보가 있는지 등의 상황을 사용자가 인지할 수 있도록 함
ex
회원가입 시 사용자 ID과 PW를 입력받아야하며 이 둘은 필수항목
때문에 스크린리더 등의 보조기기들이 이를 "필수항목"으로 인식하도록해야함<input type="button" id="user-id" aria-required="true">
3. 상태(state)
요소의 현재 상태를 의미하며 상황의 변화에 따른 값을 가진다
- expended : 메뉴가 펼쳐진 상태인가?
- invaild : 적절하지 못한 값이 입력되었는가?
- hidden : 콘텐츠가 숨김 상태인가?
ex
앱에서 제공되는 메뉴가 하위메뉴를 포함하고 있는 경우
하위 메뉴가 접힌상태인지, 펼쳐진 상태인지 스크린리더 등의
보조기기 사용자들에게 이러한 정보를 제공할 필요가 있으며 아래와 같이 작성할 수 있다<li id="menu" role="treeitem" aria-expended="true">[메뉴가 열린상태] <a>WAI-ARIA</a> <ul id="submenu" role="group"> <li id="menu" role="treeitem" aria-expended="false">[메뉴가 접힌상태]</li> </ul> </li>
- 주의사항
aria-hidden의 경우 시각적으로만 숨겨지는 것이 아니라, 의미적으로도 숨겨지기 때문에 사용자에게 시각적으로만 보이지 않게 할 경우에는aria-hidden을 사용해서는 안됨
설계패턴과 위젯
WAI-ARIA의 역할(role), 상태(state), 속성(property)을 적용하고 키보드 지원을 구현하여 일반적인 RIA 패턴과 위젯을 접근 가능하게 만드는 것이 설계패턴
아코디언
아코디언, 경고, 경고 및 메세지 대화상자, 브레드크림, 버튼, 캐러셀, 체크상자 등 많은 위젯에 대한 설계패턴이 존재하지만 너무 방대하기에 아코디언만 예시로 설명함
- 아코디언은 각각 콘텐츠 섹션을 나타내는 제목, 콘텐츠 snippet, 또는 섬네일을 포함하는 수직으로 샇여있는 인터렉티브 제목 집합을 의미함
- 제목은 연관된 콘텐츠 섹션을 사용자에게 나타내거나 숨길 수 있는 컨트롤로 기능함
- 일반적으로 단일 페이지에서 콘텐츠의 여러 섹션들을 표현할 때 스크롤 할 필요성을 줄이기위해 사용됨
아코디언 헤더
콘텐츠 섹션을 노출시키고 일부 구현에서는 숨기는 컨트롤 역할을 하는 콘텐츠 섹션에 대한 레이블이나 콘텐츠 섹션을 나타내는 썸네일
코디언 패널
아코디언 헤더와 연관된 콘텐츠 섹션
1-1. 키보드 인터렉션
1. Enter or Space
- 접혀있는 패널에 대한 아코디언 헤더에 있다면 관련된 패널을 확장시킴
- 동작이 항상 단 하나의 패널만 확장되는 것을 허용하며 다른 패널이 확장되어 있는 경우 그 패널을 축소 시킴
- 확장되어 있는 패널에 대한 아코디언 헤더에 있고 동작이 축소를 지원한다면 패널을 축소시킴
- 일부 동작은 항상 하나의 패널이 확장되어 있고 하나의 패널만이 확장하도록 요구함
- 위의 경우에는 축소 기능을 지원하지 않음
2. Tab
- focus를 다음 focusable한 엘리먼트로 이동시킴
- 아코디언 내의 모든 focusable한 엘리먼트는 페이지
Tab순서에 포함됨
3. Shift + Tab
- focus를 이전 focusable한 엘리먼트로 이동시킴
- 아코디언 내의 모든 focusable한 엘리먼트는 페이지
Tab순서에 포함됨
4. Down Arrow(선택적)
- focus가 아코디언 헤더에 있다면 다음 아코디언 헤더로 focus를 이동시킴
- focus가 마지막 아코디언 헤더에 있는 경우 아무동작도 취하지 않거나 첫번째 아코디언 헤더로 focus를 이동시킴
5. Up Arrow(선택적)
- focus가 아코디언 헤더에 있다면 이전 아코디언 헤더로 focus를 이동시킴
- focus가 첫번째 아코디언 헤더에 있는 경우 아무동작도 취하지 않거나 마지막 아코디언 헤더로 focus를 이동시킴
6. Home(선택적)
- focus가 아코디언 헤더에 있다면 첫번째 아코디언 헤더로 초점을 이동시킴
7. End(선택적)
- focus가 아코디언 헤더에 있다면 마지막 아코디언 헤더로 초점을 이동시킴
1-2. WAI-ARIA 역할(role), 상태(state), 속성(property)
- 각 아코디언 헤더의 제목은
button역할(role)을 가진 요소에 포함됨 - 각 아코디언 헤더
button은 페이지의 정보 구성에 적절한aria-level로 정해진 값을 가지는heading역할(role)을 가진 엘리먼트로 감싸짐- 네이티브 호스트 언어가 HTML 헤딩 태그같이 암묵적인
heading과aria-level을 가지고 있는 경우 네이티브 호스트 언어 요소가 사용될 수 있음 button요소는heading요소 내의 유일한 요소, 즉 보여지도록 유지되는 다른 요소가 있다면heading요소에 포함되지 않음
- 네이티브 호스트 언어가 HTML 헤딩 태그같이 암묵적인
- 아코디언 헤더와 연관된 아코디언 패널이 보여지는 상태라면, 헤더
button요소는true로 설정된aria-expanded를 가짐, 보여지지 않는 상태라면aria-expanded는false로 설정됨 - 아코디언 헤더
button요소는 아코디언 패널 콘텐츠를 포함하는 요소의 ID로 설정된aria-controls를 가짐 - 아코디언 헤더와 연관된 아코디언 패널이 보이는 상태이고 아코디언이 패널축소를 허용하지 않는다면, 헤더
button요소는true로 설정된aria-disabled를 가짐 - 선택적으로 패널 콘텐츠에 대한 컨테이너를 제공하는 각 요소는
region역할(role)과 패널의 가시성을 제어하는 버튼을 가리키는 값을 가진aria-labelledby를 가짐- 랜드마크 영역을 급증하게 만드는 상황에서는 예를 들어 동시에 확장될 수 있는 거의 6개 이상의 패널들을 포함하는 아코디언의 경우
region역할(role)을 사용하는 것을 지양하라 region역할(role)은 패널이 헤딩 요소를 포함하거나 중첩된 아코디언이 포함된 경우 스크린리더 사용자가 구조를 인식하는데에 특히 유용함
- 랜드마크 영역을 급증하게 만드는 상황에서는 예를 들어 동시에 확장될 수 있는 거의 6개 이상의 패널들을 포함하는 아코디언의 경우
랜드마크
- ARIA 랜드마크 역할(role)은 웹 페이지의 구성과 구조를 식별하는 강력한 방법을 제공함
- 페이지의 섹션을 분류하고 레이블을 지정함으로써, 레이아웃을 통해 시각적으로 전달되는 구조 정보를 프로그래밍 방식으로 나타낼 수 있음
- 스크린리더는 페이지의 중요한 부분으로의 키보드 탐색을 제공하는데 랜드마크 역할(role)을 활용함
- 랜드마크 영역은 "스킵 링크"의 대상으로도 사용될 수 있고, 브라우저 확장을 통해 향상된 키보드 탐색으로 사용될 수 있음
HTML 섹션화 요소
- 몇몇 HTML 섹션화 엘리먼트는 자동으로 ARIA 랜드마크 영역을 생성함
- 따라서 보조 기술 사용자에게 페이지의 논리적 시야를 제공하려면, HTML 섹션화 엘리먼트 사용의 영향을 이해하는 것이 중요함
HTML 섹션화 엘리먼트에 대한 기본 랜드마크 역할(role)
| HTML 엘리먼트 | 기본 랜드마크 역할(role) |
|---|---|
aside | complementary |
header | body엘리먼트의 컨텍스트에 있는 경우 banner |
footer | body엘리먼트의 컨텍스트에 있는 경우 contentinfo |
main | main |
nav | navigation |
section | aria-labelledby나 aria-label을 사용하여 접근 가능한 이름을 가지는 경우 region |
랜드마크 설계 일반 원칙
랜드마크 영역 중 하나에 페이지의 모든 인식가능한 콘텐츠를 포함시키고
각 랜드마크 영역에 의미론적(semantically)으로 유의미한(meaningful) 역할을 부여하는 것은 보조 기술 사용자가 그들의 필요와 관련된 정보를 습득할 수 있도록하는 효과적인 방법임
1단계: 논리적 구조 식별
- 디자이너가 일반적으로 정렬과 간격을 이용하여 시각적으로 표시한 콘텐츠의 인식 가능한 영역으로 페이지를 쪼갠다
- 필요에 따라 영역이 논리적 하위 영역 안으로 추가 정의될 수 있다
- 하위 영역의 예는 포털 애플리케이션의 포틀릿이다
- 포틀릿: 복합페이지의 컨텍스트내에 결집되기 위해 특별히 고안된 웹 컴포넌트
- 통상 많은 포틀릿들은 포탈페이지의 단일 요청(request)으로 호출됨
- 각 포틀릿은 마크업 조각을 생성함
- 각 포틀릿은 다른 포틀릿의 마크업과 결합되어 전체 포탈페이지 마크업이 됨
2단계: 각 영역에 랜드마크 역할(role)담당
- 영역 내의 콘텐츠 유형에 따라 랜드마크 역할(role)을 할당
banner,main,complementary,contentinfo랜드마크는 최상위 랜드마크여야 함- 랜드마크 역할(role)은 표시되는 정보의 부모/자식 관계를 식별하기 위해 중첩될 수 있음
3단계: 영역에 레이블 지정
- 한 페이지에 특정 랜드마크 역할(role)이 두번이상 사용될 경우, 각 랜드마크 인스턴스에 고유한 레이블을 제공하라
- 랜드마크의 여러 인스턴스에 동일한 레이블을 제공하는 것이 유리할 수 있는 보기 드문상황이 있다
- 각 인스턴스의 목적 및 내용이 동일한 경우
- 예를 들어 큰 검색 결과표가 동일한 페이징(pagination)컨트롤 두 세트를 가지므로
- 각각 표 위, 표 아래에 하나씩
- 각 세트는 '검색 결과'라고 레이블이 지정된 탐색 영역안에 있는 것
- 이 경우, 두 인스턴스를 구별하는 추가정보를 레이블에 추가하는 것은 주의가 산만해질 수 있는 역효과를 불러올 수 있다
- 페이지에 랜드마크가 오직 하나만 사용된다면 레이블은 필요하지 않을 수 있음
- 영역이 헤딩 엘리먼트(
h1~h6...)로 시작한다면,aria-labelledbyattribute를 사용하여 영역에 대한 레이블로 사용될 수 있음 - 영역에 레이블이 필요하고 헤딩 엘리먼트를 가지지 않는다면,
aria-labelattribute를 사용하여 레이블을 제공하라 - 랜드마크 역할(role)을 레이블의 일부로 사용하지마라
- 예를 들어 '사이트 내비게이션'이라는 레이블을 가진 navigation 랜드마크는 스크린리더에 의해 '사이트 내비게이션 내비게이션'이라고 낭독될 것임
- 레이블은 단순히 'Site'여야함
랜드마크 영역
Banner, Complementary, Contentinfo, Form, Main, Navigation, Region, Search 등이 있다
- 위의 예시들은 각각 다른 역할이 있으며 HTML기법이나 ARIA기법으로 랜드마크를 정의한다
