ARIA 사용법

2.1 ARIA 사용의 첫 번째 규칙

필요한 의미와 동작이 이미 내장된 기본 HTML 요소 [HTML51] 또는 속성을 사용할 수 있다면, 요소의 목적을 바꿔 ARIA 역할, 상태, 속성을 추가하여 접근 가능하게 만드는 대신 그렇게 하십시오.

언제 이것이 불가능할 수 있는가?

• 해당 기능이 HTML [HTML51]에는 존재하지만, 구현이 안 되어 있거나, 구현되어 있어도 접근성 지원이 없는 경우
• 시각적 디자인 제약으로 인해 특정 기본 요소를 사용할 수 없을 때, 해당 요소를 원하는 대로 스타일링할 수 없는 경우
• 해당 기능이 현재 HTML에 없는 경우

2.2 ARIA 사용의 두 번째 규칙

정말 필요하지 않다면 기본 의미를 변경하지 마십시오.

예: 개발자가 탭인 헤딩을 만들고 싶을 때.

이렇게 하면 안 됩니다:

<h2 role=tab>heading tab</h2>     

이렇게 하십시오:

<div role=tab><h2>heading tab</h2></div>

2.3 ARIA 사용의 세 번째 규칙

모든 인터랙티브 ARIA 컨트롤은 키보드로 사용할 수 있어야 합니다.

사용자가 클릭, 탭, 드래그, 드롭, 슬라이드, 스크롤할 수 있는 위젯을 만든 경우, 사용자는 키보드로도 해당 위젯에 이동하고 동일한 동작을 수행할 수 있어야 합니다.

모든 인터랙티브 위젯은 상황에 따라 표준 키 입력 또는 키 조합에 반응하도록 스크립트 처리되어야 합니다.

예를 들어 role=button을 사용하는 경우 해당 요소는 포커스를 받을 수 있어야 하며, 사용자는 WIN OS의 enter 또는 MAC OS의 return, 그리고 space 키로 해당 동작을 수행할 수 있어야 합니다.

자세한 내용은 [wai-aria-practices-1.1]의 디자인 패턴과 위젯, 키보드 인터페이스 개발 섹션을 참고하세요.

2.4 ARIA 사용의 네 번째 규칙

포커스를 받을 수 있는 요소에는 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>

 button {opacity:0}

<button tabindex="-1" aria-hidden="true">press me</button>

2.5 ARIA 사용의 다섯 번째 규칙

모든 인터랙티브 요소는 접근 가능한 이름을 가져야 합니다.

인터랙티브 요소는 접근성 API의 accessible name(또는 동등한) 속성에 값이 있는 경우에만 접근 가능한 이름을 갖습니다.

예를 들면, 아래 코드 예제의 input type=text는 'user name'라는 표시 라벨은 있지만 접근 가능한 이름은 없습니다:

    user name <input type="text">

    또는

    <span>user name</span> <input type="text">
    

이 컨트롤의 MSAA accName 속성은 비어 있습니다:

아래 코드 예제의 input type=text는 표시 라벨 'user name' 및 접근 가능한 이름을 모두 가집니다. input 요소가 labelable element이고 label 요소를 사용하여 라벨 텍스트와 입력을 연결했기 때문입니다.

<!-- 참고: for/id 사용 또는 라벨 래핑으로 텍스트와 컨트롤을 연결하면 접근 가능한 이름이 생성됩니다 -->

<input type="text" aria-label="User Name">

또는

<span id="p1">user name</span> <input type="text" aria-labelledby="p1">

이 컨트롤의 MSAA accName 속성의 값은 "user name"입니다:

HTML label 요소와 labelable 요소

아래는 HTML에서 label을 사용하는 방법입니다. ARIA 위젯을 개발하는 경우 ARIA Authoring Practices Document를 참고하세요.

