접근성 의무 최소 체크리스트

공감·문제제기

이번 주는 ‘웹 접근성’ 이야기로 시작했다. 월요일엔 접근성이 왜 ‘있으면 좋은 것’이 아니라 ‘없으면 안 되는 것’인지, 즉 법적 의무라는 점을 짚었고, 수요일엔 접근성이 무너진 사이트에서 사용자가 실제로 어떤 벽에 부딪히는지를 살펴봤다. 그리고 오늘 금요일, 가장 실무적인 이야기를 할 차례다. ‘그래서 우리 사이트의 접근성은 지금 어느 수준인지, 담당자가 직접 5분 만에 가늠해보는 최소 체크리스트’다.

먼저 솔직하게 털어놓자. 접근성이라는 단어를 들으면 많은 담당자가 ‘아, 그 어려운 거’ 하고 한 발 물러선다. 화면 낭독기가 어떻고, 명도 대비 비율이 어떻고, 코드 어디에 무슨 속성을 넣어야 하고 — 듣다 보면 ‘이건 전문가가 할 일이지 내가 손댈 영역이 아니구나’ 싶어진다. 그 마음, 충분히 이해한다. 하지만 오늘 글에서 하고 싶은 말은 정반대다. 접근성의 ‘가장 중요하고 가장 자주 걸리는’ 문제 대부분은, 전문 지식이 없는 담당자도 ‘쓰는 사람 입장에서’ 5분만 들여다보면 충분히 잡아낼 수 있다는 것이다.

왜 그런가. 접근성의 본질은 결국 ‘누구도 배제되지 않게 하는 것’이기 때문이다. 눈이 잘 안 보이는 사람, 마우스를 못 쓰는 사람, 색을 잘 구분하지 못하는 사람, 손이 떨려 작은 버튼을 정확히 누르기 어려운 사람 — 이런 사용자들이 우리 사이트에서 ‘원하는 일을 끝까지 해낼 수 있는가’가 접근성의 전부다. 그리고 이건 어려운 코드의 문제이기 전에 ‘배려의 문제’다. 코드는 그 배려를 화면에 구현하는 수단일 뿐이다. 그래서 코드를 몰라도, ‘이 사이트가 모두에게 친절한가’라는 질문은 누구나 던질 수 있다.

그런데 이 ‘배려’가 공공 웹사이트에서는 단순한 미덕이 아니라 ‘지켜야 할 의무’다. 공공기관의 웹사이트는 특정한 누군가를 위한 것이 아니라 ‘모든 국민’을 위한 것이다. 민원을 신청하고, 정책 정보를 확인하고, 각종 증명서를 발급받는 일은 누군가에게는 ‘편의’가 아니라 ‘생존에 필요한 절차’다. 그런 절차가 어떤 사용자에게만 막혀 있다면, 그건 그 사용자에게서 ‘공공 서비스를 받을 권리’ 자체를 빼앗는 것과 다르지 않다. 그래서 우리나라는 웹 접근성을 법으로 정해 두었고, 공공기관은 이를 ‘권고’가 아니라 ‘의무’로 지켜야 한다.

오늘 체크리스트는 그 의무를 ‘완벽하게 검증하는’ 정밀 진단이 아니다. 그건 사람이 손으로 할 수 있는 일이 아니다. 웹 접근성은 KWCAG라는 표준으로 33개 항목이 정해져 있는데, 이걸 한 항목 한 항목 정밀하게 따지려면 전문 도구와 상당한 시간이 든다. 대신 오늘은 그중에서도 ‘가장 자주 위반되고, 사용자에게 가장 직접적인 피해를 주는’ 핵심 항목만 골라, 비전문가도 눈과 키보드만으로 빠르게 확인할 수 있게 추렸다. 일종의 ‘접근성 자가 건강검진’이다. 정밀 검사는 도구에 맡기되, 그 전에 ‘대충 어디가 막혀 있는지’ 감을 잡는 용도다.

한 가지 미리 안심시켜 드리자면, 오늘 항목들은 ‘접근성을 잘 아는 사람’이 아니라 ‘처음 듣는 사람’을 기준으로 골랐다. 그래서 각 항목마다 ‘무엇을 보는지’뿐 아니라 ‘어떻게 확인하는지’까지 구체적인 방법을 함께 적었다. 마우스를 치우고 키보드로 다녀보기, 화면을 흑백으로 바꿔보기, 이미지를 가린 채 페이지를 읽어보기, 폼을 일부러 틀려보기 — 이런 ‘간단한 실험’ 몇 가지면 충분하다. 특별한 프로그램을 깔거나 코드를 들여다볼 필요가 없다. 우리 기관 사이트와, 평소 쓰던 컴퓨터·스마트폰만 있으면 누구나 지금 당장 따라 할 수 있다. 접근성이 ‘전문가의 영역’처럼 느껴졌다면, 오늘 글을 따라오면서 ‘아, 나도 충분히 볼 수 있는 거였구나’ 하는 마음으로 바뀌길 바란다.

왜 ‘디자인 담당자도 아닌 내가’ 이런 걸 해야 하나 싶을 수 있다. 하지만 접근성은 디자이너 한 사람의 책임이 아니다. 콘텐츠에 이미지를 올리는 담당자, 신청 양식의 입력칸을 기획하는 담당자, 안내문의 문구를 쓰는 담당자, 외주를 관리하는 담당자 — 사이트에 손을 대는 모든 사람이 조금씩 접근성을 만들거나 망가뜨린다. 이미지에 대체 텍스트 한 줄을 안 넣는 작은 누락, 색만으로 정보를 구분한 작은 선택, 이런 사소해 보이는 결정 하나하나가 쌓여 누군가의 길을 막는다. 그래서 ‘무엇이 모두에게 친절한 사이트인가’에 대한 감각을, 사이트에 관여하는 모든 사람이 조금씩 갖추는 게 중요하다.

그리고 이 점검이 ‘돈이 안 드는 일’이라는 것도 큰 매력이다. 외부 컨설팅을 부르거나 인증 절차를 밟기 전에, 지금 당장 5분이면 시작할 수 있다. 결재도 필요 없고, 예산도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 ‘평소와 다른 방식으로’ 한 바퀴 돌아보는 것뿐이다. 마우스를 손에서 떼고 키보드만으로 다녀보고, 화면을 흑백으로 바꿔 보고, 이미지를 잠깐 가린 채로 페이지를 읽어보는 — 그 작은 실험들이 ‘우리 사이트가 누군가에게 어떤 벽인지’를 단번에 보여준다.

준비물은 간단하다. 우리 기관 사이트, 그리고 키보드가 달린 컴퓨터 하나. 가능하면 스마트폰도 곁에 두자. 데스크탑과 모바일에서 접근성 문제가 다르게 나타나기 때문이다. 펜과 종이(혹은 메모 앱)에 ‘예/아니오’를 적어가며 따라오면 된다. 그리고 한 가지 마음의 준비. 이건 ‘시험’이 아니라 ‘검진’이다. ‘아니오’가 많이 나올수록 점검이 잘된 거다. 문제를 많이 찾았다는 건 곧 고칠 거리를 많이 확보했다는 뜻이고, 그건 사이트가 더 많은 사람에게 열릴 여지가 그만큼 크다는 뜻이다. 모든 항목에 ‘예’를 적고 있다면, 점검이 잘된 게 아니라 ‘너무 후하게 보고 있는’ 건 아닌지 의심해야 한다.

한 가지 더 당부하자면, 체크할 때는 ‘만든 사람’의 눈이 아니라 ‘그 도구 없이는 못 쓰는 사람’의 눈으로 봐야 한다. 우리는 눈으로 화면을 보고 마우스로 클릭하는 데 익숙해서, 그 방식이 막히는 사람이 있다는 걸 자꾸 잊는다. 그래서 오늘만큼은 일부러 ‘불편한 조건’을 만들어 사이트를 써보길 바란다. 마우스를 치우고, 화면 색을 빼고, 글자를 키우고 — 그렇게 ‘평소의 편안함’을 일부러 걷어냈을 때 비로소 보이는 문제들이 있다. 자, 시작하자.

본론 1 — 왜 접근성은 ‘의무’인가, 그리고 왜 자가 체크부터인가

