오늘 하루를 잠깐 돌아봐 주세요.
지하철에서 소리 없이 자막으로 영상을 봤나요? 햇빛 아래서 화면이 안 보여 밝기를 한껏 올렸나요? 한 손에 짐을 들고 엄지 하나로 스마트폰을 조작했나요? 눈이 피로해서 야간 모드나 다크모드를 켰나요?
축하합니다. 당신은 이미 접근성 유저입니다.
내일(5월 21일)은 세계 접근성 인식의 날, GAAD(Global Accessibility Awareness Day) 입니다.
GAAD는 2012년 웹 개발자 Joe Devon과 Jennison Asuncion이 시작한 캠페인으로, 매년 5월 셋째 주 목요일에 열립니다. 전 세계 10억 명이 넘는 장애인이 디지털 기술을 동등하게 사용할 수 있도록 인식을 높이는 것이 목표예요. 기업, 개발자, 디자이너, 일반 사용자 모두가 참여할 수 있고, 공식 홈페이지에서 다양한 이벤트와 참여 방법을 확인할 수 있습니다.
그런데 많은 분들이 이렇게 생각하시죠.
“접근성이요? 저는 장애인이 아닌데요.”
오늘 그 오해를 한번 풀어보고 싶습니다.

사진: camilo jimenez / Unsplash
“장애인만을 위한 것"이라는 오해#
‘접근성’이라는 단어를 들으면 무엇이 떠오르시나요?
점자 블록, 휠체어 마크, 저상버스, 시각장애인용 음성 안내… 아마 이런 것들이 먼저 떠오를 거예요. 웹 접근성도 마찬가지입니다. “스크린 리더 사용자를 위한 기능”, “시각장애인을 위한 alt 텍스트” 같은 이미지가 강하죠.
맞는 말이기도 합니다. 하지만 전부는 아니에요.
W3C(World Wide Web Consortium)는 웹 접근성을 이렇게 정의합니다.
“장애 여부와 관계없이 모든 사람이 웹을 인식하고, 이해하고, 탐색하고, 상호작용할 수 있도록 하는 것”
핵심은 “모든 사람” 입니다. 장애인만이 아니라, 고령자, 일시적으로 불편한 상태의 사람, 그리고 어떤 상황에서 사용하는 모든 사람을 포함해요.
세 가지 장애 유형: 생각보다 넓은 범위#
마이크로소프트의 포용적 디자인(Inclusive Design) 팀은 장애를 세 가지 유형으로 나눕니다. 이 분류가 “접근성은 나와 무관하다"는 생각을 바꿔줍니다.
| 유형 | 정의 | 예시 |
|---|---|---|
| 영구적 장애 | 지속되는 신체·감각의 차이 | 시각장애, 청각장애, 사지마비, 언어장애 |
| 일시적 장애 | 회복이 가능한 상태 | 팔 골절, 눈 수술 후, 귀 염증, 손 부상 |
| 상황적 장애 | 환경이 만들어내는 제약 | 햇빛 아래, 지하철 소음, 아기 안고 한 손, 장갑 낀 손 |

Microsoft Inclusive Design 프레임워크에서 영감을 받은 장애 유형 분류
여기서 주목할 건 상황적 장애예요. 영구적·일시적 장애는 특정 상황에서 발생하지만, 상황적 장애는 누구나 매일 겪습니다. 지하철에서 이어폰 없이 영상을 보거나, 운전 중 음성으로 길 안내를 듣거나, 밝은 야외에서 스마트폰을 쓸 때 — 이 모든 순간이 상황적 장애 상태예요.
이 세 가지 유형을 합치면, 어느 시점에 어떤 형태로든 “접근성이 필요한 상황"에 놓이지 않는 사람은 사실 거의 없습니다.
연석 절단 효과: 모두를 위한 설계의 힘#
1970년대 미국 캘리포니아 버클리. 장애인 권리 활동가들이 도로 연석을 깎아내는 작업을 직접 감행했습니다. 휠체어가 인도와 차도 사이를 자유롭게 오갈 수 있도록요.
그런데 신기한 일이 벌어졌습니다. 연석이 낮아지자, 유모차를 끄는 부모, 캐리어를 끄는 여행자, 자전거 라이더, 배달 카트를 미는 상인까지 — 예상치 못한 수많은 사람들이 그 혜택을 누리게 된 거예요.
이것이 커브 컷 효과(Curb Cut Effect) 입니다. 특정 집단을 위한 설계가 결국 모든 사람에게 편리함을 가져다준다는 것이죠.

