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

중요하며 대개 시간이 민감한 정보를 담은 라이브 리전의 한 종류입니다. 관련 역할: alertdialog, status.

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

alert는 assertive 라이브 리전이므로, 보조 기술 사용자를 위해 즉각적으로 알림을 발생시킵니다. 운영체제가 허용하는 경우, 사용자 에이전트는 WAI-ARIA alert가 생성될 때 접근성 API를 통해 시스템 alert 이벤트를 SHOULD 발생시켜야 합니다.

저자나 사용자 에이전트는 alert가 처리되도록 포커스를 설정하거나 관리할 필요가 없습니다. alert는 포커스를 받을 필요가 없으므로, 저자는 사용자가 alert를 반드시 닫게 요구해서는 SHOULD NOT 안 됩니다. 메시지로 포커스를 옮기고 싶다면, 저자는 alert 대신 alertdialog를 SHOULD 사용해야 합니다.

alert 역할을 가진 요소는 aria-live 값이 assertive, aria-atomic 값이 true로 암시적으로 설정됩니다.

알림 메시지를 포함하며, 초기 포커스가 다이얼로그 내 요소로 이동하는 다이얼로그 유형입니다. 관련 역할: alert, dialog.

alertdialog는 사용자에게 경고 메시지를 전달하는 데 사용됩니다. alertdialog 역할 은 알림 메시지와 나머지 다이얼로그를 함께 포함하는 노드에 적용됩니다. 콘텐츠 저자는 alertdialog가 표시되는 동안 키보드와 마우스 상호작용이 다이얼로그 내에서만 동작하도록 하여 alertdialog를 모달로 만드는 것이 SHOULD 권장됩니다. 자세한 내용은 aria-modal 참고.

alert와 달리 alertdialog는 사용자로부터 응답을 받을 수 있습니다. 예를 들어, 사용자가 생성된 알림을 인지했는지 확인하는 경우입니다. alertdialog가 표시될 때, 저자는 다이얼로그 내 활성 요소(폼 컨트롤 또는 확인 버튼 등)에 포커스를 설정하는 것이 SHOULD 권장됩니다. 사용자 에이전트는 알림이 생성될 때, 접근성 API를 통해 시스템 alert 이벤트를 SHOULD 발생시켜야 합니다(해당 접근성 API가 명시된 경우).

저자는 alertdialog에서 aria-describedby를 사용하여 다이얼로그 내의 알림 메시지 요소를 참조하는 것이 SHOULD 권장됩니다. 만약 그렇지 않으면, 보조 기술이 자체 복구 메커니즘을 사용하여 알림 메시지의 내용을 결정할 수 있습니다.

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

일부 사용자 에이전트 및 보조 기술은 브라우즈 모드를 제공하여, 위/아래 화살표 등 표준 입력 이벤트를 가로채어 읽기 커서를 제어하는 데 사용합니다. 이러한 브라우즈 모드 동작은 widget 역할이 없는 요소가 해당 키보드 및 제스처 이벤트를 받아서 인터랙티브 기능을 제공하는 것을 방해합니다.

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

예를 들어, 프레젠테이션 슬라이드 편집기는 방향키로 슬라이드 위의 텍스트박스 및 이미지 요소 위치를 변경할 수 있습니다. WAI-ARIA widget 역할 중 이러한 상호작용 모델에 해당하는 것이 없으므로, 저자는 슬라이드 컨테이너에 application 역할, aria-roledescription "슬라이드 편집기"와 aria-describedby로 안내문을 제공할 수 있습니다.

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

1. aria-labelledby 또는 aria-describedby를 이용해 콘텐츠를 포커스 가능한 요소와 연결합니다.
2. 콘텐츠를 role document 또는 article를 가진 포커스 가능한 요소에 배치합니다.
3. 포커스 관리에서 설명한 대로 소유 요소의 포커스를 관리하고, aria-activedescendant 값을 업데이트하여 포커스된 콘텐츠를 담고 있는 요소를 참조하도록 합니다.

문서, 페이지, 사이트의 독립적인 부분을 구성하는 작성물로 이루어진 페이지 섹션입니다.

