전 세계에는 약 3,600만 명의 시각장애인이 있는 것으로 추정되지만, 여전히 96%가 넘는 웹사이트에서 감지 가능한 접근성 오류가 발견됩니다. 이 가이드는 스크린 리더가 정확히 어떻게 작동하는지, 시각장애 사용자가 웹을 어떻게 탐색하는지, 그리고 개발자와 웹사이트 소유자가 진정으로 포용적인 디지털 경험을 구축하기 위해 무엇을 해야 하는지를 설명합니다.

전 세계에는 약 3,600만 명의 시각장애인이 있으며, 추가로 약 2억 1,700만 명이 중등도에서 중증의 시각 손상을 안고 살아가고 있습니다. 그럼에도 2025년 현재 웹사이트의 96% 이상이 여전히 하나 이상의 감지 가능한 접근성 오류를 가지고 있습니다. 스크린 리더에 의존하는 시각장애 사용자에게는, 라벨 하나가 빠졌거나, 제목(heading) 계층이 깨졌거나, 접근할 수 없는 CAPTCHA 하나가 독립적으로 작업을 완료하는 것과 아예 사이트를 포기하는 것의 차이를 만듭니다. 스크린 리더가 실제로 어떻게 작동하는지 — 이론이 아니라 실무 관점에서 — 이해하는 것은 접근 가능한 웹을 구축하는 토대입니다.

스크린 리더란 무엇이며 누가 사용하는가?

스크린 리더는 화면의 콘텐츠를 합성 음성이나 점자 디스플레이 출력으로 변환하는 보조 기술 소프트웨어입니다. 단순히 텍스트를 읽어 주는 것이 아니라, 스크린 리더는 인터페이스 요소의 구조, 역할, 상태, 관계를 해석하여, 시각적 표현에 의존하지 않고도 사용자가 웹 페이지를 포괄적으로 이해할 수 있도록 합니다. 이를 단순한 낭독자가 아니라, 전체 시각 인터페이스를 오디오 또는 촉각 정보 스트림으로 번역해 주는 지능형 통역사에 가깝다고 생각하면 됩니다.

스크린 리더는 주로 시각장애인이나 저시력 사용자가 사용하지만, 특정 인지 또는 읽기 장애가 있는 사용자도 지원합니다. WebAIM이 2023년 말에 실시하고 2024년 2월에 발표한 제10차 스크린 리더 사용자 설문조사에 따르면, 스크린 리더 사용자의 거의 77%는 시각장애인이며, 이어서 저시력 또는 기타 시각 손상이 있는 사람이 거의 20%를 차지합니다. 난청, 인지 장애, 운동 장애가 나머지를 구성합니다. 이는 틈새 이용자가 아닙니다. 미국 성인의 4.9%가 실명 또는 심각한 시력 저하를 포함한 시각 장애를 가지고 있으며, 전 세계적으로 시각 손상 사용자는 수억 명에 달합니다.

또한 스크린 리더 사용자가 결코 단일한 집단이 아니라는 점도 중요합니다. 연구는 기술 수준, 선호도, 탐색 전략, 문제 해결 방식에서 매우 큰 다양성이 있음을 일관되게 보여 줍니다. 태어날 때부터 시각장애가 있었고 20년 동안 JAWS를 사용해 온 사용자는, 최근에 시력을 잃고 아직 보조 기술을 배우는 중인 사람과는 전혀 다른 방식으로 탐색합니다. 기술적으로는 접근 가능한 웹사이트조차, 요구되는 정신적 모델이 사용자의 기대와 맞지 않으면 상당한 어려움을 줄 수 있습니다. 디자이너와 개발자는 하나의 전형적인 스크린 리더 사용자만을 상상하려는 유혹을 경계해야 합니다.

스크린 리더의 실제 작동 방식: 접근성 트리