label 요소는 label이 기본 HTML labelable element를 참조하지 않는 이상, 커스텀 컨트롤의 접근 가능한 이름을 제공할 수 없습니다.

     <!-- HTML input 요소와 combox 역할 -->

      <label>
      user name <input type="text" role="combobox">
      </label>
    

이 컨트롤의 MSAA accName 속성의 값은 "user name"입니다:

div 요소는 어떤 역할이 할당되어 있어도 HTML labelable element가 아닙니다.

     <!-- HTML div 요소와 combox 역할 -->

      <label>
      user name <div  role="combobox"></div>
      </label>
    

이 컨트롤의 MSAA accName 속성은 비어 있습니다:

2.6 역할(role)을 추가하면 기본 의미에 어떤 영향이 있나?

ARIA 역할을 추가하면 기본 역할 의미를 접근성 트리에서 덮어써서, 접근성 API를 통해 보고됩니다. 그러므로 ARIA는 스크린 리더나 기타 보조기술에 보고되는 내용을 간접적으로 바꿉니다.

예를 들어, HTML 트리에서 다음 코드는:

<h1 role=button>text</h1>

접근성 트리에서는 이렇게 바뀝니다:

역할(role) 추가로 달라지지 않는 점

ARIA 역할을 추가해도 보조기술 이외의 사람들에게 해당 요소의 보이거나 동작이 달라지지 않습니다. 요소의 동작, 상태, 속성은 바뀌지 않고 기본 역할 의미만 영향을 받습니다.

예를 들어, HTML 트리에서 다음 코드는:

<button role=heading aria-level=1>text</button>

접근성 트리에서는 이렇게 바뀝니다:

하지만 이 요소는 여전히 누를 수 있고, 기본 탭 순서에 있으며, 버튼처럼 보이고, 눌렀을 때 연결된 동작도 실행됩니다. 그래서 버튼을 heading으로 바꾸는 것은 HTML5 적합성 오류입니다.

참고: 요소의 role을 바꿔도 role 자체에 동작, 속성, 상태가 더해지지는 않습니다. ARIA는 브라우저에서 보이거나 동작하는 방식을 바꾸지 않습니다. 예를 들어, 링크를 버튼처럼 동작하게 하려면 role=button만 추가하는 것으로는 부족하며, space 키 처리를 위한 키 이벤트 핸들러를 추가해야 합니다. 왜냐하면 기본 버튼은 enter키나 spacebar로도 활성화됩니다.

2.7 ARIA를 인라인에 추가할까, 스크립트로 추가할까?

ARIA 역할이나 aria-* 속성이 상호작용 동작을 위해 스크립트에 의존하지 않는다면, 인라인으로 추가해도 안전합니다. 예를 들면, ARIA 랜드마크 역할이나 ARIA 라벨링 및 설명 속성은 인라인으로 추가해도 문제 없습니다.

콘텐츠 및 상호작용이 스크립트 사용 환경에서만 지원된다면(예. Google 문서 등은 JavaScript가 켜져야 동작), ARIA 마크업을 인라인으로 써도 안전합니다. (JavaScript 미사용 시 누구에게도 동작하지 않으므로)

그 외의 경우에는, ARIA를 스크립트로 삽입·변경·제거하세요. 예를 들어, 트리 위젯의 닫힌 섹션은 이렇고:

<li role=treeitem aria-expanded=false ...

이 섹션을 사용자가 열면 자바스크립트로 아래처럼 바꿀 수 있습니다:

<li role=treeitem aria-expanded=true ...

2.8 ARIA 유효성 검사

가장 쉬운 방법은 HTML5 DOCTYPE과 ARIA 마크업을 함께 사용하고, W3C Nu Markup Checker로 검사하는 것입니다. ARIA는 다른 DOCTYPE과도 잘 동작하지만, 유효성 검사 도구가 ARIA 마크업을 만나면 오류를 출력할 수 있습니다. 관련 DTD가 ARIA 마크업을 인식하지 않으며 앞으로도 업데이트될 가능성은 낮기 때문입니다.

