접근 가능한 리치 인터넷 애플리케이션 (WAI-ARIA) 1.3

중요하며 일반적으로 시간에 민감한 정보를 담는 라이브 리전의 한 종류입니다. 관련 역할: alertdialog, status를 참고하세요.

alert는 사용자에게 즉시 중요한 메시지를 전달할 때 사용됩니다. 경고음 등 오디오 경고가 있을 경우, alert는 청각 장애인 사용자를 위해 접근 가능한 대안을 제공합니다. alert role은 알림 메시지를 포함하는 요소에 적용합니다. alert는 status 역할의 특수한 형태로, 원자적 라이브 리전으로 처리됩니다.

alert는 단호(assertive)한 라이브 리전이며, 이는 보조기술 사용자에게 즉시 알림이 전달됨을 의미합니다. 운영체제에서 지원하는 경우 user agent는 WAI-ARIA alert가 생성될 때 접근성 API를 통해 시스템 alert event를 권장(SHOULD) 발생시켜야 합니다.

alert가 처리되기 위해 저자나 사용자 에이전트가 포커스를 설정하거나 관리할 필요는 없습니다. alert는 포커스를 받을 필요가 없으므로, 저자는 사용자가 alert를 닫아야 하는 것을 요구하지 않아야 합니다(SHOULD NOT). 메시지가 전달될 때 포커스를 이동시키고 싶다면, 저자는 alert 대신 alertdialog를 사용해야 합니다(SHOULD).

alert 역할을 가진 요소는 aria-live 값이 암묵적으로 assertive이고, aria-atomic 값이 암묵적으로 true입니다.

경고 메시지를 포함하며, 처음 포커스가 다이얼로그 내 요소로 가는 대화상자의 한 종류입니다. 관련 역할: alert, dialog.

alertdialog는 사용자에게 경고를 전달하는 역할입니다. alertdialog role은 경고 메시지와 나머지 다이얼로그 모두를 포함하는 노드에 적용합니다. 저자는 alertdialog가 표시되는 동안 키보드와 마우스 동작이 다이얼로그 내에서만 동작하도록 보장하여 대화상자를 모달로 만드는 것을 권장합니다(SHOULD). aria-modal 참고.

alert와는 달리, alertdialog는 사용자로부터 응답을 받을 수 있습니다. 예를 들어 사용자가 생성된 경고를 확인했다는 응답을 받을 때입니다. alert dialog가 표시될 때 저자는 입력 컨트롤이나 확인 버튼 등 alertdialog 내의 활성 요소에 포커스를 두는 것을 권장합니다(SHOULD). user agent는 접근성 API를 통해, 의도된 accessibility API가 명시된 경우에 시스템 alert event를 권장해서 발생시켜야 합니다(SHOULD).

저자는 alertdialog에서 경고 메시지 요소를 참조하기 위해 aria-describedby 사용을 권장합니다(SHOULD). 그렇지 않은 경우 보조 기술이 자체 복구 메커니즘으로 경고 메시지의 내용을 확인할 수 있습니다.

하나 이상의 포커스 가능한 요소를 포함하며, 키보드나 제스처 이벤트와 같이 사용자 입력이 필요하지만 widget 역할이 지원하는 표준 상호작용 패턴을 따르지 않는 structure입니다.

일부 user agent와 보조 기술은 기본 입력 이벤트(예를 들어 위아래 방향키 이벤트 등)를 가로채어 읽기 커서를 제어하는 브라우즈 모드를 제공합니다. 이 브라우즈 모드는 widget 역할이 없는 요소가 그러한 키보드·제스처 이벤트를 받아 상호작용 기능을 제공하는 것을 방해합니다.

WAI-ARIA widget 역할로 지원되지는 않지만, 독자적 상호작용 모델이 필요한 경우 저자는 해당 요소에 application 역할을 지정할 수 있습니다(MAY). 그리고 사용자가 application 역할의 요소로 이동할 때, 표준 입력 이벤트를 가로채는 보조 기술은 대부분 또는 모든 입력 이벤트를 웹 애플리케이션으로 직접 전달하도록 동작을 전환해야 합니다(SHOULD).

예시: 프레젠테이션 슬라이드 편집기는 방향키로 슬라이드 내 텍스트박스와 이미지 요소의 위치를 바꿉니다. 이와 같은 상호작용 모델에 해당하는 WAI-ARIA widget 역할은 없으므로, 저자는 슬라이드 컨테이너에 application 역할, aria-roledescription에 "Slide Editor", aria-describedby를 지정해 설명을 제공할 수 있습니다.

일부 보조 기술에서 application 요소에 포함된 포커스 가능한 요소만 접근되기 때문에, 저자는 반드시(MUST) 내부의 모든 장식용이 아닌 정적 텍스트나 이미지 콘텐츠도 접근 가능하도록 아래 방법 중 하나를 사용해야 합니다:

1. aria-labelledby 또는 aria-describedby로 콘텐츠를 포커스 가능한 요소와 연결합니다.
2. document 또는 article 역할을 가진 포커스 가능한 요소에 콘텐츠를 배치합니다.
3. 포커스 관리에 설명된 대로 접근성 하위 요소의 포커스를 직접 관리하며, aria-activedescendant 값을 포커스된 내용을 담는 요소로 업데이트합니다.

문서, 페이지 또는 사이트의 독립적인 일부를 구성하는 페이지의 섹션입니다.

