지금까지 나는 화면 낭독기라는 말을 여러 번 썼다. 시맨틱도, 대체 텍스트도, 아리아도 결국 이 낭독기에 정보를 잘 전하기 위한 것이었다. 그렇다면 화면 낭독기는 실제로 어떻게 동작할까. 이 도구를 이해하지 못하면 접근성 작업은 감으로만 하게 된다. 이번 편은 화면 낭독기가 무엇이고 어떻게 페이지를 읽는지를 다룬다.
나는 접근성을 한참 공부하고서도 정작 화면 낭독기를 직접 써본 적이 없었다. 그러다 처음으로 낭독기를 켜고 내 페이지를 들어봤을 때, 머리로만 알던 것들이 온몸으로 이해됐다. 내 페이지가 소리로 어떻게 들리는지 듣고 나서야, 무엇을 고쳐야 할지가 또렷해졌다. 이 편은 그 첫 경험에서 얻은 이해를 정리한 것이다.
1. 화면 낭독기란 무엇인가
화면 낭독기는 화면의 내용을 소리로 바꿔 읽어 주는 프로그램이다. 시각장애 사용자는 이 프로그램으로 웹을 듣고, 키보드로 조작한다. 낭독기는 화면의 픽셀을 보는 게 아니라, 브라우저가 만든 접근성 트리를 읽는다. 나는 이 사실을 알고 나서, 낭독기가 읽는 것은 내가 화면에 그린 그림이 아니라 내가 코드로 짠 의미라는 걸 이해했다.
낭독기는 종류가 여럿이다. 윈도우에서 널리 쓰이는 것이 있고, 애플 기기에는 기본으로 들어 있는 것이 있으며, 안드로이드에도 기본 낭독기가 있다. 각각 조금씩 다르게 동작하지만 기본 원리는 같다. 나는 모든 낭독기를 다 맞출 수는 없어도, 표준을 잘 지키면 대부분의 낭독기에서 무난히 동작한다는 것을 경험으로 알게 됐다.
낭독기는 화면을 위에서 아래로 읽어 나간다. 사용자는 이 흐름을 따라 듣거나, 특정 요소만 골라 건너뛰며 탐색한다. 한 번에 화면 전체를 훑는 눈과 달리, 낭독기는 한 줄씩 순서대로 듣는다. 나는 이 순차적 특성을 이해하고 나서, 내 페이지가 순서대로 들었을 때 말이 되는지를 늘 신경 쓰게 됐다. 순서가 곧 경험이다.
낭독기는 요소의 의미를 함께 읽어 준다. 그냥 텍스트만 읽는 게 아니라, 이것은 제목이다, 이것은 버튼이다, 이것은 링크다 하고 알려준다. 이 의미 안내가 있어야 사용자는 지금 듣는 것이 무엇인지 안다. 나는 시맨틱과 아리아가 결국 이 의미 안내를 위한 것임을 낭독기를 써보고서야 실감했다. 의미가 없으면 안내도 없다.
낭독기 사용자는 여러 목소리 속도와 방식에 익숙하다. 대개 상당히 빠른 속도로 듣고, 필요한 부분만 골라 듣는다. 그래서 군더더기 없는 깔끔한 낭독이 중요하다. 나는 낭독기 사용자가 초보가 아니라 능숙한 청취자임을 알고 나서, 불필요한 낭독을 줄이고 핵심만 또렷이 전하는 쪽으로 페이지를 다듬게 됐다.
정리하면 화면 낭독기는 화면이 아니라 접근성 트리를 읽어 소리로 바꾸는 프로그램이고, 종류가 여럿이며, 순서대로 읽고, 요소의 의미를 함께 안내한다. 나는 낭독기를 접근성 작업의 최종 청중으로 여긴다. 그렇다면 낭독기가 읽는 순서는 무엇이 정할까. 이것이 접근성의 핵심 원리 중 하나다.
2. 읽는 순서는 코드 순서다
화면 낭독기가 읽는 순서는 코드에 적힌 순서, 곧 문서 순서를 따른다. 화면에 보이는 위치가 아니라 코드에 나온 순서대로 읽는다. 그래서 코드 순서가 뒤죽박죽이면 낭독도 뒤죽박죽이 된다. 나는 이 원리를 접근성의 가장 중요한 규칙 중 하나로 여긴다. 화면이 아니라 코드가 낭독의 순서를 정하기 때문이다.
문제는 스타일로 화면 순서를 바꿨을 때 생긴다. 스타일 배치 도구를 쓰면 코드 순서와 다르게 요소를 화면에 배치할 수 있다. 눈에는 자연스러운 순서로 보여도, 코드 순서가 다르면 낭독은 엉뚱한 순서로 흐른다. 나는 스타일로 순서를 크게 바꾼 자리를 만나면, 낭독으로 들었을 때도 말이 되는지를 반드시 확인한다.
배치 도구의 순서 바꾸기 기능은 특히 조심해야 한다. 요소를 화면에서 앞뒤로 재배치하는 스타일 속성 order는 눈에 보이는 순서만 바꾸고 코드 순서는 그대로 둔다. 그래서 이 속성으로 순서를 크게 뒤집으면 시각과 낭독이 어긋난다. 나는 이 속성을 순서를 살짝 다듬는 데만 쓰고, 의미가 통하는 순서를 뒤집는 데는 쓰지 않는다.
그래서 원칙은 시각 순서와 코드 순서를 일치시키는 것이다. 화면에 보이는 흐름대로 코드도 흐르게 짜면, 낭독 순서가 저절로 자연스러워진다. 이것은 앞서 키보드 편에서 말한 탭 순서 원칙과 정확히 같다. 나는 코드 순서를 바로잡는 것이 낭독기 사용자와 키보드 사용자를 한꺼번에 돕는 길이라는 걸 알고, 이 일치를 늘 지킨다.
순서가 어긋나는 대표적인 예가 시각적으로만 재배치한 카드나 열이다. 눈에는 정돈돼 보이지만 낭독으로 들으면 내용이 뒤섞여 이해가 안 된다. 나는 이런 자리를 만나면 화면 배치를 위해 순서를 희생하기보다, 코드 순서를 화면 흐름에 맞춰 다시 짠다. 근본을 바로잡으면 시각과 낭독이 함께 매끄러워진다.
정리하면 낭독기는 코드 순서대로 읽으므로 시각 순서와 코드 순서를 일치시켜야 하고, 순서 바꾸기 스타일은 조심해서 쓰며, 이 일치는 키보드 사용자까지 함께 돕는다. 나는 코드 순서를 낭독의 뼈대로 여긴다. 그렇다면 화면에는 안 보이되 낭독기에는 들리게 하고 싶을 때는 어떻게 할까.
3. 눈에는 숨기고 귀에는 들리게
때로는 화면에는 보이지 않지만 낭독기에는 들려야 하는 정보가 있다. 아이콘만 있는 링크에 붙이는 이름이나, 낭독기 사용자에게만 주는 안내가 그렇다. 이럴 때 요소를 화면에서만 숨기고 낭독기에는 남기는 특별한 처리가 필요하다. 나는 이 처리를 접근성에서 자주 쓰는 중요한 기법으로 익혀 두었다.
주의할 점은 그냥 화면에서 숨기면 낭독기에서도 사라진다는 것이다. 요소를 완전히 감추는 흔한 방법들은 화면과 낭독기 양쪽에서 요소를 없앤다. 그러면 낭독기 사용자에게도 그 정보가 전해지지 않는다. 나는 이 사실을 모르고 안내 텍스트를 감췄다가 낭독기에서도 사라진 실수를 하고, 화면 감춤과 낭독 감춤이 다르다는 걸 배웠다.
그래서 눈에만 숨기려면 특별한 방식을 쓴다. 요소를 아주 작게 만들어 화면 밖으로 밀어내되 접근성 트리에는 남기는 방법이다. 이 방식으로 처리한 요소는 화면에는 안 보이지만 낭독기는 정상적으로 읽는다. 이런 처리를 보통 시각적 숨김 visually-hidden이라는 이름으로 스타일에 정의해 두고 필요할 때마다 쓴다.
이 방식은 아이콘 링크에 이름을 줄 때 특히 유용하다. 아이콘만 보이는 링크 안에, 시각적으로 숨긴 텍스트로 무슨 링크인지 적어 두면, 화면은 아이콘만 깔끔하게 보이고 낭독기는 그 텍스트를 읽는다. 나는 이 방법으로 화면의 간결함과 낭독의 친절함을 동시에 얻는다. 눈과 귀에 각각 알맞은 것을 주는 것이다.
반대의 경우도 있다. 눈에는 보이되 낭독기에서는 숨기고 싶을 때다. 장식 아이콘이나 중복 요소가 그렇다. 이때는 앞서 배운 보조기기 감춤 속성 aria-hidden을 쓴다. 눈에만 숨기는 방식과 귀에만 숨기는 방식은 방향이 정반대다. 나는 무엇을 어느 쪽에서 숨길지 먼저 정한 뒤, 그에 맞는 방식을 골라 쓴다.
정리하면 화면에만 숨기고 낭독기에는 남기려면 요소를 화면 밖으로 밀어내되 트리에 남기는 시각적 숨김을 쓰고, 반대로 눈에만 두고 귀에서 숨기려면 보조기기 감춤 속성을 쓴다. 나는 방향에 맞는 방식을 골라 쓴다. 이제 낭독기 사용자가 실제로 페이지를 어떻게 돌아다니는지 살펴보자.
4. 낭독기 사용자의 탐색법
낭독기 사용자는 페이지를 처음부터 끝까지 순서대로만 듣지 않는다. 능숙한 사용자는 특정 요소만 골라 건너뛰며 빠르게 훑는다. 제목만 따라 이동하거나, 링크만 모아 보거나, 랜드마크 단위로 점프하는 식이다. 나는 이 탐색 방식을 알고 나서, 낭독기 사용자가 내 페이지를 어떻게 훑을지를 상상하며 구조를 짜게 됐다.
가장 즐겨 쓰는 방식이 제목 이동이다. 낭독기 사용자는 제목만 따라 이동하며 페이지의 뼈대를 파악하고, 원하는 곳으로 바로 간다. 그래서 제목 계층이 잘 잡혀 있으면 탐색이 아주 편하다. 나는 앞서 강조한 제목 계층이 왜 그렇게 중요한지를 이 탐색 방식에서 다시 확인했다. 제목은 낭독기 사용자의 목차이자 지도다.
랜드마크 이동도 자주 쓰인다. 머리글, 메뉴, 본문, 바닥글 같은 큰 구획을 단위로 점프하는 것이다. 그래서 페이지 골격을 의미 있는 구획 요소로 짜두면 낭독기 사용자가 영역 단위로 빠르게 이동한다. 나는 시맨틱 골격이 이 랜드마크 이동을 가능하게 한다는 걸 알고, 페이지 구획을 늘 의미 있는 요소로 짠다.
링크만 모아 보는 방식도 있다. 낭독기는 페이지의 모든 링크를 목록으로 뽑아 보여줄 수 있다. 이때 링크 텍스트가 여기 클릭 같은 말이면, 목록에 여기 클릭만 잔뜩 뜨고 어디로 가는지 알 수 없다. 나는 링크 텍스트에 목적지를 담아, 링크만 따로 봐도 어디로 가는지 알 수 있게 한다. 링크 텍스트는 그 자체로 뜻이 통해야 한다.
이 탐색 방식들은 모두 잘 짜인 구조에 기댄다. 제목 계층, 랜드마크, 의미 있는 링크 텍스트가 갖춰져야 이 빠른 탐색이 가능하다. 구조가 엉성하면 낭독기 사용자는 처음부터 끝까지 순서대로 듣는 수밖에 없다. 나는 이 탐색을 돕는 것이 곧 낭독기 사용자의 시간을 아껴 주는 일이라 여기며, 구조를 정성껏 짠다.
정리하면 낭독기 사용자는 제목, 랜드마크, 링크 목록으로 페이지를 빠르게 훑으므로, 제목 계층과 시맨틱 골격과 뜻이 통하는 링크 텍스트가 이 탐색을 좌우한다. 나는 이 구조를 낭독기 사용자를 위한 지도로 여긴다. 마지막으로, 이 모든 것을 확인하는 가장 확실한 방법을 이야기하자.
5. 직접 들어보는 것이 답이다
화면 낭독기를 이해하는 가장 확실한 방법은 직접 켜서 들어보는 것이다. 아무리 이론을 알아도, 내 페이지가 실제로 어떻게 들리는지는 들어봐야 안다. 나는 낭독기를 처음 켰을 때 머리로만 알던 문제들이 귀로 쏟아지는 걸 경험했다. 그 뒤로 낭독기로 들어보는 것을 접근성 점검의 필수 과정으로 삼았다.
낭독기는 대부분의 기기에 이미 들어 있어 따로 살 필요가 없다. 컴퓨터에도, 스마트폰에도 기본 낭독기가 있어 설정에서 켜기만 하면 된다. 나는 처음에 낭독기를 켜는 것 자체가 낯설고 어려웠지만, 몇 번 해보니 익숙해졌다. 도구가 무료로 손안에 있으니, 남은 것은 켜서 내 페이지를 들어볼 용기뿐이었다.
낭독기로 들어보면 눈으로는 절대 안 보이는 문제들이 드러난다. 순서가 뒤엉킨 곳, 이름 없는 버튼, 상태를 안 알리는 토글, 의미 없는 링크 텍스트가 소리로 고스란히 들린다. 나는 이런 문제들을 눈으로 아무리 봐도 못 찾다가, 낭독기로 듣고 나서야 발견하곤 한다. 귀는 눈이 놓친 것을 잡아낸다.
처음에는 눈을 뜨고 화면과 낭독을 함께 확인하다가, 익숙해지면 눈을 감고 소리만으로 페이지를 써보는 것이 좋다. 소리만으로 원하는 기능에 닿을 수 있으면 접근성이 잘된 것이다. 나는 가끔 눈을 감고 내 페이지를 조작해 보며, 소리만으로도 길을 잃지 않는지 확인한다. 이 훈련이 접근성 감각을 크게 길러 주었다.
낭독기 점검은 자동 검사가 못 잡는 것을 채운다. 자동 도구는 이름 누락이나 대비 같은 것은 잡지만, 낭독이 실제로 자연스러운지, 순서가 말이 되는지는 판단하지 못한다. 나는 자동 검사로 큰 문제를 걸러낸 뒤, 낭독기로 직접 들어 실제 경험을 확인한다. 자동과 수동을 함께 써야 접근성이 완성된다.
정리하면 화면 낭독기는 직접 켜서 들어봐야 제대로 이해되고, 대부분의 기기에 무료로 있으며, 눈으로 못 찾는 문제를 귀로 잡아내고, 자동 검사가 못 채우는 부분을 메운다. 나는 낭독기 청취를 점검의 필수로 삼는다. 다음 편에서는 낭독기 사용자가 가장 자주 부딪히는 어려운 관문인 폼의 접근성을 다룬다.