Back_to_Basics

{3줄 요약}

접근성은 특별 케어가 아니라 누구나 여러 상황에서 쓰게 만드는 기반이에요.
기준을 지키면 해가 진 야외 화면이나 한 손 사용 같은 평범한 순간도 덜 불편해져요.
그래서 접근성은 뒤에 붙이는 옵션이 아니라 설계 처음부터 같이 지는 게 비용도 경험도 유리해요.

이 방법이 필요한 순간이에요

웹 서비스, 모바일 앱, 디지털 콘텐츠를 만들 때마다 접근성이 적용돼요.

특히 공공기관, 금융, 의료 서비스는 법적 접근성 기준(「장애인차별금지법」, WCAG)을 준수해야 해요.
하지만 법적 의무 이전에, 더 많은 사람이 쓸 수 있는 서비스를 만드는 게 더 좋은 서비스예요.

"접근성 = 장애인 사용자를 위한 것"이라고 생각하면 좁게 보는 거예요.
전 세계 인구의 15%가 어떤 형태의 장애를 갖고 있어요(WHO 수치).
하지만 접근성 개선으로 혜택을 받는 사람은 훨씬 더 많아요.

접근성을 저해하는 네 가지 장애 유형

시각적 장애: 완전 실명부터 색각 이상까지 다양해요.
화면 낭독기(Screen Reader)를 쓰는 사람도 있고, 색을 다르게 인식하는 사람도 있어요.

청각적 장애: 동영상의 오디오 정보를 들을 수 없어요.
자막과 수어 영상이 필요해요.

운동 장애: 마우스나 터치스크린을 정밀하게 쓰기 어려워요.
키보드만으로 조작할 수 있어야 해요.

인지 장애: 복잡한 언어, 긴 텍스트, 빠르게 바뀌는 콘텐츠가 어렵게 느껴져요.
명확하고 단순한 인터페이스가 도움이 돼요.

실행 순서를 이렇게 나눠요

1단계 — 색 대비 기준 확인하기

WCAG 2.1 기준으로 일반 텍스트의 색 대비 비율은 최소 4.5:1이에요.
큰 텍스트(18px Bold 이상 또는 24px 이상)는 3:1이에요.

측정 도구: WebAIM Contrast Checker, Figma 플러그인 Contrast, 브라우저 DevTools.

색맹 사용자를 위해: 색만으로 정보를 전달하면 안 돼요.
오류는 빨간색과 함께 느낌표 아이콘이나 텍스트를 병행해요.
링크는 색 외에 밑줄로도 구분해요.

2단계 — 모든 이미지에 대체 텍스트(alt text) 달기

화면 낭독기는 이미지를 읽을 수 없어요.
alt 속성에 이미지를 설명하는 텍스트를 달아야 해요.

✅ alt="배달의민족 로고 — 음식 배달 앱" — 내용을 설명
❌ alt="image_01.jpg" — 파일명은 설명이 아님
❌ alt="" (장식용 이미지는 빈 alt로 써도 되지만, 정보를 담은 이미지는 안 됨)

단, 순수 장식 이미지(배경 패턴 등)는 alt=""로 비워두는 게 맞아요.
낭독기가 읽지 않아야 해요.

3단계 — 키보드 접근성 확보하기

마우스 없이 키보드 Tab 키만으로 모든 인터랙티브 요소에 접근할 수 있어야 해요.

확인 방법: 페이지에서 마우스를 사용하지 않고 Tab 키만 눌러봐요.
모든 버튼, 링크, 입력창, 드롭다운에 포커스가 가는지 확인해요.

자주 발생하는 문제:

드롭다운 메뉴가 키보드로 열리지 않아요
모달 창이 키보드 포커스를 가두지 않아서 모달 밖의 요소로 Tab이 이동해요
커스텀 UI 컴포넌트(슬라이더, 탭 등)가 키보드 조작을 지원하지 않아요

포커스 인디케이터(Focus Indicator, 현재 포커스된 요소를 표시하는 테두리)가 보여야 해요.
CSS로 outline: none을 전체에 적용하는 것은 접근성을 심각하게 해쳐요.

4단계 — 적절한 HTML 시맨틱 구조 사용하기

<button> 태그로 만든 버튼과 <div onclick> 으로 만든 버튼은 시각적으로 같아 보여도 접근성이 달라요.

<button>은 자동으로 키보드 접근(Tab, Enter), 화면 낭독기 인식이 돼요.
<div>는 추가 ARIA 속성이 필요해요.

중요한 HTML 시맨틱:

제목 위계: <h1>, <h2>, <h3> 순서를 건너뛰지 않아요
랜드마크: <header>, <nav>, <main>, <footer> — 낭독기 사용자가 페이지를 빠르게 이동해요
폼 레이블: <label for="input-id"> — 입력창과 레이블이 연결되어야 해요

5단계 — 동영상과 미디어 접근성

동영상에는 자막이 있어야 해요.
자막은 청각 장애인뿐 아니라 소리를 끄고 보는 사람, 시끄러운 환경에서 보는 사람도 필요로 해요.

유튜브 통계에 따르면 자막이 있는 영상의 시청 시간이 더 길어요.
접근성 기능이 모든 사용자에게 도움이 되는 대표적인 사례예요.

접근성 도구와 테스트 방법

자동 검사 도구:

Lighthouse (Chrome DevTools) — 접근성 점수와 개선 사항 제시
axe DevTools (브라우저 확장) — 구체적인 접근성 오류 목록
WAVE (웹 접근성 평가 도구)

수동 테스트:

화면 낭독기로 실제 테스트 — macOS의 VoiceOver(Command + F5), Android의 TalkBack
키보드만으로 전체 화면 탐색 해보기
색맹 시뮬레이터로 화면 보기 (Figma의 Color Blindness 기능)

이 원칙을 어기면

비즈니스 위험: 공공기관·금융·의료 서비스는 접근성 미준수 시 법적 책임이 있어요.

기회 손실: 잠재 사용자를 배제해요.
한국 인구의 약 5%가 어떤 형태의 시각장애를 가지고 있어요.

더 나쁜 경험: 접근성 문제는 장애인만의 문제가 아니에요.
화면이 밝은 야외에서 저대비 텍스트, 좁은 터치 타겟, 자동 재생 동영상 — 모두 접근성 문제이면서 모든 사용자의 경험 문제예요.

참고 문헌

Sarah Horton & Whitney Quesenbery, 《A Web for Everyone》(2014) — 접근성을 실무에 적용하는 포괄적인 가이드예요.
WCAG 2.1, Web Content Accessibility Guidelines — https://www.w3.org/TR/WCAG21/ — 접근성 기준의 공식 출처예요.
Microsoft, Inclusive Design — https://inclusive.microsoft.design/ — 포용적 설계의 원칙과 사례를 제공해요.

접근성 (Accessibility)