Accessibility

웹 접근성 주제는 누구나 같은 정보와 기능에 닿을 수 있게 만드는 방법을 다룬다. 장애 유형별로 웹을 어떻게 쓰는지에서 출발해, WCAG라는 기준선, 마크업·스크립트·스타일 단계의 기법, 그리고 결과를 확인하는 평가 방법 순으로 읽으면 이어진다. 시맨틱 태그 자체는 시맨틱 HTML과 문서 구조에, role과 접근 가능한 이름으로 테스트를 짜는 법은 접근성 기반 UI 테스트 자동화에 있다.

노트

• 장애 유형별 웹 사용: 시각·청각·운동·인지·발작과 전정 장애 사용자가 웹을 쓰는 방식, 쓰는 보조 기술, 각각이 부딪히는 장벽
• WCAG와 POUR 원칙: 인지·운용·이해·견고 네 원칙, 성공 기준과 A·AA·AAA 수준, WCAG 2.2에서 바뀐 것, 형제 지침과 각국 법, 체크리스트로 쓰는 법
• 디자인 단계의 접근성: 포용적 디자인 원칙, 장애를 담은 페르소나, 접근성 휴리스틱 리뷰, 핸드오프 전 접근성 주석, 접근 가능한 컴포넌트·디자인 시스템 고르기
• 접근 가능한 페이지 구조: 페이지 제목, 문서 언어, 제목 계층, 랜드마크 영역, 목록, 건너뛰기 링크, iframe, 데이터 표
• 대체 텍스트, 링크, 쉬운 글: 이미지 종류별 alt 쓰는 법, 링크 텍스트와 새 창, 명확하고 쉬운 글쓰기
• 자막, 대본, 음성 해설: 동영상·오디오에 필요한 대체 수단, 자막 품질 기준, 실시간 자막
• 접근 가능한 폼과 오류 처리: label과 접근 가능한 이름, 그룹과 설명, 필수 항목, 인라인 검증과 오류 복구
• ARIA와 접근 가능한 이름: ARIA 다섯 규칙, role·state·property, 이름과 설명이 계산되는 순서, 라이브 영역
• 키보드 접근성과 포커스 관리: 포커스 순서와 표시, tabindex, 키보드 트랩, 스크립트 이벤트와 동적 콘텐츠
• 접근 가능한 위젯: 펼침·탭·캐러셀: 디스클로저와 아코디언, 탭 인터페이스, 자동 재생 캐러셀과 애니메이션 제어
• 복합 위젯의 ARIA 패턴: 콤보박스·날짜 선택기·메뉴·상태 알림: 자동완성 콤보박스, 날짜 선택기와 날짜 직접 입력, 사이트 메뉴와 menubar, 수량 버튼, 정렬 표, 툴팁, 로딩·토스트·글자 수 같은 상태 알림
• 접근성을 위한 CSS와 타이포그래피: 스크린 리더 전용 텍스트, 리플로와 확대, 글꼴과 텍스트 간격, 스크린 리더 호환을 위한 설계
• 색과 움직임의 접근성: 색각 결핍, 색만으로 정보 전달 금지, 대비 기준, prefers-color-scheme·prefers-reduced-motion, 5초 애니메이션 규칙
• 접근성 평가 방법과 도구: 자동 검사의 한계, WAVE·DevTools로 하는 점검 순서, 수동 평가 체크포인트, 오버레이 제품을 쓰지 않는 이유
• 스크린 리더로 테스트하기: NVDA·JAWS·VoiceOver·TalkBack·Narrator의 기본 조작, 브라우저 조합, 테스트할 때 볼 것, 사용자 설문으로 본 실제 사용 방식

웹 접근성이란

웹 접근성은 장애가 있는 사람도 웹을 인지하고, 이해하고, 탐색하고, 상호작용하고, 기여할 수 있게, 그것도 다른 사람과 동등한 수준으로 만드는 일이다. accessibility의 첫 글자와 끝 글자 사이 11글자를 줄여 a11y라고 쓴다. 대상은 시각 장애만이 아니다. 청각, 인지, 신경, 신체, 말하기 장애가 모두 포함된다.

세계보건기구는 장애를 개인의 속성이 아니라 능력과 환경의 불일치로 정의한다(사회적 정의). 이 관점에서는 장애와 보조 기술의 경계가 맥락에 따라 달라지고, 특정 능력을 위한 설계가 모두에게 쓸모 있어지는 일이 많다(휠체어용 경사로를 유모차도 쓴다).

접근성은 소수를 위한 추가 작업이 아니라 더 넓은 사용자를 위한 설계다. 표준 지식, 접근 가능한 디자인과 코드, 여러 테스트 기법이 필요해 리더십의 지지·시간·예산이 더 들므로, 기획·디자인·개발·운영의 전 주기에 장애가 있는 사람과 접근성 원칙을 넣는다.

현실은 멀다. WebAIM이 해마다 상위 100만 개 사이트의 홈페이지를 자동 검사하는 WebAIM Million의 2026년 결과에서 95.9%가 WCAG 2 실패를 하나 이상 갖고 있었고, 페이지당 평균 오류는 56.1개였다. 흔한 순서는 낮은 텍스트 대비(83.9%), 이미지 대체 텍스트 누락(53.1%), 폼 라벨 누락(51%), 빈 링크(46.3%), 빈 버튼(30.6%)이다. 대부분 마크업만 고쳐도 사라지는 문제다.

사람·비즈니스·법

소송을 피하는 것이 유일한 이유가 되어서는 안 되지만, 무시할 수 없는 이유다.

보조 기술은 웹을 어떻게 읽나