■ 접근성은 권고가 아니라 ‘지켜야 하는 선’이다

“접근성은 좋은 거지만, 예산도 인력도 없는데 어디까지 해야 하나요?”라는 질문을 자주 듣는다. 이 질문에는 ‘접근성은 여유가 될 때 하는 것’이라는 전제가 깔려 있다. 하지만 공공 웹사이트에서 접근성은 ‘여유가 될 때 하는 것’이 아니라 ‘기본으로 깔려 있어야 하는 선’이다. 마치 건물에 비상구와 경사로가 있어야 하는 것과 같다. 비상구를 ‘예산이 되면 만드는 옵션’으로 여기는 건물이 없듯, 공공 사이트의 접근성도 ‘있으면 좋은 추가 기능’이 아니라 ‘없으면 안 되는 기본 설비’다.

이게 ‘법적 의무’라는 표현의 진짜 의미다. 법이 무서워서 지키라는 게 아니라, 공공 서비스를 ‘모든 국민’에게 차별 없이 제공해야 하는 공공기관의 본질적 책무를 법이 명문화한 것뿐이다. 누군가는 화면을 못 보고 소리로 듣는다. 누군가는 손을 못 써 키보드나 음성으로 조작한다. 누군가는 색을 구분하지 못한다. 이들도 똑같이 세금을 내고, 똑같이 공공 서비스를 받을 권리가 있는 국민이다. 그 권리를 사이트가 ‘기술적인 이유로’ 막고 있다면, 그건 의도하지 않았더라도 결과적으로 차별이 된다.

그래서 접근성 점검의 출발점은 ‘몇 점 받을까’가 아니라 ‘우리 사이트가 누군가를 막고 있지는 않은가’여야 한다. 점수는 그 ‘막힘’을 수치로 환산한 결과일 뿐, 목적이 아니다. 오늘 체크리스트를 따라가는 동안에도 이 마음가짐을 잃지 말자. 항목 하나하나가 ‘이 항목을 어기면 어떤 사람이 못 쓰게 되는가’를 묻고 있다고 생각하면, 점검이 훨씬 또렷해진다.

■ 왜 ‘자가 체크’부터 해야 하나

“그냥 자동 검사 도구 돌리면 되는 거 아니에요?”라고 물을 수 있다. 맞다, 정밀한 접근성 검사는 도구가 한다. 그것도 사람보다 훨씬 빠르고 빠짐없이. 하지만 자가 체크를 먼저 해보는 데는 분명한 이유가 있다.

첫째, ‘내 몸으로’ 불편을 겪어봐야 개선 의지가 생긴다. 점수만 받으면 ‘아 낮네’ 하고 끝나기 쉽다. 하지만 마우스를 치우고 키보드만으로 신청 폼을 채워보다가 ‘이 버튼이 도대체 어디 있는 거지’ 하고 한참을 헤매보면, 접근성이 안 된 사이트가 ‘누군가에게는 매일의 좌절’이라는 게 몸으로 와닿는다. 그 체감이 개선을 밀어붙이는 동력이 된다. 숫자는 머리로 이해되지만, 직접 막혀본 경험은 가슴에 남는다.

둘째, 도구 결과를 ‘읽을 줄’ 알게 된다. 접근성 자동 검사 리포트를 처음 받아 든 담당자들이 가장 흔히 하는 말이 ‘항목은 많은데 뭘 먼저 봐야 할지 모르겠다’이다. ‘대체 텍스트 누락 12건’, ‘명도 대비 미달 8건’ 같은 결과가 나와도, 그게 실제로 어떤 사용자에게 어떤 불편을 주는지 모르면 그냥 ‘빨간 숫자’로만 보인다. 오늘처럼 직접 이미지를 가려보고 화면을 흑백으로 바꿔본 경험이 있으면, 같은 리포트가 ‘아, 그때 그 막혔던 게 이 항목이구나’로 살아 움직인다. 도구는 ‘무엇이 문제인지’를 알려주지만, 그 문제가 ‘누구에게 왜 문제인지’를 아는 건 결국 사람의 몫이다.

셋째, 빠르다. 5분이면 ‘우리 사이트의 접근성이 대충 어느 수준인지’ 감이 온다. 본격적인 진단과 개선에 들어가기 전, 가벼운 워밍업으로 딱이다. 그리고 이 ‘빠름’에는 또 다른 가치가 있다. 무거운 진단은 마음먹고 날을 잡아야 하지만, 5분짜리 체크는 점심시간에도, 회의 시작 전에도 할 수 있다. 부담이 작으니 자주 하게 되고, 자주 하니 새로 올린 콘텐츠가 접근성을 깨뜨렸을 때 일찍 알아챈다. 접근성은 ‘한 번 잡으면 끝’이 아니라 ‘콘텐츠가 쌓일수록 다시 무너지는’ 영역이라, 이 ‘자주 보기’가 특히 중요하다.

넷째, ‘대화의 출발점’이 생긴다. 접근성 개선은 혼자 하는 일이 아니다. 콘텐츠 담당, 개발 외주, 윗선이 함께 움직여야 한다. 그런데 ‘우리 사이트 접근성이 좀 별로인 것 같아요’라는 막연한 말로는 누구도 움직이지 않는다. 반면 ‘제가 자가 체크를 해봤더니, 키보드만으로는 신청 폼을 끝까지 채울 수가 없고, 메인 배너 이미지에 대체 텍스트가 하나도 없었습니다’라고 하면, 이야기가 구체적인 안건이 된다. 자가 체크는 ‘문제를 말로 꺼낼 수 있게’ 만들어주는 도구다. 손에 쥔 점검 결과 하나가, 미뤄지던 접근성 개선 논의를 시작하게 만드는 방아쇠가 된다.

자가 체크가 ‘정밀 진단’을 대체하는 게 아니라는 점도 분명히 해두자. 둘은 역할이 다르다. 자가 체크는 ‘빠르고 거칠게’ 큰 벽을 찾는 일이고, 정밀 진단은 ‘느리지만 정확하게’ 33개 항목 전부를 따지는 일이다. 자가 체크 없이 바로 정밀 진단만 받으면 ‘숫자는 나왔는데 뭘 봐야 할지 모르는’ 상태가 되고, 정밀 진단 없이 자가 체크만 믿으면 ‘눈에 안 보이는 깊은 문제’를 놓친다. 그래서 오늘 글은 ‘자가 체크로 큰 벽을 먼저 찾고, 그다음 정밀 진단으로 나머지를 확정하라’는 순서를 권한다.

본론 2 — 접근성 최소 체크리스트, 5개 묶음

■ 체크리스트의 구성

오늘 체크리스트는 KWCAG의 핵심 원칙을 실무 담당자가 따라 하기 쉽게 다섯 묶음으로 재구성했다. 각 묶음에서 핵심 질문 몇 개씩만 던진다. 전부 ‘예/아니오’로 답할 수 있게 만들었다.

· A. 보이지 않아도 읽히는가 — 대체 텍스트와 화면 낭독

· B. 마우스 없이도 쓸 수 있는가 — 키보드와 초점

· C. 색에만 기대고 있지 않은가 — 색·대비·구분

· D. 헷갈리지 않게 안내하는가 — 라벨·오류·구조

· E. 영상·문서·모바일까지 챙기는가 — 멀티미디어와 운영

왜 이 다섯 묶음일까. 접근성을 ‘어떤 사용자가 어떤 벽에 부딪히는가’의 관점으로 나누면 이렇게 정리된다. 화면을 못 보는 사용자(A), 마우스를 못 쓰는 사용자(B), 색을 구분하기 어려운 사용자(C), 인지·이해에 도움이 필요한 사용자(D), 그리고 영상·문서·모바일 등 ‘다른 형태의 콘텐츠’를 만나는 모든 사용자(E). 이 다섯을 차례로 보면, ‘서로 다른 어려움을 가진 사용자들이 각각 우리 사이트에서 막히는 지점’을 빠짐없이 훑게 된다.

