웹 접근성 기본기, 인증마크를 준비하며 배운 것들

웹 접근성을 처음 진지하게 마주한 건 웹퍼블리셔로 일하며 웹 접근성 인증마크를 준비하던 때다. 그때 익힌 기본기를 정리해둔다. 화려한 기술은 아니지만, 대부분의 접근성 문제는 여기서 갈린다.

접근성은 시각장애인 전용이 아니다

오해부터 짚고 가자. 웹 접근성이라고 하면 “시각장애인용 기능”이라고만 생각하기 쉬운데, 실제 범위는 훨씬 넓다.

마우스 없이 키보드만 쓰는 사용자
화면을 크게 확대해서 보는 저시력 사용자
복잡한 화면에서 쉽게 길을 잃는 인지적 부담이 큰 사용자
팔을 다쳐 한 손만 쓰는, 일시적인 상황의 사용자

접근성은 특별한 소수를 위한 별도 기능이 아니라, “언젠가의 나”까지 포함한 모두가 쓸 수 있게 만드는 일이다. 그리고 대부분은 처음부터 고려하면 추가 비용이 거의 없다. 나중에 붙이려면 전체를 뜯어야 하는 게 문제일 뿐.

시작은 시맨틱 마크업

제일 먼저 배운 건 태그에 의미를 담는 것이었다. 화면에 어떻게 보이느냐가 아니라, 그게 무슨 역할인지를 태그로 말하는 것.

대표적인 게 b와 strong, i와 em이다.

<!-- 화면에는 똑같이 굵게, 기울게 보인다 -->
<b>중요</b>       <strong>중요</strong>
<i>강조</i>       <em>강조</em>

눈으로 보면 넷 다 똑같다. 그런데 스크린 리더로 들어보면 b·i는 평범하게 읽고 지나가고, strong·em은 강조해서 읽어준다. b·i는 모양만 바꾸는 태그고, strong·em은 “여기가 중요하다”는 의미를 담은 태그이기 때문이다.

같은 원리가 문서 구조 전체에 적용된다.

제목은 h1~h6를 순서대로. 스크린 리더 사용자는 제목만 목차처럼 훑어 원하는 곳으로 바로 간다. 글씨를 크게 하려고 div에 스타일만 주면 이 목차가 사라진다.
목록은 ul·ol, 표는 table. 리더기가 “목록, 항목 5개”, “표, 3행 4열”처럼 구조를 먼저 알려준다. 표에는 caption과 th scope로 각 칸이 무슨 데이터인지 연결한다.

div로 전부 감싸면 화면은 똑같이 나와도, 눈으로 안 보는 사람에게는 구조가 통째로 사라진다.

이미지에는 대체 텍스트

이미지는 alt로 설명을 단다.

<!-- 의미가 있는 이미지 — 내용을 설명 -->
<img src="chart.png" alt="2022년 분기별 매출, 3분기에 가장 높음" />

<!-- 장식용 이미지 — 빈 alt로 건너뛰게 -->
<img src="divider.png" alt="" />

alt를 아예 빼면 리더기가 파일명(chart.png)을 그대로 읽어버린다. 장식용이라면 빈 alt로 “읽지 말고 지나가라”고 알려주는 게 맞다.

폼은 라벨과 묶는다

입력 필드는 라벨과 연결해야 한다.

<label for="email">이메일</label>
<input id="email" type="email" />

이렇게 묶으면 리더기가 “이메일, 입력란”으로 읽어주고, 라벨을 클릭해도 입력란으로 포커스가 간다. placeholder는 라벨을 대신하지 못한다. 입력을 시작하면 사라지니까.

키보드로 끝까지 갈 수 있어야

마우스 없이 Tab 키만으로 모든 기능을 쓸 수 있어야 한다. 여기서 자주 깨진다.

포커스 표시를 지우지 말 것. outline: none으로 없애버리면 키보드 사용자는 지금 어디 있는지 알 수 없다. :focus-visible을 쓰면 마우스일 때는 안 보이고 키보드로 이동할 때만 표시된다.
탭 순서는 시각적 순서와 같게. 눈으로 보는 순서와 Tab 순서가 어긋나면 혼란스럽다.
본문 바로가기(skip link). 페이지마다 반복되는 상단 메뉴를 매번 Tab으로 지나치지 않도록, 맨 앞에 “본문 바로가기” 링크를 둔다.

색상 대비

디자인은 옅은 회색 텍스트를 좋아한다. 예쁘지만 저시력 사용자에겐 거의 안 보인다. 본문 텍스트는 배경과 명도 대비 4.5:1 이상을 지키는 게 기준이다. 연회색의 유혹을 참아야 하는 지점.

ARIA는 아껴 쓴다

접근성을 공부하면 role, aria-* 같은 ARIA 속성을 알게 되는데, 여기엔 유명한 원칙이 하나 있다. “나쁜 ARIA는 없는 것만 못하다.”

네이티브 요소를 쓰면 접근성이 공짜로 따라온다. div에 role="button"을 붙이고 키보드 핸들러를 직접 다는 것보다, 그냥 button을 쓰는 게 낫다. button은 포커스, 엔터/스페이스 키 동작, 리더기 안내가 전부 기본으로 들어있다. ARIA는 네이티브 요소로 표현할 수 없는 걸 보완할 때만 꺼내는 도구다.

결국은 직접 들어봐야

자동화 도구(axe, Lighthouse)가 잡아주는 건 일부다. 나머지는 눈을 감고 스크린 리더로 들어보고, 마우스를 치우고 키보드로만 다녀봐야 안다. 한 번만 해보면 어디가 막히는지 몸으로 느껴진다. 인증마크를 준비하며 가장 크게 남은 것도 결국 이 습관이었다.