스크린 리더를 진정으로 이해하려면, 그들이 무엇을 읽는지 이해해야 합니다 — 그것은 시각적 레이아웃이 아닙니다. 스크린 리더는 브라우저가 HTML DOM으로부터 구축한 페이지의 구조화된 표현인 접근성 트리에 접근함으로써 작동합니다. 브라우저는 이 트리를 플랫폼별 접근성 API를 통해 노출합니다. Windows에서는 UI Automation, macOS에서는 NSAccessibility, Android에서는 AccessibilityService입니다. 스크린 리더는 이 API를 질의하여 각 요소에 대한 의미 정보를 받고, 이를 음성 또는 점자 출력으로 변환합니다.

이는 매우 중요한 함의를 가집니다. 화면에 보이는 것과 스크린 리더가 인식하는 것은 완전히 다를 수 있습니다. 시각적 디자인에서 <div>를 버튼처럼 보이도록 스타일링했다면, 접근성 트리에 버튼 역할이 없기 때문에 스크린 리더는 이를 버튼으로 알려 주지 않습니다. 스크린 리더는 픽셀이 보여 주는 것이 아니라 코드가 말하는 것을 알립니다. <button>, <nav>, <h1>, <form>과 같은 시맨틱 HTML 요소는 접근성 트리에 자동으로 노출되는 내장 역할을 가지고 있습니다. 개발자가 이를 우회하고 ARIA 역할을 덧붙인 일반 요소를 선호하면, 불필요한 복잡성을 만들고 자주 새로운 오류를 도입하게 됩니다.

스크린 리더는 화면에 보이지 않는 맥락도 제공합니다. 사용자가 목록을 만나면, 스크린 리더는 항목이 몇 개 있는지 알려 줍니다. 표에 도달하면, 행과 열의 개수를 알립니다. 포커스가 폼 필드로 이동하면, 필드의 라벨, 유형, 현재 상태를 읽어 줍니다. 이러한 맥락 메타데이터는 잘 구조화된 시맨틱 HTML에 전적으로 의존합니다. 이를 제거하면 사용자가 무엇을 다루고 있는지 이해할 수 있는 능력도 함께 제거됩니다.

주요 스크린 리더: JAWS, NVDA, VoiceOver, TalkBack

스크린 리더 시장은 각기 다른 특성을 가진 소수의 도구가 지배하고 있습니다. 사용자가 어떤 도구에 의존하는지 이해하는 것은 사이트를 어떻게 테스트해야 하는지에 직접적인 영향을 줍니다.

JAWS (Job Access With Speech)는 Freedom Scientific이 개발하여 1995년에 처음 출시한 제품으로, 특히 엔터프라이즈 환경에서 오랫동안 업계 표준으로 여겨져 왔습니다. WebAIM 2024 설문조사에서 JAWS는 응답자의 약 41%가 주 사용 스크린 리더로 꼽았습니다. 이는 연간 90달러에서 1,400달러 이상까지 라이선스 비용이 드는 상용 제품입니다. JAWS는 광범위한 사용자 정의, Microsoft Office 및 전문 애플리케이션의 복잡한 워크플로와의 강력한 호환성, 그리고 페이지를 탐색 가능한 선형 환경으로 변환하여 사용자가 직관적인 키 조작으로 제목, 랜드마크, 폼 필드 간을 이동할 수 있게 해 주는 "Browse Mode"를 제공합니다.

NVDA (NonVisual Desktop Access)는 NV Access가 개발하여 2006년에 선보인 Windows용 무료 오픈 소스 스크린 리더입니다. 2024년 WebAIM 설문조사에서 NVDA는 응답자의 약 38%가 주 사용 스크린 리더로 꼽았으며 — JAWS와 거의 동일한 수준입니다. NVDA는 무료 모델, 잦은 업데이트, 견고한 성능 덕분에 큰 인기를 얻었습니다. 2025년 NVDA는 단일 페이지 애플리케이션에서 포커스 관리 처리 방식을 개선하여, 사용자가 콘텐츠가 언제 변경되었고 포커스가 어디로 이동했는지 더 잘 이해할 수 있도록 했습니다. 권장 브라우저 조합은 Firefox이며, Chrome 지원도 강력합니다.

