ARIA 역할 및 속성: 최고의 선택 비교

ARIA 역할 및 속성 W3C의 WAI-ARIA 1.2 사양에는 100개가 넘는 역할과 속성이 있지만, 소수만으로도 XHTML 및 CSS 위젯의 대부분의 접근성 문제를 해결할 수 있습니다. 역할은 요소가 무엇인지 정의하고 속성은 상태나 관계를 정의하지만, ARIA는 브라우저의 동작을 수정하지 않습니다. 추가된 각 역할은 JavaScript를 통한 상호 작용 구현이 필요합니다.

ARIA(Accessible Rich Internet Application)는 기본 형식에 없는 HTML 요소에 의미 체계를 추가하는 W3C 사양입니다. 역할은 요소 가 무엇인지(버튼, 탭, 대화상자) 설명하고 속성은 상태 또는 관계(aria-expanded, aria-controls, aria-labelledby)를 설명합니다. W3C가 ARIA 사용에서 게시한 ARIA의 첫 번째 규칙은 무뚝뚝합니다. 이미 작업을 수행하는 기본 HTML 요소가 있으면 이를 사용하고 ARIA를 추가하지 마세요.

그 이유는 ARIA가 브라우저 동작을 수정하지 않기 때문입니다. <div role="button">은 Tab으로 포커스를 받지 못하고 Enter 키나 공백에 응답하지 않으며 양식과 함께 제출되지 않습니다. 보조 기술이 발표하는 내용만 변경됩니다. 모든 상호 작용은 JavaScript로 구현되어야 하며 신중하게 관리되어야 합니다. HTML이 정적이고 JS가 최소인 XHTML/CSS 프로젝트에서 이는 추가되는 각 아리아 역할과 속성이 코드가 이행해야 하는 약속임을 의미합니다.

ARIA의 두 번째 규칙은 필수적이지 않은 한 기본 의미 체계를 변경하지 말 것을 요구합니다. <h2 role="tab">은 제목 구조를 깨뜨리고 지역별로 탐색하는 스크린 리더를 혼란스럽게 합니다. 세 번째 규칙에서는 모든 ARIA 컨트롤을 키보드로 작동할 수 있어야 합니다. 네 번째는 포커스를 받는 요소에 aria-hidden="true"를 사용하지 말라고 요청합니다. 가장 잊혀진 다섯 번째는 모든 대화형 요소에 접근 가능한 이름이 필요하다는 점을 상기시켜 줍니다. 레이블이 없는 역할은 음소거 버튼입니다.

선택 방법: 목록 앞의 기준

역할이나 속성을 선택하는 것은 취향의 문제가 아닙니다. 순서대로 적용되는 이러한 기준은 아리아 역할 및 속성과 관련된 대부분의 오류를 방지합니다.

1. 네이티브 HTML 요소가 있나요? 그렇다면 이를 사용하세요. <button>, <details>, <dialog>, <input type="checkbox">는 사람들이 생각하는 것보다 더 많은 경우를 다루고 있습니다.
2. 위젯에 동적 상태가 필요합니까? 열기/닫기, 선택/선택 안함, 확장/접기 간에 변경되는 경우 상태 속성(aria-expanded, aria-selected, aria-pressed)이 필요합니다.
3. 요소 간 관계가 필요합니까? 관계 속성(aria-controls, aria-labelledby, aria-describedby, aria-owns)은 접근성 트리가 DOM에서 추론할 수 없는 부분을 연결합니다.
4. 실시간 공지가 필요합니까? 라이브 영역(aria-live, role="status", role="alert")은 포커스를 이동하지 않고 업데이트를 해결합니다.
5. 유지관리할 수 있나요? 키보드나 스크린 리더 테스트가 없는 복잡한 ARIA 패턴은 아무것도 없는 것보다 나쁩니다.

유지관리 비용은 가장 무시되는 기준입니다. 잘 만들어진 role="tablist"에는 화살표 키 관리, tabindex 회전, aria-selected 및 aria-controls 동기화, 비활성 패널의 올바른 숨김이 필요합니다. 팀이 이를 처리할 수 없는 경우 앵커가 있는 링크 세트가 더 접근하기 쉽고 저렴합니다.

관련 항목: UserWay — 무료로 계획을 세우는 위젯 de empezar hoy mismo.

가장 유용한 ARIA 역할 비교

다음 표는 실제 감사에서 반복적으로 나타나는 역할들과, 가능한 경우의 네이티브 대체 요소 및 가장 흔한 실수들을 요약한 것입니다.