article은 내비게이션 랜드마크가 아니지만, 중첩하여 토론의 구조를 만들 수 있으며, 보조 기술이 article의 중첩 구조를 사용하여 사용자가 토론의 맥락을 따라가는 데 도움을 줄 수 있습니다. article은 포럼 게시물, 잡지나 신문 기사, 블로그 글, 사용자 댓글 등 독립적인 어떤 콘텐츠라도 될 수 있습니다. 독립적이라는 의미는, article의 콘텐츠만으로도 예를 들어 syndication에서 단독으로 제공될 수 있기 때문입니다. 그러나 요소는 여전히 상위와 연관됩니다. 예를 들어, 상위 body 요소의 연락처 정보는 article에도 적용됩니다. article을 중첩할 경우, 자식 article 내용은 부모 article과 관련된 콘텐츠를 나타냅니다. 예를 들어, 댓글이 허용된 블로그 포스트는 댓글을 부모 article에 중첩된 article로 나타낼 수 있습니다. 저자, 제목, 날짜, 기타 article에 연결된 정보는 중첩된 article에는 적용되지 않습니다.

사용자가 article 역할이 할당된 요소로 이동할 때, 표준 키보드 이벤트를 가로채는 보조 기술은 보통 키보드 이벤트를 웹앱으로 넘기지 않고, 문서 탐색 모드로 동작을 전환해야 합니다(SHOULD). 일부 보조 기술은 사용자가 중첩된 article 구조를 탐색할 수 있게 도와주는 기능을 제공합니다.

article이 feed 맥락에 있다면, 저자는 aria-posinset 및 aria-setsize 값을 지정할 수 있습니다(MAY).

landmark 역할을 가지며, 페이지별 개별 정보가 아닌 사이트 중심 컨텐츠를 주로 포함합니다.

사이트 중심 컨텐츠에는 보통 사이트 로고나 스폰서의 아이덴티티, 사이트 전용 검색 도구 등이 포함됩니다. 배너는 페이지 상단에 위치하며 일반적으로 페이지 전체 너비를 차지합니다.

보조 기술은 사용자가 banner 역할을 가진 요소로 신속하게 이동할 수 있도록 권장합니다(SHOULD). user agents는 banner 역할을 가진 요소를 내비게이션 랜드마크로 처리하도록 권장합니다(SHOULD). user agents는 사용자가 banner 역할 요소로 신속 이동하는 기능을 제공할 수 있습니다(MAY).

저자는 한 페이지에 banner role을 가진 요소를 1개 이하로 지정하는 것이 권장됩니다(SHOULD).

다른 출처에서 인용한 콘텐츠 섹션입니다.

사용자가 클릭하거나 누를 때 동작이 발생하는 입력입니다. 관련 역할: link.

버튼은 주로 개별 동작을 위해 사용됩니다. 버튼의 시각적 표준화는 사용자가 위젯을 버튼으로 인식하기 쉽게 해주고, 툴바에서 더 콤팩트하게 표시할 수 있게 합니다.

버튼은 선택적으로 attribute aria-pressed를 지원합니다. aria-pressed 속성이 비어 있지 않으면 토글 버튼입니다. aria-pressed가 true이면 버튼이 "눌림" 상태이고, false이면 눌리지 않은 상태입니다. 속성이 존재하지 않으면 단순 명령 버튼입니다.

figure, grid, group, radiogroup, table, treegrid를 명명하거나 설명하는 눈에 보이는 콘텐츠입니다.

caption 사용 시 저자는 다음 사항을 지켜야 합니다(SHOULD):

• caption이 figure, grid, group, radiogroup, table, treegrid의 자손이어야 합니다.
• caption이 grid, group, radiogroup, table, treegrid의 첫 번째 비-generic 자손이어야 합니다.
• caption이 figure의 첫 번째 또는 마지막 비-generic 자손이어야 합니다.

caption이 포함 요소의 접근 가능한 이름 역할을 한다면 저자는 포함 요소에 aria-labelledby 속성을 명시해서 caption 역할 요소를 참조할 것을 권장합니다(SHOULD).

<div role="radiogroup" aria-labelledby="cap">
   <div role="caption" id="cap">
     과일을 선택하세요
   </div>
   <!-- ... -->

caption에 포함된 콘텐츠가 이름 및 설명 역할을 모두 한다면, 저자는 선택적으로(MAY) aria-labelledby로 caption 내에서 포함 요소의 "이름" 역할을 하는 요소를 참조하고, aria-describedby로 설명 콘텐츠 역할을 하는 caption 내 요소를 참조할 수 있습니다.

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">콘테스트 참가자</div>
     <div id="desc">
       이 표는 지난 4주간 콘테스트에서 총 500명의 참가자가 수용되었음을 보여줍니다.
     </div>
   </div>
   <!-- ... -->

caption이 장문의 설명이거나, 설명에 의미를 가진 시맨틱 요소가 포함된다면 저자는 선택적으로(MAY) aria-labelledby로 "이름" 역할의 요소를 참조하고, 설명 콘텐츠 역할 요소를 aria-details로 참조할 수 있습니다.

<div role="figure" aria-labelledby="name" aria-details="details">
  <!-- figure 컨텐츠 예: 복잡 데이터 시각화 SVG -->
   <div role="caption">
     <div id="name">20XX년 매출 정보</div>
     <div id="details">
       이 막대그래프는 5년간의 총 매출액을 나타냅니다.
       <a href="...">작년 매출 정보</a>를 볼 수 있고, <button aria-pressed="false">이전 연도</button> 정보를 이 그래픽에 오버레이 할 수도 있습니다.
     </div>
   </div>
   <!-- ... -->