VoiceOver는 Apple의 내장 스크린 리더로, macOS, iOS, iPadOS에서 별도 설치 없이 사용할 수 있습니다. 데스크톱에서는 VO 수정키(Control + Option)를 사용하는 키보드 단축키를, iOS에서는 스와이프, 두 번 탭, 로터와 같은 터치 제스처를 사용합니다. 모바일 기기에서 VoiceOver는 가장 널리 사용되는 스크린 리더로, 모바일 스크린 리더 사용자의 70.6%가 이에 의존합니다. VoiceOver는 macOS/iOS 접근성 API를 완전히 노출하는 유일한 브라우저인 Safari와 함께 사용할 때 가장 잘 작동합니다.

TalkBack은 Android의 내장 스크린 리더로, 음성 피드백과 진동을 제공하여 사용자가 기기를 탐색할 수 있도록 돕습니다. Android 모바일 테스트의 표준 도구이며 Chrome과 함께 사용할 때 가장 좋습니다. Windows에는 Narrator도 기본 제공되며, 꾸준히 개선되고 있지만 여전히 JAWS와 NVDA의 일부 기능은 부족합니다. 이러한 도구는 각각 다소 다르게 동작합니다 — NVDA에서 올바르게 작동하는 패턴이 JAWS에서는 실패할 수 있습니다 — 그렇기 때문에 진지한 접근성 프로그램이라면 여러 스크린 리더에 걸친 테스트가 필수입니다.

시각장애 사용자의 실제 탐색 방식: 모든 것을 바꾸는 정신적 모델

개발자가 자신의 작업을 바라보는 방식을 근본적으로 바꾸게 하는 통찰은 다음과 같습니다. 스크린 리더 사용자는 페이지를 위에서 아래로 선형적으로 읽지 않습니다. 그들은 시력이 있는 사용자가 시각적으로 훑어보는 것과 마찬가지로, 콘텐츠를 효율적으로 스캔하고 건너뛰기 위해 정교한 탐색 전략을 사용합니다. 이러한 전략을 지원하지 못하면, 기술적으로는 접근 가능한 페이지조차 지치고 사용할 수 없는 경험이 됩니다.

가장 널리 사용되는 탐색 전략은 제목(heading) 탐색입니다. 정보를 찾기 위한 제목 사용은 시간이 지남에 따라 증가해 왔으며 여전히 지배적인 방법입니다 — 응답자의 88.8%가 제목 수준이 매우 유용하거나 다소 유용하다고 답했습니다. 고급 사용자는 초보자보다 제목을 통해 탐색할 가능성이 훨씬 높습니다. 실제로는 사용자가 JAWS나 NVDA에서 H 키를 눌러 페이지의 다음 제목으로 이동하며 구조를 빠르게 스캔합니다. 1에서 6까지의 키를 누르면 해당 수준의 제목으로 바로 이동합니다. 페이지에 제목이 없거나, 문서 구조가 아니라 시각적 크기를 기준으로 제목을 사용하면, 시각장애 사용자는 이동할 랜드마크가 없어 페이지 전체를 처음부터 끝까지 들어야만 합니다.

두 번째 주요 전략은 랜드마크 탐색입니다. HTML5 랜드마크 요소 — <main>, <nav>, <header>, <footer>, <aside>, 라벨이 있는 <section> — 는 스크린 리더 사용자가 로터나 랜드마크 단축키를 사용해 이동할 수 있는 이름 있는 영역을 만듭니다. 2025년에는 네이티브 <main> 요소의 사용 증가에 힘입어 ARIA 랜드마크 채택이 소폭 증가했으며, 이제 47%의 페이지에 <main>이 존재합니다. 응답자의 31.7%는 랜드마크가 있을 때 항상 또는 자주 사용한다고 답했지만, 랜드마크를 주 탐색 방법으로 사용하는 비율은 3.7%에 불과합니다 — 이는 랜드마크가 보조 도구이지만, 방향 감각을 잡는 데 중요한 역할을 한다는 것을 시사합니다.

