WAI-ARIA 작성 방법 1.2

W3C Editor's Draft

This version:
https://w3c.github.io/aria-practices/
Latest published version:
https://www.w3.org/TR/wai-aria-practices-1.2/
Latest editor's draft:
https://w3c.github.io/aria-practices/
Editors:
(Facebook)
(University of Illinois)
(Adobe)
Zoë Bijl (Invited Expert)
(W3C)
Former editors:
Joseph Scheuhammer (Inclusive Design Research Centre, OCAD University) (Editor until October 2014)
Lisa Pappas (SAS) (Editor until October 2009)
Rich Schwerdtfeger (IBM Corporation) (Editor until October 2014)

이 번역본은 ARIA 1.2 버전에 대한 개인 번역본으로 공식 번역본이 아닙니다.
잘못된 번역으로 원문의 의도를 해치지 않기 위해 의도적으로 직역을 선택하였으며, 일부는 이해를 돕기 위해 원문의 의도를 해치지 않는 선에서 의역되거나 각색되었습니다.
원문은 아래 링크에서 확인이 가능하며, 오역이 있을 경우 Github issue에 남겨시면 확인 후 수정하도록 하겠습니다.
원문: WAI-ARIA Authoring Practices 1.2

Abstract

이 문서는 독자에게 접근 가능한 리치 인터넷 어플리케이션을 만드는데 WAI-ARIA 1.2 [WAI-ARIA]를 어떻게 사용하는지에 대한 이해를 제공합니다. WAI-ARIA 명세만으로는 대다수의 작성자에게 명확하지 않을 수 있는 고려 사항들을 설명하고 WAI-ARIA 역할(role), 상태(state), 속성(property)을 사용하여 위젯, 내비게이션, 동작을 접근 가능하게 할 수 있는 처리 방법을 추천합니다. 이 문서는 주로 웹 어플리케이션 개발자들을 대상으로 하지만, 지침은 유저 에이전트와 보조 기술 개발자에게도 유용합니다.

이 문서는 WAI-ARIA 개요에 기술된 WAI-ARIA 제품군의 일부입니다.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at https://www.w3.org/TR/.

이 문서는 웹 접근성 이니셔티브접근 가능한 리치 인터넷 어플리케이션 워킹 그룹의 편집자 초안입니다. 이 문서는 WAI-ARIA 1.2 [WAI-ARIA]를 지원하며, 기술 명세에 상응하는 것을 넘어 명세를 이해하는데 중요한 상세한 조언과 예제들을 제공합니다.

이 초안은 WAI-ARIA 작성 방법 1.2에 대해 계획된 일부 내용만을 포함합니다. 전체 지침에 대한 계획을 보려면 작성 방법 마일스톤 계획을 확인하세요.

여기 제공된 정보 상의 피드백은 정보와 운영에 대해 완전한 접근을 제공하는 리치 인터넷 어플리케이션의 궁극적인 성공에 필수적입니다. 접근 가능한 리치 인터넷 어플리케이션 워킹 그룹은 특히 다음과 같은 질문을 합니다:

의견을 남기려면, W3C ARIA Practices GitHub repository에 이슈를 남기거나, 그것이 불가능하다면, public-aria@w3.org (comment archive)로 이메일을 보내주세요.

This document was published by the Accessible Rich Internet Applications Working Group as an Editor's Draft.

Comments regarding this document are welcome. Please send them to public-aria@w3.org (archives).

Publication as an Editor's Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

This document was produced by a group operating under the W3C Patent Policy. The group does not expect this document to become a W3C Recommendation. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is governed by the 1 March 2019 W3C Process Document.

1. 소개

이 섹션은 정보성입니다.

WAI-ARIA 작성 방법은 접근 가능한 리치 인터넷 어플리케이션을 만드는데 WAI-ARIA 1.2를 사용하는 방법을 이해하기 위한 지침입니다. WAI-ARIA의 적절한 적용에 대한 지침을 제공하고, 추천 WAI-ARIA 사용 패턴을 기술하며 그 이면의 개념을 설명합니다.

리치하고 동적인 웹 사이트를 만드는데 사용되는 언어들에는, 예를 들어, HTML, JavaScript, CSS, SVG, 보조 기술(AT)을 사용하는 사람들이나 키보드 탐색에 의존하는 사람들이 사이트를 사용할 수 있게 하는데 필요한 모든 기능들이 기본적으로 포함되어 있지 않습니다. W3C 웹 접근성 이니셔티브(WAI)의 접근 가능한 리치 인터넷 어플리케이션 워킹 그룹 (ARIA WG)는 몇 가지 W3C 표준 작업들을 통해 이러한 결함들을 해결하고 있습니다. WAI-ARIA 개요WAI-ARIA에 대한 자세한 배경을 제공하고, 그 노력들을 간략하게 이야기하고, WAI-ARIA 제품군에 포함된 다른 문서들을 나열합니다.

짧은 먼저 읽어주세요 섹션 이후, 지침은 예상되는 동작을 열거하고 작업 코드로 그 동작을 보여주는 공통 위젯에 대한 ARIA 구현 패턴으로 시작합니다. 구현 패턴과 예제들은 후속 지침 섹션에서 지원 개념에 대한 자세한 설명을 참조합니다. 지침 섹션은 ARIA 랜드마크의 사용, 키보드 인터페이스에 대한 방법, 그리드와 테이블 속성(property), presentation 역할(role)의 영향과 같은 좀 더 일반적인 주제들을 다룹니다.

2. 먼저 읽어주세요

2.1 잘못된 ARIA보다 ARIA를 안쓰는게 낫다

기능적으로, ARIA (role), 상태(state), 속성(property)들은 보조 기술에 대해 CSS와 유사합니다. 스크린리더 사용자들의 경우, ARIA는 비시각적 경험의 렌더링을 제어합니다. 잘못된 ARIA는 잠재적으로 비시각적 경험에 대해 심각한 손상을 주며 시각적 경험을 잘못 전달합니다.

ARIA나 이 문서의 어떤 지침을 사용하기 이전에, 다음의 두 가지 기본 원칙을 이해하는데 시간을 들이세요.

원칙 1: 역할(role)은 약속이다

이 코드는:

<div role="button">Place Order</div>

해당 <div>의 작성자가 버튼에 기대되는 키보드 인터랙션을 제공하는 JavaScript도 구현했다는 약속입니다. HTML 입력 요소(element)와 달리, ARIA 역할(role)은 브라우저가 키보드 동작이나 스타일링을 제공하지 않습니다.

그 역할(role)의 약속을 이행하지 않고 사용하는 것은 주문을 빼먹고 쇼핑 카트를 비우는 "주문하기" 버튼을 만드는 것과 유사합니다.

이 지침의 목표 중 하나는 각 ARIA 역할(role)에 대해 기대되는 동작을 정의하는 것입니다.

원칙 2: ARIA는 은폐와 강화를 통해 힘과 위험 모두를 창출할 수 있습니다.

유저 인터페이스 요소(element)들의 의미와 목적에 대해 필요한 정보 보조 기술을 접근성 의미론이라고 합니다. 보조 기술의 관점에서, ARIA는 작성자에게 보조 기술이 달리 확실하게 추론 할 수 없을 중요한 접근성 의미론으로 HTML과 SVG 요소(element)를 꾸밀 수 있는 능력을 제공합니다.

일부 ARIA는 가면과 같습니다; 원래의 의미나 콘텐트를 완전히 감추거나 덮어 씌웁니다.

<a role="menuitem">보조 기술 사용자는 이 요소(element)를 링크가 아니라 메뉴의 항목으로 인지합니다.</a>
<a aria-label="보조 기술 사용자는 링크 텍스트가 아니라 이 aria-lable의 콘텐트만을 인식할 수 있습니다">링크 텍스트</a>

반면에, 일부 ARIA의 사용은 멜빵이나 벨트에 가깝습니다; 원본 콘텐트에 필수적인 지원을 제공하는 의미를 추가합니다.

<button aria-pressed="false">Mute</button>

이것이 ARIA의 힘입니다. 작성자가 보조 기술들이 확실하게 해석할 수 있는 방법으로 거의 모든 유저 인터페이스를 기술할 수 있게 하므로, 보조 기술 사용자에게 컴포넌트를 접근 가능하게 할 수 있습니다.

이것은 동시에 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>

2.2 브라우저와 보조 기술 지원

제품에 이 가이드의 코드를 사용하기 이전에 보조 기술 상호 운용성 테스트가 필수적입니다. 이 지침의 목적은 ARIA 명세에 정의 된 대로 ARIA 1.2의 적절한 사용을 실제로 보여주는 것이기 때문에, 설계 패턴, 참고 예제, 샘플 코드는 일부러 브라우저와 보조 기술들의 ARIA 1.2에 대한 지원의 격차에 따른 문제를 해결하기 위한 코딩 기법을 기술하고 구현하지 않습니다. 따라서, 대상 고객과 관련된 각 브라우저와 보조 기술 조합으로 구현을 철저하게 테스트 하는 것이 바람직합니다.

비슷하게, 이 지침의 JavaScript와 CSS는 작성 시점에서의 가장 최신 버전의 크롬, 파이어폭스, 인터넷 익스플로러, 사파리와 호환되도록 작성되었습니다. 특히, 인터넷 익스플로러 10 이하 버전에서는 일부 JavaScript와 CSS가 제대로 동작하지 않을 수 있습니다.

ARIA 워킹 그룹과 다른 컨트리뷰터들이 오류를 못 보고 지나친 경우를 제외하고, 이 지침의 특정 브라우저나 특정 보조 기술에서 제대로 동작하지 않는 예제는 브라우저나 보조 기술 버그를 시연하는 것입니다. 따라서 브라우저와 보조 기술 개발자는 이 지침의 코드를 활용하여 ARIA 1.2에 대한 지원 품질을 평가할 수 있습니다.

2.3 모바일과 터치 지원

현재, 이 지침은 모바일 브라우저나 터치 인터페이스와 호환되는 예제는 나와 있지 않습니다. 일부 예제는 모바일과 터치 지원을 향상시키는 특정 기능이 포함되어 있지만, 일부 ARIA 기능은 모바일 브라우저에서 지원되지 않습니다. 또한, 모바일 브라우저에서 동작하는 터치 인터랙션을 제공하기 위한 표준화 된 접근 방식은 아직 없습니다.

터치와 모바일 지원에 대한 추가 지침은 향후 지침 릴리즈에 계획되어 있습니다.

3. 설계 패턴과 위젯

이 섹션은 WAI-ARIA 역할(role), 상태(state), 속성(property)을 적용하고 키보드 지원을 구현하여 일반적인 리치 인터넷 어플리케이션 패턴과 위젯을 접근 가능하게 만드는 방법을 보여줍니다.

3.1 아코디언 (Show/Hide 기능이 있는 섹션)

아코디언은 각각 콘텐츠 섹션을 나타내는 제목, 콘텐트 스니펫, 또는 썸네일을 포함하는 수직으로 쌓여있는 인터랙티브 제목 집합입니다. 제목은 연관된 콘텐츠 섹션을 사용자에게 나타내거나 숨길 수 있는 컨트롤로 쓰입니다. 아코디언은 일반적으로 단일 페이지에서 콘텐트의 여러 섹션들을 표현할 때 스크롤 할 필요성을 줄이기 위해 사용됩니다.

아코디언을 이해하는데 필요한 용어:

아코디언 헤더:
콘텐트 섹션을 노출시키고 일부 구현에서는 숨기는 컨트롤 역할을 하는, 콘텐트 섹션에 대한 레이블이나 콘텐트 섹션을 나타내는 썸네일.
아코디언 패널:
아코디언 헤더와 연관된 콘텐트 섹션.

일부 아코디언에서는 아코디언 헤더 근처에 항상 보이는 추가 요소가 있습니다. 예를 들어, 메뉴버튼은 그 섹션에 적용되는 동작으로의 접근을 제공하기 위해 각 헤더와 함께 있을 수 있습니다. 그리고 경우에 따라, 숨겨진 콘텐트의 일부가 보여지게 유지될 수도 있습니다.

예제

아코디언 예: 한 번에 하나의 섹션을 보여주기 위해 아코디언을 사용하여 세 개 섹션으로 분리된 양식을 보여줍니다.

키보드 인터랙션

  • Enter 또는 Space:
    • 초점이 축소 된 패널에 대한 아코디언 헤더에 있다면, 관련된 패널을 확장시킵니다. 동작이 항상 단 하나의 패널만 확장 되는 것을 허용하면서 다른 패널이 확장되어 있는 경우, 그 패널을 축소시킵니다.
    • 초점이 확장 된 패널에 대한 아코디언 헤더에 있다면, 동작이 축소를 지원하는 경우 패널을 축소 시킵니다. 일부 동작에서는 항상 하나의 패널이 확장되어 있고 오직 하나의 패널만이 확장되도록 요구됩니다; 따라서 이 경우에는 축소 기능을 지원하지 않습니다.
  • Tab: 초점을 다음 초점을 얻을 수 있는 요소(focusable element)로 이동시킵니다; 아코디언 내의 모든 초점을 얻을 수 있는 요소(focusable element)는 페이지 Tab 순서에 포함됩니다.
  • Shift + Tab: 초점을 이전 초점을 얻을 수 있는 요소(focusable element)로 이동시킵니다; 아코디언 내의 모든 초점을 얻을 수 있는 요소(focusable element)는 페이지 Tab 순서에 포함됩니다.
  • Down Arrow (선택적): 초점이 아코디언 헤더에 있다면, 다음 아코디언 헤더로 초점을 이동시킵니다. 초점이 마지막 아코디언 헤더에 있다면, 아무 것도 하지 않거나 첫 번째 아코디언 헤더로 초점을 이동시킵니다.
  • Up Arrow (선택적): 초점이 아코디언 헤더에 있다면, 이전 아코디언 헤더로 초점을 이동시킵니다. 초점이 첫 번째 아코디언 헤더에 있다면, 아무 것도 하지 않거나 마지막 아코디언 헤더로 초점을 이동시킵니다.
  • Home (선택적): 초점이 아코디언 헤더에 있다면, 첫 번째 아코디언 헤더로 초점을 이동시킵니다.
  • End (선택적): 초점이 아코디언 헤더에 있다면, 마지막 아코디언 헤더로 초점을 이동시킵니다.

WAI-ARIA 역할(role), 상태(state), 속성(proeprty):

  • 각 아코디언 헤더의 제목은 button 역할(role)을 가진 요소(element)에 포함됩니다.
  • 각 아코디언 헤더 button은 페이지의 정보 구성에 적절한 aria-level로 정해진 값을 가지는 heading 역할(role)을 가진 요소(element)로 감싸집니다.
    • 네이티브 호스트 언어가 HTML 헤딩 태그 같이, 암묵적인 headingaria-level을 가지고 있는 경우, 네이티브 호스트 언어 요소(element)가 사용될 수 있습니다.
    • button 요소(element)는 heading 요소(element) 내의 유일한 요소(element)입니다. 즉, 다른 보여지도록 유지되는 요소(element)가 있다면, heading 요소(element)에 포함되지 않습니다.
  • 아코디언 헤더와 연관된 아코디언 패널이 보여지는 상태라면, 헤더 button 요소(element)는 true로 설정된 aria-expanded를 가집니다. 패널이 보여지지 않는 상태라면, aria-expandedfalse로 설정됩니다.
  • 아코디언 헤더 button 요소(element)는 아코디언 패널 콘텐트를 포함하는 요소(element)의 ID로 설정된 aria-controls 를 가집니다.
  • 아코디언 헤더와 연관된 아코디언 패널이 보이는 상태이고 아코디언이 패널이 축소되는 것을 허용하지 않는다면, 헤더 button 요소(element)는 true로 설정된 aria-disabled를 가집니다.
  • 선택적으로, 패널 콘텐트에 대한 컨테이너를 제공하는 각 요소(element)는 region 역할(role)과 패널의 가시성을 제어하는 버튼을 가리키는 값을 가진 aria-labelledby를 가집니다.
    • 랜드마크 영역을 급증하게 만드는 상황에서는 (예를 들어, 동시에 확장 될 수 있는 거의 6개 이상의 패널들을 포함하는 아코디언) region 역할(role)을 사용하는 것을 지양하세요.
    • region 역할(role)은 패널이 헤딩 요소(element)를 포함하거나 중첩된 아코디언이 포함 된 경우 스크린리더 사용자가 구조를 인식하는데 특히 유용합니다.

3.2 경고

경고는 사용자의 작업을 방해하지 않고 사용자의 관심을 끌어내는 방법으로 짤막한 중요한 메세지를 표시하는 요소(element)입니다. 동적으로 렌더링 된 경고는 대부부의 스크린리더에 의해 자동으로 낭독되며, 일부 운영체제에서는 경고음을 발생시킬 수도 있습니다. 이 때, 스크린리더는 페이지가 완전히 로드되기 전에는 페이지에 있는 경고를 사용자에게 알려주지 않는다는 점을 유념해야 합니다.

경고는 사용작의 작업을 계속 할 수 있는 것을 방해하지 않으면서 중요하고 시간에 민감할 수 있는 정보를 제공하기 위한 것이기 때문에, 키보드 초점에 영향을 주지 않는 것이 매우 중요합니다. alert dialog는 작업 흐름을 중단해야 하는 상황에 맞게 설계되었습니다.

자동으로 사라지는 경고를 설계하는 것을 피하는 것도 중요합니다. 너무 빠르게 사라지는 경고는 WCAG 2.0 성공 기준 2.2.3을 충족시키지 못하게 할 수 있습니다. 다른 중요한 설계 고려사항은 경고로 인한 중단 빈도입니다. 잦은 둔단은 시각과 인지 장애를 가진 사람들의 사용성을 저해하며, 이는 WCAG 2.0 success criterion 2.2.4의 요구사항을 충족시키는 것을 더욱 어렵게 만듭니다.

예제

경고 예

키보드 인터랙션

해당되지 않음.

WAI-ARIA 역할(role), 상태(state), 속성(property)

위젯은 alert 역할(role)을 가집니다.

3.3 Alert and Message Dialogs

An alert dialog is a modal dialog that interrupts the user's workflow to communicate an important message and acquire a response. Examples include action confirmation prompts and error message confirmations. The alertdialog role enables assistive technologies and browsers to distinguish alert dialogs from other dialogs so they have the option of giving alert dialogs special treatment, such as playing a system alert sound.

Example

Alert Dialog Example: A confirmation prompt that demonstrates an alert dialog.

Keyboard Interaction

See the keyboard interaction section for the modal dialog pattern.

WAI-ARIA Roles, States, and Properties

  • The element that contains all elements of the dialog, including the alert message and any dialog buttons, has role alertdialog.
  • The element with role alertdialog has either:
    • A value for aria-labelledby that refers to the element containing the title of the dialog if the dialog has a visible label.
    • A value for aria-label if the dialog does not have a visible label.
  • The element with role alertdialog has a value set for aria-describedby that refers to the element containing the alert message.

3.5 Button

A button is a widget that enables users to trigger an action or event, such as submitting a form, opening a dialog, canceling an action, or performing a delete operation. A common convention for informing users that a button launches a dialog is to append "…" (ellipsis) to the button label, e.g., "Save as…".

In addition to the ordinary button widget, WAI-ARIA supports 2 other types of buttons:

Note

The types of actions performed by buttons are distinctly different from the function of a link (see link pattern). It is important that both the appearance and role of a widget match the function it provides. Nevertheless, elements occasionally have the visual style of a link but perform the action of a button. In such cases, giving the element role button helps assistive technology users understand the function of the element. However, a better solution is to adjust the visual design so it matches the function and ARIA role.

Examples

  • Button Examples: Examples of clickable HTML div and span elements made into accessible command and toggle buttons.
  • Button Examples (IDL): Examples of clickable HTML div and span elements made into accessible command and toggle buttons. This example uses the IDL Interface.

Keyboard Interaction

When the button has focus:

  • Space: Activates the button.
  • Enter: Activates the button.
  • Following button activation, focus is set depending on the type of action the button performs. For example:
    • If activating the button opens a dialog, the focus moves inside the dialog. (see dialog pattern)
    • If activating the button closes a dialog, focus typically returns to the button that opened the dialog unless the function performed in the dialog context logically leads to a different element. For example, activating a cancel button in a dialog returns focus to the button that opened the dialog. However, if the dialog were confirming the action of deleting the page from which it was opened, the focus would logically move to a new context.
    • If activating the button does not dismiss the current context, then focus typically remains on the button after activation, e.g., an Apply or Recalculate button.
    • If the button action indicates a context change, such as move to next step in a wizard or add another search criteria, then it is often appropriate to move focus to the starting point for that action.
    • If the button is activated with a shortcut key, the focus usually remains in the context from which the shortcut key was activated. For example, if Alt + U were assigned to an "Up" button that moves the currently focused item in a list one position higher in the list, pressing Alt + U when the focus is in the list would not move the focus from the list.

WAI-ARIA Roles, States, and Properties

  • The button has role of button.
  • The button has an accessible label. By default, the accessible name is computed from any text content inside the button element. However, it can also be provided with aria-labelledby or aria-label.
  • If a description of the button's function is present, the button element has aria-describedby set to the ID of the element containing the description.
  • When the action associated with a button is unavailable, the button has aria-disabled set to true.
  • If the button is a toggle button, it has an aria-pressed state. When the button is toggled on, the value of this state is true, and when toggled off, the state is false.

3.7 Checkbox

WAI-ARIA supports two types of checkbox widgets:

  1. Dual-state: The most common type of checkbox, it allows the user to toggle between two choices -- checked and not checked.
  2. Tri-state: This type of checkbox supports an additional third state known as partially checked.

One common use of a tri-state checkbox can be found in software installers where a single tri-state checkbox is used to represent and control the state of an entire group of install options. And, each option in the group can be individually turned on or off with a dual state checkbox.

The user can use the tri-state checkbox to change all options in the group with a single action:

Examples

Keyboard Interaction

When the checkbox has focus, pressing the Space key changes the state of the checkbox.

WAI-ARIA Roles, States, and Properties

  • The checkbox has role checkbox.
  • The checkbox has an accessible label provided by one of the following:
    • Visible text content contained within the element with role checkbox.
    • A visible label referenced by the value of aria-labelledby set on the element with role checkbox.
    • aria-label set on the element with role checkbox.
  • When checked, the checkbox element has state aria-checked set to true.
  • When not checked, it has state aria-checked set to false.
  • When partially checked, it has state aria-checked set to mixed.
  • If a set of checkboxes is presented as a logical group with a visible label, the checkboxes are included in an element with role group that has the property aria-labelledby set to the ID of the element containing the label.
  • If the presentation includes additional descriptive static text relevant to a checkbox or checkbox group, the checkbox or checkbox group has the property aria-describedby set to the ID of the element containing the description.

3.8 Combobox

A combobox is an input widget with an associated popup that enables users to select a value for the combobox from a collection of possible values. In some implementations, the popup presents allowed values, while in other implementations, the popup presents suggested values, and users may either select one of the suggestions or type a value. The popup may be a listbox, grid, tree, or dialog. Many implementations also include a third optional element -- a graphical Open button adjacent to the combobox, which indicates availability of the popup. Activating the Open button displays the popup if suggestions are available.

The combobox pattern supports several optional behaviors. The one that most shapes interaction is text input. Some comboboxes allow users to type and edit text in the combobox and others do not. If a combobox does not support text input, it is referred to as select-only, meaning the only way users can set a value is by selecting a value in the popup. For example, in some browsers, an HTML select element with size="1" is presented to assistive technologies as a combobox. Alternatively, if a combobox supports text input, it is referred to as editable. An editable combobox may either allow users to input any arbitrary value, or it may restrict its value to a discrete set of allowed values, in which case typing input serves to filter suggestions presented in the popup.

The popup is hidden by default, i.e., the default state is collapsed. The conditions that trigger expansion -- display of the popup --are specific to each implementation. Some possible conditions that trigger expansion include:

Combobox widgets are useful for acquiring user input in either of two scenarios:

  1. The value must be one of a predefined set of allowed values, e.g., a location field must contain a valid location name. Note that the listbox and menu button patterns are also useful in this scenario; differences between combobox and alternative patterns are described below.
  2. An arbitrary value is allowed, but it is advantageous to suggest possible values to users. For example, a search field may suggest similar or previous searches to save the user time.

The nature of possible values presented by a popup and the way they are presented is called the autocomplete behavior. Comboboxes can have one of four forms of autocomplete:

  1. No autocomplete: The combobox is editable, and when the popup is triggered, the suggested values it contains are the same regardless of the characters typed in the combobox. For example, the popup suggests a set of recently entered values, and the suggestions do not change as the user types.
  2. List autocomplete with manual selection: When the popup is triggered, it presents suggested values. If the combobox is editable, the suggested values complete or logically correspond to the characters typed in the combobox. The character string the user has typed will become the value of the combobox unless the user selects a value in the popup.
  3. List autocomplete with automatic selection: The combobox is editable, and when the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox, and the first suggestion is automatically highlighted as selected. The automatically selected suggestion becomes the value of the combobox when the combobox loses focus unless the user chooses a different suggestion or changes the character string in the combobox.
  4. List with inline autocomplete: This is the same as list with automatic selection with one additional feature. The portion of the selected suggestion that has not been typed by the user, a completion string, appears inline after the input cursor in the combobox. The inline completion string is visually highlighted and has a selected state.

If a combobox is editable and has any form of list autocomplete, the popup may appear and disappear as the user types. For example, if the user types a two character string that triggers five suggestions to be displayed but then types a third character that forms a string that does not have any matching suggestions, the popup may close and, if present, the inline completion string disappears.

Two other widgets that are also visually compact and enable users to make a single choice from a set of discrete choices are listbox and menu button. One feature that distinguishes combobox from both listbox and menu button is that the user's choice can be presented as a value in an editable field, which gives users the ability to select some or all of the value for copying to the clipboard. Comboboxes and menu buttons can be implemented so users can explore the set of allowed choices without losing a previously made choice. That is, users can navigate the set of available choices in a combobox popup or menu and then press escape, which closes the popup or menu without changing previous input. In contrast, navigating among options in a single-select listbox immediately changes its value, and Escape does not provide an undo mechanism. Comboboxes and listboxes can be marked as required with aria-required="true", and they have an accessible name that is distinct from their value. Thus, when assistive technology users focus either a combobox or listbox in its default state, they can perceive both a name and value for the widget. However, a menu button cannot be marked required, and while it has an accessible name, it does not have a value so is not suitable for conveying the user's choice in its collapsed state.

Examples

Keyboard Interaction

  • Tab: The combobox is in the page Tab sequence.
  • Note: The popup indicator icon or button (if present), the popup, and the popup descendants are excluded from the page Tab sequence.
Combobox Keyboard Interaction

When focus is in the combobox:

  • Down Arrow: If the popup is available, moves focus into the popup:
    • If the autocomplete behavior automatically selected a suggestion before Down Arrow was pressed, focus is placed on the suggestion following the automatically selected suggestion.
    • Otherwise, places focus on the first focusable element in the popup.
  • Up Arrow (Optional): If the popup is available, places focus on the last focusable element in the popup.
  • Escape: Dismisses the popup if it is visible. Optionally, if the popup is hidden before Escape is pressed, clears the combobox.
  • Enter: If the combobox is editable and an autocomplete suggestion is selected in the popup, accepts the suggestion either by placing the input cursor at the end of the accepted value in the combobox or by performing a default action on the value. For example, in a messaging application, the default action may be to add the accepted value to a list of message recipients and then clear the combobox so the user can add another recipient.
  • Printable Characters:
    • If the combobox is editable, type characters in the combobox. Note that some implementations may regard certain characters as invalid and prevent their input.
    • If the combobox is not editable, optionally moves focus to a value that starts with the typed characters.
  • If the combobox is editable, it supports standard single line text editing keys appropriate for the device platform (see note below).
  • Alt + Down Arrow (Optional): If the popup is available but not displayed, displays the popup without moving focus.
  • Alt + Up Arrow (Optional): If the popup is displayed:
    • If the popup contains focus, returns focus to the combobox.
    • Closes the popup.
Note

Standard single line text editing keys appropriate for the device platform:

  1. include keys for input, cursor movement, selection, and text manipulation.
  2. Standard key assignments for editing functions depend on the device operating system.
  3. The most robust approach for providing text editing functions is to rely on browsers, which supply them for HTML inputs with type text and for elements with the contenteditable HTML attribute.
  4. IMPORTANT: Ensure JavaScript does not interfere with browser-provided text editing functions by capturing key events for the keys used to perform them.
Listbox Popup Keyboard Interaction

When focus is in a listbox popup:

  • Enter: Accepts the focused option in the listbox by closing the popup, placing the accepted value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the combobox. Optionally, if the combobox is editable, clears the contents of the combobox.
  • Down Arrow: Moves focus to and selects the next option. If focus is on the last option, either returns focus to the combobox or does nothing.
  • Up Arrow: Moves focus to and selects the previous option. If focus is on the first option, either returns focus to the combobox or does nothing.
  • Right Arrow: If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the right. If the input cursor is on the right-most character, the cursor does not move.
  • Left Arrow: If the combobox is editable, returns focus to the combobox without closing the popup and moves the input cursor one character to the left. If the input cursor is on the left-most character, the cursor does not move.
  • Home (Optional): Either moves focus to and selects the first option or, if the combobox is editable, returns focus to the combobox and places the cursor on the first character.
  • End (Optional): Either moves focus to the last option or, if the combobox is editable, returns focus to the combobox and places the cursor after the last character.
  • Any printable character:
    • If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.
    • Otherwise, moves focus to the next option with a name that starts with the characters typed.
  • Backspace (Optional): If the combobox is editable, returns focus to the combobox and deletes the character prior to the cursor.
  • Delete (Optional): If the combobox is editable, returns focus to the combobox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.
Note
  1. DOM Focus is maintained on the combobox and the assistive technology focus is moved within the listbox using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. Selection follows focus in the listbox; the listbox allows only one suggested value to be selected at a time for the combobox value.
Grid Popup Keyboard Interaction

