ARIA 사용

2.1 ARIA 사용의 첫 번째 규칙

요소의 용도를 변경하고 ARIA 역할, 상태 또는 속성을 추가하여 접근 가능하게 만드는 대신 이미 내장되어 있는 의미와 동작을 갖춘 기본 HTML 요소 [HTML51] 또는 속성을 사용할 수 있다면 그렇게 하세요.

어떤 상황에서 이것이 불가능합니까?

• 기능이 HTML [HTML51]에서 사용 가능하지만 구현되지 않았거나 구현되었지만 접근성 지원이 없는 경우입니다.
• 시각적 디자인 제약으로 인해 특정 기본 요소의 사용이 배제되는 경우, 요소의 스타일을 필요에 따라 지정할 수 없기 때문입니다.
• 현재 HTML에서 사용할 수 없는 기능인 경우.

2.2 ARIA 사용의 두 번째 규칙

꼭 필요한 경우가 아니면 기본 의미를 변경하지 마세요.

예: 개발자가 탭인 제목을 작성하려고 합니다.

다음을 수행하지 마십시오.

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

이렇게 하십시오.

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

2.3 ARIA 사용의 세 번째 규칙

모든 대화형 ARIA 컨트롤은 키보드로 사용할 수 있어야 합니다.

사용자가 클릭, 탭, 드래그, 드롭, 슬라이드 또는 스크롤할 수 있는 위젯을 생성하는 경우 사용자는 위젯으로 이동하고 키보드를 사용하여 동등한 작업을 수행할 수도 있어야 합니다.

모든 대화형 위젯은 해당되는 경우 표준 키 입력 또는 키 입력 조합에 응답하도록 스크립트를 작성해야 합니다.

예를 들어, role=button 요소를 사용하려면 포커스를 받을 수 있어야 하고 사용자는 enter(WIN OS에서) 또는 return(MAC OS)와 space키를 모두 사용하여 요소와 관련된 작업을 활성화할 수 있어야 합니다.

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

2.4 ARIA 사용의 네 번째 규칙

포커스 가능한 요소에는 role="presentation" 또는 aria-hidden="true"를 사용하지 마세요.

포커스 가능한 요소에 이들 중 하나를 사용하면 일부 사용자는 '없는 것(nothing)'에 집중하게 됩니다.

다음을 수행하지 마십시오.

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

다음을 수행하지 마십시오.

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

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

button {opacity:0}
<button tabindex="-1" aria-hidden="true">press me</button>

2.5 ARIA 사용의 다섯 번째 규칙

모든 대화형 요소에는 접근 가능한 이름이 있어야 합니다.

대화형 요소에는 접근성 API 접근 가능한 이름 (또는 이에 상응하는 이름) 속성에 값이 있는 경우에만 접근 가능 이름이 있습니다.

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

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

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

이에 비해 아래 코드 예제 input type=text에서는 'user name'이라는 레이블이 표시되고 접근 가능한 이름이 있습니다. 이 예제에는 input 요소가 레이블 지정 가능한(labelable) 요소이고 label이 레이블 텍스트를 입력과 연결하는 데 올바르게 사용되었기 때문에 접근 가능한 이름이 있습니다.

<!-- Note: use of for/id or wrapping label around text
and control methods will result in an accessible name -->
<input type="text" aria-label="User Name">
or
<span id="p1">user name</span> <input type="text" aria-labelledby="p1">

컨트롤의 MSAA accName 속성에는 "user name" 값이 있습니다.

HTML label 요소 및 레이블 지정 가능 요소

다음은 HTML에서 label 사용에 관한 것입니다. ARIA 위젯을 구축하는 경우 ARIA Authoring Practices Document를 참조하세요.

label 요소는 label이 기본 HTML 레이블 지정 가능 요소를 참조하지 않는 한 사용자 정의 컨트롤에 접근 가능한 이름을 제공하는 데 사용할 수 없습니다.

<!-- HTML input element with combox role -->
<label>
user name <input type="text" role="combobox">
</label>

컨트롤의 MSAA accName 속성에는 "user name" 값이 있습니다.

