ARIA란 무엇인가요?
ARIA를 사용하면 웹 작성자가 스크린 리더에만 표시되는 대체 현실을 만들 수 있습니다.
스크린 리더에 웹 콘텐츠에서 일어나고 있는 일에 관해 진실을 자세히 설명하거나 심지어 '거짓말'을 해야 하는 경우가 있습니다. 예를 들어 '포커스가 정말 끝났습니다!' 또는 '이것은 정말 슬라이더입니다!'와 같습니다. 워크벤치의 도구와 위젯 위에 마법의 스티커 메모를 추가하는 것과 같습니다. 이 마법의 스티커 메모는 모든 사람이 메모에 적힌 내용을 믿게 만듭니다.
마법의 스티커 메모가 있으면 각 도구의 기능이나 역할에 대한 우리의 믿음을 무시하게 됩니다. 예를 들어 '여기 있는 물건은 글루건입니다'라는 ARIA를 추가하는 경우 빈 파란색 상자이지만 마법의 스티커 메모를 통해 글루건임을 알 수 있습니다. '30% 충전되어 있습니다'라고 추가할 수도 있습니다. 이제 화면 리더가 30% 충전된 글루건이 있다고 보고합니다.
웹에서 이에 상응하는 방법은 이미지가 포함된 일반 div를 사용하고 ARIA를 사용하여 100점 만점에 30점인 슬라이더라고 지정하는 것입니다. ARIA는 div를 슬라이더로 만들지 않습니다. 스크린 리더에 슬라이더라고 말하도록 지시할 뿐입니다.
ARIA는 웹페이지의 모양이나 마우스나 키보드 사용자의 동작에 영향을 미치지 않습니다. 보조 기술 사용자만 ARIA의 영향을 확인할 수 있습니다. 웹 개발자는 보조 기술을 실행하지 않는 사용자에게 영향을 미치지 않고 임의의 ARIA를 추가할 수 있습니다.
제대로 알았습니다. ARIA는 실제로 키보드 포커스나 탭 순서에 아무런 작업을 하지 않습니다. 이 모든 과정이 HTML로 이루어지며, JavaScript로 약간 변형하기도 합니다.
ARIA는 어떻게 작동하나요?
스크린 리더나 기타 보조 기술에서 브라우저에 각 요소에 관한 정보를 요청합니다. ARIA가 요소에 존재하면 브라우저에서 정보를 가져와 해당 요소에 관해 스크린 리더에 알리는 내용을 변경합니다.
다음은 ARIA의 몇 가지 일반적인 사용 사례입니다.
- 자동 완성, 트리, 스프레드시트와 같이 HTML에 없는 특수 구성요소를 추가합니다.
- HTML에 존재하지만 작성자가 표준 요소의 동작이나 모양을 변경하기 위해 재창조해야 한다고 결정한 구성요소를 추가합니다. 예를 들어 HTML
<input type="range">요소는 기본적으로 슬라이더이지만 작성자는 다르게 보이려고 합니다.- 대부분의 경우 CSS로 해결할 수 있습니다. 그러나
range의 경우 CSS가 awkwARD입니다. 작성자는 자체 슬라이더를 만들고aria-valuenow와 함께role="slider"를 사용하여 키보드에 현재 값을 알릴 수 있습니다.
- 대부분의 경우 CSS로 해결할 수 있습니다. 그러나
- 라이브 영역을 포함하여 스크린 리더에 페이지의 특정 영역과 관련된 변경사항을 알립니다.
- 제목과 같은 랜드마크를 만듭니다. 랜드마크는 스크린 리더 사용자가 원하는 항목을 더 빠르게 찾는 데 도움이 됩니다. 랜드마크는 관련된 영역 전체를 포함할 수 있습니다. 예를 들어 '이 컨테이너는 페이지의 기본 영역입니다', '여기 있는 이 컨테이너는 탐색 패널입니다'와 같이 설명할 수 있습니다.
ARIA를 사용해야 하는 이유
이미 작동하는 HTML에 일부 ARIA를 추가하는 것이 유용할 수 있습니다. 예를 들어 양식 컨트롤이 잘못된 입력의 오류 메시지 알림을 가리키도록 할 수 있습니다. 또는 텍스트 입력의 특정 용도를 나타내려 할 수도 있습니다. 이러한 조정을 통해 스크린 리더로 일반 웹사이트를 더 유용하게 사용할 수 있습니다.
메뉴 바 예
현지 웹 스토어에서 필요한 모든 위젯을 판매하지 않는다고 가정해 보겠습니다. 하지만 YouTube는 MacGyver입니다. 다른 위젯에서 나만의 위젯을 만들 수 있습니다. 이는 메뉴 바를 만들어야 하는 웹 작성자와 매우 유사합니다.
<nav> 요소가 있지만 메뉴 바는 div, 이미지, 버튼, 클릭 핸들러, 키 누르기 핸들, ARIA를 사용하여 종종 함께 조합됩니다.
마우스 사용자 지원
함께 메뉴 바를 만들어 보겠습니다. 여기서는 div라고 하는 일반 상자 요소에 여러 항목을 표시합니다. 사용자가 div를 클릭할 때마다 해당 명령어가 실행됩니다. 좋습니다. 마우스 클릭 사용자에게도 작동합니다.
다음으로 멋지게 만듭니다. CSS를 사용하여 요소를 깔끔하게 정렬하고 그 주위에 시각적 윤곽선을 적용합니다. 사용자가 메뉴 바임을 직관적으로 알 수 있도록 다른 메뉴 바와 유사하게 보이도록 합니다. 메뉴 바는 마우스가 있는 모든 항목에 다른 배경 색상도 사용하여 사용자에게 유용한 시각적 피드백을 제공합니다.
일부 메뉴는 상위 메뉴입니다. 하위 메뉴를 생성합니다. 사용자가 이러한 아이콘 중 하나 위로 마우스를 가져갈 때마다 하위 하위 메뉴가 슬라이드 아웃되는 애니메이션이 시작됩니다.
웹의 많은 것들에 대한 일반적인 사례처럼 이 모든 것은 거의 액세스할 수 없습니다.
메뉴 바 키보드 액세스 가능하도록 만들기
키보드 접근성을 추가해 보겠습니다. 이렇게 하려면 ARIA가 아닌 HTML만 변경하면 됩니다. ARIA는 보조 기술이 없는 사용자의 경우 모양, 마우스, 키보드와 같은 핵심적인 측면에 영향을 미치지 않습니다.
웹페이지가 마우스에 응답할 수 있는 것처럼 키보드에도 응답할 수 있습니다. JavaScript는 발생하는 모든 키 입력을 리슨하고 키 누르기가 유용한지 결정할 수 있습니다. 그렇지 않으면 먹을 정도로 작은 물고기처럼 페이지에 다시 광고를 표시합니다. Google의 규칙은 다음과 같습니다.
- 사용자가 화살표 키를 누르면 자체 내부 메뉴 바 블루프린트를 살펴보고 새 활성 메뉴 항목을 결정해 보겠습니다. 현재 강조 표시를 모두 지우고 시각 장애가 없는 사용자가 현재 위치를 시각적으로 알 수 있도록 새 메뉴 항목을 강조 표시합니다. 그런 다음 웹페이지에서는
event.preventDefault()를 호출하여 브라우저가 일반적인 작업 (이 경우에는 페이지 스크롤)을 실행하지 못하게 합니다. - 사용자가 Enter 키를 누르면 이를 클릭과 마찬가지로 처리하고 적절한 작업을 실행하거나 다른 메뉴를 열 수도 있습니다.
- 사용자가 다른 작업을 실행해야 하는 키를 누르면 페이지로 다시 전송합니다. 예를 들어 메뉴 바에는 탭 키가 필요하지 않으므로 다시 던져줍니다. 이 작업은 쉽지 않습니다. 예를 들어 메뉴 바에는 화살표 키가 필요하지만 Alt+화살표 또는 Command+화살표는 필요하지 않습니다. 브라우저 탭의 웹 기록에서 이전 페이지와 다음 페이지로 이동하는 바로가기입니다. 작성자가 주의하지 않으면 메뉴 바가 이를 사용합니다. 이러한 유형의 버그는 자주 발생하며 아직 ARIA를 시작하지 않았습니다.
스크린 리더의 메뉴 바 액세스
메뉴 바는 덕트 테이프와 div로 만들었습니다. 따라서 스크린 리더는 어떤 항목인지 알 수 없습니다. 활성 항목의 배경색은 단지 색상일 뿐입니다. 메뉴 항목 div는 특별한 의미가 없는 일반 객체입니다. 따라서 메뉴 바 사용자는 어떤 키를 누르거나 어떤 항목에 있는지에 관한 안내를 받지 못합니다.
하지만 불공평해! 메뉴 바는 시각 장애가 없는 사용자에게는 제대로 작동합니다.
ARIA가 구원해 줍니다. ARIA를 사용하면 스크린 리더에 포커스가 메뉴 바에 있다고 속일 수 있습니다. 작성자가 모든 작업을 올바르게 수행하면 맞춤 메뉴 바가 화면 리더에 데스크톱 애플리케이션의 메뉴 바처럼 표시됩니다.
첫 번째 ARIA 거짓말은 aria-activedescendant 속성입니다. 활성 메뉴 항목의 ID로 속성을 설정하고 변경될 때마다 업데이트합니다. 예를 들면 aria-activedescendant="settings-menuitem"입니다. 이렇게 하면 화면 리더가 ARIA 활성 항목을 포커스로 간주하여 소리 내어 읽거나 점자 디스플레이에 표시합니다.
하위 요소라는 용어는 항목이 다른 항목 내에 포함되어 있다는 사실을 나타냅니다. 반대 용어는 상위라는 용어입니다. 즉, 항목은 상위 항목에 의해 포함됩니다. 다음 컨테이너 위/아래에는 상위/하위라는 좀 더 구체적인 용어를 사용할 수 있습니다. 예를 들어 내부에 링크가 있는 단락이 있는 문서를 가정해 보겠습니다. 링크의 상위 요소는 단락이지만 문서도 상위 요소로 포함됩니다. 반대로 문서에는 각각 링크가 있는 여러 단락 하위 요소가 있을 수 있습니다. 링크는 모두 조부모 문서의 자손입니다.
aria-activedescendant를 사용하여 포커스가 있는 메뉴 바에서 특정 메뉴 항목으로 가리키면 이제 스크린 리더는 사용자가 이동한 위치를 알 수 있지만 객체에 대한 다른 정보는 알 수 없습니다. 이 div란 무엇인가요? 여기서 역할 속성이 사용됩니다. 전체를 포함하는 요소에는 role="menubar"를 사용하고, 항목 그룹에는 role="menu"를 사용하고, 드럼롤… 개별 메뉴 항목에는 role="menuitem"를 사용합니다.
메뉴 항목이 하위 메뉴로 연결될 수 있다면 어떻게 해야 하나요? 사용자가 이를 알아야 합니다.
시각 장애가 없는 사용자의 경우 메뉴 끝에 작은 삼각형 그림이 있을 수 있지만, 적어도 현재로서는 화면 리더가 이미지를 자동으로 읽는 방법을 모릅니다. 각 확장형 메뉴 항목에 aria-expanded="false"를 추가하여 펼칠 수 있는 항목이 있고 펼쳐지지 않는 항목이 있음을 나타낼 수 있습니다. 또한 작성자는 미용 목적으로만 사용됨을 나타내기 위해 img 삼각형에 role="none"를 표시해야 합니다. 이렇게 하면 스크린 리더가 중복된 이미지에 관해 말하지 못합니다.
키보드 버그 수정
키보드 액세스는 핵심 HTML의 일부이지만 쉽게 덮어쓸 수 있습니다. 예를 들면 다음과 같습니다.
- 체크박스에서 스페이스바를 사용하여 전환하지만 작성자가
preventDefault()를 호출하지 않았습니다. 이제 스페이스바를 누르면 체크박스와 페이지가 아래로 이동합니다. 이는 스페이스바의 기본 브라우저 동작입니다. - ARIA 모달 대화상자에서 탭 탐색을 내부에 트래핑하려고 합니다. 작성자가 대화상자에서 Control+Tab 키를 눌러 새 탭을 열도록 구체적으로 허용하지 않으면 예상대로 작동하지 않습니다.
- 작성자가 선택 목록을 만들고 위쪽 및 아래쪽 키를 구현합니다. 하지만 개발자는 여전히 홈, 끝, 페이지 위로, 페이지 아래로 또는 첫 글자 탐색을 추가해야 합니다.
저자는 알려진 패턴을 따라야 합니다. 자세한 내용은 리소스 섹션을 참고하세요.
순수한 키보드 액세스 문제의 경우 스크린 리더 없이 또는 가상 브라우저 모드를 사용 중지한 상태에서 시도해 보는 것도 유용합니다. 키보드 액세스는 ARIA가 아닌 HTML로 구현되므로 스크린 리더 없이도 키보드 버그를 발견할 수 있습니다. 결국 ARIA는 키보드나 마우스 동작에 영향을 미치지 않습니다. 대신 웹페이지의 내용, 현재 포커스가 있는 항목 등에 관해 화면 리더에 거짓말을 합니다.
키보드 버그는 거의 항상 ARIA가 아닌 웹 콘텐츠, 특히 HTML 및 JavaScript의 버그입니다.
왜 이렇게 많은가요?
작성자가 ARIA를 잘못 이해하는 경우는 여러 가지가 있습니다. 실수가 있을 때마다 완전히 중단되거나 미묘한 차이가 발생합니다. 저자가 게시하기 전에 이러한 미묘한 문제를 발견할 가능성이 낮기 때문에 더 심각할 수 있습니다.
결국 작성자가 숙련된 스크린 리더 사용자인 경우가 아니라면 ARIA에 문제가 발생할 것입니다. 메뉴 바 예시에서 작성자는 'menuitem'이 올바른 경우 'option' 역할이 사용되어야 한다고 생각할 수 있습니다. aria-expanded를 사용하지 못하거나 적절한 시점에 aria-activedescendant를 설정하고 지우지 못하거나 다른 메뉴가 포함된 메뉴 바를 잊어버릴 수 있습니다.
메뉴 항목 수는 어떻게 되나요? 일반적으로 메뉴 항목은 스크린 리더가 '항목 3/5'와 같은 형태로 표시되므로 사용자가 메뉴 항목을 알 수 있습니다. 일반적으로 브라우저에서 자동으로 계산되지만 경우에 따라, 그리고 일부 브라우저 - 스크린 리더 조합에서는 잘못된 숫자가 계산될 수 있으며 작성자가 이러한 숫자를 aria-posinset 및 aria-setsize로 재정의해야 합니다.
메뉴 바만 표시됩니다. 위젯의 종류가 얼마나 많은지 생각해 보세요. 원하는 경우 ARIA 사양 또는 작성 관행을 살펴보세요. 각 패턴에 대해 ARIA가 오용될 수 있는 방법은 12가지가 있습니다. ARIA는 작성자가 자신이 무엇을 하고 있는지 알고 있다고 가정합니다. 대부분의 작성자가 스크린 리더 사용자가 아니므로 어떤 문제가 발생할 수 있나요?
즉, ARIA 위젯을 출시할 수 있다고 간주되기 전에 실제 스크린 리더 사용자가 위젯을 사용해 보는 것이 절대적으로 필요합니다. 너무 많은 뉘앙스가 있습니다. 몇 가지 불완전한 구현 외에도 구현 관련 다양한 버그가 있으므로 여러 브라우저-스크린 리더 조합으로 모든 것을 테스트하는 것이 좋습니다.
요약
ARIA는 HTML에서 언급하는 모든 항목을 재정의하거나 추가하는 데 사용할 수 있습니다. 접근성 프레젠테이션을 약간 변경하거나 전체 환경을 빌드할 수 있습니다. 따라서 ARIA는 매우 강력하면서도 스크린 리더 사용자가 아닌 개발자에게는 위험합니다.
ARIA는 다른 선택사항보다 우선 적용되는 마크업 레이어입니다. 화면 리더가 무슨 일이 일어나고 있는지 묻는 경우 ARIA가 있으면 사용자는 ARIA 버전의 진실을 확인할 수 있습니다.
추가 리소스
W3C의 ARIA 작성 관행은 각 예시의 중요한 키보드 탐색 특성을 문서화하고 작동하는 JavaScript, CSS, ARIA를 제공합니다. 예시는 현재 작동하는 항목에 중점을 두며 모바일은 다루지 않습니다.
접근성 API란 무엇인가요?
접근성 API는 스크린 리더 또는 기타 보조 기술이 페이지의 내용과 상황을 파악하는 방법입니다. 예를 들면 MSAA, IA2, UIA가 있습니다. 접근성 API는 두 부분으로 구성됩니다.
- 컨테이너 계층 구조를 나타내는 객체의 '트리'입니다. 예를 들어 한 문서는 여러 개의 단락을 포함할 수 있습니다. 단락에는 텍스트, 이미지, 링크, 텍스트 장식이 포함될 수 있습니다. 객체 트리의 각 항목에는 역할(내가 무엇인가요?), 이름 또는 라벨, 사용자가 입력한 값, 설명, 불리언 상태(예: 포커스 가능, 포커스됨, 필수, 선택됨)와 같은 속성이 있을 수 있습니다. ARIA는 이러한 속성을 재정의할 수 있습니다.
- 스크린 리더는 사용자가 가상 버퍼 모드에서 탐색하는 데 도움이 되는 트리를 사용합니다(예: '다음 제목으로 이동하세요').
- '포커스가 여기로 이동했습니다'와 같이 트리의 변경사항을 설명하는 일련의 이벤트입니다. 스크린 리더는 이벤트를 사용하여 사용자에게 방금 발생한 상황을 알려줍니다. 중요한 HTML 또는 ARIA 마크업이 변경되면 이벤트가 실행되어 스크린 리더에 변경사항이 있음을 알립니다.
HTML은 이러한 접근성 API에 잘 매핑됩니다. HTML이 충분하지 않은 경우 ARIA를 추가하여 브라우저가 스크린 리더에 객체 트리 또는 이벤트를 전송하기 전에 HTML 시맨틱스를 재정의하도록 할 수 있습니다.