HTML5 이전 버전의 유효성 검사 오류는 ARIA가 실질적인 접근성 문제를 만든다는 의미가 아니며, 사용자 경험이 나빠진다는 뜻도 아닙니다. 단지 구식 자동 검사기가 ARIA 접근성 주석을 인식하지 못해서 발생합니다.

참고: W3C Nu Markup Checker의 ARIA 체크는 개발 중이므로 100% 신뢰할 수는 없습니다(그래도 매우 좋은 편!). 만약 ARIA 명세나 HTML 명세의 적합성 규정과 상충되는 검사 결과를 보이면, 이슈를 제출하는 것이 권장됩니다.

2.9 role=presentation 또는 role=none 사용하기

role=presentation 또는 동의어 role=none은 해당 요소의 의미를 제거합니다.

예를 들어, HTML 트리에서 이 코드는:

<h1 role="presentation">text</h1>

접근성 트리에서 이렇게 됩니다:

즉, 의미 없는 텍스트로만 접근성 트리에 나타납니다.

필수 자식요소가 없는 요소의 경우, role=presentation/none이 붙은 요소 안의 다른 요소들은 고유 의미를 그대로 가집니다.

예를 들어, HTML 트리에서 이런 코드는:

<h1 role="presentation"><abbr>API</abbr></h1>

접근성 트리에서 이렇게 됩니다:

필수 자식 요소(예: ul 또는 table)가 있는 요소에 role=presentation/none을 적용하면 내부의 필수 자식 요소 역시 의미가 제거됩니다.

예를 들어, HTML 트리에서 이런 코드는:

<table role="presentation">
  <tr>
    <td>
      <abbr>API</abbr>
    </td>
  </tr>
</table>

접근성 트리에서 이렇게 됩니다:

참고: role=presentation/none이 적용된 요소의 필수 자식 요소가 아닌 기타 자식 요소는 고유 의미가 유지됩니다. 필수 자식이 있는 요소(중첩 리스트, 중첩 테이블 등)도 포함됩니다.

다음과 같이 테이블 안에 또 다른 테이블을 중첩한 경우, HTML 트리에서는:

<table>
 <tr>
  <td>
    <table>
     <tr>
      <td>
       <abbr>API</abbr>
      </td>
     </tr>
    </table>
  </td>
 </tr>
</table>

접근성 트리에서는 이렇게 됩니다:

외부 table 요소에 role=presentation/none을 추가하면, HTML 트리에서 다음 코드는:

<table role="presentation">
 <tr>
  <td>
    <table>
     <tr>
      <td>
       <abbr>API</abbr>
      </td>
     </tr>
    </table>
  </td>
 </tr>
</table>

접근성 트리에서는 이렇게 되고, 외부 table과 그 필수 자식(tr과 td)의 의미가 role=presentation/none 때문에 사라집니다:

role=presentation/none 사용 예시

잘못된 테이블 구조 고칠 때 사용 예시

<div aria-readonly="true" role="grid">
    <table role="presentation">
    <tbody><tr role="row">
    <th role="columnheader">Dog Names</th>
    <th role="columnheader">Cat Names</th>
    <th role="columnheader">Cow names</th>
    </tr>
    </tbody></table>
    <table role="none">
    <tbody><tr role="row">
    <td role="gridcell">Fido</td>
    <td role="gridcell">Whiskers</td>
    <td role="gridcell">Clarabella</td>
    </tr>
    <tr role="row">
    <td role="gridcell">Woofie</td>
    <td role="gridcell">Claws</td>
    <td role="gridcell">Glenn</td>
    </tr>
    </tbody></table>
    </div>

2.10 실무 지원: aria-label, aria-labelledby 및 aria-describedby

현재 시점에서 요약은 다음과 같습니다:

• aria-labelledby 및 aria-describedby는 인터랙티브 콘텐츠 요소(예: 링크 및 다양한 input 타입의 폼 컨트롤)에 대해 강력하게 지원됩니다.
• 대부분의 보조 기술에서 aria-label 또는 aria-labelledby를 <nav> 및 <main> 요소에 사용하는 것은 괜찮지만, <footer>, <section>, <article>, <header>에는 사용하지 않는 것이 좋습니다.
• <aside>에서 aria-label 또는 aria-labelledby의 지원은 혼재되어 있습니다.
• Android의 Talkback은 모든 랜드마크의 내용을 aria-label 또는 aria-labelledby로 덮어씁니다.
• role=navigation, role=search, role=main이 설정된 div에 aria-label 또는 aria-labelledby를 사용하는 것은 괜찮습니다. JAWS는 role=banner, role=complementary, role=contentinfo에서는 지원하지 않습니다. NVDA, VoiceOver, Talkback에서는 괜찮습니다.
• aria-label, aria-labelledby, aria-describedby는 table, th, td 요소에서 잘 동작하지만, 일부 경우 NVDA, iOS의 VoiceOver, Talkback에서 예외가 있습니다(다음 섹션 참조).
• 어떤 heading 요소(h1 등)에도 aria-label 또는 aria-labelledby를 사용하지 마십시오. 이렇게 하면 NVDA, VoiceOver, Talkback에서 헤딩에 적용된 텍스트가 덮어집니다(JAWS는 무시함).
• 기타 상호작용하지 않는 컨텐츠(p, legend, li, ul 등)에 aria-label 또는 aria-labelledby를 사용하지 마십시오. 무시됩니다.
• role이 부여되지 않은 span이나 div에 aria-label 또는 aria-labelledby를 사용하지 마십시오. 해당 속성이 인터랙티브 역할(예: link 또는 button), img 역할에 있다면 div 또는 span의 내용을 덮어씁니다. 위에서 언급한 랜드마크 외의 역할은 무시됩니다.
• span 또는 div의 aria-describedby는 디폴트로 NVDA와 VoiceOver에서 무시됩니다(인터랙티브 역할, 이미지 혹은 랜드마크 역할로 지정된 경우는 예외). JAWS, Talkback에서는 괜찮습니다.
• 정적인 기타 컨텐츠의 aria-describedby는 NVDA, VoiceOver에서 무시됩니다. JAWS, Talkback에서는 괜찮습니다.

위 내용은 모두 iframe 요소에서도 동일하게 동작합니다. aria-label과 aria-labelledby는 스크린 리더, 접근성 API에서 같은 방식으로 처리되지만, aria-label은 참조할 수 있는 가시적 텍스트가 없거나 id를 관리하기 너무 어려울 때에만 사용하는 것이 좋습니다.

Internet Explorer에서의 aria-labelledby, aria-label, aria-describedby 사용 참고사항

Internet Explorer에서 aria-labelledby에 여러 id를 지정하거나 aria-describedby에 하나 또는 여러 id를 지정할 때, 참조된 요소는 반드시 Microsoft가 정의한 접근 가능한 HTML 요소여야 합니다.

aria-labelledby를 여러 번 참조하는 경우, tabindex=-1이 추가된 span 사용 예시. 자세한 내용은 Making Non accessible Elements Accessible 참조.

또한, ARIA 역할이 부여된 요소는 Internet Explorer에서도 접근 가능한 HTML 요소로 처리됩니다. 예:

숨김 컨텐츠는 접근 가능한 이름/설명 계산에 영향을 주지 않음

의도적으로 aria-labelledby 또는 aria-describedby가 참조하는 요소에 CSS display:none이나 visibility:hidden, 또는 HTML hidden 속성을 써도 이름/설명 제공에는 영향이 없습니다.