역할	용도	네이티브 대체제	흔한 실수
button	액션을 실행하는 컨트롤	<button>	Enter/Space 처리 및 tabindex="0" 누락
link	다른 URL로 이동	<a href>	내비게이션이 아닌 액션에 사용
dialog	모달 또는 비모달 창	<dialog>	포커스 트랩 미구현 및 닫을 때 포커스 미반환
tablist / tab / tabpanel	탭 인터페이스	없음	aria-selected와 표시된 패널 간의 동기화 누락
menu / menuitem	애플리케이션 메뉴	<select> 또는 링크 목록	웹 내비게이션 메뉴에 사용
alert	긴급하고 즉각적인 메시지	긴급하지 않은 경우 role="status"	과도한 사용으로 스크린 리더 사용자 피로 유발
status	정보 업데이트	<output>	업데이트 전 DOM에 삽입하지 않음
progressbar	작업 진행률	<progress>	aria-valuenow 업데이트 누락
tooltip	팝업 설명	title (제한적)	aria-describedby와 연결하지 않음
combobox	제안 목록이 있는 필드	<datalist> (제한적)	결과 개수를 알리지 않음

role="alert"와 role="status" 사이의 선택은 아리아 역할과 속성에 관한 미묘한 차이가 있는 결정의 좋은 예입니다. alert는 현재 스크린 리더 읽기를 중단합니다. status는 사용자가 완료할 때까지 기다립니다. 양식 유효성 검사 오류의 경우 alert가 적합합니다. 사용자가 작성하는 동안 “3개 결과 발견”의 경우 ‘상태’가 정확하고 ‘경고’ 결과가 방해가 됩니다.

ARIA의 속성은 예측할 수 없으며 조합에 포함됩니다.

속성은 네 가지 계열과 연관되어 있으며 각 계열은 고유한 문제를 해결합니다.

볼만한 가치가 있는 곳: AudioEye — Accesibilidad gestionada: 자동화와 인간의 개정 결합.

에티켓. aria-label은 눈에 보이는 텍스트가 없을 때 이름을 제공합니다. ‘aria-labelledby’는 다른 요소의 ‘id’를 참조하며 텍스트가 이미 화면에 있는 경우 단일 정보 소스를 유지하므로 선호됩니다. aria-describedby는 필드의 도움말 텍스트와 같은 더 긴 설명을 추가합니다. 차이점은 중요합니다. 이름은 사용자가 초점을 맞출 때 듣는 것입니다. 설명은 중단될 수 있는 추가 컨텍스트입니다.

Estados. 아코디언 및 드롭다운 메뉴에 대한 aria-expanded(true/false). 탭 및 옵션의 경우 ‘aria-selected’입니다. 맞춤 체크박스의 경우 ‘aria-checked’, 3상태 상태의 경우 값은 ‘mixed’입니다. 토글 버튼의 ​​경우 ‘aria-pressed’입니다. 탭 순서에서 해당 요소를 제거하는 기본 속성인 ‘disabled’와는 달리 요소에 여전히 포커스가 가능하지만 작동할 수 없는 경우 ‘aria-disabled’입니다.

관계. aria-controls는 버튼이 제어하는 ​​요소를 나타냅니다. aria-owns는 DOM이 시각적 관계를 반영하지 않을 때 접근성 트리를 재구성합니다. aria-activedescendant를 사용하면 콤보박스의 일반적인 패턴인 활성 요소를 알리는 동안 컨테이너에 초점을 유지할 수 있습니다.

라이브 지역. aria-live="polite" 또는 "assertive"는 긴급성을 정의합니다. aria-atomic="true"를 사용하면 수정된 부분만이 아닌 전체 블록이 발표됩니다. 변경된 aria-relevant 필터가 발표됩니다.

흔히 간과되는 세부 사항: ARIA 속성은 유효한 역할이 있는 요소에서만 작동합니다. 역할이 없는 <div>의 aria-expanded는 발표되지 않습니다. 그리고 ARIA 부울 값은 JavaScript 부울 값이 아닌 텍스트 문자열("true", "false")입니다. aria-expanded="false"를 부울 속성으로 작성하면 일관되지 않은 결과가 생성됩니다.

위젯 액세스에 오류가 발생했습니다.

HTML 구조와 관련하여 ARIA를 사용하는 데 오류가 발생했습니다. role="navigation"을 <div>로 설정하면 <nav>를 사용하여 중복된 지역을 탐색하고 랜드마크를 혼동할 수 있습니다.

