웹 접근성(a11y), 키보드와 스크린 리더로도 쓸 수 있는 화면

Lighthouse로 페이지를 검사하면 성능 옆에 접근성 점수도 나온다.
그 아래에는 버튼에 접근 가능한 이름이 없다거나, 배경과 글자 색의 대비가 부족하다는 지적이 붙곤 한다.

Lighthouse가 접근성 점수를 매길 때 보는 항목에는 이미지의 대체 텍스트, 제목의 순서 같은 것도 있다.
화면에서 멀쩡히 보이는 버튼에 이름이 없다는 것은 무슨 뜻일까.

답하려면 마우스를 쓰지 않거나 화면을 보지 않는 사람이 웹을 어떻게 쓰는지부터 알아야 한다.

마우스와 화면 없이 웹을 쓰는 사람들

접근성은 장애가 있는 사람을 포함해 되도록 많은 사람이 웹사이트를 쓸 수 있게 하는 일이다.
가장 흔히 쓰는 방법은 스크린 리더, 화면 확대기, 음성 인식 도구, 마우스를 대신하는 입력 장치 같은 보조 기술이 제대로 동작하게 하는 일이다.

영어 accessibility의 첫 글자와 끝 글자 사이에 열한 글자가 있어서, 접근성을 a11y라고 줄여 쓰기도 한다.

보조 기술 가운데 스크린 리더는 화면의 내용을 음성이나 점자로 바꿔 전하는 프로그램이다.
화면에 그려진 모양 대신, 브라우저가 HTML에서 뽑아 준 요소의 역할과 이름, 상태를 읽는다.
브라우저가 이 정보를 요소마다 모아 둔 것을 접근성 트리라고 한다.

그래서 눈으로 보기에 멀쩡한 버튼이 스크린 리더에게는 이름 없는 상자일 수 있다.

탭 키로 움직일 때 필요한 것

키보드만으로 웹을 쓰는 사람은 탭 키로 링크와 버튼, 입력창 사이를 옮겨 다닌다.
지금 선택된 요소를 두고 포커스를 받았다고 하고, 브라우저는 그 요소 둘레에 테두리를 그려 위치를 알려 준다.

이 테두리는 곧잘 지워진다.
예전 브라우저는 마우스로 누른 버튼에도 테두리를 그렸고, 보기 싫다고 여긴 개발자들이 CSS로 테두리를 통째로 없애곤 했다.
그러면 키보드 사용자는 지금 어디에 있는지 알 수 없다.

요즘 브라우저는 버튼을 마우스로 누를 때는 대개 테두리를 그리지 않고, 키보드로 옮겨 갈 때 그린다.
CSS의 :focus-visible 선택자를 쓰면 바로 그 테두리의 모양을 사이트에 맞게 바꿀 수 있다.

웹 접근성 지침인 WCAG는 키보드로 조작하는 화면이라면 포커스 표시가 보여야 한다고 정한다.
지우는 대신 사이트에 어울리는 모양으로 다시 그리면 된다.

스크린 리더는 무엇을 읽나

스크린 리더는 글자만 읽어 주지 않는다.
요소마다 버튼, 링크, 제목 같은 역할과 이름을 함께 알려 준다.

이 정보는 HTML에서 나온다.
button 요소로 만든 버튼에는 브라우저가 알아서 버튼이라는 역할을 붙이고, 탭으로 포커스를 받게 하고, Enter나 Space 키로 누를 수 있게 해 준다.

div⁠에 클릭 동작만 붙여 버튼처럼 꾸미면 이 약속이 하나도 없다.
마우스로는 눌리지만, 스크린 리더는 버튼인 줄 모르고 키보드로는 닿지도 않는다.

div⁠에 ARIA라는 속성을 붙여 버튼이라는 역할을 알려 줄 수는 있다.
그런데 ARIA 속성은 스크린 리더에 전하는 정보만 바꿀 뿐 동작은 만들어 주지 않는다.
탭으로 포커스를 받게 하는 tabindex 속성도, Enter나 Space 키를 처리하는 코드도 따로 붙여야 한다.

W3C의 ARIA 사용 지침은 첫 번째 규칙으로 이 방법을 말린다.
필요한 의미와 동작을 이미 갖춘 HTML 요소가 있으면, 다른 요소에 역할을 덧붙이지 말고 그 요소를 쓰라는 규칙이다.

버튼에 이름이 없다는 지적

이제 Lighthouse가 무엇을 지적했는지 알 수 있다.
버튼의 이름은 스크린 리더가 그 버튼을 소개할 때 읽는 글자다.

돋보기 아이콘만 넣은 검색 버튼은 눈으로 보면 뜻이 통한다.
그런데 글자가 없으니 스크린 리더는 무엇을 하는 버튼인지 알려 줄 수 없다.
보이는 글자를 넣거나, 화면에는 안 보이는 이름을 속성으로 달아 주면 된다.