기본적으로 보조기술은 숨겨진 정보를 전달하지 않지만, 작성자는 aria-labelledby나 aria-describedby를 사용해 숨겨진 텍스트를 접근 가능한 이름이나 접근 가능한 설명의 일부로 명시적으로 포함시킬 수 있습니다.

아래 예시에서 설명은 두 상태 모두에서 보조기술 사용자에게 제공됩니다:

오류 없음 상태: 메시지 시각적으로 숨김

<label>Name <input type="text"  aria-describedby="error-message"></label>
<span id="error-message" style="display:none">
You have provided an incorrect name</span>

참고: 참조된 요소에 aria-hidden=true을 추가해도 차이 없음:

<span id="error-message" style="display:none" aria-hidden="true">
 You have provided an incorrect name</span>

오류 상태: 메시지 가시화

<span id="error-message" style="display:inline">
You have provided an incorrect name</span>

상황별 텍스트(오류 등) 제공 방법

• 오류 발생 시 DOM에 참조된 요소를 추가합니다.
• 오류 상태에서 참조 요소의 자식으로 에러 메시지 텍스트를 추가합니다.
• 오류 발생 시 aria-labelledby/aria-describedby 속성의 id 참조를 DOM에 추가합니다.

2.11 ARIA role=application 사용하기

role="application"이 스크린 리더에 미치는 영향

오늘날 많은 인기 있는 스크린 리더에서는 사용자가 탐색 모드에 있을 때 대부분의 키 입력이 웹 페이지가 아니라 스크린 리더에 의해 포착됩니다. 이는 효율적인 페이지 탐색에 필수적입니다. 현재, application 모드가 설정되면 많은 스크린 리더가 키 입력의 가로채기를 멈추고 모든 키 입력을 브라우저에 직접 전달합니다. 이 경우 사용자는 페이지를 쉽게 탐색할 수 없게 됩니다. 예를 들어, 헤딩 단위로 점프하거나 정적 텍스트 단락을 한 줄씩 읽는 것이 어렵습니다. 하지만 application 역할을 설정해도 다르게 동작하지 않는 스크린 리더들도 있습니다.

언제 사용해야 하고, 언제 사용하지 않아야 하는가?

role=application을 사용할지 결정할 때는, 스크린 리더 단축키의 장점과 해당 기능 상실을 함께 고려해야 합니다. 일반적으로 사용하지 않는 것이 좋으며, 사용한다면 스크린 리더 사용자로 실제 사용성 테스트를 거쳐야 합니다.

표준 HTML 위젯만 포함된 컨트롤 집합에는 role="application"을 사용하지 않아야 합니다. 이는 마크업을 WAI-ARIA 역할로 구현해도 마찬가지입니다.

참고: 커스텀 텍스트 입력 위젯 개발은 권장하지 않습니다. 네이티브 입력을 사용하는 것이 거의 항상 더 좋습니다.

• text box (패스워드, 검색, 전화 등 다양한 input type도 포함)
• textarea
• check box
• button
• radio button (대개 fieldset/legend 요소 내)
• select + option
• links, paragraphs, headings 등 웹의 기본 문서 요소들

아래와 같은 동적이면서 비표준 위젯이더라도 application 역할을 사용하지 않습니다. 대부분의 스크린 리더와 보조 기술은 WAI-ARIA를 지원하며 이런 위젯에 대해 탐색 모드와 포커스 모드를 기본적으로 전환 지원합니다:

• tree view
• slider
• 포커싱이 가능한 항목이 있고 화살표 키로 탐색하는 table(예: 이메일 목록 등). Interactive grid, tree grid 등도 해당
• 탭 목록 (tab, tablist), 좌우 화살표로 탭 이동 (이때 키보드 탐색 구현은 직접 해야 함)
• dialog 및 alertdialog. 이들에 포커스가 가면 일부 스크린 리더가 자동으로 application 모드로 동작. 최적 사용을 위해서는 role="dialog" 요소의 aria-describedby를 설명 텍스트의 id로 지정하고, 열 때 첫 인터랙티브 컨트롤에 포커스 이동:

  <div role="dialog" aria-label="login" aria-describedby="log1">
  <div id="log1" tabindex="-1">Provide user name and password to login.</div>
  ...
  ...
  </div>