체크할 때 ‘예/아니오’가 애매한 항목이 분명 나올 거다. ‘이게 예인가 아니오인가’ 싶을 땐, 망설이지 말고 ‘아니오’로 적는 걸 권한다. 점검의 목적은 좋은 점수가 아니라 ‘막힌 곳을 찾는 것’이기 때문이다. 후하게 채점해서 ‘우리 괜찮네’ 하고 넘어가면, 정작 누군가 매일 부딪히는 벽을 놓친다. 의심스러우면 ‘그 도구 없이는 못 쓰는 사용자’ 편에 서서 더 엄격하게 보는 게, 결국 그 사용자에게도 우리에게도 이득이다.

한 가지 더, 다섯 묶음을 ‘순서대로’ 보는 걸 권한다. 마음 가는 대로 건너뛰면 어떤 영역은 통째로 빼먹게 된다. 특히 A(대체 텍스트)와 E(영상·문서)는 눈에 잘 안 띄어서 자꾸 뒤로 밀리는데, 정작 가장 자주 위반되는 영역이 그 둘이다. 그러니 A부터 E까지 차례대로, 각 묶음을 다 끝내고 다음으로 넘어가자.

각 묶음에서 곁들이는 ‘자주 보이는 문제’ 사례는 전부 익명으로 일반화한 것이다. 특정 기관을 흉보려는 게 아니라, 규모가 크든 작든 예산이 많든 적든 거의 똑같이 반복되는 ‘전형’을 보여주려는 거다. 잘 만든 사이트라고 안 나오는 게 아니라 ‘덜 나오는’ 정도의 차이일 뿐이다. 그러니 읽으면서 ‘우리도 저런데’ 싶은 게 나와도 자책할 필요는 전혀 없다. 못 찾는 게, 다시 말해 ‘안 보이는 게’ 더 위험하다. 사례를 읽을 땐 ‘우리는 아니겠지’가 아니라 ‘혹시 우리도?’ 하는 마음으로, 실제로 우리 사이트의 해당 페이지를 열어 확인해보는 게 좋다. 자, 하나씩 가보자.

■ A. 보이지 않아도 읽히는가 — 대체 텍스트와 화면 낭독

A-1. 본문의 ‘정보를 담은 이미지’에 대체 텍스트(alt)가 붙어 있는가? (장식용 이미지는 빈 값으로 비워두었는가?)

→ 자주 보이는 문제: 메인 배너, 안내 도표, 행사 포스터에 대체 텍스트가 없어, 화면 낭독기 사용자에게는 ‘이미지’ 혹은 파일명만 읽힌다. 정작 그 이미지에 담긴 ‘무료 교육 신청 8월 마감’ 같은 핵심 정보가 통째로 사라진다.

A-2. 차트·표·인포그래픽처럼 ‘이미지로 된 정보’에 대안 설명이 있는가?

→ 자주 보이는 문제: 복잡한 통계 도표를 이미지 한 장으로 올려두고 대체 설명이 없다. 눈으로 보는 사람에게만 정보가 전달되고, 듣는 사람에겐 빈칸이다.

A-3. 화면 낭독기로 페이지를 들었을 때, ‘읽는 순서’가 자연스러운가?

→ 자주 보이는 문제: 시각적으로는 위에서 아래로 읽히는데, 낭독 순서는 코드 순서를 따라 뒤죽박죽이라 내용이 뒤섞여 들린다.

A 영역을 점검하는 가장 쉬운 방법은 ‘이미지를 안 보이게 하고 페이지를 읽어보는 것’이다. 브라우저 설정에서 이미지를 끄거나, 화면 낭독기를 켜고 눈을 감은 채 들어보라. 이미지를 다 가렸을 때 페이지의 ‘말’만으로도 무슨 내용인지 이해된다면 통과고, ‘여기 뭔가 중요한 게 있었던 것 같은데 텅 비었다’ 싶으면 대체 텍스트가 빠진 거다. 특히 ‘이미지로 만든 안내문’이 위험하다. 마감일, 신청 방법, 연락처 같은 핵심 정보를 보기 좋게 포스터 이미지 한 장에 박아 올리면, 보는 사람에겐 멋지지만 듣는 사람에겐 ‘아무 정보 없음’이 된다.

대체 텍스트를 쓸 때 흔한 오해 하나를 짚자. ‘이미지가 있으면 무조건 alt를 채워야 한다’고 알고 무의미한 글자를 욱여넣는 경우가 있는데, 이건 오히려 방해가 된다. 순전히 장식용인 이미지(예: 칸을 나누는 선, 분위기용 배경)는 대체 텍스트를 ‘빈 값’으로 두어 낭독기가 건너뛰게 해야 한다. 핵심은 ‘정보를 담은 이미지’와 ‘장식용 이미지’를 구분해, 전자에는 그 정보를, 후자에는 침묵을 주는 것이다. 대체 텍스트는 ‘이미지를 설명하는 글’이 아니라 ‘이미지가 전하려던 정보를 글로 옮긴 것’이라고 생각하면 쉽다. 행사 포스터라면 ‘포스터 이미지’가 아니라 ‘○○ 교육 신청, 8월 9일 마감, 온라인 접수’라고 적는 식이다.

A 영역이 중요한 이유를 한 번 더 짚자. 화면을 못 보는 사용자에게 사이트는 ‘소리로 듣는 사이트’다. 이들에게 대체 텍스트가 없는 이미지는 ‘안 들리는 정보’, 즉 ‘없는 정보’와 같다. 우리가 무심코 이미지 한 장에 담아 올린 ‘이번 달 핵심 공지’가, 누군가에게는 통째로 전달되지 않는다는 뜻이다. 그래서 A 영역의 ‘아니오’는 단순한 누락이 아니라 ‘특정 사용자에게만 정보를 차단한 것’이고, 접근성이 ‘의무’인 이유가 가장 선명하게 드러나는 지점이다.

대체 텍스트가 ‘가장 자주 빠지는 자리’도 미리 알아두면 점검이 빨라진다. 첫째는 메인 페이지의 큰 배너·슬라이드 이미지다. 보기엔 화려하지만 대체 텍스트가 없으면 낭독기 사용자에겐 ‘이미지’ 한마디로 끝난다. 둘째는 ‘바로가기 아이콘’들이다. 자주 쓰는 민원·신청 메뉴를 예쁜 아이콘으로 깔아두고 아이콘에 설명을 안 붙이면, 듣는 사용자에겐 ‘링크, 링크, 링크’만 줄줄이 들린다. 셋째는 본문 중간의 안내 도표다. 이 세 자리만 집중적으로 확인해도 A 영역의 큰 구멍은 거의 다 잡힌다. 우리 사이트를 열어 이 세 곳부터 ‘이미지를 끈 채’ 들여다보라.

한 가지 더, 대체 텍스트를 ‘운영 단계에서 지키게 만드는’ 게 핵심이다. 처음 사이트를 만들 때 대체 텍스트를 잘 넣어도, 이후 담당자가 게시판에 이미지를 올릴 때마다 매번 빠뜨리면 접근성은 다시 무너진다. 그래서 ‘이미지를 올릴 때 대체 텍스트 입력칸을 반드시 채우게’ 하는 작은 운영 규칙 하나가, 백 번의 사후 점검보다 효과적이다. 콘텐츠를 올리는 모든 담당자가 ‘이미지엔 항상 설명 한 줄’을 습관으로 들이면, A 영역은 저절로 유지된다.

■ B. 마우스 없이도 쓸 수 있는가 — 키보드와 초점

B-1. 키보드 Tab 키만으로 메뉴·링크·버튼·입력칸을 모두 돌아다닐 수 있는가?

→ 자주 보이는 문제: 마우스로만 펼쳐지는 메뉴, 마우스로만 닫히는 팝업이 있어 키보드 사용자가 거기서 길이 막힌다.

B-2. Tab으로 이동할 때, ‘지금 어디에 있는지’ 알려주는 초점 테두리가 또렷이 보이는가?

→ 자주 보이는 문제: 초점 표시를 디자인상 ‘지저분하다’며 없애버려, 키보드 사용자가 자기 위치를 알 수 없다.

B-3. 이동 순서가 화면에 보이는 순서(위→아래, 좌→우)와 일치하는가?

→ 자주 보이는 문제: 시각적으로는 위에 있는 버튼이 Tab 순서로는 한참 뒤에 와서, 키보드 사용자가 예상치 못한 곳으로 튄다.