article은 내비게이션 랜드마크는 아니지만, 중첩하여 토론을 구성할 수 있으므로 보조 기술은 article 중첩을 인식하여 사용자가 토론 흐름을 추적할 수 있도록 도울 수 있습니다. article은 포럼 글, 잡지나 신문 기사, 웹 로그 항목, 사용자 댓글, 또는 기타 독립적인 콘텐츠 항목이 될 수 있습니다. 독립적이라는 것은 syndication 등에서 내용이 단독으로 존재할 수 있다는 의미입니다. 단, 요소는 여전히 상위 요소와 연관되어 있습니다. 예를 들어, 상위 body 요소에 적용되는 연락처 정보는 article에도 적용됩니다. article을 중첩할 때, 자식 article은 상위 article의 콘텐츠와 관련된 내용을 나타냅니다. 예를 들어, 사용자 댓글을 허용하는 웹 로그 항목 사이트에서 댓글을 웹 로그 항목의 article 내부에 중첩된 article로 표현할 수 있습니다. 저자, 제목, 날짜 등 article에 연관된 정보는 중첩된 article에는 적용되지 않습니다.

사용자가 article 역할이 지정된 요소로 내비게이션할 때, 표준 키보드 이벤트를 가로채는 보조 기술은 키보드 이벤트를 웹 애플리케이션에 전달하는 대신 문서 탐색 모드로 SHOULD 전환해야 합니다. 보조 기술은 MAY 사용자가 중첩된 article 요소 계층을 탐색할 수 있는 기능을 제공할 수 있습니다.

article이 feed 컨텍스트에 있을 때, 저자는 aria-posinset와 aria-setsize 값을 MAY 지정할 수 있습니다.

landmark로, 주로 사이트 지향적 콘텐츠를 포함하며, 페이지별 콘텐츠가 아닙니다.

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

사용자 에이전트는 banner 역할이 부여된 요소를 내비게이션 랜드마크로 SHOULD 처리해야 합니다.

어떤 document 또는 application 내에서, 저자는 banner 역할을 가진 요소를 한 개만 SHOULD 표시해야 합니다.

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

클릭 또는 누름으로 사용자 동작을 트리거할 수 있는 입력 요소입니다. 관련 역할: link.

버튼은 주로 개별적인 동작에 사용됩니다. 버튼의 외형을 표준화하면 사용자가 위젯을 버튼으로 인식하기 쉬워지고, 툴바에서 더 콤팩트하게 표시할 수 있습니다.

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

눈에 보이는 콘텐츠로, figure, table, grid, treegrid의 이름을 지정하거나 설명할 수도 있습니다.

caption을 사용할 때, 저자는 SHOULD 다음을 보장해야 합니다:

• caption이 figure, table, grid, treegrid의 직접적인 자식이어야 합니다.
• caption이 table, grid, treegrid의 첫 번째 자식이어야 합니다.
• caption이 figure의 첫 번째 또는 마지막 자식이어야 합니다.

저자는 aria-labelledby를 부모 figure, table, grid, treegrid에 설정하여 caption 역할의 요소를 참조하는 것이 SHOULD 권장됩니다. 하지만 caption이 부모에 대한 이름과 설명을 모두 제공한다면, 저자는 MAY aria-labelledby를 caption 내부의 간결한 이름을 포함하는 요소를 참조하도록 설정하고, aria-describedby를 설명 콘텐츠를 포함하는 요소를 참조하도록 설정할 수 있습니다.

<div role="table" aria-labelledby="name" aria-describedby="desc">
   <div role="caption">
     <div id="name">콘테스트 참가자</div>
     <div id="desc">
       이 표는 지난 4주간 콘테스트에 접수된 참가자 총 인원(500명)을 보여줍니다.
     </div>
   </div>
   <!-- ... -->

표 형식 컨테이너의 셀입니다. 관련 역할: gridcell.

저자는 cell 역할의 요소가 row 역할의 요소 내부에 포함되거나 소유되어야 함을 MUST 보장해야 합니다.

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

checkbox의 aria-checked 속성은 입력이 체크됨(true), 체크 해제됨(false), 또는 요소 그룹이 체크됨과 체크 해제됨이 혼합된 상태(mixed)를 나타냅니다. 많은 체크박스는 mixed 값을 사용하지 않으므로 사실상 불리언 체크박스입니다.

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

