ARIA 역할 예: 전체 가이드

ARIA 역할 예제는 역할 속성이 인터페이스 요소를 접근성 트리에 매핑하는 방법을 보여 주며, WAI-ARIA 1.2 사양은 위젯, 문서 구조, 랜드마크, 라이브 영역, 창, 추상 역할의 6가지 역할 범주를 정의하여 80개 이상의 구체적인 역할을 포괄합니다. 이 가이드는 각 범주에 대해 바로 복사하여 사용할 수 있는 실용적인 예제와, 역할이 도움이 되는 경우와 오히려 해가 되는 경우를 결정하는 규칙을 제시합니다.

주요 내용

• ARIA 역할은 보조 기술에 항목이 무엇인지 알려줍니다. 역할 자체만으로는 동작, 포커스 또는 키보드 지원을 추가하지 않습니다.
• ARIA 사용의 첫 번째 규칙은 이미 암시적 역할, 상태 및 키보드 관리를 포함하고 있는 기본 HTML 요소를 우선적으로 사용하는 것입니다.
• 6가지 WAI-ARIA 1.2 역할 범주는 위젯, 문서 구조, 랜드마크, 활성 영역, 창, 요약입니다. 추상 역할은 마크업에 절대 나타나서는 안 됩니다.
• 랜드마크 역할은 기존 XHTML/CSS 사이트에 추가할 수 있는 가장 비용 효율적이고 위험이 낮은 ARIA입니다.
• 위젯 역할은 키보드 상호 작용 및 상태 처리를 위해 거의 항상 JavaScript 매핑이 필요하며, 그렇지 않으면 일반 HTML보다 더 나쁜 사용자 경험을 제공합니다.
• 스크린 리더와 자동화된 검사기로 각 역할을 검증하십시오. 사양상 유효한 역할이라도 실제 콘텐츠에는 적절하지 않을 수 있습니다.

ARIA 역할이 실제로 하는 일

ARIA 역할은 접근성 트리에서 요소의 의미론적 정체성을 대체하거나 제공하기 위해 role 속성에 배치하는 토큰입니다. <div role="button">은 스크린 리더가 “버튼”이라고 읽어주게 하지만, 브라우저는 이를 여전히 일반 컨테이너로 취급합니다. 즉, 포커스를 받을 수 없고, Enter나 Space 키에 반응하지 않으며, 비활성화 상태를 가지지 않습니다. 이렇게 공표된 의미론과 실제 동작 사이의 간극은 ARIA 적용 실패의 가장 흔한 원인입니다. 다음은 의미론이 동작과 어떻게 달라질 수 있는지 보여주는 일반적인 ARIA 역할 예시입니다.

W3C의 Accessible Rich Internet Applications 워킹 그룹에서 관리하는 WAI-ARIA 사양은 역할뿐만 아니라 상태와 속성도 정의합니다. 역할은 “이것이 무엇인가”라는 계층이며, aria-expanded, aria-checked, aria-label과 같은 상태 및 속성은 “어떤 상태인가”라는 계층입니다. 필수 상태가 없는 역할은 불완전합니다. 예를 들어 role="checkbox"에는 aria-checked가 필요하고, role="combobox"에는 aria-expanded와 제어된 listbox가 필요합니다.

기본 HTML 요소는 암시적 역할을 가집니다. <button>은 button 역할에, <nav>는 navigation에, <h1>부터 <h6>까지는 heading에, <input type="checkbox">는 checkbox에 해당합니다. 브라우저가 역할, 키보드 동작 및 상태를 자동으로 제공하므로, W3C의 ARIA Authoring Practices Guide에 기록된 ARIA 사용의 첫 번째 규칙은 동등한 요소가 존재하는 한 항상 기본 의미론을 사용하는 것입니다. 커스텀 트리 뷰나 <div>로 구축된 탭 패널처럼 적절한 기본 요소가 없는 경우에만 명시적 역할을 고려하십시오.

6가지 WAI-ARIA 역할 카테고리

WAI-ARIA 1.2는 역할을 6가지 범주로 조직하며, 역할이 어떤 범주에 속하는지를 알면 얼마나 많은 JavaScript 구현이 필요한지 알 수 있습니다. 다음은 일반적인 ARIA 역할 예시입니다.