B-4. 팝업·달력·드롭다운 같은 ‘떠 있는 요소’를 키보드로 열고, 안에서 조작하고, ESC 등으로 닫을 수 있는가?

→ 자주 보이는 문제: 팝업이 떠도 초점이 그 안으로 들어가지 않거나, 닫는 방법이 마우스 클릭뿐이다.

B 영역을 점검하는 가장 확실한 방법은 ‘마우스를 손에서 떼는’ 것이다. 정말로 마우스를 책상 한쪽으로 밀어두고, Tab 키와 Enter 키, 방향키만으로 우리 사이트의 핵심 흐름 하나를 처음부터 끝까지 해보라. 메인에서 신청 페이지로 들어가, 폼을 채우고, 제출까지. 이 과정에서 ‘아, 여기는 마우스가 있어야만 되는데’ 하는 지점이 한 군데라도 나오면, 그곳이 바로 키보드 사용자에게는 ‘넘을 수 없는 벽’이다. 마우스로는 멀쩡해 보이던 사이트가 키보드 앞에서 줄줄이 허점을 드러낸다.

특히 B-2의 ‘초점 테두리’는 디자인 욕심에 가장 자주 희생되는 항목이다. 화면 디자인을 깔끔하게 만들고 싶은 마음에 ‘버튼을 눌렀을 때 생기는 그 파란 테두리’를 보기 싫다며 없애버리는 경우가 정말 많다. 하지만 그 테두리는 ‘지저분한 것’이 아니라 키보드 사용자의 ‘커서’다. 마우스 사용자에게서 마우스 포인터를 빼앗는 것과 똑같은 일이다. 포인터가 안 보이면 마우스를 못 쓰듯, 초점이 안 보이면 키보드를 못 쓴다. 그러니 초점 표시는 없애는 게 아니라, 디자인과 어울리게 ‘더 보기 좋게 다듬는’ 방향으로 가야 한다.

B 영역이 중요한 이유는, 키보드 접근성이 ‘여러 종류의 사용자’를 한꺼번에 책임지기 때문이다. 손을 잘 못 쓰는 지체장애 사용자, 화면을 못 봐서 키보드로만 다니는 시각장애 사용자, 손이 떨려 정밀한 마우스 조작이 어려운 사용자 — 이들 모두가 키보드(또는 키보드처럼 동작하는 보조기기)에 기댄다. 그래서 ‘키보드만으로 모든 기능을 쓸 수 있는가’는 접근성에서 가장 기본이자 가장 영향이 넓은 질문이다. 이 하나가 막히면, 동시에 여러 부류의 사용자가 함께 막힌다.

키보드 점검을 할 때 ‘건너뛰기 링크’도 함께 확인하면 좋다. 화면을 못 보는 사용자가 어느 페이지에 들어가든 가장 먼저 만나는 건 길고 긴 상단 메뉴다. 마우스 사용자는 메뉴를 ‘쓱’ 지나쳐 본문으로 눈을 옮기지만, 키보드 사용자는 Tab을 수십 번 눌러 메뉴를 다 통과해야 본문에 닿는다. 그래서 페이지 맨 앞에 ‘본문 바로가기’ 같은 건너뛰기 링크를 두어, 키보드 한두 번으로 핵심 내용으로 점프할 수 있게 해주는 게 친절한 사이트의 기본이다. Tab을 처음 눌렀을 때 ‘본문 바로가기’ 같은 링크가 나타나는지 확인해보라. 안 나타난다면, 키보드 사용자는 매 페이지마다 메뉴 미로를 처음부터 헤매고 있는 것이다.

또 하나, 키보드로 다니다 ‘초점이 갑자기 사라지는’ 순간이 없는지도 봐야 한다. 팝업이 닫혔는데 초점이 어디로 갔는지 알 수 없거나, 어떤 메뉴를 펼쳤다 닫으니 초점이 페이지 맨 위로 튀어버리는 식이다. 이런 ‘초점 미아’가 생기면 키보드 사용자는 ‘내가 지금 어디 있지’ 하고 길을 잃고, 다시 처음부터 Tab을 눌러 위치를 찾아야 한다. 마우스 사용자가 ‘포인터를 잃어버려’ 화면 전체를 헤매는 것과 같은 상황이다. 그래서 팝업이나 메뉴를 닫은 직후 초점이 ‘원래 있던 자리’로 자연스럽게 돌아오는지를, 키보드 점검의 마지막 단계로 확인하자.

■ C. 색에만 기대고 있지 않은가 — 색·대비·구분

C-1. 글자와 배경의 명도 대비가 충분한가? (흐린 회색 글씨, 옅은 배경 위 흰 글씨가 잘 읽히는가?)

→ 자주 보이는 문제: 세련돼 보이려고 글자를 옅은 회색으로 깔아, 시력이 약한 사용자나 밝은 환경에서 글이 안 읽힌다.

C-2. ‘색만으로’ 정보를 구분하고 있지는 않은가? (필수 입력칸을 빨강‘만’으로, 그래프 항목을 색‘만’으로 구분하지 않는가?)

→ 자주 보이는 문제: 필수 항목을 빨간색으로만 표시해, 색을 구분 못 하는 사용자에겐 ‘어디가 필수인지’ 알 수 없다.

C-3. 링크가 본문 글자와 ‘색만으로’ 구분되어 있지는 않은가? (밑줄 등 다른 단서가 함께 있는가?)

→ 자주 보이는 문제: 링크를 색만 다르게 해두고 밑줄을 없애, 색 구분이 어려운 사용자에겐 어디가 클릭되는 글자인지 안 보인다.

C 영역을 점검하는 가장 좋은 방법은 ‘화면을 흑백으로 바꿔보는 것’이다. 운영체제나 브라우저의 흑백(회색조) 모드를 켜고 우리 사이트를 보라. 색을 다 걷어냈을 때도 ‘여기가 필수 항목이구나’ ‘이게 클릭되는 링크구나’ ‘이 그래프에서 이게 우리 항목이구나’가 구분된다면 통과다. 흑백으로 바꾸는 순간 ‘어디가 뭔지’ 알 수 없게 뭉개진다면, 그 사이트는 ‘색이라는 단 하나의 단서’에만 의존하고 있는 거다. 색을 구분하기 어려운 사용자(적지 않은 비율이다)에게는 그 흑백 화면이 곧 평소의 화면이다.

명도 대비는 ‘젊고 시력 좋은 디자이너의 모니터’에서만 괜찮아 보이기 쉽다는 점도 기억하자. 사무실의 좋은 모니터에서 옅은 회색 글씨는 ‘세련돼’ 보이지만, 시력이 약해지기 시작한 사용자나, 햇빛 드는 야외에서 스마트폰을 보는 사용자에겐 ‘안 보이는 글씨’다. 그래서 ‘읽을 수 있느냐’의 기준은 ‘내 모니터에서 내가 보기에’가 아니라 ‘가장 안 좋은 조건의 사용자가 보기에’여야 한다. 글자는 ‘예뻐 보이는 것’보다 ‘읽히는 것’이 먼저다. 접근성에서 대비를 까다롭게 따지는 건, 이게 ‘일부 사용자만의 문제’가 아니라 ‘나이 들면 누구나 겪는 보편적 문제’이기 때문이다.

C 영역이 중요한 이유는, 색에만 기댄 정보 전달이 ‘조용한 차단’이기 때문이다. 대체 텍스트 누락은 ‘아예 안 들리니’ 비교적 티가 나지만, 색만으로 구분한 정보는 ‘보이긴 보이는데 의미만 안 통하는’ 형태라 만든 사람이 문제를 알아채기 어렵다. 만든 사람은 색이 보이니 멀쩡해 보이고, 정작 색을 구분 못 하는 사용자만 조용히 막힌다. 그래서 C 영역은 ‘일부러 색을 빼고 봐야만’ 발견되는, 가장 놓치기 쉬운 접근성 함정이다.

