이 글은 웹 접근성을 증가시키는 방법에 대해 W3C가 규정한 WAI-ARIA에 대한 글입니다.
현재의 웹은 변화하고 있습니다. 페이지 중심의 정적이던 사이트들은 동적으로 변화하고 이쏙, 데스크톱 웹 어플리케이션들이 JS와 AJAX를 중점으로 사용하며 제작되고 있습니다. 이러한 변화는 사용성과 반응형 향상에는 극적으로 도움을 주지만, 또 다른 많은 일반 유저들과 장애를 가진 유저들에게는 접근성 격차로 다가오는 제약이 될 수 있습니다. JavaScript는 스크린리더 같은 보조기술을 사용하는 유저들이 접근하기 힘들다고 알려져 있었습니다.
HTML의 명세가 나왔을 때, 태그에 관한 자세한 설명이 주어지지 않았고, 개발자들은 보통 <div>
나 <span>
같은 것들을 활용하여 개발하였습니다. 이런 시대의 결과로 데스크톱 위젯들은 충분한 정보를 제공하지 못하였으며 이는 기술적으로 전혀 도움이 되지 않았습니다. 동적 콘텐츠는 이유가 어떻든 스크린을 보지 못하는 사람에게 문제가 되었습니다. 주식 시세 표시 위젯, 트위터 라이브 피드 갱신, 프로그레스바 같은 것들을 보조공학기술(AT)로 인식하지 못하는 경우가 많았습니다. ARIA가 필요한 이유가 여기에 있습니다.
WAI-ARIA란 Web Accessibility Initiative – Accessible Rich Internet Applications의 약자로 웹 페이지, 특히 동적 콘텐츠, 그리고 Ajax, HTML, 자바스크립트 및 관련 기술로 개발된 사용자 인터페이스 구성 요소의 접근성을 증가시키는 방법에 대해 규정한 W3C가 출판한 기술 사양입니다.
Accessible Rich Internet Applications(WAI-ARIA) 는 W3C의 Web Accessibility Initiative에서 제작하고, 스크린리더 같은 보조기기에서 필요한 정보들을 추가하는 방법을 제공합니다. ARIA는 마크업에서 특별한 속성을 추가하여 개발자들이 위젯의 디테일한 정보를 제공할 때 사용합니다. 동적 웹 어플리케이션에서 찾을 수 있는 데스크톱 스타일 콘트롤과 표준 HTML 태그 사이에 있는 차이를 채우기 위해, ARIA는 친숙한 UI 위젯의 동작 상태(state)와 역할(Role)에 대한 설명을 제공합니다.
ARIA는 다른 타입의 속성 세개 roles, states, properties를 분할하여 정의하고 있습니다. Roles는 slider, menu bar, dialog와 같은 HTML4에서 사용하지 못하는 위젯을 설명합니다. Properties는 드래그가 가능하다는 것이나, 요소가 필요하다는 것이나, 팝업이 뜨는 것과 같은 위젯의 특징에 대해 설명합니다. State는 요소의 현재 상태에 대해 설명합니다. 이 정보는 보조기기에서 요소의 접근이 불가하거나, 숨겨져 있는 상태라는 것을 명시합니다.
ARIA 속성은 브라우저에서 자동으로 해석되도록 설계되어 운영 체제의 기본 접근성 API로 변환됩니다. ARIA가 존재하면 보조 기술은 데스크톱과 동일한 방식으로 사용자 지정 JavaScript 컨트롤을 인식하고 상호 작용할 수 있습니다. 보조 기술 사용자는 웹 기반 애플리케이션을 사용할 때 데스크톱 애플리케이션의 작동 방식에 대한 모든 지식을 적용할 수 있기 때문에 이전 세대의 웹 애플리케이션보다 훨씬 더 일관된 사용자 환경을 제공할 수 있습니다.
요소의 용도를 변경하고 ARIA 역할, 상태 또는 속성을 추가하여 액세스할 수 있도록 하는 대신, 필요한 의미론 및 동작을 기본으로 하는 네이티브 HTML 요소 또는 속성을 사용할 수 있다면 사용하자
하지만 이것이 가능하지 않은 경우가 있습니다.
굳이 변경해야 하는 경우가 아니라면 기본 의미를 바꾸지 마십시오.
개발자가 탭으로 제목을 작성하려는 경우
<h2 role=tab>heading tab</h2>
<div role=tab><h2>heading tab</h2></div>
모든 대화형 ARIA 컨트롤은 키보드에서 사용할 수 있어야 합니다.
사용자가 클릭하거나 탭하거나 끌어서 놓거나 미끄럼 또는 스크롤할 수 있는 위젯을 만드는 경우, 사용자는 위젯으로 이동하여 키보드를 사용하여 동등한 작업을 수행할 수도 있어야 합니다.
해당되는 경우 표준 키 입력 또는 키 입력 조합에 응답하도록 모든 대화형 위젯을 스크립팅해야 합니다.
예를 들어, role= 버튼을 사용하는 경우 요소는 포커스를 받을 수 있어야 하며 사용자는 입력(WIN OS) 또는 반환(MAC OS) 키와 공간 키를 모두 사용하여 요소와 연결된 작업을 활성화할 수 있어야 합니다.
포커스가 가능한 요소에 role="presentation" 또는 aria-hidden="true"를 사용하지 마십시오.
이 두 가지 중 하나를 초점 있는 요소에 사용하면 일부 사용자가 아무것도 아닌 곳에 포커싱하게 되는 결과를 초래합니다.
<button role=presentation>press me</button>
<button aria-hidden="true">press me</button>
둘다 하지 말아야할 것
<div aria-hidden="true">
<button>press me</button>
</div>
표시되는 대화형 요소에 aria-hidden을 적용하면 대화형 요소가 숨겨지므로 포커싱 되는 요소에 사용하면 안됨!
button {opacity:0}
<button tabindex="-1" aria-hidden="true">press me</button>
대화형 요소를 보거나 상호작용할 수 없고, 포커스가 많지 않으면
aria-hidden
을 사용해도 된다.
모든 대화형 요소에는 액세스할 수 있는 이름이 있어야 합니다.
대화형 요소는 Accessibility API 액세스 가능 이름(또는 동등한) 속성에 값이 있는 경우에만 액세스할 수 있는 이름을 가집니다.
예를 들어, 아래 코드 예제의 입력 유형 = 텍스트에는 '사용자 이름'이라는 레이블이 표시되지만 액세스할 수 있는 이름은 없습니다.
user name <input type="text">
or
<span>user name</span> <input type="text">
이에 비해 아래 코드 예제에서 입력 유형 = 텍스트는 '사용자 이름'이라는 레이블과 액세스 가능한 이름을 가집니다. 이 예제에서는 입력 요소가 레이블 가능 요소이며 레이블 요소를 올바르게 사용하여 레이블 텍스트를 입력과 연결하기 때문에 액세스할 수 있는 이름을 가집니다.
<!-- Note: use of for/id or wrapping label around text
and control methods will result in an accessible name -->
<input type="text" aria-label="User Name">
or
<span id="p1">user name</span> <input type="text" aria-labelledby="p1">
이외에도 ARIA의 규칙은 다양합니다 더 많은 ARIA규칙을 알고싶다면
Using ARIA 사이트 방문을 추천드립니다.
다른 사이트에서 ARIA와 관련한 좋은 글이 있어서 가져왔습니다.
<a>
, <i>
, <span>
과 같이 <button>
이 아닌 태그로 구현된 사례가 많은데 만약, 개발요청과 같은 여러 가지 이유로 <button>
(혹은 <input type="button">
)이 아닌 요소에 버튼의 기능을 적용해야 한다면 role="button"을 사용하세요
role="button"을 적용한 요소가 포커스를 받을 수 없는 요소라면 tabindex="0" 적용 해야합니다.
<button>
은 enter, space 키에 대해서 click 이벤트가 트리거 됩니다. role="button"이 적용된 요소도 <button>
과 동일한 UI를 제공하기 위해 enter, space 키에 click이벤트와 같은 이벤트 핸들러를 적용해야 합니다.
좋아요, 재생, 음소거 등 토글 형태의(눌린 상태 또는 눌리지 않은 상태) <button>
에는 aria-pressed를 적용하세요. 스크린리더는 사용자에게 해당 요소를 버튼이 아닌 토글버튼이라고 읽어주며, 선택/미선택에 대한 상태 정보도 제공합니다.
버튼을 클릭하여 특정 영역을 확장하고 축소하는 UI에 aria-expanded를 사용하세요. 스크린 리더 사용자에게 버튼을 클릭하여 내용이 아래로 확장되거나 축소 될 수 있음을 알릴 수 있습니다. 또한, 현재 내용이 축소되었는지 확장되어 있는지 상태에 대한 정보까지 제공합니다.
form요소의 입력값에 대한 에러 메시지(유효성검사) 처럼 경고 역할을 하는 요소에 role="alert"을 사용하세요. 스크린 리더는 해당 요소가 화면에 나타나는 순간 DOM 위치와 상관없이 사용자에게 경고 메시지를 전달합니다.
다른 요소 위에 겹쳐나오는(예를 들어 position:absolute가 적용된 메뉴리스트) 하위메뉴를 제어하는 버튼에 aria-haspopup을 사용하세요. 스크린 리더 사용자에게 해당 요소가 하위메뉴를 포함하고 있다는(팝업될 수 있다는) 정보를 제공합니다.
1. 의미론적인 HTML요소를 사용하라
<div>Play video</div>
대신에
<button>Play video</button>
의미론적인 요소를 사용하면 다음과 같은 3가지의 장점이 있음
2. Text Content에서의 좋은 semantics 사용
<h1>My heading</h1>
<p>This is the first section of my document.</p>
<p>I'll add another paragraph here too.</p>
<ol>
<li>Here is</li>
<li>a list for</li>
<li>you to read</li>
</ol>
<h2>My subheading</h2>
<p>This is the first subsection of my document. I'd love people to be able to find this content!</p>
<h2>My 2nd subheading</h2>
<p>This is the second subsection of my content. I think is more interesting than the last one.</p>
나쁜 semantic 코드 예시
<font size="7">My heading</font>
<br><br>
This is the first section of my document.
<br><br>
I'll add another paragraph here too.
<br><br>
1. Here is
<br><br>
2. a list for
<br><br>
3. you to read
<br><br>
<font size="5">My subheading</font>
<br><br>
This is the first subsection of my document. I'd love people to be able to find this content!
<br><br>
<font size="5">My 2nd subheading</font>
<br><br>
This is the second subsection of my content. I think is more interesting than the last one.
3. 명확한 언어 사용(약어, 클래스명 등등)
4. 페이지 레이아웃을 테이블로 하지 말것(옛날에 주로 하던 방법)
이외에도 엄청나게 많은 향상 기법이 있음
Reference : 의미를 가진 HTML요소
참고사이트