웹 접근성 실무 가이드
웹 접근성은 "장애인용 별도 페이지를 만드는 일"이 아닙니다. 하나의 페이지를 화면낭독기 사용자, 키보드만 쓰는 사용자, 저시력·색약 사용자, 고령자, 손 떨림이 있는 사용자, 시끄러운 지하철에서 소리 없이 영상을 보는 사용자가 모두 쓸 수 있게 만드는 일입니다. 대부분의 개선은 마크업 몇 줄이면 끝나고, 그 결과는 검색엔진 최적화·유지보수성 향상으로도 돌아옵니다.
1. 자동 검사가 잡는 것, 못 잡는 것
자동 검사 도구는 접근성 문제의 약 30~40%만 찾아냅니다. 이것은 특정 도구의 성능 문제가 아니라 원리상의 한계입니다. 기계는 "alt 속성이 있는가"는 확인할 수 있지만 "그 alt가 이미지 내용을 제대로 설명하는가"는 판단할 수 없기 때문입니다.
| 자동으로 확실히 잡히는 것 | 사람이 봐야 하는 것 |
|---|---|
| alt 속성 누락, 빈 버튼·링크 이름, label 없는 입력창 | alt 문구가 이미지의 의미를 전달하는지 |
| 제목(h1~h6) 단계 건너뜀, 중복 id, 표의 th 누락 | 제목 구조가 실제 문서 논리와 맞는지 |
| CSS로 계산 가능한 명도 대비 | 배경 이미지·그라디언트 위 글자의 실제 대비 |
| tabindex 양수, div에 걸린 클릭 핸들러 | 탭 순서가 화면 흐름과 맞는지, 포커스가 갇히지 않는지 |
| role 오타, 깨진 aria 참조 | ARIA 상태(aria-expanded 등)가 실제 동작과 동기화되는지 |
| 자동 재생, 확대 차단, meta refresh | 동영상 자막·수어·음성해설의 품질 |
그래서 실무 순서는 자동 검사 → 수동 점검 → 실사용자 확인 순입니다. 자동 검사는 "명백한 실수"를 싸게 걷어내는 1차 필터로 쓰고, 남는 시간을 수동 점검에 쓰는 것이 효율적입니다.
2. 분야별 체크리스트
2-1. 대체 텍스트 (WCAG 1.1.1)
- 정보를 전달하는 이미지 — 이미지가 사라졌을 때 대신 읽어 줄 문장을 씁니다.
alt="2025년 분기별 매출 추이 그래프, 3분기에 최고치" - 장식용 이미지 —
alt=""로 비워서 선언합니다. 속성 자체를 빼면 안 됩니다. 속성이 없으면 화면낭독기가 파일 이름을 읽습니다. - 링크 안의 이미지 — alt에는 이미지 설명이 아니라 링크 목적지를 씁니다.
<a href="/event"><img alt="여름 할인 이벤트 안내"></a> - 아이콘 폰트·SVG — 의미가 있으면
role="img"+ 이름을, 장식용이면aria-hidden="true"를 붙입니다. - "이미지", "사진", "logo.png" 같은 alt는 없는 것과 같습니다.
2-2. 버튼·링크 이름 (WCAG 4.1.2 / 2.4.4)
- 아이콘만 있는 버튼에는
aria-label="장바구니 열기"를 붙입니다. - 링크 텍스트만 읽어도 목적지를 알 수 있어야 합니다. 화면낭독기 사용자는 링크만 따로 모아 훑는 기능을 자주 씁니다.
❌ "자세히 보기" ✅ "요금제 자세히 보기" - 같은 문구의 링크가 여러 개인데 목적지가 다르면,
aria-label로 구분해 줍니다. <div onclick>은 버튼이 아닙니다. 탭으로 도달할 수 없고 Enter로 실행되지도 않습니다.<button type="button">으로 바꾸는 것이 가장 확실합니다.
2-3. 색상 대비 (WCAG 1.4.3)
- 일반 글자 4.5:1, 큰 글자(24px 이상, 또는 굵은 18.66px 이상) 3:1 이상.
- 연한 회색 본문(
#999위 흰 배경 = 2.85:1)은 대표적인 미달 사례입니다.#767676부터 흰 배경에서 4.5:1을 겨우 넘깁니다. - 버튼 테두리·입력창 경계선 같은 UI 요소도 3:1이 필요합니다(1.4.11).
- 색만으로 정보를 전달하지 마세요(1.4.1). 오류를 빨간색으로만 표시하면 색약 사용자는 알 수 없습니다. 아이콘이나 문구를 함께 넣습니다.
2-4. 키보드 조작 (WCAG 2.1.1 / 2.4.7)
- 모든 기능은 마우스 없이 Tab, Shift+Tab, Enter, Space, 방향키만으로 쓸 수 있어야 합니다.
- 포커스 표시를 지우지 마세요.
outline: none만 쓰고 대체 표시를 넣지 않으면 키보드 사용자는 자기가 어디에 있는지 알 수 없습니다. 디자인이 문제라면:focus-visible에 눈에 띄는 테두리나 그림자를 넣으세요. tabindex에 양수를 쓰지 마세요. 탭 순서가 화면 순서와 어긋납니다. 필요한 것은tabindex="0"(순서에 포함)과tabindex="-1"(스크립트로만 포커스) 두 가지뿐입니다.- 팝업이 열리면 포커스를 팝업 안으로 옮기고, 닫으면 열었던 버튼으로 되돌립니다. 팝업이 열린 동안 뒤쪽 요소로 탭이 빠져나가면 안 됩니다.
- 페이지 맨 앞에
<a href="#main">본문 바로가기</a>를 두면 매번 메뉴를 지나지 않아도 됩니다.
2-5. 입력창·양식 (WCAG 3.3.2 / 3.3.1)
- 모든 입력칸에
<label for="id">를 연결합니다. placeholder는 레이블이 아닙니다 — 입력을 시작하면 사라지고, 일부 화면낭독기는 읽지 않습니다. - 오류 메시지는 어느 칸이 왜 잘못됐는지 글로 알려야 합니다. 테두리를 빨갛게 만드는 것만으로는 부족합니다.
- 오류 안내는
aria-describedby로 입력칸과 연결하고, 동적으로 뜬다면role="alert"이나aria-live영역에 넣습니다. - 이름·이메일·전화번호 칸에는
autocomplete를 넣습니다(1.3.5). 반복 입력 부담이 크게 줄어듭니다. - 라디오·체크박스 묶음은
<fieldset>+<legend>로 감쌉니다.
2-6. 구조·탐색 (WCAG 1.3.1 / 2.4.1 / 2.4.2)
<html lang="ko">가 없으면 화면낭독기가 한국어를 영어 발음으로 읽습니다. 한 줄이지만 체감 차이가 가장 큽니다.- 페이지마다 고유한
<title>을 씁니다. 탭을 여러 개 열었을 때의 구분 기준입니다. - 제목은 h1부터 단계를 건너뛰지 않고 내려갑니다. 글자 크기 때문에 h4를 쓰는 것은 CSS로 해결할 일입니다.
<header> <nav> <main> <footer>로 영역을 나누면 화면낭독기 사용자가 영역 단위로 건너뜁니다.- 표에는
<th scope="col|row">와<caption>을 넣습니다. 레이아웃용 표는 애초에 쓰지 않는 편이 낫습니다.
2-7. 메뉴·팝업 등 동적 요소 (WCAG 4.1.2)
- ARIA의 첫 번째 규칙은 "쓰지 않는 것"입니다. 표준 HTML 요소로 되는 일은 그렇게 하세요. 잘못 붙인 ARIA는 없느니만 못합니다.
- 펼침 메뉴에는
aria-expanded="true|false"를 실제 상태에 맞춰 갱신합니다. - 모달에는
role="dialog" aria-modal="true"와 제목 연결(aria-labelledby)이 필요합니다. - 탭 UI는
role="tablist" / "tab" / "tabpanel"세트를 맞춰 씁니다. 하나만 붙이면 오히려 혼란스럽습니다. aria-hidden="true"를 붙인 영역 안에 탭으로 갈 수 있는 요소를 남겨두지 마세요. "보이지도 않는데 포커스는 가는" 상태가 됩니다.
3. 수동 점검 — 15분이면 되는 3가지
3-1. 키보드만으로 써 보기 (5분)
마우스에서 손을 떼고 Tab만으로 페이지를 처음부터 끝까지 지나가 보세요. 확인할 것은 세 가지입니다.
- 지금 어디에 포커스가 있는지 눈으로 보이는가
- 탭 순서가 화면에 보이는 순서와 같은가
- 메뉴·팝업·슬라이더 등 모든 기능을 실행할 수 있는가, 그리고 빠져나올 수 있는가
3-2. 화면낭독기로 들어 보기 (5분)
- Windows — NVDA(무료). 실행 후 Insert+↓로 페이지 읽기 시작, H로 제목 이동, K로 링크 이동, F로 폼 요소 이동.
- macOS/iOS — VoiceOver 내장. Cmd+F5로 켜고 Ctrl+Option+→로 이동.
- Android — TalkBack 내장.
전부 들을 필요는 없습니다. 제목 목록만 훑어도 페이지 구조가 말이 되는지, 링크 목록만 훑어도 "여기", "클릭"이 몇 개나 되는지 바로 드러납니다.
3-3. 확대·축소와 색상 (5분)
- 브라우저를 200%로 확대해도 내용이 잘리거나 겹치지 않는지(1.4.4).
- 가로 폭 320px(모바일)에서 가로 스크롤 없이 읽히는지(1.4.10).
- 흑백으로 바꿔 봐도 정보를 구분할 수 있는지(1.4.1).
4. 우선순위 — 무엇부터 고칠 것인가
모든 것을 한 번에 고칠 수는 없습니다. 다음 순서를 권합니다.
- 기능을 아예 못 쓰게 만드는 것 — 키보드로 도달 불가능한 버튼, 이름 없는 제출 버튼, 레이블 없는 로그인 입력창. 사용자가 목적을 달성하지 못하는 문제입니다.
- 모든 페이지에 공통으로 깔린 것 —
lang속성, 헤더·푸터의 아이콘 링크, 전역 CSS의outline: none. 한 곳만 고쳐도 사이트 전체가 좋아집니다. - 핵심 흐름(가입·검색·결제)에 있는 것 — 방문자 대부분이 지나는 길입니다.
- 정보 전달을 방해하는 것 — 대비 미달, 제목 구조.
- 나머지
이 도구의 심각도(치명적 / 높음 / 보통 / 낮음)는 위 순서를 그대로 반영합니다. "치명적"부터 처리하면 자연스럽게 우선순위가 맞습니다.
5. 자주 하는 오해
- "접근성은 시각장애인만을 위한 것" — 키보드 접근성은 손 사용이 불편한 사용자와 파워 유저 모두에게 필요하고, 자막은 소리를 켤 수 없는 상황의 모든 사용자에게 쓰입니다.
- "오버레이 위젯을 달면 해결된다" — 페이지 위에 접근성 도구 모음을 얹어 주는 상용 위젯은 근본 마크업을 고치지 않습니다. 오히려 화면낭독기와 충돌하는 사례가 보고돼 왔습니다. 마크업을 고치는 것이 정답입니다.
- "디자인이 희생된다" — 포커스 표시와 대비 확보는 디자인 시스템 안에서 충분히 다룰 수 있습니다. 실제로 대비를 올리면 밝은 야외에서의 가독성도 함께 좋아집니다.
- "자동 검사에서 100점이면 끝" — 이 도구의 100점은 "자동으로 확인 가능한 항목에서 문제를 못 찾았다"는 뜻입니다. 준수 여부를 보증하지 않습니다.
6. 국내 제도 관련 참고
국내에서는 「장애인차별금지 및 권리구제 등에 관한 법률」에 따라 정보 접근에 대한 정당한 편의 제공 의무가 있으며, 공공기관 등을 중심으로 한국형 웹 콘텐츠 접근성 지침(KWCAG) 2.2가 적용됩니다. KWCAG는 W3C의 WCAG 2.1을 바탕으로 하고 있어, WCAG 기준으로 점검하면 대부분의 항목이 함께 충족됩니다.
이 문서와 이 도구는 기술적 참고 자료이며 법률 자문이 아닙니다. 의무 적용 대상 여부, 인증(웹 접근성 품질인증) 취득 요건 등은 소관 기관의 안내와 전문가 확인이 필요합니다.
7. 더 볼 만한 자료
- WCAG 2.1 Quick Reference (W3C) — 성공기준별 충족 방법
- ARIA Authoring Practices Guide — 탭·모달·콤보박스 등 위젯 구현 패턴
- 웹접근성연구소 — 국내 지침·인증 안내
- NVDA — 무료 화면낭독기
이 가이드는 웹 접근성 검사·수정 도우미의 검사 항목과 같은 기준(WCAG 2.1)으로 작성했습니다.
검사 결과에 나온 항목을 여기서 찾아보면 배경 설명을 확인할 수 있습니다.
문의: dkdnj123@gmail.com