code 역할의 주요 목적은 보조 기술에 해당 내용이 컴퓨터 코드임을 알리는 것이며, 특히 합성 음성에 대해 특별한 표현이 필요할 수 있음을 의미합니다. 구체적으로, 스크린 리더나 기타 텍스트-음성 변환 도구는 SHOULD 전체 구두점 발음을 선호하여 일반적인 기호(예: "-")가 제대로 발음되도록 해야 합니다.

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

columnheader는 테이블이나 그리드에서 열 헤더로 사용할 수 있습니다. 또한 파이 차트 등에서 데이터의 관계를 나타내는 용도로도 사용할 수 있습니다.

columnheader는 해당 열의 모든 셀과 관계를 형성합니다. 이는 HTML th 요소의 column scope와 구조적으로 동등합니다.

저자는 columnheader 역할의 요소가 row 역할의 요소 내부에 포함되거나 소유되어야 함을 MUST 보장해야 합니다.

aria-selected 상태를 columnheader에 적용할 때, 사용자 에이전트가 해당 열의 모든 셀에 aria-selected 상태를 자동으로 전파해서는 MUST NOT 안 됩니다. 저자는 필요에 따라 이런 선택 전파를 MAY 구현할 수 있습니다.

columnheader 역할은 인터랙티브 그리드와 비인터랙티브 테이블 모두에서 사용할 수 있지만, aria-readonly와 aria-required는 인터랙티브 요소에만 적용됩니다. 따라서 저자는 table에서 파생된 columnheader에는 aria-required나 aria-readonly를 SHOULD NOT 사용해야 하며, 사용자 에이전트도 columnheader가 grid 또는 treegrid 컨텍스트에 있지 않으면 해당 속성을 SHOULD NOT 보조 기술에 노출해야 합니다.

input이 다른 요소(예: listbox, grid)를 제어하며, 사용자가 input의 값을 설정하는 데 도움을 주도록 동적으로 팝업될 수 있습니다.

combobox는 명명된 입력 필드와 보조 팝업 요소를 통한 값 선택 지원 기능이 결합된 역할입니다. combobox 입력은 편집 및 입력이 가능한 단일 라인 텍스트 필드이거나, combobox의 현재 값만 표시하는 요소일 수도 있습니다. combobox가 텍스트 입력을 지원하고 aria-autocomplete에서 설명한 자동완성 동작을 제공한다면, 저자는 combobox 요소에 aria-autocomplete 값을 제공된 동작에 맞게 MUST 설정해야 합니다.

일반적으로 combobox의 초기 상태는 접힘(collapsed)입니다. 접힌 상태에서는 combobox 요소와 별도의 선택적 팝업 제어 button만 보입니다. combobox가 펼쳐짐(expanded) 상태일 때는 combobox 요소와 현재 값, 연결된 팝업 요소가 모두 표시됩니다. 저자는 combobox 요소가 펼쳐질 때 aria-expanded를 true로, 접힐 때 false로 MUST 설정해야 합니다.

저자는 combobox와 연관된 팝업 요소가 listbox, tree, grid, dialog 역할 중 하나를 MUST 가져야 하며, combobox 요소에 aria-controls 값을 팝업 요소를 참조하도록 MUST 설정해야 합니다.

combobox 역할 요소는 aria-haspopup 값이 listbox로 암시적으로 설정됩니다. 만약 팝업 요소의 역할이 listbox가 아니라면, 저자는 팝업 역할에 해당하는 aria-haspopup 값을 MUST 명시적으로 지정해야 합니다.

UI에 추가 아이콘이 있어 포인터와 터치 이벤트로 팝업 표시를 제어할 수 있다면, 저자는 해당 요소에 button 역할을 부여하고, 포커스 가능하지만 페이지 Tab 순서에는 포함되지 않도록 하며, combobox 요소의 자손이 아니어야 SHOULD 합니다. 또한 키보드 접근성을 위해 combobox 요소와 팝업 요소 내의 요소 간 포커스 이동을 위한 키보드 메커니즘을 SHOULD 제공해야 합니다. 예를 들어, 일반적인 규칙으로 아래 화살표는 입력에서 팝업 요소의 첫 포커스 가능한 자손으로 포커스를 옮깁니다. 팝업 요소가 aria-activedescendant를 지원한다면, 포커스 이동 대신 해당 키보드 메커니즘이 combobox 요소의 aria-activedescendant 값을 제어할 수 있습니다. 팝업의 자손 중 하나가 활성 상태일 때, 저자는 combobox의 aria-activedescendant 값을 그 자손을 참조하도록 MAY 설정할 수 있습니다(포커스는 combobox 요소에 유지).

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