카테고리	목적	역할 예시	JavaScript 필요 여부
위젯 (Widget)	대화형 컨트롤	button, checkbox, tab, slider, combobox	예 — 키보드 + 상태 구현
문서 구조 (Document structure)	콘텐츠 구성	heading, list, listitem, table, article	아니요
랜드마크 (Landmark)	탐색을 위한 페이지 영역	banner, main, navigation, complementary	아니요
라이브 영역 (Live region)	동적 업데이트 알림	alert, status, log, timer	보통 — 업데이트 트리거를 위해
창 (Window)	하위 창 및 대화 상자	dialog, alertdialog	예 — 포커스 관리
추상 (Abstract)	슈퍼클래스 역할, 직접 작성 금지	widget, input, section, landmark	해당 없음 — 사용 금지

추상 역할은 오직 분류 체계를 조직하기 위해서만 존재합니다. HTML에 role="input" 또는 role="section"을 작성하는 것은 유효성 검사 오류이며, 보조 기술에 정의된 동작이 없으므로 예측 불가능한 안내가 생성됩니다.

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

랜드마크 역할 예시

랜드마크 역할은 JavaScript가 필요 없고 이미 존재하는 영역에 직접 매핑되기 때문에, 오래된 XHTML/CSS 사이트에 추가할 수 있는 가장 안전하고 영향력 있는 ARIA 역할 예제입니다. 전형적인 페이지 골격은 다음과 같습니다.

<header role="banner">
  <nav role="navigation" aria-label="Principal">
    <ul>...</ul>
  </nav>
</header>
<main role="main">
  <article>...</article>
  <aside role="complementary" aria-label="Artículos relacionados">...</aside>
</main>
<footer role="contentinfo">...</footer>

각 마커 역할은 기본 요소에 대응합니다. 최상위 수준의 <header>는 banner, <main>은 main, <nav>는 navigation, <aside>는 complementary, <footer>는 contentinfo에 해당합니다. 기본 요소를 사용할 때는 역할이 암시적이므로 이를 중복해서 작성하지 마십시오. 명시적인 role 속성은 수정할 수 없는 <div> 마크업을 사용해야만 하는 경우(오래된 템플릿이나 CMS 출력물에서 흔함)에만 사용합니다.

여기서 두 가지 주의 사항이 있습니다. 첫째, banner, main, contentinfo는 페이지당 한 번만 나타나야 합니다. 여러 개의 main 랜드마크는 탐색을 방해합니다. 둘째, 동일한 유형의 랜드마크가 여러 개 존재하는 경우(예: 3개의 <nav> 요소), 스크린 리더 사용자가 랜드마크 목록에서 이를 구별할 수 있도록 각각 별도의 aria-label을 제공하십시오. 라벨이 없는 nav는 다른 형제 요소와 동일하게 안내되어 목적이 무색해집니다.

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

위젯 역할 예시

위젯 역할은 ARIA가 매우 강력하면서도 동시에 위험해지는 지점입니다. 각 위젯 역할에는 특정 키보드 키, 특정 상태, 특정 포커스 동작이라는 암묵적인 계약이 있습니다. ARIA Authoring Practices Guide에는 각 역할에 대한 전체 패턴이 게시되어 있습니다. 다음 ARIA 역할 예시는 이에 수반되는 복잡성을 보여줍니다.

예를 들어, 토글 버튼은 켜짐/꺼짐 상태를 전달하기 위해 aria-pressed가 필요합니다.

<button type="button" aria-pressed="false" id="mute">
  Silenciar
</button>

<button> 요소가 역할, 포커스, Enter/Space 처리를 제공하며, JavaScript는 aria-pressed 값을 "false"와 "true" 사이에서 전환하기만 하면 됩니다. 이것이 기본 요소, 최소한의 ARIA, 작은 스크립트를 사용하는 ARIA 활용의 이상적인 형태입니다.

<div>로 구축한 커스텀 탭 인터페이스는 정반대의 경우입니다. 컨테이너에는 role="tablist", 각 탭에는 role="tab", 각 패널에는 role="tabpanel", 활성 탭에는 aria-selected, 탭과 패널을 연결하는 aria-controls, 그리고 탭 간 화살표 키 탐색이 필요합니다. 이 중 하나라도 누락되면 위젯은 탭으로 안내되지만 동작은 정적 텍스트처럼 하게 됩니다. 이는 role="slider"(aria-valuenow, aria-valuemin, aria-valuemax 및 화살표 키 필요), role="combobox"(aria-expanded 및 제어된 listbox 필요), role="tree"(aria-expanded 및 전체 화살표 키 순회 필요)에도 동일하게 적용됩니다.