이미지도 마찬가지다.
img⁠의 alt 속성에 적은 대체 텍스트가 스크린 리더 사용자에게는 그 이미지의 내용이 된다.

제목은 문서의 뼈대를 알려 준다.
스크린 리더 사용자는 이 뼈대를 따라 필요한 부분으로 바로 건너뛴다.
그래서 제목 단계가 어긋나면 이동하기도 어려워진다.

제목 2 바로 다음에 제목 4가 오는 식으로 단계를 건너뛰지 않는다.
글자 크기는 CSS로 정하고, 제목 단계는 문서 구조대로 매긴다.

색으로만 알리면 생기는 일

입력 오류를 빨간 테두리로만 알리거나, 승인과 대기를 초록 점과 회색 점으로만 나누는 화면이 많다.
색을 구별하기 어려운 사람에게는 이 차이가 보이지 않는다.
흑백으로 인쇄하거나 강한 햇빛 아래에서 볼 때도 마찬가지다.

WCAG는 색을 정보를 전하는 유일한 시각 수단으로 쓰지 말라고 정한다.
색을 빼라는 뜻은 아니다.
글자나 아이콘, 모양을 함께 두면 색은 보조 단서로 남는다.

색만 있는 표시와 글자를 함께 둔 표시는 색의 단서를 지웠을 때 남는 정보가 다르다.

색만 있는 예시

신청 A 신청 B

글자도 있는 예시

A · 승인 B · 대기

색으로만 구별하던 상태는 색의 단서가 없어지면 뜻을 잃는다. 글자를 함께 두면 상태를 계속 읽을 수 있다.

왼쪽은 색의 뜻을 알아야 한다. 오른쪽은 승인·대기를 글자로도 알려 준다.

색의 단서를 지워도 오른쪽의 승인·대기는 남는다. 왼쪽은 상태를 구별할 설명이 없다.

특정 장애의 시야를 재현한 것이 아닌 정보 표현의 비교다. 이 예제의 버튼과 결과 안내는 모든 상태에서 키보드와 보조 기술로 사용할 수 있다.

대비는 숫자로 잰다

글자와 배경의 밝기 차이는 대비율이라는 숫자로 잰다.
같은 색끼리는 1:1이고, 흰 바탕의 검은 글자가 가장 큰 21:1이다.
본문 글자는 4.5:1 이상이어야 하고, 18포인트 이상이거나 14포인트 굵은 글씨 같은 큰 글자는 3:1 이상이면 된다.

자주 놓치는 것은 글자가 아닌 요소다.
입력창의 테두리나 도표의 선처럼 화면을 이해하는 데 필요한 그래픽에도 3:1 기준이 따로 있다.
포커스 표시도 이 기준을 따른다.

옅은 회색 테두리는 차분해 보여서 자주 쓰인다.
하지만 그 선이 입력창의 경계를 알려 주는 유일한 단서라면 기준에 못 미치는 결함이 된다.

WCAG는 어떤 문서인가

지금까지 나온 기준은 WCAG(Web Content Accessibility Guidelines)⁠라는 문서에서 왔다.
웹 표준을 만드는 W3C의 접근성 이니셔티브가 펴내는 지침이다.

WCAG는 2.0, 2.1, 2.2로 판을 거듭했고, 지금 가장 새로운 판은 2023년에 나온 2.2다.
새 판은 대체로 기존 기준을 그대로 두고 새 기준을 더하는 식이라, 2.2를 만족하면 2.1과 2.0도 만족하도록 만들어졌다.

기준마다 A, AA, AAA 세 단계가 붙어 있다.
앞에서 본 색 사용 기준은 A 단계이고, 대비와 포커스 표시는 AA 단계다.

자동 검사가 잡지 못하는 것

평가 도구는 접근성의 모든 면을 자동으로 확인하지 못하고, 사람의 판단이 따로 필요하다.
Lighthouse는 버튼에 이름이 있는지는 확인해도, 그 이름이 버튼이 하는 일을 제대로 설명하는지는 판단하지 못한다.

그래서 자동 검사 다음에는 직접 써 보는 확인이 따라야 한다.
마우스를 치우고 탭 키만으로 페이지를 끝까지 지나가면, 포커스가 사라지는 곳과 닿지 않는 버튼이 금방 드러난다.

휴대폰에 기본으로 들어 있는 스크린 리더를 켜고 같은 페이지를 들어 보는 것도 도움이 된다.
새 컴포넌트를 만들 때 역할과 키보드 동작을 이미 갖춘 button, a, input 같은 요소부터 고르면 고칠 거리가 크게 줄어든다.