• combobox 요소가 값을 제공하는 호스트 언어 요소(예: HTML input 요소)일 경우, combobox의 값은 해당 요소의 값입니다.
• 그 외의 경우, combobox 값은 자손 요소로 표현되며, button의 자손 콘텐츠에서 이름을 계산하는 방식과 동일하게 결정됩니다.

    <label for="tag_combo">태그</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">
   <li role="option">Zebra</li>
   <li role="option" id="selected_option">Zoom</li>
</ul>

combobox 구현의 기능과 동작은 다양하게 나타나므로, 저자를 위한 중요한 고려사항이 많습니다. combobox 디자인 패턴 구현에 대한 추가 정보는 WAI-ARIA 저작 관행을 참고하세요.

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

landmark로, DOM 계층에서 메인 콘텐츠와 유사한 수준에 있지만, 메인 콘텐츠와 분리되어도 의미가 유지되는 보조 콘텐츠를 포함합니다.

이 역할에 적합한 콘텐츠 유형은 다양합니다. 예를 들어 포털의 경우, 상영 시간, 현재 날씨, 관련 기사, 추천 주식 등이 포함될 수 있습니다. complementary 역할은 포함된 콘텐츠가 메인 콘텐츠와 관련 있음을 나타냅니다. 만약 보조 콘텐츠가 메인 콘텐츠와 완전히 분리될 수 있다면, 더 일반적인 역할을 사용할 수 있습니다.

사용자 에이전트는 complementary 역할이 부여된 요소를 내비게이션 랜드마크로 SHOULD 처리해야 합니다.

위젯으로, 탐색 가능한 자손 또는 소유 자식 요소를 포함할 수 있습니다.

저자는 컴포지트 위젯이 웹 페이지의 더 큰 내비게이션 시스템 내에서 하나의 내비게이션 정지점으로 존재하도록 SHOULD 해야 합니다. 컴포지트 위젯에 포커스가 있을 때, 저자는 자손 또는 소유된 자식 요소로 내비게이션할 수 있는 별도의 내비게이션 메커니즘을 SHOULD 제공해야 합니다.

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

이 영역에 포함되는 정보의 예로는 저작권 및 개인정보 보호정책 링크 등이 있습니다.

사용자 에이전트는 contentinfo 역할이 부여된 요소를 내비게이션 랜드마크로 SHOULD 처리해야 합니다.

어떤 document 또는 application 내에서, 저자는 contentinfo 역할을 가진 요소를 한 개만 SHOULD 표시해야 합니다.

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

저자는 정의되는 요소에 term 역할을 부여하고, aria-labelledby 속성으로 참조하거나, term 역할 요소를 definition 역할 요소의 자손으로 만들 것을 SHOULD 권장합니다.

삭제는 제거된 것으로 표시된 콘텐츠 또는 제거 제안 중인 콘텐츠를 포함합니다. 관련 역할: insertion.

삭제는 일반적으로 두 버전의 콘텐츠 간 차이를 표시하거나 여러 사람이 콘텐츠를 수정하는 상황에서 제거 제안 콘텐츠를 지정하는 데 사용됩니다.

다이얼로그는 웹 애플리케이션의 기본 창의 자손 창입니다. HTML 페이지에서는 기본 애플리케이션 창이 전체 웹 문서, 즉 body 요소입니다.

다이얼로그는 주로 사용자에게 정보를 입력하거나 응답하도록 요청할 때 사용됩니다. 워크플로우를 중단시키기 위해 설계된 다이얼로그는 보통 모달입니다. 관련 역할: alertdialog.

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

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

[ARIA 1.2에서 사용 중단됨] 그룹 멤버에 대한 참조 목록(예: 정적 목차)입니다.

directory는 링크 여부와 관계없이 정적 목차입니다. 리스트로 만든 목차(중첩 리스트 포함)도 여기에 해당합니다. 동적 목차는 대신 tree 역할을 사용할 수 있습니다.

보조 기술 사용자가 읽기 모드로 탐색하려는 콘텐츠를 포함하는 요소입니다.

사용자 에이전트의 포커스가 document 역할이 지정된 요소로 이동하면, 정적 콘텐츠를 읽기 모드로 탐색할 수 있는 보조 기술은 해당 읽기 모드로 MAY 전환하고, 위/아래 화살표 등 표준 입력 이벤트를 읽기 커서를 제어하는 데 가로챌 수 있습니다.

