1. 항상 aria-label에 의존하기 😳
만약 이 실수를 저질렀다면, 제가 비난하지는 않을 거예요. 제 자신도 같은 함정에 걸렸었거든요. 사람들은 추가적인 컨텍스트를 제공하려고 할 때 언제든지 aria-label을 쉽게 사용하지만, 그것에 대해 얼마나 주의 깊게 살펴봐야 하는지를 과소평가하곤 해요.
우선, 당신이 실제로 그것이 필요한지도 모를 수 있어요. 이것을 고려해보세요:
<section aria-label="퀴즈 정답">
<h2>퀴즈 정답</h2>
이 예는 꽤 간단하지만, HTML 구조만으로도 스크린 리더(SR) 사용자에게 필요한 컨텍스트를 제공하는 것을 알려줍니다. MDN과 HTML 표준은 우리에게 말하는 대로, section은 보통 제목과 함께 있으며 SR은 그것에 의존합니다. 실제로, SR 사용자가 제목 대신 영역(영역은 nav, main, section 등과 같이 페이지의 특정 영역을 말합니다)으로 웹페이지를 탐색할 때에도, aria-label이 없어도 SR은 section과 h2를 함께 읽습니다.
하지만 필요 없이 모든 곳에 쓸데없는 aria-label을 붙이는 것보다 훨씬 더 악질적인 면이 있습니다! 😕 이것을 확인해보세요:
<ul>
<li aria-label="옵션 1은 정답이며, 당신은 그것을 선택하지 않았습니다">
<span aria-hidden>옵션 1</span>
</li>
이것은 완전히 유효해 보이지 않나요? aria-label에서 추가적인 컨텍스트를 제공하고 span을 숨김 처리하였으므로 옵션 1이 두 번 읽히지 않도록 하려는 것입니다. 하지만, 여기서 뭔가 문제가 있습니다. NVDA와 JAWS 스크린 리더에서 이 데이터가 완전히 무시됩니다! 왜 그럴까요? 🤔
문제는 다음과 같이 2가지 부분으로 나뉩니다:
aria-hidden덕분에 목록 항목에는 SR-visible 콘텐츠가 없습니다. 예상했던 것이지만...- 숨겨진 내용을 우회하기 위해 사용되었던
aria-label이 사실상li에서는 잘못된 것이었습니다!
aria-label은 목록 항목 요소와 호환되지 않을 뿐만 아니라, 보통 div나 span과 같이 널리 사용되는 요소에도 사용할 수 없다는 겁니다! 이것에 대해 예상치 못했겠지만, 제가 과거에는 전혀 알지 못했기에요.
그럼 언제 사용할 수 있을까요? MDN에서 명확히 설명하고 있습니다(강조는 제겁니다):
div에 role="button" 속성이 있다면 aria-label이 작동하지만, 일반적인 div라면 aria-label이 무시됩니다. 그리고 제 예시에서 보여준 것처럼, 이는 SR이 추가적인 컨텍스트를 제공하지 않아도 되는 경우를 넘어서 실제로 특정 조건이 충족되면 SR 사용자에게 전체 콘텐츠 섹션이 숨겨지는 결과로 이어질 수 있습니다.
2. 폼 요소 비활성화
이 주제에 대해 많은 글이 쓰여져 있고, 요약은 Adrian Roselli의 기사를 추천합니다. 나는 폼 요소를 비활성화하는 데 관련된 IMHO로 중요한 2가지 문제를 가지고 있는데, 이는 SR 및 비-SR 사용자 모두에게 관련이 있다고 생각합니다.
그들을 찾기 어려워요 🙈
특정 이유로 웹 콘텐츠 접근성 지침(WCAG)은 비활성 요소에 대해 페이지의 나머지 부분과 동일한 색 대비 표준을 요구하지 않습니다. 따라서 이러한 디자인이 가능해집니다:
시력이 20/20인 경우 이 버튼을 읽는 데 문제가 없겠지만, 다른 많은 사람들은 흰 배경과의 낮은 대비로 인해 텍스트를 보거나 버튼 자체를 보지 못할 수도 있습니다.
설명이 제공되지 않습니다
자신에게 솔직한 질문을 해 보세요: 양식 요소나 다른 컨트롤을 비활성화할 때 그 이유에 대한 설명을 제공하는 경우가 얼마나 자주 있나요? 정확히요.
그것은 왜 그 요소가 비활성화되었는지 모르는 것은 정말 짜증나고 혼란스럽다는 말입니다. 이는 보조 기술 사용자에게 가장 큰 영향을 미치지만 모두에게 중요합니다. 예를 들어, 제출 버튼이 모든 양식 필드가 유효해질 때까지 비활성화되어야 한다는 것이 우리, 프로그래머들에게 논리적이고 완전히 이해하기 쉬울지도 모르지만, 이는 사용자들에게는 그렇게 단순하지 않을 수 있습니다.
3. SR(Speech Recognition) 차이를 과소평가하다
SR에는 여러 수준에서 큰 차이가 있습니다. 가장 눈에 띄는 차이는 SR이 웹페이지를 읽는 방식입니다. #1에서 언급된 aria-label의 함정을 기억하시나요? 맥의 VoiceOver에서는 실제로 작동했지만 Windows SR인 NVDA와 JAWS에서 완전히 고장 났습니다. 때로는 매우 상호작용적인 기능의 첫 번째 버전을 코딩하고 NVDA를 주로 사용하여 개발했을 때 잘 작동했지만, VoiceOver에서는 전혀 작동하지 않았습니다.
개발 측면에서는 WAI-ARIA 표준을 따라 저작 안내서를 사용하는 것이 가장 좋습니다. 대부분의 경우에서 문제가 해결될 것입니다.
하지만, 이것은 테스트를 건너뛸 수 없다는 뜻은 아니에요. 여러 플랫폼과 스크린 리더상에서 꼭 테스트해야 해요:
- 대다수 시장 점유율을 차지한 NVDA와 JAWS의 Windows 사용자를 대상으로 (WebAIM 2024 조사 기준)
- VoiceOver가 있는 Mac
- VoiceOver가 포함된 iOS
- Talkback 같은 Android
저는 이것이 최소한의 테스트 스위트라고 할 수 있지만, 매일 이 모든 것을 처리하기에는 개발자에게는 부담일 수 있습니다. 시간이 흐를수록 어떤 부분이 전체 (재)테스트가 필요한지를 배울 수 있고, 또한 회사의 접근성 테스팅/감사 프로세스가 지원되므로 안심하세요. 그러나 그것은 여기서 자세히 다루지 않을 주제이기 때문에 넘어가죠.
4. 화면 낭독기 사용자가 어떻게 이용하는지 모르는 경우 🤔
화면 낭독기를 시작하는 사람들, 즉 개발자나 디자이너들이 탭 키를 누르는 것 이상으로 표시된 콘텐츠를 어떻게 탐색하는지에 대한 매우 모호한 개념을 갖는 경우가 많이 있습니다. 이는 당연히 제대로 된 구현을 하지 못하게 만들며, 제품을 만들 때 대상 고객을 이해하지 못하는 것과 같은 문제로 이어질 수 있습니다.
화면 낭독기로 웹페이지나 다른 콘텐츠를 탐색하는 방법은 여러 가지가 있습니다. 대부분의 사람들은 콘텐츠를 이해하기 위해 제목을 사용합니다. 특정 영역으로 이동하거나 링크, 양식 또는 찾기 기능을 통해 탐색하는 것은 화면 낭독기 사용자에게 중요한 도구입니다.
하지만 "앵커"로 사용할 수 있는 어떤 콘텐츠인지에 대해 중요한 것은 아닙니다. 화면 낭독기의 차이점으로 돌아가서, 우리는 탐색하는 매우 다른 기술들을 발견할 수 있습니다. VoiceOver 사용자는 다른 종류의 "앵커"(영역, 링크, 제목 등) 사이를 전환하기 위해 회전 또는 검색을 사용하여 원하는 대상에 도달할 수 있습니다. 반면 NVDA는 VO와 매우 다르게 작동하기 때문에 모든겹치는 모드에서 작동하는 것이 아니라 여러 모드로 작동하며, 사용자가 양식을 작동하려고 할 때는 탐색에서 대화식으로 전환해야 합니다.
모바일에서의 스크린 리더는 데스크톱과 매우 다르게 사용자들이 조작하기 때문에 별도의 챕터로 취급됩니다. 자세한 내용은 생략하겠지만, 이들은 사물을 다른 시각에서 볼 수 있도록 도와줍니다 (#5에서 자세히 다룰 예정).
모든 내용을 이해하는 것은 접근성 있는 앱을 구현하는 데 핵심적이며, 접근성 문제를 다룰 때 무엇을, 그리고 왜 하는지 이해하는 데 도움이 됩니다. 다행히도, 이러한 이해를 얻을 수 있는 훌륭한 자료들이 있습니다:
- 웹AIM의 2024년 스크린 리더 설문조사: 사람들이 어떤 스크린 리더를 사용하고 어떻게 사용하는지 상세히 설명
- 보조 기술 사용자들의 이야기
- 시감자 점자출판의 Blind Life과 같은 채널: 장애를 가진 사용자들이 어떻게 기술을 실제로 사용하는지 자세히 설명하는 채널
5. 탭 키의 목적을 오해하기
이 것은 제가 자주 보는 즐겨찾는 영역이어서 좋아해요. 여러분이 이해하면 우리 모두의 삶이 훨씬 쉬워질 것 같아요. 그러니 함께 손을 맞잡고 이렇게 말해봐요: Tab 키는 모든 상호작용 요소를 탐색하기 위한 것이 아니에요! 🤯
이제 재미있게 느껴지나요? 혼란이 가라앉으면 아마 "내가 방금 뭘 말했지?"라고 생각할 거에요. 이해하지 못할 수도 있어요. 하지만 사실 많은 의미를 가지고 있어요. 아래 예제를 고려해보세요. Codepen으로 들어가서(저는 MDN에서 가져왔어요) Tab을 이용해 현재 탭 패널(현재 탭의 콘텐츠)까지 이동해보세요.
Tab을 많이 눌러야 했죠? 모든 탭이 상호작용 가능하고 초점을 줄 수 있어야 하지만 이렇게 모든 탭을 지나가야 했나요? 그리고 이제 5개가 아니라 10개의 탭이 있다고 상상해보세요. 혹은 더 좋게, 1000개의 이모티콘 목록을 넘어서 아래 콘텐츠에 도달하려고 노력 중이라고 상상해봐요. 그리고 그걸 모바일에서 실행할 때, Tab이 좌우로 스와이핑하여 이루어진다고 상상해봐요! 🤯 그것은 정말로 살짝 지루할 것 같은데요, 그렇죠?
이 예제는 실제로 Tab 키의 목적이 페이지의 모든 상호작용 요소를 지나가는 것이 아니라 페이지의 콘텐츠를 빠르게 탐색하는 것이라는 것을 보여줍니다. 사용자가 위의 탭 목록과 같은 콘텐츠와 상호작용하고자 한다면 화살표 키로 그렇게 할 수 있어요.
거리를 걸으며 옆집 문을 노크하고 그 즉시 들어갈지 다음 집으로 갈지 결정하는 것과 비슷합니다. 집에서 집으로 이동하는 것은 탭 키를 누르는 것이고, 집에 들어가는 것은 화살표 키입니다 (무단 침입으로 사건을 일으키면 제게 책임을 묻지 마세요).
실제로 이것이 어떻게 동작하는지 살펴봅시다. 첫 번째 탭 키를 누르면 현재 활성 탭으로 초점이 이동하고, 두 번째 탭을 누르면 탭 패널 (탭 콘텐츠)로 이동합니다. 멋지죠!
다시 한 번, 이러한 상호 작용을 얻는 방법에 대한 훌륭한 자료는 W3C의 저작 가이드라인이며, 강력히 추천하고 싶습니다.
여기까지입니다!
알았어요! 가장 짜증나는 접근성 위반은 무엇인지 알려주세요. 그리고 당신이 만들고 싶은 상위 5 목록에 담을 것은 무엇인가요?