• toolbar, toolbar buttons, menus, menu items 등

role=application은 오직 포커스 가능한 상호작용 컨트롤로만 이루어진 고급 위젯, 실제 데스크톱 앱을 에뮬레이션하는 경우에만 사용해야 합니다. 오늘날 웹앱이라지만 실상 대부분의 웹 콘텐츠는 여전히 문서 기반입니다.(예, 페이스북 글, 블로그, 트위터 피드, 동적 접힘 콘텐츠 등) 표면적으로만 데스크톱 앱처럼 보여도, 본질은 문서 콘텐츠임을 명심할 것.

포커스(폼) 모드에서도 위젯별 단축키 사용이 가능하기 때문에 role=application은 필요 없습니다. 예를 들어 ARIA role=listbox를 가진 커스텀 컨트롤은 사용자가 상호작용하는 동안 모든 입력(화살표키 등)을 직접 받을 수 있습니다.

요약: 실제로 role=application을 쓸 일은 매우 드뭅니다!

드물게 필요할 때 role=application은 어디에 넣어야 하나?

위젯의 가장 가까운 컨테이너에 지정합니다. 예시: 위젯 외부를 감싸는 div. 이 div 내부에 application 인터랙션 모델이 필요한 위젯만 있다면, 사용자가 이 부분에서 벗어나면 자동으로 포커스 모드가 해제됩니다.

페이지 전체가 위젯만 있는 경우에 한해서 body에 지정, 설명성(문서성) 콘텐츠가 있다면 해당 부분의 outermost 요소에 role=document 지정, tabindex=0으로 탭 진입도 가능하게 할 것. role=document는 role=application과 반대 역할.

경험적으로: 페이지의 90% 이상이 위젯일 경우에는 role=application이 적합할 가능성도 있으나, 반드시 실제 사용자 테스트로 두 가지 버전(사용/미사용)을 검증할 것!

절대로 body 등 넓은 범위에 role=application을 남용하지 마십시오. 페이지의 대부분이 링크 등 문서 구조이거나, 포커스 모드가 불필요한 경우 보조기술 사용자는 사이트를 이용하기 힘들어집니다.

role=application에 대한 추가 정보는 If you use the WAI-ARIA role "application", please do so wisely! 참고

2.12 커스텀 컨트롤 접근성 개발 체크리스트:

아래 설계 항목 및 체크리스트로 커스텀 컨트롤을 점검하세요. 하나라도 ‘No’가 있으면 출시 전 수정하거나, 접근성 지원이 제한되어 일부 사용자가 이용할 수 없다는 점을 문서화해야 합니다.

2.13 ARIA는 대부분의 HTML 요소의 기본 의미에 아무것도 추가하지 않음

대부분의 경우 ARIA role 및/또는 aria-* 속성이 기본 암시적 ARIA 의미와 일치하도록 설정하는 것은 불필요하며, 브라우저가 이미 해당 속성을 설정하므로 추천되지 않습니다.

<button role="button">press me</button>   

<input type="text" required aria-required="true">

<div hidden aria-hidden="true">

<h1 role="heading" aria-level="1">heading text</h1>

2.14 HTML에서 사용 불가능한 Aria 역할과 속성

2.15 ARIA 디자인 패턴 및 터치 기기 지원

2.16 권장 사항 표

HTML에서 ARIA 속성 사용을 위한 문서 적합성 요구사항 테이블을 ARIA in HTML 명세에서 참고하세요.

2.17 ARIA 역할, 상태, 속성 빠른 참조

허용된 ARIA 역할, 상태, 속성 테이블을 ARIA in HTML 명세에서 참고하세요.