관련 항목: IAAP CPACC / WAS Certification — La certificación profesional que acredita tu experiencia en accesibilidad.

두 번째 오류는 초점입니다. 열릴 때 포커스를 이동하지 않고, 열려 있는 동안 포커스를 트랩하지 않고, 닫을 때 트리거로 반환하지 않는 모달 위젯은 키보드 사용자가 보이지 않는 콘텐츠를 탐색하게 합니다. 기본 <dialog> 요소는 이 문제의 일부를 해결하지만 전부는 아닙니다. 포커스를 반환하는 것은 여전히 ​​개발자의 책임입니다.

El tercer error es ocultar con aria-hidden elementos que siguen siendo enfocables. 메뉴에서 aria-hidden="true" pero sin display: none o visibility: Hidden mantiene sus enlaces en el orden de tabulación, y el usuario enfoca elementos que no puede ver. 시각 시각의 조합을 수정하고 시각 시각적 시각을 수정합니다.

네 번째 오류는 접근 가능한 이름이 없다는 것입니다. 단일 SVG 아이콘이 있는 <버튼>에는 텍스트가 포함된 aria-label 또는 <span class="visually-hidden">이 필요합니다. 장식용 SVG에는 aria-hidden="true" 및 focusable="false"가 필요하므로 Internet Explorer 및 일부 이전 브라우저에서는 이를 탭 순서에 포함하지 않습니다.

쇼핑하는 경우: accessiBe — 48시간 동안 WCAG에 대한 IA의 중첩.

역할 및 속성 ARIA에 대한 Herramientas

실제 스크린 리더로 테스트할 수 있는 도구는 없지만 다양한 도구의 조합을 통해 아리아 역할 및 속성에서 대부분의 오류를 감지합니다.

정적 유효성 검사. W3C ARIA 유효성 검사기(Nu HTML Checker의 일부)는 존재하지 않는 역할, 잘못 작성된 속성 및 금지된 조합을 감지합니다. axe DevTools 및 Lighthouse는 액세스 가능한 이름이 없고 필수 속성이 누락된 역할을 지적합니다.

접근성 트리 검사. Chrome 및 Firefox DevTools를 사용하면 보조 기술에서 수신한 접근성 트리를 정확하게 볼 수 있습니다. 역할이 실제로 적용되었는지, 브라우저가 계산한 접근 가능한 이름을 확인하는 가장 빠른 방법입니다.

수동 테스트. 전체 위젯을 키보드(Tab, Shift+Tab, 화살표, Enter, Space, Escape)로만 탐색한 다음 Windows에서는 NVDA, 가능한 경우 JAWS, macOS 및 iOS에서는 VoiceOver를 사용하여 탐색하세요. 데스크톱 리더와 모바일 리더의 조합은 대부분의 실제 사례를 포괄합니다.

참조 문서. W3C ARIA Authoring Practices Guide(APG)에는 키보드 및 코드 예제와 함께 포괄적인 패턴이 포함되어 있습니다. 이것은 새로운 패턴을 고안하기 전에 참고해야 할 소스입니다.

XHTML/CSS 실제 프로젝트에 대한 결정을 내리세요.

경량 CSS 및 JavaScript를 사용하는 XHTML 사이트에서 가장 비용 효율적인 전략은 기본 HTML로 시작하고 기본이 도달하지 못하는 곳에만 ARIA를 추가하는 것입니다. 올바른 <label>, <fieldset> 및 <legend>가 있는 양식에는 ARIA가 거의 필요하지 않습니다. <번째 범위>가 있는 데이터 테이블도 그렇지 않습니다. HTML이 다루지 않는 패턴(탭, 아코디언, 필터링이 포함된 콤보 상자, 모달 대화 상자 및 동적 알림)이 나타날 때 ARIA 역할이 제공됩니다.

ARIA 역할과 속성의 각 사용을 코드 자체에 그 이유를 설명하는 설명과 함께 문서화하는 것이 좋습니다. 6개월 후 누군가가 구성 요소를 리팩터링하면 aria-controls가 여전히 필요한지 또는 고아가 되었는지 알 수 있습니다. 더 이상 존재하지 않는 id를 가리키는 고아 ARIA 속성은 어떤 유효성 검사기도 안정적으로 감지하지 못하는 자동 오류 소스입니다.