색 문제를 고치는 방법은 의외로 간단하다. ‘색을 빼는’ 게 아니라 ‘색에 단서를 하나 더 보태는’ 것이다. 필수 항목을 빨강으로 표시했다면, 빨강은 그대로 두되 별표(*)나 ‘필수’라는 글자를 함께 붙이면 된다. 링크를 색으로 구분했다면, 색은 그대로 두되 밑줄을 함께 그으면 된다. 그래프 항목을 색으로 나눴다면, 색은 그대로 두되 무늬나 직접 라벨을 함께 넣으면 된다. 핵심은 ‘색이 아니어도 알 수 있는 단서’를 하나 더 얹는 것이다. 이렇게 하면 색을 보는 사람에겐 그대로 보기 좋고, 색을 못 보는 사람에게도 정보가 닿는다. 접근성은 ‘색을 포기하는 것’이 아니라 ‘색에만 기대지 않는 것’이라는 걸 기억하자.

대비 문제도 마찬가지로 ‘과감한 디자인 변경’이 필요한 게 아니다. 옅은 회색 글씨를 ‘조금 더 진하게’만 해도 대부분 해결된다. ‘세련됨’과 ‘읽힘’ 사이에서 한 칸만 ‘읽힘’ 쪽으로 옮기면 되는 일이다. 그리고 이건 일부 사용자만을 위한 양보가 아니다. 대비가 좋은 글씨는 누구에게나, 특히 밝은 야외나 작은 화면에서 더 잘 읽힌다. 접근성을 위한 개선이 결국 ‘모든 사용자의 편의’로 돌아오는 대표적인 예가 바로 이 대비다.

■ D. 헷갈리지 않게 안내하는가 — 라벨·오류·구조

D-1. 모든 입력칸에 ‘바깥에 붙은 라벨’이 있는가? (칸 안의 흐린 안내문만 있지 않은가?)

→ 자주 보이는 문제: 라벨 없이 칸 안 흐린 글씨로만 ‘이름을 입력하세요’를 띄워, 입력을 시작하면 그 안내가 사라져 무슨 칸인지 헷갈린다. 화면 낭독기는 이런 칸을 ‘이름 없는 입력칸’으로 읽는다.

D-2. 폼을 잘못 채웠을 때, ‘어느 칸이, 왜 틀렸고, 어떻게 고치라’고 그 칸 옆에 알려주는가?

→ 자주 보이는 문제: 화면 맨 위에 빨간 한 줄(“입력을 확인하세요”)만 뜨고, 정작 어느 칸이 문제인지 안 알려준다. 낭독기 사용자는 오류가 났다는 사실조차 모를 수 있다.

D-3. 제목(헤딩)이 ‘크게 보이게’가 아니라 ‘제목으로’ 표시되어 있는가? (제목 단계가 1→2→3 순서대로인가?)

→ 자주 보이는 문제: 제목을 그냥 ‘큰 글씨’로만 만들어, 낭독기 사용자가 ‘제목으로 건너뛰며 훑기’를 할 수 없다. 긴 페이지를 처음부터 끝까지 다 들어야 한다.

D-4. 페이지마다 제목(브라우저 탭에 뜨는 제목)이 그 페이지 내용을 제대로 나타내는가?

→ 자주 보이는 문제: 모든 페이지 제목이 똑같이 ‘기관 홈페이지’라, 여러 탭을 열어둔 낭독기 사용자가 어느 탭이 뭔지 구분 못 한다.

D 영역은 ‘낭독기 사용자가 페이지를 어떻게 훑는가’를 떠올리면 이해가 쉽다. 눈으로 보는 사람은 한 화면을 ‘쓱’ 훑어 제목과 구조를 파악하지만, 낭독기 사용자는 그게 안 된다. 대신 ‘제목만 건너뛰며 듣기’, ‘입력칸만 모아 듣기’ 같은 방식으로 페이지의 뼈대를 파악한다. 그런데 제목이 ‘제목으로’ 표시돼 있지 않고 그냥 큰 글씨일 뿐이면, 이 ‘건너뛰며 훑기’가 작동하지 않는다. 입력칸에 제대로 된 라벨이 없으면, ‘입력칸만 모아 듣기’를 해도 ‘편집창, 편집창, 편집창’만 들린다. 그래서 D 영역은 ‘보이는 모양’이 아니라 ‘구조가 코드에 제대로 박혀 있는가’를 묻는다.

D 영역을 점검하는 실전 요령은 ‘일부러 틀려보기’와 ‘구조로 훑어보기’ 두 가지다. 먼저 폼에서 필수 칸을 비우고 제출해보라. 그때 오류가 ‘어느 칸이 왜 틀렸는지’를 그 칸 옆에서 알려주면 통과, ‘맨 위 빨간 한 줄’만 뜨면 아니오다. 다음으로, 화면 낭독기의 ‘제목 목록’ 기능을 써보라. 페이지의 제목들이 1→2→3 단계로 짜임새 있게 나오면 통과, 제목이 아예 안 잡히거나 단계가 엉켜 있으면 아니오다. 이 두 가지만 해봐도 D 영역의 핵심은 거의 다 짚인다.

D 영역이 중요한 이유는, 이게 ‘정보를 못 받는’ 문제를 넘어 ‘서비스를 못 끝내는’ 문제로 직결되기 때문이다. 라벨 없는 폼, 칸 옆에 안 붙는 오류 안내는 곧 ‘신청을 끝까지 못 하는’ 좌절이 된다. 공공 사이트에서 신청을 못 끝낸다는 건 단순한 불편이 아니라 ‘받아야 할 공공 서비스를 못 받는’ 실질적 피해다. 그래서 D 영역의 ‘아니오’는 ‘조금 불친절’이 아니라 ‘서비스 차단’으로 읽어야 한다.

D 영역에서 특히 강조하고 싶은 게 ‘라벨과 입력칸의 연결’이다. 눈으로 보면 칸 위에 ‘이름’이라는 글자가 떠 있으니 ‘라벨이 있네’ 싶지만, 그 글자가 단순히 칸 위에 ‘놓여’ 있는 것과, 코드 차원에서 그 입력칸과 ‘묶여’ 있는 것은 전혀 다르다. 제대로 묶여 있으면 낭독기가 그 칸에 도착했을 때 ‘이름, 편집창’이라고 읽어주고, 라벨 글자를 눌러도 칸으로 초점이 들어간다. 묶여 있지 않으면 보기엔 똑같아도 낭독기는 ‘편집창’이라고만 읽는다. 이건 눈으로는 구분이 안 되니, 라벨 글자를 마우스로 ‘클릭’해보는 게 빠른 점검법이다. 라벨을 눌렀는데 해당 입력칸으로 커서가 들어가면 제대로 연결된 것이고, 아무 반응이 없으면 ‘보이기만 하는 라벨’이다.

오류 안내에 관해서도 한 가지 더. 좋은 오류 안내는 ‘세 가지’를 갖춘다. 어느 칸인지(위치), 왜 틀렸는지(이유), 어떻게 고치는지(방법)다. ‘입력을 확인하세요’는 셋 다 없다. ‘이메일 형식이 올바르지 않습니다’는 이유만 있다. ‘이메일 칸: @를 포함한 주소를 입력해 주세요’는 위치·이유·방법이 다 들어 있다. 그리고 이 안내가 ‘그 칸 바로 옆에’ 떠야 하고, 낭독기 사용자에게도 ‘오류가 났다’는 사실이 즉시 전달돼야 한다. 폼을 일부러 틀려 제출했을 때, 우리 사이트의 오류 안내가 이 셋을 갖추고 있는지, 그리고 그게 칸 옆에 붙는지를 확인하자.

■ E. 영상·문서·모바일까지 챙기는가 — 멀티미디어와 운영

E-1. 사이트에 올린 영상에 자막(또는 대본)이 있는가?

→ 자주 보이는 문제: 정책 설명, 행사 안내 영상에 자막이 없어, 듣지 못하는 사용자는 내용을 전혀 알 수 없다.

E-2. 음성·소리로만 전달되는 정보에 글로 된 대안이 있는가?

→ 자주 보이는 문제: 안내 음성만 있고 글 안내가 없어, 소리를 못 듣는 환경·사용자에게 정보가 닿지 않는다.

E-3. 첨부 문서(PDF 등)가 ‘읽을 수 있는’ 형태인가? (이미지를 스캔해 붙인 ‘그림 PDF’는 아닌가?)

