ARIA
고친 사람 github-actions[bot]
ARIA 는 화면을 못 보는 사용자에게 웹 페이지의 부품이 무엇이고 지금 어떤 상태인지 알려 줍니다. 태그에 속성 몇 개를 덧붙여서 알립니다. 글을 소리로 읽어 주는 프로그램이 그 속성을 읽습니다. 그리고 「버튼」「펼쳐짐」 같은 말로 사용자에게 전합니다.
쉽고 빠른 이해
ARIA 는 웹 페이지의 태그에 「이건 무엇이고 지금 어떤 상태다」라는 이름표를 붙입니다. 아무 뜻 없는 상자 태그로 짠 메뉴 버튼에 「이건 버튼이고 지금 메뉴가 열려 있다」를 붙이는 식입니다.
이게 없으면 화면에서 버튼처럼 보이는 부품도 읽어 주는 프로그램에게는 글자 덩어리일 뿐입니다. 사용자는 그걸 누를 수 있는지, 메뉴가 열렸는지 알 길이 없습니다.
- 태그에 역할을 적습니다. 버튼인지 탭인지를 적습니다
- 이름과 상태를 속성으로 적습니다. 무슨 버튼인지, 열렸는지를 적습니다
- 브라우저가 이 정보를 모읍니다. 읽어 주는 프로그램이 그걸 말로 전합니다
대가는 알려 주기만 한다는 것입니다. 버튼이라고 적어도 키보드로 눌리게 만드는 일은 직접 해야 합니다. 틀리게 적으면 안 적은 것보다 사용자를 더 헤매게 합니다.
그래서 버튼처럼 뜻이 맞는 태그가 이미 있으면 그 태그를 씁니다. ARIA 는 탭처럼 맞는 태그가 없는 부품에만 붙입니다.
상세
ARIA 가 무엇을 누구에게 알리는지부터 봅니다. 알림을 받는 프로그램과 브라우저가 넘기는 정보가 먼저 나옵니다. 그다음 화면에서 똑같아 보이는 버튼이 화면을 못 보는 사용자에게는 다르게 전해지는 까닭을 봅니다. 끝으로 ARIA 가 그 차이를 어떻게 메우는지와 언제 쓰는지로 넓혀 갑니다.
ARIA(Accessible Rich Internet Applications, 접근 가능한 리치 인터넷 애플리케이션)는 웹 접근성을 위한 표준입니다. 접근성은 장애가 있는 사람도 웹 페이지를 똑같이 쓸 수 있게 하는 성질입니다.
리치 인터넷 애플리케이션은 페이지를 새로 불러오지 않고 자바스크립트로 화면 일부를 바꾸는 웹 애플리케이션입니다. 메일 목록에서 한 통을 누르면 옆에 본문이 뜨는 웹 메일이 그런 예입니다. ARIA 는 이런 애플리케이션을 화면을 못 보는 사용자도 쓸 수 있게 하려고 나왔습니다.
보조 기술과 스크린 리더
보조 기술은 장애가 있는 사용자가 컴퓨터를 쓰도록 돕는 소프트웨어와 기기입니다. 화면 글자를 크게 키우는 확대 프로그램, 목소리로 누르고 입력하는 음성 제어가 보조 기술입니다.
스크린 리더는 그중 화면을 못 보는 사용자가 쓰는 보조 기술입니다. 화면의 글과 부품을 소리나 점자로 읽어 줍니다. 사용자는 키보드로 부품 사이를 옮겨 다닙니다. 부품에 닿을 때마다 「저장, 버튼」 같은 안내를 듣습니다.
접근성 트리
스크린 리더는 화면에 그려진 그림을 보지 않습니다. 브라우저가 따로 만들어 넘기는 정보를 읽습니다. 그 정보가 접근성 트리입니다.
브라우저는 HTML(HyperText Markup Language) 문서를 읽어 태그마다 객체를 하나씩 만듭니다. 이 객체들을 나무 모양으로 이은 것이 DOM(Document Object Model, 문서 객체 모델)입니다. 브라우저는 DOM 에서 보조 기술에 필요한 정보만 추려 접근성 트리를 하나 더 만듭니다.
접근성 트리의 마디마다 세 가지가 붙습니다. 무엇인지를 뜻하는 역할, 무엇이라 부르는지를 뜻하는 이름, 지금 어떤지를 뜻하는 상태입니다. 「약관 동의」라는 글이 붙은 체크박스라면 역할은 체크박스, 이름은 약관 동의, 상태는 체크됨이나 안 됨입니다.
flowchart TD
A["HTML 태그와 ARIA 속성"] --> B["브라우저"]
B --> C["화면 · 눈으로 보는 사용자"]
B --> D["접근성 트리 · 역할 · 이름 · 상태"]
D --> E["스크린 리더 · 소리나 점자"]
그림처럼 브라우저는 같은 문서에서 두 갈래를 만듭니다. 화면은 눈으로 보는 사용자에게 갑니다. 접근성 트리는 스크린 리더를 거쳐 화면을 못 보는 사용자에게 갑니다. ARIA 속성은 접근성 트리 쪽 갈래만 바꿉니다. 화면에 보이는 모양과 동작은 바뀌지 않습니다.
뜻 없는 태그로 짠 부품
<button> 같은 태그는 역할을 스스로 갖고 있습니다. 그런데 웹 애플리케이션은 <div> 로 부품을
짜는 일이 많습니다. <div> 는 아무 역할도 없는 상자 태그입니다.
아래 세 줄은 스타일만 입히면 화면에서 똑같은 버튼으로 보입니다. 오른쪽 주석은 브라우저가 접근성 트리에 올리는 역할입니다.
<button>저장</button> <!-- 버튼 -->
<div>저장</div> <!-- 없음 -->
<div role="button">저장</div> <!-- 버튼 -->
둘째 줄은 스크린 리더에게 「저장」이라는 글자일 뿐입니다. 사용자는 이걸 누를 수 있다는 것을
모릅니다. 셋째 줄은 role 속성으로 역할을 적어 이 빈틈을 메웁니다.
HTML 에 태그가 아예 없는 부품도 있습니다. 탭, 트리 메뉴, 글을 치면서 목록에서 고르는 입력창인 콤보박스가 그렇습니다. 이런 부품은 뜻 없는 태그로 짤 수밖에 없습니다. ARIA 가 없으면 이 부품들은 스크린 리더 사용자에게 무엇인지 전해지지 않습니다.
역할 · 상태 · 프로퍼티
ARIA 가 적는 정보는 역할 · 상태 · 프로퍼티 세 종류입니다. 셋 다 태그의 속성으로 적습니다.
| 종류 | 알리는 것 | 예 |
|---|---|---|
| 역할 | 이 부품이 무엇인가 | role="tab" · role="dialog" |
| 상태 | 지금 어떤가. 사용자가 만지면 자주 바뀐다 | aria-expanded="true" · aria-checked="false" |
| 프로퍼티 | 이름과 다른 부품과의 관계. 잘 안 바뀐다 | aria-label="닫기" · aria-controls="menu1" |
프로퍼티는 ARIA 가 property 라고 부르는 종류입니다. HTML 태그의 속성과 헷갈리지 않게 이 글에서는 프로퍼티라고 씁니다.
접근성 트리의 세 가지와 견주면 역할과 상태는 그대로 이어집니다. 트리의 이름은 ARIA 에서 프로퍼티로
적습니다. aria-label 이 그 프로퍼티입니다. 프로퍼티에는 이름 말고 다른 부품과의 관계도 들어갑니다.
역할은 role 속성 하나로 적습니다. 상태와 프로퍼티는 둘 다 aria- 로 시작해서 겉으로는
구분이 안 됩니다. 가르는 기준은 얼마나 자주 바뀌나입니다.
메뉴를 열고 닫을 때마다 바뀌는 aria-expanded 는 상태입니다. 부품의 이름을 정하는
aria-label 은 프로퍼티입니다. aria-controls 는 이 버튼이 어느 부품을 여닫는지 가리킵니다. 가리킬 때는
태그마다 붙이는 고유 이름인 id 를 씁니다.
글자 없는 버튼의 이름
아이콘만 있는 닫기 버튼은 안에 글자가 없습니다. 스크린 리더는 이름을 찾지 못해 「버튼」이라고만 읽습니다. 사용자는 무슨 버튼인지 모릅니다.
아래처럼 aria-label 로 이름을 적습니다. 주석은 스크린 리더가 이 버튼의 이름으로 읽는 말입니다.
<button aria-label="닫기"> <!-- 닫기 -->
<svg aria-hidden="true">…</svg>
</button>
svg 는 아이콘 그림을 그리는 태그입니다. 여기 붙은 aria-hidden 은 그 그림을 접근성 트리에서 뺍니다. 이름은 버튼이 이미 가졌으니
그림까지 따로 읽을 까닭이 없습니다.
바뀌는 상태를 맞춰 두기
ARIA 속성은 한 번 적고 끝나지 않습니다. 메뉴 버튼을 눌러 메뉴가 열리면 자바스크립트가
aria-expanded 를 false 에서 true 로 바꿔야 합니다.
이걸 빠뜨리면 화면에서는 메뉴가 열렸는데 스크린 리더는 닫혔다고 읽습니다. 브라우저는 ARIA 속성을 알아서 고치지 않습니다. 화면을 바꾸는 코드가 속성도 함께 바꿔야 합니다.
라이브 리전
사용자가 건드리지 않았는데 화면 일부가 바뀌는 때가 있습니다. 「장바구니에 담았습니다」 알림이 뜨거나 채팅 메시지가 새로 올라오는 때입니다. 스크린 리더는 사용자가 옮겨 간 부품을 읽으므로 이런 변화를 놓칩니다.
aria-live 속성을 붙인 영역을 라이브 리전이라 부릅니다. 이 영역의 내용이 바뀌면 스크린 리더가
새 내용을 읽어 줍니다. 사용자는 있던 부품에서 움직이지 않아도 됩니다.
읽는 때는 속성 값으로 고릅니다. aria-live="polite" 는 하던 안내를 마친 뒤에 읽습니다.
aria-live="assertive" 는 하던 안내를 끊고 바로 읽습니다. 끊기면 사용자가 듣던 것을 놓치므로
급한 알림에만 씁니다.
HTML 태그가 먼저
ARIA 를 쓸 때 가장 먼저 따르는 원칙이 있습니다. 뜻이 맞는 HTML 태그가 있으면 ARIA 대신 그 태그를 씁니다. 이렇게 뜻에 맞는 태그를 골라 쓰는 방식을 시맨틱 마크업이라 부릅니다.
까닭은 ARIA 가 알리기만 하기 때문입니다. 키보드 입력을 받을 차례가 된 부품을 포커스를 받았다고
합니다. <div role="button"> 은 버튼이라고 알릴 뿐 Tab 키로 포커스를 받지도, Enter 키에 눌리지도
않습니다.
그렇게 만들려면 할 일이 둘 붙습니다. tabindex 속성을 0 으로 적어 Tab 키로 포커스가 오게
합니다. 그리고 Enter 와 스페이스 키를 받는 코드를 자바스크립트로 짭니다. <button> 은 이 둘을
처음부터 갖고 있습니다.
틀린 ARIA 는 없는 것보다 나쁩니다. 버튼이라고 알렸는데 눌리지 않으면 사용자는 고장 난 페이지로
압니다. 포커스를 받는 부품에 aria-hidden="true" 를 붙이면 포커스는 가는데 스크린 리더는 아무것도
못 읽습니다.
ARIA 를 쓰는 경우
지금까지 본 것을 상황별로 모으면 아래와 같습니다.
| 상황 | 쓰는 것 |
|---|---|
| 버튼 · 링크 · 체크박스처럼 HTML 태그가 있는 부품 | 그 태그. ARIA 를 안 붙인다 |
| 탭 · 트리 메뉴 · 콤보박스처럼 태그가 없는 부품 | role 과 상태 속성, 키보드 처리 코드 |
| 글자 없이 아이콘만 있는 버튼 | aria-label |
| 사용자가 안 건드려도 바뀌는 알림 | aria-live |
| 꾸밈으로만 넣은 그림 | aria-hidden="true" |
표의 첫 줄이 나머지보다 앞섭니다. 아래 줄들은 첫 줄로 풀리지 않을 때만 봅니다.
W3C 와 WCAG
ARIA 곁에는 같은 단체가 펴내는 접근성 표준이 하나 더 있습니다. 그 단체와 두 표준이 일을 어떻게 나누는지 봅니다.
ARIA 는 W3C(World Wide Web Consortium, 월드 와이드 웹 컨소시엄)가 펴냅니다. W3C 는 웹 규격을 여러 회원의 합의로 정하는 단체입니다.
W3C 안에서 접근성을 맡는 곳이 WAI(Web Accessibility Initiative, 웹 접근성 이니셔티브)입니다. ARIA 를 여기서 만들어서 WAI-ARIA 라고도 부릅니다.
W3C 는 WCAG(Web Content Accessibility Guidelines, 웹 콘텐츠 접근성 지침)도 펴냅니다. WCAG 는 웹 페이지가 무엇을 지켜야 하는지를 정합니다. 모든 부품에 이름이 있어야 한다는 것이 그런 요구입니다.
ARIA 는 그 요구를 지키는 수단 가운데 하나입니다. WCAG 가 「이름이 있어야 한다」를 정하면, ARIA 는 「이름을 이렇게 적는다」를 정합니다.
관련 항목
ARIA 와 함께 웹 접근성을 정하는 표준과 기관
ARIA 를 이루는 역할과 속성
role · aria-label · aria-labelledby · aria-describedby · aria-hidden · aria-expanded · aria-selected · aria-checked · aria-controls · aria-live
ARIA 정보를 받아 사용자에게 전하는 보조 기술
보조 기술 · 스크린 리더 · 점자 디스플레이 · 화면 확대기 · 음성 제어
ARIA 정보가 거쳐 가는 브라우저 구조
브라우저 · 접근성 트리 · 접근성 API · 렌더 트리
ARIA 보다 먼저 쓰는 HTML 수단
시맨틱 마크업 · alt 속성 · 대체 텍스트 · label 요소
ARIA 부품에 키보드 조작을 붙이는 수단
포커스 · tabindex · JavaScript · 키보드 접근성
ARIA 로 역할을 알리는 사용자 정의 위젯
탭 패널 · 콤보박스 · 모달 대화상자 · 트리 뷰 · 메뉴 버튼 · 라이브 리전
ARIA 가 속하는 상위 분야와 참고 문서
다른 이름: WAI-ARIA · Accessible Rich Internet Applications