읽기 모드가 있는 보조 기술은 기본적으로 모든 요소(단, widget 또는 application 역할 요소 제외)에 대해 해당 모드를 사용합니다. 따라서 document 역할이 보조 기술 동작을 변경하는 데 유용한 상황은 document 역할 요소가 widget 또는 application의 포커스 가능한 자식 요소일 때뿐입니다. 예를 들어, application 요소에 일부 정적 리치 텍스트가 포함되어 있을 때, 저자는 해당 텍스트가 들어 있는 요소에 document 역할을 부여하고 tabindex를 0으로 설정할 수 있습니다. 스크린 리더 사용자가 Tab 키를 눌러 document 요소에 포커스를 맞추면, 해당 텍스트를 스크린 리더의 읽기 커서로 읽을 수 있습니다.

하나 이상의 강조된 문자입니다. 관련 역할: strong.

emphasis 역할의 목적은 콘텐츠를 강조하거나 스트레스를 주는 것입니다. 이는 콘텐츠의 의미에 영향을 주지 않는 서체 변화(예: 단순 스타일 변경)를 전달하기 위한 것이 아닙니다. 저자는 SHOULD emphasis 역할의 부재가 콘텐츠의 의미를 변경시킬 경우에만 이 역할을 사용해야 합니다.

emphasis 역할은 중요성을 전달하려는 것이 아니며, 그 목적에는 strong 역할이 더 적합합니다.

스크롤 가능한 list로, article들이 포함되며, 스크롤 시 article들이 리스트 양쪽 끝에서 추가되거나 제거될 수 있습니다.

feed는 보조 기술 사용자(예: 스크린 리더)가 문서 탐색 모드를 사용하여 무한 스크롤로 더 많은 콘텐츠를 읽으면서 읽기 커서로 풍부한 콘텐츠 스트림을 읽고 스크롤할 수 있도록 지원합니다. feed에서는 보조 기술이 사용자 에이전트 포커스를 이동시켜 사용자의 읽기 커서 움직임을 웹 애플리케이션에 신호로 제공하며, 애플리케이션은 사용자가 페이지를 탐색함에 따라 새 콘텐츠를 추가하거나 시각적으로 콘텐츠를 위치시킬 수 있습니다. feed는 저자가 보조 기술에 추가 및 제거 상황을 알려 보조 기술이 읽기 뷰를 신속하게 갱신하면서 읽기를 방해하거나 성능을 저하시키지 않도록 할 수 있게 합니다.

예를 들어, feed는 각 article에 텍스트, 링크, 이미지, 댓글, 공유 및 댓글 위젯을 포함하는 뉴스 스트림을 제공할 수 있습니다. 스크린 리더 사용자가 각 기사에서 읽기 및 상호작용 후 읽기 커서를 기사에서 기사로 이동하면 각 기사가 화면에 표시되고, 필요 시 새 기사들이 로드됩니다.

feed는 자식들이 article 역할을 갖는 컨테이너 요소입니다. feed의 양쪽 끝에서 article들이 추가/제거될 때, 저자는 변경 전에 feed 요소에 aria-busy를 true로, 변경 완료 후 false로 SHOULD 설정해야 합니다. 저자는 feed 중간에 article을 삽입하거나 제거하는 것을 SHOULD 피해야 합니다. 이러한 요구는 보조 기술이 사용자의 읽기 커서 이동과 동시에 발생하는 feed 콘텐츠 변경에 부드럽게 대응할 수 있도록 돕습니다.

저자는 feed 내의 각 article이 포커스 가능하도록 하고, 애플리케이션이 사용자 에이전트 포커스가 article 또는 자손 요소에 설정될 때 해당 article을 화면에 표시하도록 SHOULD 해야 합니다. 예를 들어 HTML에서는 각 article 요소에 tabindex를 -1 또는 0으로 설정해야 합니다.

보조 기술의 읽기 커서가 하나의 article에서 다른 article로 이동할 때, 보조 기술은 읽기 커서를 포함하는 article에 사용자 에이전트 포커스를 SHOULD 설정해야 합니다. 읽기 커서가 article 내부의 포커스 가능한 요소에 도달한 경우, 보조 기술은 대신 해당 요소에 포커스를 MAY 설정할 수 있습니다.

