접근성 평가 방법과 도구

접근성 평가란

접근성 평가는 페이지가 장애인에게 실제로 쓸 수 있는지를 WCAG 같은 기준에 비춰 확인하는 일이다. 자동 검사 도구는 사이트가 접근 가능한지, 심지어 기준을 준수하는지도 판정하지 못한다. 접근성은 사람의 경험이기 때문이다. 도구는 명백한 오류를 찾고, 사람이 판단할 곳을 짚어 주는 데까지만 한다.

그래서 평가는 자동 검사 → 수동 점검 → 보조 기술 테스트 순서로 한다. 도구가 놓친 것을 사람이 채우는 구조다. 기준은 따로 요구되는 것이 없으면 최신 WCAG(2.2) AA다(기준 고르기는 WCAG 지침).

감사와 테스트 계획

• 감사는 한 번으로 끝나지 않는다. 처음에 기준선을 잡고, 개발 주기 내내 같은 기준으로 반복해 적합성이 어떻게 바뀌는지 본다. 자동 검사는 CI에 넣어 매 변경마다, 수동·보조 기술 테스트는 큰 기능과 출시 전에 돌린다.
• 설계 단계에서 막는 편이 싸다. 디자인 검토와 접근성 주석은 디자인 단계의 접근성에 있다.
• 적합성은 출발점이다. 장애인과 하는 사용성 테스트, 장애가 있는 사람의 채용, 전문가 자문이 함께 가야 한다(웹 접근성).

자동 검사는 빠르고, 반복할 수 있고, 전문 지식이 적어도 돌린다. 대신 많은 오류를 놓치고, 실제 위반이 아닌 것을 오류로 띄우는 오탐(false positive)도 낸다.

자동 검사로 걸리는 문제가 얼마나 흔한지는 웹 접근성의 WebAIM Million 수치를 본다. 상위 100만 개 홈페이지의 95% 이상에서 자동 검사만으로도 오류가 나온다.

도구 고르기

• 무료 도구는 쓰는 사람이 접근성 기준을 안다고 가정한다. 도구의 판정보다 기준을 아는 쪽이 믿을 만하다.
• 도구마다 보는 곳이 달라서 두 개 이상을 섞어 쓰는 편이 낫다.
• Section 508 기준만 보고하는 도구는 낡았다. 508은 2018년부터 WCAG 2.0 AA를 기준으로 삼는다.
• 최초의 온라인 자동 검사 도구 중 하나는 1996년 CAST가 만든 Bobby다. 지금 W3C WAI의 평가 도구 목록에는 브라우저 확장, 린터, 데스크톱·모바일 앱, 대시보드, 오픈소스 API까지 100개가 넘는 도구가 있다.

자주 쓰는 도구

자동 검사를 Playwright·Testing Library 테스트에 넣는 방법은 접근성 기반 테스트에 있다.

개발 주기 단계별 도구

문제는 늦게 찾을수록 고치기 비싸다. 디자인 파일, 브라우저, 편집기, 빌드 단계마다 도구를 하나씩 두면 각 단계에서 기계가 잡을 수 있는 것은 그 자리에서 걸러진다.

디자인 단계 도구의 주석 기능은 대체 텍스트·포커스 순서처럼 개발자가 추측하던 결정을 디자인 파일에 못 박는다(디자인 단계의 접근성). 어느 단계 도구든 기계가 확인할 수 있는 것만 잡는다. 읽기 순서·이름의 적절성·위젯 동작은 아래 수동 절차로 본다.

평가 절차

0. 준비      광고 차단·비밀번호 관리자·자동 채움 등 화면을 바꾸는 확장을 끈다.
             CodePen 같은 iframe 안의 데모는 iframe 없이 연다(디버그 보기)