→ 자주 보이는 문제: 공문서를 스캔한 이미지 PDF라 낭독기로는 한 글자도 안 읽힌다. 보이는 사람만 읽을 수 있는 ‘그림’이 되어버린다.

E-4. 모바일에서 글자를 키워도(확대해도) 내용이 잘리거나 겹치지 않는가? 터치 버튼이 누르기에 충분히 큰가?

→ 자주 보이는 문제: 글자를 키우면 레이아웃이 깨져 버튼이 화면 밖으로 나가거나, 버튼이 너무 작고 붙어 있어 옆 버튼이 잘못 눌린다.

E 영역은 ‘텍스트 페이지 너머의 콘텐츠’를 챙기는 묶음이다. 접근성 점검을 할 때 사람들은 보통 ‘페이지의 글과 버튼’만 보고, 영상·음성·첨부 문서는 깜빡 잊는다. 하지만 공공 사이트에서 정작 ‘핵심 정보’가 영상이나 PDF에 들어 있는 경우가 많다. 정책 브리핑 영상, 신청 서식 PDF, 안내 책자 — 이런 것들이 접근 불가능하면, 사이트 본문은 멀쩡해도 ‘정작 중요한 알맹이’가 막힌 셈이다. 특히 ‘스캔한 이미지 PDF’는 공공 사이트의 단골 함정이다. 종이 문서를 그대로 찍어 올리면 보는 사람에겐 똑같아 보이지만, 낭독기에는 ‘한 글자도 없는 그림’이다.

E 영역을 점검하는 방법은 단순하다. 영상이 있으면 ‘소리를 끄고’ 봐서 자막만으로 내용이 따라가지는지 확인하고, 첨부 PDF가 있으면 그 안의 글자를 마우스로 ‘드래그해 선택’해보라. 글자가 블록으로 선택되면 ‘읽을 수 있는 문서’, 그림처럼 통째로 잡히거나 선택이 안 되면 ‘그림 PDF’다. 모바일은 글자 크기를 키운 상태로 핵심 페이지를 열어, 레이아웃이 깨지지 않고 버튼이 화면 안에 잘 들어오는지, 버튼끼리 너무 붙어 있지 않은지를 본다. 이 세 가지만 해도 E 영역의 큰 구멍은 대부분 드러난다.

E 영역이 중요한 이유는, 이게 ‘접근성은 한 번 잡으면 끝’이라는 착각을 깨주기 때문이다. 본문 구조는 한 번 잘 잡아두면 오래가지만, 영상·문서·콘텐츠는 ‘매일 새로 올라온다’. 오늘 자막을 잘 단 운영자가 내일 바쁘면 자막 없는 영상을 올린다. 그래서 E 영역은 ‘점검 항목’이라기보다 ‘운영 습관’에 가깝다. 콘텐츠를 올릴 때마다 ‘이게 못 보는·못 듣는 사람에게도 닿는가’를 한 번씩 떠올리는 습관 — 그게 접근성을 ‘유지’하는 진짜 비결이다.

모바일 항목(E-4)은 따로 한 번 더 짚을 만하다. 요즘 공공 사이트 방문의 상당수가 스마트폰에서 일어난다. 그런데 접근성 점검은 자꾸 ‘데스크탑 화면’에서만 이뤄지곤 한다. 모바일에는 모바일만의 접근성 함정이 있다. 글자를 키우는 사용자가 많은데(나이가 들수록 더), 글자를 키웠을 때 버튼이 화면 밖으로 밀려나거나 글자끼리 겹치면 그 페이지는 ‘못 쓰는 페이지’가 된다. 또 손이 떨리거나 화면을 정확히 못 누르는 사용자에게 작고 다닥다닥 붙은 버튼은 ‘오작동 지뢰밭’이다. 그러니 모바일에서 우리 사이트를 열어, 시스템 설정으로 글자 크기를 한두 단계 키운 뒤 핵심 페이지가 깨지지 않는지, 버튼이 손가락으로 편하게 눌릴 만큼 크고 충분히 떨어져 있는지를 꼭 확인하자.

E 영역을 마치며 한 가지 마음가짐을 권한다. ‘이미 올라간 콘텐츠를 다 고치자’가 아니라 ‘앞으로 올리는 것부터 지키자’로 시작하는 것이다. 수년간 쌓인 영상·문서를 전부 손보는 건 현실적으로 어렵다. 하지만 ‘오늘부터 올리는 영상엔 자막을, 문서는 읽을 수 있는 형태로, 이미지엔 설명을’ 지키기 시작하면, 시간이 지날수록 ‘접근 가능한 콘텐츠’의 비중이 자연히 늘어난다. 그러면서 사용량이 많은 옛 콘텐츠부터 틈틈이 정비하면 된다. 접근성은 ‘한 번에 완벽하게’가 아니라 ‘오늘부터 꾸준히’가 정답인 영역이다.

본론 3 — 결과를 어떻게 읽고 무엇부터 고칠까

■ ‘아니오’에 우선순위를 매기는 법

다섯 묶음을 다 봤다면, 손에 ‘아니오’가 몇 개 쥐어져 있을 거다. 여기서 흔히 하는 실수가 ‘아니오 개수를 세서 점수처럼 매기는’ 것이다. 하지만 접근성에서 ‘아니오 5개’가 다 같은 무게는 아니다. 어떤 ‘아니오’는 한 명을 살짝 불편하게 하고, 어떤 ‘아니오’는 특정 부류의 사용자 전체를 ‘아예 못 쓰게’ 만든다. 그래서 개수보다 ‘영향의 크기’로 줄을 세워야 한다.

우선순위를 매기는 간단한 기준은 두 가지다. 첫째, ‘이걸 어기면 그 기능을 아예 못 쓰는가, 아니면 불편할 뿐 쓸 수는 있는가’. 키보드로 신청 폼을 끝까지 못 채우는 문제(B)나, 핵심 안내가 자막·대체텍스트 없이 영상·이미지에만 있는 문제(A·E)는 ‘아예 못 쓰는’ 쪽이라 최우선이다. 반면 명도 대비가 ‘조금’ 모자란 정도는 ‘읽기 불편하지만 가능’한 쪽이라 그다음이다. 둘째, ‘얼마나 많은 페이지에 퍼져 있는가’. 모든 페이지에 공통으로 깔린 메뉴·헤더·푸터의 문제는 한 번 고치면 사이트 전체가 좋아지니, 가성비가 가장 높다.

이 두 기준을 ‘사용자의 관점’으로 바꿔 말하면 이렇다. 첫 번째 기준은 ‘이 문제 때문에 누군가는 우리 서비스를 아예 이용할 수 없게 되는가’를 묻는 것이고, 두 번째 기준은 ‘그 차단이 우리 사이트의 한 귀퉁이가 아니라 사이트 전체에 걸쳐 있는가’를 묻는 것이다. 두 질문에 모두 ‘그렇다’가 나오는 항목은, 곧 ‘우리 사이트를 통째로 못 쓰는 사용자 집단을 만들고 있는’ 가장 심각한 문제다. 이런 항목은 점수 몇 점의 문제가 아니라, 공공기관이 ‘일부 국민을 서비스에서 배제하고 있다’는 무거운 의미를 갖는다. 그래서 우선순위의 맨 윗자리는 늘 ‘넓고 깊게 막는 것’의 차지여야 한다.

이 두 기준을 겹쳐 보면 자연스럽게 ‘가장 먼저 고칠 것’이 떠오른다. ‘아예 못 쓰게 만들면서, 모든 페이지에 깔린’ 문제 — 예를 들어 전 페이지 공통 메뉴가 키보드로 안 열린다거나, 모든 페이지의 제목이 똑같다거나 하는 것 — 이 최우선이다. 반대로 ‘특정 한 페이지에서, 살짝 불편한’ 문제는 뒤로 미뤄도 된다. 접근성 개선도 결국 ‘한정된 시간과 인력’으로 하는 일이라, ‘가장 많은 사람을, 가장 크게 막는 것’부터 손대는 게 정답이다.