스크린 리더, 점자 디스플레이, 시선 추적 같은 대체 입력 장치가 웹을 쓰는 보조 기술이다. 그중 스크린 리더가 기술적으로 가장 까다롭다. 화면의 시각 단서 없이 "이건 버튼인가", "어떤 순서로 읽나", "제목만 훑을 수 있나"에 답해야 하기 때문이다.

지금 브라우저는 DOM을 파싱해 화면을 그리는 동시에 접근성 트리(accessibility tree)를 만든다. 트리의 노드는 role(버튼), name(버튼 텍스트), state(포커스됨) 같은 속성을 갖고, 스크린 리더는 이 값을 읽는다.

flowchart LR
  html["HTML"] -->|"파싱"| dom["DOM"]
  dom --> render["렌더링"]
  render --> screen["화면"]
  dom --> tree["접근성 트리"]
  tree --> api["접근성 API"]
  api --> at["스크린 리더 · 점자 장치"]

• h1~h6는 heading 노드가 된다. 스크린 리더 사용자가 가장 흔히 쓰는 정보 탐색 방법이 제목 훑기다.
• 아이콘만 있는 버튼에는 aria-label, 이미지에는 alt로 name을 준다. 다만 ARIA는 의미만 더하고 동작은 하나도 더하지 않으므로, 같은 의미의 네이티브 요소가 있으면 그것을 먼저 쓴다.
• Chrome DevTools의 접근성 패널에서 접근성 트리 전체를 볼 수 있다.
• 머신러닝이 이미지 대체 텍스트를 자동 생성하는 등 트리에 들어갈 데이터를 보강하기 시작했지만, 개발자가 넣는 의미가 기본이다.

이 방식의 약점은 개발자가 의도에 맞는 태그와 속성을 써야만 동작한다는 점이다. 그래서 웹 접근성의 가장 큰 장벽은 기술 한계가 아니라 인식과 우선순위의 부족이다.

표준을 지켜도 쓰기 어려울 수 있다

WCAG를 통과해도 너무 가는 글자 굵기, 이해하기 어려운 날짜 선택 UI, 확대 시야 밖에 뜨는 다음 단계, 너무 긴 aria-label처럼 기준에 걸리지 않는 문제로 과제를 끝내지 못할 수 있다. 표준은 필요조건이지 충분조건이 아니다. 체크리스트만 보면 사람 사이의 상호작용을 놓친다. 그래서 접근성은 사용성과 함께 본다. 제이컵 닐슨의 사용성 5요소가 기준이 된다.

장애인 참가자와 사용성 테스트하기

테스트의 진짜 효과는 보고서보다 관찰한 팀원의 관점 변화다. 장애인 인권 운동의 구호 "우리 없이 우리에 대해 결정하지 말라(Nothing About Us Without Us)"는 사용자 중심 디자인과 같은 뿌리다. 리서치 방법 전반은 사용자 리서치에 있다.

바로 할 수 있는 다섯 가지

1. 마우스를 치우고 키보드로만 써 본다. 포커스 표시가 항상 보이고, 포커스 순서가 논리적이어야 한다.
2. 낮은 대비를 피한다. 눈으로 먼저 거슬리는 곳을 찾고 대비 검사 도구로 확인한다. WCAG에 글자 크기 최솟값은 없지만, 브라우저에서 200%로 키워도 내용이 잘리지 않아야 하므로(성공 기준 1.4.4) 글자 크기는 px보다 rem으로 준다.
3. 자동 검사를 돌리고 스크린 리더로 들어 본다. axe DevTools, Lighthouse, WAVE, Accessibility Insights가 라벨 누락 같은 문제를 빨리 잡지만 일부 문제만 찾는다. 키보드로 끝까지 할 수 있는지, 읽는 순서가 자연스러운지는 사람이 확인한다. Windows는 무료 NVDA, macOS·iOS는 내장 VoiceOver로 들어 보고, 접근성 트리·계산된 이름·소스 순서는 Chrome DevTools로 확인한다(DevTools로 DOM과 CSS 다루기).
4. 접근성 페이지를 둔다. 취한 조치와 문제를 알릴 연락처를 밝힌다.
5. 쉬운 말로 쓴다. 전문용어를 줄이고, 제목·문단·목록으로 나누고, 한 문단에 요점 하나를 둔다.

"월 얼마에 100% 준수"를 약속하는 오버레이 솔루션은 지름길이 아니다(접근성 평가 방법과 도구). 접근성에는 교육과 우선순위 외에 지름길이 없다.

조직 차원의 접근성

접근성은 한 팀의 체크리스트가 아니라 조직의 우선순위다.

더 읽을 자료

정리

• 장애는 능력과 환경의 불일치다. 접근성은 결국 더 많은 사람을 위한 설계다.
• 브라우저는 시맨틱 HTML로 접근성 트리를 만든다. 의미에 맞는 마크업이 보조 기술 지원의 기본이고, ARIA는 네이티브 요소로 안 될 때만 쓴다.
• 접근성은 사람·비즈니스·법 모두의 문제이고, 기획부터 운영까지 전 주기의 일이다.
• WCAG는 최소선이다. 지켜도 쓰기 어려울 수 있으니 장애인과 직접 테스트한다.
• 자동 검사와 오버레이는 보조 수단이다. 키보드 테스트와 사람의 판단이 필요하다.
• 가장 큰 장벽은 기술이 아니라 우선순위다.

관련 주제: 시맨틱 HTML과 폼 사용성(더 나은 폼을 만드는 팁)은 Web, 접근성 기반 테스트는 Testing 주제에 있다.