보조 기술의 읽기 커서로 다른 article로 스크롤할 수 있으려면 페이지에 다른 article이 존재해야 하므로, 저자는 SHOULD 사용자 에이전트 포커스가 로드된 article 집합의 양쪽 끝에 도달하기 전에 추가 article을 로드하도록 시도해야 합니다. 또는, 저자는 MAY 양쪽 끝에 button 등 추가 article 로드를 요청할 수 있는 요소가 포함된 article을 포함할 수 있습니다.

저자는 간단한 라벨뿐 아니라 aria-describedby를 feed 내 article 요소에 적용하여 스크린 리더가 사용자가 article 단위로 내비게이션할 때 어떤 요소를 라벨 뒤에 읽도록 권장할 수 있습니다. 스크린 리더는 MAY feed 콘텐츠를 빠르게 스캔할 수 있도록 라벨과 접근성 설명을 함께 읽어주며, 저자가 설명에서 생략한 반복적이거나 덜 중요한 요소(예: 내장 상호작용 위젯 등)는 사용자가 무시할 수 있게 합니다.

저자는 SHOULD feed 내 article들 간 포커스 이동을 위한 키보드 명령을 제공하여, article 내비게이션 기능을 제공하지 않는 보조 기술을 사용하는 사용자도 키보드로 feed를 탐색할 수 있도록 해야 합니다.

feed에 포함된 article의 총 개수가 고정된 경우, 저자는 MAY 해당 feed의 article 요소에 aria-setsize를 지정할 수 있습니다. 단, 총 개수가 매우 크거나 불확정적이거나 자주 변하는 경우, 저자는 MAY aria-setsize를 -1로 설정해 집합의 크기가 알 수 없음을 전달할 수 있습니다.

WAI-ARIA 저작 관행에서 feed 디자인 패턴 구현에 대한 추가 정보를 확인할 수 있습니다.

인지 가능한 section 콘텐츠로, 일반적으로 그래픽 문서, 이미지, 코드 조각, 예시 텍스트를 포함합니다. figure의 부분은 MAY 사용자가 탐색할 수 있습니다.

저자는 SHOULD 본문에서 figure로의 참조를 제공해야 하지만, figure는 참조하는 요소와 동일한 위치에 표시될 필요는 없습니다. 저자는 MAY 캡션 역할의 텍스트를 aria-describedby로 참조할 수 있습니다. 저자는 MAY aria-label로 라벨을 제공하거나, MAY 라벨 역할의 텍스트를 aria-labelledby로 참조할 수 있습니다.

보조 기술은 SHOULD 사용자가 figure로 빠르게 이동할 수 있도록 해야 합니다. 일반 사용자 에이전트도 MAY 사용자가 figure로 빠르게 이동할 수 있도록 할 수 있습니다.

landmark 영역으로, 아이템과 객체 집합을 포함하며 전체적으로 폼을 구성합니다. 관련 역할: search.

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

저자는 MUST form 역할의 각 요소에 폼의 목적을 설명하는 간략한 라벨을 제공해야 하며, 표시되는 라벨이 있으면 aria-labelledby로 참조하는 것이 SHOULD 권장됩니다. 저자는 라벨을 가능하면 heading 내에 포함하는 것이 SHOULD 권장되며, heading은 표준 호스트 언어 heading 요소이거나 heading 역할 요소일 수 있습니다.

저자가 스크립트를 사용해 사용자의 동작으로 onsubmit 이벤트가 발생하지 않는 경우(예: 값 변경 시 폼 제출) 폼을 제출한다면, 해당 동작에 대해 사용자가 미리 알 수 있도록 SHOULD 안내해야 합니다.

사용자 에이전트는 form 역할 요소를 내비게이션 랜드마크로 SHOULD 처리해야 합니다.

자체적으로 시맨틱 의미가 없는 이름 없는 컨테이너 요소입니다.

generic 역할은 호스트 언어의 일반 요소(예: HTML div 또는 span)의 암시적 역할로 사용되도록 설계되었으므로 주로 사용자 에이전트 구현자를 위한 것입니다. 저자는 이 역할을 콘텐츠에 SHOULD NOT 사용해야 합니다. 저자는 MAY presentation 또는 none을 사용해 암시적 접근성 시맨틱을 제거하거나, group과 같은 시맨틱 컨테이너 역할로 자손을 명명된 컨테이너로 시맨틱 그룹화할 수 있습니다.