1. 자동 검사  WAVE 확장으로 오류(빨강)부터 고치고, 경고·구조 아이콘을 사람이 확인
2. 이름 확인  DevTools Accessibility 패널로 버튼·링크·입력의 접근 가능한 이름 확인
3. 키보드    마우스를 치우고 Tab·Shift+Tab·Enter·Space·방향키·Esc로 과업 끝내기
4. 확대      200% 확대, 1280px 창에서 400% 리플로, 텍스트 간격 북마클릿
5. 대비·색   텍스트 4.5:1, 큰 텍스트·UI 경계·포커스 표시 3:1, 색만으로 정보 전달 금지
6. 스크린 리더 제목·랜드마크·폼·동적 변화가 의도대로 읽히는지 듣기

1. WAVE로 자동 검사

WAVE는 결과를 오류(error), 대비 오류(contrast), 경고(alert), 기능(feature), 구조(structure), ARIA(aria) 여섯 범주로 나눈다. WAVE 도움말이 색을 밝히는 것은 앞의 셋뿐이다. 빨간 아이콘은 고쳐야 할 오류, 노란 아이콘은 검토할 경고, 초록 아이콘은 확인할 접근성 기능이다.

• Details 패널의 아이콘을 누르면 페이지에서 해당 위치가 강조되고, Code 버튼으로 해당 마크업을 본다.
• Styles를 끄면 페이지가 선형으로 펼쳐져 스크린 리더가 읽는 순서와 숨긴 요소가 드러난다.
• 오류 0개는 접근 가능하다는 뜻이 아니다. WAVE는 대체 텍스트가 맞는지 판단하지 못하고, 보여만 준다.
• 온라인 버전은 JavaScript 지원이 제한된다. 로그인 뒤 페이지, 로컬 페이지, 동적 페이지는 브라우저 확장으로 검사한다.
• iframe은 표시만 하고 내용을 검사하지 않는다. iframe 주소를 따로 열어 검사한다.

2. 접근 가능한 이름 확인

ARIA 라벨은 <label>, alt, 링크 텍스트를 덮어쓴다. 그래서 마크업만 보고는 최종 이름을 알 수 없다.

1. Chrome DevTools Elements 패널에서 요소를 고른다.
2. Accessibility 탭의 Computed Properties에서 Name과 Description을 본다. 이름이 어느 출처(aria-labelledby → aria-label → <label> → title·placeholder)에서 왔는지 계산 순서가 함께 나온다.
3. 보이는 텍스트가 접근 가능한 이름에 들어 있는지 확인한다(WCAG 2.5.3 Label in Name).

이름 계산 규칙 자체는 ARIA 기초, DevTools 사용법은 DevTools로 DOM과 CSS 다루기를 본다.

3. 키보드 점검

체크할 것:

• 모든 포커스 대상에 보이는 포커스 표시가 있고(2.4.7), 대비가 3:1 이상이며(1.4.11), 고정 헤더 등에 가려지지 않는다(2.4.11).
• 포커스 순서가 시각 순서와 맞는다. tabindex에 양수를 쓰지 않는다.
• 마우스 호버로만 열리는 메뉴가 없다. 호버·포커스로 뜬 툴팁은 그 위에 머무는 동안 유지되고 Esc로 닫힌다.
• 드래그·멀티 포인트 제스처에는 버튼 같은 단일 포인터 대안이 있다(2.5.1, 2.5.7).
• 포인터 대상은 최소 24×24 CSS px이다(2.5.8, 예외 있음).
• 건너뛰기 링크가 포커스 때 나타나고, 실행 뒤 Tab을 누르면 본문으로 간다.
• 모바일 메뉴 등 반응형 화면마다 따로 확인한다.
• 마우스를 치우기 어렵다면 마우스 포인터를 숨기는 작은 스크립트(no-mouse-days 같은)를 페이지에 넣고 점검한다.
• 대화상자는 열릴 때 포커스가 들어가고, 모달이면 포커스를 가두고, 닫으면 원래 자리로 돌아온다.

macOS는 시스템 설정의 키보드 탐색을 켜고, Safari는 설정 → 고급에서 「Tab 키로 웹 페이지의 각 항목 강조」를 켜야 Tab이 모든 요소로 간다. 포커스 표시가 없는 곳을 찾을 때는 Chrome의 chrome://settings/accessibility에서 「포커스된 객체를 잠시 강조 표시」를 켠다. 키보드 구현 원칙은 키보드 접근성에 있다.