caption이 이름 역할에 적합한 텍스트 없이 설명만 포함된다면, aria-label이나 aria-labelledby를 사용해 접근 가능한 이름을 제공하고, caption을 aria-details로만 참조해서 설명 콘텐츠로 사용할 수 있습니다(MAY).

<div role="figure" aria-label="매출 정보" aria-details="details">
  <!-- figure 컨텐츠 예: 복잡 데이터 시각화 SVG -->
   <div role="caption" id="details">
     이 막대그래프는 5년간의 총 매출액을 나타냅니다.
     <a href="...">작년 매출 정보</a>를 볼 수 있고,
     <button aria-pressed="false">이전 연도</button> 정보를 이 그래픽에 오버레이 할 수도 있습니다.
   </div>
   <!-- ... -->

표 형태 컨테이너 내의 셀입니다. 관련 역할: gridcell 참고.

저자는 반드시(MUST) element에 role cell을 지정할 경우 role이 row인 요소의 접근성 자식이어야 합니다.

세 가지 값을 가질 수 있는 체크 가능한 입력(인풋)입니다: true, false, mixed.

aria-checked attribute는 checkbox가 체크됨(true), 체크 해제됨(false), 혹은 일부만 체크된 상태(mixed)(여러 element가 혼합되어 있음)를 나타냅니다. 많은 체크박스는 mixed 값을 사용하지 않으므로 사실상 불린 체크박스입니다.

컴퓨터 코드 조각을 나타내는 섹션입니다.

code 역할의 주요 목적은 보조 기술에 해당 콘텐츠가 컴퓨터 코드임을 알려, 특히 음성 출력(합성음)과 관련해 특별한 표현이 요구될 수 있음을 알리는 것입니다. 즉, 화면 낭독기 등 텍스트를 음성으로 읽어주는 도구는 일반 기호(예: "-")도 모두 말하도록 구두점 명료도를 지원해야 합니다(SHOULD).

열의 헤더 정보를 담는 셀입니다.

columnheader는 표나 그리드에서 열 헤더로 쓸 수 있습니다. 파이 차트 등에서도 데이터의 관계를 나타내기 위해 사용할 수 있습니다.

columnheader는 해당 열의 모든 셀과의 관계를 만듭니다. 이는 HTML th element 중 열 범위(scope)가 지정된 structurally equivalent 역할입니다.

저자는 반드시(MUST) element에 role columnheader를 지정한 경우 row 역할의 요소의 접근성 자식이어야 합니다.

aria-selected 상태를 columnheader에 지정하더라도, 사용자 에이전트는 그와 같은 열의 모든 셀이 동일하게 선택 상태가 되도록 aria-selected 상태를 자동으로 전파해서는 안 됩니다(MUST NOT). 각 애플리케이션 목적에 따라 저자가 수동으로 전파할 수도 있습니다(MAY).

columnheader 역할은 상호작용 가능한 grid와 비상호작용 표(table) 모두 사용 가능하지만, aria-readonly와 aria-required의 사용은 상호작용 요소에만 적용됩니다. 따라서, table에 속한 columnheader에는 두 속성을 사용하지 않아야 하며(SHOULD NOT), 사용자 에이전트도 columnheader가 grid 계통이 아닌 경우, 두 속성을 보조 기술에 노출하지 않아야 합니다(SHOULD NOT).

input 역할을 가지며, listbox나 grid와 같이, 사용자가 input 값을 설정하도록 도와주는 보조 팝업 요소를 동적으로 제어합니다.

combobox는 이름이 지정된 입력 필드에 보조 팝업 요소를 통해 값 선택을 지원하는 기능을 결합합니다. combobox 입력은 편집과 입력이 가능한 단일라인 텍스트 필드이거나, combobox의 현재값만 보여주는 요소일 수도 있습니다. combobox가 텍스트 입력과 aria-autocomplete에서 설명한 오토컴플리트 동작을 지원한다면 저자는 반드시(MUST) combobox 요소에 aria-autocomplete를 적절한 동작값으로 설정해야 합니다.

보통 combobox의 최초 상태는 축소(collapsed)된 상태입니다. 축소된 상태에서는 combobox 요소와 별도의 팝업 제어 button(선택 사항)만이 보입니다. combobox가 현재 값과 관련 팝업 요소 모두가 보이면 확장(expanded) 상태입니다. 저자는 반드시(MUST) aria-expanded를 확장 시 true, 축소 시 false로 combobox 요소에 지정해야 합니다.

저자는 반드시(MUST) combobox에 연결된 팝업 요소가 listbox, tree, grid, 또는 dialog 역할일 것을 보장해야 합니다. 팝업이 보이면 저자는 반드시(MUST) aria-controls 값이 팝업 요소를 참조하도록 combobox에 설정해야 합니다.

combobox 역할 요소는 암묵적으로 aria-haspopup 값이 listbox입니다. 만약 combobox의 팝업 역할이 listbox 이외라면 저자는 반드시(MUST) 팝업 역할에 맞는 aria-haspopup 값을 지정해야 합니다.

