모든 개발자가 알아야 할 WCAG 접근성 기초
모든 개발자가 알아야 할 WCAG 접근성 기초
웹 접근성이란 무엇인가
웹 접근성(Web Accessibility)은 장애가 있는 사람을 포함하여 모든 사용자가 웹사이트를 동등하게 이용할 수 있도록 만드는 것을 의미합니다. 시각, 청각, 운동 능력, 인지 능력에 제한이 있는 사용자뿐만 아니라, 일시적으로 한 손만 쓸 수 있는 상황이나 밝은 햇빛 아래에서 화면을 보는 상황까지 포함합니다. 접근성은 특정 사용자만을 위한 것이 아니라, 결국 모든 사용자의 경험을 향상시킵니다.
WCAG(Web Content Accessibility Guidelines)는 W3C에서 제정한 웹 접근성 국제 표준입니다. 현재 최신 버전은 WCAG 2.2이며, 레벨 A(최소), AA(권장), AAA(최고) 세 단계의 적합성 수준이 있습니다. 대부분의 법적 요구사항과 실무에서는 레벨 AA를 기준으로 합니다.
POUR: 접근성의 4대 원칙
WCAG의 모든 가이드라인은 네 가지 원칙을 기반으로 합니다. 머리글자를 따서 POUR이라고 부릅니다.
인식 가능(Perceivable)
정보와 UI 구성 요소를 사용자가 인식할 수 있어야 합니다. 이미지에 대체 텍스트(alt text)를 제공하고, 동영상에 자막을 넣고, 콘텐츠를 시각에만 의존하지 않도록 설계해야 합니다.
가장 기본적인 예로, 모든 <img> 태그에는 의미 있는 alt 속성이 있어야 합니다. 장식용 이미지라면 alt=""로 빈 값을 넣어 스크린 리더가 건너뛸 수 있도록 합니다.
<!-- 좋은 예 -->
<img src="chart.png" alt="2025년 월별 매출 추이 그래프" />
<!-- 장식용 이미지 -->
<img src="divider.png" alt="" role="presentation" />
운용 가능(Operable)
모든 UI 구성 요소와 내비게이션은 조작 가능해야 합니다. 키보드만으로 모든 기능을 사용할 수 있어야 하며, 사용자에게 콘텐츠를 읽고 사용할 충분한 시간을 제공해야 합니다.
이해 가능(Understandable)
정보와 UI 조작 방법을 이해할 수 있어야 합니다. 텍스트는 읽기 쉬워야 하고, 웹 페이지의 동작은 예측 가능해야 하며, 사용자가 실수를 방지하고 교정할 수 있도록 도와야 합니다.
견고함(Robust)
다양한 사용자 에이전트(브라우저, 보조 기술 등)에서 안정적으로 해석될 수 있어야 합니다. 올바른 HTML 마크업과 표준 준수가 핵심입니다.
가장 자주 발생하는 접근성 위반 사항
실제 웹사이트를 검사하면 반복적으로 발견되는 문제들이 있습니다. 접근성 검사 도구를 개발하면서 수천 개의 웹사이트를 분석한 경험을 바탕으로 가장 빈번한 위반 사항을 정리했습니다.
색상 대비 부족: 텍스트와 배경 간의 명도 대비가 충분하지 않은 경우입니다. WCAG AA 기준으로 일반 텍스트는 4.5:1, 큰 텍스트(18pt 이상 또는 14pt 굵게)는 3:1 이상의 대비 비율이 필요합니다. 연한 회색 텍스트에 흰 배경 조합은 가장 흔한 위반 사례입니다.
이미지 대체 텍스트 누락: <img> 태그에 alt 속성이 없거나, 의미 없는 값(예: "image1.jpg")이 들어간 경우입니다. 스크린 리더 사용자는 이미지의 내용을 전혀 파악할 수 없습니다.
폼 레이블 누락: 입력 필드에 <label> 요소가 연결되지 않으면 스크린 리더 사용자는 해당 입력란이 무엇을 위한 것인지 알 수 없습니다. placeholder는 레이블을 대체할 수 없습니다.
<!-- 나쁜 예 -->
<input type="email" placeholder="이메일 입력" />
<!-- 좋은 예 -->
<label for="email">이메일</label>
<input type="email" id="email" placeholder="example@email.com" />
키보드 접근 불가: 마우스 클릭으로만 동작하는 요소가 있을 때 키보드 사용자는 해당 기능을 이용할 수 없습니다. div나 span에 클릭 이벤트를 넣는 대신 button이나 a 태그를 사용하세요.
포커스 표시 제거: outline: none을 전역으로 적용하면 키보드 사용자가 현재 어느 요소에 포커스되어 있는지 알 수 없습니다. 기본 포커스 스타일이 디자인과 맞지 않는다면 제거하지 말고 커스텀 포커스 스타일을 적용하세요.
키보드 내비게이션
키보드 접근성은 모든 접근성의 기반입니다. Tab 키로 포커스 이동, Enter/Space로 활성화, Escape로 닫기, 화살표 키로 옵션 탐색이 가능해야 합니다.
키보드 내비게이션에서 중요한 점은 논리적인 탭 순서입니다. 시각적 배치와 DOM 순서가 일치해야 합니다. CSS로 시각적 위치를 변경하더라도 DOM 순서가 논리적이지 않으면 키보드 사용자에게 혼란을 줍니다.
모달 다이얼로그가 열렸을 때는 포커스 트래핑(Focus Trapping) 을 구현하여 모달 내부에서만 포커스가 순환하도록 해야 합니다. 모달이 닫히면 모달을 연 요소로 포커스를 되돌려야 합니다.
스크린 리더와 ARIA
ARIA(Accessible Rich Internet Applications)는 HTML만으로 전달하기 어려운 의미와 상태를 보조 기술에 전달하기 위한 속성들입니다. 하지만 ARIA를 사용할 때 가장 중요한 규칙이 있습니다. 네이티브 HTML 요소로 해결할 수 있다면 ARIA를 사용하지 마세요.
<!-- ARIA 불필요 - 네이티브 버튼이 더 낫다 -->
<div role="button" tabindex="0" aria-pressed="false">클릭</div>
<!-- 이렇게 하세요 -->
<button>클릭</button>
ARIA가 꼭 필요한 경우도 있습니다. 탭 패널, 아코디언, 트리 뷰 같은 커스텀 위젯은 role, aria-expanded, aria-selected, aria-controls 같은 속성으로 상태를 전달해야 합니다. 또한 동적으로 변하는 콘텐츠는 aria-live 영역을 사용하여 스크린 리더에 변경 사항을 알려야 합니다.
접근성 테스트 도구
자동화 도구만으로는 접근성 문제의 30~40%만 발견할 수 있습니다. 나머지는 수동 테스트가 필요합니다. 그래도 자동화 도구는 기본적인 위반 사항을 빠르게 잡아주므로 반드시 사용해야 합니다.
추천하는 도구들은 다음과 같습니다.
- axe DevTools: 가장 널리 사용되는 접근성 검사 브라우저 확장 프로그램
- Lighthouse: Chrome 내장 도구로 접근성 점수를 제공
- WAVE: 시각적으로 문제를 표시해주는 온라인 검사 도구
- 키보드 테스트: Tab 키만으로 사이트를 처음부터 끝까지 이동해보기
- 스크린 리더 테스트: VoiceOver(Mac), NVDA(Windows) 등으로 실제 사용해보기
접근성은 선택이 아닌 필수입니다. 처음부터 접근성을 고려하여 개발하면 나중에 수정하는 것보다 훨씬 적은 비용이 들며, 결과적으로 더 많은 사용자에게 도달할 수 있습니다. 작은 것부터 하나씩 시작해보세요.