4. 확대와 텍스트 간격

리플로와 글꼴 설계는 접근성을 위한 CSS와 타이포그래피에 있다.

5. 대비와 색

• 텍스트 4.5:1, 큰 텍스트(24px 이상 또는 18.67px 굵게) 3:1.
• 아이콘 같은 필수 그래픽, 입력란 테두리 같은 UI 경계, 포커스 표시는 3:1.
• 호버·포커스 상태 대비는 DevTools에서 상태를 강제로 켜고 잰다.
• 밑줄 없이 색으로만 구분한 링크는 본문 글자와 3:1 이상 차이 나고, 호버·포커스 때 색 말고도 바뀌는 것이 있어야 한다.

색과 대비의 원칙은 색과 움직임의 접근성을 본다.

6. 시각·콘텐츠 점검

화면 확대·브라우저 확대를 켠 채 눈으로 보는 점검과, 글과 맥락을 읽는 점검이다. IBM Equal Access 같은 공개 체크리스트에서 출발해 제품에 맞게 다듬는다.

「여기를 클릭」 같은 문구는 린터가 표시할 수 있지만 맥락에 맞게 다시 쓰는 것은 사람의 일이다.

7. 항목별 수동 체크포인트

자동 검사가 표시만 하고 판단은 사람에게 넘기는 것들이다. 만드는 방법은 각 링크 노트가 맡는다.

자주 나오는 문제와 고치기

일부러 접근성을 망가뜨린 데모 페이지를 단계별로 고쳐 보면, 단계마다 잡히는 문제가 다르다.

자동 검사가 100점이 된 뒤에도 수동 단계에서, 그 뒤 스크린 리더 단계에서 문제가 계속 나온다. 스크린 리더로만 드러나는 문제는 스크린 리더로 테스트하기에 있다. 세 단계를 모두 통과해도 완전한 접근성이 보장되지는 않는다.

오버레이는 평가를 대신하지 못한다

오버레이(overlay)는 사이트에 스크립트 한 줄을 넣어 접근성을 "자동으로" 고쳐 준다고 파는 서드파티 위젯이다. 글자 크기·대비 조절 버튼을 띄우거나, 페이지를 스캔해 alt·라벨·포커스를 자동 수리한다고 주장한다.

Overlay Fact Sheet에는 1,000명 넘는 접근성 실무자·장애인 사용자가 "오버레이를 권하지 않고, 문제를 원인에서 고친다"고 서명했다. WebAIM 실무자 설문에서도 응답자 67%(장애가 있는 응답자는 72%)가 오버레이가 효과가 없거나 거의 없다고 답했다. 2025년에는 미국 연방거래위원회(FTC)가 오버레이 업체 accessiBe의 WCAG 준수 보장 광고를 문제 삼아 100만 달러를 내라는 최종 명령을 내렸다(FTC 보도자료).

정리

• 감사는 기준선을 잡은 뒤 개발 주기 내내 반복하고, 결과는 ACR(VPAT 양식)로 남긴다.
• 자동 검사는 출발점이다. 오류 0개는 접근 가능하다는 증거가 아니다.
• 순서는 WAVE 같은 자동 검사 → DevTools로 이름 확인 → 키보드 → 확대·텍스트 간격 → 대비 → 스크린 리더다.
• 경고 아이콘과 대체 텍스트, 읽는 순서, 포커스 흐름은 사람이 판단한다.
• 도구는 두 개 이상 섞고, 도구보다 기준을 먼저 익힌다.
• 오버레이는 평가도 수리도 대신하지 못한다. 문제는 소스에서 고친다.

관련 노트: 웹 접근성, WCAG 지침, 디자인 단계의 접근성, 스크린 리더로 테스트하기, 접근성 기반 테스트, 키보드 접근성, DevTools로 DOM과 CSS 다루기