만약 팝업의 가시성을 포인터/터치로 조작하는 추가 아이콘이 있다면, 저자는 해당 요소가 button 역할이며 포커스 가능하지만 페이지 Tab 시퀀스에는 포함되지 않고, combobox의 자식이 아니도록 권장합니다(SHOULD). 또한, 키보드 접근성을 위해 combobox 요소와 팝업 내 요소 간 포커스 이동을 위한 키보드 메커니즘 제공도 권장합니다(SHOULD). 예시로, 아래 화살표는 입력필드에서 팝업의 첫 포커스 가능 자식으로 이동하는 관례가 있습니다. 만약 팝업 요소가 aria-activedescendant를 지원하면, 실제 포커스 이동 대신 combobox의 aria-activedescendant 값을 변경해도 됩니다. 팝업 자식이 활성화 상태일 때, 저자는 선택적으로(MAY) combobox의 aria-activedescendant 값을 팝업 내 활성 요소 id로 지정할 수 있습니다(포커스는 combobox 유지).

사용자 에이전트는 반드시(MUST) combobox 역할 요소의 값을 보조 기술에 노출해야 합니다. combobox 값은 다음 중 하나로 표현됩니다:

• combobox가 예를 들어 HTML input 요소 등 값이 존재하는 호스트 언어 요소라면 그 값이 combobox의 값입니다.
• 그 외에는, combobox의 자식요소 후손 값을 통해 결정되며, button의 이름 산정법과 동일하게 정해집니다.

    <label id="tag_label" for="tag_combo">Tag</label>
  <input type="text" id="tag_combo"
      role="combobox" aria-autocomplete="list"
      aria-haspopup="listbox" aria-expanded="true"
      aria-controls="popup_listbox" aria-activedescendant="selected_option">
<ul role="listbox" id="popup_listbox" aria-labelledby="tag_label">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

combobox 구현의 특징과 동작은 매우 다양합니다. 이에 따라 다양한 중요한 작성 고려사항이 있으니, 상세 구현은 WAI-ARIA Authoring Practices를 참고하세요.

행동을 수행하지만 입력 데이터를 받지는 않는 위젯 형태입니다.

command는 온톨로지에서 사용되는 추상 역할입니다. 저자는 절대(MUST NOT) 콘텐츠에 command 역할을 사용해서는 안 됩니다.

comment는 다른 콘텐츠에 대한 반응을 담는 내용을 포함합니다.

comment는 작은 텍스트 영역부터 다른 코멘트, 전체 article까지 어떤 가시 콘텐츠에도 주석을 달 수 있습니다. 저자는 comment와 피평(주석대상) 콘텐츠 간의 관계를 다음과 같이 권장(SHOULD)합니다:

1. comment가 또 다른 comment의 답글(reply)인 경우:
   • 모든 상위 comment가 DOM에 있으면, reply comment를 답글 대상 comment의 시맨틱 자식(즉, DOM 자손요소 또는 aria-owns 활용)으로 작성하세요.
   • 또는, 상위 comment의 일부/전체가 DOM에 없을 경우(페이지네이션 등), 계층 레벨은 aria-level로, 그룹 내 위치 추가 정보는 aria-posinset와 aria-setsize로 지정할 수 있습니다(MAY).
2. 그 외, comment가 페이지 내의 다른 콘텐츠와 연관된 경우:
   • comment를 가진 요소를 aria-details로 참조하여 피평 콘텐츠에 지정하세요.
   • 여러 comment가 하나의 콘텐츠에 달렸으면 각각을 aria-details로 모두 참조하거나, comment 컨테이너를 aria-details로 지정하세요. 이때 해당 comment 컨테이너가 comment 요소 모음임을 명확히 하려면, group 또는 region 역할을 부여할 것을 권장합니다(SHOULD).

aria-level, aria-posinset, aria-setsize를 author가 comment 요소에 명시적으로 선언하지 않은 경우, 사용자 에이전트는 반드시(MUST) 빠진 값을 자동 계산하여 보조기술에 노출해야 합니다.

이 역할은 메인 콘텐츠와 형제이거나 자식인 경우, 메인 콘텐츠를 보완하는 landmark입니다. complementary 랜드마크의 내용은 연관된 메인 콘텐츠와 분리되어 있어도 의미를 가집니다.

이 role이 적합한 콘텐츠 유형에는 다양한 것이 있습니다. 예를 들어 포털사이트에서는 상영시간, 현재 날씨, 관련기사, 주목해야 할 주식 등이 될 수 있습니다. 만약 보완 콘텐츠가 메인 콘텐츠와 완전히 분리되어 있다면 더 일반적인 역할이 적합할 수 있습니다.

보조 기술은 사용자가 complementary 역할 요소로 빠르게 이동할 수 있도록 권장합니다(SHOULD). user agents는 complementary 역할 요소를 내비게이션 랜드마크로 처리하는 것이 권장됩니다(SHOULD). user agents는 사용자가 complementary 역할 요소로 신속 이동하는 기능을 제공할 수 있습니다(MAY).

내비게이션 가능한 accessibility descendants를 포함할 수 있는 위젯입니다.

저자는 복합 위젯이 웹 페이지 전체 내비게이션 시스템에서 하나의 네비게이션 스톱(탭정거점)으로만 동작하도록 권장합니다(SHOULD). 복합 위젯에 포커스가 들어오면, 저자는 사용자가 해당 복합 요소의 element와 접근성 자식을 별도 내비게이션 방식으로 이동할 수 있도록 권장합니다(SHOULD).