In a grid popup, each suggested value may be represented by either a single cell or an entire row. See notes below for how this aspect of grid design effects the keyboard interaction design and the way that selection moves in response to focus movements.

  • Enter: Accepts the currently selected suggested value by closing the popup, placing the selected value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the combobox. Optionally, if the combobox is editable, clears the contents of the combobox.
  • Right Arrow: Moves focus one cell to the right. Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row. If focus is on the last cell in the grid, either does nothing or returns focus to the combobox.
  • Left Arrow: Moves focus one cell to the left. Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row. If focus is on the first cell in the grid, either does nothing or returns focus to the combobox.
  • Down Arrow: Moves focus one cell down. If focus is in the last row of the grid, either does nothing or returns focus to the combobox.
  • Up Arrow: Moves focus one cell up. If focus is in the first row of the grid, either does nothing or returns focus to the combobox.
  • Page Down (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.
  • Page Up (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.
  • Home (Optional): Either:
    • Moves focus to the first cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the first cell in the grid.
    • If the combobox is editable, returns focus to the combobox and places the cursor on the first character.
  • End (Optional): Either:
    • Moves focus to the last cell in the row that contains focus. Or, if the grid has fewer than three cells per row or multiple suggested values per row, focus may move to the last cell in the grid.
    • If the combobox is editable, returns focus to the combobox and places the cursor after the last character.
  • Control + Home (optional): moves focus to the first row.
  • Control + End (Optional): moves focus to the last row.
  • Any printable character: If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.
  • Backspace (Optional): If the combobox is editable, returns focus to the combobox and deletes the character prior to the cursor.
  • Delete (Optional): If the combobox is editable, returns focus to the combobox, removes the selected state if a suggestion was selected, and removes the inline autocomplete string if present.
Note
  1. DOM Focus is maintained on the combobox and the assistive technology focus is moved within the grid using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. The grid allows only one suggested value to be selected at a time for the combobox value.
  3. In a grid popup, each suggested value may be represented by either a single cell or an entire row. This aspect of design effects focus and selection movement:
    1. If every cell contains a different suggested value:
      • Selection follows focus so that the cell containing focus is selected.
      • Horizontal arrow key navigation typically wraps from one row to another.
      • Vertical arrow key navigation typically wraps from one column to another.
    2. If all cells in a row contain information about the same suggested value:
      • Either the row containing focus is selected or a cell containing a suggested value is selected when any cell in the same row contains focus.
      • Horizontal key navigation may wrap from one row to another.
      • Vertical arrow key navigation does not wrap from one column to another.
Tree Popup Keyboard Interaction

In some implementations of tree popups, some or all parent nodes may serve as suggestion category labels so may not be selectable values. See notes below for how this aspect of the design effects the way selection moves in response to focus movements.

When focus is in a vertically oriented tree popup:

  • Enter: Accepts the currently selected suggested value by closing the popup, placing the selected value in the combobox, and if the combobox is editable, placing the input cursor at the end of the value.
  • Escape: Closes the popup and returns focus to the combobox. Optionally, clears the contents of the combobox.
  • Right arrow:
    • When focus is on a closed node, opens the node; focus and selection do not move.
    • When focus is on a open node, moves focus to the first child node and selects it if it is selectable.
    • When focus is on an end node, does nothing.
  • Left arrow:
    • When focus is on an open node, closes the node.
    • When focus is on a child node that is also either an end node or a closed node, moves focus to its parent node and selects it if it is selectable.
    • When focus is on a root node that is also either an end node or a closed node, does nothing.
  • Down Arrow: Moves focus to the next node that is focusable without opening or closing a node and selects it if it is selectable.
  • Up Arrow: Moves focus to the previous node that is focusable without opening or closing a node and selects it if it is selectable.
  • Home: Moves focus to the first focusable node in the tree without opening or closing a node and selects it if it is selectable.
  • End: Moves focus to the last focusable node in the tree without opening or closing a node and selects it if it is selectable.
  • Any printable character:
    • If the combobox is editable, returns the focus to the combobox without closing the popup and types the character.
    • Otherwise, moves focus to the next suggested value with a name that starts with the characters typed.
Note
  1. DOM Focus is maintained on the combobox and the assistive technology focus is moved within the tree using aria-activedescendant as described in Managing Focus in Composites Using aria-activedescendant.
  2. The tree allows only one suggested value to be selected at a time for the combobox value.
  3. In a tree popup, some or all parent nodes may not be selectable values; they may serve as category labels for suggested values. If focus moves to a node that is not a selectable value, either:
    • The previously selected node, if any, remains selected until focus moves to a node that is selectable.
    • There is no selected value.
    • In either case, focus is visually distinct from selection so users can readily see if a value is selected or not.
  4. If nodes in the tree are arranged horizontally (aria-orientation is set to horizontal):
    1. Down Arrow performs as Right Arrow is described above, and vice versa.
    2. Up Arrow performs as Left Arrow is described above, and vice versa.
Dialog Popup Keyboard Interaction

When focus is in a dialog popup:

  • There are two ways to close the popup and return focus to the combobox:
    1. Perform an action in the dialog, such as activate a button, that specifies a value for the combobox.
    2. Cancel out of the dialog, e.g., press Escape or activate the cancel button in the dialog. Canceling either returns focus to the text box without changing the combobox value or returns focus to the combobox and clears the combobox.
  • The dialog implements the keyboard interaction defined in the modal dialog pattern.
Note

Unlike other combobox popups, dialogs do not support aria-activedescendant so DOM focus moves into the dialog from the combobox.

WAI-ARIA Roles, States, and Properties

  • The element that serves as an input and displays the combobox value has role combobox.
  • The combobox element has aria-controls set to a value that refers to the element that serves as the popup. Note that aria-controls only needs to be set when the popup is visible. However, it is valid to reference an element that is not visible.
  • The popup is an element that has role listbox, tree, grid, or dialog.
  • If the popup has a role other than listbox, the element with role combobox has aria-haspopup set to a value that corresponds to the popup type. That is, aria-haspopup is set to grid, tree, or dialog. Note that elements with role combobox have an implicit aria-haspopup value of listbox.
  • When the combobox popup is not visible, the element with role combobox has aria-expanded set to false. When the popup element is visible, aria-expanded is set to true. Note that elements with role combobox have a default value for aria-expanded of false.
  • When a combobox receives focus, DOM focus is placed on the combobox element.
  • When a descendant of a listbox, grid, or tree popup is focused, DOM focus remains on the combobox and the combobox has aria-activedescendant set to a value that refers to the focused element within the popup.
  • For a combobox that controls a listbox, grid, or tree popup, when a suggested value is visually indicated as the currently selected value, the option, gridcell, row, or treeitem containing that value has aria-selected set to true.
  • If the combobox has a visible label and the combobox element is an HTML element that can be labelled using the HTML label element (e.g., the input element), it is labeled using the label element. Otherwise, if it has a visible label, the combobox element has aria-labelledby set to a value that refers to the labelling element. Otherwise, the combobox element has a label provided by aria-label.
  • The combobox element has aria-autocomplete set to a value that corresponds to its autocomplete behavior:
    • none: When the popup is displayed, the suggested values it contains are the same regardless of the characters typed in the combobox.
    • list: When the popup is triggered, it presents suggested values. If the combobox is editable, the values complete or logically correspond to the characters typed in the combobox.
    • both: When the popup is triggered, it presents suggested values that complete or logically correspond to the characters typed in the combobox. In addition, the portion of the selected suggestion that has not been typed by the user, known as the completion string, appears inline after the input cursor in the combobox. The inline completion string is visually highlighted and has a selected state.
Note
  1. In ARIA 1.0, the combobox referenced its popup with aria-owns instead of aria-controls. While user agents might support comboboxes with aria-owns for backwards compatibility with legacy content, it is strongly recommended that authors use aria-controls.
  2. When referring to the roles, states, and properties documentation for the below list of patterns used for popups, keep in mind that a combobox is a single-select widget where selection follows focus in the popup.
  3. The roles, states, and properties for popup elements are defined in their respective design patterns:

3.9 Dialog (Modal)

A dialog is a window overlaid on either the primary window or another dialog window. Windows under a modal dialog are inert. That is, users cannot interact with content outside an active dialog window. Inert content outside an active dialog is typically visually obscured or dimmed so it is difficult to discern, and in some implementations, attempts to interact with the inert content cause the dialog to close.

Like non-modal dialogs, modal dialogs contain their tab sequence. That is, Tab and Shift + Tab do not move focus outside the dialog. However, unlike most non-modal dialogs, modal dialogs do not provide means for moving keyboard focus outside the dialog window without closing the dialog.

The alertdialog role is a special-case dialog role designed specifically for dialogs that divert users' attention to a brief, important message. Its usage is described in the alert dialog design pattern.

Examples

Keyboard Interaction

In the following description, the term tabbable element refers to any element with a tabindex value of zero or greater. Note that values greater than 0 are strongly discouraged.

  • When a dialog opens, focus moves to an element inside the dialog. See notes below regarding initial focus placement.
  • Tab:
    • Moves focus to the next tabbable element inside the dialog.
    • If focus is on the last tabbable element inside the dialog, moves focus to the first tabbable element inside the dialog.
  • Shift + Tab:
    • Moves focus to the previous tabbable element inside the dialog.
    • If focus is on the first tabbable element inside the dialog, moves focus to the last tabbable element inside the dialog.
  • Escape: Closes the dialog.
Note
  1. When a dialog opens, focus placement depends on the nature and size of the content.
    • In all circumstances, focus moves to an element contained in the dialog.
    • Unless a condition where doing otherwise is advisable, focus is initially set on the first focusable element.
    • If content is large enough that focusing the first interactive element could cause the beginning of content to scroll out of view, it is advisable to add tabindex=-1 to a static element at the top of the dialog, such as the dialog title or first paragraph, and initially focus that element.
    • If a dialog contains the final step in a process that is not easily reversible, such as deleting data or completing a financial transaction, it may be advisable to set focus on the least destructive action, especially if undoing the action is difficult or impossible. The Alert Dialog Pattern is often employed in such circumstances.
    • If a dialog is limited to interactions that either provide additional information or continue processing, it may be advisable to set focus to the element that is likely to be most frequently used, such as an OK or Continue button.
  2. When a dialog closes, focus returns to the element that invoked the dialog unless either:
    • The invoking element no longer exists. Then, focus is set on another element that provides logical work flow.
    • The work flow design includes the following conditions that can occasionally make focusing a different element a more logical choice:
      1. It is very unlikely users need to immediately re-invoke the dialog.
      2. The task completed in the dialog is directly related to a subsequent step in the work flow.
      For example, a grid has an associated toolbar with a button for adding rows. the Add Rows button opens a dialog that prompts for the number of rows. After the dialog closes, focus is placed in the first cell of the first new row.
  3. It is strongly recommended that the tab sequence of all dialogs include a visible element with role button that closes the dialog, such as a close icon or cancel button.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the dialog container has a role of dialog.
  • All elements required to operate the dialog are descendants of the element that has role dialog.
  • The dialog container element has aria-modal set to true.
  • The dialog has either:
  • Optionally, the aria-describedby property is set on the element with the dialog role to indicate which element or elements in the dialog contain content that describes the primary purpose or message of the dialog. Specifying descriptive elements enables screen readers to announce the description along with the dialog title and initially focused element when the dialog opens.
Note
  • Because marking a dialog modal by setting aria-modal to true can prevent users of some assistive technologies from perceiving content outside the dialog, users of those technologies will experience severe negative ramifications if a dialog is marked modal but does not behave as a modal for other users. So, mark a dialog modal only when both:
    1. Application code prevents all users from interacting in any way with content outside of it.
    2. Visual styling obscures the content outside of it.
  • The aria-modal property introduced by ARIA 1.1 replaces aria-hidden for informing assistive technologies that content outside a dialog is inert. However, in legacy dialog implementations where aria-hidden is used to make content outside a dialog inert for assistive technology users, it is important that:
    1. aria-hidden is set to true on each element containing a portion of the inert layer.
    2. The dialog element is not a descendant of any element that has aria-hidden set to true.

3.10 Disclosure (Show/Hide)

A disclosure is a button that controls visibility of a section of content. When the controlled content is hidden, it is often styled as a typical push button with a right-pointing arrow or triangle to hint that activating the button will display additional content. When the content is visible, the arrow or triangle typically points down.

Examples

Keyboard Interaction

When the disclosure control has focus:

  • Enter: activates the disclosure control and toggles the visibility of the disclosure content.
  • Space: activates the disclosure control and toggles the visibility of the disclosure content.

WAI-ARIA Roles, States, and Properties

  • The element that shows and hides the content has role button.
  • When the content is visible, the element with role button has aria-expanded set to true. When the content area is hidden, it is set to false.
  • Optionally, the element with role button has a value specified for aria-controls that refers to the element that contains all the content that is shown or hidden.

3.11 Feed

A feed is a section of a page that automatically loads new sections of content as the user scrolls. The sections of content in a feed are presented in article elements. So, a feed can be thought of as a dynamic list of articles that often appears to scroll infinitely.

The feature that most distinguishes feed from other ARIA patterns that support loading data as users scroll, e.g., a grid, is that a feed is a structure, not a widget. Consequently, assistive technologies with a reading mode, such as screen readers, default to reading mode when interacting with feed content. However, unlike most other WAI-ARIA structures, a feed establishes an interoperability contract between the web page and assistive technologies. The contract governs scroll interactions so that assistive technology users can read articles, jump forward and backward by article, and reliably trigger new articles to load while in reading mode.

For example, a product page on a shopping site may have a related products section that displays five products at a time. As the user scrolls, more products are requested and loaded into the DOM. While a static design might include a next button for loading five more products, a dynamic implementation that automatically loads more data as the user scrolls simplifies the user experience and reduces the inertia associated with viewing more than the first five product suggestions. But, unfortunately when web pages load content dynamically based on scroll events, it can cause usability and interoperability difficulties for users of assistive technologies.

The feed pattern enables reliable assistive technology reading mode interaction by establishing the following interoperability agreement between the web page and assistive technologies:

  1. In the context of a feed, the web page code is responsible for:
    • Appropriate visual scrolling of the content based on which article contains DOM focus.
    • Loading or removing feed articles based on which article contains DOM focus.
  2. In the context of a feed, assistive technologies with a reading mode are responsible for:
    • Indicating which article contains the reading cursor by ensuring the article element or one of its descendants has DOM focus.
    • providing reading mode keys that move DOM focus to the next and previous articles.
    • Providing reading mode keys for moving the reading cursor and DOM focus past the end and before the start of the feed.

Thus, implementing the feed pattern allows a screen reader to reliably read and trigger the loading of feed content while staying in its reading mode.

Another feature of the feed pattern is its ability to facilitate skim reading for assistive technology users. Web page authors may provide both an accessible name and description for each article. By identifying the elements inside of an article that provide the title and the primary content, assistive technologies can provide functions that enable users to jump from article to article and efficiently discern which articles may be worthy of more attention.

Example

Example Implementation of Feed Pattern

Keyboard Interaction

The feed pattern is not based on a desktop GUI widget so the feed role is not associated with any well-established keyboard conventions. Supporting the following, or a similar, interface is recommended.

When focus is inside the feed:

  • Page Down: Move focus to next article.
  • Page Up: Move focus to previous article.
  • Control + End: Move focus to the first focusable element after the feed.
  • Control + Home: Move focus to the first focusable element before the feed.
Note
  1. Due to the lack of convention, providing easily discoverable keyboard interface documentation is especially important.
  2. In some cases, a feed may contain a nested feed. For example, an article in a social media feed may contain a feed of comments on that article. To navigate the nested feed, users first move focus inside the nested feed. Options for supporting nested feed navigation include:
    • Users move focus into the nested feed from the content of the containing article with Tab. This may be slow if the article contains a significant number of links, buttons, or other widgets.
    • Provide a key for moving focus from the elements in the containing article to the first item in the nested feed, e.g., Alt + Page Down.
    • To continue reading the outer feed, Control + End moves focus to the next article in the outer feed.
  3. In the rare circumstance that a feed article contains a widget that uses the above suggested keys, the feed navigation key will operate the contained widget, and the user needs to move focus to an element that does not utilize the feed navigation keys in order to navigate the feed.

WAI-ARIA Roles, States, and Properties

  • The element that contains the set of feed articles has role feed.
  • If the feed has a visible label, the feed element has aria-labelledby referring to the element containing the title. Otherwise, the feed element has a label specified with aria-label.
  • Each unit of content in a feed is contained in an element with role article. All content inside the feed is contained in an article element.
  • Each article element has aria-labelledby referring to elements inside the article that can serve as a distinguishing label.
  • It is optional but strongly recommended for each article element to have aria-describedby referring to one or more elements inside the article that serve as the primary content of the article.
  • Each article element has aria-posinset set to a value that represents its position in the feed.
  • Each article element has aria-setsize set to a value that represents either the total number of articles that have been loaded or the total number in the feed, depending on which value is deemed more helpful to users. If the total number in the feed is undetermined, it can be represented by a aria-setsize value of -1.
  • When article elements are being added to or removed from the feed container, and if the operation requires multiple DOM operations, the feed element has aria-busy set to true during the update operation. Note that it is extremely important that aria-busy is set to false when the operation is complete or the changes may not become visible to some assistive technology users.

3.12 Grids : Interactive Tabular Data and Layout Containers

A grid widget is a container that enables users to navigate the information or interactive elements it contains using directional navigation keys, such as arrow keys, Home, and End. As a generic container widget that offers flexible keyboard navigation, it can serve a wide variety of needs. It can be used for purposes as simple as grouping a collection of checkboxes or navigation links or as complex as creating a full-featured spreadsheet application. While the words "row" and "column" are used in the names of WAI-ARIA attributes and by assistive technologies when describing and presenting the logical structure of elements with the grid role, using the grid role on an element does not necessarily imply that its visual presentation is tabular.

When presenting content that is tabular, consider the following factors when choosing between implementing this grid pattern or the table pattern.

Uses of the grid pattern broadly fall into two categories: presenting tabular information (data grids) and grouping other widgets (layout grids). Even though both data grids and layout grids employ the same ARIA roles, states, and properties, differences in their content and purpose surface factors that are important to consider in keyboard interaction design. To address these factors, the following two sections describe separate keyboard interaction patterns for data and layout grids.

Examples

  • Layout Grid Examples: Three example implementations of grids that are used to lay out widgets, including a collection of navigation links, a message recipients list, and a set of search results.
  • Data Grid Examples: Three example implementations of grid that include features relevant to presenting tabular information, such as content editing, sort, and column hiding.
  • Advanced Data Grid Example: Example of a grid with behaviors and features similar to a typical spreadsheet, including cell and row selection.

Data Grids For Presenting Tabular Information

A grid can be used to present tabular information that has column titles, row titles, or both. The grid pattern is particularly useful if the tabular information is editable or interactive. For example, when data elements are links to more information, rather than presenting them in a static table and including the links in the tab sequence, implementing the grid pattern provides users with intuitive and efficient keyboard navigation of the grid contents as well as a shorter tab sequence for the page. A grid may also offer functions, such as cell content editing, selection, cut, copy, and paste.

In a grid, every cell contains a focusable element or is itself focusable, regardless of whether the cell content is editable or interactive. There is one exception: if column or row header cells do not provide functions, such as sort or filter, they do not need to be focusable. One reason it is important for all cells to be able to receive or contain keyboard focus is that screen readers will typically be in their application reading mode, rather than their document reading mode, when users are interacting with the grid. While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements. So, screen reader users may unknowingly overlook elements contained in a grid that are either not focusable or not used to label a column or row.

Keyboard Interaction For Data Grids

The following keys provide grid navigation by moving focus among cells of the grid. Implementations of grid make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with Tab.

  • Right Arrow: Moves focus one cell to the right. If focus is on the right-most cell in the row, focus does not move.
  • Left Arrow: Moves focus one cell to the left. If focus is on the left-most cell in the row, focus does not move.
  • Down Arrow: Moves focus one cell down. If focus is on the bottom cell in the column, focus does not move.
  • Up Arrow: Moves focus one cell Up. If focus is on the top cell in the column, focus does not move.
  • Page Down: Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.
  • Page Up: Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.
  • Home: moves focus to the first cell in the row that contains focus.
  • End: moves focus to the last cell in the row that contains focus.
  • Control + Home: moves focus to the first cell in the first row.
  • Control + End: moves focus to the last cell in the last row.
Note
  • When the above grid navigation keys move focus, whether the focus is set on an element inside the cell or the grid cell depends on cell content. See Whether to Focus on a Cell or an Element Inside It.
  • While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell. If this functionality is needed, see Editing and Navigating Inside a Cell.
  • If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as control + End, may move focus to the last row in the DOM rather than the last available row in the back-end data.

If a grid supports selection of cells, rows, or columns, the following keys are commonly used for these functions.

  • Control + Space: selects the column that contains the focus.
  • Shift + Space: Selects the row that contains the focus. If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.
  • Control + A: Selects all cells.
  • Shift + Right Arrow: Extends selection one cell to the right.
  • Shift + Left Arrow: Extends selection one cell to the left.
  • Shift + Down Arrow: Extends selection one cell down.
  • Shift + Up Arrow: Extends selection one cell Up.
Note

See § 6.8 Key Assignment Conventions for Common Functions for cut, copy, and paste key assignments.

Layout Grids for Grouping Widgets

The grid pattern can be used to group a set of interactive elements, such as links, buttons, or checkboxes. Since only one element in the entire grid is included in the tab sequence, grouping with a grid can dramatically reduce the number of tab stops on a page. This is especially valuable if scrolling through a list of elements dynamically loads more of those elements from a large data set, such as in a continuous list of suggested products on a shopping site. If elements in a list like this were in the tab sequence, keyboard users are effectively trapped in the list. If any elements in the group also have associated elements that appear on hover, the grid pattern is also useful for providing keyboard access to those contextual elements of the user interface.

Unlike grids used to present data, A grid used for layout does not necessarily have header cells for labelling rows or columns and might contain only a single row or a single column. Even if it has multiple rows and columns, it may present a single, logically homogenous set of elements. For example, a list of recipients for a message may be a grid where each cell contains a link that represents a recipient. The grid may initially have a single row but then wrap into multiple rows as recipients are added. In such circumstances, grid navigation keys may also wrap so the user can read the list from beginning to end by pressing either Right Arrow or Down Arrow. While This type of focus movement wrapping can be very helpful in a layout grid, it would be disorienting if used in a data grid, especially for users of assistive technologies.

Because arrow keys are used to move focus inside of a grid, a grid is both easier to build and use if the components it contains do not require the arrow keys to operate. If a cell contains an element like a listbox, then an extra key command to focus and activate the listbox is needed as well as a command for restoring the grid navigation functionality. Approaches to supporting this need are described in the section on Editing and Navigating Inside a Cell.

Keyboard Interaction For Layout Grids

The following keys provide grid navigation by moving focus among cells of the grid. Implementations of grid make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with Tab.

  • Right Arrow: Moves focus one cell to the right. Optionally, if focus is on the right-most cell in the row, focus may move to the first cell in the following row. If focus is on the last cell in the grid, focus does not move.
  • Left Arrow: Moves focus one cell to the left. Optionally, if focus is on the left-most cell in the row, focus may move to the last cell in the previous row. If focus is on the first cell in the grid, focus does not move.
  • Down Arrow: Moves focus one cell down. Optionally, if focus is on the bottom cell in the column, focus may move to the top cell in the following column. If focus is on the last cell in the grid, focus does not move.
  • Up Arrow: Moves focus one cell up. Optionally, if focus is on the top cell in the column, focus may move to the bottom cell in the previous column. If focus is on the first cell in the grid, focus does not move.
  • Page Down (Optional): Moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row of the grid, focus does not move.
  • Page Up (Optional): Moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row of the grid, focus does not move.
  • Home: moves focus to the first cell in the row that contains focus. Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the first cell in the grid.
  • End: moves focus to the last cell in the row that contains focus. Optionally, if the grid has a single column or fewer than three cells per row, focus may instead move to the last cell in the grid.
  • Control + Home (optional): moves focus to the first cell in the first row.
  • Control + End (Optional): moves focus to the last cell in the last row.
Note
  • When the above grid navigation keys move focus, whether the focus is set on an element inside the cell or the grid cell depends on cell content. See Whether to Focus on a Cell or an Element Inside It.
  • While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell. If this functionality is needed, see Editing and Navigating Inside a Cell.
  • If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as control + End, may move focus to the last row in the DOM rather than the last available row in the back-end data.

It would be unusual for a layout grid to provide functions that require cell selection. If it did, though, the following keys are commonly used for these functions.

  • Control + Space: selects the column that contains the focus.
  • Shift + Space: Selects the row that contains the focus. If the grid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.
  • Control + A: Selects all cells.
  • Shift + Right Arrow: Extends selection one cell to the right.
  • Shift + Left Arrow: Extends selection one cell to the left.
  • Shift + Down Arrow: Extends selection one cell down.
  • Shift + Up Arrow: Extends selection one cell Up.
Note

See § 6.8 Key Assignment Conventions for Common Functions for cut, copy, and paste key assignments.

Keyboard Interaction - Setting Focus and Navigating Inside Cells

This section describes two important aspects of keyboard interaction design shared by both data and layout grid patterns:

  1. Choosing whether a cell or an element inside a cell receives focus in response to grid navigation key events.
  2. Enabling grid navigation keys to be used to interact with elements inside of a cell.
Whether to Focus on a Cell Or an Element Inside It

For assistive technology users, the quality of experience when navigating a grid heavily depends on both what a cell contains and on where keyboard focus is set. For example, if a cell contains a button and a grid navigation key places focus on the cell instead of the button, screen readers announce the button label but do not tell users a button is present.

There are two optimal cell design and focus behavior combinations:

  1. A cell contains one widget whose operation does not require arrow keys and grid navigation keys set focus on that widget. Examples of such widgets include link, button, menubutton, toggle button, radio button (not radio group), switch, and checkbox.
  2. A cell contains text or a single graphic and grid navigation keys set focus on the cell.

While any combination of widgets, text, and graphics may be included in a single cell, grids that do not follow one of these two cell design and focus movement patterns add complexity for authors or users or both. The reference implementations included in the example section below demonstrate some strategies for making other cell designs as accessible as possible, but the most widely accessible experiences are likely to come by applying the above two patterns.

Editing and Navigating Inside a Cell

While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to perform actions like operate a combobox or move an editing caret inside of a cell. The user may need keys that are used for grid navigation to operate elements inside a cell if a cell contains:

  1. Editable content.
  2. Multiple widgets.
  3. A widget that utilizes arrow keys in its interaction model, such as a radio group or slider.

Following are common keyboard conventions for disabling and restoring grid navigation functions.

  • Enter: Disables grid navigation and:
    • If the cell contains editable content, places focus in an input field, such as a textbox. If the input is a single-line text field, a subsequent press of Enter may either restore grid navigation functions or move focus to an input field in a neighboring cell.
    • If the cell contains one or more widgets, places focus on the first widget.
  • F2:
    • If the cell contains editable content, places focus in an input field, such as a textbox. A subsequent press of F2 restores grid navigation functions.
    • If the cell contains one or more widgets, places focus on the first widget. A subsequent press of F2 restores grid navigation functions.
  • Alphanumeric keys: If the cell contains editable content, places focus in an input field, such as a textbox.

When grid navigation is disabled, conventional changes to navigation behaviors include:

  • Escape: restores grid navigation. If content was being edited, it may also undo edits.
  • Right Arrow or Down Arrow: If the cell contains multiple widgets, moves focus to the next widget inside the cell, optionally wrapping to the first widget if focus is on the last widget. Otherwise, passes the key event to the focused widget.
  • Left Arrow or Up Arrow: If the cell contains multiple widgets, moves focus to the previous widget inside the cell, optionally wrapping to the first widget if focus is on the last widget. Otherwise, passes the key event to the focused widget.
  • Tab: moves focus to the next widget in the grid. Optionally, the focus movement may wrap inside a single cell or within the grid itself.
  • Shift + Tab: moves focus to the previous widget in the grid. Optionally, the focus movement may wrap inside a single cell or within the grid itself.

WAI-ARIA Roles, States, and Properties

  • The grid container has role grid.
  • Each row container has role row and is either a DOM descendant of or owned by the grid element or an element with role rowgroup.
  • Each cell is either a DOM descendant of or owned by a row element and has one of the following roles:
    • columnheader if the cell contains a title or header information for the column.
    • rowheader if the cell contains title or header information for the row.
    • gridcell if the cell does not contain column or row header information.
  • If there is an element in the user interface that serves as a label for the grid, aria-labelledby is set on the grid element with a value that refers to the labelling element. Otherwise, a label is specified for the grid element using aria-label.
  • If the grid has a caption or description, aria-describedby is set on the grid element with a value referring to the element containing the description.
  • If the grid provides sort functions, aria-sort is set to an appropriate value on the header cell element for the sorted column or row as described in the section on grid and table properties.
  • If the grid supports selection, when a cell or row is selected, the selected element has aria-selected set true. If the grid supports column selection and a column is selected, all cells in the column have aria-selected set to true.
  • If the grid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, aria-readonly may be set true on cells where editing is disabled. If edit functions are disabled for all cells, aria-readonly may be set true on the grid element. Grids that do not provide editing functions do not include the aria-readonly attribute on any of their elements.
  • If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., data is dynamically loaded when scrolling or the grid provides functions for hiding rows or columns, the following properties are applied as described in the section on grid and table properties.
  • If the grid includes cells that span multiple rows or multiple columns, and if the grid role is NOT applied to an HTML table element, then aria-rowspan or aria-colspan is applied as described in grid and table properties.
Note
  • If the element with the grid role is an HTML table element, then it is not necessary to use ARIA roles for rows and cells because the HTML elements have implied ARIA semantics. For example, an HTML <TR> has an implied ARIA role of row. A grid built from an HTML table that includes cells that span multiple rows or columns must use HTML rowspan and colspan and must not use aria-rowspan or aria-colspan.
  • If rows or cells are included in a grid via aria-owns, they will be presented to assistive technologies after the DOM descendants of the grid element unless the DOM descendants are also included in the aria-owns attribute.

3.14 Listbox

A listbox widget presents a list of options and allows a user to select one or more of them. A listbox that allows a single option to be chosen is a single-select listbox; one that allows multiple options to be selected is a multi-select listbox.

When screen readers present a listbox, they may render the name, state, and position of each option in the list. The name of an option is a string calculated by the browser, typically from the content of the option element. As a flat string, the name does not contain any semantic information. Thus, if an option contains a semantic element, such as a heading, screen reader users will not have access to the semantics. In addition, the interaction model conveyed by the listbox role to assistive technologies does not support interacting with elements inside of an option. Because of these traits of the listbox widget, it does not provide an accessible way to present a list of interactive elements, such as links, buttons, or checkboxes. To present a list of interactive elements, see the grid pattern.

Avoiding very long option names facilitates understandability and perceivability for screen reader users. The entire name of an option is spoken as a single unit of speech when the option is read. When too much information is spoken as the result of a single key press, it is difficult to understand. Long names inhibit perception by increasing the impact of interrupted speech because users typically have to re-read the entire option. And, if the user does not understand what is spoken, reading the name by character, word, or phrase may be a difficult operation for many screen reader users in the context of a listbox widget.

Sets of options where each option name starts with the same word or phrase can also significantly degrade usability for keyboard and screen reader users. Scrolling through the list to find a specific option becomes inordinately time consuming for a screen reader user who must listen to that word or phrase repeated before hearing what is unique about each option. For example, if a listbox for choosing a city were to contain options where each city name were preceded by a country name, and if many cities were listed for each country, a screen reader user would have to listen to the country name before hearing each city name. In such a scenario, it would be better to have 2 list boxes, one for country and one for city.

Examples

Keyboard Interaction

For a vertically oriented listbox:

  • When a single-select listbox receives focus:
    • If none of the options are selected before the listbox receives focus, the first option receives focus. Optionally, the first option may be automatically selected.
    • If an option is selected before the listbox receives focus, focus is set on the selected option.
  • When a multi-select listbox receives focus:
    • If none of the options are selected before the listbox receives focus, focus is set on the first option and there is no automatic change in the selection state.
    • If one or more options are selected before the listbox receives focus, focus is set on the first option in the list that is selected.
  • Down Arrow: Moves focus to the next option. Optionally, in a single-select listbox, selection may also move with focus.
  • Up Arrow: Moves focus to the previous option. Optionally, in a single-select listbox, selection may also move with focus.
  • Home (Optional): Moves focus to first option. Optionally, in a single-select listbox, selection may also move with focus. Supporting this key is strongly recommended for lists with more than five options.
  • End (Optional): Moves focus to last option. Optionally, in a single-select listbox, selection may also move with focus. Supporting this key is strongly recommended for lists with more than five options.
  • Type-ahead is recommended for all listboxes, especially those with more than seven options:
    • Type a character: focus moves to the next item with a name that starts with the typed character.
    • Type multiple characters in rapid succession: focus moves to the next item with a name that starts with the string of characters typed.
  • Multiple Selection: Authors may implement either of two interaction models to support multiple selection: a recommended model that does not require the user to hold a modifier key, such as Shift or Control, while navigating the list or an alternative model that does require modifier keys to be held while navigating in order to avoid losing selection states.
    • Recommended selection model -- holding modifier keys is not necessary:
      • Space: changes the selection state of the focused option.
      • Shift + Down Arrow (Optional): Moves focus to and toggles the selected state of the next option.
      • Shift + Up Arrow (Optional): Moves focus to and toggles the selected state of the previous option.
      • Shift + Space (Optional): Selects contiguous items from the most recently selected item to the focused item.
      • Control + Shift + Home (Optional): Selects the focused option and all options up to the first option. Optionally, moves focus to the first option.
      • Control + Shift + End (Optional): Selects the focused option and all options down to the last option. Optionally, moves focus to the last option.
      • Control + A (Optional): Selects all options in the list. Optionally, if all options are selected, it may also unselect all options.
    • Alternative selection model -- moving focus without holding a Shift or Control modifier unselects all selected nodes except the focused node:
      • Shift + Down Arrow: Moves focus to and toggles the selection state of the next option.
      • Shift + Up Arrow: Moves focus to and toggles the selection state of the previous option.
      • Control + Down Arrow: Moves focus to the next option without changing its selection state.
      • Control + Up Arrow: Moves focus to the previous option without changing its selection state.
      • Control + Space Changes the selection state of the focused option.
      • Shift + Space (Optional): Selects contiguous items from the most recently selected item to the focused item.
      • Control + Shift + Home (Optional): Selects the focused option and all options up to the first option. Optionally, moves focus to the first option.
      • Control + Shift + End (Optional): Selects the focused option and all options down to the last option. Optionally, moves focus to the last option.
      • Control + A (Optional): Selects all options in the list. Optionally, if all options are selected, it may also unselect all options.
Note
  1. DOM focus (the active element) is functionally distinct from the selected state. For more details, see this description of differences between focus and selection.
  2. The listbox role supports the aria-activedescendant property, which provides an alternative to moving DOM focus among option elements when implementing keyboard navigation. For details, see Managing Focus in Composites Using aria-activedescendant.
  3. In a single-select listbox, moving focus may optionally unselect the previously selected option and select the newly focused option. This model of selection is known as "selection follows focus". Having selection follow focus can be very helpful in some circumstances and can severely degrade accessibility in others. For additional guidance, see Deciding When to Make Selection Automatically Follow Focus.
  4. If selecting or unselecting all options is an important function, implementing separate controls for these actions, such as buttons for "Select All" and "Unselect All", significantly improves accessibility.
  5. If the options in a listbox are arranged horizontally:
    1. Down Arrow performs as Right Arrow is described above, and vice versa.
    2. Up Arrow performs as Left Arrow is described above, and vice versa.

WAI-ARIA Roles, States, and Properties

  • An element that contains or owns all the listbox options has role listbox.
  • Each option in the listbox has role option and is a DOM descendant of the element with role listbox or is referenced by an aria-owns property on the listbox element.
  • If the listbox is not part of another widget, then it has a visible label referenced by aria-labelledby on the element with role listbox.
  • In a single-select listbox, the selected option has aria-selected set to true.
  • if the listbox supports multiple selection:
  • If the complete set of available options is not present in the DOM due to dynamic loading as the user scrolls, their aria-setsize and aria-posinset attributes are set appropriately.
  • If options are arranged horizontally, the element with role listbox has aria-orientation set to horizontal. The default value of aria-orientation for listbox is vertical.

3.17 Meter

A meter is a graphical display of a numeric value that varies within a defined range. For example, a meter could be used to depict a device's current battery percentage or a car's fuel level.

Note
  • A meter should not be used to represent a value like the current world population since it does not have a meaningful maximum limit.
  • The meter should not be used to indicate progress, such as loading or percent completion of a task. To communicate progress, use the progressbar role instead.

Example

Meter Example

Keyboard Interaction

Not applicable.

WAI-ARIA Roles, States, and Properties

  • The element serving as the meter has a role of meter.
  • The meter has aria-valuenow set to a decimal value between aria-valuemin and aria-valuemax representing the current value of the meter.
  • The meter has aria-valuemin set to a decimal value less than aria-valuemax.
  • The meter has aria-valuemax set to a decimal value greater than aria-valuemin.
  • Assistive technologies often present aria-valuenow as a percentage. If conveying the value of the meter only in terms of a percentage would not be user friendly, the aria-valuetext property is set to a string that makes the meter value understandable. For example, a battery meter value might be conveyed as aria-valuetext="50% (6 hours) remaining".
  • If the meter has a visible label, it is referenced by aria-labelledby on the element with role meter. Otherwise, the element with role meter has a label provided by aria-label.

3.18 Radio Group

A radio group is a set of checkable buttons, known as radio buttons, where no more than one of the buttons can be checked at a time. Some implementations may initialize the set with all buttons in the unchecked state in order to force the user to check one of the buttons before moving past a certain point in the workflow.

Examples

Keyboard Interaction

For Radio Groups Not Contained in a Toolbar

This section describes the keyboard interaction implemented for most radio groups. For the special case of a radio group nested inside a toolbar, use the keyboard interaction described in the following section.

  • Tab and Shift + Tab: Move focus into and out of the radio group. When focus moves into a radio group :
    • If a radio button is checked, focus is set on the checked button.
    • If none of the radio buttons are checked, focus is set on the first radio button in the group.
  • Space: checks the focused radio button if it is not already checked.
  • Right Arrow and Down Arrow: move focus to the next radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the last button, focus moves to the first button.
  • Left Arrow and Up Arrow: move focus to the previous radio button in the group, uncheck the previously focused button, and check the newly focused button. If focus is on the first button, focus moves to the last button.
Note

The initial focus behavior described above differs slightly from the behavior provided by some browsers for native HTML radio groups. In some browsers, if none of the radio buttons are selected, moving focus into the radio group with Shift+Tab will place focus on the last radio button instead of the first radio button.

For Radio Group Contained in a Toolbar

Because arrow keys are used to navigate among elements of a toolbar and the Tab key moves focus in and out of a toolbar, when a radio group is nested inside a toolbar, the keyboard interaction of the radio group is slightly different from that of a radio group that is not inside of a toolbar. For instance, users need to be able to navigate among all toolbar elements, including the radio buttons, without changing which radio button is checked. So, when navigating through a radio group in a toolbar with arrow keys, the button that is checked does not change. The keyboard interaction of a radio group nested in a toolbar is as follows.

  • Space: If the focused radio button is not checked, unchecks the currently checked radio button and checks the focused radio button. Otherwise, does nothing.
  • Enter (optional): If the focused radio button is not checked, unchecks the currently checked radio button and checks the focused radio button. Otherwise, does nothing.
  • Right Arrow:
    • When focus is on a radio button and that radio button is not the last radio button in the radio group, moves focus to the next radio button.
    • When focus is on the last radio button in the radio group and that radio button is not the last element in the toolbar, moves focus to the next element in the toolbar.
    • When focus is on the last radio button in the radio group and that radio button is also the last element in the toolbar, moves focus to the first element in the toolbar.
  • Left Arrow:
    • When focus is on a radio button and that radio button is not the first radio button in the radio group, moves focus to the previous radio button.
    • When focus is on the first radio button in the radio group and that radio button is not the first element in the toolbar, moves focus to the previous element in the toolbar.
    • When focus is on the first radio button in the radio group and that radio button is also the first element in the toolbar, moves focus to the last element in the toolbar.
  • Down Arrow (optional): Moves focus to the next radio button in the radio group. If focus is on the last radio button in the radio group, moves focus to the first radio button in the group.
  • Up Arrow (optional): Moves focus to the previous radio button in the radio group. If focus is on the first radio button in the radio group, moves focus to the last radio button in the group.
Note

Radio buttons in a toolbar are frequently styled in a manner that appears more like toggle buttons. For an example, See the Simple Editor Toolbar Example

WAI-ARIA Roles, States, and Properties

  • The radio buttons are contained in or owned by an element with role radiogroup.
  • Each radio button element has role radio.
  • If a radio button is checked, the radio element has aria-checked set to true. If it is not checked, it has aria-checked set to false.
  • Each radio element is labelled by its content, has a visible label referenced by aria-labelledby, or has a label specified with aria-label.
  • The radiogroup element has a visible label referenced by aria-labelledby or has a label specified with aria-label.
  • If elements providing additional information about either the radio group or each radio button are present, those elements are referenced by the radiogroup element or radio elements with the aria-describedby property.

3.19 Slider

A slider is an input where the user selects a value from within a given range. Sliders typically have a slider thumb that can be moved along a bar or track to change the value of the slider.

Examples

Keyboard Interaction

  • Right Arrow: Increase the value of the slider by one step.
  • Up Arrow: Increase the value of the slider by one step.
  • Left Arrow: Decrease the value of the slider by one step.
  • Down Arrow: Decrease the value of the slider by one step.
  • Home: Set the slider to the first allowed value in its range.
  • End: Set the slider to the last allowed value in its range.
  • Page Up (Optional): Increment the slider by an amount larger than the step change made by Up Arrow.
  • Page Down (Optional): Decrement the slider by an amount larger than the step change made by Down Arrow.
Note
  1. Focus is placed on the slider (the visual object that the mouse user would move, also known as the thumb.
  2. In some circumstances, reversing the direction of the value change for the keys specified above, e.g., having Up Arrow decrease the value, could create a more intuitive experience.

WAI-ARIA Roles, States, and Properties

  • The element serving as the focusable slider control has role slider.
  • The slider element has the aria-valuenow property set to a decimal value representing the current value of the slider.
  • The slider element has the aria-valuemin property set to a decimal value representing the minimum allowed value of the slider.
  • The slider element has the aria-valuemax property set to a decimal value representing the maximum allowed value of the slider.
  • If the value of aria-valuenow is not user-friendly, e.g., the day of the week is represented by a number, the aria-valuetext property is set to a string that makes the slider value understandable, e.g., "Monday".
  • If the slider has a visible label, it is referenced by aria-labelledby on the slider element. Otherwise, the slider element has a label provided by aria-label.
  • If the slider is vertically oriented, it has aria-orientation set to vertical. The default value of aria-orientation for a slider is horizontal.

3.20 Slider (Multi-Thumb)

A multi-thumb slider is a slider with two or more thumbs that each set a value in a group of related values. For example, in a product search, a two-thumb slider could be used to enable users to set the minimum and maximum price limits for the search. In many two-thumb sliders, the thumbs are not allowed to pass one another, such as when the slider sets the minimum and maximum values for a range. For example, in a price range selector, the maximum value of the thumb that sets the lower end of the range is limited by the current value of the thumb that sets the upper end of the range. Conversely, the minimum value of the upper end thumb is limited by the current value of the lower end thumb. However, in some multi-thumb sliders, each thumb sets a value that does not depend on the other thumb values.

Example

Multi-Thumb Slider Examples: Demonstrates two-thumb sliders for picking price ranges for an airline flight and hotel reservation.

Keyboard Interaction

  • Each thumb is in the page tab sequence and has the same keyboard interaction as a single-thumb slider.
  • The tab order remains constant regardless of thumb value and visual position within the slider. For example, if the value of a thumb changes such that it moves past one of the other thumbs, the tab order does not change.

WAI-ARIA Roles, States, and Properties

  • Each element serving as a focusable slider thumb has role slider.
  • Each slider element has the aria-valuenow property set to a decimal value representing the current value of the slider.
  • Each slider element has the aria-valuemin property set to a decimal value representing the minimum allowed value of the slider.
  • Each slider element has the aria-valuemax property set to a decimal value representing the maximum allowed value of the slider.
  • When the range (e.g. minimum and/or maximum value) of another slider is dependent on the current value of a slider, the values of aria-valuemin or aria-valuemax of the dependent sliders are updated when the value changes.
  • If a value of aria-valuenow is not user-friendly, e.g., the day of the week is represented by a number, the aria-valuetext property is set to a string that makes the slider value understandable, e.g., "Monday".
  • If a slider has a visible label, it is referenced by aria-labelledby on the slider element. Otherwise, the slider element has a label provided by aria-label.
  • If a slider is vertically oriented, it has aria-orientation set to vertical. The default value of aria-orientation for a slider is horizontal.

3.21 Spinbutton

A spinbutton is an input widget that restricts its value to a set or range of discrete values. For example, in a widget that enables users to set an alarm, a spinbutton could allow users to select a number from 0 to 59 for the minute of an hour.

Spinbuttons often have three components, including a text field that displays the current value, an increment button, and a decrement button. The text field is usually the only focusable component because the increment and decrement functions are keyboard accessible via arrow keys. Typically, the text field also allows users to directly edit the value.

If the range is large, a spinbutton may support changing the value in both small and large steps. For instance, in the alarm example, the user may be able to move by 1 minute with Up Arrow and Down Arrow and by 10 minutes with Page Up and Page Down.

Example

Date Picker Spin Button Example: Illustrates a date picker made from three spin buttons for day, month, and year.

Keyboard Interaction

  • Up Arrow: Increases the value.
  • Down Arrow: Decreases the value.
  • Home: If the spinbutton has a minimum value, sets the value to its minimum.
  • End: If the spinbutton has a maximum value, sets the value to its maximum.
  • Page Up (Optional): Increases the value by a larger step than Up Arrow.
  • Page Down (Optional): Decreases the value by a larger step than Down Arrow.
  • If the spinbutton text field allows directly editing the value, the following keys are supported:
    • Standard single line text editing keys appropriate for the device platform (see note below).
    • Printable Characters: Type characters in the textbox. Note that many implementations allow only certain characters as part of the value and prevent input of any other characters. For example, an hour-and-minute spinner would allow only integer values from 0 to 59, the colon ':', and the letters 'AM' and 'PM'. Any other character input does not change the contents of the text field nor the value of the spinbutton.
Note
  1. Focus remains on the text field during operation.
  2. Standard single line text editing keys appropriate for the device platform:
    1. include keys for input, cursor movement, selection, and text manipulation.
    2. Standard key assignments for editing functions depend on the device operating system.
    3. The most robust approach for providing text editing functions is to rely on browsers, which supply them for HTML inputs with type text and for elements with the contenteditable HTML attribute.
    4. IMPORTANT: Be sure that JavaScript does not interfere with browser-provided text editing functions by capturing key events for the keys used to perform them.

WAI-ARIA Roles, States, and Properties

  • The focusable element serving as the spinbutton has role spinbutton. This is typically an element that supports text input.
  • The spinbutton element has the aria-valuenow property set to a decimal value representing the current value of the spinbutton.
  • The spinbutton element has the aria-valuemin property set to a decimal value representing the minimum allowed value of the spinbutton if it has a known minimum value.
  • The spinbutton element has the aria-valuemax property set to a decimal value representing the maximum allowed value of the spinbutton if it has a known maximum value.
  • If the value of aria-valuenow is not user-friendly, e.g., the day of the week is represented by a number, the aria-valuetext property is set on the spinbutton element to a string that makes the spinbutton value understandable, e.g., "Monday".
  • If the spinbutton has a visible label, it is referenced by aria-labelledby on the spinbutton element. Otherwise, the spinbutton element has a label provided by aria-label.
  • The spinbutton element has aria-invalid set to true if the value is outside the allowed range. Note that most implementations prevent input of invalid values, but in some scenarios, blocking all invalid input may not be practical.

3.22 Table

Like an HTML table element, a WAI-ARIA table is a static tabular structure containing one or more rows that each contain one or more cells; it is not an interactive widget. Thus, its cells are not focusable or selectable. The grid pattern is used to make an interactive widget that has a tabular structure.

However, tables are often used to present a combination of information and interactive widgets. Since a table is not a widget, each widget contained in a table is a separate stop in the page tab sequence. If the number of widgets is large, replacing the table with a grid can dramatically reduce the length of the page tab sequence because a grid is a composite widget that can contain other widgets.

Note

As with other WAI-ARIA roles that have a native host language equivalent, authors are strongly encouraged to use a native HTML table element whenever possible. This is especially important with role table because it is a new feature of WAI-ARIA 1.1. It is thus advisable to test implementations thoroughly with each browser and assistive technology combination that could be used by the target audience.

Examples

Table Example: ARIA table made using HTML div and span elements.

Keyboard Interaction

Not applicable.

WAI-ARIA Roles, States, and Properties

  • The table container has role table.
  • Each row container has role row and is either a DOM descendant of or owned by the table element or an element with role rowgroup.
  • Each cell is either a DOM descendant of or owned by a row element and has one of the following roles:
    • columnheader if the cell contains a title or header information for the column.
    • rowheader if the cell contains title or header information for the row.
    • cell if the cell does not contain column or row header information.
  • If there is an element in the user interface that serves as a label for the table, aria-labelledby is set on the table element with a value that refers to the labelling element. Otherwise, a label is specified for the table element using aria-label.
  • If the table has a caption or description, aria-describedby is set on the table element with a value referring to the element containing the description.
  • If the table contains sortable columns or rows, aria-sort is set to an appropriate value on the header cell element for the sorted column or row as described in the section on grid and table properties.
  • If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., there are widgets on the page for hiding rows or columns, the following properties are applied as described in the section on grid and table properties.
  • If the table includes cells that span multiple rows or multiple columns, then aria-rowspan or aria-colspan is applied as described in grid and table properties.
Note

If rows or cells are included in a table via aria-owns, they will be presented to assistive technologies after the DOM descendants of the table element unless the DOM descendants are also included in the aria-owns attribute.

3.23 Tabs

Tabs are a set of layered sections of content, known as tab panels, that display one panel of content at a time. Each tab panel has an associated tab element, that when activated, displays the panel. The list of tab elements is arranged along one edge of the currently displayed panel, most commonly the top edge.

Terms used to describe this design pattern include:

Tabs or Tabbed Interface
A set of tab elements and their associated tab panels.
Tab List
A set of tab elements contained in a tablist element.
tab
An element in the tab list that serves as a label for one of the tab panels and can be activated to display that panel.
tabpanel
The element that contains the content associated with a tab.

When a tabbed interface is initialized, one tab panel is displayed and its associated tab is styled to indicate that it is active. When the user activates one of the other tab elements, the previously displayed tab panel is hidden, the tab panel associated with the activated tab becomes visible, and the tab is considered "active".

Examples

Keyboard Interaction

For the tab list:

  • Tab: When focus moves into the tab list, places focus on the active tab element. When the tab list contains the focus, moves focus to the next element in the page tab sequence outside the tablist, which is typically either the first focusable element inside the tab panel or the tab panel itself.
  • When focus is on a tab element in a horizontal tab list:
    • Left Arrow: moves focus to the previous tab. If focus is on the first tab, moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
    • Right Arrow: Moves focus to the next tab. If focus is on the last tab element, moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
  • When focus is on a tab in a tablist with either horizontal or vertical orientation:
    • Space or Enter: Activates the tab if it was not activated automatically on focus.
    • Home (Optional): Moves focus to the first tab. Optionally, activates the newly focused tab (See note below).
    • End (Optional): Moves focus to the last tab. Optionally, activates the newly focused tab (See note below).
    • Shift + F10: If the tab has an associated popup menu, opens the menu.
    • Delete (Optional): If deletion is allowed, deletes (closes) the current tab element and its associated tab panel, sets focus on the tab following the tab that was closed, and optionally activates the newly focused tab. If there is not a tab that followed the tab that was deleted, e.g., the deleted tab was the right-most tab in a left-to-right horizontal tab list, sets focus on and optionally activates the tab that preceded the deleted tab. If the application allows all tabs to be deleted, and the user deletes the last remaining tab in the tab list, the application moves focus to another element that provides a logical work flow. As an alternative to Delete, or in addition to supporting Delete, the delete function is available in a context menu.
Note
  1. It is recommended that tabs activate automatically when they receive focus as long as their associated tab panels are displayed without noticeable latency. This typically requires tab panel content to be preloaded. Otherwise, automatic activation slows focus movement, which significantly hampers users' ability to navigate efficiently across the tab list. For additional guidance, see § 6.4 초점을 따라 자동으로 선택되게 하는 시기 결정.
  2. When a tab list has its aria-orientation set to vertical:
    1. Down Arrow performs as Right Arrow is described above.
    2. Up Arrow performs as Left Arrow is described above.
  3. If the tab list is horizontal, it does not listen for Down Arrow or Up Arrow so those keys can provide their normal browser scrolling functions even when focus is inside the tab list.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the container for the set of tabs has role tablist.
  • Each element that serves as a tab has role tab and is contained within the element with role tablist.
  • Each element that contains the content panel for a tab has role tabpanel.
  • If the tab list has a visible label, the element with role tablist has aria-labelledby set to a value that refers to the labelling element. Otherwise, the tablist element has a label provided by aria-label.
  • Each element with role tab has the property aria-controls referring to its associated tabpanel element.
  • The active tab element has the state aria-selected set to true and all other tab elements have it set to false.
  • Each element with role tabpanel has the property aria-labelledby referring to its associated tab element.
  • If a tab element has a popup menu, it has the property aria-haspopup set to either menu or true.
  • If the tablist element is vertically oriented, it has the property aria-orientation set to vertical. The default value of aria-orientation for a tablist element is horizontal.

3.24 Toolbar

A toolbar is a container for grouping a set of controls, such as buttons, menubuttons, or checkboxes.

When a set of controls is visually presented as a group, the toolbar role can be used to communicate the presence and purpose of the grouping to screen reader users. Grouping controls into toolbars can also be an effective way of reducing the number of tab stops in the keyboard interface.

To optimize the benefit of toolbar widgets:

Example

Toolbar Example: A toolbar that uses roving tabindex to manage focus and contains several types of controls, including toggle buttons, radio buttons, a menu button, a spin button, a checkbox, and a link.

Keyboard Interaction

  • Tab and Shift + Tab: Move focus into and out of the toolbar. When focus moves into a toolbar:
    • If focus is moving into the toolbar for the first time, focus is set on the first control that is not disabled.
    • If the toolbar has previously contained focus, focus is optionally set on the control that last had focus. Otherwise, it is set on the first control that is not disabled.
  • For a horizontal toolbar (the default):
    • Left Arrow: Moves focus to the previous control. Optionally, focus movement may wrap from the first element to the last element.
    • Right Arrow: Moves focus to the next control. Optionally, focus movement may wrap from the last element to the first element.
  • Home (Optional): Moves focus to first element.
  • End (Optional): Moves focus to last element.
Note
  1. If the items in a toolbar are arranged vertically:
    1. Down Arrow performs as Right Arrow is described above.
    2. Up Arrow performs as Left Arrow is described above.
  2. Typically, disabled elements are not focusable when navigating with a keyboard. However, in circumstances where discoverability of a function is crucial, it may be helpful if disabled controls are focusable so screen reader users are more likely to be aware of their presence. For additional guidance, see § 6.7 Focusability of disabled controls.
  3. In applications where quick access to a toolbar is important, such as accessing an editor's toolbar from its text area, a documented shortcut key for moving focus from the relevant context to its corresponding toolbar is recommended.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the toolbar container has role toolbar.
  • If the toolbar has a visible label, it is referenced by aria-labelledby on the toolbar element. Otherwise, the toolbar element has a label provided by aria-label.
  • If the controls are arranged vertically, the toolbar element has aria-orientation set to vertical. The default orientation is horizontal.

3.25 Tooltip Widget

NOTE: This design pattern is work in progress; it does not yet have task force consensus. Progress and discussions are captured in issue 128.

A tooltip is a popup that displays information related to an element when the element receives keyboard focus or the mouse hovers over it. It typically appears after a small delay and disappears when Escape is pressed or on mouse out.

Tooltip widgets do not receive focus. A hover that contains focusable elements can be made using a non-modal dialog.

Example

Work to develop a tooltip example is tracked by issue 127.

Keyboard Interaction

Escape: Dismisses the Tooltip.

Note
  1. Focus stays on the triggering element while the tooltip is displayed.
  2. If the tooltip is invoked when the trigger element receives focus, then it is dismissed when it no longer has focus (onBlur). If the tooltip is invoked with mouseIn, then it is dismissed with on mouseOut.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the tooltip container has role tooltip.
  • The element that triggers the tooltip references the tooltip element with aria-describedby.

3.26 Tree View

A tree view widget presents a hierarchical list. Any item in the hierarchy may have child items, and items that have children may be expanded or collapsed to show or hide the children. For example, in a file system navigator that uses a tree view to display folders and files, an item representing a folder can be expanded to reveal the contents of the folder, which may be files, folders, or both.

Terms for understanding tree views include:

Node
An item in a tree.
Root Node
Node at the base of the tree; it may have one or more child nodes but does not have a parent node.
Child Node
Node that has a parent; any node that is not a root node is a child node.
End Node
Node that does not have any child nodes; an end node may be either a root node or a child node.
Parent Node
Node with one or more child nodes. It can be open (expanded) or closed (collapsed).
Open Node
Parent node that is expanded so its child nodes are visible.
Closed Node
Parent node that is collapsed so the child nodes are not visible.

When using a keyboard to navigate a tree, a visual keyboard indicator informs the user which node is focused. If the tree allows the user to choose just one item for an action, then it is known as a single-select tree. In some implementations of single-select tree, the focused item also has a selected state; this is known as selection follows focus. However, in multi-select trees, which enable the user to select more than one item for an action, the selected state is always independent of the focus. For example, in a typical file system navigator, the user can move focus to select any number of files for an action, such as copy or move. It is important that the visual design distinguish between items that are selected and the item that has focus. For more details, see this description of differences between focus and selection and Deciding When to Make Selection Automatically Follow Focus.

Examples

Keyboard Interaction

For a vertically oriented tree:

  • When a single-select tree receives focus:
    • If none of the nodes are selected before the tree receives focus, focus is set on the first node.
    • If a node is selected before the tree receives focus, focus is set on the selected node.
  • When a multi-select tree receives focus:
    • If none of the nodes are selected before the tree receives focus, focus is set on the first node.
    • If one or more nodes are selected before the tree receives focus, focus is set on the first selected node.
  • Right arrow:
    • When focus is on a closed node, opens the node; focus does not move.
    • When focus is on a open node, moves focus to the first child node.
    • When focus is on an end node, does nothing.
  • Left arrow:
    • When focus is on an open node, closes the node.
    • When focus is on a child node that is also either an end node or a closed node, moves focus to its parent node.
    • When focus is on a root node that is also either an end node or a closed node, does nothing.
  • Down Arrow: Moves focus to the next node that is focusable without opening or closing a node.
  • Up Arrow: Moves focus to the previous node that is focusable without opening or closing a node.
  • Home: Moves focus to the first node in the tree without opening or closing a node.
  • End: Moves focus to the last node in the tree that is focusable without opening a node.
  • Enter: activates a node, i.e., performs its default action. For parent nodes, one possible default action is to open or close the node. In single-select trees where selection does not follow focus (see note below), the default action is typically to select the focused node.
  • Type-ahead is recommended for all trees, especially for trees with more than 7 root nodes:
    • Type a character: focus moves to the next node with a name that starts with the typed character.
    • Type multiple characters in rapid succession: focus moves to the next node with a name that starts with the string of characters typed.
  • * (Optional): Expands all siblings that are at the same level as the current node.
  • Selection in multi-select trees: Authors may implement either of two interaction models to support multiple selection: a recommended model that does not require the user to hold a modifier key, such as Shift or Control, while navigating the list or an alternative model that does require modifier keys to be held while navigating in order to avoid losing selection states.
    • Recommended selection model -- holding a modifier key while moving focus is not necessary:
      • Space: Toggles the selection state of the focused node.
      • Shift + Down Arrow (Optional): Moves focus to and toggles the selection state of the next node.
      • Shift + Up Arrow (Optional): Moves focus to and toggles the selection state of the previous node.
      • Shift + Space (Optional): Selects contiguous nodes from the most recently selected node to the current node.
      • Control + Shift + Home (Optional): Selects the node with focus and all nodes up to the first node. Optionally, moves focus to the first node.
      • Control + Shift + End (Optional): Selects the node with focus and all nodes down to the last node. Optionally, moves focus to the last node.
      • Control + A (Optional): Selects all nodes in the tree. Optionally, if all nodes are selected, it can also unselect all nodes.
    • Alternative selection model -- Moving focus without holding the Shift or Control modifier unselects all selected nodes except for the focused node:
      • Shift + Down Arrow: Moves focus to and toggles the selection state of the next node.
      • Shift + Up Arrow: Moves focus to and toggles the selection state of the previous node.
      • Control + Down Arrow: Without changing the selection state, moves focus to the next node.
      • Control + Up Arrow: Without changing the selection state, moves focus to the previous node.
      • Control + Space: Toggles the selection state of the focused node.
      • Shift + Space (Optional): Selects contiguous nodes from the most recently selected node to the current node.
      • Control + Shift + Home (Optional): Selects the node with focus and all nodes up to the first node. Optionally, moves focus to the first node.
      • Control + Shift + End (Optional): Selects the node with focus and all nodes down to the last node. Optionally, moves focus to the last node.
      • Control + A (Optional): Selects all nodes in the tree. Optionally, if all nodes are selected, it can also unselect all nodes.
Note
  1. DOM focus (the active element) is functionally distinct from the selected state. For more details, see this description of differences between focus and selection.
  2. The tree role supports the aria-activedescendant property, which provides an alternative to moving DOM focus among treeitem elements when implementing keyboard navigation. For details, see Managing Focus in Composites Using aria-activedescendant.
  3. In a single-select tree, moving focus may optionally unselect the previously selected node and select the newly focused node. This model of selection is known as "selection follows focus". Having selection follow focus can be very helpful in some circumstances and can severely degrade accessibility in others. For additional guidance, see Deciding When to Make Selection Automatically Follow Focus.
  4. If selecting or unselecting all nodes is an important function, implementing separate controls for these actions, such as buttons for "Select All" and "Unselect All", significantly improves accessibility.
  5. If the nodes in a tree are arranged horizontally:
    1. Down Arrow performs as Right Arrow is described above, and vice versa.
    2. Up Arrow performs as Left Arrow is described above, and vice versa.

WAI-ARIA Roles, States, and Properties

  • All tree nodes are contained in or owned by an element with role tree.
  • Each element serving as a tree node has role treeitem.
  • Each root node is contained in the element with role tree or referenced by an aria-owns property set on the tree element.
  • Each parent node contains or owns an element with role group.
  • Each child node is contained in or owned by an element with role group that is contained in or owned by the node that serves as the parent of that child.
  • Each element with role treeitem that serves as a parent node has aria-expanded set to false when the node is in a closed state and set to true when the node is in an open state. End nodes do not have the aria-expanded attribute because, if they were to have it, they would be incorrectly described to assistive technologies as parent nodes.
  • If the tree supports selection of more than one node, the element with role tree has aria-multiselectable set to true. Otherwise, aria-multiselectable is either set to false or the default value of false is implied.
  • If the tree does not support multiple selection, aria-selected is set to true for the selected node and it is not present on any other node in the tree.
  • if the tree supports multiple selection:
    • All selected nodes have aria-selected set to true.
    • All nodes that are selectable but not selected have aria-selected set to false.
    • If the tree contains nodes that are not selectable, those nodes do not have the aria-selected state.
  • The element with role tree has either a visible label referenced by aria-labelledby or a value specified for aria-label.
  • If the complete set of available nodes is not present in the DOM due to dynamic loading as the user moves focus in or scrolls the tree, each node has aria-level, aria-setsize, and aria-posinset specified.
  • If the tree element is horizontally oriented, it has aria-orientation set to horizontal. The default value of aria-orientation for a tree is vertical.
Note

If aria-owns is set on the tree container to include elements that are not DOM children of the container, those elements will appear in the reading order in the sequence they are referenced and after any items that are DOM children. Scripts that manage focus need to ensure the visual focus order matches this assistive technology reading order.

3.27 Treegrid

A treegrid widget presents a hierarchical data grid consisting of tabular information that is editable or interactive. Any row in the hierarchy may have child rows, and rows with children may be expanded or collapsed to show or hide the children. For example, in a treegrid used to display messages and message responses for a e-mail discussion list, messages with responses would be in rows that can be expanded to reveal the response messages.

In a treegrid both rows and cells are focusable. Every row and cell contains a focusable element or is itself focusable, regardless of whether individual cell content is editable or interactive. There is one exception: if column header cells do not provide functions, such as sort or filter, they do not need to be focusable. One reason it is important for all cells to be able to receive or contain keyboard focus is that screen readers will typically be in their application reading mode, rather than their document reading mode, when users are interacting with the grid. While in application mode, a screen reader user hears only focusable elements and content that labels focusable elements. So, screen reader users may unknowingly overlook elements contained in a treegrid that are either not focusable or not used to label a column or row.

When using a keyboard to navigate a treegrid, a visual keyboard indicator informs the user which row or cell is focused. If the treegrid allows the user to choose just one item for an action, then it is known as a single-select treegrid, and the item with focus also has a selected state. However, in multi-select treegrids, which enable the user to select more than one row or cell for an action, the selected state is independent of the focus. For example, in a hierarchical e-mail discussion grid, the user can move focus to select any number of rows for an action, such as delete or move. It is important that the visual design distinguish between items that are selected and the item that has focus. For more details, see this description of differences between focus and selection.

Examples

  • E-mail Inbox treegrid Example: A treegrid for navigating an e-mail inbox that demonstrates three keyboard navigation models -- rows first, cells first, and cells only.

Keyboard Interaction

The following keys provide treegrid navigation by moving focus among rows and cells of the grid. Implementations of treegrid make these key commands available when an element in the grid has received focus, e.g., after a user has moved focus to the grid with Tab. Moving focus into the grid may result in the first cell or the first row being focused. Whether focus goes to a cell or the row depends on author preferences and whether row focus is supported, since some treegrids may not provide focus to rows.

  • Enter: If cell-only focus is enabled and focus is on the first cell with the aria-expanded property, opens or closes the child rows.,Otherwise, performs the default action for the cell.
  • Tab: If the row containing focus contains focusable elements (e.g., inputs, buttons, links, etc.), moves focus to the next input in the row. If focus is on the last focusable element in the row, moves focus out of the treegrid widget to the next focusable element.
  • Right Arrow:
    • If focus is on a collapsed row, expands the row.
    • If focus is on an expanded row or is on a row that does not have child rows, moves focus to the first cell in the row.
    • If focus is on the right-most cell in a row, focus does not move.
    • If focus is on any other cell, moves focus one cell to the right.
  • Left Arrow:
    • If focus is on an expanded row, collapses the row.
    • If focus is on a collapsed row or on a row that does not have child rows, focus does not move.
    • If focus is on the first cell in a row and row focus is supported, moves focus to the row.
    • If focus is on the first cell in a row and row focus is not supported, focus does not move.
    • If focus is on any other cell, moves focus one cell to the left.
  • Down Arrow:
    • If focus is on a row, moves focus one row down. If focus is on the last row, focus does not move.
    • If focus is on a cell, moves focus one cell down. If focus is on the bottom cell in the column, focus does not move.
  • Up Arrow:
    • If focus is on a row, moves focus one row up. If focus is on the first row, focus does not move.
    • If focus is on a cell, moves focus one cell up. If focus is on the top cell in the column, focus does not move.
  • Page Down:
    • If focus is on a row, moves focus down an author-determined number of rows, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row, focus does not move.
    • If focus is on a cell, moves focus down an author-determined number of cells, typically scrolling so the bottom row in the currently visible set of rows becomes one of the first visible rows. If focus is in the last row, focus does not move.
  • Page Up:
    • If focus is on a row, moves focus up an author-determined number of rows, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row, focus does not move.
    • If focus is on a cell, moves focus up an author-determined number of cells, typically scrolling so the top row in the currently visible set of rows becomes one of the last visible rows. If focus is in the first row, focus does not move.
  • Home:
    • If focus is on a row, moves focus to the first row. If focus is in the first row, focus does not move.
    • If focus is on a cell, moves focus to the first cell in the row. If focus is in the first cell of the row, focus does not move.
  • End:
    • If focus is on a row, moves focus to the last row. If focus is in the last row, focus does not move.
    • If focus is on a cell, moves focus to the last cell in the row. If focus is in the last cell of the row, focus does not move.
  • Control + Home:
    • If focus is on a row, moves focus to the first row. If focus is in the first row, focus does not move.
    • If focus is on a cell, moves focus to the first cell in the column. If focus is in the first row, focus does not move.
  • Control + End:
    • If focus is on a row, moves focus to the last row. If focus is in the last row, focus does not move.
    • If focus is on a cell, moves focus to the last cell in the column. If focus is in the last row, focus does not move.
Note
  • When the above treegrid navigation keys move focus, whether the focus is set on an element inside the cell or on the cell depends on cell content. See Whether to Focus on a Cell or an Element Inside It.
  • While navigation keys, such as arrow keys, are moving focus from cell to cell, they are not available to do something like operate a combobox or move an editing caret inside of a cell. If this functionality is needed, see Editing and Navigating Inside a Cell.
  • If navigation functions can dynamically add more rows or columns to the DOM, key events that move focus to the beginning or end of the grid, such as control + End, may move focus to the last row in the DOM rather than the last available row in the back-end data.

If a treegrid supports selection of cells, rows, or columns, the following keys are commonly used for these functions.

  • Control + Space:
    • If focus is on a row, selects all cells.
    • If focus is on a cell, selects the column that contains the focus.
  • Shift + Space:
    • If focus is on a row, selects the row.
    • If focus is on a cell, selects the row that contains the focus. If the treegrid includes a column with checkboxes for selecting rows, this key can serve as a shortcut for checking the box when focus is not on the checkbox.
  • Control + A: Selects all cells.
  • Shift + Right Arrow:
    • If focus is on a row, does not change selection.
    • if focus is on a cell, extends selection one cell to the right.
  • Shift + Left Arrow:
    • If focus is on a row, does not change selection.
    • if focus is on a cell, extends selection one cell to the left.
  • Shift + Down Arrow:
    • If focus is on a row, extends selection to all the cells in the next row.
    • If focus is on a cell, extends selection one cell down.
  • Shift + Up Arrow:
    • If focus is on a row, extends selection to all the cells in the previous row.
    • If focus is on a cell, extends selection one cell up.
Note

See § 6.8 Key Assignment Conventions for Common Functions for cut, copy, and paste key assignments.

WAI-ARIA Roles, States, and Properties

  • The treegrid container has role treegrid.
  • Each row container has role row and is either a DOM descendant of or owned by the treegrid element or an element with role rowgroup.
  • Each cell is either a DOM descendant of or owned by a row element and has one of the following roles:
    • columnheader if the cell contains a title or header information for the column.
    • rowheader if the cell contains title or header information for the row.
    • gridcell if the cell does not contain column or row header information.
  • A row that can be expanded or collapsed to show or hide a set of child rows is a parent row. Each parent row has the aria-expanded state set on either the row element or on a cell contained in therow. The aria-expanded state is set to false when the child rows are not displayed and set to true when the child rows are displayed. Rows that do not control display of child rows do not have the aria-expanded attribute because, if they were to have it, they would be incorrectly described to assistive technologies as parent rows.
  • If the treegrid supports selection of more than one row or cell, it is a multi-select treegrid and the element with role treegrid has aria-multiselectable set to true. Otherwise, it is a single-select treegrid, and aria-multiselectable is either set to false or the default value of false is implied.
  • If the treegrid is a single-select treegrid, aria-selected is set to true on the selected row or cell, and it is not present on any other row or cell in the treegrid.
  • if the treegrid is a multi-select treegrid:
    • All selected rows or cells have aria-selected set to true.
    • All rows and cells that are not selected have aria-selected set to false.
  • If there is an element in the user interface that serves as a label for the treegrid, aria-labelledby is set on the grid element with a value that refers to the labelling element. Otherwise, a label is specified for the grid element using aria-label.
  • If the treegrid has a caption or description, aria-describedby is set on the grid element with a value referring to the element containing the description.
  • If the treegrid provides sort functions, aria-sort is set to an appropriate value on the header cell element for the sorted column or row as described in the section on grid and table properties.
  • If the treegrid provides content editing functionality and contains cells that may have edit capabilities disabled in certain conditions, aria-readonly is set to true on cells where editing is disabled. If edit functions are disabled for all cells, instead of setting aria-readonly to true on every cell, aria-readonly may be set to true on the treegrid element. Treegrids that do not provide cell content editing functions do not include the aria-readonly attribute on any of their elements.
  • If there are conditions where some rows or columns are hidden or not present in the DOM, e.g., data is dynamically loaded when scrolling or the grid provides functions for hiding rows or columns, the following properties are applied as described in the section on grid and table properties.
  • If the treegrid includes cells that span multiple rows or multiple columns, and if the treegrid role is NOT applied to an HTML table element, then aria-rowspan or aria-colspan is applied as described in grid and table properties.
Note
  • A treegrid built from an HTML table that includes cells that span multiple rows or columns must use HTML rowspan and colspan and must not use aria-rowspan or aria-colspan.
  • If rows or cells are included in a treegrid via aria-owns, they will be presented to assistive technologies after the DOM descendants of the treegrid element unless the DOM descendants are also included in the aria-owns attribute.

3.28 Window Splitter

NOTE: ARIA 1.1 introduced changes to the separator role so it behaves as a widget when focusable. While this pattern has been revised to match the ARIA 1.1 specification, the task force will not complete its review until a functional example that matches the ARIA 1.1 specification is complete. Progress on this pattern is tracked by issue 129.

A window splitter is a moveable separator between two sections, or panes, of a window that enables users to change the relative size of the panes. A Window Splitter can be either variable or fixed. A fixed splitter toggles between two positions whereas a variable splitter can be adjusted to any position within an allowed range.

A window splitter has a value that represents the size of one of the panes, which, in this pattern, is called the primary pane. When the splitter has its minimum value, the primary pane has its smallest size and the secondary pane has its largest size. The splitter also has an accessible name that matches the name of the primary pane.

For example, consider a book reading application with a primary pane for the table of contents and a secondary pane that displays content from a section of the book. The two panes are divided by a vertical splitter labelled "Table of Contents". When the table of contents pane has its maximum size, the splitter has a value of 100, and when the table of contents is completely collapsed, the splitter has a value of 0.

Note that the term "primary pane" does not describe the importance or purpose of content inside the pane.

Example

Work to develop an example window splitter widget is tracked by issue 130.

Keyboard Interaction

  • Left Arrow: Moves a vertical splitter to the left.
  • Right Arrow: Moves a vertical splitter to the right.
  • Up Arrow: Moves a horizontal splitter up.
  • Down Arrow: Moves a horizontal splitter down.
  • Enter: If the primary pane is not collapsed, collapses the pane. If the pane is collapsed, restores the splitter to its previous position.
  • Home (Optional): Moves splitter to the position that gives the primary pane its smallest allowed size. This may completely collapse the primary pane.
  • End (Optional): Moves splitter to the position that gives the primary pane its largest allowed size. This may completely collapse the secondary pane.
  • F6 (Optional): Cycle through window panes.
Note

A fixed size splitter omits implementation of the arrow keys.

WAI-ARIA Roles, States, and Properties

  • The element that serves as the focusable splitter has role separator.
  • The separator element has the aria-valuenow property set to a decimal value representing the current position of the separator.
  • The separator element has the aria-valuemin property set to a decimal value that represents the position where the primary pane has its minimum size. This is typically 0.
  • The separator element has the aria-valuemax property set to a decimal value that represents the position where the primary pane has its maximum size. This is typically 100.
  • If the primary pane has a visible label, it is referenced by aria-labelledby on the separator element. Otherwise, the separator element has a label provided by aria-label.
  • The separator element has aria-controls referring to the primary pane.

4. 랜드마크 영역

ARIA 랜드마크 역할(role)은 웹 페이지의 구성과 구조를 식별하는 강력한 방법을 제공합니다. 페이지의 섹션을 분류하고 레이블을 지정함으로써, 레이아웃을 통해 시각적으로 전달되는 구조 정보를 프로그래밍 방식으로 나타낼 수 있습니다. 스크린리더는 페이지의 중요한 부분으로의 키보드 탐색을 제공하는데 랜드마크 역할(role)을 활용합니다. 랜드마크 영역은 "스킵 링크"의 대상으로도 사용될 수 있고, 브라우저 확장을 통해 향상된 키보드 탐색으로 사용될 수 있습니다.

이 섹션은 보조 기술 사용자가 페이지의 레이아웃의 의미를 이해하기 쉽게 할 수 있도록 HTML 섹션화 요소(element)와 ARIA 랜드마크 역할(role)을 사용하는 방법을 설명합니다.

4.1 HTML 섹션화 요소(element)

몇 몇 HTML 섹션화 요소(element)는 자동으로 ARIA 랜드마크 영역을 생성합니다. 따라서, 보조 기술 사용자에게 페이지의 논리적 시야를 제공하려면, HTML 섹션화 요소(element) 사용의 영향을 이해하는 것이 중요합니다. [HTML-ARIA]에는 HTML 요소 역할 매핑에 대한 자세한 정보가 포함되어 있습니다.

HTML 섹션화 요소(element)에 대한 기본 랜드마크 역할(role)
HTML 요소(element) 기본 랜드마크 역할(role)
aside complementary
footer body 요소(element)의 컨텍스트에 있는 경우 contentinfo
header body 요소(element)의 컨텍스트에 있는 경우 banner
main main
nav navigation
section aria-labelledbyaria-label을 사용하여 접근 가능한 이름을 가지는 경우 region

4.2 랜드마크 설계 일반 원칙

랜드 마크 영역 중 하나에 페이지의 모든 인식 가능한 콘텐트를 포함시키고 각 랜드 마크 영역에 의미론적으로(semantically) 유의미한(meaningful) 역할을 부여하는 것은 보조 기술 사용자가 그들의 필요와 관련된 정보를 못 보고 지나가지 않도록하는 가장 효과적인 방법 중 하나입니다.

1 단계: 논리적 구조 식별

2 단계: 각 영역에 랜드마크 역할(role) 할당

3 단계: 영역에 레이블 지정

4.3 랜드마크 영역

4.3.1 Banner

banner 랜드마크는 웹 사이트 내 각 페이지의 시작 부분에 있는 사이트 지향적인(site-oriented) 콘텐트를 식별합니다. 사이트 지향적인(site-oriented) 콘텐트는 일반적으로 로고나 사이트 제공자의 신분 같은 것들과, 사이트 지향적인(site-oriented) 검색 도구를 포함합니다. 배너는 보통 페이지의 맨 위에 나타나고 일반적으로 전체 너비에 걸쳐 있습니다.

  • 각 페이지는 하나의 banner 랜드마크를 가질 수 있습니다.
  • banner 랜드마크는 최상위 랜드마크이어야 합니다.
  • 페이지가 중첩된 document와/또는 application 역할(role)을 포함하는 경우 (예를 들어, 일반적으로 iframeframe 요소(element)의 사용을 통해), 각 documentapplication 역할(role)은 하나의 banner 랜드마크를 가질 수 있습니다.
  • 페이지가 둘 이상의 banner 랜드 마크를 포함한다면, 각각은 고유한 레이블을 가져야 합니다 (위의 3 단계 참고).
HTML 기법
  • HTML header 요소(element)는 그것의 컨텍스트가 body 요소(element)인 경우 banner 랜드마크를 정의합니다.
  • HTML header 요소(element)는 다음 요소(element)들 중 하나의 후손일 경우 banner 랜드마크로 간주되지 않습니다 (HTML 접근성 매핑 [HTML-AAM] 참고):
    • article
    • aside
    • main
    • nav
    • section
ARIA 기법

HTML header 요소(element) 기술이 사용되지 않는 경우, role="banner" 속성(attribute)이 banner 랜드마크를 정의하는데 사용되어야 합니다.

Banner Landmark 예제

4.3.2 Complementary

complementary 랜드마크는 문서의 지원(supporting) 섹션으로, DOM 계층상 유사한 수준에서 주 콘텐트를 보완하도록 설계되었으며 주 콘텐트로부터 분리되는 경우에도 여전히 유의미합니다.

  • complementary 랜드마크는 최상위 랜드마크여야 합니다. (예를 들어, 다른 랜드마크에 포함되지 않은).
  • complementary 콘텐트가 주 콘텐트와 관련이 없다면, 좀 더 일반적인 역할(role)이 할당되어야 합니다(예를 들어 region).
  • 페이지가 둘 이상의 complementary 랜드마크를 포함한다면, 각각은 고유한 레이블을 가져야 합니다 (위 3 단계 참고).
HTML 기법

complementary 랜드마크를 정의하도록 HTML aside 요소(element)를 사용하세요.

ARIA 기법

HTML aside 요소(element) 기법이 사용되지 않는다면, complementary 랜드마크를 정의하도록 role="complementary" 속성(attribute)을 사용하세요.

예제

Complementary 랜드마크 예

4.3.3 Contentinfo

contentinfo 랜드마크는 저작권 및 개인 정보 보호와 접근성 성명서에 대한 링크 같은 정보를 포함하는 일반적으로 페이지의 "footer"라고 불리는 웹 사이트 내에서 각 페이지의 하단에 있는 일반적인 정보를 식별하는 방법입니다.

  • 각 페이지는 하나의 contentinfo 랜드마크를 가질 수 있습니다.
  • contentinfo 랜드마크는 최상위 랜드마크여야 합니다.
  • 페이지가 중첩된 document와/또는 application 역할(role)을 포함하는 경우 (예를 들어, 일반적으로 iframeframe 요소(element)의 사용을 통해), 각 documentapplication ���할(role)은 하나의 contentinfo 랜드마크를 가질 수 있습니다.
  • 페이지가 둘 이상의 contentinfo 랜드마크를 포함한다면, 각각은 고유한 레이블을 가져야 합니다 (위 3 단계 참고).
HTML 기법
  • HTML footer 요소(element)는 그것의 컨텍스트가 body 요소(element)인 경우 contentinfo 랜드마크를 정의합니다.
  • HTML footer 요소(element)는 다음 요소(element)들 중 하나의 후손일 경우 contentinfo 랜드마크로 간주되지 않습니다 (HTML 접근성 매핑 [HTML-AAM] 참고):
    • article
    • aside
    • main
    • nav
    • section
ARIA 기법

HTML footer 요소(element) 기법이 사용되지 않는다면, contentinfo 랜드마크를 정의하도록 role="contentinfo" 속성(attribute)이 사용되어야 합니다.

예제

Contentinfo 랜드마크 예

4.3.4 Form

form 랜드마크는 다른 기명 랜드마크(예를 들어, main 또는 search)가 적절하지 않은 경우 양식을 만들도록 전체적으로 결합되는 항목과 객체들의 모음을 포함하는 영역을 식별합니다.

  • 양식이 검색 기능으로 사용되는 경우 form 랜드마크 대신 search 랜드마크를 사용하세요.
  • form 랜드마크는 사용자들이 양식의 목적을 이해할 수 있도록 레이블을 가져야 합니다.
  • form 랜드마크에 대한 레이블은 모든 사용자들에게 잘 보여야 합니다(예를 들어, h1-h6 요소(element)).
  • 페이지가 둘 이상의 form 랜드마크를 포함하는 경우, 각각은 고유한 레이블을 가져야 합니다 (위 3 단계 참고).
  • 가능한 항상 HTML 문서의 form 랜드마크에 포함된 컨트롤들은 네이티브 호스트 의미론을 사용해야 합니다:
    • button
    • input
    • select
    • textarea
HTML 기법

HTML form 요소(element)는 접근 가능한 이름 (예를 들어, aria-labelledby, aria-labeltitle)을 가질 때 form 랜드마크를 정의합니다.

ARIA 기법

페이지의 영역을 식별하도록 role="form" 을 사용하세요; 모든 양식 필드를 식별하는데 사용하지 마세요.

예제

Form 랜드마크 예

4.3.5 Main

main 랜드마크는 페이지의 주요(primary) 콘텐트를 식별합니다.

  • 각 페이지는 하나의 main 랜드마크를 가져야 합니다.
  • main 랜드마크는 최상위 랜드마크여야 합니다.
  • 페이지에 중첩된 document와/또는 application 역할(roles)을 포함하는 경우 (예를 들어, 일반적으로 iframeframe 요소(elements)의 사용을 통해), 각 documentapplication 역할(role)은 하나의 main 랜드마크를 가질 수 있습니다.
  • 페이지가 둘 이상의 main 랜드마크를 포함하는 경우, 각각은 고유한 레이블을 가져야 합니다 (위 3 단계 참고).
HTML 기법

main 랜드마크를 정의하도록 HTML main 요소(element)를 사용하세요.

ARIA 기법

HTML main 요소(element) 기법이 사용되지 않는다면, main 랜드마크를 정의하도록 role="main" 속성(attribute)을 사용하세요.

예제

Main 랜드마크 예

4.3.6 Navigation

Navigation 랜드마크는 웹 사이트나 페이지 콘텐트를 탐색하는데 사용되도록 의도된 링크의 그룹(예를 들어 목록)을 식별하는 방법을 제공합니다.

  • 페이지가 둘 이상의 navigation 랜드마크를 포함하는 경우, 각각은 고유한 레이블을 가져야 합니다.(위 3 단계 참고).
  • navigation 랜드마크가 페이지의 다른 navigation 랜드마크와 동일한 링크 세트를 가지는 경우, 각 navigation 랜드마크에 대해 동일한 레이블을 사용하세요.
HTML 기법

navigation 랜드마크를 정의하도록 HTML nav 요소(element)를 사용하세요.

ARIA 기법

HTML nav 요소(element) 기법이 사용되지 않는다면, navigation 랜드마크를 정의하도록 role="navigation" 속성(attribute)을 사용하세요.

예제

Navigation 랜드마크 예

4.3.7 Region

region 랜드마크는 사용자가 섹션으로 이동 할 수 있어야 할 정도로 충분히 중요한 콘텐트를 포함하는 페이지의 인식 가능한 섹션입니다.

  • region 랜드마크는 레이블을 가져야(must) 합니다.
  • 페이지가 둘 이상의 region 랜드마크를 포함한다면, 각각은 고유한 레이블을 가져야 합니다 (위 3 단계 참고).
  • region 랜드마크는 기명 랜드마크로는 적절하게 설명할 수 없는 콘텐트를 식별하는데 사용될 수 있습니다.
HTML 기법

HTML section 요소(element)가 접근 가능한 이름을(예를 들어 aria-labelledbyaria-labeltitle) 가지는 경우 region 랜드마크를 정의합니다.

ARIA 기법

HTML section 요소(element) 기법이 사용되지 않는 다면, region 랜드마크를 정의하도록 role="region" 속성(attribute)을 사용하세요.

예제

Region 랜드마크 예

5. 접근 가능한 이름과 설명 제공

접근 가능한 이름과 적절한 경우 접근 가능한 설명을 가진 요소(element)를 제공하는 것은 접근 가능한 웹 경험을 개발할 때 작성자가 가져야 할 가장 중요한 책임 중 하나입니다. 대부분의 요소(element)에서는 그렇게 하는 것이 간단한 반면, 보조 기술 사용자들을 완전히 차단할 수 있는 기술적 실수 역시 쉽게 만들 수 있고 불행하게도 흔하게 일어납니다. 작성자가 접근 가능한 이름과 설명을 효과적으로 제공할 수 있도록 돕기 위해, 이 섹션에서는 그 목적과, 작성자가 그것들을 제공해야 하는 경우, 브라우저가 그것들을 모으는 방법, 그것들을 코드화하고 구성하기 위한 규칙을 설명합니다. 또한 작성자에게 다음의 이름 지정와 설명 지정 기법 및 WAI-ARIA 속성 사용에 대해서도 안내합니다:

5.1 접근 가능한 이름과 설명이란?

접근 가능한 이름은 일반적으로 1 ~ 3개 단어의 짧은 문자열로, 작성자가 보조 기술 사용자에게 요소(element)에 대한 레이블을 제공하기 위해 요소(element)와 연관시킨 문자열입니다. 예를 들어, 입력 필드는 접근 가능한 "User ID"이라는 이름을 가지거나, 버튼은 "Submit"으로 이름 지을 수 있습니다.

접근 가능한 이름은 스크린리더와 같은 보조 기술 사용자에게 두 가지 주요 목적을 제공합니다:

  1. 요소(element)의 목적이나 의도를 전달.
  2. 페이지의 다른 요소(element)로부터 요소(element)를 구별.

WAI-ARIA 명세와 WCAG 둘 모두 모든 포커서블(focusable), 인터랙티브 요소(element)들은 접근 가능한 이름을 가지도록 요구합니다. 게다가 대화 상자와 tablesregions 같은 일부 구조 컨테이너들도 이름을 가지도록 요구됩니다. 많은 다른 요소(element)들도 이름을 지정할 수 있지만, 이름이 접근성을 향상시키는가의 여부는 주변 컨텍스트의 다양한 특성에 따라서 결정됩니다. 마지막으로, 접근 가능한 이름을 제공하는 것이 기술적으로는 가능하지만 권장할만 하지는 않은 일부 요소(element)들이 있습니다. 역할에 따른 접근 가능한 이름 지침 섹션은 모든 ARIA 역할에 대한 이름 지정 요구 사항과 지침들을 나열합니다.

접근 가능한 설명 역시 보조 기술에 의해 렌더링 되는 작성자가 제공한 문자열입니다. 작성자는 입력 필드에 대한 지시 사항이나 형식 요구 사항과 같은, 요소(element)와 연관 시킬 필요가 있는 추가적인 정보가 있을 경우 설명을 제공합니다.

보조 기술은 이름과 설명을 다르게 표현합니다. 예를 들어, 스크린리더는 일반적으로 요소의 이름과 역할을 먼저 낭독합니다. 예를 들어, 대화 음소거라고 명명된 버튼은 대화 음소거 버튼이라고 낭독되어 질 수 있습니다. 요소(element)가 상태(state)를 가지는 경우, 이름과 역할 앞이나 뒤로 낭독될 수 있습니다; 일반적으로 기본은 이름과 역할 이후입니다. 예를 들어, 꺼짐 상태인 대화 음소거라고 명명된 스위치 버튼은 대화 음소거 스위치 버튼 꺼짐으로 낭독 될 수 있습니다. 설명은 일반적으로 이름보다 상당히 긴 선택적인 문자열이기 때문에, 마지막에 표현되고, 때로는 약간 지연 된 후에 표현됩니다. 예를 들어, 대화 음소거 스위치 버튼 꺼짐, 이 대화의 활동에 대한 경고와 알림 소리를 없앱니다. 자세한 내용을 줄이기 위해, 일부 스크린리더는 기본적으로 설명을 낭독하지 않고, 대신 사용자에게 그 존재를 알려 사용자가 설명을 낭독시키도록 키를 누르게 할 수 있습니다.

5.2 이름과 설명 문자열은 어떻게 파생되나요?

접근 가능한 이름이나 설명 문자열에 포함 시킬 텍스트를 지정할 요소(element)와 속성(attribute)들이 여럿 있기 때문에, 그리고 작성자가 거의 끝 없는 방식으로 그 텍스트들을 결합 할 수 있기 때문에, 브라우저는 문자열을 조립하기 위해 상당히 복잡한 알고리즘을 구현합니다. 접근 가능한 이름 계산접근 가능한 설명 계산의 섹션들이 알고리즘과 브라우저들이 우선 순위를 구현하는 방법을 설명합니다. 하지만, 이름이나 설명이 유용한 경우의 거의 모든 상황은 이름 지정 기법설명 지정 기법 섹션에 기술된 코딩 패턴에 따라 지원되기 때문에 대부분의 작성자는 알고리즘에 대한 상세한 이해 같은 것은 필요하지 않습니다.

5.3 접근 가능한 이름

5.3.1 이름 지정의 기본 규칙

5.3.1.1 규칙 1: 경고에 주의하고 철처하게 테스트

아래 몇 가지 이름 지정 기법은 ARIA 명세에 의해 금지되거나 아직 완전히 정의되지 않은 회색 지대에 속하는 특정 코딩 패턴에 대해 경고하는 메모를 포함하고 있습니다. 이러한 금지된 것이나 모호한 패턴 중 일부는 논리적으로 나타나고 일부 브라우저에서 희망했던 이름을 내 줄 수도 있습니다. 하지만, 특히 브라우저 간의 이름 계산의 일관성을 개선하기 위한 작업이 진행됨에 따라 브라우저 전체를 통틀어 일관된 결과를 제공할 가능성이 낮습니다.

이름 지정 기법에 제공되는 경고에 주의를 기울이는 것 외에도, 브라우저가 계산한 이름과 예상 한 것이 일치하도록 보장하기 위해 테스트의 중요성을 지나치게 강조하기란 쉽지 않습니다.

5.3.1.2 규칙 2: 보이는 텍스트 선택

유저 인터페이스가 적절한 접근 가능한 이름을 제공하는데 사용될 수 있는 보이는 텍스트를 포함하는 경우, 접근 가능한 이름에 대한 보이는 텍스트를 사용하는 것이 유지보수를 간소화하고, 오류를 방지하며 언어 번역 요구 사항을 줄입니다. 이름이 시각적으로 표시되지 않고 마크업 안에만 존재하는 텍스트로부터 생성되는 경우, 유저 인터페이스 설계나 콘텐츠가 변경될 경우 접근 가능한 이름은 업데이트 되지 않을 소지가 높습니다.

입력 상자나 버튼과 같은 대화형 요소(interactive element)가 시각적으로 사라지지 않는 텍스트 레이블이 없는 경우, 이를 포함하도록 디자인을 조정하세요. 접근 가능한 이름에 대해 더 견고한 소스를 제공하는 것 외에, 보이는 텍스트 레이블은 보이지 않는 이름을 나타내는 보조 기술을 사용하지 않는 많은 장애인들에 대한 접근성을 향상시킵니다. 대부분의 상황에서, 보이는 텍스트 레이블은 또한 유저 인터페이스를 모든 사용자들이 이해하기 더 쉽게 만듭니다.

5.3.1.3 규칙 3: 기본 기술 선택

HTML 문서에서, 가능할때마다, 폼 요소에 대한 HTML label 요소와 표에 대한 caption 요소와 같은 HTML 이름 지정 기법을 사용하세요. 유연성은 떨어지지만, 보이는 텍스트에 대한 단순성과 의존성은 견고한 접근 가능한 환경을 보장하는데 도움이 됩니다. 몇 몇 이름 지정 기법은 ARIA 속성 대신 HTML 기능을 사용하는 것의 특정 접근성 장점을 강조합니다.

5.3.1.4 규칙 4: 브라우저 폴백 방지

작성자가 이름 지정을 위해 의도된 요소나 속성을 사용하여 접근 가능한 이름을 지정하지 않는 경우, 브라우저는 이름을 생성하기 위한 폴백 메서드에 기대어 보조 기술 사용자를 도우려 시도합니다. 예를 들어, HTML titleplaceholder 속성은 접근 가능한 이름에 대한 콘텐츠의 최후의 수단으로 사용됩니다. 이 속성의 목적은 이름 지정이 아니기 때문에, 일반적으로 그 내용은 유효하지 않은 저품질의 접근 가능한 이름을 산출합니다.

5.3.1.5 규칙 5: 간단하고 유용한 이름 작성

시각적으로 화면을 가득 메우고 모호한 아이콘이 사용성을 떨어뜨리는 방법과 유사하게, 지나치게 길거나 충분히 분명하지 않거나 불확실한 접근 가능한 이름은 유저 인터페이스를 매우 어렵게 만들거나 심지어 유저 인터페이스의 비시각적 형태에 의존하는 사람들의 사용을 불가능하게 만들 수 있습니다. 다시 말해, 접근 가능한 웹 경험을 위해 접근 가능한 이름이 유효해야 합니다. 유효하고 사용자 친화적인 접근 가능한 이름 작성 섹션은 간결성과 명확성의 균형을 위한 지침을 제공합니다.

5.3.2 이름 지정 기법

5.3.2.1 자식 콘텐츠로 이름 지정

특정 요소는 포함하는 콘텐트로부터 이름을 가져옵니다. 예를 들어, 다음 링크는 "Home"으로 이름 지어집니다.

<a href="/">Home</a>

보조 기술이 링크나 버튼과 같이 콘텐트로부터 접근 가능한 이름을 가져오는 요소를 제공 할 경우, 접근 가능한 이름은 사용자가 그 요소에 대해 인식 할 수 있는 유일한 콘텐트입니다. 이는 접근 가능한 이름이 요소의 콘텐트나 값에 추가하여 표시되는 레이블인 텍스트 필드나 표와 같은 다른 요소들과 대조적입니다. 예를 들어, 표의 접근 가능한 이름은 caption 요소로부터 파생될 수 있고, 보조 기술은 caption과 테이블 내에 포함된 모든 다른 콘텐트를 모두 제공 합니다.

기본적으로 다음 역할(role) 중 하나를 가지는 요소는 후손 콘텐츠로부터 계산된 문자열로 이름이 지정됩니다:

  • button
  • cell
  • checkbox
  • columnheader
  • gridcell
  • heading
  • link
  • menuitem (자식 menu 요소에 포함된 콘텐트는 제외 됨.)
  • menuitemcheckbox
  • menuitemradio
  • option
  • radio
  • row
  • rowheader
  • switch
  • tab
  • tooltip
  • treeitem (자식 group 요소에 포함된 콘텐트는 제외 됨.)

요소에 대한 콘텐트로부터 이름을 계산할 경우, 유저 에이전트는 각 후손 요소를 재귀적으로 확인하고 각 후손에 대한 이름 문자열을 계산하고, 결과 문자열을 연결합니다. 두 가지 특정한 경우, 특정 후손들은 무시됩니다: treeitem 요소의 후손인 groupmenuitem 요소의 후손인 menu는 계산에서 생략됩니다. 예를 들어, 다음 tree에서 첫 번째 트리 항목의 이름은 과일입니다; 사과, 바나나, and 오렌지는 생략됩니다.

<ul role="tree">
  <li role="treeitem">과일
    <ul role="group">
      <li role="treeitem">사과</li>
      <li role="treeitem">바나나</li>
      <li role="treeitem">오렌지</li>
    </ul>
  </li>
</ul>
Warning

자식 콘텐츠로부터 이름 지정을 지원하는 위 역할(role) 중 하나를 가지는 요소가 aria-label이나 aria-labelledby로 이름이 지정되는 경우, 요소에 포함된 콘텐트와 후손은 후손 콘텐츠가 aria-labelledby에 의해 참조되지 않는 한 보조 기술 사용자에게 숨겨집니다. 보조 기술 사용자로부터 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 위 요소들 중 하나의 콘텐트를 재정의하기 위해 이 속성들 중 하나를 사용하지 않는 것이 강력히 권장됩니다. 또한, 볼 수 있는 콘텐트가 이 속성 중 하나의 사용으로 인해 보조 기술 사용자에게 숨겨지는 경우에서는 보조 기술을 사용한 철저한 테스트가 특히 중요합니다.

5.3.2.2 aria-label을 통해 문자열 속성으로 이름 지정

aria-label 속성은 작성자가 시각적으로 전달하지 않는 문자열로 요소에 이름을 지정할 수 있게 합니다. 예를 들어, 다음 버튼의 이름은 "Close"입니다.

<button type="button" aria-label="Close">X</button>

aria-label 속성은 적절한 접근 가능한 이름으로 제공할 보이는 텍스트 콘텐트가 없는 경우에 유용합니다.

aria-label 속성은 적용되는 요소의 역할(role)에 의존하여 두 가지 다른 방법 중 하나로 보조 기술 사용자에게 영향을 줍니다. 자식 콘텐트로부터 이름 지정을 지원하는 역할(role) 중 하나를 요소에 적용하는 경우, aria-label은 보조 기술 사용자에게 후손 콘텐트를 숨기고 aria-label의 값으로 교체합니다. 하지만, 거의 모든 다른 유형의 요소들에 적용되는 경우, 보조 기술은 aria-label의 값과 요소의 콘텐트를 모두 전달할 것입니다. 예를 들어, 다음 내비게이션 영역의 이름은 "Product" 입니다.

<nav aria-label="Product">
  <!-- 프로덕트 페이지로의 내비게이션 링크 목록 -->
</nav>

이 내비게이션 영역을 만나면, 스크린리더 사용자는 요소의 이름과 역할을 듣게 될 것이고, 예를 들어, "프로덕트 내비게이션 영역", 영역에 포함된 링크를 통해 읽을 수 있습니다.

Warning
  1. aria-label자식 콘텐트로부터 이름 지정을 지원하는 역할(role) 중 하나로 요소에 적용된다면, 요소에 포함되고 요소의 후손인 콘텐트는 보조 기술 사용자에게 숨깁니다. 보조 기술 사용자로부터 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 위 요소들 중 하나의 콘텐트를 재정의하기 위해 aria-label을 사용하지 않는 것이 강력히 권장됩니다.
  2. aria-label로 이름을 지정하지 않아야 하는, 문단과 목록 항목 같은 특정한 유형의 요소가 있습니다. 그것들은 역할(role)에 의한 접근 가능한 이름 지정 지침 섹션의 표에 나와 있습니다.
  3. aria-label의 값은 시각적으로 전달되지 않기 때문에, 예상되는 이름이 사용자에게 제공하는 것을 확인하기 위해 보조 기술을 사용하여 테스트하는 것이 특히 중요합니다.
  4. 유저 인터페이스가 여러 언어로 번역되는 경우, aria-label 값이 번역 되는지 확인하세요.
5.3.2.3 aria-labelledby를 통해 참조된 콘텐트로 이름 지정

aria-labelledby 속성은 작성자가 접근 가능한 이름을 정의하기 위해 페이지의 다른 요소들을 참조할 수 있게 합니다. 예를 들어, 다음 스위치는 이전 형제 요소의 텍스트 콘텐트로 이름이 지정됩니다.

<span id="night-mode-label">야간 모드</span>
<span role="switch" aria-checked="false" tabindex="0" aria-labelledby="night-mode-label"></span>

이 상황에서 aria-labelledby를 사용하는 것이 for 속성(attribute)을 가진 HTML label을 사용하는 것과 유사한 반면, 한 가지 중요한 차이점은 브라우저가 레이블을 지정하는 요소를 클릭하는 것이 레이블이 지정된 요소를 자동으로 활성화 하지 않는 다는 것에 주목하세요. 그것은 작성자의 책임입니다. 하지만, HTML labelspan 요소에 레이블을 지정하는데 사용될 수 없습니다. 다행히 HTML type="checkbox"을 가진 input은 ARIA switch 역할(role)을 허용하므로 가능한 경우 다음 접근법을 사용하는 것이 더 견고한 해결책을 만듭니다.

<label for="night-mode">야간 모드</label>
<input type="checkbox" role="switch" id="night-mode">
텍스트가 복잡하여 부연 설명을 덧붙이면, HTML의 기본 기능으로 label을 클릭하면 이 labelfor 속성(attribute)으로 연결된 요소를 활성화 하도록 동작하는데, 위 예제에서와 같이 ARIA의 작성하는 것은 label의 동작과 같은 HTML 네이티브 동작을 제공하지 않음을 의미합니다. 따라서, HTML 네이티브와 동등하게 동작하게 하는 것은 작성자의 몫으로 남겨집니다.

aria-labelledby 속성(property)은 다음의 이유로 여러 상황에서 유용합니다:

  • 브라우저가 접근 가능한 이름을 계산할 때 가장 높은 우선 순위를 가집니다. 즉, 자식 콘텐트로부터의 이름과 aria-label을 포함하여 모든 다른 이름 속성들 보다 우선됩니다.

  • 여러 요소의 콘텐츠를 단일 이름 문자열로 연결할 수 있습니다.

  • 가시성과 관계 없이 요소의 콘텐트를 포함합니다. 즉, 계산된 이름 문자열에 hidden 속성(attribute), CSS display: none이나 CSS visibility: hidden을 가진 요소의 콘텐트도 포함합니다.

  • input 요소의 값을 통합합니다. 즉, 텍스트 상자를 참조하는 경우, 텍스트 상자의 값이 계산 된 이름 문자열에 포함됩니다.

aria-labelledby를 가진 숨겨진 요소를 참조하는 예는 야간 스위치 제어에 대한 레이블 일 수 있습니다:

<span id="night-mode-label" hidden>야간 모드</span>
<input type="checkbox" role="switch" aria-labelledby="night-mode-label">

경우에 따라, 요소에 대한 가장 효과적인 이름은 다른 요소의 콘텐트와 자체 콘텐츠가 결합된 것입니다. aria-labelledby는 이름 계산에서 가장 높은 우선 순위를 가지기 때문에, 그 경우 자체 요소와 다른 요소를 모두 참조하도록 aria-labelledby를 사용할 수 있습니다. 다음 예에서, "더 보기..." 링크는 요소 자신과 게시글의 제목에 의해 이름이 지정되어 결과적으로 "더 보기... 벌을 구할 수 있는 7가지 방법"의 링크 이름이 됩니다.

<h2 id="bees-heading">벌을 구할 수 있는 7가지 방법</h2>
<p>벌이 빠르게 사라지고 있습니다. 여기 당신이 도울 수 있는 7가지가 있습니다.</p>
<p><a id="bees-read-more" aria-labelledby="bees-read-more bees-heading">더 보기...</a></p>

여러 요소들이 aria-labelledby로 참조되는 경우, 각 참조 된 요소들의 텍스트 콘텐트는 aria-labelledby 값에 정의된 순서로 연결됩니다. 요소가 두 번 이상 참조되는 경우, 첫 번째 참조만 처리됩니다. 여러 요소들의 콘텐트를 연결하는 경우, 브라우저는 선행, 후행 공백을 제거하고 각 요소의 콘텐트를 단일 공백으로 분리합니다.

<button id="download-button" aria-labelledby="download-button download-details">Download</button>
<span id="download-details">PDF, 2.4 MB</span>

위 예에서, 버튼의 접근 가능한 이름은 "DownloadPDF, 2.4 MB"가 아니라 "Download"와 "PDF" 사이에 공백이 있는 "Download PDF, 2.4 MB"가 될 것입니다.

Warning
  1. aria-labelledby 속성(property)은 체이닝 될 수 없습니다. 즉, aria-labelledby를 가진 요소가 aria-labelledby를 가진 다른 요소를 참조하는 경우, 참조된 요소의 aria-labelledby 속성(attribute)은 무시될 것입니다.
  2. 이름 계산 중에 요소가 두 번 이상 aria-labelledby에 의해 참조되는 경우, 두 번째 및 이후의 참조는 무시될 것입니다.
  3. aria-labelledby로 이름을 지정하지 않아야 하는 문단이나 목록 항목과 같은 특정 유형의 요소가 있습니다. 그것들은 역할에 따른 접근 가능한 이름 지정 지침 섹션의 표에 나와있습니다.
  4. aria-labelledby자식 콘텐츠로부터 이름 지정을 지원하는 역할(role)의 하나를 가진 요소에 적용되는 경우, 요소와 그 요소의 후손에 포함된 콘텐트는 aria-labelledby에 의해 참조되지 않는 한, 보조 기술 사용자에게 숨겨집니다. 보조 기술 사용자에게 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 이 속성(attribute)를 사용하여 이 요소들 중 하나의 콘텐트를 무시하게 하는 것을 방지하는 것이 강력하게 권장됩니다.
  5. aria-labelledby를 가진 요소의 이름을 계산하는 것은 복잡하고 숨겨진 콘텐트를 참조할 수 있기 때문에, 기대하는 이름이 사용자에게 노출되는지를 보장하도록 보조 기술을 가지고 테스트 하는 것이 특히 중요합니다.
5.3.2.4 Label 요소로 폼 컨트롤 이름 지정

HTML label 요소는 작성자가 레이블로 제공하는 콘텐트를 식별하고 폼 컨트롤과 연결할 수 있게 합니다. label 요소가 폼 컨트롤과 연결 될 경우, 브라우저는 label 콘텐트로부터 폼 컨트롤에 대한 접근 가능한 이름을 계산합니다.

예를 들어, 체크 박스와 나란히 표시되는 텍스트는 체크박스와 시각적으로 연결 될 수 있으므로, 시각적 연관성을 인식할 수 있는 사용자에 의해 체크박스 레이블로 이해됩니다. 하지만, 텍스트가 프로그래밍 방식으로 체크박스와 연결되어 있지 않으면, 보조 기술 사용자는 레이블이 없는 체크박스를 경험하게 될 것입니다. 다음과 같이 체크박스와 label 요소에 체크박스와 레이블 텍스트를 감싸는 것은 체크박스에 접근 가능한 이름을 제공합니다.

<label>
  <input type="checkbox" name="subscribe">
  뉴스레터 구독
</label>

폼 컨트롤은 label 요소의 for 속성(attribute)을 사용하여 레이블과 연결될 수도 있습니다. 이는 레이블과 폼 컨트롤이 형제가 되게하거나 DOM에서 부모가 다르지만 폼 컨트롤에 id 속성(attribute)을 추가하는 것을 요구하므로 오류가 발생하게 할 수 있습니다. 가능하다면, 연결을 위해 다음의 for 속성(attribute) 기법 대신 위의 캡슐화 기법을 사용하세요.

<input type="checkbox" name="subscribe" id="subscribe_checkbox">
<label for="subscribe_checkbox">뉴스레터 구독</label>

label 요소를 사용하는 것은 규칙 2: 보이는 텍스트 선택을 만족시키는 효과적인 기법입니다. 또한 규칙 3: 기본 기술 선택을 만족시킵니다. 네이티브 HTML 레이블은 ARIA 레이블링 기법보다 중요한 사용성과 접근성의 이점을 제공합니다: 브라우저는 자동으로 레이블을 클릭하는 것이 폼 컨트롤을 클릭한 것과 동일하게 합니다. 이는 폼 컨트롤의 누르는 영역을 증가시킵니다.

5.3.2.5 legend 요소로 필드셋 이름 지정

HTML fieldset 요소는 폼 컨트롤을 그룹핑하는데 사용될 수 있고, legend 요소는 그룹에 이름을 제공하는데 사용될 수 있습니다. 예를 들어, 라디오 버튼 그룹은 legend 요소가 라디오 버튼들에 대한 그룹에 레이블을 지정하는 fieldset 안에 함께 그룹핑 될 수 있습니다.

<fieldset>
  <legend>시작 클래스 선택</legend>
  <label><input type="radio" name="starter-class" value="green"> Green</label>
  <label><input type="radio" name="starter-class" value="red"> Red</label>
  <label><input type="radio" name="starter-class" value="blue"> Blue</label>
</fieldset>

이 그룹핑 기법은 다중 선택 문제를 표현하는데 특히 유용합니다. 작성자들이 질문과 답변 그룹을 연결 시킬 수 있게 합니다. 질문이 프로그램적으로 답변 그룹과 연결되지 않는 경우, 보조 기술 사용자는 질문을 알지 못한 채 답변에 접근할 것입니다.

fieldsetlegend를 사용하여 다른 유형의 폼 필드를 그룹핑 하고 이름을 지정하는 경우에도 유사한 이점을 얻을 수 있습니다.

<fieldset>
  <legend>배송 주소</legend>
  <p><label>이름 <input name="name" required></label></p>
  <p><label>주소 1 <input name="address-1" required></label></p>
  <p><label>주소 2 <input name="address-2"></label></p>
  ...
</fieldset>
<fieldset>
  <legend>청구서 받을 주소</legend>
  ...
</fieldset>

fieldset 요소에 이름을 지정하기 위해 legend 요소를 사용하는 것이 규칙 2: 보이는 텍스트 선택규칙 3: 기본 기술 선택을 만족시킵니다.

5.3.2.6 캡션으로 표와 삽화 이름 지정

HTML tablefigure에 대한 접근 가능한 이름은 각각 자식 caption이나 figcaption으로부터 파생될 수 있습니다. 표와 삽화는 종종 그것이 무엇에 관한 것인지, 어떻게 읽는지를 설명하기 위해, 그리고 간혹 주변 글에서 그것들을 가리키는데 사용되는 숫자를 제공하는 캡션을 가집니다. 캡션은 모든 사용자가 콘텐츠를 더 잘 이해하는데 도움이 되지만, 특히 보조 기술 사용자에게 도움이 됩니다.

HTML에서, table 요소는 데이터 테이블을 마크업하고 caption 요소를 사용하여 캡션이 함께 제공될 수 있습니다. table 요소가 aria-labelaria-labelledby를 가지지 않은 경우, caption이 접근 가능한 이름으로 사용 될 것입니다. 예를 들어 다음 표의 접근 가능한 이름은 특별 영업 시간입니다.

<table>
 <caption>특별 영업 시간</caption>
 <tr><td>5월 30일 <td>휴무
 <tr><td>6월 6일 <td>11:00-16:00
</table>

다음 예는 참조 할 수 있도록 표 번호를 (표 1)을 제공합니다.

<table>
 <caption>표 1. 1950년 오키나와인과 다른 일본인의 전통적인 식이 섭취</caption>
 <thead>
  <tr>
   <th>
   <th>오키나와, 1949
   <th>일본, 1950
 <tbody>
  <tr>
   <th>총 칼로리
   <td>1785
   <td>2068

  [...]

</table>

참고: 위 표는 Caloric restriction, the traditional Okinawan diet, and healthy aging: the diet of the world's longest-lived people and its potential impact on morbidity and life span에서 가져옴.

tablearia-labelaria-labelledby를 사용하여 이름이 지정되고, caption 요소가 있다면 이는 접근 가능한 설명이 될 것입니다. 예를 들어, 캡션으로 표와 삽화를 설명하기를 참고하세요.

유사하게, HTML figure 요소는 figcaption 요소를 사용하여 캡션이 제공 될 수 있습니다. 캡션은 삽화의 앞 혹은 뒤에 나타날 수 있지만, 삽화 뒤에 캡션이 있는 것이 더 일반적입니다.

<figure>
 <img alt="사막에서 걷고 있는 사람의 그림." src="Hole_JesusalDesierto.jpg">
 <figcaption>윌리엄 홀이 상상한 사막으로 들어가는 예수, 1908</figcaption>
</figure>

table 요소와 같이, figurearia-label이나 aria-labelledby를 사용하여 이름이 지정되지 않은 경우, figcaption 요소의 콘텐츠가 접근 가능한 이름으로 사용될 것입니다. 하지만 table 요소와 달리, figcaption 요소가 이름으로 사용되지 않은 경우, aria-describedby로 참조되지 않는 한 접근 가능한 설명이 되지는 않습니다. 그럼에도 불구하고, 보조 기술은 그것이 이름이나 설명 또는 둘 다로 사용되는지 여부에 관계 없이 figcaption의 콘텐트를 렌더링 합니다.

table 요소에 이름을 지정하기 위해 caption 요소를 사용하거나, figure 요소에 이름을 지정하기 위해 figcaption 요소를 사용하는 것은 규칙 2: 보이는 텍스트 선택규칙 3: 기본 기술 선택을 만족시킵니다.

5.3.2.7 title 및 placeholder로부터 파생 된 대체 이름

접근 가능한 이름이 주요 기법들 중 하나 (예를 들어, aria-labelaria-labelledby 속성(attribute)) 또는, 네이티브 마크업 기법을 (예를 들어, HTML label 요소나, HTML img 요소의 alt 속성(attribute)) 사용하여 제공되지 않은 경우, 브라우저는 대체 매커니즘으로 다른 속성(attribute)으로부터 접근 가능한 이름을 계산합니다. 대체 이름 계산으로 사용되는 속성(attribute)은 이름 지정을 위해 의도되지 않았기 때문에, 일반적으로 유효하지 않은 낮은 품질의 접근 가능한 이름을 생성합니다. 따라서, 규칙 4: 브라우저 폴백 방지에 설명된 대로 이 섹션에 설명된 대체 기술 보다 위에서 설명된 명시적 레이블링 기법을 우선하세요.

HTML 요소는 지정된 title 속성(attribute)을 가질 수 있습니다. title 속성(attribute)은 요소의 대체 접근 가능한 이름으로 사용될 수 있습니다. title 속성(attribute)은 일반적으로 사용자가 포인팅 기기로 요소 위를 맴돌 때 툴팁으로 시작적으로 표시되어 특별히 쉽게 찾을 수 없고, 포인팅 기기가 없은 시각 사용자에게도 접근 가능하지 않습니다.

예를 들어, 자식 legend 요소가 없지만 title 속성(attribute)이 있는 fieldset 요소는 title 속성(attribute)으로부터 접근 가능한 이름을 가져옵니다.

<fieldset title="시작 클래스 선택">
  <label><input type="radio" name="starter-class" value="green"> Green</label>
  <label><input type="radio" name="starter-class" value="red"> Red</label>
  <label><input type="radio" name="starter-class" value="blue"> Blue</label>
</fieldset>

HTML inputtextarea 요소에 대해, placeholder 속성(attribute)은 다른 (title 속성(attribute)을 포함하여) 레이블을 생성하는 것이 없다면 대체 레이블링 메커니즘으로 사용됩니다. 사용자가 폼 컨트롤에 초점을 주었을 때 시각적으로 사라지지 않기 때문에 label 요소를 사용하는 것이 더 좋습니다.

<!-- <label>을 사용하는 것이 권장됩니다 -->
<label>검색 <input type=search name=q></label>

<!-- placeholder가 폴백으로 사용됩니다 -->
<input type=search name=q placeholder="검색">

5.3.3 효과적이고 사용자 친화적인 접근 가능한 이름 구성

보조 기술 사용자, 특히 스크린리더 사용자의 경우, 접근 가능한 이름의 품질은 사용성에 가장 중요한 기여자 중 하나입니다. 충분한 정보를 제공하지 않는 이름이 사용자의 효과성(effectiveness)을 떨어뜨리는 반면 너무 긴 이름은 효율성(efficiency)을 떨어뜨립니다. 그리고 이해하기 어려운 이름은 효과성(effectiveness), 효율성(efficiency), 흥미를 떨어뜨립니다.

다음 지침은 사용자 친화적인 이름에 대한 시작점을 제공합니다.

  • 형태가 아닌 기능이나 목적을 전달하세요. 예를 들어, X 문자처럼 보이는 아이콘이 대화상자를 닫는 경우, X 가 아니라 닫기로 이름을 지정하세요. 유사하게, 왼쪽 사이드바의 내비게이션 링크 세트가 쇼핑몰 사이트의 상품 페이지를 탐색하는 경우, 내비게이션 영역을 왼쪽이 아니라 상품으로 이름을 지정하세요.
  • 가장 특징적이고 중요한 단어를 먼저 넣으세요. 종종 동작을 수행하는 대화형 요소(interactive element)의 경우, 동사가 첫 번째 단어라는 것을 의미합니다. 예를 들어, 연락처 목록이 각 연락처에 대한 편집, 삭제, 작업 버튼을 표기하는 경우, 편집 John Doe, 삭제 John Doe, 작업 John DoeJohn Doe 수정, John Doe 삭제, John Doe 작업보다 더 좋은 접근 가능한 이름일 것 입니다. 이름의 처음에 동사를 배치하여, 스크린리더 사용자는 더 쉽고 빠르게 John Doe에 대한 연락처 카드를 여는 요소뿐 아니라 다른 것들로부터 버튼을 구별할 수 있습니다.
  • 간결하게 하세요. 많은 요소들의 경우, 1 ~ 3 단어면 충분합니다. 필요할 경우에만 더 많은 단어를 추가하세요.
  • 접근 가능한 이름에 WAI-ARIA 역할(role) 이름을 포함시키지 마세요. 예를 들어, 버튼 이름에 버튼이라는 단어를 포함 시키거나, 이미지 이름에 이미지라는 단어를 포함시키거나, 내비게이션 영역 이름에 내비게이션이라는 단어를 포함시키지 마세요. 그렇게 하는 것은 스크린리더가 이름에 요소의 역할(role)을 추가로 전달하므로 스크린리더 출력이 중복되게 만들게 됩니다.
  • 요소가 실제로 동일하지 않는 한 동일한 역할을 가진 요소에 대해 고유한 이름을 생성하세요. 예를 들어, 동일한 위치를 참조하는 여러 링크가 있는 경우를 제외하고 페이지의 모든 링크는 서로 다른 이름을 가지도록 해야 합니다. 마찬가지로, 동일한 탐색 기능을 수행하는 동일한 콘텐트를 가진 영역이 없는 한 페이지의 모든 내비게이션 영역에 다른 이름을 지정하세요.
  • 대문자로 이름을 시작하세요; 이는 일부 스크린리더가 적절한 어조로 말하게 하는데 도움을 줍니다. 마침표로 이름을 끝내지 마세요; 이름은 문장이 아닙니다.

5.3.4 역할(role)별 접근 가능한 이름 지정 지침

어떤 요소는 항상 이름을 요구하고, 어떤 요소는 보통 또는 종종 이름을 요구하고, 그러나 어떤 요소들은 결코 이름이 지정되지 않아야 합니다. 다음 표는 ARIA 역할(role)을 나열하고 각각에 대한 다음 정보를 제공합니다:

이름 지정 필요성
작성자가 지정된 역할(role)을 가진 요소의 콘텐트를 보완하거나 대체하도록 하기 위해 이름을 지정하는 속성(attribute)나 요소(element)를 추가할 필요성의 정도를 나타냅니다. 이 열은 다음 값들 중 하나를 포함할 수 있습니다:
  • 내용이 불충분한 경우에만 필요: 이 역할(roel)을 가진 요소는 하위 콘텐츠에 의해 이름이 지정됩니다. aria-labelaria-labelledby가 적용된 경우, 요소와 요손의 후손에 포함된 콘텐트는 aria-labelledby에 의해 다시 참조되지 않는 한 보조 기술 사용자에게 숨겨집니다. 그렇게 하는 것이 보조 기술 사용자에게 도움이 되는 드문 경우를 제외하고 후손 콘텐트가 숨겨지는 것을 방지하세요.
  • 필수: ARIA 명세는 작성자가 이름을 제공하도록 요구합니다; 이름이 누락되는 것은 접근성 검사기가 오류를 보고합니다.
  • 권장: 이름을 제공하는 것이 강력히 권장됩니다.
  • 재량: 이름을 지정하는 것이 선택적이거나, 지침 컬럼에 설명된 상황에서는 사용되지 않아야 합니다.
  • 이름을 지정하지 말것: 기술적으로 허용된다 하더라도 이름을 지정하는 것은 강력히 권장되지 않습니다; 종종 보조 기술은 이름이 제공 된다 하더라도 이름을 표시하지 않습니다.
  • 금지: ARIA 명세는 요소에 이름지 지정되는 것을 허용하지 않습니다; 이름이 지정되는 경우, 접근성 검사기는 오류를 보고할 것입니다.
지침:
이름을 제공하는 것이 유익한지 여부를 결정하는데 도움이 되는 정보를 제공하고, 권장 기술을 설명합니다.
역할(role) 이름 지정 필요성 지침
alert 재량 일부 스크린리더는 경고 콘텐트를 낭독하기 전에 경로 이름을 낭독합니다. 따라서, aria-label은 경고의 내용으로 표시되지 않는 텍스트로 경고의 가시적 콘텐트에 대한 말문을 여는 방법을 제공합니다. aria-label을 사용하는 것은, alert 요소의 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, 경고 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
alertdialog 필수 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
application 필수 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
article 권장
  • 아티클을 서로 구별할 것이 권장됩니다; 아티클을 탐색할 때 사용자를 돕습니다.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
banner 재량
  • 동일한 페이지에 두 개의 banner 랜드마크 영역이 존재하는 일반적이지 않은 상황에 필요합니다. 그렇지 않으면 선택적입니다.
  • 시각적으로 보이는 레이블이 존재한다면 aria-labelledby를 사용하고, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
  • Banner 랜드마크 섹션을 참고하세요.
blockquote 재량 시각적으로 보이는 레이블이 존재하는 경우, aria-labelledby를 사용하여 인용구를 연결시키는 것은 일부 보조 기술 사용자들에게 이로울 수 있습니다.
button 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 시각적 하위 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
caption 금지
cell 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 시각적 하위 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • 이름이 요구되지 않는 다는 것에 주목하세요; 보조 기술은 표의 빈 셀은 빈 이름으로 표현될 것으로 기대합니다.
  • 연관된 행 또는 컬럼 헤더가 cell 이름을 지정하지 않는 다는 것에 주목하세요; 표에서 셀의 이름은 그것의 내용 입니다. 헤더는 보완 정보입니다.
checkbox 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • HTML type="checkbox" 기반인 경우, label 요소를 사용하세요.
  • 그렇지 않으면, aria-labelledby를 통해 가시적으로 보이는 콘텐트를 참조시키세요.
code 금지
columnheader 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 시각적 하위 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • columnheader 역할(role)이 HTML th에서 암시된 것이라면, HTML abbr 속성(attribute)이 스크린리더가 table, grid, treegrid 내의 연관된 cell을 읽을 때 낭독되기만 하는 이름의 축약 버전을 지정하는데 사용될 수 있습니다.
combobox 필수
  • combobox 역할(role)이 HTML selectinput 요소에 적용된 경우, HTML label 요소로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
complementary 권장
  • 동일한 페이지에 둘 이상의 complementary 랜드마크가 존재하는 경우 이름 지정이 필요합니다.
  • 랜드마크 영역을 탐색할 때 사용자가 영역 내용의 목적을 이해하는데 도움을 주기 위해 하나의 영역이 존재할 경우에도 이름을 지정하는 것이 권장됩니다.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Complementary 랜드마크 섹션을 참고하세요.
contentinfo 재량
  • 동일한 페이지에 둘 이상의 contentinfo 랜드마크 영역이 존재하는 일반적이지 않은 상황에 필요합니다. 그렇지 않으면 선택적입니다.
  • 시각적으로 보이는 레이블이 존재한다면 aria-labelledby를 사용하고, 그렇지 않으면 aria-label을 사용하세요.
definition 권장 aria-labelledby를 사용하여, role="term"를 가진 정의되는 용어를 참조시키세요.
deletion 금지
dialog 필수 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
directory 재량
  • 이름을 지정하는 것은 사용자가 디렉토리의 목적을 이해하는데 도움이 될 수 있습니다.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
document 재량 document 역할(role)을 가진 요소는 application 역할(role)을 가진 요소 내에 포함되며, 이름을 가져야 할 필요가 있습니다. 일반적으로, application 요소의 이름은 document 요소에 대한 충분한 컨텍스트와 정체성을 제공할 것입니다. application 요소는 흔치 않은 사용자 정의 위젯을 생성하는데에만 사용되기 때문에, 주의 깊은 평가가 접근 가능한 이름을 추가할지의 여부가 유익한지 결정하는데 필요합니다.
emphasis 금지
feed 권장
  • 스크린리더 사용자가 컨텍스트와 feed의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Feed 설계 패턴을 참고하세요.
figure 권장
  • HTML의 경우, figurefigcaption 요소를 사용하세요. figcaptionfigure에 대한 접근 가능한 이름으로서 제공할 것입니다. 캡션으로 표와 삽화 이름 지정 섹션을 참고하세요.
  • HTML을 사용하지 않는 경우, 혹은 레거시 HTML을 개조하는 경우 figure의 캡션을 가리키게 하여 figure에 aria-labelledby를 사용하세요.
  • 시각적으로 보이는 캡션이 없는 경우 aria-label이 사용될 수 있습니다.
form 권장
  • 스크린리더 사용자가 컨텍스트와 form 랜드마크의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Form 랜드마크 섹션을 참고하세요.
generic 금지
grid 권장
  • HTML table 요소에 grid가 적용된 경우, 접근 가능한 이름은 표의 caption 요소로부터 파생될 수 있습니다.
  • 그렇지 않으면, 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
gridcell 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • 이름이 필수가 아님을 주의하세요; 보고 기술은 그리드의 빈 셀이 빈 이름으로 표현될 것으으로 예상합니다.
  • 연관된 열이나 행 헤더는 gridcell에 이름을 지정하지 않음에 주의하세요; 그리드에서 셀 이름은 그것의 콘텐트 입니다. 헤더는 보완 정보(complementary information)입니다.
group 재량
  • HTML fieldset 요소를 사용하는 경우, 접근 가능한 이름은 legend 요소로부터 파생될 수 있습니다.
  • details 요소를 사용하는 경우, 이 요소에 대한 접근 가능한 이름을 제공하지 마세요. 사용자는 summary 요소로 상호 작용하고, 그것의 콘텐츠로부터 접근 가능한 이름을 파생시킬 수 있습니다.
  • optgroup 요소를 사용하는 경우, label 속성(attribute)을 사용하세요.
  • 그렇지 않으면, 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
heading 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
insertion 금지
img 필수 HTML img 요소의 경우, alt 속성(attribute)을 사용하세요. img 역할(role)을 가진 다른 요소의 경우, aria-labelledbyaria-label을 사용하세요.
link 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
list 재량
  • 잠재적으로 이름 목록과 페이지의 목록 탐색 모두를 지원하는 스크린리더 사용자에게 유용합니다.
  • navigation 영역과 같이 특히 이름이 지정된 컨테이너 내에 중첩된 경우, 잠재적으로 정신없게 만들거나 바람직하지 않게 스크린리더가 장황하게 이야기하는 원인이 됩니다.
  • 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정될 수 있습니다.
listbox 필수
  • listbox 역할(role)이 (값이 1보다 큰 multiple 속성이나 size 속성을 가진) HTML select 요소에 적용된 경우, HTML label 요소로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
  • Listbox 설계 패턴을 참고하세요.
listitem 이름을 지정하지 말것 이름 지정이 보조 기술에 의해 지원되지 않습니다; 목록 항목 내에 관련 내용을 포함시켜야 합니다.
log 재량 일부 스크린리더는 log 요소(element)의 콘텐트를 낭독하기 전에 log 요소(element)의 이름을 낭독합니다. 따라서, aria-label은 로그 요소(element)의 부분으로 노출되지 않는 텍스트로 log 요소(element)의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다. aria-label을 사용하는 것은 log 요소(element)에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, log 요소(element)의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
main 재량
  • 잠재적으로 특히 페이지 로드 이벤트를 생성하지 않고 main 콘텐츠 변경을 일으키는 싱글 페이지 어플리케이션에서 보조 기술 사용자를 지향하는데 도움이 됩니다.
  • 가시적으로 보이는 레이블이 존재한다면 aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정될 수 있습니다.
  • Main 랜드마크 섹션을 참고하세요.
marquee 필수 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
math 권장
  • math 요소(element)가 표현을 위한 자식만을 가지고 접근 가능한 이름이 수학 표현식을 전달하기 위해 의도된 경우, 표현식을 나타내는 문자열을 제공하도록 aria-label을 사용하세요.
  • math 요소(element)가 수학 표현식을 전달하는 탐색 가능한 콘텐트를 포함하고 표현식에 대한 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를 사용하세요.
  • 그렇지 않으면, 표현식에 이름을 지정하기 위해 aria-label을 사용하세요, 예를 들어, aria-label="피타고라스 정리".
menu 권장
  • 이 요소(element)의 가시성을 제어하는 메뉴 아이템이나 버튼을 나타내도록 aria-labelledby를 사용하세요.
  • 그렇지 않으면, aria-label을 사용하세요.
  • Menu나 Menu bar 설계 패턴을 참고하세요.
menubar 권장
  • 스크린리더 사용자가 컨텍스트와 menubar 내의 menuitem 요소(element)의 목적을 이해하도록 도와주세요. menubar에 이름을 지정하는 것은 메뉴 버튼에 이름을 지정하는 것과 비슷합니다. menu를 여는 button의 이름은 메뉴의 목적이 그것을 여는 것(open)임을 전달합니다. menubar 요소(element)는 지속적으로 노출되기 때문에, menubar의 이름은 동일한 목적을 제공할 수 있습니다.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Menu나 Menu bar 설계 패턴을 참고하세요.
menuitem 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • 주의: 자식 menu 내에 포함된 콘텐트는 자동으로 접근 가능한 계산에서 제외됩니다.
  • Menu나 Menu bar 설계 패턴을 참고하세요.
menuitemcheckbox 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • Menu나 Menu bar 설계 패턴을 참고하세요.
menuitemradio 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • Menu나 Menu bar 설계 패턴을 참고하세요.
meter 필수
  • HTML meter 요소(element)를 기반으로 하는 경우, HTML label 요소로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
navigation 권장
  • 스크린리더 사용자가 컨텍스트와 navigation 랜드마크의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Navigation 랜드마크 섹션을 참고하세요.
none 금지 role="none"을 가진 요소(element)는 (오류 케이스를 제외하고) 접근성 트리의 일부가 아닙니다. aria-labelledbyaria-label을 사용하지 마세요.
note 재량
  • 이름 지정은 선택적이지만, 스크린리더 사용자가 컨텍스트와 note의 목적을 이해하도록 도울 수 있습니다.
  • 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
option 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • Combobox 설계 패턴을 참고하세요.
paragraph 금지
presentation 금지 role="presentation"을 가진 요소(element)는 (오류 케이스를 제외하고) 접근성 트리의 일부가 아닙니다. aria-labelledbyaria-label을 사용하지 마세요.
progressbar 필수
  • progressbar 역할(role)이 HTML progress 요소(element)에 적용된 경우, HTML label 요소(element)로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
radio 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • HTML type="checkbox"를 기반으로 하는 경우, label 요소(element)를 사용하세요.
  • 그렇지 않으면, aria-labelledby를 통해 가시적으로 보이는 콘텐트를 참조시키세요.
radiogroup 필수
  • 보조 기술 사용자가 radio 버튼 그룹의 목적을 이해하도록 돕는 것이 권장됩니다.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Radio 그룹 설계 패턴을 참고하세요.
region 필수
  • 스크린리더 사용자가 컨텍스트와 랜드마크의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Region 랜드마크 섹션을 참고하세요.
row 내용이 불충분하고 treegrid의 후손이며 행이 focusable한 경우에만 필수 row 요소(element)가 treegrid에서 초점을 얻을 수 있는 경우, 스크린리더는 행으로 탐색하는 경우 행의 전체 콘텐트를 낭독합니다. 이것이 일반적으로 가장 적절한 동작입니다. 하지만, 어떤 상황에서, 셀이 낭독되는 순서를 변경하거나 낭독할 셀을 지정하기위해 aria-labelledby를 사용하여 특정 셀의 낭독을 제외시키는 것이 유리할 수 있습니다.
rowgroup 이름을 지정하지 말것 이름 지정이 보조 기술에 의해 지원되지 않습니다.
rowheader 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • rowheader 역할(role)이 HTML th로부터 적용된 경우, HTML abbr 속성(attribute)이 스크린리더가 table, grid, 또는 treegrid 내의 연관된 cell을 읽을 때에만 낭독되는 이름의 축약 버전을 지정하는데 사용될 수 있습니다.
scrollbar 재량
  • 이름 지정은 선택적이지만, 잠재적으로 스크린리더 사용자가 scrollbar의 목적을 이해하도록 도움을 줄 수 있습니다. 목적은 scrollbar에 대해 필요한 aria-controls 속성(attribute)을 사용하여 전달될 수 있습니다.
  • 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
search 권장
  • 스크린리더 사용자가 컨텍스트와 search 랜드마크의 목적을 이해하도록 도와주세요.
  • 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
  • Search 랜드마크 섹션을 참고하세요.
searchbox 필수
  • searchbox 역할(role)이 HTML input 요소(element)에 적용된 경우, HTML label 요소(element)로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
separator 재량
  • 페이지에 초점을 얻을 수 있는 separator 요소(element)가 둘 이상 존재하는 경우 권장됩니다.
  • 스크린리더 사용자가 컨텍스트와 separator의 목적을 이해하도록 도울 수 있습니다.
  • 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
slider 필수
  • slider 역할(role)이 HTML input 요소(element)에 적용된 경우, HTML label 요소(element)로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
  • Slider 설계 패턴Slider (Multi-Thumb) 설계 패턴을 참고하세요.
spinbutton 필수
  • textbox 역할(role)이 HTML input 요소(element)에 적용된 경우, HTML label 요소(element)로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
  • Spinbutton 설계 패턴을 참고하세요.
status 재량 일부 스크린리더는 status 요소(element)의 콘텐트를 낭독하기 전에 status 요소(element)의 이름을 낭독합니다. 따라서, aria-label은 status 요소(element)의 부분으로 노출되지 않는 텍스트로 로그 요소(element)의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다. aria-label을 사용하는 것은 status 요소(element)에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, status 요소(element)의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
strong 금지
subscript 금지
superscript 금지
switch 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • HTML type="checkbox"을 기반으로 하는 경우, label 요소(element)를 사용하세요.
  • 그렇지 않으면, aria-labelledby를 통해 가시적으로 보이는 콘텐트를 참조시키세요.
tab 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
table 필수
  • HTML table 요소(element)를 사용하는 경우, caption 요소(element)를 사용하세요.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
  • Table 설계 패턴을 참고하세요.
tablist 권장
  • 스크린리더 사용자가 컨텍스트와 tablist의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Carousel 설계 패턴Tabs 설계 패턴을 참고하세요.
tabpanel 필수
term 이름을 지정하지 말것 term은 일반적으로 role="definition" 요소(element)에 대한 이름이기 때문에, 용어 자체가 이름을 또 가지면 혼동 될 수 있습니다.
textbox 필수
  • textbox 역할(role)이 HTML inputtextarea 요소(element)에 적용된 경우, HTML label 요소(element)로 이름이 지정될 수 있습니다.
  • 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우 aria-labelledby를 사용하세요.
  • 가시적으로 보이는 레이블이 존재하지 않는 경우 aria-label을 사용하세요.
time 이름을 지정하지 말것 이름 지정이 보조 기술에 의해 지원되지 않습니다.
timer 재량 일부 스크린리더는 timer 요소(element)의 콘텐트를 낭독하기 전에 timer 요소(element)의 이름을 낭독합니다. 따라서, aria-label은 timer 요소(element)의 부분으로 노출되지 않는 텍스트로 timer 요소(element)의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다. aria-label을 사용하는 것은 timer 요소(element)에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, timer 요소(element)의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
toolbar 권장
  • 페이지에 둘 이상의 toolbar 요소(element)가 존재하는 경우, 이름 지정은 필수입니다.
  • 페이지에 오직 하나의 툴바만 존재하는 경우라도, 보조 기술 사용자가 툴바의 목적을 이해하도록 도와주세요.
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Toolbar 패턴을 참고하세요.
tooltip 내용이 불충분한 경우에만 필요
  • 경고! aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
tree 필수
  • 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Tree View 설계 패턴을 참고하세요.
treegrid 필수
  • treegrid가 HTML table 요소(element)에 적용된 경우, 접근 가능한 이름은 표의 caption 요소(element)로부터 파생될 수 있습니다.
  • 그렇지 않으면, 시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
  • Treegrid 설계 패턴을 참고하세요.
treeitem 내용이 불충분한 경우에만 필요
  • 경고! aria-labelaria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
  • 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
  • 주의: 자식 group 내에 포함된 콘텐트는 자동으로 접근 가능한 이름 계산에서 제외됩니다.
  • Tree View 설계 패턴을 참고하세요.

5.3.5 접근 가능한 이름 계산

유저 에이전트는 잠재적인 이름 지정 방법의 목록을 단계별로 통과하면서 이름을 생성하는 첫 방법을 사용하여 요소(element)에 대한 접근 가능한 이름 문자열을 구성합니다. 이 알고리즘은 접근 가능한 이름 명세에 정의되어 있습니다. 대략 다음과 같습니다:

  1. aria-labelledby 속성(property)이 있다면 이것이 사용됩니다.

  2. 이름이 여전히 비어있다면, aria-label 속성(property)이 있다면 이것이 사용됩니다.

  3. 이름이 여전히 비어있다면, 호스트-언어별 속성(attribute)이나 요소(element)가 존재한다면 이것이 사용됩니다. HTML의 경우, 요소(element)에 따라 다음과 같습니다:

    type 속성(attribute)이 Button, Submit Button, 또는 Reset Button 상태에 있는 input
    value 속성(attribute).
    type 속성(attribute)이 Image Button 상태에 있는 input
    img
    area
    alt 속성(attribute).
    fieldset
    첫 번째 자식 legend 요소(element).
    다른 form 요소(elements)
    연관된 label 요소(element)(들).
    figure
    첫 번째 자식 figcaption 요소(element).
    table
    첫 번째 자식 caption 요소(element).
  4. 이름이 여전히 비어있다면, 자식 콘텐츠로부터 이름 지정을 지원하는 역할(role)을 가진 요소(element)의 경우, 요소(element)의 콘텐트가 사용됩니다.

  5. 마지막으로, 이름이 여전히 비어있다면, 다른 폴백 호스트-언어별 속성(attribute)이나 요소(element)가 존재한다면 이것이 사용됩니다. HTML의 경우, 요소(element)에 따라 다음과 같습니다:

    type 속성(attribute)이 Text, Password, Search, Telephone, 또는 URL 상태에 있는 input
    textarea
    title 속성(attribute). 그렇지 않으면, placeholder 속성(attribute).
    type 속성(attribute)이 Submit Button 상태에 있는 input
    단어 "submit"의 지역화 된 문자열.
    type 속성(attribute)이 Reset Button 상태에 있는 input
    단어 "reset"의 지역화 된 문자열.
    type 속성(attribute)이 Image Button 상태에 있는 input
    title 속성(attribute). 그렇지 않으면, 문구 "Submit Query"의 지역화 된 문자열.
    summary
    단어 "Details".
    다른 요소(element)
    title 속성(attribute)

마지막 단계는 폴백 메커니즘입니다. 일반적으로 요소(element)에 레이블을 지정할 때는, 폴백이 아닌 메커니즘 중 하나를 사용하세요.

콘텐트로부터 이름을 계산하는 경우, 유저 에이전트는 아래 기술 된 대로 treeitemmenuitem의 경우를 제외하고 모든 후손 노드를 단계별로 통과합니다. 그리고, aria-labelledby 속성(attribute)의 참조를 따르는 경우, 마찬가지로 각 참조된 요소(element)의 트리를 통과합니다. 따라서, 이름 지정 알고리즘은 재귀적입니다. 다음 두 섹션은 알고리즘이 작동하는 방법의 비재귀 및 재귀 예제를 설명합니다.

treeitem 역할(role)에 대한 콘텐트로부터 이름을 계산하는 경우, 자식 group 요소(element)의 후손 콘텐트는 포함되지 않습니다. 예를 들어, 다음 tree에서, 첫 번째 트리 항목의 이름은 과일입니다; 사과, 바나나, 오렌지는 자동으로 생략됩니다.

<ul role="tree">
  <li role="treeitem">과일
    <ul role="group">
      <li role="treeitem">사과</li>
      <li role="treeitem">바나나</li>
      <li role="treeitem">오렌지</li>
    </ul>
  </li>
</ul>

비슷하게, menuitem 역할(role)에 대한 콘텐트로부터 이름을 계산하는 경우, 자식 menu 요소(element)의 후손 콘텐트는 포함되지 않습니다. 따라서, 다음 menu위 첫 번째 부모 menuitem의 이름은 과일입니다.

<ul role="menu">
  <li role="menuitem">과일
    <ul role="menu">
      <li role="menuitem">사과</li>
      <li role="menuitem">바나나</li>
      <li role="menuitem">오렌지</li>
    </ul>
  </li>
</ul>
5.3.5.1 비 재귀적 접근 가능한 이름 계산의 예

연결된 label 요소(element)가 없고 name 속성(attribute)만 있어서 접근 가능한 이름이 없는 input를 가정해보세요 (이렇게 하지 마세요):

<input name="code">

placeholder 속성(attribute)이 있다면, 이름 지정 폴백 메커니즘으로 제공됩니다 (이렇게 하지 마세요):

<input name="code"
       placeholder="One-time code">

또한 title 속성(attribute)이 존재하는 경우, 이것이 placeholder 대신 접근 가능한 이름으로 사용되지만, 여전히 폴백입니다 (이렇게 하지 마세요):

<input name="code"
       placeholder="123456"
       title="One-time code">

또한 label 요소(element)가 존재하는 경우 (추천), 그것이 접근 가능한 이름으로 사용되고, title 속성(attribute)은 접근 가능한 설명으로 대신 사용됩니다:

<label>One-time code
 <input name="code"
        placeholder="123456"
        title="Get your code from the app.">
</label>

또한 aria-label 속성(attribute)이 존재하는 경우 (보조 기술 사용자에게 명확성을 더해주기 위해서가 아닌 이상 추천되지 않습니다), 그것이 label 요소(element)를 대체하여 접근 가능한 이름이 될 것입니다:

<label>Code
 <input name="code"
        aria-label="One-time code"
        placeholder="123456"
        title="Get your code from the app.">
</label>

또한 aria-labelledby 속성(attribute)이 존재하는 경우, 다른 요소(element)와 속성(attribute)보다 우위에 섭니다 (aria-label 속성(attribute)은 사용되지 않을 경우 제거 되어야 합니다):

<p>Please fill in your <span id="code-label">one-time code</span> to log in.</p>
<p>
 <label>Code
  <input name="code"
         aria-labelledby="code-label"
         aria-label="This is ignored"
         placeholder="123456"
         title="Get your code from the app.">
 </label>
</p>
5.3.5.2 재귀적 접근 가능한 이름 계산의 예

접근 가능한 이름 계산 알고리즘은 필요할 때 재귀적으로 호출 될 것입니다. aria-labelledby 참조는 알고리즘이 재귀적으로 호출되도록 하고, 콘텐트로부터 접근 가능한 이름을 계산할 때 알고리즘은 각 자식 노드에 대해 재귀적으로 호출됩니다.

이 예에서, 버튼에 대한 레이블은 각 자식 노드로 재귀하여 계산된 결과 휴지통으로 이동입니다.

<button><img src="bin.svg" alt="휴지통">으로 이동</button>

aria-labelledby 참조를 따를 때, 알고리즘은 무한 루프를 방지하기 위해 동일한 참조를 두 번 따르는 것을 방지합니다.

이 예에서, 버튼에 대한 레이블은 우선 aria-labelledby가 참조하는 부모 요소(element)를 따라 계산되고, 이후 자식 노드들로부터 그 요소(element)에 대한 레이블을 계산하여 먼저 button 요소(element)를 다시 방문하지만 aria-labelledby 참조를 무시하고 대신 aria-label을 사용하고, 이후 다음 자식 (테스트 노드)를 방문하여 계산됩니다. 결과 레이블은 회의 삭제: 일일 상태 보고서입니다.

<div id="meeting-1">
  <button aria-labelledby="meeting-1" aria-label="회의 삭제:">X</button>
  일일 상태 보고서
</div>

5.4 접근 가능한 설명

5.4.1 설명 기법

5.4.1.1 aria-describedby로 내용을 참조하여 설명하기

aria-describedby 속성(property)은 aria-labelledby 속성(property)과 비슷하게 동작합니다. 예를 들어, 버튼은 형태 단락에 의해 설명 될 수 있습니다.

<button aria-describedby="trash-desc">휴지통으로 이동</button>
...
<p id="trash-desc">휴지통의 항목은 30일 후 영구적으로 제거될 것입니다.</p>

설명은 텍스트 문자열로 조정 됩니다. 예를 들어, 설명이 img 요소(element)를 포함하는 경우, 이미지에 해당하는 텍스트가 계산됩니다.

<button aria-describedby="trash-desc"> <img src="bin.svg" alt="휴지통">으로 이동</button>
...
<p id="trash-desc"><img src="bin.svg" alt="휴지통">의 항목은 30일 후 영구적으로 제거 될 것입니다.</p>

aria-labelledby와 마찬가지로, 요소가 숨겨져 있어도 aria-describedby를 사용하여 요소를 참조할 수 있습니다. 예를 들어, 양식의 텍스트 필드는 기본적으로 숨겨진 설명을 가질 수 있지만, 공개 위젯을 사용하여 요청 시 나타낼 수 있습니다. 설명은 aria-describedby로 직접적으로 텍스트 필드로부터 참조될 수도 있습니다. 다음 예에서, input 요소(element)에 대한 접근 가능한 설명은 username은 이 서비스에 로그인하는데 사용되는 이름입니다. 입니다.

<label for="username">Username</label>
<input id="username" name="username" aria-describedby="username-desc">
<button aria-expanded="false" aria-controls="username-desc" aria-label="Help about username">?</button>
<p id="username-desc" hidden>
  username은 이 서비스에 로그인하는데 사용되는 이름입니다.
</p>
5.4.1.2 캡션으로 표 및 삽화에 설명 지정

HTML에서, tablearia-labelaria-labelledby를 사용하여 이름이 지정되고, 자식 caption 요소(element)는 접근 가능한 설명이 됩니다. 예를 들어, 앞선 제목은 적절한 접근 가능한 이름으로 제공될 수 있고, caption 요소(element)는 더 긴 설명을 포함할 수 있습니다. 이러한 상황에서, aria-labelledby은 접근 가능한 이름을 제목 콘텐츠로 설정하기 위해 table에 사용 될 수 있고, caption은 접근 가능한 설명이 될 것입니다.

<h2 id="events-heading">다가오는 일정</h2>
<table aria-labelledby="events-heading">
 <caption>
  다가오는 일정의 달력, 27주에서 31주까지, 매주 월요일에 시작합니다. 첫 번째 열은 주차입니다.
 </caption>
 <tr><th>주차<th><th><th><th><th><th><th><tr><td>27<td><td><td><td><td><td><td>
 <tr><td>28<td><td><td><td><td><td><td><a href="/events/9856">왕세자비 생일</a>
 <tr><td>29<td><td><td><td><td><td><td>
 <tr><td>30<td><td><td><td><td><td><td>
 <tr><td>31<td><td><td><td><td><td><td>
</table>

HTML figure 요소(element)은 figcaption 요소(element)로부터 접근 가능한 이름을 얻을 수 있지만, 접근 가능한 이름으로 사용되지 않더라도 접근 가능한 설명으로는 사용되지 않습니다. figcaption 요소(element)가 접근 가능한 설명으로 적절하고, 접근 가능한 이름이 aria-labelledbyaria-label를 사용하여 지정되는 경우, figcaptionaria-describedby 속성(attribute)을 사용하여 접근 가능한 설명으로 명시적으로 설정 될 수 있습니다.

<h2 id="neutron">중성자</h2>
<figure aria-labelledby="neutron" aria-describedby="neutron-caption">
 <img src="neutron.svg" alt="중성자 내에는 상호 연결된 3개의 쿼크 (파란색 'u',
 빨간색 'd', 녹색 'd')가 있습니다.">
 <figcaption id="neutron-caption">
  중성자의 쿼크. 개별 쿼크의 색상 배정은 임의이지만, 세 가지 모든 색상이 표현되어야 합니다.
  쿼크 사이의 힘은 글루온에 의해 매개 됩니다.
 </figcaption>
</figure>
5.4.1.3 제목으로부터 파생된 설명

접근 가능한 설명이 aria-describedby 속성(attribute)을 사용하여 또는 주 호스트 언어별 속성(attribute)이나 요소(element) 중 하나를 (예를 들어, table에 대한 caption 요소) 사용하여 제공되지 않았다면, HTML의 경우 요소(element)가 title 속성(attribute)을 가지고 있다면 그것이 접근 가능한 설명으로 사용됩니다.

aria-describedby와 함께 가시적으로 보이는 설명이 일반적으로 권장됩니다. 보이지 않는 설명이 필요한 경우, 접근 가능한 설명을 가질 수 있는 HTML 요소(element)에 대해, title 속성(attribute)이 사용될 수 있습니다.

title 속성(attribute)은 일부 사용자, 특히 hover를 지원하는 포인팅 기기 (예를 들어, 마우스)를 사용하지 않고 스크린 리더를 사용하지 않는 정상 시력 사용자에게 접근 가능하지 않을 수 있음을 주의하세요

예를 들어, pattern 속성(attribute)를 사용하여 제한된 입력을 가지는 input 요소(element)는 예상되는 입력이 무엇인지를 설명하도록 title 속성(attribute)를 사용 할 수 있습니다.

<label> 부품 번호:
 <input pattern="[0-9][A-Z]{3}" name="part"
        title="부품 번호는 숫자 다음에 대문제 3개가 오는 숫자입니다."/>
</label>

이 경우 title 속성(attribute)은 사용자가 컨트롤에 호버하거나 초점을 줄 때 툴팁으로 사용자에게 보여질 수 있지만, 유저 에이전트가 양식을 검증할 때 input 요소(element)의 값이 pattern과 일치하지 않는 경우 오류 메세지의 일부로도 보여질 수 있습니다.

다른 예로, 링크는 title 속성(attribute)을 링크를 보다 자세히 설명하는데 사용할 수 있습니다.

<a href="http://twitter.com/W3C"
   title="W3C 트위터를 팔로우 하세요">
   <img src="/2008/site/images/Twitter_bird_logo_2012.svg"
        alt="트위터" class="social-icon" height="40" />
</a>

5.4.2 접근 가능한 설명 계산

접근 가능한 이름 계산과 같이, 접근 가능한 설명 계산은 테스트 문자열을 생성합니다.

접근 가능한 설명 계산 알고리즘은 이름이나 설명이 계산 여부에 따라 몇 가지 지점을 제외하고 접근 가능한 이름 계산 알고리즘과 동일합니다. 특히, 접근 가능한 설명을 위해 텍스트를 누적할 경우, 알고리즘은 aria-labelledby 대신 aria-describedby를 사용핳ㅂ니다.

유저 에이전트는 잠잭적인 설명 방법의 목록을 단계별로 통과하면서 설명을 생성하는 첫 방법을 사용하여 요소에 대해 접근 가능한 설명 문자열을 구성합니다. 이 알고리즘은 접근 가능한 이름 명세에 정의되어 있습니다. 대략 다음과 같습니다:

  1. aria-describedby 속성(property)이 있다면 이것이 사용됩니다.

  2. 설명이 여전히 비어있다면, 호스트 언어별 속성(attribute)이나 요소(element)가 존재한다면, 그것이 접근 가능한 이름으로 이미 사용되지 않았다면, 이것이 사용됩니다. HTML의 경우, 요소(element)에 다라 다음과 같습니다:

    type 속성(attribute)이 Button, Submit Button, 또는 Reset Button 상태에 있는 input
    value 속성(attribute).
    summary
    요소(element)의 하위 트리.
    table
    첫 번째 자식 caption 요소(element).
  3. 마지막으로 설명이 여전히 비어있다면, 다른 호스트 언어별 속성(attribute)이나 요소(element)가 있고, 그것이 접근 가능한 이름으로 이미 사용 되지 않았다면 이것이 사용됩니다. HTML의 경우 이것은 title 속성(attribute)입니다.

6. 키보드 인터페이스 개발

네이티브 HTML 양식 요소(element)들과 달리, 브라우저는 ARIA로 접근 가능하게 만들어진 그래픽 유저 인터페이스(GUI) 컴포넌트에 대한 키보드 지원을 제공하지 않습니다; 작성자는 코드에 키보드 지원을 제공해야 합니다. 이 섹션은 메뉴와 그리드 같은 ARIA 위젯 뿐 아니라 키보드로 운용할 수 있는 툴바와 대화상자 같은 인터랙티브 컴포넌트를 포함하는 웹 페이지의 기능을 만드는 원칙과 방법을 설명합니다. 초점 관리의 기본 사항과 함께, 이 섹션은 키보드 사용자들에게 다른 사람들이 사용할 수 있는 경험 만큼 효율적이고 즐거운 경험을 제공한다는 목표에 대한 지침을 제공합니다.

이 섹션은 다음을 다룹니다:

  1. ARIA 설계 패턴에 사용되는 초점 이동 규칙의 기본 원칙 이해.
  2. 가시적 초점 유지, 예측 가능한 초점 이동, 키보드 초점과 선택 상태 구분.
  3. 컴포넌트 간 초점 이동 관리, 예를 들어 Tab 키와 Shift+Tab 키가 눌렸을 때 초점 이동 방법.
  4. 초점을 얻을 수 있는 여러 요소들을 포함하는 컴포넌트 내부에서 키보드 초점 이동 관리, 예를 들어 라디오 그룹, 메뉴, 목록 상자, 트리, 그리드와 같이 위젯 내부에 프로그램적으로 초점을 노출하는 두 가지 다른 방식
  5. 비활성화 된 인터랙티브 요소(element)가 초점을 얻을 수 있게 만드는 시점 결정
  6. 보조 기술, 브라우저, 운영 체제의 키보드 명령과의 충동 문제를 방지하는 방법에 대한 지침을 포함하여, 키보드 단축키를 지정하고 표시

6.1 기본 키보드 탐색 규칙

ARIA 역할(role), 상태(state), 속성(property)은 마이크로소프트 윈도우, 맥 OS, 그놈을 비롯하여 대중적인 데스스톱 GUI의 GUI 컴포넌트 간에 공유되는 동작과 기능을 모델링 합니다. 마찬가지로, ARIA 설계 패턴은 웹에서 키보드 인터페이스의 쉬운 학습과 효율적인 운영을 용이하게 하는 목적을 가진 공통 규약을 일관되게 포함하여 이 플랫폼들로부터 사용자 기대치와 키보드 규칙을 차용합니다.

웹 페이지가 접근 가능하도록, 모든 인터랙티브 요소(element)들은 키보드를 통해 운용 가능해야 합니다. 또한, ARIA 설계 패턴에 기술된 공통 GUI 키보드 인터페이스 규칙의 일관된 적용은 특히 보조 기술 사용자에게 중요합니다. 예를 들어, 스크린리더 사용자가 트리를 운용한다고 가정해보세요. 익숙한 시각적 스타일이 사용자가 마우스로 트리 가지를 확장하는 방법을 발견하는데 도움이 되는 것 처럼, ARIA 속성(attribute)은 데스크톱 어플리케이션에서 트리의 소리와 느낌을 제공합니다. 따라서, 스크린리더 사용자는 일반적으로 오른쪽 방향키를 누르는 것이 축소된 노드를 확장할 것이라고 예상할 것입니다. 스크린리더는 요소(element)가 트리임을 알고 있기 때문에, 초보자에게 운용하는 방법을 지시하는 기능을 가질 수도 있습니다. 마찬가지로, 음성 인식 소프트웨어는 요소(element)를 트리로 인식하기 때문에 가지를 확장하고 축소하는 기능을 구현할 수 있고, 적절한 키보드 명령을 실행 할 수 있습니다. 이 모든 것들은 트리가 ARIA 트리 패턴에 기술된 대로 GUI 키보드 규약이 구현될 경우에만 가능합니다.

보통 모든 플랫폼에서 주요 키보드 탐색 규칙은 다른 키들, 주로 방향키가 여러 초점 가능한 요소들을 포함하는 컴포넌트의 내부로 초점을 이동시키는 반면 tabshift+tab 키는 한 UI 컴포넌트에서 다른 컴포넌트로 초점을 이동시킨다는 것입니다. tab 키를 누를 때 초점이 따르는 경로를 탭 시퀀스 혹은 탭 링이라고 부릅니다.

초점을 얻을 수 있는 여러 요소들을 포함하는 UI 컴포넌트의 일반적이 예는 라디오 그룹, 탭 목록, 메뉴, 그리드입니다. 예를 들어, 라디오 그룹은 각각이 초점을 얻을 수 있는 여러 라디오 버튼을 포함합니다. 하지만 오직 한 개 라디오 버튼만이 탭 시퀀스에 포함됩니다. Tab 키를 누른 후 초점은 그룹 내의 라디오 버튼으로 이동하고, 방향키를 누르면 그룹 내의 라디오 버튼 간에 초점이 이동하며, 다시 Tab 키를 누르면 라디오 그룹을 벗어나 탭 시퀀스 내의 다음 요소로 초점이 이동됩니다.

ARIA 명세는 composite 위젯으로 여러 초점을 얻을 수 있는 요소(element)를 포함하는 개별 UI 컴포넌트를 참조합니다. composite 내에서 초점 이동을 제어하는 프로세스를 초점 관리라고 합니다. 다음은 초점 관리를 보여주는 예제 구현이 포함된 일부 ARIA 설계 패턴입니다:

6.2 식별 가능하고 예측 가능한 키보드 초점

이 섹션을 완료하기 위한 작업은 issue 217에서 추적됩니다.

키보드로 조작할 경우, 좋은 경험의 두 가지 필수 요소는 키보드 초점의 위치를 쉽게 식별할 수 있고 탐색 키가 눌린 후 초점이 놓인 위치를 예측 할 수 있는 기능입니다. 다음 요인들은 웹 페이지가 사용자에게 이러한 기능을 제공하는 정도에 영향을 줍니다.

  1. 초점 표시의 가시성: 사용자는 키보드 초첨 표시를 다른 시각적 디자인 기능과 쉽게 구별 할 수 있어야 합니다. 마우스 사용자가 마오스 포인터를 찾기 위해 마우스를 움직이는 것 처럼, 키보드 사용자는 움직임을 보기 위해 탐색 키를 눌러 볼 수 있습니다. 초점 이동에 대한 시각적 변화가 감지하기 어려우면, 많은 사용자들은 초점을 잃어버리고 조작 할 수 없게 됩니다. 작성자들은 브라우저에서 제공되는 기본 초점 표시기를 사용하는 것이 좋습니다. 기본값을 재정의하려면 다음을 고려하세요:
    • 어떤 것들은... 고대비 모드에서 색상과 그라디언트가 사라질 수 있습니다.
    • 사용자는 초첨 vs 선택 그리고 이중 초점의 인식에 기술된 대로 초점과 선택 사이를 쉽게 구별할 수 있어야 합니다. 특히, 선택된 요소들을 포함하는 컴포넌트가 초점을 포함하고 있지 않은 경우.
    • ... 다른 추가 고려 사항들 ...
  2. 초점의 지속성: 유저 인터페이스 내에 활성화 된 컴포넌트가 항상 있고 (document.activeElement가 null이 아니거나 body 요소가 아닌) 활성 요소(element)는 시각적인 초점 표시기를 가져야 하는 것이 필수적입니다. 작성자는 현재 활성 요소(element)에 영향을 주는 이벤트를 관리하여 초점이 여전히 표시되고 논리적으로 이동하도록 해야 합니다. 예를 들어, 사용자가 대화 상자를 닫거나 목록에서 항목을 삭제하는 것과 같이 파괴적인 작업을 수행하는 경우, 활성 요소(element)는 숨겨지거나 DOM에서 제거될 것입니다. 이러한 이벤트가 대화상자를 발생시킨 버튼이나 삭제된 항목 다음의 목록 항목으로 초점을 설정하지 않으면, 브라우저는 body 요소(element)로 초점을 설정하여, 사실상 유저 인터페이스 내에서 초점을 잃게 만듭니다.
  3. 이동의 예측 가능성: 키보드 인터페이스의 사용성은 사용자가 탐색 키를 누른 이후 초점이 어디로 놓일 지 얼마나 손쉽게 추측할 수 있는가에 따라 크게 영향을 받습니다. 예측 가능성을 최적화 하는 몇 가지 가능한 접근 방식은 다음과 같습니다:
    • 페이지 언어의 읽기 순서와 일치하는 패턴으로 초점을 이동시킵니다. 예를 들어, 왼쪽에서 오른쪽 방향의 언어에서는 왼쪽에서 오른쪽으로, 위에서 아래로 초점이 이동하는 탭 시퀀스를 만드세요.
    • 다른 섹션으로 초점을 이동시키기 전에 페이지의 섹션의 모든 요소(element)를 탭 시퀀스에 포함시키세요. 예를 들어, 왼쪽 사이드 바, 가운데 영역, 오른쪽 사이드 바에 콘텐트가 있는 여러 열을 가진 페이지에서, 가운데 열의 첫 번째 초점을 얻을 수 있는 요소(element)로 초점을 이동시키기 전에 왼쪽 사이드 바의 모든 요소를 포함하는 탭 시퀀스를 만드세요.
    • 탭 시퀀스에서 연속된 두 요소(element)간의 거리가 중요한 경우, 뒤로 이동으로 인식 되는 이동을 피하세요. 예를 들어, 왼쪽에서 오른쪽 방향의 언어를 가진 페이지에서, 메인 콘텐트의 우측 하단에 있는 마지막 요소(element)에서 왼쪽 사이드바의 상위 요소(element)로 점프하는 것은, 특히 시야가 좁은 사용자에게, 예측하기 어렵고 따라가기가 더 어렵습니다.
    • 사이트 전체적으로 일관적인 패턴을 따르세요. 유사한 페이지에 유사한 초점 이동 패턴이 있을 때 키보드 경험은 더 예측 가능합니다.
    • 다음과 같은 경우를 제외하고 페이지가 로드 될 때 초기 초점을 설정하지 마세요:
      • 페이지가 로드 된 직후 거의 모든 사용자가 사용하는 단일의 주요 기능만을 제공하는 경우
      • 일부 특정 사용자가 페이지를 자주 사용할 가능성이 높은 경우

6.3 초점 vs 선택, 이중 초점 인식

경우에 따라, 동시에 한 페이지에 두 요소가 초점을 가지는 것처럼 나타날 수 있습니다. 예를 들어, 다중 선택 목록 상자에서, 옵션이 선택되는 경우 회색으로 표시 될 것입니다. 그러나, 초점 표시기는 선택 될 수 있는 다른 옵션으로 여전히 이동 될 수 있습니다. 마찬가지로, 사용자가 탭 목록에서 탭을 활성화시키면, 선택된 상태가 탭에 설정되고 시각적 모양이 변경됩니다. 하지만 사용자는 탭이 선택 된 모양과 상태를 유지하면서 페이지의 다른 곳으로 초점 포시기를 이동하면서 여전히 탐색 할 수 있습니다.

초점과 선택은 상당히 다릅니다. 키보드 사용자의 관점에서, 초점은 마우스 포인터와 같은 포인터 입니다; 탐색 경로를 추적합니다. 초점 포인트는 항상 하나 뿐이며 모든 작업은 초점 포인트에서 이루어집니다. 반면에, 선택은 목록 상자, 트리, 탭 목록과 같은 일부 위젯에서 수행될 수 있는 작업입니다. 위젯이 단 한 개 선택만 지원하는 경우, 단 한 개 항목만 선택 가능하고 초점이 위젯 내부를 이동할 때 선택 된 상태가 단순히 초점을 따라가는 경우가 많습니다. 즉, 일부 위젯에서, 초점 이동이 선택 작업을 수행 할 수도 있습니다. 하지만, 위젯이 다중 선택을 지원하는 경우, 선택된 상태는 한 개 이상이 될 수 있고, 초점 이동에 대한 키는 선택을 수행하지 않습니다. 일부 다중 선택 위젯은 초점 이동과 선택 변경 키 명령을 지원하지만, 이러한 키는 일반 탐색 키와는 다릅니다. 마지막으로 초점이 선택된 요소를 포함하는 위젯을 떠날 때, 선택 된 상태는 지속됩니다.

개발자 관점에서, 차이점은 간단합니다 -- 초점을 얻은 요소(element)는 활성 요소 (document.activeElement)입니다. 선택된 요소(element)는 aria-selected="true"를 가지는 요소(element)입니다.

초점과 선택 된 상태와 관련하여, 디자이너와 개발자에게 중요한 고려사항은 다음과 같습니다:

바로 위 "시각적으로 구별"에 대해서 한 가지 언급해보면, 단순히 "디자이너의 눈으로 보기에" 구별되는게 아니라, 색맹·색약·저시력자의 눈에도 시각적으로 구분이 가능해야 함을 의미한다.

6.4 초점을 따라 자동으로 선택되게 하는 시기 결정

탭 목록이나 단일 선택 목록 상자와 같이 단 하나의 요소(element)만 선택 될 수 있는 복합 위젯에서, 초점 이동은 초점을 얻은 요소(element)가 선택 된 요소(element)가 되게 할 수 있습니다. 이를 초점을 따라 선택 되도록 하는 것이라고 합니다. 초점을 따라 선택 되도록 하는 것은 종종 사용자에게 유익하지만, 일부 상황에서는 접근성에 매우 해롭습니다.

예를 들어, 탭 목록에서, 선택 상태는 패널이 노출되어 있음을 나타내는데 사용 됩니다. 따라서, 탭 목록에서 선택이 초점을 따르는 경우, 한 탭에서 다른 탭으로 초점 이동은 자동으로 노출되는 패널을 변경시킵니다. DOM에 패널의 콘텐츠가 존재한다면, 새로운 패널의 노출은 거의 즉시 이루어집니다. 6개 탭 중 4번째 탭을 노출시키기 원하는 키보드 사용자는 오른쪽 키를 3번 빠르게 눌러 그렇게 할 수 있습니다. 그리고 탭의 레이블을 탐색하여 인식하는 스크린리더 사용자는 대기 시간 없이 전체 탭 목록을 효율적을 읽을 수 있습니다.

반면에, 새로운 패널을 노출시키는 것이 네트워크 요청을 발생시키고 페이지가 갱신(refresh) 될 수 있는 경우, 초점을 따라 자동으로 선택되게 하는 것은 키보드와 스크린리더 사용자의 경험을 파괴할 수 있습니다. 이 경우, 네 번째 탭을 표시하거나 탭 목록을 읽는 것은 사용자가 각 초점의 이동과 함께 상당한 지연 시간을 경험하기 때문에 지루하고 시간을 낭비하는 작업이 됩니다. 게다가, 새 탭이 페이지를 갱신하면 사용자는 새 페이지가 로드 될 때까지 기다려야 할 뿐만 아니라 탭 목록으로 초점을 다시 보내야 합니다.

선택이 초점을 따르지 않는 경우, 사용자는 EnterSpace 키를 눌러 선택 된 요소(element)를 변경합니다.

6.5 컴포넌트 간 키보드 탐색 (탭 시퀀스)

여기서 컴포넌트(component)는 구성 요소로의 의미입니다. Front-End 개발에서 이야기하는 컴포넌트 단위와는 차이가 있습니다.

§ 6.1 기본 키보드 탐색 규칙 섹션에 설명된 대로, 모든 대화형 UI 컴포넌트는 키보드를 통해 접근 할 수 있어야 합니다. 이것은 탭 시퀀스에 그것들을 포함시키거나 탭 시퀀스에 있는 컴포넌트에 (예를 들어, 복합 컴포넌트의 일부) 접근 할 수 있도록 함으로써 가장 잘 달성됩니다. 이 섹션에서는 탭 시퀀스를 만들고 관리하는 방법을 다루고, 이후 섹션에서는 컴포넌트 내에 포함된 초점을 얻을 수 있는 요소(element)가 키보드 접근 가능하도록 하는 내용을 다룹니다.

[HTML] tabindex와 [SVG2] tabindex 속성(attribute)은 탭 시퀀스에 요소(element)를 추가하거나 제거하는데 사용될 수 있습니다. tabindex 값은 탭 시퀀스 순서에도 영향을 미칠 수도 있지만, 그 목적으로 tabindex를 사용하지 않는 것을 강력히 권합니다.

HTML 에서, 웹 페이지의 기본 탭 시퀀스는 maxOS에서는 form 요소(element)만 포함하는 것을 제외하고, 링크와 form 요소(element)만 포함합니다. macOS 시스템 환경 설정에는 탭 키가 모든 초점을 얻을 수 있는 요소(element)로 초점을 이동할 수 있는 키보드 설정이 포함되어 있습니다.

탭 시퀀스의 기본 요소(element) 순서는 DOM의 요소(element) 순서입니다. DOM 순서는 또한 스크린리더 낭독 순서를 결정합니다. 이는 § 6.2 식별 가능하고 예측 가능한 키보드 초점에 기술된 대로 키보드 탭 시퀀스와 스크린리더 낭독 순서를 정렬되고, 논리적이고, 예측 가능하게 유지하는데 중요합니다. 읽기 순서와 함께 정렬을 유지하면서 탭 시퀀스 순서를 조작하는 모든 브라우저에서 현재 사용 가능한 가장 강력한 방법은 DOM에서 요소(element)를 재정렬 하는 것입니다.

tabindex 속성(attribute) 값은 다음 효과를 가집니다.

tabindex 가 없거나 유효한 값을 가지지 않는 경우
요소(element)는 기본 초점 동작을 가집니다. HTML에서, form 컨트롤과 HREF 속성(attribute)을 가진 앵커만 탭 시퀀스에 포함됩니다.
tabindex="0"
요소(element) DOM에서의 위치에 따라 탭 시퀀스에 포함됩니다.
tabindex="-1"
요소(element)는 탭 시퀀스에 포함되지 않지만 element.focus()로 초점을 얻을 수 있습니다.
tabindex="X", X는 1 <= X <= 32767 범위의 정수
이 값을 사용하지 않는 것을 강력히 권합니다. 요소(element)는 tabindex의 값에 따라 탭 시퀀스에 배치됩니다. tabindex 값이 0인 요소(element)와 기본적으로 초점을 얻을 수 있는 요소(element)들은 tabindex 값이 1 이상인 요소(element) 이후 시퀀스에 있게 됩니다.

6.6 컴포넌트 내부 키보드 탐색

§ 6.1 기본 키보드 탐색 규칙 섹션에 기술된 대로, 탭 시퀀스는 단 하나의 복합 UI 컴포넌트의 초점을 얻을 수 있는 요소(element)만 포함해야 합니다. 일단 복합 컴포넌트가 초점을 포함하면, TabShift + Tab 이외의 키들로 사용자가 복합 컴포넌트의 초점 가능한 요소(element) 간에 초점 이동을 할 수 있게 합니다. 작성자는 복합 컴포넌트 내부에서 초점을 이동시키는 키를 자유롭게 선택할 수 있지만, § 3. 설계 패턴과 위젯에 설명 된 대로 공통 GUI 운영 체제의 유사한 컴포넌트와 동일한 키 바인딩을 사용하는 것을 강력히 권합니다.

Tab 키 이벤트의 결과로 초점을 얻을 때 복합 컴포넌트 내 초점을 얻을 위치에 대한 규칙은 복합 컴포넌트의 유형에 따라 다릅니다. 일반적으로 다음 중 하나입니다.

다음 섹션에서는 복합 요소(element)에서 초점을 관리하기 위한 두가지 전략: 이동(roving) tabindex 생성과 aria-activedescendant 속성(property) 사용에 대해 설명합니다.

6.6.1 이동(roving) tabindex를 사용하여 컴포넌트에서 초점 관리

복합 UI 컴포넌트에서 초점을 관리하기 위해 이동 tabindex를 사용하는 경우, 탭 시퀀스에 포함 되어야 할 요소(element)는 0 값의 tabindex를 가지고 복합 컴포넌트의에 포함 된 다른 모든 초점을 얻을 수 있는 요소(element)는 -1 값의 tabindex를 가집니다. 이동 tabindex 전략에 대한 알고리즘은 다음과 같습니다.

  • 컴포넌트 컨테이너가 로드되거나 생성될 때, 초기에 탭 시퀀스에 포함되는 요소(element)에 tabindex="0"를 설정하고 포함 된 다른 모든 초점을 얻을 수 있는 요소(element)에 tabindex="-1"을 설정하세요.
  • 컴포넌트가 초점을 포함하고 사용자가 컴포넌트 내에서 방향키와 같이 초점을 이동시키는 탐색 키를 누를 때:
    • tabindex="0"를 가진 요소(element)에 tabindex="-1"를 설정하세요.
    • 키 이벤트의 결과로 초점을 얻게 될 요소(element)에 tabindex="0"를 설정하세요.
    • tabindex="0"를 가진 요소(element)에 element.focus()로 초점을 설정하세요.
  • 설계가 다음에 사용자가 Tab이나 Shift+Tab으로 복합 컴포넌트 내로 초점을 이동시킬 때 특정 요소가 초점을 얻도록 요구하는 경우, 복합 컴포넌트가 초점을 잃을 때 그 대상 요소(element)가 tabindex="0"를 가지고 있는지 확인하세요. 그렇지 않으면, 대상 요소(element)에 tabindex="0"를 설정하고 이전에 tabindex="0"를 가졌던 요소(element)에 tabindex="-1"을 설정하세요.

초점을 관리하기 위해 aria-activedescendant 보다 이동 tabindex 사용의 한 가지 이점은 유저 에이전트가 새롭게 초점을 얻은 요소를 뷰(view)로 스크롤 한다는 것입니다.

6.6.2 aria-activedescendant를 사용하여 복합 컴포넌트에서 초점 관리

컴포넌트 컨테이너가 aria-activedescendant 속성을 지원하는 ARIA 역할(role)을 가지는 경우, tabindex 속성(attribute)을 관리하고 컨테이너 내에 초점을 얻을 수 있는 요소(element) 간에 DOM 초점을 이동시킬 필요가 없습니다. 대신, 컨테이너 요소(element)만 탭 시퀀스에 포함되면 됩니다. 컨테이너가 DOM 초점을 가지는 경우, 컨테이너의 aria-activedescendant 값은 위젯에서 활성화 되는 요소(element)를 보조 기술에 알려줍니다. 보조 기술은 DOM 초점이 aria-activedescendant 속성(property)를 가진 요소(element)에 있다 하더라도 활성화 된 것으로 참조되는 요소(element)를 초점을 얻은 요소(element)라고 간주할 것입니다. 그리고, aria-activedescendant 값이 변경될 때, 보조 기술은 DOM 초점이 실제로 이동될 때 받는 것과 동일한 초점 변경 이벤트를 받을 것입니다.

초점 관리의 aria-activedescendant 사용 방법 단계는 다음과 같습니다.

  • aria-activedescendant를 지원하는 역할(role)을 가진 컨테이터 요소(element)가 로드되거나 생성될 때, 다음을 보장하세요:
    • 컨테이너 요소(element)가 § 6.5 컴포넌트 간 키보드 탐색 (탭 시퀀스)에 기술된 대로 탭 시퀀스에 포함되거나, 이동 tabindex를 구현하는 복합 컴포넌트의 초점을 얻을 수 있는 요소(element)입니다.
    • IDREF가 위젯이 초점을 받을 때 컨테이너 내의 활성으로 식별되어야 하는 요소(element)의 ID인 aria-activedescendant="IDREF"가집니다. 참조 된 요소(element)는 아래 설명된 DOM 관계 요구 사항을 충족해야 합니다.
  • 컨테이너 요소(element)가 DOM 초점을 얻을 때, 활성 요소(element)에 시각적 초점 표시기를 그리고 활성 요소가 뷰(view) 안으로 스크롤 되도록 보장하세요.
  • 복합 위젯이 초점을 포함하고 사용자가 위젯 내에서 방향키와 같은 초점을 이동하는 탐색 키를 누를 때:
    • 보조 기술에 활성으로 보고되어야 하는 요소(element)를 가리키도록
    • 필요하다면, 시각적 초점 표시기를 이동시키고 뷰(view) 안으로 활성 요소(element)를 스크롤 되게 하세요.
  • 설계가 다음에 사용자가 Tab이나 Shift+Tab으로 복합 컴포넌트 내로 초점을 이동시킬 때 특정 요소(element)가 초점을 얻도록 요구하는 경우, 컨테이너가 초점을 잃을 때 aria-activedescendant가 그 대상 요소(element)를 가리키고 있는지 확인하세요. 그렇지 않으면, aria-activedescendant를 대상 요소(element)를 가리키도록 설정하세요.

aria-activedescendant에 대한 명세는 aria-activedescendant 속성(attribute)을 가진 초점을 얻은 요소(element)와 속성(attribute) 값에 의해 활성으로 참조되는 요소(element) 간의 DOM 관계에 중요한 제한 사항을 둡니다. 다음 세 가지 조건 중 하나가 충족되어야 합니다.

  1. 활성으로 참조 된 요소(element)는 초점을 얻은 참조하는 요소(element)의 DOM 후손입니다.
  2. 초점을 얻은 참조하는 요소(element)는 활성으로 참조되는 요소(element)의 ID를 포함하는 aria-owns 속성(property)에 지정된 값을 가집니다.
  3. 초점을 얻은 요소(element)는 textbox 역할(role)을 가지고 aria-activedescendant를 지원하는 역할(role)을 가지면서 다음 중 하나인 요소(element)를 참조하는 aria-controls 속성(property)를 가집니다:
    1. 활성으로 참조 된 요소(element)가 제어 요소(element)의 후손입니다.
    2. 제어 요소(element)는 활성으로 참조되는 요소(element)의 ID를 포함하는 aria-owns 속성(property)에 지정된 값을 가집니다.

6.7 Focusability of disabled controls

By default, disabled HTML input elements are removed from the tab sequence. In most contexts, the normal expectation is that disabled interactive elements are not focusable. However, there are some contexts where it is common for disabled elements to be focusable, especially inside of composite widgets. For example, as demonstrated in the § 3.15 Menu or Menu bar pattern, disabled items are focusable when navigating through a menu with the arrow keys.

Removing focusability from disabled elements can offer users both advantages and disadvantages. Allowing keyboard users to skip disabled elements usually reduces the number of key presses required to complete a task. However, preventing focus from moving to disabled elements can hide their presence from screen reader users who "see" by moving the focus.

Authors are encouraged to adopt a consistent set of conventions for the focusability of disabled elements. The examples in this guide adopt the following conventions, which both reflect common practice and attempt to balance competing concerns.

  1. For elements that are in the tab sequence when enabled, remove them from the tab sequence when disabled.
  2. For the following composite widget elements, keep them focusable when disabled:
  3. For elements contained in a toolbar, make them focusable if discoverability is a concern. Here are two examples to aid with this judgment.
    1. A toolbar with buttons for moving, removing, and adding items in a list includes buttons for "Up", "Down", "Add", and "Remove". The "Up" button is disabled and its focusability is removed when the first item in the list is selected. Given the presence of the "Down" button, discoverability of the "Up" button is not a concern.
    2. A toolbar in an editor contains a set of special smart paste functions that are disabled when the clipboard is empty or when the function is not applicable to the current content of the clipboard. It could be helpful to keep the disabled buttons focusable if the ability to discover their functionality is primarily via their presence on the toolbar.

One design technique for mitigating the impact of including disabled elements in the path of keyboard focus is employing appropriate keyboard shortcuts as described in § 6.9 Keyboard Shortcuts.

6.8 Key Assignment Conventions for Common Functions

The following key assignments can be used in any context where their conventionally associated functions are appropriate. While the assignments associated with Windows and Linux platforms can be implemented and used in browsers running in macOS, replacing them with macOS assignments in browsers running on a macOS device can make the keyboard interface more discoverable and intuitive for those users. In some cases, it may also help avoid system or browser keyboard conflicts.

Function Windows/Linux Key macOS Key
open context menu Shift + F10
Copy to clipboard Control + C Command + C
Paste from clipboard Control + V Command + V
Cut to clipboard Control + X Command + X
undo last action Control + Z Command + Z
Redo action Control + Y Command + Shift + Z

6.9 Keyboard Shortcuts

When effectively designed, keyboard shortcuts that focus an element, activate a widget, or both can dramatically enhance usability of frequently used features of a page or site. This section addresses some of the keyboard shortcut design and implementation factors that most impact their effectiveness, including:

  1. Understanding how keyboard shortcuts augment a keyboard interface and whether to make a particular shortcut move focus, perform a function, or both.
  2. Making key assignments and avoiding assignment conflicts with assistive technologies, browsers, and operating systems.
  3. Exposing and documenting key assignments.

6.9.1 Designing the Scope and Behavior of Keyboard Shortcuts

This section explains the following factors when determining which elements and features to assign keyboard shortcuts and what behavior to give each shortcut:

  1. Ensuring discovery through navigation; keyboard shortcuts enhance, not replace, standard keyboard access.
  2. Effectively choosing from among the following behaviors:
    1. Navigation: Moving focus to an element.
    2. Activation: Performing an operation associated with an element that does not have focus and might not be visible.
    3. Navigation and activation: Both moving focus to an element and activating it.
  3. Balancing efficiency and cognitive load: lack of a shortcut can reduce efficiency while too many shortcuts can increase cognitive load and clutter the experience.
6.9.1.1 Ensure Basic Access Via Navigation

Before assigning keyboard shortcuts, it is essential to ensure the features and functions to which shortcuts may be assigned are keyboard accessible without a keyboard shortcut. In other words, all elements that could be targets for keyboard shortcuts need to be focusable via the keyboard using the methods described in:

Do not use keyboard shortcuts as a substitute for access via navigation. This is essential to full keyboard access because:

  1. The primary means of making functions and their shortcuts discoverable is by making the target elements focusable and revealing key assignments on the element itself.
  2. If people who rely on the keyboard have to read documentation to learn which keys are required to use an interface, the interface may technically meet some accessibility standards but in practice is only accessible to the small subset of them who have the knowledge that such documentation exists, have the extra time available, and the ability to retain the necessary information.
  3. Not all devices that depend on keyboard interfaces can support keyboard shortcuts.
6.9.1.2 Choose Appropriate Shortcut Behavior

The following conventions may help identify the most advantageous behavior for a keyboard shortcut.

  • Move focus when the primary objective is to make navigation more efficient, e.g., reduce the number of times the user must press Tab or the arrow keys. This behavior is commonly expected when assigning a shortcut to a text box, toolbar, or composite, such as a listbox, tree, grid, or menubar. This behavior is also useful for moving focus to a section of a page, such as the main content or a complementary landmark section.
  • Activate an element without moving focus when the target context of the function is the context that contains the focus. This behavior is most common for command buttons and for functions associated with elements that are not visible, such as a "Save" option that is accessible via a menu. For example, if the focus is on an option in a listbox and a toolbar contains buttons for moving and removing options, it is most beneficial to keep focus in the listbox when the user presses a key shortcut for one of the buttons in the toolbar. This behavior can be particularly important for screen reader users because it provides confirmation of the action performed and makes performing multiple commands more efficient. For instance, when a screen reader user presses the shortcut for the "Up" button, the user will be able to hear the new position of the option in the list since it still has the focus. Similarly, when the user presses the shortcut for deleting an option, the user can hear the next option in the list and immediately decide whether to press the delete shortcut again.
  • Move focus and activate when the target of the shortcut has a single function and the context of that function is the same as the target. This behavior is typical when a shortcut is assigned to a button that opens a menu or dialog, to a checkbox, or to a navigation link or button.
6.9.1.3 Choose Where to Add Shortcuts

Work to draft content for this section is tracked in issue 219.

The first goal when designing a keyboard interface is simple, efficient, and intuitive operation with only basic keyboard navigation support. If basic operation of a keyboard interface is inefficient, attempting to compensate for fundamental design issues, such as suboptimal layout or command structure, by implementing keyboard shortcuts will not likely reduce user frustration. The practical implication of this is that, in most well-designed user interfaces, the percentage of functionality that needs to be accessible via a keyboard shortcut in order to create optimal usability is not very high. In many simple user interfaces, keyboard shortcuts can be entirely superfluous. And, in user interfaces with too many keyboard shortcuts, the excess shortcuts create cognitive load that make the most useful ones more difficult to remember.

Consider the following when deciding where to assign keyboard shortcuts:

  1. To be written.

6.9.2 Assigning Keyboard Shortcuts

When choosing the keys to assign to a shortcut, there are many factors to consider.

  • Making the shortcut easy to learn and remember by using a mnemonic (e.g., Control + S for "Save") or following a logical or spacial pattern.
  • Localizing the interface, including for differences in which keys are available and how they behave and for language considerations that could impact mnemonics.
  • Avoiding and managing conflicts with key assignments used by an assistive technology, the browser, or the operating system.

Methods for designing a key shortcut scheme that supports learning and memory is beyond the scope of this guide. Unless the key shortcut scheme is extensive, it is likely sufficient to mimic concepts that are familiar from common desktop software, such as browsers. Similarly, while localization is important, describing how to address it is left to other resources that specialize in that topic.

The remainder of this section provides guidance balancing requirements and concerns related to key assignment conflicts. It is typically ideal if key assignments do not conflict with keys that are assigned to functions in the user's operating system, browser, or assistive technology. Conflicts can block efficient access to functions that are essential to the user, and a perfect storm of conflicts can trap a user. At the same time, there are some circumstances where intentional conflicts are useful. And, given the vast array of operating system, browser, and assistive technology keys, it is almost impossible to be certain conflicts do not exist. So it is also important to employ strategies that mitigate the impact of conflicts whether they are intentional or unknown.

Note

In the following sections, meta key refers to the Windows key on Windows-compatible keyboards and the Command key on MacOS-compatible keyboards.

6.9.2.1 Operating System Key Conflicts

It is essential to avoid conflicts with keys that perform system level functions, such as application and window management and display and sound control. In general, this can be achieved by refraining from the following types of assignments.

  1. Any modifier keys + any of Tab, Enter, Space, or Escape.
  2. Meta key + any other single key (there are exceptions, but they can be risky as these keys can change across versions of operating systems).
  3. Alt + a function key.

In addition, there are some important application level features that most applications, including browsers, generally support. These include:

  1. Zoom
  2. Copy/Paste
  3. ... to be continued ...
6.9.2.2 Assistive Technology Key Conflicts

Even though assistive technologies have collectively taken thousands of key assignments, avoiding conflicts is relatively easy. This is because assistive technologies have had to develop key assignment schemes that avoid conflicts with both operating systems and applications. They do this by hijacking specific keys as modifiers that uniquely define their key commands. For example, many assistive technologies use the Caps Lock key as a modifier.

Deflect assistive technology key conflicts by steering clear of the following types of assignments.

  1. Caps Lock + any other combination of keys.
  2. Insert + any combination of other keys.
  3. Scroll Lock + any combination of other keys.
  4. macOS only: Control+Option + any combination of other keys.
6.9.2.3 Browser Key Conflicts

While there is considerable similarity among browser keyboard schemes, the patterns within the schemes are less homogenous. Consequently, it is more difficult to avoid conflicts with browser key assignments. While the impact of conflicts is sometimes mitigated by the availability of two paths to nearly every function -- keyboard accessible menus and keyboard shortcuts, avoiding conflicts with shortcuts to heavily used functions is nonetheless important. Pay special attention to avoiding conflicts with shortcuts to:

  1. Address or location bar
  2. Notification bar
  3. Page refresh
  4. Bookmark and history functions
  5. Find functions
6.9.2.4 Intentional Key Conflicts

While avoiding key conflicts is usually desirable, there are circumstances where intentionally conflicting with a browser function is acceptable or even desirable. This can occur when the following combination of conditions arises:

  • A web application has a frequently used function that is similar to a browser function.
  • Users will often want to execute the web application function.
  • Users will rarely execute the browser function.
  • There is an efficient, alternative path to the browser function.

For example, consider a save function that is available when the focus is in an editor. Most browsers use ... to be continued ...

7. Grid and Table Properties

To fully present and describe a grid or table, in addition to parsing the headers, rows, and cells using the roles described in the grid pattern or table pattern, assistive technologies need to be able to determine:

Browsers automatically populate their accessibility tree with the number of rows and columns in a grid or table based on the rendered DOM. However, there are many situations where the DOM does not contain the whole grid or table, such as when the data set is too large to fully render. Additionally, some of this information, like skipped columns or rows and how data is sorted, cannot be derived from the DOM structure.

The below sections explain how to use the following properties that ARIA provides for grid and table accessibility.

Grid and Table Property Definitions
Property Definition
aria-colcount Defines the total number of columns in a table, grid, or treegrid.
aria-rowcount Defines the total number of rows in a table, grid, or treegrid.
aria-colindex
  • Defines a cell's position with respect to the total number of columns within a table, grid, or treegrid.
  • Note: Numbering starts with 1, not 0.
aria-rowindex
  • Defines a cell's position with respect to the total number of rows within a table, grid, or treegrid.
  • Note: Numbering starts with 1, not 0.
aria-colspan Defines the number of columns spanned by a cell or gridcell within a table, grid, or treegrid.
aria-rowspan Defines the number of rows spanned by a cell or gridcell within a table, grid, or treegrid.
aria-sort Indicates if items in a row or column are sorted in ascending or descending order.

7.1 Using aria-rowcount and aria-rowindex

When the number of rows represented by the DOM structure is not the total number of rows available for a table, grid, or treegrid, the aria-rowcount property is used to communicate the total number of rows available, and it is accompanied by the aria-rowindex property to identify the row indices of the rows that are present in the DOM.

The aria-rowcount is specified on the element with the table, grid, or treegrid role. Its value is an integer equal to the total number of rows available, including header rows. If the total number of rows is unknown, a value of -1 may be specified. Using a value of -1 indicates that more rows are available to include in the DOM without specifying the size of the available supply.

When aria-rowcount is used on a table, grid, or treegrid, a value for aria-rowindex property is specified on each of its descendant rows, including any header rows. The value of aria-rowindex is an integer that is:

  1. Greater than or equal to 1.
  2. Greater than the value of aria-rowindex on any previous rows.
  3. Set to the index of the first row in the span if cells span multiple rows.
  4. Less than or equal to the total number of rows.

WARNING! Missing or inconsistent values of aria-rowindex could have devastating effects on assistive technology behavior. For example, specifying an invalid value for aria-rowindex or setting it on some but not all rows in a table, could cause screen reader table reading functions to skip rows or simply stop functioning.

The following code demonstrates the use of aria-rowcount and aria-rowindex properties on a table containing a hypothetical class list.


  <!--
    aria-rowcount tells assistive technologies the actual size of the grid
    is 463 rows even though only 4 rows are present in the markup.
  -->
  <table role="grid" aria-rowcount="463">
    aria-label="Student roster for history 101"
    <thead>
      <tr aria-rowindex="1">
        <th>Last Name</th>
        <th>First Name</th>
        <th>E-mail</th>
        <th>Major</th>
        <th>Minor</th>
        <th>Standing</th>
      </tr>
    </thead>
    <tbody>
        <!--
          aria-rowindex tells assistive technologies that this
          row is row 51 in the grid of 463 rows.
        -->
      <tr aria-rowindex="51">
        <td>Henderson</td>
        <td>Alan</td>
        <td>ahederson56@myuniveristy.edu</td>
        <td>Business</td>
        <td>Spanish</td>
        <td>Junior</td>
      </tr>
        <!--
          aria-rowindex tells assistive technologies that this
          row is row 52 in the grid of 463 rows.
        -->
      <tr aria-rowindex="52">
        <td>Henderson</td>
        <td>Alice</td>
        <td>ahederson345@myuniveristy.edu</td>
        <td>Engineering</td>
        <td>none</td>
        <td>Sophomore</td>
      </tr>
        <!--
          aria-rowindex tells assistive technologies that this
          row is row 53 in the grid of 463 rows.
        -->
      <tr aria-rowindex="53">
        <td>Henderson</td>
        <td>Andrew</td>
        <td>ahederson75@myuniveristy.edu</td>
        <td>General Studies</td>
        <td>none</td>
        <td>Freshman</td>
      </tr>
    </tbody>
  </table>

7.2 Using aria-colcount and aria-colindex

When the number of columns represented by the DOM structure is not the total number of columns available for a table, grid, or treegrid, the aria-colcount property is used to communicate the total number of columns available, and it is accompanied by the aria-colindex property to identify the column indices of the columns that are present in the DOM.

The aria-colcount is specified on the element with the table, grid, or treegrid role. Its value is an integer equal to the total number of columns available. If the total number of columns is unknown, a value of -1 may be specified. Using a value of -1 indicates that more columns are available to include in the DOM without specifying the size of the available supply.

When aria-colcount is used on a table, grid, or treegrid, a value for aria-colindex property is either specified on each of its descendant rows or on every cell in each descendant row, depending on whether the columns are contiguous as described below. The value of aria-colindex is an integer that is:

  1. Greater than or equal to 1.
  2. When set on a cell, greater than the value set on any previous cell within the same row.
  3. Set to the index of the first column in the span if a cell spans multiple columns.
  4. Less than or equal to the total number of columns.

WARNING! Missing or inconsistent values of aria-colindex could have devastating effects on assistive technology behavior. For example, specifying an invalid value for aria-colindex or setting it on some but not all cells in a row, could cause screen reader table reading functions to skip cells or simply stop functioning.

7.2.1 Using aria-colindex When Column Indices Are Contiguous

When all the cells in a row have column index numbers that are consecutive integers, aria-colindex can be set on the row element with a value equal to the index number of the first column in the set. Browsers will then compute a column number for each cell in the row.

The following code shows a grid with 16 columns, of which columns 2 through 5 are displayed to the user. Because the set of columns is contiguous, aria-colindex can be placed on each row.

        
<div role="grid" aria-colcount="16">
  <div role="rowgroup">
    <div role="row" aria-colindex="2">
      <span role="columnheader">First Name</span>
      <span role="columnheader">Last Name</span>
      <span role="columnheader">Company</span>
      <span role="columnheader">Address</span>
    </div>
  </div>
  <div role="rowgroup">
    <div role="row" aria-colindex="2">
      <span role="gridcell">Fred</span>
      <span role="gridcell">Jackson</span>
      <span role="gridcell">Acme, Inc.</span>
      <span role="gridcell">123 Broad St.</span>
    </div>
    <div role="row" aria-colindex="2">
      <span role="gridcell">Sara</span>
      <span role="gridcell">James</span>
      <span role="gridcell">Acme, Inc.</span>
      <span role="gridcell">123 Broad St.</span>
    </div></div>
</div>

7.2.2 Using aria-colindex When Column Indices Are Not Contiguous

When the cells in a row have column index numbers that are not consecutive integers, aria-colindex needs to be set on each cell in the row. The following example shows a grid for an online grade book where the first two columns contain a student name and subsequent columns contain scores. In this example, the first two columns with the student name are shown, but the score columns have been scrolled to show columns 10 through 13. Columns 3 through 9 are not visible so are not in the DOM.


  <table role="grid" aria-rowcount="463" aria-colcount="13">
    aria-label="Student grades for history 101"
    <!--
      aria-rowcount and aria-colcount tell assistive technologies
      the actual size of the grid is 463 rows by 13 columns,
      which is not the number rows and columns found in the markup.
    -->
    <thead>
      <tr aria-rowindex="1">
        <!--
          aria-colindex tells assistive technologies that the
          following columns represent columns 1 and 2 of the total data set.
        -->
        <th aria-colindex="1">Last Name</th>
        <th aria-colindex="2">First Name</th>
        <!--
          aria-colindex tells users of assistive technologies that the
          following columns represent columns 10, 11, 12, and 13 of
          the overall data set of grades.
        -->
        <th aria-colindex="10">Homework 4</th>
        <th aria-colindex="11">Quiz 2</th>
        <th aria-colindex="12">Homework 5</th>
        <th aria-colindex="13">Homework 6</th>
      </tr>
    </thead>
    <tbody>
      <tr aria-rowindex="50">
        <!--
          every cell needs to define the aria-colindex attribute
        -->
        <td aria-colindex="1">Henderson</td>
        <td aria-colindex="2">Alan</td>
        <td aria-colindex="10">8</td>
        <td aria-colindex="11">25</td>
        <td aria-colindex="12">9</td>
        <td aria-colindex="13">9</td>
      </tr>
      <tr aria-rowindex="51">
        <td aria-colindex="1">Henderson</td>
        <td aria-colindex="2">Alice</td>
        <td aria-colindex="10">10</td>
        <td aria-colindex="11">27</td>
        <td aria-colindex="12">10</td>
        <td aria-colindex="13">8</td>
      </tr>
      <tr aria-rowindex="52">
        <td aria-colindex="1">Henderson</td>
        <td aria-colindex="2">Andrew</td>
        <td aria-colindex="10">9</td>
        <td aria-colindex="11">0</td>
        <td aria-colindex="12">29</td>
        <td aria-colindex="13">8</td>
      </tr>
    </tbody>
  </table>

7.3 Defining cell spans using aria-colspan and aria-rowspan

For tables, grids, and treegrids created using elements other than HTML table elements, row and column spans are defined with the aria-rowspan and aria-colspan properties.

The value of aria-colspan is an integer that is:

  1. Greater than or equal to 1.
  2. less than the value that would cause the cell to overlap the next cell in the same row.

The value of aria-rowspan is an integer that is:

  1. Greater than or equal to 0.
  2. 0 means the cell spans all the remaining rows in its row group.
  3. less than the value that would cause the cell to overlap the next cell in the same column.

The following example grid has a two row header. The first two columns have headers that span both rows of the header. The subsequent 6 columns are grouped into 3 pairs with headers in the first row that each span two columns.


  <div role="grid" aria-rowcount="463">
    aria-label="Student grades for history 101"
    <div role="rowgroup">
      <div role="row" aria-rowindex="1">
          <!--
            aria-rowspan and aria-colspan provide
            assistive technologies with the correct data cell header information
            when header cells span more than one row or column.
          -->
          <span role="columnheader" aria-rowspan="2">Last Name</span>
          <span role="columnheader" aria-rowspan="2">First Name</span>
          <span role="columnheader" aria-colspan="2">Test 1</span>
          <span role="columnheader" aria-colspan="2">Test 2</span>
          <span role="columnheader" aria-colspan="2">Final</span>
      </div>
      <div role="row" aria-rowindex="2">
          <span role="columnheader">Score</span>
          <span role="columnheader">Grade</span>
          <span role="columnheader">Score</span>
          <span role="columnheader">Grade</span>
          <span role="columnheader">Total</span>
          <span role="columnheader">Grade</span>
      </div>
    </div>
    <div role="rowgroup">
      <div role="row" aria-rowindex="50">
        <span role="cell">Henderson</span>
        <span role="cell">Alan</span>
        <span role="cell">89</span>
        <span role="cell">B+</span>
        <span role="cell">72</span>
        <span role="cell">C</span>
        <span role="cell">161</span>
        <span role="cell">B-</span>
      </div>
      <div role="row"  aria-rowindex="51">
        <span role="cell">Henderson</span>
        <span role="cell">Alice</span>
        <span role="cell">94</span>
        <span role="cell">A</span>
        <span role="cell">86</span>
        <span role="cell">B</span>
        <span role="cell">180</span>
        <span role="cell">A-</span>
      </div>
      <div role="row"  aria-rowindex="52">
        <span role="cell">Henderson</span>
        <span role="cell">Andrew</span>
        <span role="cell">82</span>
        <span role="cell">B-</span>
        <span role="cell">95</span>
        <span role="cell">A</span>
        <span role="cell">177</span>
        <span role="cell">B+</span>
      </div>
    </div>
  </div>

Note: When using HTML table elements, use the native semantics of the th and td elements to define row and column spans by using the rowspan and colspan attributes.

7.4 Indicating sort order with aria-sort

When rows or columns are sorted, the aria-sort property can be applied to a column or row header to indicate the sorting method. The following table describes allowed values for aria-sort.

Description of values for aria-sort
Value Description
ascending Data are sorted in ascending order.
descending Data are sorted in descending order.
other Data are sorted by an algorithm other than ascending or descending.
none Default (no sort applied).

It is important to note that ARIA does not provide a way to indicate levels of sort for data sets that have multiple sort keys. Thus, there is limited value to applying aria-sort with a value other than none to more than one column or row.

The following example grid uses aria-sort to indicate the rows are sorted from the highest "Quiz 2" score to the lowest "Quiz 2" score.


  <table role="grid" aria-rowcount="463" aria-colcount="13"
    aria-label="Student grades for history 101">
    <thead>
      <tr aria-colindex="10" aria-rowindex="1">
        <th>Homework 4</th>
        <!--
          aria-sort indicates the column with the heading
          "Quiz 2" has been used to sort the rows of the grid.
        -->
        <th aria-sort="descending">Quiz 2</th>
        <th>Homework 5</th>
        <th>Homework 6</th>
      </tr>
    </thead>
    <tbody>
      <tr aria-colindex="10" aria-rowindex="50">
        <td>8</td>
        <td>30</td>
        <td>9</td>
        <td>9</td>
      </tr>
      <tr aria-colindex="10"  aria-rowindex="51">
        <td>10</td>
        <td>29</td>
        <td>10</td>
        <td>8</td>
      </tr>
      <tr aria-colindex="10"  aria-rowindex="52">
        <td>9</td>
        <td>9</td>
        <td>27</td>
        <td>6</td>
      </tr>
      <tr aria-colindex="10"  aria-rowindex="53">
        <td>9</td>
        <td>10</td>
        <td>26</td>
        <td>8</td>
      </tr>
      <tr aria-colindex="10"  aria-rowindex="54">
        <td>9</td>
        <td>7</td>
        <td>24</td>
        <td>6</td>
      </tr>
    </tbody>
  </table>

8. Intentionally Hiding Semantics with the presentation Role

While ARIA is primarily used to express semantics, there are some situations where hiding an element’s semantics from assistive technologies is helpful. This is done with the presentation role, which declares that an element is being used only for presentation and therefore does not have any accessibility semantics. The ARIA 1.1 specification also includes role none, which serves as a synonym for presentation.

For example, consider a tabs widget built using an HTML ul element.

<ul role="tablist">
  <li role="presentation">
    <a role="tab" href="#">Tab 1</a>
  </li>
  <li role="presentation">
    <a role="tab" href="#">Tab 2</a>
  </li>
  <li role="presentation">
    <a role="tab" href="#">Tab 3</a>
  </li>
</ul>

Because the list is declared to be a tablist, the list items are not in a list context. It could confuse users if an assistive technology were to render those list items. Applying role presentation to the li elements tells browsers to leave those elements out of their accessibility tree. Assistive technologies will thus be unaware of the list item elements and see the tab elements as immediate children of the tablist.

Three common uses of role presentation are:

  1. Hiding a decorative image; it is equivalent to giving the image null alt text.
  2. Suppressing table semantics of tables used for layout in circumstances where the table semantics do not convey meaningful relationships.
  3. Eliminating semantics of intervening orphan elements in the structure of a composite widget, such as a tablist, menu, or tree as demonstrated in the example above.

8.1 Effects of Role presentation

When role="presentation" is specified on an element, if a condition that requires a browser to ignore the presentation role does not exist, it has the following three effects.

  1. The element’s implied ARIA role and any ARIA states and properties associated with that role are hidden from assistive technologies.
  2. Text contained by the element, i.e., inner text, as well as inner text of all its descendant elements remains visible to assistive technologies except, of course, when the text is explicitly hidden, e.g., styled with display: none or has aria-hidden="true".
  3. The roles, states, and properties of each descendant element remain visible to assistive technologies unless the descendant requires the context of the presentational element. For example:
    • If presentation is applied to a ul or ol element, each child li element inherits the presentation role because ARIA requires the listitem elements to have the parent list element. So, the li elements are not exposed to assistive technologies, but elements contained inside of those li elements, including nested lists, are visible to assistive technologies.
    • Similarly, if presentation is applied to a table element, the descendant caption, thead, tbody, tfoot, tr, th, and td elements inherit role presentation and are thus not exposed to assistive technologies. But, elements inside of the th and td elements, including nested tables, are exposed to assistive technologies.

8.2 Conditions That Cause Role presentation to be Ignored

Browsers ignore role="presentation", and it therefore has no effect, if either of the following are true about the element to which it is applied:

8.3 Example Demonstrating Effects of the presentation Role

This code:

<ul role="presentation">
  <li>Date of birth:</li>
  <li>January 1, 3456</li>
</ul>

when parsed by a browser, is equivalent to the following from the perspective of a screen reader or other assistive technology that relies on the browser's accessibility tree:

<div>Date of birth:</div>
  <div>January 1, 3456</div>

9. Roles That Automatically Hide Semantics by Making Their Descendants Presentational

There are some types of user interface components that, when represented in a platform accessibility API, can only contain text. For example, accessibility APIs do not have a way of representing semantic elements contained in a button. To deal with this limitation, WAI-ARIA requires browsers to automatically apply role presentation to all descendant elements of any element with a role that cannot support semantic children.

The roles that require all children to be presentational are:

For instance, consider the following tab element, which contains a heading.

<li role="tab"><h3>Title of My Tab</h3></li>

Because WAI-ARIA requires descendants of tab to be presentational, the following code is equivalent.

<li role="tab"><h3 role="presentation">Title of My Tab</h3></li>

And, from the perspective of anyone using a technology that relies on an accessibility API, such as a screen reader, the heading does not exist since the previous code is equivalent to the following.

<li role="tab">Title of My Tab</li>

See the section about role presentation for a detailed explanation of what it does.

10. Structural Roles

ARIA provides a set of roles that convey the accessibility semantics of structures on a page. These roles express the meaning that is conveyed by the layout and appearance of elements that organize and structure content, such as headings, lists, and tables.

some host languages, such as HTML, include elements that express the same semantics as an ARIA role. For instance, the HTML <p> element is mapped to accessibility APIs in exactly the same way as <div role="paragraph">. The ARIA and HTML specifications refer to this mapping of HTML elements to ARIA attributes as implied semantics, i.e., the implied ARIA role of the HTML <p> element is paragraph.

When developing HTML, it is important to use native HTML elements where ever possible. Do not use an ARIA role or property if it is possible to use an HTML element that has equivalent semantics. Circumstances where it is appropriate to use ARIA attributes instead of equivalent HTML are:

  1. When the HTML element cannot be styled in a way that meets visual design requirements.
  2. When testing reveals that browsers or assistive technologies provide better support for the ARIA equivalent.
  3. When remediating or retrofitting legacy content and altering the underlying DOM to use the HTML would be cost prohibitive.
  4. When building a web component to compose a custom element and the element being extended does not convey the appropriate or sufficient accessibility semantics.

The following table lists all structural roles defined in ARIA 1.2.

ARIA structural roles
ARIA Role HTML Equivalent
applicationNo equivalent element
articlearticle
blockquoteblockquote
captioncaption
celltd
codecode
columnheaderth
definitiondd
deletiondel
directoryNo equivalent element
documentNo equivalent element
emphasisem
feedNo equivalent element
figurefigure
genericdiv, span
groupNo equivalent element
heading with aria-level="N" where N is 1, 2, 3, 4, 5, or 6h1, h2, h3, h4, h5, h6
insertionins
imgimg
listul, ol
listitemli
mathNo equivalent element
noneNo equivalent element
noteNo equivalent element
presentationNo equivalent element
paragraphp
rowtr
rowgrouptbody, thead, tfoot
rowheaderth
separator (when not focusable)hr
strongstrong
subscriptsub
superscriptsup
tabletable
termdfn
timetime
toolbarNo equivalent element
tooltipNo equivalent element

A. Indexes

B. Change History

B.1 Changes in November 2019 publication of the 3rd working draft of version 1.2

APG 1.1 supported ARIA 1.1, and this version, APG 1.2, supports ARIA 1.2. The following changes have been made to APG 1.1 in order to make this draft of APG 1.2.

For more detail, see:

B.2 Changes in July 2019 Publication of APG 1.1 Release 4

Also see:

B.3 Changes in January 2019 Publication of APG 1.1 Release 3

Also see:

B.4 Changes in July 2018 Publication of APG 1.1 Release 2

Also see:

B.5 Changes in December 2017 Publication of APG 1.1 Release 1

Also see:

B.6 Changes in June 2017 APG 1.1 Working Draft

Also see:

C. Acknowledgements

C.1 Major Contributors to Version 1.1

While WAI-ARIA Authoring Practices 1.1 is the work of the entire Authoring Practices Task Force and also benefits from many people throughout the open source community who both contribute significant work and provide valuable feedback, special thanks goes to the following people who provided distinctly large portions of the content and code in version 1.1.

C.2 Participants active in the ARIA Authoring Practices Task Force

C.3 Other commenters and contributors to Version 1.1

C.4 Enabling funders

This publication has been funded in part with U.S. Federal funds from the Department of Education, National Institute on Disability, Independent Living, and Rehabilitation Research (NIDILRR), initially under contract number ED-OSE-10-C-0067 and currently under contract number HHSP23301500054C. The content of this publication does not necessarily reflect the views or policies of the U.S. Department of Education, nor does mention of trade names, commercial products, or organizations imply endorsement by the U.S. Government.

D. References

D.1 Informative references

[HTML]
HTML Standard. Anne van Kesteren; Domenic Denicola; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
[HTML-AAM]
HTML Accessibility API Mappings 1.0. Steve Faulkner; Alexander Surkov; Scott O'Hara; Bogdan Brinza; Jason Kiss; Cynthia Shelly. W3C. 17 August 2020. W3C Working Draft. URL: https://www.w3.org/TR/html-aam-1.0/
[HTML-ARIA]
ARIA in HTML. Steve Faulkner; Scott O'Hara; Patrick Lauke. W3C. 7 October 2020. W3C Working Draft. URL: https://www.w3.org/TR/html-aria/
[SVG2]
Scalable Vector Graphics (SVG) 2. Amelia Bellamy-Royds; Bogdan Brinza; Chris Lilley; Dirk Schulze; David Storey; Eric Willigers. W3C. 4 October 2018. W3C Candidate Recommendation. URL: https://www.w3.org/TR/SVG2/
[WAI-ARIA]
Accessible Rich Internet Applications (WAI-ARIA) 1.1. Joanmarie Diggs; Shane McCarron; Michael Cooper; Richard Schwerdtfeger; James Craig. W3C. 14 December 2017. W3C Recommendation. URL: https://www.w3.org/TR/wai-aria-1.1/