여기에 ‘고치는 난이도’라는 세 번째 기준을 살짝 얹으면 우선순위가 더 또렷해진다. 같은 영향·같은 범위라면, ‘쉽게 고칠 수 있는 것’을 먼저 처리하는 게 합리적이다. 예를 들어 메인 배너의 대체 텍스트를 채우는 일이나, 초점 테두리를 다시 살리는 일은 비교적 손이 적게 가면서 효과는 크다. 이런 ‘영향 크고 손쉬운’ 항목을 먼저 처리해 빠른 성과를 내면, 조직 안에서 ‘접근성 개선이 별일 아니구나, 해볼 만하구나’라는 분위기가 생긴다. 그 작은 성공이 ‘구조를 바꿔야 하는 어려운 항목’으로 나아갈 동력이 된다. 반대로 처음부터 가장 어려운 것에 매달리면 진이 빠져 흐지부지되기 쉽다. 그래서 ‘영향·범위·난이도’ 세 가지를 함께 놓고, ‘영향 크고 범위 넓으며 비교적 쉬운 것’부터 손대는 순서를 권한다.

마지막으로, 우선순위를 매겼다고 ‘나머지는 안 해도 된다’는 뜻은 아니라는 걸 분명히 하자. 우선순위는 ‘무엇을 버릴지’가 아니라 ‘무엇을 먼저 할지’의 문제다. 접근성에서 ‘이 정도 불편은 괜찮겠지’ 하고 영영 미뤄둔 항목이, 누군가에게는 매일의 벽일 수 있다. 그러니 급한 것부터 처리하되, 나머지도 ‘언젠가는 할 일’로 목록에 남겨두자. 점검 결과를 한 장의 표로 정리해 ‘급함·중간·나중’으로 칸을 나눠두면, 이번에 못 한 것을 다음 분기에 자연스럽게 이어갈 수 있다.

■ ‘기록’이 점검을 완성한다

점검을 마쳤다면, ‘아니오’ 옆에 한 줄짜리 메모를 꼭 남기자. ‘B-2 아니오 — Tab으로 다닐 때 초점 테두리가 안 보임’, ‘A-1 아니오 — 메인 배너 3개 모두 대체 텍스트 없음’처럼. 이 한 줄이 나중에 개발 외주나 콘텐츠 담당에게 넘길 ‘작업 지시서’가 된다. 점검만 하고 무엇이 문제였는지 적어두지 않으면, 며칠만 지나도 ‘분명 아니오가 많았는데 뭐였더라’가 된다. 접근성 점검의 가치는 ‘발견’이 아니라 ‘기록’에서 완성된다.

그리고 이 기록은 ‘추세’를 만들 때 비로소 빛난다. 분기에 한 번씩 같은 체크리스트로 다시 점검하고 그때마다 결과를 남겨두면, 우리 사이트의 접근성이 좋아지고 있는지 나빠지고 있는지가 한눈에 보인다. 접근성은 콘텐츠가 쌓이면서 조용히 무너지는 영역이라, 이 ‘추세 관리’가 특히 중요하다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다.

■ 자가 체크의 한계, 그리고 그다음

여기까지 따라왔다면 분명 느꼈을 거다. 이 체크리스트로 ‘큰 벽’은 찾을 수 있지만, KWCAG 33개 항목 전부를 사람 눈으로 빠짐없이 따지는 건 불가능하다는 걸. 화면 낭독 순서가 코드 차원에서 정확히 맞는지, 명도 대비가 기준 수치를 정확히 넘는지, 모든 입력칸의 라벨이 코드상 제대로 연결돼 있는지 — 이런 ‘정밀한 검증’은 사람 손으로 하면 시간도 오래 걸리고, 무엇보다 빠뜨리기 쉽다. 페이지가 수십, 수백 개인 공공 사이트라면 더더욱.

그래서 자가 체크로 ‘우리 사이트에 접근성 벽이 있다’는 걸 확인했다면, 그다음은 ‘빠짐없이, 정확하게’ 따지는 단계로 넘어가야 한다. 바로 여기서 자동 검사 도구가 필요하다. 자가 체크가 ‘몇 개의 핵심 흐름을 사람이 깊게’ 보는 것이라면, 자동 검사는 ‘모든 페이지의 모든 요소를 기계가 빠짐없이’ 훑는 것이다. 둘은 경쟁 관계가 아니라 짝꿍이다.

본론 4 — 자동 검사는 어디까지 해주나 (ViewCheck 소개)

■ 사람이 못 하는 ‘전수 점검’을 기계에 맡기기

자가 체크의 가장 큰 한계는 ‘범위’다. 사람은 기껏해야 핵심 페이지 몇 개, 핵심 흐름 한두 개를 깊게 볼 수 있을 뿐이다. 하지만 공공 사이트는 메인 한 페이지가 아니라 수십, 수백 개의 페이지로 이뤄져 있고, 접근성 문제는 ‘하필 내가 안 본 그 페이지’에 숨어 있곤 한다. 그래서 ‘우리 사이트 전체의 접근성’을 제대로 알려면, 결국 ‘모든 페이지를 빠짐없이’ 훑는 도구가 필요하다.

우리가 만든 ViewCheck(뷰체크)가 바로 그 일을 한다. URL 하나만 넣으면 사이트의 여러 페이지를 자동으로 돌며, 웹 접근성(KWCAG)을 포함한 여러 영역을 한 번에 점검한다. 그것도 한두 페이지가 아니라 수십, 수백 페이지를 함께 본다. 사람이 ‘핵심 몇 개’를 깊게 봤다면, ViewCheck는 ‘전체를 빠짐없이’ 훑어 ‘어느 페이지의 어떤 요소가 어떤 접근성 항목을 어겼는지’를 목록으로 정리해준다. 오늘 자가 체크에서 ‘우리 메인은 괜찮던데’ 했더라도, 깊숙한 신청 페이지나 오래된 게시판에서 문제가 숨어 있을 수 있는데, 그런 ‘안 본 곳’까지 기계가 대신 확인해주는 것이다.

이 ‘여러 페이지를 함께 본다’는 점이 생각보다 중요하다. 접근성 문제는 보통 ‘한 페이지에만 있는 특이한 결함’이 아니라, 사이트 전체에 같은 방식으로 반복되는 ‘패턴’으로 나타난다. 예컨대 ‘모든 게시판 글의 첨부 이미지에 대체 텍스트가 없다’거나, ‘모든 신청 폼에서 오류 안내가 칸 옆에 안 붙는다’거나 하는 식이다. 한 페이지만 봐서는 그게 ‘우연한 누락’인지 ‘구조적 패턴’인지 알 수 없지만, 수십 페이지를 한꺼번에 보면 ‘아, 이건 사이트 전체에 깔린 같은 문제구나’가 보인다. 그리고 패턴으로 드러난 문제는 ‘한 번에 고치면 모든 페이지가 함께 좋아지는’, 가장 가성비 높은 개선 지점이 된다. 사람의 자가 체크가 잡아내기 가장 어려운 게 바로 이 ‘전체 패턴’인데, 도구는 그걸 가장 잘한다.

■ 접근성만이 아니라 ‘품질 전체’를 함께 본다

ViewCheck는 웹 접근성만 보는 도구가 아니다. 행정안전부의 「전자정부 웹사이트 품질관리 지침」이 정한 7대 영역, 즉 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성을 두루 점검한다. 접근성은 그중 한 축이고, 오늘 다룬 KWCAG 33항목이 바로 이 접근성 영역의 핵심 기준이다. 사이트 품질이라는 게 결국 ‘얼마나 많은 사람이, 얼마나 안정적이고 편하게 쓸 수 있는가’의 문제라, 접근성은 다른 영역들과 떼어놓고 볼 수 없다. 접근성이 좋은 사이트는 대개 구조가 깔끔하고, 구조가 깔끔하면 다른 품질 지표도 함께 좋아지는 경향이 있다.

