이 섹션은 WAI-ARIA 역할(role), 상태(state), 속성(property)을 적용하고 키보드 지원을 구현하여 일반적인 리치 인터넷 어플리케이션 패턴과 위젯을 접근 가능하게 만드는 방법을 보여줍니다.
콤보박스는 사용자가 콤보박스에 대한 값을 가능한 값들의 모음에서 선택할 수 있도록 한 입력 위젯 및 연관 된 팝업입니다.
일부 구현에서는 팝업이 허용 된 값을 나타내는 반면 일부 다른 구현에서는 팝업이 추천 값을 나타내기도 하며, 사용자는 제안 된 것 중 하나를 선택하거나 값을 타이핑 할 수 있습니다.
팝업은 목록상자나
그리드,
트리, 혹은
대화상자일 수 있습니다.
많은 구현들은 제 3의 선택적인 엘리먼트 -- 팝업의 사용 가능성을 나타내는 콤보박스에 인접한 그래픽 열기
버튼도 포함합니다.
열기
버튼을 활성화면 제안이 사용 가능한 경우 팝업을 노출합니다.
콤보박스 패턴은 몇 가지 선택적인 동작을 제공합니다.
가장 구체화 된 형태 중 하나는 텍스트 입력입니다.
일부 콤보박스는 사용자가 콤보박스에 텍스트를 입력하고 수정할 수 있도록 하고 다른 일부는 아닙니다.
콤보박스가 텍스트 입력을 지원하지 않는다면, 사용자가 값을 선택할 수 있는 유일한 방법이 팝업에 있는 값을 선택하는 것임을 의미하는, 선택 전용으로 간주됩니다.
예를 들어, 일부 브라우저에서, size="1"인 HTML select 엘리먼트는 보조 기술에 콤보박스로 표현됩니다.
그렇지 않고, 콤보박스가 텍스트 입력을 지원하는 경우, 편집 가능한 것으로 간주됩니다.
편집 가능한 콤보박스는 사용자가 임의의 값을 입력하도록 허용하거나, 타이핑 입력이 팝업에 나타난 제안을 필터링 하도록 제공되는 경우 허용 된 값의 별개 집합으로 값을 제한 할 수 있습니다.
팝업은 기본적으로 숨겨집니다, 즉, 기본 상태는 접혀있습니다. 확장-- 팝업 표시 -- 을 작동시키는 조건은 각 구현에 따라 다릅니다. 확장을 작동시키는 일부 가능한 조건은 다음과 같습니다:
- Down Arrow 키가 눌리거나
열기
버튼이 활성화 된 경우 표시 됩니다. 선택적으로, 콤보박스가 편집 가능하고 허용 된 값과 일치하지 않는 문자열을 포함한다면 확장이 일어나지 않습니다.
- 콤보박스가 편집 가능하고 비어있다 하더라도 콤보박스가 초점을 얻을 경우 표시 됩니다.
- 콤보박스가 편집 가능하다면, 콤보박스에 특정 수의 문자가 입력 되고 그 문자가 제안 값 중 하나의 일부와 일치하는 경우에만 팝업이 표시됩니다.
콤보박스 위젯은 다음 두 가지 시나리오 중 하나에서 사용자 입력을 획득하는데 유용합니다:
-
값은 미리 정의 된 허용 된 값 세트 중 하나여야(must) 합니다. 예를 들어, 위치 필드는 유효한 위치 이름을 포함해야 합니다.
목록상자와 메뉴 버튼 패턴이 이 시나리오에 유용하다는 것을 참고하세요; 콤보박스와 대체 패턴의 차이점은 아래에 기술 되어 있습니다.
-
임의의 값이 허용되지만, 사용자에게 가능한 값을 제안하는 것이 유리합니다.
예를 들어, 검색 필드는 사용자 시간을 절약하기 위해 유사하거나 이전의 검색을 제안할 수 있습니다.
팝업으로 표시되는 가능한 값의 특성과 그것들이 표시되는 방식을 자동완성 동작이라고 부릅니다.
콤보박스는 다음 4가지 자동완성 형식 중 하나를 가질 수 있습니다:
-
자동완성 없음: 콤보박스가 편집 가능하고, 팝업이 작동 되었 때, 콤보박스에 입력된 문자와 관계 없이 제안 값은 동일한 값을 포함합니다.
예를 들어, 팝업은 최근 입력되었던 값들을 제안하고, 제안 항목은 사용자 타이핑에 따라 변경되지 않습니다.
-
수동 선택 목록 자동완성: 팝업이 작동 되었을 때, 제안 값이 나타납니다. 콤보박스가 편집 가능한 경우, 제안 값은 콤보박스에 입력 된 문자와 완전히 또는 논리적으로 일치합니다.
사용자가 타이핑 한 문자열은 사용자가 팝업의 값을 선택하지 않는 한 콤보박스의 값이 됩니다.
-
자동 선택 목록 자동완성: 콤보박스가 편집 가능하고, 팝업이 작동 되었을 때, 콤보박스에 타이핑 된 문자와 정확히 또는 논리적으로 일치하는 값이 나타나고,
첫 번째 제안 항목이 자동으로 선택된 것으로 강조 표시 됩니다.
사용자가 다른 제안 항목을 선택하거나 콤보박스의 문자열을 변경하지 않는 한 콤보박스가 초점을 잃을 때 자동으로 선택 된 제안 항목이 콤보박스의 값이 됩니다.
-
인라인 자동완성 목록: 자동 선택 목록과 동일하며 한 가지 추가 기능이 있습니다.
선택 된 제안 항목인 완성 문자열의 사용자가 타이핑 하지 않은 부분은 콤보박스의 입력 커서 뒤에 인라인으로 표시됩니다.
인라인 완성 문자열은 시각적으로 강조 표시되고 선택 된 상태를 가집니다.
콤보박스가 편집 가능하고 자동완성 목록 형식이 있는 경우, 사용자가 타이핑 할 때 팝업이 나타났다 사라질 수 있습니다.
예를 들어, 사용자가 다섯 개의 제안이 표시되도록 하는 두 개 문자를 입력하고 일치하는 제안을 가지지 않는 문자열을 형성하는 세 번째 문자를 타이핑 한다면,
팝업이 닫히고 인라인 완성 문자열이 있다면 사라집니다.
시각적으로 간결하고 사용자가 개별 선택 항목들로부터 단일 항목을 선택할 수 있도록 하는 다른 2가지 위젯은 목록상자와 메뉴 버튼입니다.
콤보박스를 목록상자와 메뉴 버튼으로부터 구별하는 한 가지 기능은 사용자의 선택이 편집 가능한 필드에 값으로 표현될 수 있다는 것이고, 이는 사용자가 클립보드에 복사할 값의 일부 또는 전체를 선택할 수 있게 한다는 것입니다.
콤보박스와 메뉴 버튼은 사용자가 이전에 선택한 항목을 잃지 않고 허용된 선택 항목을 탐색 할 수 있도록 구현될 수 있습니다.
즉, 사용자가 콤보박스 팝업이나 메뉴의 사용 가능한 선택 항목을 탐색한 뒤 escape를 누를 수 있고, 이는 이전 입력 변경 없이 팝업이나 메뉴를 닫습니다.
대조적으로, 단일 선택 목록상자의 옵션 항목을 탐색하는 것은 즉시 그 값을 변경하고, escape는 취소 메커니즘을 제공하지 않습니다.
콤보박스와 목록상자는 aria-required="true"로 필수 항목으로 표시 될 수 있고, 다른 값과 구별하는 접근 가능한 이름을 가집니다.
따라서, 보조 기술 사용자가 기본 상태의 콤보박스나 목록상자에 초점을 주면, 위젯에 대한 이름과 값을 모두 인식할 수 있습니다.
하지만, 메뉴 버튼은 필수 표기가 될 수 없고, 접근 가능한 이름은 있지만 값은 가지지 못하므로 접힌 상태에서 사용자의 선택을 전달하는데 적합하지 않습니다.
- Tab: 콤보박스가 페이지 Tab 시퀀스에 있습니다.
- 주의: 팝업 표시 아이콘이나 버튼(이 있다면), 팝업, 팝업 하위 항목들은 페이지 Tab 시퀀스에서 제외됩니다.
초점이 콤보박스에 있는 경우:
- Down Arrow: 팝업이 사용 가능한 경우, 팝업 내부로 초점을 이동시킵니다:
- Down Arrow가 눌리기 전에, 자동완성 동작이 자동으로 제안을 선택한 경우, 초점이 자동으로 선택된 제안의 다음 제안에 지정됩니다.
- 그렇지 않으면, 팝업 내 첫 번째 초점을 얻을 수 있는 (focusable) 엘리먼트에 초점이 지정됩니다.
- Up Arrow (선택사항): 팝업이 사용 가능한 경우, 팝업 내 마지막 초점을 얻을 수 있는 (focusable) 엘리먼트에 초점이 지정됩니다.
- Escape: 팝업이 노출되어 있는 경우 팝업을 닫습니다. 선택적으로, Escape가 눌리기 전에 팝업이 숨겨져 있는 경우, 콤보박스를 지웁니다(clear).
-
Enter: 콤보박스가 편집 가능하고 팝업에서 자동 선택이 선택 된 경우, 콤보박스의 허용된 값의 맨 뒤에 입력 커서를 위치시키거나 값에 기본 작업을 수행하여 제안을 수락합니다.
예를 들어, 메시징 응용프로그램에서, 기본 작업은 허용된 값을 메시지 수신인 목록에 추가한 후 사용자가 다른 수신인을 추가할 수 있도록 콤보박스를 지우는 것입니다.
- 출력 가능한 문자:
- 콤보박스가 편집 가능한 경우, 콤보박스에 문자를 입력합니다. 일부 구현에서는 특정 문자를 유효하지 않은 것으로 간주하여 입력할 수 없음에 주의하세요.
- 콤보박스가 편집 가능하지 않은 경우, 선택적으로 초점을 입력 문자로 시작하는 값으로 이동시킵니다.
- 콤보박스가 편집 가능한 경우, 이는 기기 플랫폼에 적절한 표준 단일 라인 텍스트 편집 키를 지원합니다. (아래 참고).
- Alt + Down Arrow (선택사항): 팝업이 사용 가능하지만 노출되지 않았다면, 초점 이동 없이 팝업을 노출시킵니다.
- Alt + Up Arrow (선택사항): 팝업이 노출되어 있다면:
- 팝업이 초점을 포함하고 있다면, 초점을 콤보박스에 되돌려 줍니다.
- 팝업을 닫습니다.
Note
기기 플랫폼에 적절한 표준 단일 라인 텍스트 편집 키:
- 입력, 커서 이동, 선택, 텍스트 조작을 위한 키를 포함합니다.
- 편집 기능을 위한 표준 키 할당은 기기 운영 체제에 따라 다릅니다.
- 텍스트 입력 기능을 제공하기 위한 가장 강력한 방법은 브라우저에 의존하는 것으로, 브라우저는 text 유형을 가진 HTML 입력(input)과
contenteditable HTML 어트리뷰트를 가진 엘리먼트에 대해 텍스트 입력 기능을 제공합니다.
- 중요: JavaScript가 브라우저 제공 텍스트 편집 기능을 수행하는데 사용되는 키에 대해 키 이벤트를 캡쳐하여 간섭하지 않도록 하세요.
목록상자 팝업에 초점이 있는 경우:
- Enter: 팝업을 닫고, 콤보박스에 승인 된 값을 위치시키고, 콤보박스가 편집 가능한 경우 입력 커서를 값의 끝에 위치시켜 목록상자의 초점을 얻은 옵션 항목을 승인합니다.
- Escape: 팝업을 닫고 콤보박스로 초점을 되돌려줍니다. 선택적으로, 콤보박스가 편집 가능한 경우, 콤보박스의 콘텐츠를 지웁니다.
- Down Arrow: 다음 옵션 항목으로 초점을 이동시키고 선택합니다. 마지막 옵션 항목에 초점이 있는 경우, 콤보박스로 초점을 되돌려주거나 아무 것도 하지 않습니다.
- Up Arrow: 이전 옵션 항목으로 초점을 이동시키고 선택합니다. 첫 번째 옵션 항목에 초점이 있는 경우, 콤보박스로 초점을 되돌려주거나 아무 것도 하지 않습니다.
-
Right Arrow: 콤보박스가 편집 가능한 경우, 팝업을 닫지 않고 콤보박스로 초점을 되돌려주고 입력 커서를 오른쪽으로 한 글자 이동시킵니다.
입력 커서가 맨 오른쪽 문자에 있다면, 커서는 이동시키지 않습니다.
-
Left Arrow: 콤보박스가 편집 가능한 경우, 팝업을 닫지 않고 콤보박스로 초점을 되돌려주고 입력 커서를 왼쪽으로 한 글자 이동시킵니다.
입력 커서가 맨 왼쪽 문자에 있다면, 커서는 이동시키지 않습니다.
- Home (선택사항): 첫 번째 옵션 항목으로 초점을 이동시키고 선택하거나, 콤보박스가 편집 가능한 경우 콤보박스로 초점을 되돌려주고 첫 번째 문자에 커서를 위치시킵니다.
- End (선택사항): 마지막 옵션 항목으로 초점을 이동시키고 선택하거나, 콤보박스가 편집 가능한 경우 콤보박스로 초점을 되돌려주고 마지막 문자에 커서를 위치시킵니다.
- 출력 가능한 문자:
- 콤보박스가 편집 가능한 경우, 팝업을 닫지 않고 콤보박스로 초점을 되돌려주고 문자를 입력합니다.
- 그렇지 않으면, 입력된 문자로 시작하는 이름을 가진 다음 옵션 항목으로 초점을 이동시킵니다.
- Backspace (선택사항): 콤보박스가 편집 가능한 경우, 콤보박스로 초점을 되돌려주고 커서 앞의 문자를 삭제합니다.
- Delete (선택사항): 콤보박스가 편집 가능한 경우, 콤보박스로 초점을 되돌려주고, 제안이 선택된 경우 제안 된 상태를 제거하고, 자동완성 문자열이 있는 경우 삭제합니다.
그리드 팝업에서, 각 제안 값은 단일 셀 또는 전체 행으로 표현될 수 있습니다.
그리드 설계의 이러한 측면이 초점 이동에 대한 응답에서 키보드 인터랙션 설계와 선택 이동 방식에 어떻게 영향을 주는지 다음 사항을 참고하세요.
- Enter: 팝업을 닫고 콤보박스에 선택 된 값을 위치시키고, 콤보박스가 편집 가능한 경우 값의 끝에 입력 커서를 위치시켜 현재 선택된 제안된 값을 수락합니다.
- Escape: 팝업을 닫고 콤보박스로 초점을 되돌려줍니다. 선택적으로, 콤보박스가 편집 가능한 경우 콤보박스의 콘텐츠를 지웁니다.
-
Right Arrow: 초점을 오른쪽으로 한 셀 이동시킵니다.
선택적으로, 초점이 행의 가장 오른쪽 셀에 있다면, 다음 행의 첫 번째 셀로 초점을 이동시킬 수 있습니다.
초점이 그리드의 마지막 셀에 있다면, 아무 것도 하지 않거나 콤보박스로 초점을 되돌려줍니다.
-
Left Arrow: 초점을 왼쪽으로 한 셀 이동시킵니다.
선택적으로, 초점이 행의 가장 왼쪽 셀에 있다면, 이전 행의 마지막 셀로 초점을 이동시킬 수 있습니다.
초짐이 그리드의 첫 번째 셀에 있다면, 아무 것도 하지 않거나 콤보박스로 초점을 되돌려줍니다.
-
Down Arrow: 초점을 아래로 한 셀 이동시킵니다.
초점이 그리드의 마지막 행에 있다면, 아무 것도 하지 않거나 콤보박스로 초점을 되돌려줍니다.
-
Up Arrow: 초점을 위로 한 셀 이동시킵니다.
초점이 그리드의 첫 번째 행에 있다면, 아무 것도 하지 않거나 콤보박스로 초점을 되돌려줍니다.
-
Page Down (선택사항): 초점을 아래로 작성자가 정의한 행 개수 만큼, 일반적으로 현재 보이는 행 세트의 맨 아래 행이 첫 번째 보이는 행이 되도록 이동시킵니다.
초점이 그리드의 마지막 행에 있다면, 초점은 이동하지 않습니다
-
Page Up (선택사항): 초점을 위로 작성자가 정의한 행 개수 만큼, 일반적으로 현재 보이는 행의 세트의 첫 번째 행이 보이는 행의 마지막 행이 되도록 이동시킵니다.
초점이 그리드의 첫 번째 행에 있다면, 초점은 이동하지 않습니다.
- Home (선택사항): 다음 중 하나:
- 초점을 초점을 포함하고 있는 행의 첫 번째 셀로 이동시킵니다. 또는 그리드가 행 당 셀이 3개 미만이거나 행 당 여러 개의 제안 값을 가지는 경우, 그리드의 첫 번째 셀로 초점을 이동시킬 수 있습니다.
- 콤보박스가 편집 가능한 경우, 초점을 콤보박스로 되돌려주고 입력 커서를 첫 번째 문자로 위치시킵니다.
- End (선택사항): 다음 중 하나:
- 초점을 초점을 포함하고 있는 행의 마지막 셀로 이동시킵니다. 또는 그리드가 행 당 셀이 3개 미만이거나 행 당 여러 개의 제안 값을 가지는 경우, 그리드의 마지막 셀로 초점을 이동시킬 수 있습니다.
- 콤보박스가 편집 가능한 경우, 초점을 콤보박스로 되돌려주고 입력 커서를 마지막 문자 뒤로 위치시킵니다.
- Control + Home (선택사항): 첫 번째 행으로 초점을 이동시킵니다.
- Control + End (선택사항): 마지막 행으로 초점을 이동시킵니다.
- 출력 가능한 문자: 콤보박스가 편집가능하다면, 팝업을 닫지 않고 콤보박스로 초점을 돌려주고 문자를 입력합니다.
- Backspace (선택사항): 콤보박스가 편집 가능하다면, 콤보박스로 초점을 돌려주고 커서 앞의 문자를 삭제합니다.
- Delete (선택사항): 콤보박스가 편집 가능하다면, 콤보박스로 초점을 돌려주고, 제안이 선택되었다면 선택 상태를 제거하고 인라인 자동완성 문자열이 있다면 이를 제거합니다.
Note
- DOM 초점은 콤보박스에 유지되고 aria-activedescendant를 사용하여 복합 컴포넌트에서 초점 관리에 기술 된 대로
aria-activedescendant를 사용하여 그리드 내에서 보조기술 초점이 이동됩니다.
- 그리드는 콤보박스 값에 대해 한 번에 오직 하나의 제안 값만 선택될 수 있습니다.
- 그리드 팝업에서, 각 제안 값은 단일 셀 또는 전체 행으로 표현될 수 있습니다. 설계의 이러한 측면은 초점과 선택 이동에 영향을 줍니다:
- 모든 셀이 서로 다른 제안된 값을 가지는 경우:
- 선택은 초점을 따르므로 초점을 포함하는 셀이 선택됩니다.
- 상하 방향키는 일반적으로 행에서 다른 행으로 탐색합니다.
- 좌우 방향키는 일반적으로 열에서 다른 열로 탐색합니다.
- 행의 모든 셀이 동일한 제안 값에 대한 정보를 포함하는 경우:
- 동일한 행의 셀이 초점을 포함하는 경우 초점을 포함하는 행이 선택되거나 선택 된 값을 포함하는 셀이 선택됩니다.
- 상하 방향키는 행에서 다른 행으로 탐색할 수 있습니다.
- 좌우 방향키는 행에서 다른 행으로 탐색하지 않습니다
트리 팝업의 일부 구현에서, 일부 혹은 모든 상위 노드들은 제안 카테고리 레이블로 제공 될 수 있으므로 선택 될 수 있는 값이 아닐 수 있습니다.
설계의 이 측면이 초점 이동에 대한 응답에서 선택 이동 방법에 어떻게 영향을 주는지에 대해서 다음을 참고하세요.
초점이 수직 방향 트리 팝업에 있는 경우:
- Enter: 팝업을 닫지 않고 콤보박스에 선택 된 값을 위치시키고 콤보박스가 편집 가능 하다면 값의 끝에 입력 커서를 위치시켜 현재 선택 된 제안 값을 승인합니다.
- Escape: 팝업을 닫고 콤보박스로 초점을 돌려줍니다. 선택적으로 콤보박스의 콘텐츠를 지웁니다.
- Right arrow:
- 초점이 닫힌 노드에 있다면, 노드를 엽니다; 초점과 선택은 이동시키지 않습니다.
- 초점이 열린 노드에 있다면, 초점을 첫 번째 자식 노드로 이동시키고 선택 가능하다면 선택합니다.
- 초점이 마지막 노드에 있다면, 아무것도 하지 않습니다.
- Left arrow:
- 초점이 열린 노드에 있다면, 노드를 닫습니다.
- 초점이 마지막 노드이거나 닫힌 노드인 자식 노드에 있다면, 부모 노드로 초점을 이동 시키고 선택 가능하다면 선택합니다.
- 초점이 마지막 노드이거나 닫힌 노드인 최상위 노드에 있다면, 아무 것도 하지 않습니다.
- Down Arrow: 노드를 열거나 닫지 않고 초점을 얻을 수 있는(focusable) 다음 노드로 초점을 이동시키고 선택 가능하다면 선택합니다.
- Up Arrow: 노드를 열거나 닫지 않고 초점을 얻을 수 있는(focusable) 이전 노드로 초점을 이동시키고 선택 가능하다면 선택합니다.
- Home: 노드를 열거나 닫지 않고 트리의 첫 번째 초점을 얻을 수 있는(focusable) 노드로 초점을 이동시키고 선택 가능하다면 선택합니다.
- End: 노드를 열거나 닫지 않고 트리의 마지막 초점을 얻을 수 있는(focusable) 마지막 노드로 초점을 이동시키고 선택 가능하다면 선택합니다.
- 출력 가능한 문자:
- 콤보박스가 편집 가능하다면, 팝업을 닫지 않고 콤보박스로 초점을 돌려주고 문자를 타이핑합니다.
- 그렇지 않으면, 입력 된 문자로 시작하는 이름을 가진 다음 제안 값으로 초점을 이동시킵니다.
Note
- DOM 초점은 콤보박스에 유지되고 aria-activedescendant를 사용하여 복합 컴포넌트에서 초점 관리에 기술 된 대로
aria-activedescendant를 사용하여 트리 내에서 보조 기술 초점이 이동됩니다.
- 트리는 콤보박스 값에 대해 한 번에 오직 하나의 제안 값만 선택 될 수 있습니다.
-
트리 팝업에서, 일부 또는 모든 부모 노드는 선택 가능한 값이 되지 않을 수 있습니다; 제안 값에 대한 카테고리 레이블로 제공 될 수 있습니다.
선택 가능한 값이 아닌 노드로 초점이 이동하는 경우:
- 이전에 선택된 노드가 있다면 선택 가능한 노드로 초점이 이동 될 때까지 선택 된 상태를 유지하거나
- 선택된 값이 없거나
- 어느 경우에나, 초점이 선택과 시각적으로 구별되어 사용자가 값이 선택되었는지의 여부를 쉽게 확인할 수 있습니다.
- 트리의 노드가 수평으로 배열 된 (aria-orientation가
horizontal로 설졍 된) 경우:
- Down Arrow는 위에 설명된 Right Arrow와 동일하게 수행하고, 그 반대의 경우도 마찬가지입니다.
- Up Arrow는 위에 설명된 Left Arrow와 동일하게 수행하고, 그 반대의 경우도 마찬가지입니다.
초점이 대화상자 팝업에 있는 경우:
- 팝업을 닥고 콤보박스로 초점을 되돌리는 두 가지 방법이 있습니다:
- 버튼을 활성화 하는 것과 같이 콤보박스에 대한 특정 값을 지정하는 대화상자의 동작을 수행합니다.
-
대화상자 밖에서 취소, 예를 들어 Escape를 누르거나 대화상자의 취소 버튼을 활성화합니다.
취소하는 것은 콤보박스를 변경하지 않고 텍스트 박스로 초점을 되돌려주거나 콤보박스로 초점을 되돌려주고 콤보박스를 지웁니다.
- 대화상자는 모달 대화상자 패턴에 기술 된 키보드 인터랙션을 구현합니다.
Note
다른 콤보박스 팝업과는 달리, 대화상자는 aria-activedescendant를 지원하지 않으므로 DOM 초점이 콤보박스로부터 대화상자로 이동합니다.
- input으로 제공하고 콤보박스 값을 표시하는 엘리먼트는 combobox를 가집니다.
-
콤보박스 엘리먼트는 팝업으로 제공하는 엘리먼트를 가리키는 값으로 설정 된 aria-controls를 가집니다.
aria-controls는 팝업이 보일 때에만 설정이 필요함에 주의하세요. 하지만, 보이지 않는 엘리먼트를 참조하는 것도 유효합니다.
- 팝업은 listbox, tree, grid 또는 dialog 역할(role)을 가지는 엘리먼트입니다..
-
팝업이
listbox와 다른 역할(role)을 가진다면, combobox 역할(role)을 가진 엘리먼트는 팝업 유형에 해당하는 값으로 설정 된 aria-haspopup을 가집니다.
즉, aria-haspopup이 grid, tree, 또는 dialog로 설정됩니다.
combobox 역할(role)을 가진 엘리먼트가 명시적인 listbox 값의 aria-haspopup을 가지는 것에 유의하세요.
-
콤보박스 팝업이 보이지 않는 경우,
combobox 역할(role)을 가진 엘리먼트는 false로 설정 된 aria-expanded를 가집니다.
팝업 엘리먼트가 보이는 경우, aria-expanded가 true로 설정 됩니다.
combobox 역할(role)을 가진 엘리먼트가 aria-expanded에 대한 기본 값으로 false를 가짐에 유의하세요.
- 콤보박스가 초점을 얻을 때, DOM 초점이 콤보박스 엘리먼트에 위치합니다.
- 목록상자, 그리드, 트리 팝업의 후손이 초점을 얻을 때, DOM 초점은 콤보박스에 유지되고 콤보박스는 팝업 내의 초점을 얻은 엘리먼트를 가리키는 값으로 설정 된 aria-activedescendant를 가집니다.
- 목록상자, 그리드, 트리 팝업을 제어하는 콤보박스의 경우, 제안 값이 시각적으로 현재 선택 된 값으로 보여진다면, 값을 포함하고 있는
option, gridcell, row, treeitem은 true로 설정 된 aria-selected를 가집니다.
-
콤보박스가 보이는 레이블을 가지고 콤보박스 엘리먼트가
label 엘리먼트를 사용하여 레이블이 지정될 수 있는 HTML 엘리먼트라면(예를 들어, input엘리먼트), label 엘리먼트를 사용하여 레이블이 지정됩니다.
그렇지 않고 보이는 레이블이 있는 경우, 콤보박스 엘리먼트는 레이블을 지정하는 엘리먼트를 가리키는 값으로 설정 된 aria-labelledby를 가집니다.
그렇지 않으면, 콤보박스는 aria-label로 제공되는 레이블을 가집니다..
- 콤보박스 엘리먼트는 자동완성 동작에 해당하는 값으로 설정 된 aria-autocomplete를 가집니다:
none: 팝업이 노출 될 때, 콤보박스에 입력된 문자와 상관없이 팝업에 포함 된 제안 값은 동일합니다.list: 팝업이 트리거 될 때, 제안 값을 나타냅니다. 콤보박스가 편집 가능하다면, 값은 완전히 또는 논리적으로 콤보박스에 입력 된 문자와 일치합니다.-
both: 팝업이 트리거 될 때, 콤보박스에 입력된 문자와 완전히 또는 논리적으로 일치하는 제안 값을 나타냅니다.
또한 사용자가 입력하지 않은 선택된 제안의 일부가 (완성 문자열
로 알려진), 콤보박스의 입력 커서 뒤에 인라인으로 나타납니다.
인라인 완성 문자열은 시각적으로 강조 표시되고 선택된 상태를 가집니다.
Note
-
ARIA 1.0에서, 콤보박스는 aria-controls 대신 aria-owns로 팝업이 참조되었습니다.
유저 에이전트가 레거시 콘텐츠와의 하위 호환성을 위해 aria-owns를 가진 콤보박스를 지원할 수 있지만, aria-controls를 사용하는 것이 강력히 권장됩니다.
- 팝업에 사용되는 패턴의 다음 목록에 대한 역할(role), 상태(state), 속성(property) 문서를 참조할 때, 콤보박스가 선택이 팝업 내의 초점을 따르는 단일 선택 위젯이라는 점을 유념하세요.
- 팝업 엘리먼트에 대한 역할(role), 상태(state), 속성(property)는 각각의 설계 패턴에서 정의됩니다:
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.
-
A
grid is a composite widget so it:
- Always contains multiple focusable elements.
- Only one of the focusable elements contained by the grid is included in the page tab sequence.
- Requires the author to provide code that manages focus movement inside it.
- All focusable elements contained in a table are included in the page tab sequence.
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.
- 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.
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.
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.
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.
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.
This section describes two important aspects of keyboard interaction design shared by both data and layout grid patterns:
- Choosing whether a cell or an element inside a cell receives focus in response to grid navigation key events.
- Enabling grid navigation keys to be used to interact with elements inside of a cell.
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:
-
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.
- 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.
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:
- Editable content.
- Multiple widgets.
- 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.
- 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.
접근 가능한 이름과 적절한 경우 접근 가능한 설명을 가진 엘리먼트를 제공하는 것은 접근 가능한 웹 경험을 개발할 때 작성자가 가져야 할 가장 중요한 책임 중 하나입니다.
대부분의 엘리먼트에서는 그렇게 하는 것이 간단한 반면, 보조 기술 사용자들을 완전히 차단할 수 있는 기술적 실수 역시 쉽게 만들 수 있고 불행하게도 흔하게 일어납니다.
작성자가 접근 가능한 이름과 설명을 효과적으로 제공할 수 있도록 돕기 위해, 이 섹션에서는 그 목적과, 작성자가 그것들을 제공해야 하는 경우, 브라우저가 그것들을 모으는 방법, 그것들을 코드화하고 구성하기 위한 규칙을 설명합니다.
또한 작성자에게 다음의 이름 지정와 설명 지정 기법 및 WAI-ARIA 속성 사용에 대해서도 안내합니다:
- 이름 지정:
- 자식 콘텐트로 이름 지정.
aria-label을 통해 문자열 속성으로 이름 지정.aria-labelledby로 콘텐트를 참조하여 이름 지정.- label 엘리먼트로 폼 컨트롤 이름 지정.
- 엘리먼트로 필드셋 이름 지정.
- 캡션으로 표 및 삽화 이름 지정.
- 제목과 자리 표시자로부터 파생된 폴백 이름.
- 설명 붙이기:
aria-describedby로 콘텐츠를 참조하여 설명 지정.- 캡션으로 표 및 삽화에 설명 지정.
- 제목으로부터 파생된 설명.
접근 가능한 이름은 일반적으로 1 ~ 3개 단어의 짧은 문자열로, 작성자가 보조 기술 사용자에게 엘리먼트에 대한 레이블을 제공하기 위해 엘리먼트와 연관시킨 문자열입니다.
예를 들어, 입력 필드는 접근 가능한 "User ID"이라는 이름을 가지거나, 버튼은 "Submit"으로 이름 지을 수 있습니다.
접근 가능한 이름은 스크린리더와 같은 보조 기술 사용자에게 두 가지 주요 목적을 제공합니다:
- 엘리먼트의 목적이나 의도를 전달.
- 페이지의 다른 엘리먼트로부터 엘리먼트를 구별.
WAI-ARIA 명세와 WCAG 둘 모두 모든 포커서블(focusable), 인터랙티브 엘리먼트들은 접근 가능한 이름을 가지도록 요구합니다.
게다가 대화 상자와 tables과 regions 같은 일부 구조 컨테이너들도 이름을 가지도록 요구됩니다.
많은 다른 엘리먼트들도 이름을 지정할 수 있지만, 이름이 접근성을 향상시키는가의 여부는 주변 컨텍스트의 다양한 특성에 따라서 결정됩니다.
마지막으로, 접근 가능한 이름을 제공하는 것이 기술적으로는 가능하지만 권장할만 하지는 않은 일부 엘리먼트들이 있습니다.
역할에 따른 접근 가능한 이름 지침 섹션은 모든 ARIA 역할에 대한 이름 지정 요구 사항과 지침들을 나열합니다.
접근 가능한 설명 역시 보조 기술에 의해 렌더링 되는 작성자가 제공한 문자열입니다.
작성자는 입력 필드에 대한 지시 사항이나 형식 요구 사항과 같은, 엘리먼트와 연관 시킬 필요가 있는 추가적인 정보가 있을 경우 설명을 제공합니다.
보조 기술은 이름과 설명을 다르게 표현합니다.
예를 들어, 스크린리더는 일반적으로 엘리먼트의 이름과 역할을 먼저 낭독합니다. 예를 들어, 대화 음소거
라고 명명된 버튼은 대화 음소거 버튼
이라고 낭독되어 질 수 있습니다.
엘리먼트가 상태(state)를 가지는 경우, 이름과 역할 앞이나 뒤로 낭독될 수 있습니다; 일반적으로 기본은 이름과 역할 이후입니다.
예를 들어, 꺼짐
상태인 대화 음소거
라고 명명된 스위치 버튼은 대화 음소거 스위치 버튼 꺼짐
으로 낭독 될 수 있습니다.
설명은 일반적으로 이름보다 상당히 긴 선택적인 문자열이기 때문에, 마지막에 표현되고, 때로는 약간 지연 된 후에 표현됩니다.
예를 들어, 대화 음소거 스위치 버튼 꺼짐, 이 대화의 활동에 대한 알림(alert)과 알림 소리를 없앱니다.
자세한 내용을 줄이기 위해, 일부 스크린리더는 기본적으로 설명을 낭독하지 않고, 대신 사용자에게 그 존재를 알려 사용자가 설명을 낭독시키도록 키를 누르게 할 수 있습니다.
접근 가능한 이름이나 설명 문자열에 포함 시킬 텍스트를 지정할 엘리먼트와 어트리뷰트들이 여럿 있기 때문에, 그리고 작성자가 거의 끝 없는 방식으로 그 텍스트들을 결합 할 수 있기 때문에, 브라우저는 문자열을 조립하기 위해 상당히 복잡한 알고리즘을 구현합니다.
접근 가능한 이름 계산과 접근 가능한 설명 계산의 섹션들이 알고리즘과 브라우저들이 우선 순위를 구현하는 방법을 설명합니다.
하지만, 이름이나 설명이 유용한 경우의 거의 모든 상황은 이름 지정 기법과 설명 지정 기법 섹션에 기술된 코딩 패턴에 따라 지원되기 때문에 대부분의 작성자는 알고리즘에 대한 상세한 이해 같은 것은 필요하지 않습니다.
아래 몇 가지 이름 지정 기법은 ARIA 명세에 의해 금지되거나 아직 완전히 정의되지 않은 회색 지대에 속하는 특정 코딩 패턴에 대해 경고하는 메모를 포함하고 있습니다.
이러한 금지된 것이나 모호한 패턴 중 일부는 논리적으로 나타나고 일부 브라우저에서 희망했던 이름을 내 줄 수도 있습니다.
하지만, 특히 브라우저 간의 이름 계산의 일관성을 개선하기 위한 작업이 진행됨에 따라 브라우저 전체를 통틀어 일관된 결과를 제공할 가능성이 낮습니다.
이름 지정 기법에 제공되는 경고에 주의를 기울이는 것 외에도, 브라우저가 계산한 이름과 예상 한 것이 일치하도록 보장하기 위해 테스트의 중요성을 지나치게 강조하기란 쉽지 않습니다.
유저 인터페이스가 적절한 접근 가능한 이름을 제공하는데 사용될 수 있는 보이는 텍스트를 포함하는 경우, 접근 가능한 이름에 대한 보이는 텍스트를 사용하는 것이 유지보수를 간소화하고, 오류를 방지하며 언어 번역 요구 사항을 줄입니다.
이름이 시각적으로 표시되지 않고 마크업 안에만 존재하는 텍스트로부터 생성되는 경우, 유저 인터페이스 설계나 콘텐츠가 변경될 경우 접근 가능한 이름은 업데이트 되지 않을 소지가 높습니다.
입력 상자나 버튼과 같은 대화형 엘리먼트(interactive element)가 시각적으로 사라지지 않는 텍스트 레이블이 없는 경우, 이를 포함하도록 디자인을 조정하세요.
접근 가능한 이름에 대해 더 견고한 소스를 제공하는 것 외에, 보이는 텍스트 레이블은 보이지 않는 이름을 나타내는 보조 기술을 사용하지 않는 많은 장애인들에 대한 접근성을 향상시킵니다.
대부분의 상황에서, 보이는 텍스트 레이블은 또한 유저 인터페이스를 모든 사용자들이 이해하기 더 쉽게 만듭니다.
HTML 문서에서, 가능할때마다, 폼 엘리먼트에 대한 HTML label 엘리먼트와 표에 대한 caption 엘리먼트와 같은 HTML 이름 지정 기법을 사용하세요.
유연성은 떨어지지만, 보이는 텍스트에 대한 단순성과 의존성은 견고한 접근 가능한 환경을 보장하는데 도움이 됩니다.
몇 몇 이름 지정 기법은 ARIA 속성 대신 HTML 기능을 사용하는 것의 특정 접근성 장점을 강조합니다.
작성자가 이름 지정을 위해 의도된 엘리먼트나 어트리뷰트를 사용하여 접근 가능한 이름을 지정하지 않는 경우, 브라우저는 이름을 생성하기 위한 폴백 메서드에 기대어 보조 기술 사용자를 도우려 시도합니다.
예를 들어, HTML title과 placeholder 어트리뷰트는 접근 가능한 이름에 대한 콘텐츠의 최후의 수단으로 사용됩니다.
이 어트리뷰트의 목적은 이름 지정이 아니기 때문에, 일반적으로 그 내용은 유효하지 않은 저품질의 접근 가능한 이름을 산출합니다.
시각적으로 화면을 가득 메우고 모호한 아이콘이 사용성을 떨어뜨리는 방법과 유사하게, 지나치게 길거나 충분히 분명하지 않거나 불확실한 접근 가능한 이름은 유저 인터페이스를 매우 어렵게 만들거나 심지어 유저 인터페이스의 비시각적 형태에 의존하는 사람들의 사용을 불가능하게 만들 수 있습니다.
다시 말해, 접근 가능한 웹 경험을 위해 접근 가능한 이름이 유효해야 합니다.
유효하고 사용자 친화적인 접근 가능한 이름 작성 섹션은 간결성과 명확성의 균형을 위한 지침을 제공합니다.
특정 엘리먼트는 포함하는 콘텐트로부터 이름을 가져옵니다.
예를 들어, 다음 링크는 "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 엘리먼트의 후손인 group과 menuitem 엘리먼트의 후손인 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에 의해 참조되지 않는 한 보조 기술 사용자에게 숨겨집니다.
보조 기술 사용자로부터 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 위 엘리먼트들 중 하나의 콘텐트를 재정의하기 위해 이 속성들 중 하나를 사용하지 않는 것이 강력히 권장됩니다.
또한, 볼 수 있는 콘텐트가 이 속성 중 하나의 사용으로 인해 보조 기술 사용자에게 숨겨지는 경우에서는 보조 기술을 사용한 철저한 테스트가 특히 중요합니다.
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
-
aria-label이 자식 콘텐트로부터 이름 지정을 지원하는 역할(role) 중 하나로 엘리먼트에 적용된다면, 엘리먼트에 포함되고 엘리먼트의 후손인 콘텐트는 보조 기술 사용자에게 숨깁니다.
보조 기술 사용자로부터 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 위 엘리먼트들 중 하나의 콘텐트를 재정의하기 위해 aria-label을 사용하지 않는 것이 강력히 권장됩니다.
aria-label로 이름을 지정하지 않아야 하는, 문단과 목록 항목 같은 특정한 유형의 엘리먼트가 있습니다. 그것들은 역할(role)에 의한 접근 가능한 이름 지정 지침 섹션의 표에 나와 있습니다.aria-label의 값은 시각적으로 전달되지 않기 때문에, 예상되는 이름이 사용자에게 제공하는 것을 확인하기 위해 보조 기술을 사용하여 테스트하는 것이 특히 중요합니다.- 유저 인터페이스가 여러 언어로 번역되는 경우,
aria-label 값이 번역 되는지 확인하세요.
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 어트리뷰트를 가진 HTML label을 사용하는 것과 유사한 반면, 한 가지 중요한 차이점은 브라우저가 레이블을 지정하는 엘리먼트를 클릭하는 것이 레이블이 지정된 엘리먼트를 자동으로 활성화 하지 않는 다는 것에 주목하세요. 그것은 작성자의 책임입니다.
하지만, HTML label은 span 엘리먼트에 레이블을 지정하는데 사용될 수 없습니다.
다행히 HTML type="checkbox"을 가진 input은 ARIA switch 역할(role)을 허용하므로 가능한 경우 다음 접근법을 사용하는 것이 더 견고한 해결책을 만듭니다.
<label for="night-mode">야간 모드</label>
<input type="checkbox" role="switch" id="night-mode">
aria-labelledby 속성(property)은 다음의 이유로 여러 상황에서 유용합니다:
브라우저가 접근 가능한 이름을 계산할 때 가장 높은 우선 순위를 가집니다. 즉, 자식 콘텐트로부터의 이름과 aria-label을 포함하여 모든 다른 이름 속성들 보다 우선됩니다.
여러 엘리먼트의 콘텐츠를 단일 이름 문자열로 연결할 수 있습니다.
-
가시성과 관계 없이 엘리먼트의 콘텐트를 포함합니다. 즉, 계산된 이름 문자열에 hidden 어트리뷰트, 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
aria-labelledby 속성(property)은 체이닝 될 수 없습니다. 즉, aria-labelledby를 가진 엘리먼트가 aria-labelledby를 가진 다른 엘리먼트를 참조하는 경우, 참조된 엘리먼트의 aria-labelledby 어트리뷰트는 무시될 것입니다.- 이름 계산 중에 엘리먼트가 두 번 이상
aria-labelledby에 의해 참조되는 경우, 두 번째 및 이후의 참조는 무시될 것입니다.
aria-labelledby로 이름을 지정하지 않아야 하는 문단이나 목록 항목과 같은 특정 유형의 엘리먼트가 있습니다. 그것들은 역할에 따른 접근 가능한 이름 지정 지침 섹션의 표에 나와있습니다.-
aria-labelledby가 자식 콘텐츠로부터 이름 지정을 지원하는 역할(role)의 하나를 가진 엘리먼트에 적용되는 경우, 엘리먼트와 그 엘리먼트의 후손에 포함된 콘텐트는 aria-labelledby에 의해 참조되지 않는 한, 보조 기술 사용자에게 숨겨집니다.
보조 기술 사용자에게 콘텐트를 숨기는 것이 이로운 드문 경우를 제외하고 이 어트리뷰트를 사용하여 이 엘리먼트들 중 하나의 콘텐트를 무시하게 하는 것을 방지하는 것이 강력하게 권장됩니다.
aria-labelledby를 가진 엘리먼트의 이름을 계산하는 것은 복잡하고 숨겨진 콘텐트를 참조할 수 있기 때문에, 기대하는 이름이 사용자에게 노출되는지를 보장하도록 보조 기술을 가지고 테스트 하는 것이 특히 중요합니다.
HTML label 엘리먼트는 작성자가 레이블로 제공하는 콘텐트를 식별하고 폼 컨트롤과 연결할 수 있게 합니다.
label 엘리먼트가 폼 컨트롤과 연결 될 경우, 브라우저는 label 콘텐트로부터 폼 컨트롤에 대한 접근 가능한 이름을 계산합니다.
예를 들어, 체크상자와 나란히 표시되는 텍스트는 체크상자와 시각적으로 연결 될 수 있으므로, 시각적 연관성을 인식할 수 있는 사용자에 의해 체크상자 레이블로 이해됩니다.
하지만, 텍스트가 프로그래밍 방식으로 체크상자와 연결되어 있지 않으면, 보조 기술 사용자는 레이블이 없는 체크상자를 경험하게 될 것입니다.
다음과 같이 체크상자와 label 엘리먼트에 체크상자와 레이블 텍스트를 감싸는 것은 체크상자에 접근 가능한 이름을 제공합니다.
<label>
<input type="checkbox" name="subscribe">
뉴스레터 구독
</label>
폼 컨트롤은 label 엘리먼트의 for 어트리뷰트를 사용하여 레이블과 연결될 수도 있습니다.
이는 레이블과 폼 컨트롤이 형제가 되게하거나 DOM에서 부모가 다르지만 폼 컨트롤에 id 어트리뷰트를 추가하는 것을 요구하므로 오류가 발생하게 할 수 있습니다.
가능하다면, 연결을 위해 다음의 for 어트리뷰트 기법 대신 위의 캡슐화 기법을 사용하세요.
<input type="checkbox" name="subscribe" id="subscribe_checkbox">
<label for="subscribe_checkbox">뉴스레터 구독</label>
label 엘리먼트를 사용하는 것은 규칙 2: 보이는 텍스트 선택을 만족시키는 효과적인 기법입니다.
또한 규칙 3: 기본 기술 선택을 만족시킵니다.
네이티브 HTML 레이블은 ARIA 레이블링 기법보다 중요한 사용성과 접근성의 이점을 제공합니다: 브라우저는 자동으로 레이블을 클릭하는 것이 폼 컨트롤을 클릭한 것과 동일하게 합니다.
이는 폼 컨트롤의 누르는 영역을 증가시킵니다.
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>
이 그룹핑 기법은 다중 선택 문제를 표현하는데 특히 유용합니다.
작성자들이 질문과 답변 그룹을 연결 시킬 수 있게 합니다.
질문이 프로그램적으로 답변 그룹과 연결되지 않는 경우, 보조 기술 사용자는 질문을 알지 못한 채 답변에 접근할 것입니다.
fieldset과 legend를 사용하여 다른 유형의 폼 필드를 그룹핑 하고 이름을 지정하는 경우에도 유사한 이점을 얻을 수 있습니다.
<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: 기본 기술 선택을 만족시킵니다.
HTML table과 figure에 대한 접근 가능한 이름은 각각 자식 caption이나 figcaption으로부터 파생될 수 있습니다.
표와 삽화는 종종 그것이 무엇에 관한 것인지, 어떻게 읽는지를 설명하기 위한 캡션을 가지며 때때로 이들에 주변 글에서 이들을 참조하는데 사용되는 숫자를 부여합니다.
캡션은 모든 사용자가 콘텐츠를 더 잘 이해하는데 도움이 되지만, 특히 보조 기술 사용자에게 도움이 됩니다.
HTML에서, table 엘리먼트는 데이터 테이블을 마크업하고 caption 엘리먼트를 사용하여 캡션이 함께 제공될 수 있습니다.
table 엘리먼트가 aria-label나 aria-labelledby를 가지지 않은 경우, caption이 접근 가능한 이름으로 사용 될 것입니다.
예를 들어 다음 표의 접근 가능한 이름은 특별 영업 시간
입니다.
<table>
<caption>특별 영업 시간</caption>
<tr><td>5월 30일 <td>휴무</td></tr>
<tr><td>6월 6일 <td>11:00-16:00</td></tr>
</table>
다음 예는 참조 할 수 있도록 표 번호를 (표 1
)을 제공합니다.
<table>
<caption>표 1. 1950년 오키나와인과 다른 일본인의 전통적인 식이 섭취</caption>
<thead>
<tr>
<th>
<th>오키나와, 1949</th>
<th>일본, 1950</th>
</tr>
<tbody>
<tr>
<th>총 칼로리</th>
<td>1785</td>
<td>2068</td>
[...]
</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에서 가져옴.
table이 aria-label나 aria-labelledby를 사용하여 이름이 지정되고, caption 엘리먼트가 있다면 이는 접근 가능한 설명이 될 것입니다.
예를 들어, 캡션으로 표와 삽화를 설명하기를 참고하세요.
유사하게, HTML figure 엘리먼트는 figcaption 엘리먼트를 사용하여 캡션이 제공 될 수 있습니다.
캡션은 삽화의 앞 혹은 뒤에 나타날 수 있지만, 삽화 뒤에 캡션이 있는 것이 더 일반적입니다.
<figure>
<img alt="사막에서 걷고 있는 사람의 그림." src="Hole_JesusalDesierto.jpg">
<figcaption>윌리엄 홀이 상상한 사막으로 들어가는 예수, 1908</figcaption>
</figure>
table 엘리먼트와 같이, figure가 aria-label이나 aria-labelledby를 사용하여 이름이 지정되지 않은 경우, figcaption 엘리먼트의 콘텐츠가 접근 가능한 이름으로 사용될 것입니다.
하지만 table 엘리먼트와 달리, figcaption 엘리먼트가 이름으로 사용되지 않은 경우, aria-describedby로 참조되지 않는 한 접근 가능한 설명이 되지는 않습니다.
그럼에도 불구하고, 보조 기술은 그것이 이름이나 설명 또는 둘 다로 사용되는지 여부에 관계 없이 figcaption의 콘텐트를 렌더링 합니다.
table 엘리먼트에 이름을 지정하기 위해 caption 엘리먼트를 사용하거나, figure 엘리먼트에 이름을 지정하기 위해 figcaption 엘리먼트를 사용하는 것은 규칙 2: 보이는 텍스트 선택과 규칙 3: 기본 기술 선택을 만족시킵니다.
접근 가능한 이름이 주요 기법들 중 하나 (예를 들어, aria-label나 aria-labelledby 어트리뷰트) 또는, 네이티브 마크업 기법을 (예를 들어, HTML label 엘리먼트나, HTML img 엘리먼트의 alt 어트리뷰트) 사용하여 제공되지 않은 경우, 브라우저는 대체 매커니즘으로 다른 어트리뷰트로부터 접근 가능한 이름을 계산합니다.
대체 이름 계산으로 사용되는 어트리뷰트는 이름 지정을 위해 의도되지 않았기 때문에, 일반적으로 유효하지 않은 낮은 품질의 접근 가능한 이름을 생성합니다.
따라서, 규칙 4: 브라우저 폴백 방지에 설명된 대로 이 섹션에 설명된 대체 기술 보다 위에서 설명된 명시적 레이블링 기법을 우선하세요.
HTML 엘리먼트는 지정된 title 어트리뷰트를 가질 수 있습니다.
title 어트리뷰트는 엘리먼트의 대체 접근 가능한 이름으로 사용될 수 있습니다.
title 어트리뷰트는 일반적으로 사용자가 포인팅 기기로 엘리먼트 위를 맴돌 때 툴팁으로 시작적으로 표시되어 특별히 쉽게 찾을 수 없고, 포인팅 기기가 없은 시각 사용자에게도 접근 가능하지 않습니다.
예를 들어, 자식 legend 엘리먼트가 없지만 title 어트리뷰트가 있는 fieldset 엘리먼트는 title 어트리뷰트로부터 접근 가능한 이름을 가져옵니다.
<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 input과 textarea 엘리먼트에 대해, placeholder 어트리뷰트는 다른 (title 어트리뷰트를 포함하여) 레이블을 생성하는 것이 없다면 대체 레이블링 메커니즘으로 사용됩니다.
사용자가 폼 컨트롤에 초점을 주었을 때 시각적으로 사라지지 않기 때문에 label 엘리먼트를 사용하는 것이 더 좋습니다.
<label>검색 <input type=search name=q></label>
<input type=search name=q placeholder="검색">
보조 기술 사용자, 특히 스크린리더 사용자의 경우, 접근 가능한 이름의 품질은 사용성에 가장 중요한 기여자 중 하나입니다.
충분한 정보를 제공하지 않는 이름이 사용자의 효과성(effectiveness)을 떨어뜨리는 반면 너무 긴 이름은 효율성(efficiency)을 떨어뜨립니다.
그리고 이해하기 어려운 이름은 효과성(effectiveness), 효율성(efficiency), 흥미를 떨어뜨립니다.
다음 지침은 사용자 친화적인 이름에 대한 시작점을 제공합니다.
-
형태가 아닌 기능이나 목적을 전달하세요.
예를 들어,
X
문자처럼 보이는 아이콘이 대화상자를 닫는 경우, X
가 아니라 닫기
로 이름을 지정하세요.
유사하게, 왼쪽 사이드바의 내비게이션 링크 세트가 쇼핑몰 사이트의 상품 페이지를 탐색하는 경우, 내비게이션 영역을 왼쪽
이 아니라 상품
으로 이름을 지정하세요.
-
가장 특징적이고 중요한 단어를 먼저 넣으세요.
종종 동작을 수행하는 대화형 엘리먼트(interactive element)의 경우, 동사가 첫 번째 단어라는 것을 의미합니다.
예를 들어, 연락처 목록이 각 연락처에 대한
편집
, 삭제
, 작업
버튼을 표기하는 경우,
편집 John Doe
, 삭제 John Doe
, 작업 John Doe
가 John Doe 수정
, John Doe 삭제
, John Doe 작업
보다 더 좋은 접근 가능한 이름일 것 입니다.
이름의 처음에 동사를 배치하여, 스크린리더 사용자는 더 쉽고 빠르게 John Doe에 대한 연락처 카드를 여는 엘리먼트뿐 아니라 다른 것들로부터 버튼을 구별할 수 있습니다.
-
간결하게 하세요. 많은 엘리먼트들의 경우, 1 ~ 3 단어면 충분합니다.
필요할 경우에만 더 많은 단어를 추가하세요.
-
접근 가능한 이름에 WAI-ARIA 역할(role) 이름을 포함시키지 마세요.
예를 들어, 버튼 이름에
버튼
이라는 단어를 포함 시키거나, 이미지 이름에 이미지
라는 단어를 포함시키거나, 내비게이션 영역 이름에 내비게이션
이라는 단어를 포함시키지 마세요.
그렇게 하는 것은 스크린리더가 이름에 엘리먼트의 역할(role)을 추가로 전달하므로 스크린리더 출력이 중복되게 만들게 됩니다.
-
엘리먼트가 실제로 동일하지 않는 한 동일한 역할을 가진 엘리먼트에 대해 고유한 이름을 생성하세요.
예를 들어, 동일한 위치를 참조하는 여러 링크가 있는 경우를 제외하고 페이지의 모든 링크는 서로 다른 이름을 가지도록 해야 합니다.
마찬가지로, 동일한 탐색 기능을 수행하는 동일한 콘텐트를 가진 영역이 없는 한 페이지의 모든 내비게이션 영역에 다른 이름을 지정하세요.
-
대문자로 이름을 시작하세요; 이는 일부 스크린리더가 적절한 어조로 말하게 하는데 도움을 줍니다.
마침표로 이름을 끝내지 마세요; 이름은 문장이 아닙니다.
어떤 엘리먼트는 항상 이름을 요구하고, 어떤 엘리먼트는 보통 또는 종종 이름을 요구하고, 그러나 어떤 엘리먼트들은 결코 이름이 지정되지 않아야 합니다.
다음 표는 ARIA 역할(role)을 나열하고 각각에 대한 다음 정보를 제공합니다:
- 이름 지정 필요성
-
작성자가 지정된 역할(role)을 가진 엘리먼트의 콘텐트를 보완하거나 대체하도록 하기 위해 이름을 지정하는 어트리뷰트나 엘리먼트를 추가할 필요성의 정도를 나타냅니다.
이 열은 다음 값들 중 하나를 포함할 수 있습니다:
-
내용이 불충분한 경우에만 필요: 이 역할(role)을 가진 엘리먼트는 하위 콘텐츠에 의해 이름이 지정됩니다.
aria-label나 aria-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 어트리뷰트가 스크린리더가 table, grid, treegrid 내의 연관된 cell을 읽을 때 낭독되기만 하는 이름의 축약 버전을 지정하는데 사용될 수 있습니다.
|
combobox |
필수 |
combobox 역할(role)이 HTML select나 input 엘리먼트에 적용된 경우, 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의 경우,
figure와 figcaption 엘리먼트를 사용하세요. figcaption은 figure에 대한 접근 가능한 이름으로서 제공할 것입니다. 캡션으로 표와 삽화 이름 지정 섹션을 참고하세요.
- 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-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- 이름이 필수가 아님을 주의하세요; 보고 기술은 그리드의 빈 셀이 빈 이름으로 표현될 것으으로 예상합니다.
- 연관된 열이나 행 헤더는
gridcell에 이름을 지정하지 않음에 주의하세요; 그리드에서 셀 이름은 그것의 콘텐트 입니다. 헤더는 보완 정보(complementary information)입니다.
|
group |
재량 |
- HTML
fieldset 엘리먼트를 사용하는 경우, 접근 가능한 이름은 legend 엘리먼트로부터 파생될 수 있습니다.
details 엘리먼트를 사용하는 경우, 이 엘리먼트에 대한 접근 가능한 이름을 제공하지 마세요. 사용자는 summary 엘리먼트로 상호 작용하고, 그것의 콘텐츠로부터 접근 가능한 이름을 파생시킬 수 있습니다.optgroup 엘리먼트를 사용하는 경우, label 어트리뷰트를 사용하세요.- 그렇지 않으면, 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
|
heading |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
|
insertion |
금지 |
|
img |
필수 |
HTML img 엘리먼트의 경우, alt 어트리뷰트를 사용하세요. img 역할(role)을 가진 다른 엘리먼트의 경우, aria-labelledby나 aria-label을 사용하세요. |
link |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-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 엘리먼트의 콘텐트를 낭독하기 전에 log 엘리먼트의 이름을 낭독합니다.
따라서, aria-label은 로그 엘리먼트의 부분으로 노출되지 않는 텍스트로 log 엘리먼트의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다.
aria-label을 사용하는 것은 log 엘리먼트에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, log 엘리먼트의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
|
main |
재량 |
- 잠재적으로 특히 페이지 로드 이벤트를 생성하지 않고 main 콘텐츠 변경을 일으키는 싱글 페이지 어플리케이션에서 보조 기술 사용자를 지향하는데 도움이 됩니다.
- 가시적으로 보이는 레이블이 존재한다면
aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정될 수 있습니다.
- Main 랜드마크 섹션을 참고하세요.
|
marquee |
재량 |
시각적으로 보이는 레이블이 존재하는 경우 aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요. |
math |
권장 |
math 엘리먼트가 표현을 위한 자식만을 가지고 접근 가능한 이름이 수학 표현식을 전달하기 위해 의도된 경우, 표현식을 나타내는 문자열을 제공하도록 aria-label을 사용하세요.math 엘리먼트가 수학 표현식을 전달하는 탐색 가능한 콘텐트를 포함하고 표현식에 대한 가시적으로 보이는 레이블이 존재한다면, aria-labelledby를 사용하세요.- 그렇지 않으면, 표현식에 이름을 지정하기 위해
aria-label을 사용하세요, 예를 들어, aria-label="피타고라스 정리".
|
menu |
권장 |
- 이 엘리먼트의 가시성을 제어하는 메뉴 아이템이나 버튼을 나타내도록
aria-labelledby를 사용하세요.
- 그렇지 않으면,
aria-label을 사용하세요.
- Menu나 Menu bar 설계 패턴을 참고하세요.
|
menubar |
권장 |
-
스크린리더 사용자가 컨텍스트와
menubar 내의 menuitem 엘리먼트의 목적을 이해하도록 도와주세요.
menubar에 이름을 지정하는 것은 메뉴 버튼에 이름을 지정하는 것과 비슷합니다.
menu를 여는 button의 이름은 메뉴의 목적이 그것을 여는 것(open)임을 전달합니다.
menubar 엘리먼트는 지속적으로 노출되기 때문에, menubar의 이름은 동일한 목적을 제공할 수 있습니다.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Menu나 Menu bar 설계 패턴을 참고하세요.
|
menuitem |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- 주의: 자식
menu 내에 포함된 콘텐트는 자동으로 접근 가능한 계산에서 제외됩니다.
- Menu나 Menu bar 설계 패턴을 참고하세요.
|
menuitemcheckbox |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- Menu나 Menu bar 설계 패턴을 참고하세요.
|
menuitemradio |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- Menu나 Menu bar 설계 패턴을 참고하세요.
|
meter |
필수 |
- HTML
meter 엘리먼트를 기반으로 하는 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.
- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
|
navigation |
권장 |
- 스크린리더 사용자가 컨텍스트와 navigation 랜드마크의 목적을 이해하도록 도와주세요.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Navigation 랜드마크 섹션을 참고하세요.
|
none |
금지 |
role="none"을 가진 엘리먼트는 (오류 케이스를 제외하고) 접근성 트리의 일부가 아닙니다. aria-labelledby나 aria-label을 사용하지 마세요. |
note |
재량 |
- 이름 지정은 선택적이지만, 스크린리더 사용자가 컨텍스트와 note의 목적을 이해하도록 도울 수 있습니다.
- 가시적으로 보이는 레이블이 존재한다면,
aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
|
option |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- Combobox 설계 패턴을 참고하세요.
|
paragraph |
금지 |
|
presentation |
금지 |
role="presentation"을 가진 엘리먼트는 (오류 케이스를 제외하고) 접근성 트리의 일부가 아닙니다. aria-labelledby나 aria-label을 사용하지 마세요. |
progressbar |
필수 |
progressbar 역할(role)이 HTML progress 엘리먼트에 적용된 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
|
radio |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- HTML
type="checkbox"를 기반으로 하는 경우, label 엘리먼트를 사용하세요.
- 그렇지 않으면,
aria-labelledby를 통해 가시적으로 보이는 콘텐트를 참조시키세요.
|
radiogroup |
필수 |
- 보조 기술 사용자가
radio 버튼 그룹의 목적을 이해하도록 돕는 것이 권장됩니다.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Radio 그룹 설계 패턴을 참고하세요.
|
region |
필수 |
- 스크린리더 사용자가 컨텍스트와 랜드마크의 목적을 이해하도록 도와주세요.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Region 랜드마크 섹션을 참고하세요.
|
row |
내용이 불충분하고
treegrid의 후손이며 행이 focusable한
경우에만 필수
|
row 엘리먼트가 treegrid에서 초점을 얻을 수 있는 경우, 스크린리더는 행으로 탐색하는 경우 행의 전체 콘텐트를 낭독합니다.
이것이 일반적으로 가장 적절한 동작입니다.
하지만, 어떤 상황에서, 셀이 낭독되는 순서를 변경하거나 낭독할 셀을 지정하기위해 aria-labelledby를 사용하여 특정 셀의 낭독을 제외시키는 것이 유리할 수 있습니다.
|
rowgroup |
이름을 지정하지 말것 |
이름 지정이 보조 기술에 의해 지원되지 않습니다. |
rowheader |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
rowheader 역할(role)이 HTML th로부터 적용된 경우, HTML abbr 어트리뷰트가 스크린리더가 table, grid, 또는 treegrid 내의 연관된 cell을 읽을 때에만 낭독되는 이름의 축약 버전을 지정하는데 사용될 수 있습니다.
|
scrollbar |
재량 |
- 이름 지정은 선택적이지만, 잠재적으로 스크린리더 사용자가 scrollbar의 목적을 이해하도록 도움을 줄 수 있습니다. 목적은
scrollbar에 대해 필요한 aria-controls 어트리뷰트를 사용하여 전달될 수 있습니다.
- 가시적으로 보이는 레이블이 존재한다면,
aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
|
search |
권장 |
- 스크린리더 사용자가 컨텍스트와 search 랜드마크의 목적을 이해하도록 도와주세요.
- 가시적으로 보이는 레이블이 존재한다면,
aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
- Search 랜드마크 섹션을 참고하세요.
|
searchbox |
필수 |
searchbox 역할(role)이 HTML input 엘리먼트에 적용된 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
|
separator |
재량 |
- 페이지에 초점을 얻을 수 있는
separator 엘리먼트가 둘 이상 존재하는 경우 권장됩니다.
- 스크린리더 사용자가 컨텍스트와 separator의 목적을 이해하도록 도울 수 있습니다.
- 가시적으로 보이는 레이블이 존재한다면,
aria-labelledby를, 그렇지 않으면 aria-label을 사용하여 이름이 지정됩니다.
|
slider |
필수 |
slider 역할(role)이 HTML input 엘리먼트에 적용된 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
- Slider 설계 패턴과 Slider (Multi-Thumb) 설계 패턴을 참고하세요.
|
spinbutton |
필수 |
textbox 역할(role)이 HTML input 엘리먼트에 적용된 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
- Spinbutton 설계 패턴을 참고하세요.
|
status |
재량 |
일부 스크린리더는 status 엘리먼트의 콘텐트를 낭독하기 전에 status 엘리먼트의 이름을 낭독합니다.
따라서, aria-label은 status 엘리먼트의 부분으로 노출되지 않는 텍스트로 로그 엘리먼트의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다.
aria-label을 사용하는 것은 status 엘리먼트에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, status 엘리먼트의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
|
strong |
금지 |
|
subscript |
금지 |
|
superscript |
금지 |
|
switch |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- HTML
type="checkbox"을 기반으로 하는 경우, label 엘리먼트를 사용하세요.
- 그렇지 않으면,
aria-labelledby를 통해 가시적으로 보이는 콘텐트를 참조시키세요.
|
tab |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
|
table |
필수 |
- HTML
table 엘리먼트를 사용하는 경우, caption 엘리먼트를 사용하세요.
- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
- Table 설계 패턴을 참고하세요.
|
tablist |
권장 |
- 스크린리더 사용자가 컨텍스트와 tablist의 목적을 이해하도록 도와주세요.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Carousel 설계 패턴과 Tabs 설계 패턴을 참고하세요.
|
tabpanel |
필수 |
|
term |
이름을 지정하지 말것 |
term은 일반적으로 role="definition" 엘리먼트에 대한 이름이기 때문에, 용어 자체가 이름을 또 가지면 혼동 될 수 있습니다. |
textbox |
필수 |
textbox 역할(role)이 HTML input나 textarea 엘리먼트에 적용된 경우, HTML label 엘리먼트로 이름이 지정될 수 있습니다.- 그렇지 않으면 가시적으로 보이는 레이블이 존재하는 경우
aria-labelledby를 사용하세요.
- 가시적으로 보이는 레이블이 존재하지 않는 경우
aria-label을 사용하세요.
|
time |
이름을 지정하지 말것 |
이름 지정이 보조 기술에 의해 지원되지 않습니다. |
timer |
재량 |
일부 스크린리더는 timer 엘리먼트의 콘텐트를 낭독하기 전에 timer 엘리먼트의 이름을 낭독합니다.
따라서, aria-label은 timer 엘리먼트의 부분으로 노출되지 않는 텍스트로 timer 엘리먼트의 보이는 콘텐트를 미리 나타내는 방법을 제공합니다.
aria-label을 사용하는 것은 timer 엘리먼트에 aria-label을 지원하지 않는 스크린리더에서는 오프스크린(off-screen) 텍스트가 낭독 될 것이라는 것을 제외하고, timer 엘리먼트의 콘텐트의 오프스크린(off-screen) 텍스트를 제공하는 것과 기능적으로 동일합니다.
|
toolbar |
권장 |
- 페이지에 둘 이상의
toolbar 엘리먼트가 존재하는 경우, 이름 지정은 필수입니다.
- 페이지에 오직 하나의 툴바만 존재하는 경우라도, 보조 기술 사용자가 툴바의 목적을 이해하도록 도와주세요.
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Toolbar 패턴을 참고하세요.
|
tooltip |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label이나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
|
tree |
필수 |
- 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Tree View 설계 패턴을 참고하세요.
|
treegrid |
필수 |
treegrid가 HTML table 엘리먼트에 적용된 경우, 접근 가능한 이름은 표의 caption 엘리먼트로부터 파생될 수 있습니다.- 그렇지 않으면, 시각적으로 보이는 레이블이 존재하는 경우
aria-labelledby를, 그렇지 않으면 aria-label을 사용하세요.
- Treegrid 설계 패턴을 참고하세요.
|
treeitem |
내용이 불충분한 경우에만 필요 |
- 경고!
aria-label나 aria-labelledby를 사용하는 것은 보조 기술에게 후손 콘텐트를 숨길 것입니다.
- 가시적으로 보이는 후손 콘텐트에 의해 이름이 지정되는 것이 이상적입니다.
- 주의: 자식
group 내에 포함된 콘텐트는 자동으로 접근 가능한 이름 계산에서 제외됩니다.
- Tree View 설계 패턴을 참고하세요.
|
유저 에이전트는 잠재적인 이름 지정 방법의 목록을 단계별로 통과하면서 이름을 생성하는 첫 방법을 사용하여 엘리먼트에 대한 접근 가능한 이름 문자열을 구성합니다.
이 알고리즘은 접근 가능한 이름 명세에 정의되어 있습니다.
대략 다음과 같습니다:
aria-labelledby 속성(property)이 있다면 이것이 사용됩니다.
이름이 여전히 비어있다면, aria-label 속성(property)이 있다면 이것이 사용됩니다.
-
이름이 여전히 비어있다면, 호스트-언어별 어트리뷰트나 엘리먼트가 존재한다면 이것이 사용됩니다. HTML의 경우, 엘리먼트에 따라 다음과 같습니다:
type 어트리뷰트가 Button, Submit Button, 또는 Reset Button 상태에 있는 inputvalue 어트리뷰트.type 어트리뷰트가 Image Button 상태에 있는 inputimgareaalt 어트리뷰트. fieldset- 첫 번째 자식
legend 엘리먼트.
- 다른 form 엘리먼트
- 연관된
label 엘리먼트(들).
figure- 첫 번째 자식
figcaption 엘리먼트.
table- 첫 번째 자식
caption 엘리먼트.
이름이 여전히 비어있다면, 자식 콘텐츠로부터 이름 지정을 지원하는 역할(role)을 가진 엘리먼트의 경우, 엘리먼트의 콘텐트가 사용됩니다.
-
마지막으로, 이름이 여전히 비어있다면, 다른 폴백 호스트-언어별 어트리뷰트나 엘리먼트가 존재한다면 이것이 사용됩니다. HTML의 경우, 엘리먼트에 따라 다음과 같습니다:
type 어트리뷰트가 Text, Password, Search, Telephone, 또는 URL 상태에 있는 inputtextareatitle 어트리뷰트. 그렇지 않으면, placeholder 어트리뷰트.type 어트리뷰트가 Submit Button 상태에 있는 input- 단어 "submit"의 지역화 된 문자열.
type 어트리뷰트가 Reset Button 상태에 있는 input- 단어 "reset"의 지역화 된 문자열.
type 어트리뷰트가 Image Button 상태에 있는 inputtitle 어트리뷰트. 그렇지 않으면, 문구 "Submit Query"의 지역화 된 문자열.summary- 단어 "Details".
- 다른 엘리먼트
title 어트리뷰트
마지막 단계는 폴백 메커니즘입니다. 일반적으로 엘리먼트에 레이블을 지정할 때는, 폴백이 아닌 메커니즘 중 하나를 사용하세요.
콘텐트로부터 이름을 계산하는 경우, 유저 에이전트는 아래 기술 된 대로 treeitem과 menuitem의 경우를 제외하고 모든 후손 노드를 단계별로 통과합니다.
그리고, aria-labelledby 어트리뷰트의 참조를 따르는 경우, 마찬가지로 각 참조된 엘리먼트의 트리를 통과합니다.
따라서, 이름 지정 알고리즘은 재귀적입니다.
다음 두 섹션은 알고리즘이 작동하는 방법의 비재귀 및 재귀 예제를 설명합니다.
treeitem 역할(role)에 대한 콘텐트로부터 이름을 계산하는 경우, 자식 group 엘리먼트의 후손 콘텐트는 포함되지 않습니다.
예를 들어, 다음 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 엘리먼트의 후손 콘텐트는 포함되지 않습니다.
따라서, 다음 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>
연결된 label 엘리먼트가 없고 name 어트리뷰트만 있어서 접근 가능한 이름이 없는 input를 가정해보세요 (이렇게 하지 마세요):
<input name="code">
placeholder 어트리뷰트가 있다면, 이름 지정 폴백 메커니즘으로 제공됩니다 (이렇게 하지 마세요):
<input name="code"
placeholder="One-time code">
또한 title 어트리뷰트가 존재하는 경우, 이것이 placeholder 대신 접근 가능한 이름으로 사용되지만, 여전히 폴백입니다 (이렇게 하지 마세요):
<input name="code"
placeholder="123456"
title="One-time code">
또한 label 엘리먼트가 존재하는 경우 (추천), 그것이 접근 가능한 이름으로 사용되고, title 어트리뷰트는 접근 가능한 설명으로 대신 사용됩니다:
<label>One-time code
<input name="code"
placeholder="123456"
title="Get your code from the app.">
</label>
또한 aria-label 어트리뷰트가 존재하는 경우 (보조 기술 사용자에게 명확성을 더해주기 위해서가 아닌 이상 추천되지 않습니다), 그것이 label 엘리먼트를 대체하여 접근 가능한 이름이 될 것입니다:
<label>Code
<input name="code"
aria-label="One-time code"
placeholder="123456"
title="Get your code from the app.">
</label>
또한 aria-labelledby 어트리뷰트가 존재하는 경우, 다른 엘리먼트와 어트리뷰트보다 우위에 섭니다 (aria-label 어트리뷰트는 사용되지 않을 경우 제거 되어야 합니다):
<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>
접근 가능한 이름 계산 알고리즘은 필요할 때 재귀적으로 호출 될 것입니다. aria-labelledby 참조는 알고리즘이 재귀적으로 호출되도록 하고, 콘텐트로부터 접근 가능한 이름을 계산할 때 알고리즘은 각 자식 노드에 대해 재귀적으로 호출됩니다.
이 예에서, 버튼에 대한 레이블은 각 자식 노드로 재귀하여 계산된 결과 휴지통으로 이동
입니다.
<button><img src="bin.svg" alt="휴지통">으로 이동</button>
aria-labelledby 참조를 따를 때, 알고리즘은 무한 루프를 방지하기 위해 동일한 참조를 두 번 따르는 것을 방지합니다.
이 예에서, 버튼에 대한 레이블은 우선 aria-labelledby가 참조하는 부모 엘리먼트를 따라 계산되고, 이후 자식 노드들로부터 그 엘리먼트에 대한 레이블을 계산하여 먼저 button 엘리먼트를 다시 방문하지만 aria-labelledby 참조를 무시하고 대신 aria-label을 사용하고, 이후 다음 자식 (테스트 노드)를 방문하여 계산됩니다. 결과 레이블은 회의 삭제: 일일 상태 보고서
입니다.
<div id="meeting-1">
<button aria-labelledby="meeting-1" aria-label="회의 삭제:">X</button>
일일 상태 보고서
</div>
aria-describedby 속성(property)은 aria-labelledby 속성(property)과 비슷하게 동작합니다.
예를 들어, 버튼은 형태 단락에 의해 설명 될 수 있습니다.
<button aria-describedby="trash-desc">휴지통으로 이동</button>
...
<p id="trash-desc">휴지통의 항목은 30일 후 영구적으로 제거될 것입니다.</p>
설명은 텍스트 문자열로 조정 됩니다. 예를 들어, 설명이 img 엘리먼트를 포함하는 경우, 이미지에 해당하는 텍스트가 계산됩니다.
<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 엘리먼트에 대한 접근 가능한 설명은 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>
HTML에서, table은 aria-label나 aria-labelledby를 사용하여 이름이 지정되고, 자식 caption 엘리먼트는 접근 가능한 설명이 됩니다.
예를 들어, 앞선 제목은 적절한 접근 가능한 이름으로 제공될 수 있고, caption 엘리먼트는 더 긴 설명을 포함할 수 있습니다.
이러한 상황에서, 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 엘리먼트은 figcaption 엘리먼트로부터 접근 가능한 이름을 얻을 수 있지만, 접근 가능한 이름으로 사용되지 않더라도 접근 가능한 설명으로는 사용되지 않습니다. figcaption 엘리먼트가 접근 가능한 설명으로 적절하고, 접근 가능한 이름이 aria-labelledby나 aria-label를 사용하여 지정되는 경우, figcaption은 aria-describedby 어트리뷰트를 사용하여 접근 가능한 설명으로 명시적으로 설정 될 수 있습니다.
<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>
접근 가능한 설명이 aria-describedby 어트리뷰트를 사용하여 또는 주 호스트 언어별 어트리뷰트나 엘리먼트 중 하나를 (예를 들어, table에 대한 caption 엘리먼트) 사용하여 제공되지 않았다면, HTML의 경우 엘리먼트가 title 어트리뷰트를 가지고 있다면 그것이 접근 가능한 설명으로 사용됩니다.
aria-describedby와 함께 가시적으로 보이는 설명이 일반적으로 권장됩니다. 보이지 않는 설명이 필요한 경우, 접근 가능한 설명을 가질 수 있는 HTML 엘리먼트에 대해, title 어트리뷰트가 사용될 수 있습니다.
title 어트리뷰트는 일부 사용자, 특히 hover를 지원하는 포인팅 기기 (예를 들어, 마우스)를 사용하지 않고 스크린리더를 사용하지 않는 정상 시력 사용자에게 접근 가능하지 않을 수 있음을 주의하세요
예를 들어, pattern 어트리뷰트를 사용하여 제한된 입력을 가지는 input 엘리먼트는 예상되는 입력이 무엇인지를 설명하도록 title 어트리뷰트를 사용 할 수 있습니다.
<label> 부품 번호:
<input pattern="[0-9][A-Z]{3}" name="part"
title="부품 번호는 숫자 다음에 대문제 3개가 오는 숫자입니다."/>
</label>
이 경우 title 어트리뷰트는 사용자가 컨트롤에 호버하거나 초점을 줄 때 툴팁으로 사용자에게 보여질 수 있지만, 유저 에이전트가 양식을 검증할 때 input 엘리먼트의 값이 pattern과 일치하지 않는 경우 오류 메세지의 일부로도 보여질 수 있습니다.
다른 예로, 링크는 title 어트리뷰트를 링크를 보다 자세히 설명하는데 사용할 수 있습니다.
<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>
접근 가능한 이름 계산과 같이, 접근 가능한 설명 계산은 테스트 문자열을 생성합니다.
접근 가능한 설명 계산 알고리즘은 이름이나 설명이 계산 여부에 따라 몇 가지 지점을 제외하고 접근 가능한 이름 계산 알고리즘과 동일합니다.
특히, 접근 가능한 설명을 위해 텍스트를 누적할 경우, 알고리즘은 aria-labelledby 대신 aria-describedby를 사용합니다.
유저 에이전트는 잠잭적인 설명 방법의 목록을 단계별로 통과하면서 설명을 생성하는 첫 방법을 사용하여 엘리먼트에 대해 접근 가능한 설명 문자열을 구성합니다.
이 알고리즘은 접근 가능한 이름 명세에 정의되어 있습니다.
대략 다음과 같습니다:
aria-describedby 속성(property)이 있다면 이것이 사용됩니다.
-
설명이 여전히 비어있다면, 호스트 언어별 어트리뷰트나 엘리먼트가 존재한다면, 그것이 접근 가능한 이름으로 이미 사용되지 않았다면, 이것이 사용됩니다. HTML의 경우, 엘리먼트에 다라 다음과 같습니다:
type 어트리뷰트가 Button, Submit Button, 또는 Reset Button 상태에 있는 inputvalue 어트리뷰트.summary- 엘리먼트의 하위 트리.
table- 첫 번째 자식
caption 엘리먼트.
-
마지막으로 설명이 여전히 비어있다면, 다른 호스트 언어별 어트리뷰트나 엘리먼트가 있고, 그것이 접근 가능한 이름으로 이미 사용 되지 않았다면 이것이 사용됩니다. HTML의 경우 이것은 title 어트리뷰트입니다.
네이티브 HTML 양식 엘리먼트들과 달리, 브라우저는 ARIA로 접근 가능하게 만들어진 그래픽 유저 인터페이스(GUI) 컴포넌트에 대한 키보드 지원을 제공하지 않습니다; 작성자는 코드에 키보드 지원을 제공해야 합니다.
이 섹션은 메뉴와 그리드 같은 ARIA 위젯 뿐 아니라 키보드로 운용할 수 있는 툴바와 대화상자 같은 인터랙티브 컴포넌트를 포함하는 웹 페이지의 기능을 만드는 원칙과 방법을 설명합니다.
초점 관리의 기본 사항과 함께, 이 섹션은 키보드 사용자들에게 다른 사람들이 사용할 수 있는 경험 만큼 효율적이고 즐거운 경험을 제공한다는 목표에 대한 지침을 제공합니다.
이 섹션은 다음을 다룹니다:
- ARIA 설계 패턴에 사용되는 초점 이동 규칙의 기본 원칙 이해.
- 가시적 초점 유지, 예측 가능한 초점 이동, 키보드 초점과 선택 상태 구분.
- 컴포넌트 간 초점 이동 관리, 예를 들어 Tab 키와 Shift+Tab 키가 눌렸을 때 초점 이동 방법.
- 초점을 얻을 수 있는 여러 엘리먼트들을 포함하는 컴포넌트 내부에서 키보드 초점 이동 관리, 예를 들어 라디오 그룹, 메뉴, 목록상자, 트리, 그리드와 같이 위젯 내부에 프로그램적으로 초점을 노출하는 두 가지 다른 방식
- 비활성화 된 인터랙티브 엘리먼트가 초점을 얻을 수 있게 만드는 시점 결정
- 보조 기술, 브라우저, 운영 체제의 키보드 명령과의 충동 문제를 방지하는 방법에 대한 지침을 포함하여, 키보드 단축키를 지정하고 표시
ARIA 역할(role), 상태(state), 속성(property)은 마이크로소프트 윈도우, 맥 OS, 그놈을 비롯하여 대중적인 데스스톱 GUI의 GUI 컴포넌트 간에 공유되는 동작과 기능을 모델링 합니다.
마찬가지로, ARIA 설계 패턴은 웹에서 키보드 인터페이스의 쉬운 학습과 효율적인 운영을 용이하게 하는 목적을 가진 공통 규약을 일관되게 포함하여 이 플랫폼들로부터 사용자 기대치와 키보드 규칙을 차용합니다.
웹 페이지가 접근 가능하도록, 모든 인터랙티브 엘리먼트들은 키보드를 통해 운용 가능해야 합니다.
또한, ARIA 설계 패턴에 기술된 공통 GUI 키보드 인터페이스 규칙의 일관된 적용은 특히 보조 기술 사용자에게 중요합니다.
예를 들어, 스크린리더 사용자가 트리를 운용한다고 가정해보세요.
익숙한 시각적 스타일이 사용자가 마우스로 트리 가지를 확장하는 방법을 발견하는데 도움이 되는 것 처럼, ARIA 어트리뷰트는 데스크톱 어플리케이션에서 트리의 소리와 느낌을 제공합니다.
따라서, 스크린리더 사용자는 일반적으로 오른쪽 방향키를 누르는 것이 축소된 노드를 확장할 것이라고 예상할 것입니다.
스크린리더는 엘리먼트가 트리임을 알고 있기 때문에, 초보자에게 운용하는 방법을 지시하는 기능을 가질 수도 있습니다.
마찬가지로, 음성 인식 소프트웨어는 엘리먼트를 트리로 인식하기 때문에 가지를 확장하고 축소하는 기능을 구현할 수 있고, 적절한 키보드 명령을 실행 할 수 있습니다.
이 모든 것들은 트리가 ARIA 트리 패턴에 기술된 대로 GUI 키보드 규약이 구현될 경우에만 가능합니다.
모든 플랫폼에서 주요 키보드 탐색 규칙은 일반적으로 tab과 shift+tab키가 한 UI 컴포넌트에서 다른 컴포넌트로 이동하는 반면 다른 키, 주로 방향키는 여러 초점을 얻을 수 있는(focusable) 엘리먼트들을 포함하는 컴포넌트의 내부로 초점을 이동시킨다는 것입니다.
tab 키를 누를 때 초점이 따르는 경로를 탭 시퀀스 혹은 탭 링이라고 부릅니다.
초점을 얻을 수 있는 여러 엘리먼트들을 포함하는 UI 컴포넌트의 일반적인 예는 라디오 그룹, 탭 목록, 메뉴, 그리드입니다.
예를 들어, 라디오 그룹은 각각이 초점을 얻을 수 있는 여러 라디오 버튼을 포함합니다.
하지만 오직 한 개 라디오 버튼만이 탭 시퀀스에 포함됩니다.
Tab 키를 누른 후 초점은 그룹 내의 라디오 버튼으로 이동하고, 방향키를 누르면 그룹 내의 라디오 버튼 간에 초점이 이동하며, 다시 Tab 키를 누르면 라디오 그룹을 벗어나 탭 시퀀스 내의 다음 엘리먼트로 초점이 이동됩니다.
ARIA 명세는 composite
위젯으로 여러 초점을 얻을 수 있는(focusable) 엘리먼트를 포함하는
개별 UI 컴포넌트를 참조합니다. composite 내에서 초점 이동을 제어하는 프로세스를
초점 관리라고 합니다. 다음은 초점 관리를 보여주는 예제 구현이 포함된
일부 ARIA 설계 패턴입니다:
이 섹션을 완료하기 위한 작업은 issue 217에서 추적됩니다.
키보드로 조작할 경우, 좋은 경험의 두 가지 필수 요소는 키보드 초점의 위치를 쉽게 식별할 수 있고 탐색 키가 눌린 후 초점이 놓인 위치를 예측 할 수 있는 기능입니다.
다음 요인들은 웹 페이지가 사용자에게 이러한 기능을 제공하는 정도에 영향을 줍니다.
- 초점 표시의 가시성: 사용자는 키보드 초첨 표시를 다른 시각적 디자인 기능과 쉽게 구별 할 수 있어야 합니다. 마우스 사용자가 마오스 포인터를 찾기 위해 마우스를 움직이는 것 처럼, 키보드 사용자는 움직임을 보기 위해 탐색 키를 눌러 볼 수 있습니다. 초점 이동에 대한 시각적 변화가 감지하기 어려우면, 많은 사용자들은 초점을 잃어버리고 조작 할 수 없게 됩니다. 작성자들은 브라우저에서 제공되는 기본 초점 표시기를 사용하는 것이 좋습니다. 기본값을 재정의하려면 다음을 고려하세요:
- 어떤 것들은... 고대비 모드에서 색상과 그라디언트가 사라질 수 있습니다.
- 사용자는 초첨 vs 선택 그리고 이중 초점의 인식에 기술된 대로 초점과 선택 사이를 쉽게 구별할 수 있어야 합니다. 특히, 선택된 엘리먼트들을 포함하는 컴포넌트가 초점을 포함하고 있지 않은 경우.
- ... 다른 추가 고려 사항들 ...
- 초점의 지속성: 유저 인터페이스 내에 활성화 된 컴포넌트가 항상 있고 (document.activeElement가 null이 아니거나 body 엘리먼트가 아닌) 활성 엘리먼트는 시각적인 초점 표시기를 가져야 하는 것이 필수적입니다. 작성자는 현재 활성 엘리먼트에 영향을 주는 이벤트를 관리하여 초점이 여전히 표시되고 논리적으로 이동하도록 해야 합니다. 예를 들어, 사용자가 대화 상자를 닫거나 목록에서 항목을 삭제하는 것과 같이 파괴적인 작업을 수행하는 경우, 활성 엘리먼트는 숨겨지거나 DOM에서 제거될 것입니다. 이러한 이벤트가 대화상자를 발생시킨 버튼이나 삭제된 항목 다음의 목록 항목으로 초점을 설정하지 않으면, 브라우저는 body 엘리먼트로 초점을 설정하여, 사실상 유저 인터페이스 내에서 초점을 잃게 만듭니다.
-
이동의 예측 가능성: 키보드 인터페이스의 사용성은 사용자가 탐색 키를 누른 이후 초점이 어디로 놓일 지 얼마나 손쉽게 추측할 수 있는가에 따라 크게 영향을 받습니다.
예측 가능성을 최적화 하는 몇 가지 가능한 접근 방식은 다음과 같습니다:
-
페이지 언어의 읽기 순서와 일치하는 패턴으로 초점을 이동시킵니다. 예를 들어, 왼쪽에서 오른쪽 방향의 언어에서는 왼쪽에서 오른쪽으로, 위에서 아래로 초점이 이동하는 탭 시퀀스를 만드세요.
-
다른 섹션으로 초점을 이동시키기 전에 페이지의 섹션의 모든 엘리먼트를 탭 시퀀스에 포함시키세요. 예를 들어,
왼쪽 사이드 바, 가운데 영역, 오른쪽 사이드 바에 콘텐트가 있는 여러 열을 가진 페이지에서, 가운데 열의 첫 번째 초점을 얻을 수 있는(focusable) 엘리먼트로 초점을 이동시키기 전에 왼쪽 사이드 바의 모든 엘리먼트를 포함하는 탭 시퀀스를 만드세요.
-
탭 시퀀스에서 연속된 두 엘리먼트간의 거리가 중요한 경우, 뒤로 돌아가는 것으로 인지되는 움직임을 피하세요.
예를 들어, 왼쪽에서 오른쪽 방향의 언어를 가진 페이지에서, 메인 콘텐트의 우측 하단에 있는 마지막 엘리먼트에서 왼쪽 사이드바의 상위 엘리먼트로 점프하는 것은, 특히 시야가 좁은 사용자에게, 예측하기 어렵고 따라가기가 더 어렵습니다.
-
사이트 전체적으로 일관적인 패턴을 따르세요.
유사한 페이지에 유사한 초점 이동 패턴이 있을 때 키보드 경험은 더 예측 가능합니다.
- 다음과 같은 경우를 제외하고 페이지가 로드 될 때 초기 초점을 설정하지 마세요:
- 페이지가 로드 된 직후 거의 모든 사용자가 사용하는 단일의 주요 기능만을 제공하는 경우
- 어느 사용자든 페이지를 자주 사용할 가능성이 높은 경우
경우에 따라, 동시에 한 페이지에 두 엘리먼트가 초점을 가지는 것처럼 나타날 수 있습니다.
예를 들어, 다중 선택 목록상자에서, 옵션 항목이 선택되는 경우 회색으로 표시 될 것입니다.
그러나, 초점 표시기는 선택 될 수 있는 다른 옵션 항목으로 여전히 이동 될 수 있습니다.
마찬가지로, 사용자가 탭 목록에서 탭을 활성화시키면, 선택된 상태가 탭에 설정되고 시각적 모양이 변경됩니다.
하지만 사용자는 탭이 선택 된 모양과 상태를 유지하면서 페이지의 다른 곳으로 초점 포시기를 이동하면서 여전히 탐색 할 수 있습니다.
초점과 선택은 상당히 다릅니다.
키보드 사용자의 관점에서, 초점은 마우스 포인터와 같은 포인터 입니다; 탐색 경로를 추적합니다.
초점 포인트는 항상 하나 뿐이며 모든 작업은 초점 포인트에서 이루어집니다.
반면에, 선택은 목록상자, 트리, 탭 목록과 같은 일부 위젯에서 수행될 수 있는 작업입니다.
위젯이 단 한 개 선택만 지원하는 경우, 단 한 개 항목만 선택 가능하고 초점이 위젯 내부를 이동할 때 선택 된 상태가 단순히 초점을 따라가는 경우가 많습니다.
즉, 일부 위젯에서, 초점 이동이 선택 작업을 수행 할 수도 있습니다.
하지만, 위젯이 다중 선택을 지원하는 경우, 선택된 상태는 한 개 이상이 될 수 있고, 초점 이동에 대한 키는 선택을 수행하지 않습니다.
일부 다중 선택 위젯은 초점 이동과 선택 변경 키 명령을 지원하지만, 이러한 키는 일반 탐색 키와는 다릅니다.
마지막으로 초점이 선택된 엘리먼트를 포함하는 위젯을 떠날 때, 선택 된 상태는 지속됩니다.
개발자 관점에서, 차이점은 간단합니다 -- 초점을 얻은 엘리먼트는 활성 엘리먼트 (document.activeElement)입니다.
선택된 엘리먼트는 aria-selected="true"를 가지는 엘리먼트입니다.
초점과 선택 된 상태와 관련하여, 디자이너와 개발자에게 중요한 고려사항은 다음과 같습니다:
- 시각적 초점 표시기는 항상 표시되어야 합니다.
- 선택된 상태는 초점 표시기와 시각적으로 구별되어야 합니다.
탭 목록이나 단일 선택 목록상자와 같이 단 하나의 엘리먼트만 선택 될 수 있는 복합 위젯에서, 초점 이동은 초점을 얻은 엘리먼트가 선택 된 엘리먼트가 되게 할 수 있습니다. 이를 초점을 따라 선택 되도록 하는 것이라고 합니다. 초점을 따라 선택 되도록 하는 것은 종종 사용자에게 유익하지만, 일부 상황에서는 접근성에 매우 해롭습니다.
예를 들어, 탭 목록에서, 선택 상태는 패널이 노출되어 있음을 나타내는데 사용 됩니다.
따라서, 탭 목록에서 선택이 초점을 따르는 경우, 한 탭에서 다른 탭으로 초점 이동은 자동으로 노출되는 패널을 변경시킵니다.
DOM에 패널의 콘텐츠가 존재한다면, 새로운 패널의 노출은 거의 즉시 이루어집니다.
6개 탭 중 4번째 탭을 노출시키기 원하는 키보드 사용자는 오른쪽 키를 3번 빠르게 눌러 그렇게 할 수 있습니다.
그리고 탭의 레이블을 탐색하여 인식하는 스크린리더 사용자는 대기 시간 없이 전체 탭 목록을 효율적을 읽을 수 있습니다.
반면에, 새로운 패널을 노출시키는 것이 네트워크 요청을 발생시키고 페이지가 갱신(refresh) 될 수 있는 경우, 초점을 따라 자동으로 선택되게 하는 것은 키보드와 스크린리더 사용자의 경험을 파괴할 수 있습니다. 이 경우, 네 번째 탭을 표시하거나 탭 목록을 읽는 것은 사용자가 각 초점의 이동과 함께 상당한 지연 시간을 경험하기 때문에 지루하고 시간을 낭비하는 작업이 됩니다. 게다가, 새 탭이 페이지를 갱신하면 사용자는 새 페이지가 로드 될 때까지 기다려야 할 뿐만 아니라 탭 목록으로 초점을 다시 보내야 합니다.
선택이 초점을 따르지 않는 경우, 사용자는 Enter나 Space 키를 눌러 선택 된 엘리먼트를 변경합니다.
6.1 핵심 키보드 탐색 규칙 섹션에 설명된 대로, 모든 대화형 UI 컴포넌트는 키보드를 통해 접근 할 수 있어야 합니다. 이것은 탭 시퀀스에 그것들을 포함시키거나 탭 시퀀스에 있는 컴포넌트에 (예를 들어, 복합 컴포넌트의 일부) 접근 할 수 있도록 함으로써 가장 잘 달성됩니다. 이 섹션에서는 탭 시퀀스를 만들고 관리하는 방법을 다루고, 이후 섹션에서는 컴포넌트 내에 포함된 초점을 얻을 수 있는(focusable) 엘리먼트가 키보드 접근 가능하도록 하는 내용을 다룹니다.
[HTML] tabindex와 [SVG2] tabindex 어트리뷰트는 탭 시퀀스에 엘리먼트를 추가하거나 제거하는데 사용될 수 있습니다.
tabindex 값은 탭 시퀀스 순서에도 영향을 미칠 수도 있지만, 그 목적으로 tabindex를 사용하지 않는 것을 강력히 권합니다.
HTML 에서, 웹 페이지의 기본 탭 시퀀스는 maxOS에서는 form 엘리먼트만 포함하는 것을 제외하고, 링크와 form 엘리먼트만 포함합니다.
macOS 시스템 환경 설정에는 탭 키가 모든 초점을 얻을 수 있는(focusable) 엘리먼트로 초점을 이동할 수 있는 키보드 설정이 포함되어 있습니다.
탭 시퀀스의 기본 엘리먼트 순서는 DOM의 엘리먼트 순서입니다.
DOM 순서는 또한 스크린리더 낭독 순서를 결정합니다.
이는 6.2 식별 가능하고 예측 가능한 키보드 초점에 기술된 대로 키보드 탭 시퀀스와 스크린리더 낭독 순서를 정렬되고, 논리적이고, 예측 가능하게 유지하는데 중요합니다.
읽기 순서와 함께 정렬을 유지하면서 탭 시퀀스 순서를 조작하는 모든 브라우저에서 현재 사용 가능한 가장 강력한 방법은 DOM에서 엘리먼트를 재정렬 하는 것입니다.
tabindex 어트리뷰트 값은 다음 효과를 가집니다.
- tabindex 가 없거나 유효한 값을 가지지 않는 경우
-
엘리먼트는 기본 초점 동작을 가집니다.
HTML에서, form 컨트롤과 HREF 어트리뷰트를 가진 앵커만 탭 시퀀스에 포함됩니다.
- tabindex="0"
- 엘리먼트 DOM에서의 위치에 따라 탭 시퀀스에 포함됩니다.
- tabindex="-1"
- 엘리먼트는 탭 시퀀스에 포함되지 않지만 element.focus()로 초점을 얻을 수 있습니다.
- tabindex="X", X는 1 <= X <= 32767 범위의 정수
-
이 값을 사용하지 않는 것을 강력히 권합니다.
엘리먼트는 tabindex의 값에 따라 탭 시퀀스에 배치됩니다.
tabindex 값이 0인 엘리먼트와 기본적으로 초점을 얻을 수 있는(focusable) 엘리먼트들은 tabindex 값이 1 이상인 엘리먼트 이후 시퀀스에 있게 됩니다.
6.1 핵심 키보드 탐색 규칙 섹션에 기술된 대로, 탭 시퀀스는 단 하나의 복합 UI 컴포넌트의 초점을 얻을 수 있는(focusable) 엘리먼트만 포함해야 합니다.
일단 복합 컴포넌트가 초점을 포함하면, Tab과 Shift + Tab 이외의 키들로 사용자가 복합 컴포넌트의 초점을 얻을 수 있는(focusable) 엘리먼트 간에 초점 이동을 할 수 있게 합니다.
작성자는 복합 컴포넌트 내부에서 초점을 이동시키는 키를 자유롭게 선택할 수 있지만, 3. 설계 패턴과 위젯에 설명 된 대로 공통 GUI 운영 체제의 유사한 컴포넌트와 동일한 키 바인딩을 사용하는 것을 강력히 권합니다.
Tab 키 이벤트의 결과로 초점을 얻을 때 복합 컴포넌트 내 초점을 얻을 위치에 대한 규칙은 복합 컴포넌트의 유형에 따라 다릅니다. 일반적으로 다음 중 하나입니다.
-
마지막으로 복합 컴포넌트가 초점을 포함했을 때 초점을 가진 엘리먼트.
또는, 복합 컴포넌트가 초점을 아직 포함하지 않았다면, 첫 번째 엘리먼트.
일반적으로 이 패턴을 사용하는 위젯은 grid 및 tree grid를 포함합니다.
-
선택 된 엘리먼트. 또는 선택 된 엘리먼트가 없을 경우, 첫 번째 엘리먼트.
일반적으로 이 패턴이 구현되는 위젯은 라디오 그룹, 탭, 목록상자, 트리를 포함합니다.
참고: 라디오 그룹의 경우, 이 패턴은 체크 된 (checked) 라디오 버튼을 가리킵니다; 선택 된 (selected) 상태는 라디오 버튼에 대해 지원되지 않습니다.
-
첫 번째 엘리먼트.
일반적으로 이 패턴을 따르는 컴포넌트는 메뉴바와 툴바를 포함합니다.
다음 섹션에서는 복합 엘리먼트에서 초점을 관리하기 위한 두가지 전략: 이동(roving) tabindex 생성과 aria-activedescendant 속성(property) 사용에 대해 설명합니다.
복합 UI 컴포넌트에서 초점을 관리하기 위해 이동 tabindex를 사용하는 경우, 탭 시퀀스에 포함 되어야 할 엘리먼트는 0 값의 tabindex를 가지고 복합 컴포넌트의에 포함 된 다른 모든 초점을 얻을 수 있는(focusable) 엘리먼트는 -1 값의 tabindex를 가집니다.
이동 tabindex 전략에 대한 알고리즘은 다음과 같습니다.
- 컴포넌트 컨테이너가 로드되거나 생성될 때, 초기에 탭 시퀀스에 포함되는 엘리먼트에
tabindex="0"를 설정하고 포함 된 다른 모든 초점을 얻을 수 있는(focusable) 엘리먼트에 tabindex="-1"을 설정하세요.
-
컴포넌트가 초점을 포함하고 사용자가 컴포넌트 내에서 방향키와 같이 초점을 이동시키는 탐색 키를 누를 때:
tabindex="0"를 가진 엘리먼트에 tabindex="-1"를 설정하세요.- 키 이벤트의 결과로 초점을 얻게 될 엘리먼트에
tabindex="0"를 설정하세요.
tabindex="0"를 가진 엘리먼트에 element.focus()로 초점을 설정하세요.
-
설계가 다음에 사용자가 Tab이나 Shift+Tab으로 복합 컴포넌트 내로 초점을 이동시킬 때 특정 엘리먼트가 초점을 얻도록 요구하는 경우, 복합 컴포넌트가 초점을 잃을 때 그 대상 엘리먼트가
tabindex="0"를 가지고 있는지 확인하세요.
그렇지 않으면, 대상 엘리먼트에 tabindex="0"를 설정하고 이전에 tabindex="0"를 가졌던 엘리먼트에 tabindex="-1"을 설정하세요.
초점을 관리하기 위해 aria-activedescendant 보다 이동 tabindex 사용의 한 가지 이점은 유저 에이전트가 새롭게 초점을 얻은 엘리먼트를 뷰(view)로 스크롤 한다는 것입니다.
컴포넌트 컨테이너가 aria-activedescendant 속성을 지원하는 ARIA 역할(role)을 가지는 경우, tabindex 어트리뷰트를 관리하고 컨테이너 내에 초점을 얻을 수 있는(focusable) 엘리먼트 간에 DOM 초점을 이동시킬 필요가 없습니다.
대신, 컨테이너 엘리먼트만 탭 시퀀스에 포함되면 됩니다. 컨테이너가 DOM 초점을 가지는 경우, 컨테이너의 aria-activedescendant 값은 위젯에서 활성화 되는 엘리먼트를 보조 기술에 알려줍니다.
보조 기술은 DOM 초점이 aria-activedescendant 속성(property)를 가진 엘리먼트에 있다 하더라도 활성화 된 것으로 참조되는 엘리먼트를 초점을 얻은 엘리먼트라고 간주할 것입니다.
그리고, aria-activedescendant 값이 변경될 때, 보조 기술은 DOM 초점이 실제로 이동될 때 받는 것과 동일한 초점 변경 이벤트를 받을 것입니다.
초점 관리의 aria-activedescendant 사용 방법 단계는 다음과 같습니다.
- aria-activedescendant를 지원하는 역할(role)을 가진 컨테이터 엘리먼트가 로드되거나 생성될 때, 다음을 보장하세요:
- 컨테이너 엘리먼트가 6.5 컴포넌트 간 키보드 탐색 (탭 시퀀스)에 기술된 대로 탭 시퀀스에 포함되거나, 이동 tabindex를 구현하는 복합 컴포넌트의 초점을 얻을 수 있는(focusable) 엘리먼트입니다.
-
IDREF가 위젯이 초점을 받을 때 컨테이너 내의 활성으로 식별되어야 하는 엘리먼트의 ID인
aria-activedescendant="IDREF"가집니다.
참조 된 엘리먼트는 아래 설명된 DOM 관계 요구 사항을 충족해야 합니다.
- 컨테이너 엘리먼트가 DOM 초점을 얻을 때, 활성 엘리먼트에 시각적 초점 표시기를 그리고 활성 엘리먼트가 뷰(view) 안으로 스크롤 되도록 보장하세요.
- 복합 위젯이 초점을 포함하고 사용자가 위젯 내에서 방향키와 같은 초점을 이동하는 탐색 키를 누를 때:
- 보조 기술에 활성으로 보고되어야 하는 엘리먼트를 참조하도록 컨테이너에 aria-activedescendant의 값을 변경시킵니다
- 필요하다면, 시각적 초점 표시기를 이동시키고 뷰(view) 안으로 활성 엘리먼트를 스크롤 되게 하세요.
-
설계가 다음에 사용자가 Tab이나 Shift+Tab으로 복합 컴포넌트 내로 초점을 이동시킬 때 특정 엘리먼트가 초점을 얻도록 요구하는 경우, 컨테이너가 초점을 잃을 때 aria-activedescendant가 그 대상 엘리먼트를 가리키고 있는지 확인하세요.
그렇지 않으면, aria-activedescendant를 대상 엘리먼트를 가리키도록 설정하세요.
aria-activedescendant에 대한 명세는 aria-activedescendant 어트리뷰트를 가진 초점을 얻은 엘리먼트와 어트리뷰트 값에 의해 활성으로 참조되는 엘리먼트 간의 DOM 관계에 중요한 제한 사항을 둡니다.
다음 세 가지 조건 중 하나가 충족되어야 합니다.
- 활성으로 참조 된 엘리먼트는 초점을 얻은 참조 하는 엘리먼트의 DOM 후손입니다.
- 초점을 얻은 참조 하는 엘리먼트는 aria-owns 속성(property)에 활성으로 참조 되는 엘리먼트의 ID를 포함하도록 지정된 값을 가집니다.
- 초점을 얻은 엘리먼트가 combobox, textbox, 또는 searchbox 역할(role)을 가지고 있고 aria-activedescendant를 지원하는 역할(role)을 가지면서 다음 중 하나에 해당하는 엘리먼트를 참조하는 aria-controls 속성(property)을 가집니다:
- 활성으로 참조 된 엘리먼트가 제어 엘리먼트의 후손이거나
- 제어 엘리먼트는 활성으로 참조되는 엘리먼트의 ID를 포함하는 aria-owns 속성(property)에 지정된 값을 가집니다.
기본적으로 비활성화 된 HTML input 엘리먼트는 탭 시퀀스에서 제거됩니다.
대부분의 상황에서, 일반적인 예상은 비활성화 된 인터랙티브 엘리먼트는 초점을 얻을 수 없다는 것입니다.
하지만, 비활성화 된 엘리먼트가 초점을 얻을 수 있는 것이 일반적인 상황이 있습니다, 특히 복합 위젯 내부에서.
예를 들어, 3.15 Menu or Menu bar 패턴에서 보여지는 것처럼, 비활성화 된 항목이 방향키로 메뉴를 탐색할 때 초점을 얻을 수 있습니다.
비활성화 된 엘리먼트에서 초점 가능성을 제거하는 것은 사용자에게 장점과 단점을 모두 제공할 수 있습니다.
키보드 사용자가 비활성화 된 엘리먼트를 건너 뛰는 것을 허용하는 것은 일반적으로 작업을 완료하는데 필요한 키 누름 회수를 줄입니다.
하지만, 비활성화 된 엘리먼트로의 이동으로부터 초점을 차단하는 것은 초점 이동을 통해 "보는" 스크린리더 사용자에게 해당 엘리먼트의 존재를 숨기게 될 수 있습니다.
작성자는 비활성화 된 엘리먼트의 초점 가능성에 대해 일관된 규칙을 채택하도록 권장됩니다.
이 지침의 예는 일반적인 사례를 반영하고 우선순위를 조정하려고 시도하는 다음 규칙을 채택합니다.
- 활성화 되었을 때 탭 시퀀스에 있는 엘리먼트의 경우, 비활성화 될 때 탭 시퀀스에서 제거합니다.
-
다음 복합 위젯 엘리먼트의 경우, 비활성화 될 때 초점을 얻을 수 있도록 유지합니다:
-
툴바에 포함 된 엘리먼트의 경우, 발견 가능성(discoverability)이 중요하다면 초점을 얻을 수 있도록 유지합니다. 이 판단에 도움이 되는 두 가지 예가 있습니다.
-
목록의 항목을 이동시키거나, 제거하거나, 추가하기 위한 버튼을 가지는 툴바가 "위", "아래", "추가", "제거" 버튼을 포함합니다.
목록의 첫 번째 항목이 선택 된 경우 "위" 버튼이 비활성화 되고 초점 가능성이 제거됩니다.
"아래" 버튼의 존재가 주어졌다면, "위" 버튼의 발견 가능성(discoverability)은 문제 되지 않습니다.
-
편집기의 툴바는 클립보드가 비어있거나 기능이 클립보드의 현재 콘텐츠에 적합하지 않다면 비활성화 되어있는 특별한 스마트 기능 세트를 포함합니다.
기능을 발견할 수 있는 것이 주로 그것들이 툴바에 존재하는 가를 통해 이루어지는 경우 비활성화 된 버튼이 초점을 얻을 수 있도록 유지하는 것이 도움이 될 수 있습니다.
비활성화 된 엘리먼트를 키보드 초점 경로에 포함시키는 것의 영향을 완화시키는 한 가지 설계 기법은 6.9 키보드 단축키에 기술 된 대로 적절한 단축키를 사용하는 것입니다.
다음의 키 할당은 전통적으로 연관된 기능이 적절한 모든 컨텍스트에서 사용될 수 있습니다.
Windows와 Linux 플램폼과 관련 된 할당은 macOS에서 실행되는 브라우저에서 구현되고 사용될 수 있지만,
macOS 기기에서 실행되는 브라우저에서 macOS 할당으로 그것들을 대체하는 것은 그 사용자들에 대해 키보드 인터페이스를 보다 쉽게 찾게 할 수 있고 직관적으로 만들 수 있습니다.
경우에 따라, 시스템이나 브라우저 키보드 충돌을 방지하는데 도움이 될 수도 있습니다.
효과적으로 설계 된 경우, 엘리먼트에 초점을 주거나, 위젯을 활성화 시키는 키보드 단축키는 페이지나 사이트의 자주 사용되는 기능의 사용성을 극적으로 향상시킬 수 있습니다.
이 섹션은 다음을 포함하여 효율성에 가장 큰 영향을 미치는 키보드 단축키 설계와 구현 요소에 대해 설명합니다:
- 키보드 단축키가 키보드 인터페이스를 확장시키는 방법과 특정 단축키가 초점을 이동시키는지, 기능을 수행하는지, 혹은 둘 모두인지 여부에 대한 이해.
- 키 할당과 보조 기술, 브라우저, 운영 체제와의 할당 충돌 방지.
- 키 할당 노출과 문서화.
이 섹션은 키보드 단축키를 할당할 엘리먼트 및 기능과 각 단축키에 제공할 동작을 결정할 때 다음 요소에 대해 설명합니다:
- 탐색을 통한 발견 보장; 키보드 단축키는 표준 키보드 접근을 대체하는 것이 아니라 향상시키는 것입니다.
-
다음 동작 중 효과적인 것을 선택:
- 탐색: 엘리먼트로 초점 이동.
- 활성화: 초점을 가지지 않고 보이지 않을 수도 있는 엘리먼트와 연관된 작업 수행.
- 탐색 및 활성화: 엘리먼트로 초점을 이동하고 그것을 활성화.
- 효율성(efficiency)과 인지 부하(cognitive load)의 균형: 단축키가 없으면 효율성이 저하될 수 있는 반면 너무 많은 단축키는 인지 부하를 증가시키고 경험을 혼잡하게 만들 수 있습니다.
단축키를 할당하기 전에, 기능(feature)과 단축키가 할당되는 기능(function)이 키보드 단축키 없이도 접근 가능함을 보장하는 것이 중요합니다.
다시 말해, 키보드 단축키에 대한 대상이 될 수 있는 모든 엘리먼트는 다음에 설명된 방법을 사용하여 키보드를 통해 초점을 얻을 수 있어야 합니다:
탐색을 통한 접근에 대한 대체로 키보드 단축키를 사용하지 마세요.
이것은 다음의 이유로 전체 키보드 접근에 필수적입니다:
- 기능을 만들고 단축키를 쉽게 찾을 수 있게 하는 주요 수단이 대상 엘리먼트가 초점을 얻을 수 있게 하고 엘리먼트 자체에 키 할당을 표시하도록 하는 것입니다.
- 키보드를 사용하는 사람들이 인터페이스를 사용하는 데 필요한 키를 학습하기 위해 문서를 읽어야 하는 경우, 인터페이스는 기술적으로는 일부 접근성 표준을 충족할 수 있지만 실제로는 그러한 문서가 존재한다는 사실을 알고 있고 가용한 추가 시간이 있으며, 필요한 정보를 기억할 수 있는 능력을 가진 비교적 적은 수의 사람만이 접근할 수 있습니다.
- 키보드 인터페이스에 의존하는 모든 장치가 키보드 단축키를 지원할 수 있는 것은 아닙니다.
다음 규칙은 키보드 단축키에 대한 가장 유리한 동작을 식별하는데 도움이 될 수 있습니다.
-
기본 목표가 탐색을 보다 효과적으로 만드는 것인 경우, 예를 들어 사용자가 Tab이나 방향키를 눌려야 하는 횟수를 줄이는 것인 경우 초점을 이동시키세요.
이 동작은 일반적으로 텍스트 상자, 툴바 또는 목록상자, 트리, 그리드, 메뉴바와 같은 복합 컴포넌트에 단축키를 할당 할 경우 예상됩니다.
이 동작은 또한 메인 콘텐츠나 complementary 랜드마크 섹션과 같은 페이지의 섹션으로 초점을 이동하는데에도 유용합니다.
- 기능의 대상 콘텍스트가 초점을 포함하는 콘텍스트 인 경우 초점 이동 없이 엘리먼트를 작동 시키세요. 이 동작은 명령 버튼 및 메뉴를 통해서 접근 가능한 "저장" 옵션 항목과 같이 보이지 않는 엘리먼트에 연관 된 기능에 가장 일반적입니다. 예를 들어, 초점이 목록상자의 옵션 항목에 있고 툴바가 옵션 항목을 이동시키고 제거하는 버튼을 포함하는 경우, 사용자가 툴바 내 버튼 중 하나에 대한 단축 키를 누를 때 목록상자에 초점을 유지하는 것이 가장 좋습니다. 이 동작은 수행 된 작업의 확인을 제공하고 여러 명령을 수행하는 것을 더 효율적으로 만들 수 있기 때문에 스크린리더 사용자에게 특히 중요할 수 있습니다. 예를 들어 스크린리더 사용자가 "위" 버튼에 대한 단축키를 누를 때, 사용자는 여전히 초점을 가지고 있기 때문에 목록의 옵션 항목의 새로운 위치를 들을 수 있습니다. 마찬가지로, 사용자가 옵션 항목을 삭제하는 단축키를 누를 때,
사용자는 목록의 다음 옵션 항목을 들을 수 있고 즉시 다시 삭제 단축키를 누를지를 결정할 수 있습니다.
-
단축키 대상이 단일 기능을 가지고 그 기능의 컨텍스트가 대상과 동일할 경우 초점을 이동하고 활성화 시키세요.
이 동작은 단축키가 메뉴나 대화상자를 여는 버튼이나, 체크상자, 내비게이션 링크나 버튼에 할당 될 경우 일반적입니다.
이 섹션에 대한 초안 콘텐트 작업은 issue 219에서 추적됩니다.
키보드 인터페이스를 설계할 때 첫 번째 목표는 기본 키보드 내비게이션 지원만으로 간단하고, 효율적이며, 직관적인 조작입니다. 키보드 인터페이스의 기본 조작이 비효율적인 경우, 키보드 단축키를 구현하여 최적화 되지 않은 레이아웃이나 명령 구조와 같은 근본적인 설계 이슈에 대한 보완을 위한 시도하는 것은 사용자 불만을 줄일 수 없을 것입니다. 이것의 실질적인 의미는, 대부분의 잘 설계된 유저 인터페이스에서는 최적화 된 사용성을 만들기 위해 키보드 단축키를 통해 접근 할 수 있어야 하는 기능의 비율이 높지 않다는 것입니다. 많은 단순한 유저 인터페이스에서, 키보드 단축키는 완전히 불필요할 수 있습니다. 그리고, 키보드 단축키가 너무 많은 유저 인터페이스에서는, 가장 유용한 단축키를 기억하기 어렵게 만드는 인지 부하를 발생시킵니다.
키보드 단축키를 할당을 결정할 때 다음 사항을 고려하세요:
- 작성 예정...
할당할 단축키를 선택할 때 고려해야 할 많은 요소들이 있습니다.
- 니모닉(예를 들어, "저장"을 위해 Control + S)을 사용하거나 논리적 혹은 공간적 패턴을 따라 학습하고 기억하기 쉽게 만듦
- 사용 가능한 키와 동작 방식의 차이, 그리고 니모닉에 영향을 줄 수 있는 언어 고려사항을 포함하여 인터페이스를 지역화
- 보조 기술, 브라우저, 운영 체제에서 사용되는 키 할당과의 충돌 방지 및 관리
학습과 기억을 지원하는 단축키 체계를 설계하는 방법은 이 지침의 범위를 벗어납니다.
단축키 체계가 광범위 하지 않은 이상, 브라우저와 같은 일반적인 데스크탑 소프트웨어에서 익숙한 개념을 모방하는 것으로 충분합니다.
마찬가지로 지역화가 중요하지만, 이를 해결하는 방법을 설명하는 것은 그 토픽을 전문으로 하는 다른 리소스에 맡깁니다.
이 섹션의 나머지 부분에서는 키 할당 충돌과 관련된 요구 사항과 우려 사항을 조정하는 지침을 제공합니다.
일반적으로 키 할당은 사용자의 운영 체제, 브라우저, 보조 기술의 기능에 할당 된 키와 충돌하지 않는 경우가 이상적입니다.
충돌은 사용자에게 필수적인 기능에 대한 유효한 접근을 차단할 수 있고, 충돌의 더할 수 없이 나쁜 상황은 사용자를 가두어 버릴 수 있습니다.
동시에, 의도적인 충돌이 유용한 상황도 있습니다.
그리고 방대한 운영 체제, 브라우저, 보조 기술 키를 감안할 때, 일부 충돌이 존재하지 않는 다는 것은 거의 불가능합니다.
따라서 의도적이든 알려지지 않았든, 충돌의 영향을 완화하는 전략을 채택하는 것도 중요합니다.
Note
다음 섹션에서, meta키는 Windows 호환 키보드의 Windows와 MacOS 호환 키보드의 Command키를 가리킵니다.
어플리케이션 및 창 관리, 디스플레이 및 사운드 제어와 같은 시스템 수준 기능을 수행하는 키와의 충돌을 방지하는 것이 중요합니다. 일반적으로, 다음과 같은 유형의 할당을 자제함으로써 이를 달성 할 수 있습니다.
- 임의의 보조 키(modifier key) + Tab, Enter, Space, Escape 중 하나.
- Meta 키 + 다른 단일 키(single key) (예외가 있지만, 이 키들은 운영체제 버전에 따라 변경될 수 있으므로 위험할 수 있습니다.).
- Alt + 기능 키.
또한, 브라우저를 포함하여 대부분의 어플리케이션이 일반적으로 지원하는 몇 가지 중요한 어플리케이션 수준 기능이 있습니다.
다음이 포함됩니다:
- 확대
- 복사/붙여넣기
- ... to be continued ...
보조 기술은 통틀어 수천 개의 키 할당을 취했지만 충돌을 피하는 것은 비교적 쉽습니다.
이는 보조 기술이 운영 체제 및 어플리케이션과의 충돌을 피하는 키 할당 체계를 개발해야 했기 때문입니다.
특정 키를 키 명령을 고유하게 정의하는 보조 키로 가로채는 방식으로 이를 수행합니다.
예를 들어, 많은 보조 기술들이 보조 키로 Caps Lock를 사용합니다.
다음 유형의 할당을 피하여 보조 기술 키 충돌을 피하세요.
- Caps Lock + 다른 키 조합.
- Insert + 다른 키 조합.
- Scroll Lock + 다른 키 조합.
- macOS only: Control+Option + 다른 키 조합.
브라우저 키보드 체계에는 상당한 유사성이 있지만 체계 내의 패턴은 동질적이지 않습니다. 따라서 브라우저 키 할당과의 충돌을 피하는 것이 더 어렵습니다. 충돌의 영향은 거의 모든 기능 -- 키보드 접근 가능한 메뉴와 키보드 단축키에 대한 두 가지 경로를 사용할 수 있기 때문에 다소 완화되지만, 많이 사용되는 기능에 대한 단축키와의 충돌을 피하는 것이 중요합니다. 다음 단축키와의 충돌을 방지하기 위해 각별히 주의하세요:
- 주소 또는 위치바
- 알림 바
- 페이지 새로 고침
- 북마크와 히스토리 기능
- 기능 찾기
키 충돌을 피하는 것이 일반적으로 바람직하지만, 브라우저 기능과 의도적으로 충돌하는 것이 적절하거나 심지어 바람직한 상황이 있습니다.
다음 조건의 조합이 유발하는 경우 발생할 수 있습니다:
- 웹 어플리케이션에는 브라우저 기능과 유사한 자주 사용되는 기능이 있습니다.
- 사용자가 종종 웹 어플리케이션 기능을 실행하려고 합니다.
- 사용자가 브라우저 기능을 거의 실행하지 않습니다.
- 브라우저 기능에 대한 효율적인 대체 경로가 있습니다.
예를 들어, 초점이 편집기에 있을 경우 사용 가능한 저장 키를 생각해보세요. 대다수의 브라우저가 ... to be continued ...
그리드 또는 테이블을 완전히 나타내고 설명하려면, 그리드 패턴이나 테이블 패턴에
기술 된 역할(role)을 사용하여 헤더, 행(row), 셀(cell)을 해석하는 것 외에도
보조 기술이 다음을 결정할 수 있어야 합니다:
- 행과 열의 개수
- 열 또는 행의 숨김 여부, 예를 들어, 1 ~ 3열과 5 ~ 8열은 보여지지만 4열은 숨김.
- 셀이 여러 행 또는 열로 합쳐져 있는지 여부.
- 데이터 정렬 여부 및 방법.
브라우저는 자동으로 렌더링 된 DOM을 기준으로 그리드나 테이블의 행과 열 개수로 접근 가능한 트리를 채웁니다.
하지만, 데이터가 너무 커서 완전히 렌더링 할 수 없는 경우와 같이 DOM이 전체 그리드나 테이블이 포함하지 않는 많은 상황이 있습니다.
게다가, 건너 뛴 열이나 행 및 데이터 정렬 방법과 같은 일부 정보는 DOM 구조에서 파생될 수 없습니다.
아래 섹션에서는 ARIA가 그리드와 테이블에 접근성을 제공하는 속성(property)들을 사용하는 방법을 설명합니다.
DOM 구조가 나타낸 행의 개수가 table, grid, treegrid에 사용 가능한 총 행 개수가 아닌 경우,
aria-rowcount 속성(property)이 사용 가능한 총 행 개수를 전달하는데 사용되고,
DOM에 있는 행의 행 인덱스를 식별하기 위해 aria-rowindex 속성(property)이 수반됩니다.
aria-rowcount는 table, grid, treegrid 역할(role)이 있는 엘리먼트에 지정됩니다.
값은 헤더 행을 포함하여 사용 가능한 행의 총 개수와 동일한 정수입니다.
행의 총 개수를 알 수 없는 경우, -1 값이 지정 될 수 있습니다.
-1 값을 사용하는 것은 사용 가능한 공급의 크기를 지정하지 않고 사용 가능한 더 많은 행을 DOM에 포함 시킬 수 있음을 나타냅니다
table, grid, treegrid에 aria-rowcount가 사용되는 경우,
aria-rowindex 속성(property) 값이 헤더 행을 포함하여 각 하위 행에 지정됩니다.
aria-rowindex 값은 다음과 같은 정수입니다:
- 1 이상.
- 이전 행의
aria-rowindex 값보다 큰 값.
- 셀이 여러 행에 합쳐진 경우 합쳐진 첫 번째 행의 인덱스로 설정.
- 전체 행 수 이하.
주의! aria-rowindex의 누락 또는 부적합한 값은 보조 기술 동작에 치명적인 영향을 미칠 수 있습니다.
예를 들어, aria-rowindex에 유효하지 않은 값을 지정하거나 테이블에 모든 행이 아니라 일부에만 설정하는 것은 스크린리더 테이블 낭독 기능이 행을 건너 뛰거나 단순히 기능을 중지 시키게 할 수 있습니다.
다음 코드는 가상의 수업 목록을 포함하는 표에 aria-rowcount와 aria-rowindex 속성(property)의 사용을 보여줍니다.
<table role="grid" aria-rowcount="463"
aria-label="역사 101 학생 명부">
<thead>
<tr aria-rowindex="1">
<th>성</th>
<th>이름</th>
<th>E-mail</th>
<th>전공</th>
<th>부전공</th>
<th>학년</th>
</tr>
</thead>
<tbody>
<tr aria-rowindex="51">
<td>Henderson</td>
<td>Alan</td>
<td>ahederson56@myuniveristy.edu</td>
<td>경영</td>
<td>스페인어</td>
<td>3학년</td>
</tr>
<tr aria-rowindex="52">
<td>Henderson</td>
<td>Alice</td>
<td>ahederson345@myuniveristy.edu</td>
<td>공학</td>
<td>없음</td>
<td>2학년</td>
</tr>
<tr aria-rowindex="53">
<td>Henderson</td>
<td>Andrew</td>
<td>ahederson75@myuniveristy.edu</td>
<td>General Studies</td>
<td>없음</td>
<td>1학년</td>
</tr>
</tbody>
</table>
DOM 구조에 나타난 열 개수가 table, grid, treegrid에 사용 가능한 열의 총 개수가 아닐 경우,
aria-colcount 속성(property)이 사용 가능한 열의 총 개수를 전달하는데 사용되고,
DOM에 있는 열의 열 인덱스를 식별하기 위해 aria-colindex 속성(property)이 수반됩니다.
aria-colcount는 table, grid, or treegrid 역할(role)이 있는 엘리먼트에 지정됩니다.
값은 사용 가능한 열의 총 개수와 동일한 정수입니다.
열의 총 개수를 알 수 없는 경우, -1 값이 지정될 수 있습니다.
-1 값을 사용하는 것은 사용 가능한 공급의 크기를 지정하지 않고 사용 가능한 더 많은 열을 DOM에 포함 시킬 수 있음을 나타냅니다.
table, grid, treegrid에 aria-colcount가 사용되는 경우,
aria-colindex 속성(property) 값은 아래 기술된 대로 열이 연속되어 있는지에 따라 각 후손 행이나 후손 행의 모든 셀에 지정됩니다.
aria-colindex의 값은 다음과 같은 정수입니다:
- 1 이상.
- 셀에 설정할 경우, 동일한 행 내의 이전 셀에 설정 된 모든 값보다 큰 값.
- 셀이 여러 열에 합쳐져 있을 경우, 합쳐진 첫 번째 열의 인덱스 값으로 설정.
- 전체 열 개수 이하.
주의! aria-colindex의 누락 또는 부적합한 값은 보조 기술 동작에 치명적인 영향을 미칠 수 있습니다.
예를 들어, aria-colindex에 유효하지 않은 값을 지정하거나 행의 모든 셀이 아니라 일부에만 설정하는 것은 스크린리더 테이블 낭독 기능이 셀을 건너 뛰거나 단순히 기능을 중지 시키게 할 수 있습니다.
행의 모든 셀이 연속적인 정수인 열 인덱스 번호를 가지는 경우,
aria-colindex가 세트의 첫 번째 열의 인덱스 번호와 동일한 값이 행 엘리먼트에 설정될 수 있습니다.
브라우저는 행의 각 셀의 열 번호를 계산합니다.
다음의 코드는 사용자에게 2 ~ 5까지의 열이 표시 된 16개 열을 가진 그리드를 보여줍니다.
열 세트가 연속적이기 때문에, aria-colindex가 각 행에 배치될 수 있습니다.
<div role="grid" aria-colcount="16">
<div role="rowgroup">
<div role="row" aria-colindex="2">
<span role="columnheader">이름</span>
<span role="columnheader">성</span>
<span role="columnheader">회사</span>
<span role="columnheader">주소</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>
행의 셀이 비연속적인 정수인 열 인덱스 번호를 가지는 경우, aria-colindex는 행의 각 셀에 설정 되어야 합니다.
다음 예제는 처음 두 열이 학생 이름을 포함하고 이후 열들이 점수를 포함하는 온라인 성적표에 대한 그리드를 보여줍니다.
이 예에서, 학생 이름이 있는 첫 두 열은 표시되고, 점수 열은 10 ~ 13 열을 표시하도록 스크롤 되었습니다.
열 3 ~ 9는 표시되지 않으므로 DOM에 없습니다.
<table role="grid" aria-rowcount="463" aria-colcount="13">
aria-label="역사 101에 대한 학생 성적"
<thead>
<tr aria-rowindex="1">
<th aria-colindex="1">성</th>
<th aria-colindex="2">이름</th>
<th aria-colindex="10">숙제 4</th>
<th aria-colindex="11">시험 2</th>
<th aria-colindex="12">숙제 5</th>
<th aria-colindex="13">숙제 6</th>
</tr>
</thead>
<tbody>
<tr aria-rowindex="50">
<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>
HTML table 엘리먼트가 아닌 엘리먼트를 사용하여 tables, grids, treegrids이 생성된 경우,
행과 열 합침은 aria-rowspan과 aria-colspan 속성(property)으로 정의됩니다.
aria-colspan의 값은 다음과 같은 정수입니다:
- 1 이상.
- 동일 행의 다음 셀과 겹쳐지게 되는 값보다 작은 값
aria-rowspan의 값은 다음과 같은 정수입니다:
- 0 이상.
- 0은 행 그룹의 나머지 모든 행 합침을 의미합니다.
- 동일 열의 다음 셀과 겹쳐지게 되는 값보다 작은 값.
다음 예제 그리드는 두 개의 행 헤더를 가집니다.
첫 두 열은 헤더의 모든 행에 걸쳐진 헤더를 가집니다.
이후 6개 열은 첫번째 행의 헤더로 각 2개 열이 합쳐진 3쌍으로 그룹핑 됩니다.
<div role="grid" aria-rowcount="463">
aria-label="역사 101에 대한 학생 성적"
<div role="rowgroup">
<div role="row" aria-rowindex="1">
<span role="columnheader" aria-rowspan="2">성</span>
<span role="columnheader" aria-rowspan="2">이름</span>
<span role="columnheader" aria-colspan="2">시험 1</span>
<span role="columnheader" aria-colspan="2">시험 2</span>
<span role="columnheader" aria-colspan="2">최종</span>
</div>
<div role="row" aria-rowindex="2">
<span role="columnheader">점수</span>
<span role="columnheader">등급</span>
<span role="columnheader">점수</span>
<span role="columnheader">등급</span>
<span role="columnheader">점수</span>
<span role="columnheader">등급</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>
참고: table 엘리먼트를 사용하는 경우,
열과 행 합침을 정의하도록 rowspan과 colspan 어트리뷰트를 사용하여
th와 td의 기본 의미론을 사용하세요.
행 또는 열이 정렬되는 경우, aria-sort 속성(property)이 정렬 방법을 나타내기 위해 열이나 행 헤더에 적용될 수 있습니다.
다음 표는 aria-sort에 허용된 값을 설명합니다.
ARIA가 여러 정렬 키를 가진 데이터 세트에 대한 정렬의 수준을 나타내는 방법을 제공하지 않는다는 점에 유의해야 합니다.
따라서, 둘 이상의 열이나 행에 none 이외의 값을 가진 aria-sort를 적용하는데 제한적인 값이 있습니다.
다음 예제 그리드는 행이 최고 "Quiz 2" 점수부터 최저 "Quiz 2" 점수로 정렬되었음을 나타내는데 aria-sort를 사용합니다.
<table role="grid" aria-rowcount="463" aria-colcount="13"
aria-label="역사 101에 대한 학생 성적">
<thead>
<tr aria-colindex="10" aria-rowindex="1">
<th>Homework 4</th>
<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>
ARIA는 다음 역할(role)을 범위 위젯으로 정의하고, 이는 일반적으로 숫자이고 한도를 정의하기 위해 강제 된 값을 전달한다는 것을 의미합니다.
meterprogressbarscrollbarseparator (if focusable)sliderspinbutton
예를 들어, 1월의 날짜를 선택하는 스핀 버튼은 1 ~ 31까지 범위의 정수 값을 허용합니다.
경우에 따라, 값은 숫자로 나타나지만, 사용자에게 숫자로 표시되지 않습니다.
일례로, 요일을 선택하는 스핀 버튼은 1 ~ 7까지의 값을 지원할 수 있지만, 사용자에게는 요일 이름 예를 들어, "월요일", "화요일" 등으로 표시될 수 있습니다.
이 섹션은 범위 위젯의 특성을 전달하는 다음의 4가지 속성(property)에 대한 고려사항을 설명합니다:
| 속성(property) |
정의 |
aria-valuemin |
범위 위젯에 허용된 최소 값을 정의. |
aria-valuemax |
범위 위젯에 허용된 최대 값을 정의. |
aria-valuenow |
범위 위젯의 현재 값을 정의. 이 값은 (지정되었다면) aria-valuemin 이상의 숫자이고 aria-valuemax 이하의 값입니다. |
aria-valuetext |
숫자 값이 충분히 설명적이지 않은 경우, 이 속성이 범위 위젯의 현재 값의 텍스트 설명을 정의할 수 있습니다. |
엘리먼트의 값이 범위 내에 포함되어 있지만 그 값이 ("작음", "중간", "큼"과 같이) 숫자가 아닌 경우,
또는 숫자이지만 숫자만으로보다는 더 많은 정보를 전달하는 것에 가치가 있는 경우,
aria-valuetext가 보조 기술에 텍스트 값을 드러내는데 사용됩니다.
aria-valuetext를 사용하는 것은 보조 기술이 aria-valuenow과 통신하는 것을 방해하므로 aria-valuenow이 사용자에게 충분히 유의미하지 않은 경우 aria-valuetext만 사용하세요.
예를 들어, 배터리 표시기의 경우, 남은 충전 비율과 함께, 남은 시간(분)을 아는 것이 유용할 것입니다.
<span id="battery-label">배터리</span>
<span role="meter" aria-labelledby="battery-label"
aria-valuenow="5"
aria-valuetext="5%, 18 분 남음.">
</span>
label을 클릭하면 이label의for어트리뷰트로 연결된 엘리먼트를 활성화 하도록 동작하는데, 위 예제에서와 같이 ARIA의 작성하는 것은 label의 동작과 같은 HTML 네이티브 동작을 제공하지 않음을 의미합니다. 따라서, HTML 네이티브와 동등하게 동작하게 하는 것은 작성자의 몫으로 남겨집니다.