presentation 역할 요소와 마찬가지로, generic 역할 요소는 자손에 대해 aria-live 속성과 같은 제한된 수의 접근성 상태와 속성을 제공할 수 있습니다. 하지만 presentation 역할 요소와 달리 generic 요소는 접근성 API에 노출되어, 보조 기술이 레이아웃, 경계 등 특정 속성을 수집할 수 있습니다.

집합적인 widget으로, 하나 이상의 행(row)과 하나 이상의 셀(cell)을 포함하며, 그리드의 일부 또는 모든 셀이 방향키 등 2차원 내비게이션 방법으로 포커스될 수 있습니다.

grid 역할은 특정 시각적(예: 표 형태) 표현을 의미하지 않습니다. 이는 요소들 간의 관계를 설명합니다. 체크박스 집합이나 내비게이션 링크 그룹처럼 단순한 경우부터, 복잡한 스프레드시트 애플리케이션까지 다양하게 사용할 수 있습니다.

grid의 셀 요소들은 gridcell 역할을 갖습니다. 저자는 MAY 셀을 행 또는 열 헤더로 지정하기 위해 rowheader 또는 columnheader 역할을 gridcell 역할 대신 사용할 수 있습니다. 저자는 MUST gridcell, columnheader, rowheader 역할 요소들이 row 역할 요소에 소유되어야 하며, 해당 row는 다시 rowgroup 또는 grid에 소유되어야 합니다.

키보드 접근성을 위해, 저자는 SHOULD 포커스 관리에 따라 grid의 자손 포커스를 조정해야 합니다. 사용자가 키보드로 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가 셀 내에 나타나게 할 수 있습니다.

grid 역할 요소에 aria-readonly가 설정되어 있으면, 사용자 에이전트는 MUST 그 값(읽기 전용 여부)을 grid가 소유하는 모든 gridcell 요소에 전파하고 접근성 API에 노출해야 합니다. 저자는 MAY 개별 gridcell 요소에 대해서 전파된 값을 덮어쓸 수 있습니다.

셀 콘텐츠 편집 기능이 있는 grid에서, 포커스 가능한 gridcell의 콘텐츠가 편집 불가일 경우, 저자는 해당 gridcell 요소에 aria-readonly를 true로 MAY 설정할 수 있습니다. 단, aria-readonly 값은 grid나 개별 셀에 지정하더라도 셀 내부 콘텐츠의 편집 가능 여부만 나타내며, grid 자체의 내비게이션이나 조작 기능 제공 여부와는 관련이 없습니다.

aria-readonly 값을 명시하지 않는다고 해서 grid나 gridcell에 편집 가능한 콘텐츠가 있다는 의미는 아닙니다. 예를 들어, grid가 날짜를 나타내는 link 요소 집합 등 편집 불가 요소 모음일 경우, aria-readonly 값을 굳이 지정할 필요가 없습니다.

저자는 MAY gridcell이 동작의 대상(선택 가능)임을 aria-selected 속성으로 표시할 수 있습니다. grid에서 여러 gridcell을 선택할 수 있다면, 저자는 aria-multiselectable를 true로 grid 역할 요소에 SHOULD 설정해야 합니다.

WAI-ARIA는 호스트 언어의 요소를 확장할 수 있으므로, grid는 네이티브 테이블의 요소 및 속성을 재사용할 수 있습니다. 예를 들어, 저자가 HTML table 요소에 grid 역할을 적용하면, 하위 HTML tr와 td 요소에 row와 gridcell 역할을 별도로 적용할 필요가 없습니다. 사용자 에이전트가 자동으로 적절한 변환을 수행합니다. 네이티브 테이블 요소를 재사용하며 gridcell 요소가 여러 행 또는 열에 걸쳐야 할 경우, 저자는 WAI-ARIA aria-rowspan나 aria-colspan 대신, 호스트 언어의 해당 속성을 SHOULD 사용해야 합니다.

WAI-ARIA 저작 관행에서 grid 디자인 패턴 구현에 대한 추가 정보를 확인할 수 있습니다.

grid 또는 treegrid 내의 cell입니다.

