지금까지 접근성의 여러 갈래를 하나씩 다뤘다. 시맨틱, 대체 텍스트, 키보드, 포커스, 아리아, 색 대비, 낭독기, 폼, 미디어, 알림, 모션, 확대까지 챙길 것이 많았다. 이 많은 것을 사람이 매번 눈으로 다 확인하기는 어렵다. 그래서 검사를 돕는 도구가 있다. 이번 편은 접근성 자동 검사 도구와 그 한계를 다룬다.
나는 접근성 자동 검사 도구를 처음 썼을 때 신세계를 만난 듯했다. 버튼 하나 누르니 페이지의 접근성 문제들을 목록으로 뽑아 주었다. 그런데 그 목록을 다 고치고도 낭독기로 들어보니 여전히 쓰기 어려운 곳이 많았다. 도구가 통과라고 한 페이지가 실제로는 미완성이었던 것이다. 이 편은 도구를 믿되 맹신하지 않는 법에 관한 이야기다.
1. 자동 검사 도구라는 조력자
접근성 자동 검사 도구는 페이지를 훑어 접근성 문제를 자동으로 찾아 주는 프로그램이다. 사람이 하나하나 확인할 것을 기계가 빠르게 대신 검사해 준다. 나는 이 도구를 접근성 작업의 든든한 조력자로 여긴다. 사람이 놓치기 쉬운 것을 기계가 빠짐없이 훑어 주니, 검사의 첫 관문으로 삼기에 좋다.
이런 도구는 여러 형태로 있다. 브라우저에 설치해 쓰는 확장 도구가 있고, 브라우저에 이미 들어 있는 검사 기능도 있으며, 페이지 주소만 넣으면 검사해 주는 웹 도구도 있다. 나는 상황에 맞게 골라 쓰되, 어느 것을 쓰든 기본 원리는 비슷하다는 걸 알게 됐다. 이름과 생김새는 달라도 하는 일은 접근성 문제 찾기로 같다.
도구의 가장 큰 장점은 빠르고 빠짐없다는 것이다. 사람이 큰 페이지를 눈으로 다 훑으려면 오래 걸리고 놓치는 것도 많지만, 도구는 순식간에 전체를 검사한다. 나는 새 페이지를 만들면 먼저 이 도구로 한번 훑어, 명백한 문제들을 빠르게 걸러낸다. 사람의 정성 어린 점검에 앞서, 기계의 빠른 훑기로 큰 문제부터 잡는 것이다.
도구는 문제를 알려줄 뿐 아니라 어디가 왜 문제인지도 짚어 준다. 어느 요소에 이름이 없는지, 어느 글자의 대비가 부족한지를 구체적으로 알려준다. 나는 이 안내를 접근성을 배우는 교재로도 삼았다. 도구가 지적한 문제를 하나씩 고치다 보면, 무엇이 왜 접근성에 어긋나는지 자연스럽게 익히게 된다. 도구는 검사기이자 선생이다.
그러나 도구를 조력자로 여기되 심판으로 여기지는 않는다. 도구가 통과라고 해도 실제로는 쓰기 어려울 수 있고, 문제라고 짚은 것이 사실은 괜찮을 수도 있다. 나는 도구의 결과를 최종 판정이 아니라 참고로 받아들인다. 도구는 나를 돕는 조력자이지, 접근성의 완성을 보증하는 심판이 아니라는 걸 늘 기억한다. 도구를 심판으로 삼는 순간, 통과라는 결과에 안심하며 정작 중요한 사용성을 놓치기 쉽다. 나는 도구의 결과를 시작점으로 삼고, 진짜 판단은 사람의 몫으로 남겨 둔다.
정리하면 자동 검사 도구는 페이지를 빠르고 빠짐없이 훑어 접근성 문제를 찾아 주는 든든한 조력자이자 배움의 교재이지만, 최종 심판은 아니다. 나는 도구를 검사의 첫 관문으로 삼는다. 그렇다면 이 도구는 구체적으로 무엇을 잘 잡아낼까. 도구가 잘하는 영역부터 살펴보자.
2. 도구가 잘 잡는 것
자동 검사 도구는 기계가 판정할 수 있는 문제를 잘 잡는다. 규칙이 분명해서 맞고 틀림을 계산으로 가릴 수 있는 것들이다. 색 대비가 대표적이다. 두 색의 밝기 차이는 숫자로 계산되니, 도구가 기준 미달인 글자를 정확히 찾아낸다. 나는 대비 문제만큼은 도구에 크게 기대는데, 사람 눈보다 도구의 계산이 더 정확하기 때문이다.
이름이 빠진 요소도 도구가 잘 잡는다. 대체 텍스트 속성이 없는 이미지, 라벨이 연결되지 않은 입력 칸, 이름 없는 버튼처럼 있어야 할 이름이 없는 경우를 도구가 짚어 준다. 나는 이름 누락을 도구로 걸러낸다. 있어야 할 것이 없는 것은 기계가 확실히 잡아내니, 이런 빠뜨림은 도구에 맡기면 안심이다.
구조의 문제도 상당 부분 잡는다. 제목 단계를 건너뛴 곳, 같은 식별자가 여러 번 쓰인 곳, 요소를 잘못 중첩한 곳처럼 규칙에 어긋난 구조를 찾아낸다. 나는 이런 구조 오류를 도구로 점검한다. 사람이 눈으로는 놓치기 쉬운 제목 단계의 어긋남 같은 것도, 도구는 규칙에 따라 정확히 짚어 준다.
속성을 잘못 쓴 것도 도구가 잡는다. 아리아 속성에 잘못된 값을 넣거나, 존재하지 않는 요소를 참조하거나, 서로 어울리지 않는 속성을 함께 쓴 경우를 찾아낸다. 나는 아리아를 쓸 때 도구로 그 값이 올바른지 확인한다. 아리아는 잘못 쓰면 오히려 해로우니, 기계가 값의 옳고 그름을 검사해 주는 것이 큰 도움이 된다.
이런 문제들은 공통점이 있다. 규칙이 분명해 기계적으로 판정할 수 있다는 것이다. 있는지 없는지, 기준을 넘는지 못 넘는지, 값이 맞는지 틀리는지가 계산으로 갈린다. 나는 이렇게 판정이 분명한 영역은 도구에 맡기고, 사람의 시간은 도구가 못 하는 곳에 쓴다. 기계가 잘하는 일과 사람이 잘하는 일을 나누는 것이다.
정리하면 도구는 색 대비, 이름 누락, 구조 오류, 속성 오용처럼 규칙이 분명해 기계적으로 판정할 수 있는 문제를 잘 잡는다. 나는 이런 영역을 도구에 맡긴다. 그런데 접근성에는 규칙만으로 판정할 수 없는 영역이 훨씬 많다. 도구가 못 잡는 것을 아는 것이 더 중요하다.
3. 도구가 못 잡는 것
자동 검사 도구가 잡아내는 문제는 전체의 일부에 지나지 않는다. 접근성 문제의 상당 부분은 사람의 판단이 필요해 기계가 판정하지 못한다. 나는 도구가 못 잡는 것이 무엇인지를 아는 것이, 도구가 잡는 것을 아는 것보다 더 중요하다고 생각한다. 못 잡는 영역을 모르면, 도구의 통과를 완성으로 착각하기 때문이다.
대표적인 것이 대체 텍스트의 적절성이다. 도구는 대체 텍스트가 있는지 없는지는 알지만, 그 내용이 이미지에 맞는지는 판단하지 못한다. 이미지라는 무의미한 대체 텍스트도 있기만 하면 도구는 통과시킨다. 나는 대체 텍스트가 실제로 이미지의 뜻을 전하는지는 사람이 읽어봐야 안다는 걸 알고, 이 부분은 도구에 맡기지 않는다.
읽는 순서도 도구가 판정하기 어렵다. 요소들이 낭독기에서 말이 되는 순서로 읽히는지는 내용을 이해해야 알 수 있는데, 이것은 기계의 몫이 아니다. 나는 읽기 순서가 자연스러운지는 낭독기로 직접 들어봐야 한다는 걸 안다. 도구는 순서가 있는지는 알아도 그 순서가 뜻이 통하는지는 알지 못한다.
키보드 조작감도 도구가 못 잡는다. 도구는 요소가 포커스를 받을 수 있는지는 알지만, 실제로 키보드만으로 기능을 무리 없이 쓸 수 있는지, 포커스가 자연스럽게 흐르는지는 판정하지 못한다. 나는 키보드 조작감은 직접 탭을 눌러 가며 써봐야 안다는 걸 안다. 조작의 매끄러움은 계산이 아니라 경험으로만 확인된다.
동적 알림이 실제로 낭독되는지도 도구가 확인하지 못한다. 라이브 리전이 제대로 지정됐는지는 알아도, 그 알림이 낭독기에서 실제로 소리로 나는지는 들어봐야 안다. 나는 앞서 동적 알림 편에서 이것을 강조했다. 의미 있는 링크 텍스트인지, 포커스 관리가 매끄러운지도 마찬가지로 도구의 판정 밖에 있다.
정리하면 도구는 대체 텍스트의 적절성, 읽는 순서, 키보드 조작감, 동적 알림의 실제 낭독처럼 사람의 판단이 필요한 영역은 잡지 못한다. 나는 이 못 잡는 영역을 늘 염두에 둔다. 그렇다면 도구가 못 잡는 이 영역은 무엇으로 채울까. 답은 사람이 직접 하는 수동 검사다.
4. 수동 검사가 채운다
도구가 못 잡는 영역은 사람이 직접 검사해 채운다. 자동 검사가 큰 그물로 명백한 문제를 걸러낸다면, 수동 검사는 그물을 빠져나간 미묘한 문제를 손으로 잡는다. 나는 자동과 수동을 접근성 검사의 두 축으로 여긴다. 어느 하나만으로는 부족하고, 둘이 함께여야 접근성이 온전히 검사된다. 도구와 사람은 서로를 보완한다.
수동 검사의 첫째가 키보드 검사다. 마우스를 치우고 탭과 화살표, 엔터만으로 페이지를 처음부터 끝까지 써보는 것이다. 포커스가 자연스럽게 흐르는지, 모든 기능에 닿는지, 갇히는 곳은 없는지를 몸으로 확인한다. 나는 새 페이지마다 이 키보드 순회를 하며, 도구가 못 잡는 조작감의 문제를 직접 잡아낸다.
둘째가 낭독기 검사다. 화면 낭독기를 켜고 내 페이지가 어떻게 들리는지 확인하는 것이다. 순서가 말이 되는지, 이름이 제대로 읽히는지, 상태가 알려지는지, 알림이 소리로 나는지를 귀로 듣는다. 나는 이 낭독기 검사가 도구가 못 잡는 것의 대부분을 채운다는 걸 경험했다. 귀로 들어야 비로소 드러나는 문제가 많다.
셋째가 확대와 설정 검사다. 화면을 크게 확대해 무너지지 않는지, 어두운 화면 선호나 움직임 줄이기 설정이 존중되는지를 확인한다. 나는 여러 사용자 상황을 흉내 내며, 각 상황에서 페이지가 잘 쓰이는지 살핀다. 확대한 화면, 어두운 화면, 움직임을 줄인 화면을 각각 직접 만들어 보며 점검하는 것이다.
수동 검사에서 가장 좋은 방법은 실제 사용자의 목소리를 듣는 것이다. 접근성을 늘 쓰는 사용자가 직접 써보고 알려주는 것만큼 확실한 검사는 없다. 나는 기회가 되면 실제 접근성 사용자의 의견을 구하려 한다. 만드는 사람이 아무리 흉내를 내도, 매일 그 도구로 웹을 쓰는 사람의 경험을 온전히 알기는 어렵기 때문이다.
정리하면 수동 검사는 도구가 못 잡는 영역을 채우며, 키보드 순회와 낭독기 청취와 확대 설정 점검으로 이루어지고, 가장 좋은 것은 실제 사용자의 목소리다. 나는 자동과 수동을 두 축으로 삼는다. 마지막으로, 이 검사들을 한 번으로 끝내지 않고 꾸준히 이어가는 법을 살펴보자.
5. 검사를 흐름에 심는다
접근성 검사는 한 번 하고 끝나는 일이 아니다. 코드를 고치면 접근성이 다시 무너질 수 있어, 검사를 반복해야 한다. 그런데 매번 사람이 손으로 검사하기는 번거롭다. 나는 자동 검사를 개발 흐름에 심어, 코드가 바뀔 때마다 자동으로 접근성이 점검되게 하는 것이 좋다는 걸 배웠다. 검사를 일상에 녹이는 것이다.
자동 검사 도구는 사람이 버튼을 눌러 쓰는 것뿐 아니라, 코드 점검 과정에 자동으로 끼워 넣을 수도 있다. 코드를 바꿀 때마다 접근성 검사가 자동으로 돌아, 문제가 생기면 바로 알려주게 하는 것이다. 나는 이 방식으로 접근성이 무너진 채 배포되는 일을 막는다. 사람이 깜빡해도 기계가 지켜 주니 든든하다.
이렇게 검사를 흐름에 심으면 접근성이 뒷걸음치지 않는다. 한번 잘 만든 접근성이 나중에 코드를 고치다 무너지는 일을 막을 수 있다. 나는 이 자동 점검을 접근성의 안전망으로 여긴다. 새로 생긴 문제를 그때그때 잡아내니, 접근성이 조금씩 좋아지기만 할 뿐 나빠지지 않게 지킬 수 있다.
다만 자동 점검을 심어도 수동 검사를 대신하지는 못한다. 흐름에 심은 자동 검사는 규칙으로 잡히는 문제만 막을 뿐, 사람이 판단할 영역은 여전히 사람이 확인해야 한다. 나는 자동 점검으로 뒷걸음을 막되, 중요한 변화가 있을 때는 여전히 키보드와 낭독기로 직접 확인한다. 자동은 지킴이이고 수동은 완성이다.
무엇보다 접근성 검사는 나중이 아니라 처음부터, 그리고 꾸준히 하는 것이 중요하다. 다 만든 뒤에 몰아서 검사하면 고칠 것이 산더미가 된다. 나는 만드는 내내 조금씩 검사하며, 문제를 그때그때 잡는다. 접근성은 마지막에 덧붙이는 것이 아니라 처음부터 함께 짜고 꾸준히 지켜 가는 것임을 검사에서도 다시 확인한다.
정리하면 접근성 검사는 반복해야 하므로 자동 검사를 개발 흐름에 심어 뒷걸음을 막되, 이것이 수동 검사를 대신하지는 못하며, 처음부터 꾸준히 하는 것이 핵심이다. 나는 검사를 일상에 녹인다. 이제 접근성 시리즈의 마지막 편이 남았다. 다음 편에서는 지금까지 다룬 것을 아우르며 접근성의 흔한 실수들을 정리한다.