---
type: knowledge
domain: frontend
status: active
last-reviewed: 2026-07-27
---

# 접근성 실전

> 한 줄 정의
> 접근성은 스크린리더 전용 기능이 아니라 **키보드 사용자·저시력·일시적 제약(한 손에 짐·햇빛 아래) 전부**를 위한 기본 품질이다. 원칙 한 줄은 [[프론트엔드 원리]] — 여기는 실제로 무엇을 검사하고 어떻게 고치는지를 다룬다.

## 실무 최다 실수 5가지 — 여기부터 잡는다

| 실수 | 왜 문제인가 | 처방 |
|------|-----------|------|
| 명도 대비 부족 | 저시력·야외 환경에서 안 읽힘 — 자동 검사에서 가장 많이 걸리는 항목 | 본문 4.5:1, 큰 글씨(18pt+ 또는 14pt bold+) 3:1 이상, UI 요소·의미 있는 그래픽도 3:1 |
| 이미지 alt 누락/무의미 | 스크린리더가 "이미지"라고만 읽음 | 의미 있으면 내용 서술, 장식이면 `alt=""` (누락이 아니라 빈 값) |
| 폼 입력에 라벨 없음 | placeholder는 라벨이 아니다 — 입력을 시작하면 사라진다 | 모든 입력에 연결된 `<label>` |
| 링크 텍스트 "여기 클릭" | 링크만 모아 들으면 목적지를 알 수 없음 | 링크 텍스트만으로 목적지가 설명되게 |
| 색으로만 정보 전달 | 색각 이상 사용자에게 정보 소실 | 색 + 아이콘/텍스트/패턴 병행 |

## 키보드 — 가장 싼 전수 검사

마우스를 치우고 Tab만으로 한 바퀴 돌면 접근성 문제의 큰 덩어리가 그대로 드러난다:

- 모든 인터랙션 요소에 Tab으로 **도달**하고 표준 키로 **작동**하는가 — 링크는 Enter, 버튼은 Enter/Space, 체크박스는 Space. 복합 위젯(탭·메뉴 등)은 ARIA APG의 role별 키 패턴을 따른다.
- 포커스 순서 = 시각적 순서인가 (DOM 순서가 뒤틀리면 어긋난다).
- **지금 어디에 포커스가 있는지 항상 보이는가** — `outline: none` 후 대체 스타일 없음은 키보드 사용자에게 화면을 끄는 것과 같다.
- 모달: 열리면 포커스가 안으로 이동, Tab이 안에서 순환(포커스 트랩), Esc로 닫힘, 닫히면 열었던 버튼으로 복귀.

## 시맨틱 우선 — ARIA 제1규칙

> [!NOTE] ARIA의 제1규칙은 "ARIA를 쓰지 않는 것"
> `<div onclick>`에 role·tabindex·키 핸들러를 붙이는 것보다 `<button>` 하나가 낫다. 네이티브 요소는 키보드·포커스·의미 전달을 공짜로 준다. **잘못된 ARIA는 없는 것보다 해롭다** — 스크린리더에 거짓말을 하기 때문이다.

- 동작은 `<button>`, 이동은 `<a href>` — "클릭되는 div" 금지.
- 랜드마크(`header`·`nav`·`main`·`footer`)로 섹션 건너뛰기가 가능하게.
- 제목 계층(h1→h2→h3)을 건너뛰지 않는다 — 스크린리더 사용자는 제목 목록으로 문서를 탐색한다.

## 동적 콘텐츠

- 토스트·에러 메시지 등 갑자기 나타나는 정보는 `aria-live` 영역으로 알린다 — 안 하면 시각 외 사용자에겐 아무 일도 없었던 것이다.
- 로딩 상태 변화도 마찬가지 — 스피너는 시각 전용 신호다.
- `prefers-reduced-motion` 대응: 대형 모션·패럴랙스는 꺼질 수 있어야 한다. 전정기관 반응은 취향이 아니라 신체 증상이다.

## 터치·모바일

- 터치 타겟은 44×44px(iOS 관례)이 하한, **이 볼트의 납품 기본값은 48×48px** ([[04_접근성·반응형·성능 계획]]) — 링크 두 개가 붙어서 오터치가 나면 사용자 실수가 아니라 설계 문제다.
- 확대(pinch zoom) 차단 금지 (`user-scalable=no` 금지).

## 검사 방법 — 자동 도구의 한계

- 자동 검사(axe 계열)는 대비·alt처럼 기계 판별 가능한 항목만 잡는다. **"자동 검사 통과 = 접근 가능"이 아니다.**
- 최소 루틴: ① 자동 검사 ② 키보드로 핵심 플로우 한 바퀴 ③ 스크린리더(macOS는 VoiceOver)로 핵심 플로우 1회.
- 접근성 문제는 QA 신호이기도 하다 — 라벨 없는 폼은 E2E 테스트도 선택자로 고생한다. **접근 가능한 마크업 = 테스트 가능한 마크업.**

## 관련 문서

- [[프론트엔드 원리]] · [[웹 성능 실전]] · [[프론트엔드-체크리스트]] · [[00_프론트엔드 허브]]
- [[UX 원리]] — 인지 부하·포커스 설계와 연속선
- [[UI 시각 체계]] — 대비·타이포 토큰
- [[QA 원리]] — 탐색적 투어에 접근성 렌즈 추가