유용한 결정 규칙: 해당 작업을 수행하는 기본 요소(<button>, <input type="checkbox">, <select>, <details>)가 있다면 이를 사용하고 위젯 역할은 완전히 무시하십시오. 커스텀 위젯 역할은 정말로 새로운 컨트롤에만 사용하고, 출시 전에 전체 키보드 패턴을 구현할 JavaScript 개발 예산을 책정하십시오.

문서 구조 및 라이브 영역 예시

문서 구조 역할은 기본 요소를 사용할 수 없을 때 콘텐츠 관계를 설명합니다. 이러한 ARIA 역할 예시에는 aria-level을 함께 사용하는 role="heading"이 포함되며, 이는 제목 역할을 하는 스타일링된 <div>를 구제하는 전형적인 방법입니다.

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

<div role="heading" aria-level="2">Novedades del mes</div>

여기서 aria-level 속성은 필수입니다. 레벨이 없는 heading 역할은 순위 없이 안내되어 문서 개요를 깨뜨립니다. 마찬가지로 role="list"와 role="listitem"은 list-style: none과 같은 CSS나 flex 컨테이너로 인해 일부 브라우저에서 목록 의미론이 제거되었을 때 이를 복원하며, role="table", role="row", role="columnheader", role="cell"은 <div> 마크업으로 데이터 테이블을 재구축합니다. 실제로 <ul>, <ol>, <table> 요소로 재구성하는 것이 전체 구조 역할을 유지하는 것보다 거의 항상 작업량이 적습니다.

라이브 영역 역할은 페이지 새로고침 없이 변경되는 콘텐츠를 안내합니다. role="alert"는 스크린 리더를 즉시 중단시키며 오류 메시지나 긴급 알림에 적합합니다. role="status"는 정중하게 대기하며 “Guardado”와 같은 확인 메시지에 적합합니다. role="log"는 채팅이나 활동 피드에, role="timer"는 카운트다운에 해당합니다. 중요한 점은 라이브 영역 컨테이너가 콘텐츠가 변경되기 전에 DOM에 존재해야 한다는 것입니다. role="alert"와 텍스트를 포함한 새 요소를 동시에 삽입하면, 모니터링할 영역이 미리 존재하지 않았기 때문에 안내가 생성되지 않는 경우가 많습니다. 페이지 로드 시 빈 <div role="status">를 생성하고 나중에 텍스트를 업데이트하십시오.

일반적인 ARIA 역할 실수

가장 흔한 실수는 중복 역할입니다. <button role="button">이나 <nav role="navigation">과 같은 ARIA 역할 예시는 아무런 이득 없이 마크업만 복잡하게 만듭니다. 암시적 역할이 이미 존재하기 때문입니다. 개발자가 <h2>에 role="heading"을 추가하는 것도 같은 중복입니다.

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

두 번째는 필수 상태 누락입니다. aria-checked 없는 role="checkbox", aria-valuenow 없는 role="slider", aria-expanded 없는 role="combobox"는 모두 사용자에게 오해를 불러일으키는 불완전한 안내를 생성합니다. 사양에는 각 역할에 필요한 상태와 속성이 나열되어 있으며, 자동 검사기가 누락 여부를 표시합니다.

세 번째는 잘못된 요소에 역할을 사용하는 것입니다. <a href>에 role="button"을 넣으면 링크 의미론이 무시되어 새 탭에서 열기와 같은 예상 동작이 깨집니다. 포커스 가능한 요소에 role="presentation" 또는 role="none"을 넣으면 탭 순서에는 남겨두면서 의미론만 제거하여, 정체성이 안내되지 않는 포커스 가능 요소가 생성됩니다. 또한 role="widget"이나 role="input" 같은 추상 역할을 사용하는 것은 항상 오류입니다.

마지막으로, ARIA 역할은 망가진 DOM을 고칠 수 없습니다. role="tab" 내부에 role="tabpanel"이 중첩되어 있다면, 속성을 아무리 많이 추가해도 의미 없는 트리가 생성됩니다. 먼저 구조를 수정하고 그 위에 ARIA를 입히십시오.

ARIA 역할 테스트 방법

자동화 도구는 유효성 오류는 감지하지만 의미론적 불일치는 감지하지 못하므로, ARIA 역할 테스트에는 여러 방법이 필요합니다. 먼저 axe DevTools, WAVE, Lighthouse와 같은 접근성 검사기로 잘못된 역할, 누락된 필수 속성, 마크업 내 추상 역할을 감지하십시오. 이러한 도구는 빠르며 기계적인 오류를 찾아냅니다.