사용자는 또한 단일 키 단축키를 사용해 링크, 폼 필드, 버튼으로 탐색하며, 페이지의 모든 제목, 모든 링크, 모든 폼 필드를 한 번에 보여 주는 요소 목록을 자주 띄워 필요한 곳으로 바로 이동합니다. 이러한 행동은 링크 텍스트에 엄청난 영향을 미칩니다. "Read more, Read more, Read more"라고만 나열된 링크 목록은 탐색 가치가 전혀 없습니다. 모든 링크와 버튼은 문맥 밖에서도 의미가 통하는, 설명적이고 고유한 접근 가능한 이름을 가져야 합니다.

모바일에서는 패러다임이 터치 제스처로 전환됩니다. VoiceOver와 TalkBack 사용자는 오른쪽으로 스와이프하여 다음 요소로 이동하고, 두 번 탭하여 활성화하며, 로터 제스처로 탐색 모드를 전환합니다. 모바일 앱 사용 선호도는 2021년 51.8%에서 2024년 58%로 증가했습니다. 이는 반응형 디자인과 모바일 접근성이 선택적 부가 기능이 아니라, 많은 스크린 리더 사용자에게 주요 사용 시나리오라는 뜻입니다.

오늘날 웹에서 가장 문제가 되는 장벽

WebAIM 설문조사는 응답자에게 가장 문제가 되는 항목을 식별해 달라고 요청했습니다. 결과는 10년이 넘는 기간 동안 놀라울 정도로 일관되며 — 귀하의 사이트가 반드시 제대로 구현해야 할 항목의 체크리스트이기도 합니다.

CAPTCHA는 상당한 차이로 최상위 불만 사항입니다. 스크린 리더 사용자는 14년 넘게 CAPTCHA가 가장 문제가 되는 항목이라고 일치된 의견을 보여 왔습니다. 전통적인 CAPTCHA 사용은, 스크린 리더가 이미지를 처리할 수 없어 폼에서 요구하는 정보를 얻지 못하게 만들기 때문에, 시각장애인에게 명백히 문제가 됩니다. 오디오 CAPTCHA조차 의도적인 왜곡 때문에 알아듣기 어려워 많은 사용자가 실패합니다. 실질적인 권장 사항: 가능한 경우 reCAPTCHA v3나 허니팟 기법과 같은 보이지 않는 행동 기반 검증을 사용하십시오.
예상치 못한 동작을 하는 인터랙티브 요소 — 확립된 키보드 상호작용 패턴을 따르지 않는 메뉴, 탭, 대화 상자, 커스텀 위젯 — 도 CAPTCHA 바로 뒤를 잇습니다. 이러한 요소는 종종 과도한 ARIA 속성으로 구축되며, 불규칙한 상호작용 동작과 브라우저 및 스크린 리더 간 호환성 문제를 가지고 있습니다.
모호한 링크와 버튼은 사용자를 끊임없이 좌절시킵니다. "click here", "learn more", "read more"와 같은 문구는 링크 목록에서 따로 들었을 때 목적지나 동작에 대한 단서를 전혀 제공하지 않습니다.
예상치 못한 화면 변경 — 예고 없이 발생하는 동적 콘텐츠 업데이트 — 는 시각적으로 무엇이 바뀌었는지 알 수 없는 시각장애 사용자를 혼란스럽게 합니다. 이는 특히 React, Vue, Angular로 구축된 단일 페이지 애플리케이션에서 두드러지는데, 페이지를 다시 로드하지 않고도 콘텐츠가 바뀔 수 있기 때문입니다.
깨진 제목(heading) 계층은 대부분의 고급 사용자가 사용하는 주요 탐색 전략을 약화시킵니다. 약 39%의 웹사이트가 깨진 제목 계층을 가지고 있어, 스크린 리더 사용자가 콘텐츠를 제대로 탐색하기 어렵게 만듭니다.
누락되었거나 부적절한 대체 텍스트(alt text)가 있는 이미지. 대체 텍스트가 없으면, 스크린 리더는 이미지의 존재만 알리고 내용을 설명하지 않거나, 더 나쁘게는 "IMG_4823.jpg"와 같은 의미 없는 파일 이름을 읽어 줄 수 있습니다.