여기에 더해 ViewCheck는 KRDS(공공 디자인 시스템)의 846개 규칙으로 사이트의 디자인·구조를 정밀하게 따진다. 이 846개는 그냥 한 덩어리가 아니라 네 갈래로 나뉜다. 색·글꼴·간격 같은 기초를 보는 DS 120개, 버튼·입력칸·메뉴 같은 부품을 보는 CP 446개, 신청·검색·오류 같은 흐름을 보는 BP 108개, 그리고 로그인·신청·정책 같은 서비스 패턴을 보는 SP 172개다. 오늘 자가 체크에서 우리가 ‘대충 눈으로’ 본 항목들을, ViewCheck는 이 846개 규칙으로 ‘정확한 수치와 근거를 들어’ 판정한다. 사람이 ‘이 버튼 좀 안 보이는데’ 한 것을, 도구는 ‘이 요소가 어떤 규칙을 어겼고 왜 문제인지’로 바꿔준다.

■ 결과는 ‘읽을 수 있게’ 나온다

자동 검사의 흔한 문제는 ‘결과가 너무 어렵다’는 것이다. 빨간 숫자와 코드 위치만 잔뜩 나오면, 정작 담당자는 ‘그래서 뭘 하라는 거지’에서 막힌다. ViewCheck는 분석이 끝나면 화면 상단에 점수 카드를 먼저 보여준다. 접근성을 비롯한 각 영역이 지금 몇 점인지, 어디가 가장 급한지를 한눈에 잡을 수 있게 정리한 카드다. 오늘 우리가 손으로 ‘아니오’에 우선순위를 매긴 그 작업을, 도구가 ‘수치와 순위’로 대신 해주는 셈이다. 그래서 자가 체크로 ‘감’을 잡은 담당자가 이 결과를 보면, 숫자가 그냥 숫자가 아니라 ‘아, 내가 아까 막혔던 그게 이 항목이구나’로 또렷이 읽힌다.

오늘 글의 흐름을 다시 떠올려보자. 우리는 마우스를 떼고 키보드로 다녀봤고, 화면을 흑백으로 바꿔봤고, 이미지를 가린 채 페이지를 들어봤다. 그렇게 ‘몸으로’ 접근성을 한번 겪고 나면, 자동 검사 결과지의 모든 항목이 살아 움직인다. 자가 체크는 ‘이해’를 주고, 자동 검사는 ‘범위와 정확도’를 준다. 이 둘을 함께 쓸 때, 비로소 ‘우리 사이트가 모두에게 열려 있는가’라는 질문에 제대로 답할 수 있다.

그리고 이 결과는 ‘혼자 보고 끝’이 아니라 ‘함께 보고 움직이는’ 자료로 쓸 때 진가가 난다. 접근성 개선은 콘텐츠 담당, 개발 외주, 그리고 결재 라인이 함께 움직여야 가능한 일이다. 그런데 ‘우리 사이트 접근성이 좀 부족한 것 같습니다’라는 막연한 말로는 예산도 인력도 붙지 않는다. 반면 ‘전체 ○○개 페이지 중 접근성 점수가 기준 미달인 페이지가 이만큼이고, 그중 가장 많이 반복되는 문제가 무엇이며, 그게 어떤 사용자를 막고 있다’는 구체적인 자료가 손에 있으면, 막연한 걱정이 ‘실행 가능한 안건’으로 바뀐다. 도구가 정리해준 점수 카드와 문제 목록은, 그 자체로 ‘윗선을 설득하는 보고서’이자 ‘외주에 건네는 작업 지시서’가 된다. 오늘 손으로 한 자가 체크가 ‘나의 이해’를 만들었다면, 자동 검사 결과는 ‘조직을 움직이는 근거’를 만든다.

마무리

오늘 우리는 ‘접근성 의무 최소 체크리스트’를 다섯 묶음으로 따라가 봤다. 잠깐 정리해보자.

A에서는 ‘보이지 않아도 읽히는가’를 봤다. 이미지를 가리고 페이지를 읽어, 대체 텍스트가 빠진 곳을 찾았다. B에서는 ‘마우스 없이도 쓸 수 있는가’를 봤다. 마우스를 떼고 키보드만으로 다녀, 초점 표시가 없거나 키보드로 막히는 곳을 찾았다. C에서는 ‘색에만 기대고 있지 않은가’를 봤다. 화면을 흑백으로 바꿔, 색만으로 구분한 정보와 흐린 글씨를 찾았다. D에서는 ‘헷갈리지 않게 안내하는가’를 봤다. 일부러 폼을 틀려보고 제목 구조를 훑어, 라벨·오류·구조의 구멍을 찾았다. E에서는 ‘영상·문서·모바일까지 챙기는가’를 봤다. 소리를 끄고 영상을 보고, PDF 글자를 드래그해보고, 모바일에서 글자를 키워, 콘텐츠 차원의 벽을 찾았다.

이 다섯을 관통하는 한 가지 마음은 ‘그 도구 없이는 못 쓰는 사람의 자리에 서보는 것’이었다. 접근성은 어려운 코드의 문제이기 전에, 그 자리에 서보려는 마음의 문제다. 그리고 공공 사이트에서 그 마음은 ‘있으면 좋은 미덕’이 아니라 ‘반드시 지켜야 할 의무’다. 우리가 무심코 빠뜨린 대체 텍스트 한 줄, 없애버린 초점 테두리 하나, 색만으로 표시한 필수 항목 하나가, 누군가에게는 ‘공공 서비스를 못 받는 벽’이 된다는 걸 기억하면, 이 점검은 ‘귀찮은 일’이 아니라 ‘당연히 해야 하는 일’이 된다.

한 가지 덧붙이고 싶은 건, 접근성을 챙기다 보면 ‘장애가 있는 사용자만을 위한 일’이 아니라는 걸 알게 된다는 점이다. 키보드로도 잘 되는 사이트는 마우스가 고장 난 사람에게도, 노트북 터치패드가 불편한 사람에게도 편하다. 대비가 좋은 글씨는 햇빛 드는 야외에서 스마트폰을 보는 모든 사람에게 잘 읽힌다. 자막이 달린 영상은 조용한 사무실에서 소리 없이 보는 사람에게도 유용하다. 접근성을 위해 한 일이 결국 ‘모든 사용자의 편의’로 돌아온다. 그래서 접근성을 ‘일부를 위한 양보’가 아니라 ‘모두를 위한 기본기’로 보는 게 맞다.

다만 솔직하게 다시 짚자. 오늘 체크리스트는 ‘시작’이지 ‘끝’이 아니다. 이걸로 큰 벽은 찾을 수 있지만, KWCAG 33항목 전부를, 수백 페이지에 걸쳐, 빠짐없이 정확하게 따지는 건 사람 손으로는 무리다. 그래서 자가 체크로 ‘우리 사이트에 벽이 있다’는 걸 확인했다면, 그다음은 도구의 힘을 빌릴 차례다.

ViewCheck는 그 ‘다음 단계’를 가장 쉽게 시작하도록 돕는다. krds.viewcheck.co.kr 에 들어가 우리 기관 사이트 주소를 넣으면, 웹 접근성(KWCAG)을 포함한 여러 영역을 자동으로 진단해 ‘어느 페이지의 무엇이 어떤 기준을 어겼는지’를 점수 카드와 함께 정리해준다. 오늘 손으로 찾은 ‘아니오’들이 도구의 결과와 얼마나 겹치는지, 그리고 내가 미처 못 본 페이지엔 또 어떤 벽이 숨어 있는지 직접 확인해보길 권한다. 손으로 한번 겪어본 사람에게는, 그 결과지가 그냥 숫자가 아니라 ‘우리 사이트를 모두에게 여는 지도’로 읽힐 것이다.

접근성은 거창한 개편으로 한 번에 끝내는 일이 아니다. 오늘처럼 5분짜리 점검을 분기마다 반복하고, 콘텐츠를 올릴 때마다 ‘이게 못 보는·못 듣는 사람에게도 닿는가’를 한 번씩 떠올리고, 큰 벽은 도구로 빠짐없이 잡아내는 — 그 작은 습관들이 쌓여 사이트는 서서히 ‘모두의 것’이 된다. 그 첫걸음을, 오늘 이 체크리스트로 떼어보자. 다음 주에는 또 다른 주제로 찾아오겠다. 오늘도 끝까지 읽어줘서 고맙다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #전자정부 #접근성의무 #웹표준 #장애인접근성 #공공사이트 #UX #디지털포용 #ViewCheck