그다음 스크린 리더 테스트를 진행하십시오. Windows의 Firefox+NVDA, Chrome+JAWS, macOS의 Safari+VoiceOver는 각각 접근성 트리를 다르게 노출하므로, 한 곳에서 올바르게 안내되는 역할이 다른 곳에서는 그렇지 않을 수 있습니다. 랜드마크와 제목별로 탐색하여 구조 역할이 예상한 개요를 생성하는지 확인하고, 모든 위젯을 탭하며 안내되는 역할, 상태, 키보드 동작이 일치하는지 검증하십시오.

Chrome 또는 Firefox DevTools의 접근성(Accessibility) 패널에서 접근성 트리를 직접 검사하십시오. 여기서는 모든 요소의 계산된 역할과 이름이 표시됩니다. 이를 통해 작성한 역할과 브라우저가 실제로 노출하는 역할 사이의 간극을 확인할 수 있으며, 부모 요소에 의해 재정의되거나 완전히 무시된 역할을 찾는 가장 빠른 방법입니다.

출처 및 추가 자료

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

자주 묻는 질문

ARIA 역할이란 무엇이며 어떻게 작동하나요?

ARIA 역할은 role 속성의 값으로, 스크린 리더가 요소를 올바르게 안내할 수 있도록 접근성 트리에서 요소의 정체성을 정의합니다. 이는 의미론만 변경할 뿐, 외형, 포커스 또는 키보드 동작을 변경하지 않습니다. WAI-ARIA 1.2 사양은 6가지 역할 범주와 80개 이상의 구체적인 역할을 정의하며, 각 역할에는 필수 상태와 속성이 있습니다.

기본 HTML 대신 ARIA 역할을 사용해야 하는 경우는 언제인가요?

필요한 의미론을 제공하는 기본 HTML 요소가 없을 때만 ARIA 역할을 사용하십시오. <button>, <nav>, <input type="checkbox">와 같은 기본 요소는 암시적 역할과 더불어 내장된 키보드 지원 및 상태 관리를 제공합니다. ARIA 사용의 첫 번째 규칙은 기본 의미론을 우선시하고, 커스텀 위젯이나 구조 변경이 불가능한 레거시 마크업에만 명시적 역할을 추가하는 것입니다.

ARIA 역할과 ARIA 속성의 차이점은 무엇인가요?

ARIA 역할은 “이 항목이 무엇인가”에 답하고, aria-expanded, aria-checked, aria-label과 같은 ARIA 속성은 “어떤 상태인가” 또는 “이름이 무엇인가”에 답합니다. 역할과 필수 속성은 함께 작동합니다. ARIA 역할 예시로, role="checkbox"는 aria-checked 없이는 불완전하며, role="combobox"는 aria-expanded와 제어된 listbox가 필요합니다.

모든 HTML 요소에 ARIA 역할을 사용할 수 있나요?

대부분의 요소에 ARIA 역할을 적용할 수 있지만, 일부 조합은 유효하지 않거나 해롭습니다. widget 및 input과 같은 추상 역할은 직접 작성해서는 안 됩니다. 링크의 역할을 role="button"으로 변경하면 링크의 예상 동작이 깨지며, 포커스 가능한 요소에 role="presentation"을 사용하면 탭 순서에는 남겨두면서 의미론만 제거하게 됩니다.

ARIA 역할은 JavaScript 없이도 작동하나요?

문서 구조와 랜드마크 역할은 의미 체계만 수정하므로 JavaScript 없이 작동합니다. tab, slider 및 combobox와 같은 위젯 역할에는 키보드 상호 작용 및 상태 업데이트를 구현하기 위해 JavaScript가 필요합니다. JavaScript가 없으면 요소는 컨트롤로 안내되지만 컨트롤처럼 동작하지 않습니다. 이는 일반 HTML보다 더 나쁩니다.

내 ARIA 역할이 올바른지 어떻게 확인하나요?

자동 테스트와 수동 테스트를 결합합니다. axe DevTools, WAVE 또는 Lighthouse를 실행하여 잘못된 역할과 누락된 필수 속성을 검색한 다음 NVDA, JAWS 및 VoiceOver를 테스트하여 음성 안내 및 키보드 동작을 확인하세요. Chrome 및 Firefox DevTools의 접근성 패널에는 계산된 역할이 표시되어 브라우저가 재정의하거나 무시하는 모든 역할을 보여줍니다.