대다수 — 67% — 의 스크린 리더 사용자는 장벽에 대해 웹사이트 소유자에게 거의 또는 전혀 연락하지 않습니다. 그들은 그냥 떠납니다. 불만을 받지 못할 것입니다. 단지 사용자를 잃을 뿐입니다.

스크린 리더가 실제로 해석할 수 있는 코드 작성하기

사용자 탐색 패턴을 이해하면 기술적 요구 사항이 훨씬 더 구체적으로 다가옵니다. 마크업과 JavaScript에서 내리는 모든 결정은 시각장애 사용자에게 직접적으로, 소리로 들리는 결과를 낳습니다. 다음은 가장 중요한 원칙들입니다.

시맨틱 HTML은 가장 첫 번째이자 가장 강력한 도구입니다. ARIA의 첫 번째 규칙은 다음과 같습니다. "필요한 의미와 동작이 이미 내장된 네이티브 HTML 요소나 속성을 사용할 수 있다면, 요소를 재목적화하고 ARIA 역할, 상태, 속성을 추가하여 접근 가능하게 만들기보다는 그렇게 하라." <button>, <nav>, <header>, <form>과 같은 요소는 접근성이 기본으로 탑재되어 있습니다. 네이티브 컨트롤을 사용하면 추가 코드 없이도 브라우저와 보조 기술과의 호환성을 보장할 수 있습니다.

ARIA는 대체물이 아니라 보완재입니다. ARIA(Accessible Rich Internet Applications)는 HTML만으로는 필요한 의미를 표현할 수 없는 경우 — 예를 들어, 커스텀 슬라이더를 접근 가능하게 만들거나, 동적 콘텐츠 변경을 알리거나, 접이식 메뉴가 현재 확장되어 있음을 표시하는 경우 — 접근성 격차를 메우기 위해 설계된 HTML 속성 집합입니다. 위험은 오용에 있습니다. ARIA가 사용된 홈 페이지는, ARIA가 없는 페이지보다 평균 두 배 이상의 접근성 오류를 가지고 있습니다. ARIA가 많다고 해서 더 접근 가능해지는 것이 아니라, 종종 오류가 더 많아진다는 뜻입니다. ARIA를 잘못 사용한 페이지는 그렇지 않은 페이지보다 감지 가능한 오류가 70% 더 많았습니다. 네이티브 요소로는 해결할 수 없는 곳에만, 외과 수술하듯 신중하게 사용하십시오.

다음 코드 예시는 접근할 수 없는 커스텀 버튼과 제대로 접근 가능한 버튼의 차이를 보여 줍니다.

<!-- Inaccessible: a div with click handler, no role, no keyboard support -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native button with built-in role, keyboard support, and focus -->
<button type='submit'>Submit</button>

<!-- If you must use a non-button element, add role, tabindex, and keyboard event -->
<div role='button' tabindex='0'
     aria-label='Submit the registration form'
     onkeydown='handleKey(event)'
     onclick='submitForm()'>
  Submit
</div>

