개념
접근성(Accessibility)이란
시각·청각·운동·인지 장애가 있는 사용자도 서비스를 동등하게 쓸 수 있게 만드는 것이 접근성이다. 모듈 13(레슨 3)에서 "역할·라벨 기반 로케이터가 왜 안정적인가"를 배울 때 이미 접근성 개념을 살짝 다뤘다 — 자동화 테스트가 화면을 인식하는 방식과, 스크린 리더가 화면을 인식하는 방식이 근본적으로 같다. 접근성이 잘 지켜진 화면일수록 로케이터도 안정적이라는 원칙이, 이 레슨에서는 반대 방향으로 확인된다 — 접근성을 검증하는 것이 곧 좋은 로케이터 설계를 검증하는 것과 상당 부분 겹친다.
WCAG란
WCAG(Web Content Accessibility Guidelines)는 웹 접근성의 국제 표준이다. 모듈 8에서 배운 ISO/IEC/IEEE 29119처럼, WCAG도 준수 여부를 판단할 수 있는 구체적인 기준을 제공한다. 핵심 원칙은 네 가지 머리글자 POUR로 요약된다.
Perceivable(인지 가능) — 사용자가 콘텐츠를 인지할 수 있는가
Operable(조작 가능) — 사용자가 인터페이스를 조작할 수 있는가
Understandable(이해 가능) — 콘텐츠와 조작 방법을 이해할 수 있는가
Robust(견고함) — 다양한 보조 기술과 호환되는가대표적인 확인 항목들
대체 텍스트(Alt Text) — 이미지가 안 보이는 사용자(시각장애, 또는 이미지 로딩 실패)에게 이미지의 의미를 텍스트로 전달한다.
<!-- 나쁨: 정보가 없음 -->
<img src="product.jpg" alt="이미지">
<!-- 좋음: 의미가 전달됨 -->
<img src="product.jpg" alt="무선 이어폰, 화이트 색상">키보드만으로 조작 가능한가 — 마우스를 쓸 수 없는 사용자는 Tab, Enter, 화살표 키만으로 모든 기능에 접근해야 한다.
확인 방법: 마우스를 치우고, Tab 키만으로 로그인부터 결제까지
전체 흐름을 완주할 수 있는지 직접 시도해본다색상 대비(Color Contrast) — 텍스트와 배경의 명도 차이가 충분해야, 저시력 사용자도 글자를 읽을 수 있다. WCAG는 일반 텍스트 기준 4.5:1 이상의 대비를 권장한다.
폼 라벨 — 입력창마다 무엇을 입력해야 하는지 명확한 라벨이
연결되어 있어야 한다. 이건 모듈 13(레슨 2)에서 배운
getByLabel이 바로 이 라벨을 활용하는 것이다 — 자동화 테스트가
잘 작동한다는 것 자체가, 스크린 리더도 잘 작동할 가능성이
높다는 신호다.
스크린 리더로 직접 확인하기
접근성을 가장 정확히 확인하는 방법은, 실제로 스크린 리더(화면의 내용을 음성으로 읽어주는 보조 기술)를 켜고 서비스를 써보는 것이다. 화면을 보지 않고 소리만으로 회원가입을 완주할 수 있는지 시도해보면, 코드만 봐서는 안 보이던 문제(읽는 순서가 뒤죽박죽, 버튼의 목적이 음성으로 전달 안 됨)가 바로 드러난다.
자동화 도구와 수동 확인은 함께 쓰인다
Lighthouse 같은 도구(레슨 4에서 언급)는 대체 텍스트 누락, 색상 대비 부족 같은 기계적으로 판단 가능한 항목을 자동으로 찾아준다. 하지만 "이 버튼의 목적이 스크린 리더 사용자에게 명확히 전달되는가" 같은 맥락적 판단은 여전히 사람이 직접 확인해야 한다 — 이건 모듈 10(레슨 5)에서 배운 "커버리지 도구는 실행 여부만 볼 뿐 올바름은 판단 못 한다"는 원칙과 같은 구조다.
실무에서 왜 필요한가
공공기관·금융권은 접근성 준수가 법적 의무인 경우가 많다(모듈 8에서 배운 규제 산업 QA와 연결된다). 법적 의무가 없는 서비스라도, 접근성을 갖추는 것은 더 많은 사용자가 서비스를 쓸 수 있게 하는 실질적인 가치가 있다. QA가 Tab 키 하나로 핵심 흐름을 완주해보는 습관만 가져도, 개발 후반에야 발견되는 큰 접근성 결함을 미리 잡아낼 수 있다.