할당된 역할에 관계없이 div 요소는 HTML 레이블 지정 가능 요소가 아닙니다.

<!-- HTML div element with combox role -->
<label>
user name <div  role="combobox"></div>
</label>

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

2.6 역할을 추가하면 기본 의미에 어떤 영향을 미치나요?

ARIA 역할을 추가하면 접근성 API를 통해 보고되는 접근성 트리의 기본 역할 의미가 재정의되므로 ARIA는 화면 낭독기나 기타 보조 기술에 보고되는 내용에 간접적으로 영향을 미칩니다.

예를 들어 HTML 트리의 다음 코드는 다음과 같습니다.

<h1 role=button>text</h1>

접근성 트리에서는 다음과 같이 됩니다.

역할을 추가하면 안되는 것

ARIA 역할을 추가해도 보조 기술을 사용하지 않는 사람들에게는 요소가 다르게 보이거나 작동하지 않습니다. 호스트 요소의 동작, 상태 및 속성은 변경되지 않고 기본 역할의 의미만 변경 됩니다.

예를 들어 HTML 트리에서 이 코드는 다음과 같습니다.

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

접근성 트리에서는 다음과 같이 됩니다.

그러나 여전히 누를 수 있고, 여전히 기본 탭 순서에 있으며, 여전히 버튼처럼 보이고, 누르면 관련 작업이 계속 실행됩니다. 이것이 바로 버튼을 제목으로 변경하는 것이 HTML5 준수 오류인 이유입니다.

참고: role 요소의 변경은 사용된 요소에 동작, 속성 또는 상태를 추가하지 않습니다. ARIA는 브라우저에서 표시되거나 작동하는 방식을 변경하지 않습니다. 예를 들어 링크가 버튼처럼 작동하는 데 사용되는 경우 role=button 추가로는 충분하지 않습니다. 또한 기본 버튼이 enter 키나 spacebar를 통해 활성화될 수 있는 것처럼 space 키 입력을 수신하는 키 이벤트 핸들러를 포함하여 기본 버튼처럼 동작하도록 해야 합니다.

2.7 ARIA 추가는 인라인으로? 스크립트로?

ARIA 역할 또는 aria-* 속성이 상호 작용 동작을 제공하기 위해 스크립팅에 의존하지 않는 경우 ARIA 마크업을 인라인으로 포함하는 것이 안전합니다. 예를 들어 ARIA 랜드마크 역할을 추가 하거나 ARIA 라벨 지정 및 속성 설명을 인라인으로 추가하는 것은 괜찮습니다.

콘텐츠와 상호 작용이 스크립팅이 가능한 브라우징 컨텍스트에서만 지원되는 경우, 즉 Google 문서(애플리케이션이 작동하려면 JavaScript가 활성화되어 있어야 함) 애플리케이션은 Javascript가 활성화되지 않은 상태에서 간단히 작동하지 않으므로(누구에게나) ARIA 마크업을 인라인으로 포함하는 것도 안전합니다.

그렇지 않으면 스크립팅을 통해 ARIA를 삽입, 변경 및 제거합니다. 예를 들어 트리 위젯의 접힌 섹션은 다음과 같습니다.

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

사용자가 섹션을 펼치면 Javascript를 사용하여 섹션이 다음과 같이 변경됩니다.

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

2.8 ARIA 유효성 검사

가장 쉬운 방법은 ARIA 마크업과 함께 HTML5 DOCTYPE을 사용하고 W3C Nu Markup Checker를 사용하여 유효성을 검사하는 것입니다. ARIA는 다른 DOCTYPE에도 동일하게 작동 하지만, 관련 DTD가 ARIA 마크업을 인식하도록 업데이트되지 않았고 그럴 가능성도 거의 없기 때문에 ARIA 마크업을 발견하면 검증 도구에서 오류가 발생합니다.

HTML5 이전 HTML 버전의 이러한 유효성 검사 오류는 ARIA가 실제 접근성 문제를 일으킨다 는 것을 의미하지 않으며 부정적인 사용자 경험이 있을 것임을 의미하지도 않습니다. 이는 ARIA 접근성 주석을 수용하지 않는 오래된 자동 유효성 검사 테스트의 결과일 뿐입니다.

