장애 사용자의 웹 이용 전략

전맹 사용자 — 스크린 리더 탐색

Users Without Vision — Screen Reader Navigation

스크린 리더 사용자는 페이지를 위에서 아래로 다 듣지 않습니다. 대표 전략: 헤딩 단축키(H, 1~6)로 구조를 건너뛰며 훑기, 랜드마크(main, nav 등)로 영역 간 이동, 링크 목록·헤딩 목록 대화상자(예: NVDA 요소 목록, VoiceOver 로터)에서 알파벳 탐색, 첫 글자 내비게이션, 찾기 기능. WebAIM 설문에서 헤딩 탐색은 수년째 압도적 1위 전략입니다.

Screen reader users don't listen to pages top to bottom. Primary strategies: skimming structure with heading shortcuts (H, 1–6), jumping between regions via landmarks (main, nav), alphabetical browsing in link/heading list dialogs (NVDA's elements list, VoiceOver's rotor), first-letter navigation, and find. In WebAIM's surveys, heading navigation has been the dominant strategy for years.

이 전략들이 작동하려면: 논리적 헤딩 계층, 올바른 랜드마크, 맥락 없이도 이해되는 링크 텍스트('여기를 클릭' 금지), 정확한 폼 레이블이 필요합니다. 또한 스크린 리더는 '가상 버퍼/브라우즈 모드'와 '포커스/폼 모드'를 전환하며 작동하므로, 커스텀 위젯이 role과 키보드 처리를 제대로 구현해야 모드 전환이 자연스럽습니다.

For these to work you need: a logical heading hierarchy, correct landmarks, link text that makes sense out of context (no 'click here'), and accurate form labels. Screen readers also switch between virtual buffer/browse mode and focus/forms mode, so custom widgets must implement roles and keyboard handling correctly for smooth mode switching.

저시력·읽기 제한 사용자

Users with Low Vision and Limited Reading

저시력 사용자의 도구는 다양합니다: 브라우저 확대(200~400%), 화면 확대 프로그램(부분 확대·따라가기), 고대비/색상 반전 모드, 사용자 지정 글꼴·색상, 큰 커서. 핵심 요구: 400% 확대에서 가로 스크롤 없이 읽히는 리플로우(1.4.10), 확대해도 잘리지 않는 콘텐츠, 색에만 의존하지 않는 구분, 충분한 기본 대비. 일부는 스크린 리더를 병행합니다.

Low-vision users employ varied tools: browser zoom (200–400%), screen magnifiers (partial zoom with focus tracking), high-contrast/inverted modes, custom fonts and colors, large cursors. Key requirements: reflow at 400% zoom without horizontal scrolling (1.4.10), content that doesn't clip when enlarged, distinctions not by color alone, and adequate default contrast. Some also run a screen reader alongside.

읽기 제한(난독증 등) 사용자는 텍스트 음성 변환(TTS)으로 읽기를 보완하고, 읽기 도구(줄 강조, 글꼴 교체, 배경색 변경)를 씁니다. 콘텐츠 요구: 명확한 언어, 짧은 문단, 목록·헤딩으로 구조화, lang 속성의 정확한 지정(TTS 발음 결정), 텍스트를 이미지로 만들지 않기(도구가 조작할 수 없음).

Users with limited reading (e.g., dyslexia) supplement reading with text-to-speech and reading tools (line highlighting, font swapping, background tinting). Content requirements: clear language, short paragraphs, structure via lists and headings, accurate lang attributes (which drive TTS pronunciation), and never rendering text as images (tools cannot manipulate them).

운동 장애 사용자 — 키보드·스위치·음성

Users with Motor Disabilities — Keyboard, Switch, Voice

마우스를 못 쓰거나 정밀 조작이 어려운 사용자의 전략: 키보드 전용 탐색(Tab/Shift+Tab, Enter/Space), 스위치 접근(한두 개의 스위치 + 스캐닝), 음성 제어(Dragon, 음성 컨트롤 — 보이는 레이블을 말해 클릭), 헤드 포인터·시선 추적, 키가드와 대체 키보드. 트랙볼이나 조이스틱으로 마우스를 대신하기도 합니다.

Users who can't use a mouse or lack fine motor control rely on: keyboard-only navigation (Tab/Shift+Tab, Enter/Space), switch access (one or two switches plus scanning), voice control (Dragon, Voice Control — speaking visible labels to click), head pointers and eye tracking, keyguards and alternative keyboards. Trackballs or joysticks may replace mice.