composite는 온톨로지에서 사용하는 추상 역할입니다. 저자는 절대(MUST NOT) 콘텐츠에 composite 역할을 사용해서는 안 됩니다.

상위 문서에 대한 정보를 포함하는 landmark입니다.

이 영역에 포함되는 정보 예시는 저작권 정보와 개인정보 처리방침 링크 등이 있습니다.

보조 기술은 사용자가 contentinfo 역할의 요소로 빠르게 이동할 수 있도록 권장합니다(SHOULD). user agents는 contentinfo 역할 요소를 내비게이션 랜드마크로 처리하는 것이 권장됩니다(SHOULD). user agents는 사용자가 contentinfo 역할 요소로 신속 이동하는 기능을 제공할 수 있습니다(MAY).

저자는 한 페이지에 contentinfo 역할의 element를 반드시 1개 이하로만 지정하는 것이 권장됩니다(SHOULD).

용어나 개념에 대한 정의입니다. 관련 역할: term.

저자는 반드시(MUST) 정의하려는 element를 명확히 하고 그 요소에 term 역할을 지정해야 합니다.

저자는 사용해서는 안 됩니다(SHOULD NOT) form 컨트롤과 같은 상호작용 요소에 definition 역할을 지정하면 보조기술 사용자가 해당 요소와 상호작용하지 못할 수 있으므로 지양해야 합니다.

deletion은 삭제된 콘텐츠, 삭제 제안 콘텐츠, 또는 해당 맥락에서 더 이상 적절하지 않은 콘텐츠를 나타냅니다. 관련 역할: insertion.

deletion은 주로 두 버전 간 콘텐츠 차이 표시, 또는 다수의 사용자가 콘텐츠를 편집하는 상황에서 삭제 제안 내용을 표시하는 데 사용됩니다.

다이얼로그는 웹 애플리케이션의 기본 창의 하위 창입니다. HTML 페이지의 경우, 기본 애플리케이션 창은 전체 웹 문서이며, 즉 body 요소입니다.

다이얼로그는 주로 사용자에게 정보를 입력하거나 응답하도록 요청할 때 사용됩니다. 작업 흐름을 중단하도록 설계된 다이얼로그는 보통 모달입니다. 관련 역할: alertdialog를 참고하세요.

저자는 반드시(MUST) 다이얼로그에 접근 가능한 이름을 제공해야 하며, aria-label 또는 aria-labelledby 속성으로 지정할 수 있습니다.

저자는 권장합니다(SHOULD) 모든 다이얼로그(모달, 비모달 모두)에 최소 하나 이상의 포커스 가능한 자손 요소를 갖도록 해야 합니다. 다이얼로그가 표시될 때는 모달 다이얼로그 내의 요소에 포커스를 주고, 모달 다이얼로그의 포커스 관리를 권장합니다(SHOULD).

[ARIA 1.2에서 폐지됨] 그룹의 구성원에 대한 참조 목록(예: 정적 목차)입니다.

directory는 연결된 것이든 연결되지 않은 것이든 정적 목차입니다. 이는 리스트로 구축된 목차(중첩 리스트 포함) 모두를 포함합니다. 동적 목차는 tree 역할을 사용할 수도 있습니다.

element 내에 포함되어 있는 콘텐츠로, 보조 기술 사용자가 읽기 모드로 탐색하고자 할 수 있습니다.

user agent 포커스가 document 역할이 지정된 요소로 이동할 때, 정적 콘텐츠 읽기 모드가 있는 보조 기술은 선택적으로(MAY) 읽기 모드로 전환하고, 위/아래 방향키 같은 표준 입력 이벤트를 읽기 커서 조작용으로 가로챌 수 있습니다.

읽기 모드가 있는 보조 기술은, widget 또는 application 역할이 아닌 모든 요소에 대해 기본적으로 읽기 모드를 사용합니다. 따라서 document 역할이 보조 기술 동작을 바꾸는 것이 유용한 상황은, document 역할 요소가 widget 또는 application의 포커스 가능한 자식인 경우뿐입니다. 예를 들어, application 요소에 정적 리치 텍스트가 포함된 경우, 그 텍스트가 들어있는 요소에 document 역할을 부여하고 tabindex를 0으로 하면, 스크린리더 사용자가 Tab 키로 document 요소에 포커스할 때 읽기 커서로 해당 내용을 탐색할 수 있습니다.

하나 이상의 강조(강세)된 문자입니다. 관련 역할: strong를 참고하세요.

emphasis 역할의 목적은 콘텐츠의 의미를 강조하거나 스트레스 주는 것입니다. 단순히 의미에 영향 없는 타이포그래피적 변화를 전달하려는 목적이 아닙니다. 저자는 권장합니다(SHOULD) emphasis 역할의 부재가 내용의 의미 변화를 야기할 때만 이 역할을 사용해야 합니다.

emphasis 역할은 중요성을 전달하는 용도가 아닙니다. 그러한 목적에는 strong 역할이 더 적합합니다.

스크롤이 가능한 list로, 스크롤 될 때 articles이 리스트 양 끝에 추가되거나 제거될 수 있습니다.