참고: ARIA 검사를 위한 W3C Nu Markup Checker 지원은 작업 중이므로 올바른 결과를 제공하는 데 전적으로 의존할 수는 없습니다(아주 훌륭하긴 하지만!). ARIA 명세나 HTML 명세의 ARIA 준수 요구 사항과 충돌하는 결과가 발생하는 경우 문제를 제기하는 것이 좋습니다.

2.9 Role=presentation 혹은 Role=none 사용

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

예를 들어 HTML 트리에서 이 코드는 다음과 같습니다.

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

접근성 트리에서는 다음과 같이 됩니다.

즉, 의미론적 의미가 없는 텍스트 문자열로 접근성 트리에 보고될 뿐입니다.

필수 하위 항목이 없는 요소의 경우 role=presentation/none이 있는 요소 내부에 중첩된 모든 요소는 원래 의미를 유지합니다.

예를 들어 HTML 트리에서 이 코드는 다음과 같습니다.

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

접근성 트리에서는 다음과 같이 됩니다.

필수 하위 요소(예: ul 또는 table)가 있는 요소의 경우 role=presentation/none이 있는 요소 내부에 중첩된 필수 하위 요소의 의미도 제거됩니다.

예를 들어 HTML 트리에서 이 코드는 다음과 같습니다.

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

접근성 트리에서는 다음과 같이 됩니다.

참고: role=presentation/none가 있는 요소의 필수 하위 요소가 아닌 모든 요소는 의미 체계를 유지합니다 . 여기에는 중첩 목록이나 중첩 테이블과 같은 필수 하위 항목이 있는 다른 요소가 포함됩니다.

예를 들어 HTML 트리에서 내부에 중첩된 다른 테이블이 있는 테이블로 구성된 다음 코드는 다음과 같습니다.

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

접근성 트리에서는 다음과 같이 됩니다.

role=presentation/none을 외부 table 요소에 추가하면 HTML 트리에 다음 코드가 표시됩니다.

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

role=presentation/none을 추가하여 필수 하위 항목(tr 및 td 요소)을 포함한 외부 table은 접근성 트리에서 의미가 제거됩니다

role=presentation/none 사용 예

잘못된 테이블 구조를 수정하는데 사용

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

2.10 실용적 지원: aria-label, aria-labelledby, aria-describedby

이 글을 요약하면 다음과 같습니다.

• aria-labelledby와 aria-describedby는 다양한 input 유형을 포함한 links 및 양식 컨트롤 과 같은 대화형 콘텐츠 요소 에 대해 강력하게 지원됩니다.
• 대부분의 보조 기술의 경우 aria-label 또는 aria-labelledby를 <nav>, <main> 요소에 사용할 수 있지만 <footer>, <section>, <article>, <header>에서는 사용할 수 없습니다.
• <aside>에는 aria-label 또는 aria-labelledby에 대한 지원이 혼합되어 있습니다.
• Android의 Talkback은 aria-label 또는 aria-labelledby.가 있는 모든 랜드마크의 콘텐츠를 재정의합니다.
• div 요소에 role=navigation, role=search, role=main을 사용할 때 aria-label 또는 aria-labelledby를 사용하는 것은 괜찮습니다. 하지만 JAWS는 role=banner, role=complementary, role=contentinfo를 지원하지 않습니다. NVDA, VoiceOver 및 Talkback에서는 괜찮습니다.
• aria-label, aria-labelledby, aria-describedby는 table, th, td 요소에서 잘 작동하지만, 다음 섹션에서 설명하는 NVDA, iOS의 VoiceOver 및 Talkback에 대한 예외가 있습니다.
• 헤딩 요소에는 aria-label, aria-labelledby를 사용하지 마세요. NVDA, VoiceOver 및 Talkback에서는 헤딩을 대체하기 때문입니다. JAWS는 이들을 무시합니다.
• 대화형이 아닌 p, legend, li, ul과 같은 기타 콘텐츠에는 aria-label, aria-labelledby를 사용하지 마세요. 무시됩니다.
• span, div에는 role이 지정된 경우가 아니라면 aria-label, aria-labelledby를 사용하지 마세요. 대화형 역할(예: link, button) 또는 img 역할에 aria-label나 aria-labelledby가 있으면 div나 span의 내용이 대체됩니다. 랜드마크 역할(위에서 설명한)을 제외한 다른 역할은 무시됩니다.
• span 또는 div에 aria-describedby를 사용하면 대화형 role, 이미지 또는 랜드마크 role이 지정되지 않은 경우 NVDA와 VoiceOver에서 무시됩니다. JAWS와 Talkback에서는 괜찮습니다.
• aria-describedby는 NVDA와 VoiceOver에서 다른 정적 콘텐츠에 대해 무시됩니다. JAWS와 Talkback에서는 괜찮습니다.