콘텐츠 요구사항: 모든 기능의 키보드 접근(2.1.1)과 보이는 포커스(2.4.7), 논리적 포커스 순서, 건너뛰기 링크, 충분한 타깃 크기(2.5.8), 드래그의 대안(2.5.7), 시간 제한 조절(2.2.1). 음성 제어 사용자를 위해 접근 가능한 이름에 보이는 레이블 텍스트가 포함되어야 합니다(2.5.3 Label in Name) — 화면에 '검색'이라 쓰인 버튼의 접근 가능한 이름이 '찾기'라면 '검색 클릭'이 실패합니다.

Content requirements: keyboard access to everything (2.1.1) with visible focus (2.4.7), logical focus order, skip links, adequate target size (2.5.8), alternatives to dragging (2.5.7), adjustable time limits (2.2.1). For voice control users, the accessible name must contain the visible label text (2.5.3 Label in Name) — if a button showing '검색' has an accessible name of '찾기', saying 'click 검색' fails.

인지·청각 사용자

Users with Cognitive and Auditory Disabilities

인지 장애 사용자의 전략과 대응: 익숙한 패턴에 의존하므로 일관된 내비게이션(3.2.3)과 예측 가능한 동작(3.2.1~2)이 중요합니다. 주의 분산에 취약하므로 움직임 정지 수단(2.2.2), 시간 연장(2.2.1)이 필요하고, 기억 부담을 줄이는 자동 완성(1.3.5)·로그인 간소화(3.3.8)·오류 복구 안내(3.3.3)가 돕습니다. 일부는 광고 차단기, 리더 모드, 단순화 확장을 사용합니다.

Cognitive strategies and responses: users rely on familiar patterns, so consistent navigation (3.2.3) and predictable behavior (3.2.1–2) matter. Vulnerable to distraction, they need ways to stop motion (2.2.2) and extend time (2.2.1); autocomplete (1.3.5), simpler logins (3.3.8), and error recovery guidance (3.3.3) reduce memory burden. Some use ad blockers, reader modes, and simplification extensions.

농·난청 사용자의 전략: 자막(라이브는 실시간 자막)과 대본에 의존하고, 일부 농인은 수어가 제1언어라 복잡한 문어 텍스트가 제2언어일 수 있음을 기억해야 합니다. 콘텐츠 요구: 모든 오디오의 자막(1.2.2)·대본, 음성 전용 안내 금지, 소리 알림의 시각적 대응물, 고객 지원의 텍스트 채널(채팅·이메일 — 전화 전용 금지).

Deaf and hard-of-hearing strategies: reliance on captions (live captions for live content) and transcripts; remember that for some Deaf users sign language is their first language, making complex written text a second language. Content requirements: captions (1.2.2) and transcripts for all audio, no voice-only flows, visual counterparts to sound alerts, and text channels for support (chat, email — never phone-only).

사용자 선호 방식 vs 사이트 특정 방식

User-Preferred vs. Website-Specific Methods

BoK가 강조하는 원칙: 사용자는 자신의 보조기술과 몸에 밴 전략(사용자 선호 방식)으로 모든 사이트를 탐색하고 싶어 하며, 사이트마다 다른 특수 장치(사이트 특정 방식 — 자체 접근성 위젯, 독자적 단축키, '접근성 모드' 별도 페이지)를 새로 배우기를 원하지 않습니다. 별도 접근성 오버레이 위젯이 비판받는 이유가 여기 있습니다 — 표준 시맨틱을 올바르게 쓰면 사용자의 기존 도구가 그대로 작동합니다.

The BoK's principle: users want to navigate every site with their own assistive technology and ingrained strategies (user-preferred methods), not to learn a new site-specific apparatus per site (custom accessibility widgets, proprietary shortcuts, separate 'accessibility mode' pages). This is why accessibility overlay widgets draw criticism — correct standard semantics let users' existing tools just work.

실무 결론: 표준 HTML 시맨틱과 WCAG 준수로 '사용자의 방식'을 지원하는 것이 우선이고, 사이트 고유 편의 기능(예: 단축키)은 표준을 보완하는 선택지로만 제공하며 충돌을 피해야 합니다(2.1.4 문자 단축키). 이 관점은 시험 전반 — 커스텀 위젯, 오버레이, 접근성 기능 설계 문항 — 의 판단 기준이 됩니다.

The practical conclusion: supporting users' own methods through standard HTML semantics and WCAG conformance comes first; site-specific conveniences (e.g., shortcuts) are optional supplements that must avoid conflicts (2.1.4 Character Key Shortcuts). This perspective is the judgment standard across exam questions on custom widgets, overlays, and accessibility feature design.