ARIA 라이브 영역은 동적 콘텐츠 변경을 알리는 올바른 메커니즘입니다. 페이지가 전체 새로고침 없이 콘텐츠를 업데이트할 때 — 폼 검증 메시지, 장바구니 합계, 알림 등 — 이 변경은 라이브 영역을 사용하지 않는 한 스크린 리더 사용자에게는 조용히 지나갑니다. aria-live='polite' 속성은 스크린 리더에게 사용자의 현재 활동이 끝난 후 변경 사항을 알리도록 지시하고, aria-live='assertive'는 즉시 끼어들어 알립니다 — 후자는 긴급한 경고에만 절제하여 사용해야 합니다. 2025년 현재 약 33%의 사이트가 aria-live 속성을 사용하고 있으며, 이는 2024년보다 4% 증가한 수치지만, 배포된 동적 인터페이스의 수를 고려하면 여전히 너무 낮은 채택률입니다.

인터랙티브 컴포넌트에서의 포커스 관리 — 모달 대화 상자, 플라이아웃 메뉴, 아코디언 — 는 명시적으로 처리해야 합니다. 모달이 열리면 포커스는 그 안으로 이동해야 합니다. 모달이 닫히면 포커스는 이를 트리거한 요소로 돌아와야 합니다. 모달을 열었는데 포커스가 여전히 뒤에 있는 버튼에 머물러 있다면, 스크린 리더 사용자는 사실상 대화 상자의 콘텐츠에 접근할 수 없습니다.

스크린 리더로 사이트 테스트하기

자동 접근성 스캐너는 유용하지만 한계가 있습니다. 자동 도구는 WCAG 위반의 30–40%를 잡아내지만, 실제 보조 기술 테스트는 사이트를 사용자가 실제로 어떻게 경험하는지 — 누락된 맥락, 혼란스러운 탐색, 아예 작동하지 않는 상호작용 — 를 드러냅니다. 어떤 스캐너도 모달의 제목이 주변 시각적 맥락 없이는 전혀 의미가 통하지 않는다거나, 커스텀 드롭다운이 특정 브라우저-스크린 리더 조합에서만 상태를 잘못 알린다는 사실을 알려 주지 않습니다.

대부분의 팀에게 실질적인 출발점은 Firefox와 함께 사용하는 NVDA입니다 — 무료이고 널리 사용되며, 대부분의 일반적인 문제를 효과적으로 잡아냅니다. 여기에 macOS와 iOS 사용자를 커버하기 위해 Safari와 함께 사용하는 VoiceOver를 추가하십시오. 엔터프라이즈 환경이나 높은 컴플라이언스 요구 사항이 있는 클라이언트의 경우, Chrome 또는 Edge와 함께 사용하는 JAWS를 포함하십시오. 각 스크린 리더는 특정 브라우저 조합에서 가장 잘 작동하며, 잘못된 조합을 사용하면 오해를 불러일으키는 테스트 결과가 나올 수 있습니다.

테스트할 때는 실제 사용자가 사용하는 탐색 패턴을 채택하십시오. 마우스를 사용하지 마십시오. H 키로 제목을 따라 탐색하십시오. 링크 목록을 띄워 모든 링크가 문맥 밖에서도 의미가 통하는지 확인하십시오. 폼 필드를 Tab 키로 이동하며 각 라벨이 올바르게 읽히는지 확인하십시오. 모달 대화 상자를 열어 포커스가 그 안으로 이동하는지 검증하십시오. 폼을 작성하고 제출하면서 모든 검증 메시지를 들으십시오. 모니터를 끄고 대표적인 사용자 작업을 처음부터 끝까지 완료해 보십시오 — 시력이 있는 테스터에게는 불편한 경험이겠지만, 시각장애 사용자에게는 매일의 현실입니다.

또한 브라우저 에뮬레이터나 시뮬레이터가 아니라 실제 보조 기술로 테스트하는 것이 중요합니다. 브라우저 개발자 도구의 접근성 패널은 접근성 트리를 보여 주어 디버깅에 유용하지만, 청각적 경험을 재현하지 못하며 실제 스크린 리더 소프트웨어에서만 드러나는 상호작용 특이점을 보여 주지 못합니다.