feed는 문서 탐색 모드를 지원하는 스크린리더와 같은 보조기술 사용자들이 탐색 커서를 사용하여, 무한히 스크롤될 수 있는 다양한 리치 콘텐츠 스트림을 읽고 스크롤할 수 있게 해 줍니다. feed에서 보조기술은 사용자의 읽기 커서 이동을 user agent 포커스 이동을 통해 웹앱에 전달하며, 앱은 사용자의 읽기에 맞게 새로운 콘텐츠를 추가하거나 시각적으로 콘텐츠 위치를 조정할 수 있습니다. 또한 feed는 콘텐츠의 추가/제거를 보조기기에 알릴 수 있게 하여 읽기 흐름을 방해하지 않고도 더 신뢰성 있게 보기를 갱신할 수 있도록 도와줍니다.

예시로, feed는 각 article에 텍스트, 링크, 이미지, 덧글, 공유 및 댓글 기능 위젯 등이 포함된 뉴스 스트림에 사용할 수 있습니다. 스크린리더 사용자가 각 기사에 포커스하면서 기사를 읽고 상호작용할 때, 각 기사가 뷰에 표시되고 필요할 경우 새로운 기사가 추가됩니다.

feed는 자식이 article 역할을 가지는 컨테이너 요소입니다. articles가 feed 양단에서 추가/제거될 경우, 저자는 변경 전 feed에 aria-busy를 true로, 변경 완료 후 false로 지정하는 것이 권장됩니다(SHOULD). feed 중간에 articles를 삽입/제거하는 것은 지양해야 합니다(SHOULD). 이 요구사항들은 보조기술이 읽기 커서 이동과 동시에 피드 변경에 부드럽게 반응할 수 있게 도와줍니다.

저자는 권장합니다(SHOULD) feed 내 각 article가 포커스 가능하도록 하고, user agent 포커스가 해당 article나 그 자손에 위치할 때 프로그램이 해당 article를 스크롤 뷰로 가져가는 기능을 제공해야 합니다. 예시로, HTML에서는 각 article에 tabindex를 -1 또는 0으로 설정해야 합니다.

보조기술의 읽기 커서가 한 article에서 다른 article로 이동하면, 보조기술은 article에 user agent 포커스를 이동하도록 권장합니다(SHOULD). 읽기 커서가 article 내 포커스 가능한 요소에 멈추면, 보조기술은 해당 요소에 포커스를 이동할 수 있습니다(MAY).

읽기 커서로 다른 article로 이동하려면, 페이지에 또 다른 article이 존재해야 하므로, 저자는 user agent 포커스가 로드된 article 집합의 양단에 도달하기 전 미리 추가 콘텐츠를 로드할 것을 권장합니다(SHOULD). 또는, 양단에 button 등 추가 로드 트리거 UI 요소가 포함된 article을 둘 수 있습니다(MAY).

요약 레이블 외에도, 저자는 선택적으로(MAY) aria-describedby를 feed 내 article에 적용해, 스크린리더가 각 article 탐색 시 어떤 요소를 레이블 뒤에 읽어야 할지 추천할 수 있습니다. 스크린리더는 선택적으로(MAY) 사용자가 article로 이동할 때 레이블과 접근 가능한 설명을 함께 읽어, 반복적이거나 덜 중요한 위젯 등 저자가 설명에 제외한 요소를 사용자가 건너뛸 수 있게 도와줄 수 있습니다.

저자는 권장합니다(SHOULD) feed 내 articles 간 포커스 이동을 위한 키보드 명령을 제공해야 하며, article 탐색 기능이 없는 보조기술 사용자도 키보드로 feed를 탐색할 수 있게 해야 합니다.

만약 feed의 전체 기사 수가 고정이라면, 저자는 선택적으로(MAY) 각 article에 aria-setsize를 명시할 수 있습니다. 전체 수가 매우 크거나 불특정, 빈번히 변하는 경우, 저자는 선택적으로(MAY) aria-setsize를 -1로 지정해 집합 크기를 알 수 없음을 전달할 수 있습니다.

피드 디자인 패턴 구현에 대한 더 자세한 내용은 WAI-ARIA Authoring Practices를 참고하세요.

일반적으로 section의 시각적으로 인지 가능한 컨텐츠로, 주로 그래픽 문서, 이미지, 미디어 플레이어, 코드 스니펫, 예시 텍스트 등을 포함합니다. figure의 부분은 사용자가 탐색할 수 있습니다(MAY).

저자는 권장합니다(SHOULD) 메인 텍스트에서 해당 figure로의 참조를 제공하고, figure가 반드시 참조 요소와 같은 위치에 표시될 필요는 없습니다. 저자는 선택적으로(MAY) figure에 caption을 설정할 수 있으며, 이는 이름, 설명 텍스트, 또는 둘 다를 포함할 수 있습니다. caption이 제공되고 figure의 내용을 묘사하는 역할이라면, 저자는 권장합니다(SHOULD) aria-details를 이용해 figure와 caption의 연관을 명시하세요.

저자는 선택적으로(MAY) aria-label 또는 aria-labelledby를 이용해 페이지 내 다른 텍스트를 참조하여 figure에 접근 가능한 이름을 제공할 수 있습니다.

figure와 caption을 연결하는 더 자세한 방법은 caption 역할 설명을 참고하세요.

보조기술은 사용자가 figure로 빠르게 이동할 수 있도록 권장합니다(SHOULD). User agents는 figure로 신속 이동을 제공할 수 있습니다(MAY).

여러 아이템 및 객체가 모여 하나의 폼을 구성하는 landmark 영역입니다. 관련 역할: search.

