역할 · 문서 구조
role="application"
표준 위젯 역할로 표현할 수 없는 독자적인 키보드 조작 영역을 만들 때 씁니다. 화면낭독기의 읽기 모드 키 가로채기를 멈추게 합니다.
심화
한눈에 보기
- 분류
- 문서 구조
- 대응 HTML
- 없음
- 이름 정하는 방법
- 작성자 (author)
- 이름 필수
- 예
- 필수 상위 요소
- 없음
- 필수 하위 요소
- 없음
설명
화면낭독기(NVDA·JAWS 등)는 웹 문서를 읽을 때 읽기(가상 커서) 모드에서 화살표 키, 글자 키를 가로채 낭독 이동에 씁니다. application 영역 안으로 들어가면 화면낭독기는 대부분의 키를 웹 페이지에 그대로 넘기는 포커스(응용 프로그램) 모드로 바뀝니다. 슬라이드 편집기처럼 화살표 키로 개체를 옮기는, 어떤 위젯 역할에도 맞지 않는 조작 방식이 필요할 때만 씁니다.
왜 거의 쓰지 않나
- 메뉴, 탭, 그리드, 트리, 리스트박스 등 대부분의 위젯은 이미 해당 역할이 있고, 그 역할이 포커스 모드 전환을 처리합니다.
application을 덧씌울 이유가 없습니다. - application 안에서는 화면낭독기의 제목·목록 이동 같은 읽기 기능을 쓸 수 없습니다. 페이지 전체(
<body>)에 붙이면 사실상 문서를 읽을 수 없게 됩니다. - 안의 정적 텍스트는 포커스 가능한 요소에
aria-labelledby/aria-describedby로 연결하거나, 포커스 가능한document/article요소 안에 두거나, 라이브 리전으로 알려야만 사용자가 접근할 수 있습니다(명세의 MUST 요구 사항).
이름이 필수이며, 조작 방법은 aria-describedby로 안내하고, 필요하면 aria-roledescription으로 “슬라이드 편집기” 같은 사람이 읽을 수 있는 역할 설명을 줍니다.
마지막 수단
먼저 기존 위젯 역할과 APG 패턴으로 해결할 수 없는지 확인하세요. 잘못 쓴 application은 화면낭독기 사용자가 내용을 전혀 읽지 못하게 만드는 심각한 오류가 됩니다.
테스터 관점
role="application"이 넓은 영역(본문, 페이지 전체)에 붙어 있지 않은지 확인합니다. 들어갔을 때 모든 정보에 키보드로 접근할 수 있는지, 조작 안내가 있는지 점검합니다.
함께 쓰는 속성
지원 속성
전역 속성(이름·설명 등)은 모든 역할에 쓸 수 있어 생략했습니다.
키보드 동작
| 키 | 동작 |
|---|---|
| Tab | 영역 안의 포커스 가능한 요소로 이동합니다. 나머지 키 동작은 작성자가 직접 구현해야 합니다. |
사용 예
독자적 조작 방식의 편집 영역
<div role="application" tabindex="0"
aria-label="슬라이드 편집"
aria-roledescription="슬라이드 편집기"
aria-describedby="help">
…
</div>
<p id="help">화살표 키로 선택한 개체를 옮기고, Delete 키로 지웁니다.</p>페이지 전체에 application (비권장)
<body role="application">
<h1>쇼핑몰</h1>
…
</body>제목·목록·문단을 읽기 모드로 읽을 수 없게 됩니다.
화면낭독기에서는
| 상황 | 들리는 안내 (예) |
|---|---|
| 영역에 포커스가 들어감 | 슬라이드 편집, 슬라이드 편집기 (포커스 모드로 전환) |
사용 지침
이렇게 쓰세요
- 표준 위젯 역할로 표현할 수 없는 조작에만 제한적으로 씁니다.
- 조작 방법을
aria-describedby로 안내합니다.
이렇게 쓰지 마세요
<body>나 본문 전체에 쓰지 않습니다.- 메뉴·탭·그리드 등 기존 위젯 위에 덧씌우지 않습니다.