사진: Michael Hamments / Unsplash
웹에서도 똑같은 일이 일어납니다.
- 자막: 청각장애인을 위해 만들었지만 → 소음 많은 카페, 조용히 해야 하는 도서관, 외국어 학습자 모두가 활용
- 키보드 접근성: 운동 장애인을 위해 만들었지만 → Vim 사용자, 파워 유저, 손 부상자 모두가 활용
- alt 텍스트: 시각장애인을 위해 만들었지만 → 검색엔진(SEO), 이미지 로딩 실패 시 텍스트 표시, 느린 네트워크 환경 모두에게 도움
- 충분한 색 대비: 색각이상 사용자를 위해 만들었지만 → 햇빛 아래, 노안, 저해상도 화면 모두에게 도움
접근성 기능은 “누군가를 배려하기 위한 추가 기능"이 아니에요. 처음부터 더 잘 만든 것입니다.
숫자로 보는 실제 규모#
세계보건기구(WHO)에 따르면 전 세계 인구의 16%, 약 13억 명이 어떤 형태로든 장애를 가지고 있습니다. 그런데 여기에 일시적·상황적 장애까지 포함하면 어떨까요?
한국은 이미 초고령사회에 진입했습니다. 65세 이상 인구가 전체의 20%를 넘어섰고, 고령화에 따른 시력 저하, 청력 감소, 손 떨림은 모두 접근성과 직결됩니다.
결론적으로, “접근성이 전혀 필요 없는 사람"이 오히려 드문 것이 현실입니다. 우리는 그저 그 사실을 인식하지 못하고 있을 뿐이에요.
개발자를 위한 GAAD 실천 — AI와 함께라면 더 쉽다#
여기까지 읽으신 개발자분들께 드리는 이야기입니다. “알겠는데 어디서부터 시작하지?” 싶으시다면, 오늘 딱 세 가지만 해보세요.
기본 3가지 (5분이면 충분)#
① 이미지 alt 텍스트 확인
Chrome DevTools에서 이미지를 우클릭 → Inspect하면 alt 속성이 보입니다. 비어있다면 추가하고, 장식용 이미지라면 alt=""로 명시해주세요.
② 키보드 탭 테스트
마우스를 내려놓고 Tab 키로만 내 사이트를 탐색해보세요. 포커스 링이 보이는가? 논리적인 순서로 이동하는가? 직접 해보면 숨어있던 문제들이 바로 보입니다.
③ 색 대비 확인
Chrome DevTools → Lighthouse → Accessibility 탭을 실행하면 색 대비 문제를 자동으로 잡아줍니다.
AI를 접근성 파트너로 활용하기#
요즘 개발자 대부분이 AI 코딩 도구를 쓰고 있죠. Cursor, GitHub Copilot, Claude Code… 그렇다면 AI를 접근성 개선에도 적극적으로 활용해볼 수 있습니다.
① CLAUDE.md에 접근성 규칙 박아두기
Claude Code를 쓴다면 프로젝트 루트의 CLAUDE.md에 접근성 규칙을 명시해두세요. 한 번 적어두면 Claude가 코드를 생성할 때마다 자동으로 따릅니다.
## 코드 작성 규칙
- 모든 인터랙티브 요소는 키보드로 접근 가능해야 합니다
- 이미지에는 반드시 의미 있는 alt 텍스트를 포함하세요 (장식용은 alt="")
- 버튼과 링크에는 명확한 레이블이 있어야 합니다
- 색상만으로 정보를 전달하지 마세요
- div, span보다 시맨틱 HTML 요소를 우선 사용하세요매번 프롬프트에 접근성을 언급하지 않아도 됩니다. 규칙이 프로젝트에 심어져 있으니까요.
② 접근성 리뷰 슬래시 커맨드 만들기
Claude Code에서는 .claude/commands/ 폴더에 마크다운 파일을 추가하면 /커맨드명으로 바로 실행할 수 있습니다. 접근성 리뷰 전용 커맨드를 만들어두면 편리해요.
.claude/commands/a11y-review.md:
현재 파일 또는 지정한 컴포넌트를 WCAG 2.2 기준으로 검토합니다.
확인 항목:
- 키보드 접근성 (Tab 순서, 포커스 링, 키보드 트랩)
- ARIA 속성 (role, aria-label, aria-describedby 등)
- 이미지 alt 텍스트
- 색 대비 (4.5:1 이상)
- 시맨틱 HTML 구조
- 에러 메시지 접근성
문제를 발견하면 수정 코드와 함께 이유를 설명해주세요.이제 코드 작업 중 언제든 /a11y-review를 입력하면 즉시 접근성 리뷰를 받을 수 있어요.
③ axe-core 에러를 AI에게 붙여넣고 수정 요청
Lighthouse나 axe-core로 뽑은 접근성 오류 메시지를 그대로 AI에게 붙여넣으면, 원인 설명과 수정 코드를 한 번에 받을 수 있습니다.
다음 axe-core 접근성 오류를 수정해줘:
[에러 메시지 붙여넣기]④ alt 텍스트 초안 받기
이미지가 무엇을 보여주는지, 글에서 어떤 맥락으로 쓰이는지 설명하면 AI가 alt 텍스트 초안을 잡아줍니다. 단, 최종 검토는 사람이 해야 합니다. AI는 이미지가 전체 맥락에서 어떤 역할을 하는지 완전히 파악하지 못하거든요.
한 가지 주의할 점
AI가 짜준 코드라고 해서 접근성이 자동으로 보장되지는 않아요. 오히려 빠르게 생성된 코드일수록 <div> 남용, ARIA 속성 누락이 자주 나타납니다. 규칙을 심어두고, 슬래시 커맨드로 주기적으로 검토하는 것 — 이 두 가지 습관이 AI 시대의 접근성을 지켜줍니다.
마무리#
언젠가 당신이 만든 서비스를 누군가 처음으로 열어봅니다.
마우스 없이 Tab 키로 조심스럽게 탐색하는 사람일 수도 있고, 화면 확대를 켜고 작은 글씨를 읽는 사람일 수도 있어요. 아니면 지하철에서 소리 없이 자막으로 영상을 보던 — 오늘의 당신일 수도 있습니다.
접근성은 “착한 일"이 아닙니다. 내가 만든 것에 더 많은 사람이 닿을 수 있도록 하는 일입니다.
오늘 딱 하나만 해보세요. Tab 키로 내 서비스를 한 번 탐색해보는 것. 그게 전부여도 충분합니다.
GAAD 2026, 5월 21일. 당신은 이미 접근성 유저입니다.