무시할 수 없는 비즈니스 및 법적 근거

접근성에 대한 도덕적 근거를 상업적 현실로 보강해야 한다면, 숫자는 매우 분명합니다. 미국에만 약 700만 명의 시각 손상자가 있으며, 이는 상당한 소비자 기반을 의미합니다. 전 세계적으로는 미국 성인의 26%가 장애를 가지고 있으며, 이는 약 13조 달러의 시장 기회를 의미합니다. 접근할 수 없는 디자인으로 시각장애 사용자를 사이트에서 배제하면, 도덕적 의무를 저버릴 뿐 아니라 고객을 거부하고 조직을 법적 위험에 노출시키는 것입니다.

WCAG 2.2는 이제 수천 건의 ADA 소송에서 참조되는 법적 기준이며, 2025년 6월 민간 기업에 전면 적용된 European Accessibility Act는 EU 전역으로 컴플라이언스 요구 사항을 확장합니다. 대부분의 스크린 리더 사용자는 장벽에 대해 웹사이트 소유자에게 연락하지 않습니다 — 그들은 그냥 떠나 다른 곳에서 거래합니다. 문제를 결코 보고하지 않는 67%의 사용자는 만족한 것이 아니라, 좌절한 것입니다. 개발 프로세스 초기에 스크린 리더 호환성을 내장하면 비용이 많이 드는 사후 수정 작업을 피하고, 법적 노출을 줄이며, 실제로 사용할 수 있는 디지털 경험을 적극적으로 찾고 있는 사용자에게 제품을 개방할 수 있습니다.

핵심 요약

스크린 리더는 시각이 아니라 구조를 탐색합니다. 이들은 플랫폼 접근성 API를 통해 브라우저의 접근성 트리를 질의합니다. 올바른 제목, 랜드마크, 네이티브 컨트롤과 같은 시맨틱 HTML은 스크린 리더 호환성을 위해 할 수 있는 가장 영향력 있는 투자입니다.
시각장애 사용자는 선형적으로가 아니라 제목, 랜드마크, 요소 목록으로 탐색합니다. 88% 이상의 스크린 리더 사용자가 탐색을 위해 제목 수준이 매우 유용하거나 다소 유용하다고 답했습니다. 깨졌거나 누락된 제목 계층은 웹에서 가장 흔하고도 치명적인 접근성 실패 중 하나입니다.
ARIA는 좋은 마크업도, 나쁜 마크업도 증폭시킵니다. ARIA가 사용된 페이지는 그렇지 않은 페이지보다 평균 두 배 이상의 접근성 오류를 가지고 있습니다. 필요한 의미를 네이티브 HTML로 표현할 수 없는 경우에만 ARIA를 사용하고, 구현 후에는 항상 실제 보조 기술로 테스트하십시오.
CAPTCHA, 모호한 링크, 알리지 않은 동적 콘텐츠 변경이 현실에서 가장 큰 장벽입니다. 시각적 CAPTCHA를 행동 기반 검증으로 대체하고, 설명적인 링크 및 버튼 텍스트를 작성하며, 동적 업데이트에 ARIA 라이브 영역을 구현하면 시각장애 사용자의 사용성이 즉각적이고 측정 가능하게 향상됩니다.
여러 브라우저 조합에서 실제 스크린 리더로 테스트하십시오. 자동 스캐너는 WCAG 위반의 30–40%만 잡아냅니다. Firefox와 함께 사용하는 NVDA와 Safari와 함께 사용하는 VoiceOver는 비용 없이도 사용자 기반의 대부분을 커버하며, 마우스 없이 사이트를 탐색하는 경험은 어떤 자동 도구도 드러내지 못하는 문제를 밝혀 줍니다.

스크린 리더 설명: 시각장애 사용자는 웹을 어떻게 탐색할까