위의 모든 내용은 iframe 요소 에서도 동일하게 작동합니다. aria-label와 aria-labelledby 둘 다 화면 낭독기 및 Accessibility API와 동일한 동작을 갖지만 페이지 에 참조할 텍스트가 표시되지 않거나 id 값을 추적하는 것이 너무 어려운 경우를 위해 aria-label이 예약되어야 합니다.

aria-labelledby, aria-label, aria-describedby에 대한 Internet Explorer 참고 사항

Internet Explorer에서 여러 id를 참조하는 aria-labelledby이나 단일 또는 여러 id를 참조하는 aria-describedby를 사용하는 경우 참조된 요소는 Microsoft에서 말하는 접근 가능한 HTML 요소여야 합니다.

다음 예에서는 여러 참조가 있는 aria-labelledby를 사용한 span에 tabindex=-1를 추가합니다. 접근 불가능한 요소를 접근 가능하게 만들기를 참조하십시오.

또한 요소에 ARIA 역할이 있는 경우 Internet Explorer에서 해당 요소는 접근 가능한 HTML 요소가 됩니다 . 예를 들어:

콘텐츠를 숨겨도 접근 가능한 이름이나 설명 계산에는 영향을 미치지 않습니다

의도적으로 aria-labelledby 및 aria-describedby가 참조하는 요소의 콘텐츠를 숨기더라도(CSS display:none 또는 visibility:hidden 또는 HTML hidden 속성 사용) 이름/설명을 제공하는데 콘텐츠가 사용되는 것을 막지는 않습니다.

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

다음 예에서는 두 상태 모두 보조 기술 사용자에게 설명이 제공됩니다.

오류 없는(Non-Error) 상태: 메시지가 시각적으로 숨겨짐

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

참고: 참조된 요소에 aria-hidden=true를 추가해도 아무런 차이가 없습니다.

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

오류 상태: 메시지 표시

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

맥락에 맞는 이름/설명 텍스트를 제공하는 방법

오류 메시지와 같이, 상황에 맞는 텍스트를 연결하려면 다음을 수행할 수 있습니다.

• 오류 상태가 발생하면 참조된 요소를 DOM에 추가합니다.
• 오류 상태가 발생할 때 DOM에서 참조된 요소의 하위 요소로 오류 텍스트를 추가합니다.
• 오류 상태가 발생하면 DOM의 ID 참조를 aria-labelledby/aria-describedby 속성에 추가하세요.

2.11 ARIA role=application 사용

role="application"이 화면 낭독기에 어떤 영향을 미치나요?

오늘날 널리 사용되는 많은 화면 낭독기에서는 사용자가 탐색 모드에 있을 때 웹 페이지가 아닌 화면 낭독기에 의해 대부분의 키 입력이 감지됩니다. 이는 페이지를 효율적으로 탐색하는 데 필요합니다. 이 글을 쓰는 시점에서 애플리케이션 모드가 설정되면 많은 화면 낭독기가 키 입력 가로채기를 중지하고 모든 키 입력을 브라우저에 직접 전달합니다. 그러면 사용자는 페이지를 쉽게 탐색할 수 없습니다. 예를 들어 페이지 제목을 건너뛰거나 정적 텍스트 단락을 한 줄씩 읽을 수 없습니다. 그러나 여러 화면 낭독기는 애플리케이션 역할이 설정된 경우 다르게 작동하지 않습니다.