gridcell은 포커스 가능, 편집 가능, 선택 가능할 수 있습니다. gridcell은 aria-controls 등 기능적 관계를 위한 관계를 가질 수 있습니다.

저자가 gridcell에 행 헤더, 열 헤더 또는 둘 다를 부여하려고 하고, 관련 헤더가 DOM 구조에서 결정할 수 없다면, 저자는 SHOULD gridcell에 aria-describedby를 적용하여 rowheader 또는 columnheader 역할의 요소를 참조해야 합니다.

treegrid에서 저자는 MAY gridcell을 aria-expanded 속성으로 확장 가능하게 정의할 수 있습니다. aria-expanded 속성이 제공될 경우, 해당 셀 개별에만 적용됩니다. 이는 row 컨테이너의 대리(proxy)가 아니며, 행(row) 역시 확장 가능할 수 있습니다. 이 속성을 gridcell에 제공하는 주요 용도는 피벗 테이블 동작입니다.

저자는 MUST gridcell 역할의 요소가 row 역할 요소에 포함되거나 소유되어야 함을 보장해야 합니다.

페이지 요약이나 목차에 보조 기술에서 포함되지 않는 UI object 집합입니다.

region은 UI 객체 그룹을 페이지 요약/목차에 포함시키는 반면, group은 포함되지 않습니다.

저자는 SHOULD group을 widget 내 논리적 아이템 집합(예: 트리 위젯에서 계층 내 형제 집합) 구성을 위해 사용해야 합니다. 단, group이 listbox 컨텍스트에서 사용될 경우, 저자는 MUST 자식 요소를 option 요소로 제한해야 합니다. 즉, 저자와 보조 기술이 group을 다루는 방식은 제공되는 컨텍스트에 따라 결정됩니다.

저자는 MAY group 요소를 중첩할 수 있습니다. 웹 페이지 목차에 포함될 만큼 중요한 구역이라면, 저자는 SHOULD 그 역할을 region 또는 표준 랜드마크 역할로 지정해야 합니다.

페이지 섹션의 제목입니다.

heading 역할의 요소가 논리적인 개요 구조로 정리되도록, 저자는 MUST aria-level 속성을 사용하여 올바른 중첩 수준을 표시해야 합니다.

이미지를 구성하는 요소 모음을 담는 컨테이너입니다.

img는 캡션 및 설명 텍스트, 그리고 여러 이미지 파일을 포함할 수 있으며, 함께 보면 하나의 이미지처럼 보입니다. img는 문서 내의 단일 그래픽을 나타내며, 개별 드로잉 object 모음으로 구성되어 있든 아니든 상관없습니다. img 역할의 요소가 인지 가능하려면, 저자는 MUST aria-label 또는 aria-labelledby 속성으로 라벨을 제공해야 합니다.

사용자 입력을 허용하는 일반적인 widget 유형입니다.

삽입은 추가된 것으로 표시된 콘텐츠 또는 추가 제안 중인 콘텐츠를 포함합니다. 관련 역할: deletion.

삽입은 일반적으로 두 버전의 콘텐츠 간 차이를 표시하거나 여러 사람이 콘텐츠를 수정하는 상황에서 추가 제안 콘텐츠를 지정하는 데 사용됩니다.

특정 저자 지정 목적에 관련된 콘텐츠를 포함하는 인지 가능한 section으로, 충분히 중요한 경우 사용자가 해당 섹션으로 쉽게 이동하거나 페이지 요약에 포함되기를 원할 수 있습니다. 이러한 페이지 요약은 사용자 에이전트나 보조 기술에 의해 동적으로 생성될 수 있습니다.

저자는 랜드마크 역할의 서브클래스 역할을 지정하고, 필요에 따라 간략하고 설명적인 라벨을 제공함으로써 콘텐츠의 목적을 지정합니다.

랜드마크 역할의 서브클래스 역할을 가진 요소는 랜드마크 영역 또는 내비게이션 랜드마크 영역으로 불립니다. 보조 기술은 SHOULD 사용자가 랜드마크 영역으로 빠르게 이동할 수 있도록 해야 합니다. 일반 사용자 에이전트도 MAY 사용자가 랜드마크 영역으로 빠르게 이동할 수 있도록 할 수 있습니다.

내부 또는 외부 리소스를 인터랙티브하게 참조하는 것으로, 활성화 시 사용자 에이전트가 해당 리소스로 이동합니다. 관련 역할: button.