ARIA 접근성 가이드

역할 · 문서 구조

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영역 안의 포커스 가능한 요소로 이동합니다. 나머지 키 동작은 작성자가 직접 구현해야 합니다.

사용 예

독자적 조작 방식의 편집 영역

HTML
<div role="application" tabindex="0"
     aria-label="슬라이드 편집"
     aria-roledescription="슬라이드 편집기"
     aria-describedby="help">
  …
</div>
<p id="help">화살표 키로 선택한 개체를 옮기고, Delete 키로 지웁니다.</p>

페이지 전체에 application (비권장)

비권장HTML
<body role="application">
  <h1>쇼핑몰</h1>
  …
</body>

제목·목록·문단을 읽기 모드로 읽을 수 없게 됩니다.

화면낭독기에서는

화면낭독기 안내 예시 (표현은 화면낭독기·브라우저·버전에 따라 조금씩 다릅니다)
상황들리는 안내 (예)
영역에 포커스가 들어감슬라이드 편집, 슬라이드 편집기 (포커스 모드로 전환)

사용 지침

이렇게 쓰세요

  • 표준 위젯 역할로 표현할 수 없는 조작에만 제한적으로 씁니다.
  • 조작 방법을 aria-describedby로 안내합니다.

이렇게 쓰지 마세요

  • <body>나 본문 전체에 쓰지 않습니다.
  • 메뉴·탭·그리드 등 기존 위젯 위에 덧씌우지 않습니다.

참고 자료