그렇다면 언제 사용해야 하고, 언제 사용하지 말아야 할까요?

role=application을 사용할 시기를 판단할 때 무엇보다도 화면 낭독기 키보드 단축키의 장점과 해당 기능의 손실을 비교하여 고려해야 합니다. 일반적으로 사용해서는 안 되며, 사용하는 경우 화면 낭독기 사용자를 대상으로 사용성 테스트를 수행해야 합니다.

컨트롤 세트에 표준 HTML의 일부인 이러한 위젯만 포함되어 있는 경우에는 role="application"을 사용하지 마세요. 이는 표준 HTML 위젯 대신 WAI-ARIA 역할을 사용하여 마크업하고 상호 작용 모델을 생성하는 경우에도 적용됩니다.

참고: 작성자가 사용자 정의 텍스트 입력 위젯을 개발하는 것은 권장되지 않습니다. 이에 대해서는 거의 항상 기본 입력을 사용하는 것이 가장 좋습니다.

• text box. 이는 password, search, tel 및 기타 새로운 input type 파생에도 적용됩니다.
• textarea
• check box
• button
• radio button (보통 fieldset/legend 요소 wrapper 내부)
• select + option(s)
• links, paragraphs, headings 및 기타 웹 문서의 고전/기본 요소입니다.

위젯이 다음과 같이 보다 동적이고 기본이 아닌(non-native) 위젯 중 하나인 경우에도 application 역할을 사용하지 않습니다. WAI-ARIA를 지원하는 화면 낭독기 및 기타 보조 기술은 기본적으로 탐색 모드와 초점 모드 간 전환도 지원합니다.

• tree view
• slider
• arrow 키로 탐색, 초점을 받을 수 있는 항목이 있는 table(예: 특정 정보를 제공하는 이메일 메시지 목록). 다른 예로는 대화형 그리드, 트리 그리드 등이 있습니다.
• 사용자가 왼쪽 및 오른쪽 arrow 키를 통해 탭을 선택하는 탭 목록(tab, tablist)입니다. 이를 위해서는 키보드 탐색 모델을 구현해야 한다는 점을 기억하세요!
• dialog 그리고 alertdialog. 이로 인해 일부 화면 낭독기가 초점이 그 안의 컨트롤로 이동하면 일종의 응용 프로그램 모드(암묵적으로)로 전환됩니다. 이들이 가장 잘 작동하려면 역할이 dialog인 요소의 aria-describedby 속성을 대화 상자의 목적을 설명하는 텍스트의 id로 설정하고, 열릴 때 첫 번째 대화형 컨트롤에 포커스를 맞추어야 합니다.
  

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

• toolbar와 toolbar buttons, menus와 menu items, 그리고 유사한 것들.

제공하는 콘텐츠가 집중 가능한 대화형 컨트롤과 대부분 실제 데스크톱 애플리케이션을 에뮬레이트하는 고급 위젯 으로 구성된 경우에만 role=application을 사용하고 싶을 것입니다. 현재 웹 애플리케이션이라고 불리는 많은 것들이 있음에도 불구하고 이러한 웹 애플리케이션과 함께 작동하는 콘텐츠의 대부분은 Facebook 게시물 및 댓글, 블로그, Twitter 피드, 특정 유형의 정보를 동적으로 표시하고 숨기는 아코디언 등 여전히 문서 기반 정보입니다. 비록 표면적으로는 데스크탑과 같은 느낌을 주지만 우리는 주로 여전히 웹상의 문서를 다루고 있습니다.

사용자가 화면 낭독기에서 양식 (초점) 모드에 있는 동안에는 컨트롤별 키보드 단축키를 사용하기 위해 role=application을 사용할 필요가 없습니다. 예를 들어, ARIA role=listbox를 사용한 사용자 정의 컨트롤은 사용자가 상호 작용하는 동안 arrow 키를 포함하여 누른 모든 키를 쉽게 감지할 수 있습니다.

간단히 말해서, 실제로 role=application를 사용하게 될 경우는 아마도 매우 드물 것입니다!