폼에는 호스트 언어 폼 컨트롤, 스크립트 기반 제어, 하이퍼링크 등이 혼합될 수 있습니다. 저자는 가능한 경우 반드시 네이티브 호스트 언어 시맨틱을 활용해 폼 컨트롤을 생성해야 합니다. 폼의 목적이 검색 조건 제출이라면, 저자는 일반 form 대신 search 역할을 권장합니다(SHOULD).

저자는 반드시(MUST) form 역할의 각 요소에 해당 폼의 목적을 설명하는 짧은 레이블을 제공해야 합니다. 눈에 보이는 레이블이 있는 경우 aria-labelledby로 이를 참조하는 것이 권장됩니다(SHOULD). 레이블은 가능하다면 heading(제목) 안에 포함하는 것이 권장됩니다(SHOULD). heading은 표준 호스트 언어 heading 요소나 heading 역할 요소가 될 수 있습니다(MAY).

저자가 사용자의 특정 행동(예: 값 변경)에 의해 표준 onsubmit 이벤트가 발생하지 않음에도 스크립트로 폼을 submit하도록 한다면, 사전 안내를 해주는 것이 권장됩니다(SHOULD).

보조기술은 사용자가 form 역할 요소로 신속하게 이동할 수 있게 권장합니다(SHOULD). User agents는 form 역할 및 접근 가능한 이름이 있는 요소를 내비게이션 랜드마크로 처리하는 것이 권장됩니다(SHOULD). User agents는 사용자가 form 역할 요소로 신속 이동할 수 있는 기능을 제공할 수 있습니다(MAY).

그 자체로 의미를 가지지 않는, 이름 없는 컨테이너 element입니다.

generic 역할은 주로 호스트 언어(예: HTML div, span)의 암묵적 역할로, 주로 user agent 구현자가 사용하기 위한 것입니다. 저자(콘텐츠 작성자)는 이 역할을 콘텐츠에 사용해서는 안 됩니다(SHOULD NOT). 저자는 암묵적 접근성 시맨틱을 제거할 때 presentation 또는 none을, 이름 있는 컨테이너로 의미적 그룹화를 원할 때는 group 역할을 사용할 수 있습니다(MAY).

presentation 역할과 유사하게, generic 역할 요소도 aria-live 속성과 같이, 자식에 일부 접근성 속성을 제공할 수 있습니다.

그러나 presentation 역할 요소와 달리, user agent는 허용된 접근성 속성이 명시된 경우 generic 요소를 접근성 API에 노출합니다. 허용 속성이 지정되지 않은 경우, user agent는 generic 요소를 무시할 수 있습니다(MAY).

방향키 등 양방향 탐색 수단을 사용하여 그리드 내 일부 또는 모든 셀에 포커스를 둘 수 있는 하나 이상의 행과 한 개 이상의 셀 모음을 포함하는 복합 widget입니다.

grid 역할은 특정 시각적(예: 표 형태) 표현을 의미하지 않습니다. 이는 관계를 설명합니다. 단순히 체크박스 모음이나 내비게이션 링크 묶음에서부터, 복잡한 스프레드시트 응용 프로그램 구성에 이르기까지 다양하게 활용할 수 있습니다.

grid의 셀 요소는 gridcell 역할을 가집니다. 저자는 선택적으로(MAY) 셀을 행 또는 열 헤더로 지정할 때는 rowheader 또는 columnheader role을 쓸 수 있습니다. 저자는 반드시(MUST) gridcell, columnheader, rowheader 역할 요소가 row 역할 요소의 접근성 자식이 되도록 하고, 이 row가 rowgroup 또는 grid 역할의 접근성 자식이 되도록 해야 합니다.

키보드 접근성을 위해, 저자는 포커스 관리 설명대로 grid의 후손 포커스를 관리하는 것이 권장됩니다(SHOULD). 사용자가 grid를 키보드로 탐색할 때 포커스는 다음과 같이 두는 것이 권장됩니다(SHOULD):

• gridcell에 포커스 받을 때 방향키를 소모하지 않는 인터랙티브 widget 하나(예: checkbox, button, link)만 있으면, 저자는 선택적으로(MAY) 그 안의 인터랙티브 요소에 포커스를 둘 수 있습니다. 이렇게 하면 내장 위젯을 직접 조작할 수 있습니다.
• 그 외에는 포커스를 받는 요소가 gridcell, rowheader, columnheader가 되도록 권장합니다(SHOULD).

저자는 권장합니다(SHOULD) 포커스가 가능한 셀에 다음 중 하나 이상이 포함되어 있다면 내용 내 탐색 또는 상호작용을 할 수 있도록 모드 변경 수단을 제공해야 합니다:

• 방향키로 조작이 필요한 위젯, 예: combobox나 radiogroup
• 여러 인터랙티브 요소
• 편집 가능한 콘텐츠

예시로, 스프레드시트 셀에 combobox나 편집 가능한 텍스트가 있다면 포커스 시 Enter 키로 셀 상호작용 또는 편집 모드를 활성화시키고, 이렇게 되면 방향키로 해당 combobox나 textbox를 조작할 수 있습니다. 다시 Enter, Tab, Escape 또는 다른 키를 누르면 그리드 탐색 모드로 돌아갈 수도 있습니다.

저자는 선택적으로(MAY) gridcell에 수식 결과를 표시할 수 있으며 이 값은 사용자가 편집할 수도 있습니다. 예를 들어 스프레드시트 앱에서 gridcell은 계산된 값을 표시하다가 사용자가 편집 모드를 활성화하면 textbox가 나타나 입력할 수 있습니다.