마지막으로, 접근성을 후속 감사가 아닌 “완료”에 대한 구성 요소 정의의 일부로 처리하십시오. 첫 번째 커밋에서 키보드와 스크린 리더로 테스트된 ARIA 역할이 있는 위젯은 감사 후 수리된 위젯보다 비용이 훨씬 저렴합니다.

주요 내용

• ARIA 역할 및 속성은 동작을 추가하지 않습니다. 키보드 및 포커스 관리가 없는 역할은 아무것도 없는 것보다 나쁩니다.
• ARIA의 첫 번째 규칙은 네이티브 HTML이 존재할 때마다 이를 사용하는 것입니다. <버튼>, <대화상자> 및 <세부정보>는 생각보다 더 많은 경우를 다룹니다.
• 속성은 라벨링, 상태, 관계 및 라이브 영역으로 그룹화됩니다. 각 가족은 다른 문제를 해결합니다.
• role="alert"는 중단되고 role="status"는 대기합니다. 잘못 선택하면 스크린 리더 사용자가 포화 상태가 됩니다.
• ARIA 부울 값은 문자열("true"/"false")이며 속성은 유효한 역할이 있는 요소에서만 작동합니다.
• 키보드와 실제 스크린 리더를 사용한 테스트는 필수입니다. 유효성 검사기는 오류의 일부만 감지합니다.

출처 및 추가 자료

• WAI-ARIA — Wikipedia: 웹 접근성 이니셔티브 – 액세스 가능한 리치 인터넷 애플리케이션(WAI-ARIA)은 W3C(월드 와이드 웹 컨소시엄)에서 발표한 기술 사양으로…

자주 묻는 질문

¿ Cuál es la diferencia entre un rol y un atributo ARIA?

역할은 role="tab" 또는 role="dialog"와 같은 보조 기술 요소가 무엇인지 정의합니다. 속성은 ‘aria-expanded’ 또는 ‘aria-labelledby’와 같은 상태나 관계를 설명합니다. 역할은 구성 요소를 나타내는 요소에 적용됩니다. 속성은 일반적으로 동일한 요소나 이와 관련된 요소에 적용됩니다.

HTML 기본 언어로 ARIA를 사용할 수 있나요?

패턴을 덮는 HTML 요소가 없는 경우에만 해당됩니다. W3C ARIA의 첫 번째 규칙은 명시적입니다. 기본 요소가 있으면 이를 사용하십시오. ARIA 역할은 HTML이 자체적으로 구현할 수 없는 기타 패턴 중에서 탭, 아코디언, 필터링이 포함된 콤보 상자 및 모달 대화 상자에 필요합니다.

¿ Qué는 액세스 가능하다는 의미입니까?

액세스 가능한 이름은 요소에 초점을 맞출 때 화면 판독기가 알려주는 텍스트입니다. 사양에 정의된 우선순위에 따라 콘텐츠, aria-label, aria-labelledby 또는 관련 <label>에서 계산됩니다. 액세스 가능한 이름이 없는 대화형 역할은 사용자가 식별할 수 없는 컨트롤입니다.

role="button"에 대해 응답이 없나요?

ARIA는 동작을 추가하지 않기 때문입니다. <div role="button">에는 포커스를 받기 위한 tabindex="0"과 Enter 및 Space에 대한 keydown 핸들러가 필요합니다. tabindex="0"이 필요합니다. 가장 간단하고 강력한 솔루션은 포커스, 키보드 활성화 및 양식 제출이 이미 포함된 기본 <button> 요소를 사용하는 것입니다.

aria-hidden="true"를 사용하는 것이 좋지 않을까요?

접근성 트리에서 장식적이거나 중복된 콘텐츠를 숨기는 것은 맞지만, 포커스를 받는 요소에는 절대로 적용해서는 안 됩니다. 포커스 가능한 요소가 aria-hidden="true"로 남아 있는 경우 키보드 사용자는 스크린 리더가 알려주지 않는 항목에 포커스를 둘 수 있습니다. 항상 실제 시각적 숨김과 결합하십시오.

ARIA 역할과 속성을 검증하는 도구는 무엇인가요?

W3C Nu HTML 검사기에는 ARIA 역할 및 속성의 유효성 검사가 포함되어 있으며 존재하지 않는 역할이나 금지된 조합을 감지합니다. axe DevTools 및 Lighthouse는 접근 가능한 이름이 없고 필수 속성이 누락된 역할을 지적합니다. 최종 결과를 확인하기 위해 브라우저 DevTools의 접근성 트리 검사기는 보조 기술이 수신하는 내용을 정확하게 보여줍니다.