그렇다면 role=application를 넣어서 유용한 경우는?

위젯의 가장 가까운 포함 요소(예: 가장 바깥쪽 위젯 요소인 요소의 부모 div)에 배치합니다. 해당 외부 div이 애플리케이션 상호 작용 모델이 필요한 위젯만 감싸는 경우 사용자가 이 위젯에서 탭 아웃하면 초점 모드가 꺼집니다.

페이지가 초점 모드를 켜야 하는 위젯 또는 위젯 세트로만 구성된 경우에만 본문 요소에 배치하세요. 이러한 위젯이 대부분 있지만 사용자가 찾아보기를 원하는 항목도 있는 경우 페이지의 문서 같은 부분의 가장 바깥쪽 요소에 role=document를 사용하세요. 이는 role=application과 반대 개념이며 화면 낭독기에게 이 부분에 대해 찾아보기 모드를 사용하도록 지시하는 것입니다. 또한 tabindex=0 사용자가 접근할 수 있도록 이 요소에 tabindex=0를 설정하여 탭할 수 있게 만드세요.

일반적인 규칙: 페이지가 90% 이상, 심지어 95%가 위젯로 구성된 경우에만 role=application을 고려할 수 있습니다. 그래도 role=application을 설정한 버전과 설정하지 않은 버전을 실제로 테스트하여 어떤 모델이 가장 잘 작동하는지 알아볼 수 있는 전문가를 찾으세요.

절대로 페이지가 주로 사용자가 초점 모드에서 상호 작용할 필요가 없는 전통적인 위젯이나 링크와 같은 페이지 요소로 구성된 경우 body와 같은 광범위한 요소에 role=application을 적용하지 마세요. 이렇게 하면 사이트/애플리케이션을 사용하려는 모든 보조 기술 사용자에게 큰 어려움이 발생합니다.

role=application 사용에 대한 자세한 내용은WAI-ARIA 역할 "application"을 현명하게 사용하세요!"를 참조하세요.

2.12 사용자 정의 컨트롤에 대한 접근성 개발 체크리스트:

다음 설계 고려 사항을 기준으로 사용자 정의 컨트롤을 확인하세요. 이에 대한 대답이 '아니요'인 경우 배포 전에 수정하거나 최소한 문제를 문서화하여 다른 개발자에게 제한된 접근성 지원으로 인해 일부 사람들이 사용자 정의 컨트롤을 사용할 수 없음을 알리는 것을 고려하십시오.

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

HTML4에 정의된 요소 중 기본 의미를 노출하기 위해 ARIA 역할을 추가할 필요가 있는 요소는 없습니다. ARIA 역할을 추가하는 것은 아무런 이득이 없는 추가 작업이며 본인이나 다른 사람에게 고통을 안겨줄 수 있습니다. 구현된 HTML5에 정의된 새로운 기능은 이제 대부분의 브라우저에서 기본 의미 체계를 노출합니다. HTML 명세에는 다음 참고 사항이 포함되어 있습니다.

대부분의 경우 기본 암시적 ARIA 의미 체계와 일치하는 ARIA role 및/또는 aria-* 속성을 설정하는 것은 불필요하며 권장되지 않습니다. 이러한 속성은 브라우저에서 이미 설정되어 있기 때문입니다.

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

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

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

2.14 HTML의 기능으로 사용할 수 없는 ARIA 역할 및 속성

아래에는 HTML에서 기본적으로 사용할 수 없는 것으로 간주되는 ARIA 역할 및 속성이 나열되어 있습니다. 사용자에게 정보를 전달하는 데 사용하는 ARIA의 많은 역할과 속성을 HTML에서는 사용할 수 없다는 것은 분명합니다.

2.15 ARIA 설계 패턴 및 터치 장치 지원

2.16 권고안 표:

HTML의 ARIA 명세의 HTML 테이블 의 ARIA 속성 사용에 대한 문서 준수 요구 사항을 참조하세요.

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

HTML의 ARIA 명세에서 허용되는 ARIA 역할, 상태, 속성 표를 참조하세요.