스크린 리더에 거짓말을 하면 접근성이 개선됩니다.
ARIA란 무엇인가요?
웹 작성자는 ARIA를 통해 스크린 리더로만 볼 수 있는 대체 현실을 만들 수 있습니다 🤥
때로는 진실을 넓히거나 스크린 리더에게 웹 콘텐츠에서 일어나는 일에 관해 완전히 '거짓말'해야 할 때도 있습니다. 예를 들어 '포커스가 정말 여기 있습니다!' 또는 '이것이 정말 슬라이더입니다!' 워크벤치의 도구와 위젯 위에 마법의 스티커 메모를 붙이는 것과 같습니다. 이 마법의 스티커 메모는 모든 사람이 자신의 글에 적힌 내용을 믿게 만듭니다.
마법의 스티커 메모는 각 도구가 무엇인지 또는 도구에 관한 Google의 믿음에 우선합니다. 예: '여기 있는 이 물건은 풀건입니다!' 실제로는 워크벤치에 있는 빈 파란색 상자지만 마법의 스티커 메모로 보면 글루건임을 알 수 있습니다. '30% 찼습니다'라고 추가할 수도 있습니다. 이제 스크린 리더가 여기에 30% 의 완전한 글루건이 있다고 보고합니다.
이와 동등한 웹은 내부에 이미지가 있는 일반 상자 요소 (div)를 취하고 ARIA를 사용하여 100점 만점에 30점의 슬라이더라고 하는 것입니다.
ARIA가 아닌 앱
ARIA는 웹페이지의 모양이나 마우스 또는 키보드 사용자의 동작에 영향을 미치지 않습니다. 보조 기술 사용자만 ARIA와 차이를 느끼게 됩니다. 웹 개발자는 보조 기술을 실행하지 않는 사용자에게 영향을 주지 않고 임의의 ARIA를 추가할 수 있습니다.
제대로 읽으셨네요. ARIA는 실제로 키보드 포커스나 탭 순서에 어떤 작업도 하지 않습니다. 이 작업은 HTML에서 할 수 있으며 자바스크립트를 약간 조정하여 수정하기도 합니다.
ARIA는 어떻게 작동하나요?
스크린 리더 또는 기타 보조 기술이 브라우저에 각 요소에 관한 정보를 요청합니다. 요소에 ARIA가 있는 경우 브라우저는 정보를 가져와 스크린 리더에 해당 요소에 관해 알리는 내용을 변경합니다.
ARIA를 사용해야 하는 이유
왜 사용자에게 거짓말을 하고 싶은 걸까요?
지역 웹 스토어에서 필요한 위젯을 모두 판매하지 않는다고 가정해 보겠습니다. 하지만 우린 MacGyver예요. 다른 위젯에서 나만의 위젯을 만들 수 있습니다. 맥가이버가 가장 많이 사용하는 물건은 스위스 아미 칼, 껌, 신발끈, 성냥, 클립, 생일 초, 덕트 테이프입니다. 그냥 누워 있는 것이 아닌 폭탄과 다른 물건을 만드는 데 그것을 사용합니다. 이는 메뉴바를 만들어야 하는 웹 작성자와 매우 비슷합니다. 메뉴바는 매우 유용하여 HTML의 일부일 것이라고 생각하지만 실제로는 그렇지 않습니다. 참 잘했어요! 링크와 버튼이 작성자들에게 만족할 것이라고 생각하지 않으셨나요? 따라서 저자는 div, 이미지, 스타일, 클릭 핸들러, 키 누름 핸들러, spit, ARIA와 같은 즐겨 사용하는 도구를 사용하여 하나의 코드를 만들 것입니다.
때로는 ARIA를 최대까지 사용하는 대신 그냥 향상 기능으로 사용하기도 합니다. 이미 기본적으로 작동하는 일부 HTML에 ARIA를 뿌리는 것이 유용할 수 있습니다. 예를 들어 양식 컨트롤이 잘못된 입력과 관련된 오류 메시지 알림을 가리키도록 할 수 있습니다. 또는 텍스트 상자가 검색용임을 나타낼 수도 있습니다. 조금만 수정하면 스크린 리더로 일반 웹사이트를 더 유용하게 사용할 수 있습니다.
메뉴 바 예
마우스 클리커 사용자 지원
함께 메뉴 바를 만들어 봅시다. div라는 일반 상자 요소에 여러 항목이 표시되어 있습니다. 사용자가 div를 클릭할 때마다 상응하는 명령어가 실행됩니다. 마우스 클리커를 사용하는 사람들에게도 정말 멋집니다!
다음으로, 사진을 예쁘게 만듭니다. CSS(스타일)를 사용하여 멋지게 정렬하고 눈에 띄는 윤곽선을 표시합니다. 다른 메뉴 바처럼 보이도록 만들어 사용자가 직관적으로 메뉴 바라는 것을 인지하고 사용 방법을 알 수 있도록 합니다. 메뉴 바는 마우스 위에 있는 모든 항목에 다른 배경 색상을 사용하여 사용자에게 유용한 시각적 피드백을 제공합니다.
일부 메뉴 항목은 상위 메뉴입니다. 하위 하위 메뉴가 생성됩니다. 사용자가 이들 중 하나에 마우스를 가져가면 하위 하위 메뉴를 슬라이드아웃하는 애니메이션이 시작됩니다.
물론 이 방법은 웹 작성자에게 필요한 모든 것을 추가하지 못했기 때문에 웹에서 많은 작업을 할 때 일반적으로 그러하듯 액세스가 상당히 불가능합니다. 그리고 그렇게 하더라도 웹 작성자는 항상 자신만의 특별한 버전을 발명하고 싶어할 것입니다.
접근성 메뉴 바 만들기
접근성을 위한 첫 번째 단계로 키보드 접근성을 추가해 보겠습니다. 이 부분은 HTML만 사용하고 ARIA는 사용하지 않습니다. ARIA는 보조 기술이 없는 사용자를 위한 디자인, 마우스, 키보드 등의 핵심 기능에 영향을 미치지 않습니다.
웹페이지가 마우스에 반응할 수 있는 것처럼 키보드에도 응답할 수 있습니다. JavaScript는 발생하는 모든 키 입력을 수신 대기하고 키 누름이 유용한지 판단합니다. 그렇지 않으면 먹을 수 없을 정도로 작은 물고기처럼 페이지로 다시 돌아갑니다. Google의 규칙은 다음과 같습니다.
- 사용자가 화살표 키를 누르면 자체 내부 메뉴 바 청사진을 살펴보고 새 활성 메뉴 항목을 결정해 보겠습니다. 일반 사용자가 어디에 있는지 시각적으로 알 수 있도록 현재 강조표시를 지우고 새 메뉴 항목을 강조표시합니다. 그러면 웹페이지에서
event.preventDefault()를 호출하여 브라우저가 일반적인 작업 (이 경우 페이지 스크롤)을 실행하지 못하도록 해야 합니다. - 사용자가 Enter 키를 누르면 클릭처럼 처리하고 적절한 작업을 실행하거나 다른 메뉴를 열 수도 있습니다.
- 사용자가 다른 작업을 실행해야 하는 키를 누르는 경우 먹지 마세요. 원래 의도대로 페이지에 다시 배치합니다. 예를 들어 메뉴 바에는 Tab 키가 필요하지 않으므로 다시 던지세요. 이것은 올바르게 이해하기가 어려우며, 저자들은 종종 실수합니다. 예를 들어 메뉴 바에는 화살표 키가 필요하지만 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"를 추가하여 1) 펼칠 수 있는 항목이 있고 2) 현재 펼쳐지지 않았음을 나타낼 수 있습니다. 추가 터치로 작성자는 img 삼각형에 role="none"를 배치하여 장식용임을 나타내야 합니다. 이렇게 하면 기껏해야 중복되거나 성가시게 할 수 있는 이미지에 관해 스크린 리더가 말하는 것을 방지할 수 있습니다.
버그 처리
키보드 버그 (HTML!)
키보드 액세스는 핵심 HTML의 일부이지만, 작성자는 키보드 탐색을 그다지 많이 사용하지 않거나 제대로 사용해야 할 미묘한 차이가 있기 때문에 항상 혼란을 야기합니다.
버그의 예:
- 체크박스에서 스페이스바를 사용하여 전환하지만 작성자가
preventDefault()을 호출하지 않았습니다. 이제 스페이스바를 사용하면 체크박스와 페이지 아래로 모두 전환됩니다. 이는 스페이스바의 기본 브라우저 동작입니다. - ARIA 모달 대화상자가 내부에 탭 탐색을 트랩하려고 하지만 작성자가 특별히 Control+Tab을 눌러 브라우저로 이동하도록 허용하지 않은 경우 이제 Control+Tab은 대화상자 내에서만 탐색하며 브라우저에서 탭을 제대로 전환하지 않습니다. 이런.
- 작성자가 선택 목록을 만들고 위/아래를 구현하지만 home/end/pageup/pagedown 또는 첫 글자 탐색을 구현하지는 않습니다.
작성자는 알려진 패턴을 따라야 합니다. 자세한 내용은 리소스 섹션을 참고하세요.
순수한 키보드 액세스 문제의 경우 스크린 리더를 사용하지 않거나 가상 브라우저 모드를 끈 상태에서 시도해 보는 것이 좋습니다. 스크린 리더는 일반적으로 키보드 버그를 발견하는 데 필요하지 않으며 키보드 액세스는 실제로 ARIA가 아닌 HTML로 구현됩니다. ARIA는 키보드나 마우스 동작과 같은 기본적인 기능에는 영향을 미치지 않으며, 웹페이지에 있는 내용, 현재 포커스가 맞춰진 항목에 관한 스크린 리더에만 영향을 미칩니다.
키보드 버그는 거의 항상 웹 콘텐츠, 특히 ARIA가 아닌 HTML 및 자바스크립트의 버그입니다.
ARIA 버그: 왜 그렇게 많은가요?
작성자가 ARIA를 잘못 이해할 수 있는 곳은 매우 많으며, 각 오류는 완전한 손상 또는 미묘한 차이로 이어집니다. 아마도 미묘한 부분은 저자가 게시하기 전에 대부분의 것을 잡아내지 못하기 때문에 더 안 좋을 것입니다.
작성자가 숙련된 스크린 리더 사용자가 아니라면 ARIA에 문제가 발생할 수 있기 때문입니다. 메뉴 바 예에서 작성자는 'menuitem'이 올바르면 'option' 역할이 사용된다고 생각할 수 있습니다. aria-expanded를 사용하지 않았거나, 적절한 시점에 aria-activedescendant를 설정 및 삭제하지 않았거나, 다른 메뉴가 포함된 메뉴 바가 있는 것을 잊어버릴 수 있습니다.
메뉴 항목 개수는 어떨까요? 일반적으로 메뉴 항목은 사용자가 어디에 있는지 알 수 있도록 스크린 리더에서 '항목 3/5'과 함께 표시됩니다. 이는 일반적으로 브라우저에서 자동으로 계산되지만 경우에 따라 일부 브라우저(스크린 리더 조합)의 경우 잘못된 숫자가 계산될 수 있으며 작성자는 이러한 숫자를 aria-posinset 및 aria-setsize로 재정의해야 합니다.
이것은 단지 메뉴 바에 불과합니다. 얼마나 많은 종류의 위젯이 있는지 생각해 보세요. 원하는 경우 ARIA 사양이나 작성 방법을 한눈에 볼 수 있습니다. 각 패턴에는 ARIA가 오용될 수 있는 12가지 방법이 있습니다. ARIA는 작성자가 무엇을 하고 있는지 알 수 있어야 합니다. 대부분의 작성자가 스크린 리더 사용자가 아니라고 한다면 어떤 문제가 발생할 수 있을까요?
즉, 실제 스크린 리더 사용자는 배송 가능한 것으로 간주되기 전에 ARIA 위젯을 사용해 볼 필요가 100%입니다. 미묘한 차이가 너무 많습니다. 여러 가지 브라우저-스크린 리더 조합으로 모든 것을 시도하는 것이 이상적입니다. 몇 가지 불완전한 구현에 더해 구현상의 특이한 사항이 있기 때문입니다.
요약
요약하자면, ARIA 매직은 HTML이 지시하는 모든 것을 재정의하거나 추가하는 데 사용할 수 있습니다. 접근성 표현을 미세하게 변경하거나 전체 환경을 만드는 데 사용할 수 있습니다. 이것이 ARIA가 놀라울 정도로 강력하면서도 일반적으로 스크린 리더를 사용하지 않는 친절한 현지 웹 작성자에게는 위험한 이유입니다.
ARIA는 간단한 TTP 마크업 레이어입니다. ARIA가 있는 경우 스크린 리더가 무슨 일이 일어나고 있는지 물으면 실제 근본적인 진실 대신 ARIA 버전의 진실을 받게 됩니다.
부록 1: 추가 리소스
키보드 정보와 코드 예시가 포함된 하이브리드 참조
- W3C의 ARIA 작성 방식: 각 예의 중요한 키보드 탐색 특성을 문서화하고 작동하는 JS/CSS/ARIA 코드를 제공합니다. 이 예제는 현재 효과가 있는 것에 중점을 두고 있으며 모바일은 다루지 않습니다.
부록 2: ARIA가 가장 많이 사용되는 용도
ARIA는 작거나 큰 사실을 대체하거나 보완할 수 있기 때문에 일반적으로 스크린 리더가 중요하게 여기는 내용을 말할 때 유용합니다.
다음은 ARIA의 일반적인 용도입니다.
- 메뉴 바, 자동 완성, 트리 또는 스프레드시트와 같이 HTML에 없는 특수 위젯
- HTML에 있는 위젯이지만 작성자가 직접 만든 위젯입니다. 일반 위젯의 동작이나 모양을 조정해야 했기 때문일 수 있습니다. 예를 들어 HTML
<input type="range">요소는 기본적으로 슬라이더이지만 작성자는 다르게 보이게 하려고 합니다. 대부분의 경우 CSS를 사용할 수 있지만input type="range"의 경우 CSS가 어색합니다. 작성자는 자체 슬라이더를 만들고aria-valuenow와 함께role="slider"를 사용하여 현재 값을 말할 수 있습니다. - 라이브 영역은 스크린 리더에 '페이지의 이 영역에서 사용자에게 알릴 가치가 있는 변경사항'이라고 알립니다.
- 랜드마크 (현재 HTML에 동등한 항목이 있음) 제목과 마찬가지로 스크린 리더 사용자가 원하는 것을 더 빠르게 찾을 수 있습니다. 그러나 전체 관련 영역을 포함한다는 점에서 다릅니다. 예: '이 컨테이너는 페이지의 기본 영역입니다', '여기 위에 있는 이 컨테이너는 탐색 패널입니다'.
부록 3: Accessibility API란 무엇인가요?
접근성 API는 스크린 리더 또는 기타 AT가 페이지의 내용과 현재 상황을 파악하는 방법입니다. MSAA, IA2, UIA를 예로 들 수 있습니다. 이것이 바로 Windows입니다. 접근성 API는 두 부분으로 구성됩니다.
- 컨테이너 계층 구조를 나타내는 객체의 '트리'입니다. 이들은 러시아 중첩 인형과 같지만, 각 인형에는 여러 개의 다른 인형이 들어 있을 수 있습니다. 예를 들어 하나의 문서는 여러 단락을 포함할 수 있고 단락에는 텍스트, 이미지, 링크, 굵은 글꼴 등을 포함할 수 있습니다. 객체 트리의 각 항목에는 역할 (나란 무엇인가요?), 이름/라벨, 사용자가 입력한 값, 설명뿐만 아니라 포커스 가능, 포커스, 필수, 확인됨과 같은 불리언 상태와 같은 속성이 있을 수 있습니다. ARIA는 이러한 모든 속성을 재정의할 수 있습니다. 스크린 리더는 사용자가 '다음 제목으로 이동'과 같이 가상 버퍼 모드로 탐색할 수 있도록 트리를 사용합니다.
- 트리의 변경사항을 설명하는 일련의 이벤트(예: '포커스가 이제 여기에 있습니다!') 스크린 리더는 이벤트를 사용하여 사용자에게 방금 발생한 상황을 알려줍니다. 중요한 HTML 또는 ARIA 마크업이 변경되면 스크린 리더에 변경사항이 있음을 알리는 이벤트가 실행됩니다.
일반적으로 작성자는 이러한 접근성 API에 잘 매핑되는 HTML만 사용합니다. HTML이 충분하지 않으면 ARIA가 사용되고 브라우저가 객체 트리 또는 이벤트를 스크린 리더로 전송하기 전에 HTML 의미 체계를 재정의합니다.