aria-readonly가 grid 역할 요소에 지정되면, user agents는 반드시 해당 grid의 gridcell 접근성 자식 전체에 해당 값을 전달하고, 접근성 API에 노출해야 합니다. 개별 gridcell에서는 이 값을 개별적으로 덮어쓸 수 있습니다(MAY).

셀 편집 기능이 있는 grid에서, 포커스 가능한 gridcell의 내용이 편집 불가라면 해당 셀에 aria-readonly를 true로 지정할 수 있습니다(MAY). 단, grid 또는 셀에 지정된 aria-readonly의 값은 셀 내용 편집 가능 여부만 나타내며, 그리드 자체의 탐색/조작 가능 여부는 의미하지 않습니다.

aria-readonly가 지정되지 않았다고 해서 grid나 gridcell 내용이 편집 가능함을 의미하지는 않습니다. 예를 들어, grid가 수정 불가한 요소 모음(예: 날짜를 나타내는 link 등)일 경우 저자는 aria-readonly 값을 명시할 필요가 없습니다.

저자는 선택적으로(MAY) 포커스 가능한 gridcell이 어떤 작업의 대상(선택 가능)임을 aria-selected 속성으로 나타낼 수 있습니다. 만약 grid가 여러 gridcell 동시 선택을 지원한다면, 저자는 grid 역할 요소에 aria-multiselectable을 true로 두는 것이 권장됩니다(SHOULD).

WAI-ARIA는 호스트 언어 요소를 확장할 수 있으므로 grid는 HTML table 같이 네이티브 테이블 요소와 속성을 재사용할 수 있습니다. 저자가 grid 역할을 HTML table에 적용할 때, 후손 tr, td에는 추가로 row 및 gridcell 역할을 적용할 필요가 없습니다. user agent가 자동으로 적절히 변환합니다. 네이티브 테이블을 재사용하면서 특정 gridcell이 여러 행 또는 열에 걸쳐야 할 경우, 저자는 WAI-ARIA의 aria-rowspan 또는 aria-colspan 속성 대신 호스트 언어 속성을 활용하는 것이 권장됩니다(SHOULD).

그리드 디자인 패턴 구현에 대한 자세한 내용은 WAI-ARIA Authoring Practices를 참고하세요.

grid 또는 treegrid 내 cell입니다.

gridcell은 포커스 가능, 편집 가능, 선택 가능할 수 있습니다. 또한 관계(예: aria-controls)를 사용해 기능적 관계를 표현할 수 있습니다.

gridcell에 행/열 헤더나 둘 다 지정하려고 할 때, 해당 헤더를 DOM 구조로 파악할 수 없다면, 저자는 권장합니다(SHOULD) gridcell에 aria-describedby를 지정해 관련 role rowheader 또는 columnheader 요소를 참조해야 합니다.

treegrid에서는, 저자는 선택적으로(MAY) aria-expanded 속성을 사용해 gridcell을 확장 가능 셀로 정의할 수 있습니다. aria-expanded 속성이 제공된 경우 해당 셀에만 적용되며, 행 컨테이너 전체를 대변하지 않습니다. 이 속성은 피벗 테이블 등의 동작에 주로 사용됩니다.

저자는 반드시(MUST) element에 role gridcell을 부여할 때, 해당 요소가 반드시 row 역할 요소의 접근성 자식이 되도록 해야 합니다.

보조 기술에 의해 페이지 요약 또는 목차에 포함되지 않아야 할 UI objects의 집합입니다.

region은, 페이지 요약이나 목차에 포함될 UI 객체 집합이라는 점에서 대조됩니다.

저자는 권장합니다(SHOULD) group을 widget 내 논리적 아이템 묶음(예: 트리 위젯 하위 요소들을 동일 계층의 형제 집합으로 묶음)으로 사용해야 합니다. 하지만 group이 listbox 맥락에서 사용될 때는 저자가 반드시(MUST) 자식 요소를 option 요소로 제한해야 합니다. 즉 group의 처리 방법은 제공 맥락에 따라 저자와 보조 기술이 다르게 해석해야 합니다.

저자는 선택적으로(MAY) group 요소를 중첩할 수 있습니다. 만약 특정 구간이 웹 페이지 목차에 포함될 만큼 중요하다면 저자는 role을 region 또는 표준 랜드마크 역할로 지정하는 것이 권장됩니다(SHOULD).

페이지 구간의 제목(heading)입니다.

heading 역할 요소가 논리적 계층 구조로 구성되도록, 저자는 반드시(MUST) aria-level 속성으로 적절한 계층을 나타내야 합니다.

이미지를 구성하는 요소 모음의 컨테이너입니다. 동의어: img를 참고하세요.

이미지를 구성하는 요소 모음의 컨테이너입니다. 동의어: image를 참고하세요.

img는 캡션, 설명 텍스트, 여러 이미지 파일을 포함할 수 있으며, 이들이 함께 나타날 때 하나의 이미지로 인식됩니다. img는 그 구성이 도형 object의 모음이든 아니든 문서 내의 하나의 그래픽을 나타냅니다. img 역할의 요소가 지각 가능하려면, 저자는 반드시(MUST) 그 요소에 접근 가능한 이름을 제공해야 합니다. 이는 aria-label 또는 aria-labelledby 속성으로 지정할 수 있습니다.