핵심 5항목 점검 체크리스트

공감·문제제기

이번 주 월요일엔 웹 접근성이 왜 ‘법으로 정해진 의무’이면서 동시에 ‘좋은 서비스의 기본’인지를 이야기했고, 수요일엔 접근성을 무시한 사이트가 실제로 어떤 사람들을 어떻게 밀어내는지를 다뤘다. 오늘은 가장 손에 잡히는 이야기다. ‘우리 사이트가 접근성 기준에서 어디가 걸리는지’를 담당자가 직접, 도구 없이도 빠르게 점검할 수 있는 핵심 5항목 체크리스트다.

먼저 솔직하게 털어놓자. 웹 접근성 한국형 지침(KWCAG)은 33개 항목으로 되어 있다. 33개를 다 외워서 하나하나 따지라고 하면, 솔직히 나라도 도망가고 싶다. 현장 담당자에게 33개 항목 표를 들이밀면 십중팔구 ‘이걸 언제 다 보냐’며 그대로 서랍에 넣어버린다. 그래서 오늘은 욕심을 버렸다. 33개 전부가 아니라, ‘가장 많은 사람에게 영향을 주고, 가장 자주 걸리고, 그러면서도 비전문가가 눈과 손으로 직접 확인할 수 있는’ 다섯 개만 추렸다. 이 다섯 개만 제대로 봐도 우리 사이트 접근성의 8할은 가늠이 된다.

왜 ‘접근성은 개발자가 알아서 하는 거 아니냐’는 말이 틀렸는지부터 짚자. 접근성은 코드만의 문제가 아니다. 이미지를 올리는 콘텐츠 담당자가 대체 텍스트 한 줄을 안 적으면, 아무리 코드가 완벽해도 그 이미지는 시각장애인에게 ‘이미지’라는 단어조차 전해지지 않는다. 영상을 올리는 담당자가 자막을 빼먹으면, 청각장애인에게 그 영상은 ‘소리 없는 화면’일 뿐이다. 양식을 기획하는 담당자가 라벨을 빠뜨리면, 화면을 못 보는 사용자는 빈칸 앞에서 ‘여기 뭘 적으라는 거지’ 하고 멈춘다. 접근성은 사이트에 손을 대는 모든 사람이 조금씩 만들거나 망가뜨리는 것이다. 그래서 개발자만의 일이 아니라 ‘모두의 일’이다.

게다가 이건 ‘착한 일’이기 이전에 ‘해야 하는 일’이다. 공공기관 웹사이트의 접근성은 권고가 아니라 의무다. 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성) 중에서도 접근성은 가장 무게가 실린 영역이고, 미흡하면 감리나 실태조사에서 바로 지적이 들어온다. 그런데 정작 현장에서는 ‘접근성을 챙겨야 한다는 건 아는데, 구체적으로 뭘 어떻게 보라는 건지 모르겠다’는 막막함이 가장 크다. 오늘 글은 바로 그 막막함을 깨는 데 초점을 맞췄다. 거창한 이론 말고, ‘지금 우리 사이트 열어서 이렇게 해보세요’라는 동작 단위로 풀어간다.

이 점검의 또 다른 매력은 ‘공짜’라는 점이다. 비싼 도구를 사거나 외부 컨설팅을 부르기 전에, 지금 당장 5분이면 시작할 수 있다. 결재도, 예산도, 누구의 허락도 필요 없다. 그저 우리 사이트를 ‘잘 안 보이는 사람, 잘 안 들리는 사람, 마우스를 못 쓰는 사람’의 입장에서 한 바퀴 돌아보는 것뿐이다. 거창한 개편 계획을 세우기 전에, 먼저 ‘지금 어떤 상태인지’ 아는 것 — 모든 개선은 거기서 출발한다. 그리고 그 출발점을 찍는 데는 전문 지식보다 ‘사용자의 처지를 상상하는 마음’이 훨씬 중요하다.

준비물은 단출하다. 우리 기관 사이트, 키보드, 그리고 약간의 상상력. 가능하면 스마트폰도 곁에 두자. 데스크탑과 모바일에서 접근성 양상이 꽤 다르기 때문이다. 펜과 종이(혹은 메모 앱)에 항목마다 ‘예/아니오’를 적고, ‘아니오’ 옆엔 한 줄짜리 메모를 남기면서 따라오면 된다. 이 메모가 나중에 ‘무엇을 고쳐야 하는지’ 정확히 짚어주는 작업 지시서가 된다.

마음가짐 하나만 다잡고 시작하자. 이건 ‘시험’이 아니라 ‘건강검진’이다. 시험이라면 좋은 점수가 목적이지만, 검진은 ‘어디가 안 좋은지 찾아내는 것’이 목적이다. 그러니 ‘아니오’가 많이 나올수록 오히려 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 그만큼 확보했다는 뜻이고, 사이트가 좋아질 여지가 그만큼 크다는 뜻이다. 반대로 모든 항목에 ‘예’를 적고 있다면, 점검이 잘된 게 아니라 ‘너무 후하게 보고 있는’ 건 아닌지 의심해야 한다. 좋은 점검자는 자기 사이트에 엄격하다. 이 글을 따라오는 동안만큼은, 우리 사이트를 ‘처음 온 까다로운 사용자’, 그것도 ‘잘 안 보이고 잘 안 들리는 사용자’의 눈으로 봐주길 바란다.

한 가지 더 당부하자면, 점검할 때는 ‘만든 사람’의 마음이 아니라 ‘쓰는 사람’의 마음으로 봐야 한다. 우리는 우리 사이트를 너무 잘 안다. 어느 메뉴가 어디 있는지, 신청 버튼이 어느 구석에 숨어 있는지 다 외우고 있어서 ‘이 정도면 알아보겠지’ 하고 넘기기 쉽다. 하지만 처음 방문한 사용자, 그것도 화면을 못 보거나 마우스를 못 쓰는 사용자는 아무것도 모른다. 그 사람의 처지에서 봐야 진짜 문제가 보인다. 접근성 점검이 유독 어려운 건, 이 ‘남의 처지로 보기’가 핵심이기 때문이다. 눈이 멀쩡하고 손이 자유로운 우리에게 ‘안 보이고 안 들리고 손이 안 닿는’ 상황은 상상의 영역이라, 의식적으로 그 처지를 흉내 내봐야 한다. 그래서 오늘 점검법은 ‘소리를 끄고’, ‘마우스를 떼고’, ‘화면을 흑백으로 바꾸고’처럼 일부러 우리 감각의 일부를 막아보는 방식이 많다. 잠깐이라도 그 불편을 직접 겪어봐야, 매일 그 불편 속에서 우리 사이트를 마주하는 사용자들의 처지가 비로소 손에 잡힌다.

그리고 솔직히 고백하자면, 나도 처음 접근성을 공부할 때는 ‘이게 그렇게 많은 사람의 문제일까’ 하고 가볍게 봤다. 그런데 통계를 보면 그렇지가 않다. 시각·청각·지체 장애가 있는 분들만 해도 적지 않은 수인데, 거기에 노안이 온 어르신, 손을 다쳐 한동안 마우스를 못 쓰는 사람, 시끄러운 환경이나 소리를 못 키우는 환경에 있는 사람까지 더하면, ‘접근성의 도움을 받는 사람’은 우리가 생각하는 것보다 훨씬 넓다. 게다가 누구나 나이가 들면 눈이 침침해지고 손이 둔해진다. 접근성은 ‘특별한 소수’가 아니라 ‘언젠가의 나’를 포함한 모두를 위한 것이다. 이 사실을 마음에 새기고 점검을 시작하면, 항목 하나하나가 단순한 ‘규정 통과’가 아니라 ‘누군가에게 문을 열어주는 일’로 보이기 시작한다.

본론 1 — 왜 ‘핵심 5’인가, 그리고 무엇을 보나

■ 33개를 다 보지 말고 ‘5개’부터 봐야 하는 이유

“접근성 항목이 33개라며. 그런데 왜 5개만 보라는 거지? 나머지 28개는 안 중요한가?”라는 의문이 들 거다. 당연한 질문이다. 답부터 말하면, 나머지 28개도 중요하다. 하지만 점검에는 순서가 있고, 그 순서를 무시하면 결국 아무것도 못 본다.

첫째, ‘파레토’가 여기서도 통한다. 실제 사용자가 겪는 접근성 불편의 대부분은 소수의 항목에서 반복적으로 발생한다. 대체 텍스트, 키보드 접근, 색 대비, 자막, 입력 라벨 — 이 다섯 군데에서 막히는 사람이 압도적으로 많다. 그래서 이 다섯만 제대로 잡아도 ‘실제로 못 쓰던 사람이 쓸 수 있게 되는’ 비율이 확 올라간다. 나머지 항목은 더 세밀한 마감에 가깝다. 집을 지을 때 비 새는 지붕부터 막고 벽지를 고르듯, 접근성도 ‘아예 못 들어오는’ 문제부터 막는 게 순서다.

둘째, ‘비전문가가 직접 확인 가능한가’를 기준으로 골랐다. 33개 중에는 코드를 뜯어봐야 하거나 보조기기를 실제로 돌려봐야 판정되는 항목도 많다. 그건 도구와 전문가의 몫이다. 반면 오늘의 다섯 개는 마우스를 떼고 키보드만 써보거나, 화면을 흑백으로 바꿔보거나, 이미지에 마우스를 올려보는 정도의 ‘아주 단순한 동작’만으로도 상당 부분 확인된다. 담당자가 ‘내 눈과 손으로’ 확인할 수 있어야 그 결과를 믿고 움직이게 된다. 남이 준 점수표는 잊혀도, 내가 직접 겪은 불편은 잊히지 않는다.

셋째, ‘대화의 출발점’이 된다. 접근성 개선은 혼자 하는 일이 아니다. 콘텐츠팀, 개발팀, 외주 업체, 윗선이 함께 움직여야 한다. 그런데 ‘우리 사이트 접근성이 좀 약한 것 같아요’라는 막연한 말로는 누구도 움직이지 않는다. 반면 ‘제가 직접 점검해봤더니 핵심 5항목 중 대체 텍스트와 키보드 접근에서 아니오가 나왔습니다’라고 하면, 이야기가 구체적인 안건이 된다. 손에 쥔 점검 결과 하나가, 미뤄지던 개선 논의를 시작하게 만드는 방아쇠가 된다.

자가 점검이 ‘정밀 진단’을 대체하는 게 아니라는 점은 분명히 해두자. 둘은 역할이 다르다. 자가 점검은 ‘빠르고 거칠게’ 큰 구멍을 찾는 일이고, 정밀 진단은 ‘느리지만 정확하게’ 33개 전부와 그 너머까지 따지는 일이다. 건강에 빗대면 자가 점검은 ‘요즘 좀 불편한데 어디가 문제지’ 하고 스스로 살펴보는 것이고, 정밀 진단은 병원 정밀 검사다. 둘 다 필요하다. 자가 점검 없이 정밀 진단만 받으면 ‘숫자는 나왔는데 뭘 봐야 할지 모르는’ 상태가 되고, 정밀 진단 없이 자가 점검만 믿으면 ‘눈에 안 보이는 깊은 문제’를 놓친다. 그래서 오늘 글은 ‘핵심 5로 감을 잡고, 그다음 도구로 33개 전부를 확정하라’는 순서를 권한다.

■ 오늘 점검할 핵심 5항목

미리 전체 그림을 펼쳐 두자. 오늘 다룰 다섯은 다음과 같다. 각 항목이 ‘누구를 위한 것인지’를 함께 적어두면 점검할 때 마음가짐이 달라진다.

· 핵심 ① 대체 텍스트(alt) — 화면을 못 보는 사람을 위해, 모든 의미 있는 이미지에 ‘이 이미지가 무엇인지’ 글로 적혀 있는가

· 핵심 ② 키보드 접근 — 마우스를 못 쓰는 사람을 위해, 모든 기능을 키보드만으로 쓸 수 있고 ‘지금 어디에 있는지’ 초점 표시가 보이는가

· 핵심 ③ 색 대비 — 시력이 약하거나 색각이 다른 사람을 위해, 글자와 배경이 충분히 또렷하게 구분되는가

· 핵심 ④ 자막·대체수단 — 소리를 못 듣는 사람을 위해, 영상·음성에 자막이나 글 설명이 제공되는가

· 핵심 ⑤ 입력 라벨·오류 안내 — 화면을 못 보거나 인지가 어려운 사람을 위해, 입력칸마다 무엇을 적는지 알 수 있고 틀렸을 때 친절히 알려주는가

이 다섯을 ‘① 보기 → ② 조작하기 → ③ 구별하기 → ④ 듣기 → ⑤ 입력하기’의 사용자 행동 순서로 배열했다. 사용자가 사이트에 들어와 무언가를 보고, 손으로 조작하고, 화면을 구별하고, 소리를 듣고, 정보를 입력하는 — 그 자연스러운 흐름을 따라가며 ‘각 단계에서 누군가 막히지 않는가’를 점검하는 셈이다. 순서대로 보면 어느 한 단계도 통째로 빼먹지 않게 된다. 특히 ④ 자막과 ⑤ 라벨은 눈에 잘 안 띄어 자꾸 뒤로 밀리는데, 정작 가장 자주 누락되는 게 그 둘이니 끝까지 가는 게 중요하다.

점검할 때 ‘예/아니오’가 애매한 항목이 분명 나올 거다. ‘이게 예인가 아니오인가’ 싶을 땐, 망설이지 말고 ‘아니오’로 적는 걸 권한다. 점검의 목적은 좋은 점수를 받는 게 아니라 ‘고칠 곳을 찾는 것’이기 때문이다. 의심스러우면 사용자 편에 서서 더 엄격하게 보는 게, 결국 사용자에게도 우리에게도 이득이다.

■ 점검 전, ‘세 가지 처지’를 미리 상상해두기

다섯 항목으로 들어가기 전에, 점검 내내 마음에 품고 갈 ‘세 명의 가상 사용자’를 소개하고 싶다. 추상적인 ‘장애인’이 아니라 구체적인 한 사람을 떠올리면, 점검이 훨씬 또렷해진다.

첫째, ‘화면을 못 보는 김 씨’다. 김 씨는 화면 낭독기로 사이트를 ‘듣는다’. 김 씨에게 사이트는 그림이 아니라 ‘위에서 아래로 읽히는 한 줄짜리 목소리’다. 그래서 김 씨를 떠올리면 ‘이 이미지는 소리로 어떻게 들릴까’, ‘이 입력칸은 뭐라고 읽힐까’를 자연스럽게 묻게 된다. 핵심 ①(대체 텍스트)과 ⑤(입력 라벨)가 김 씨를 위한 항목이다.

둘째, ‘마우스를 못 쓰는 이 씨’다. 이 씨는 손 떨림 때문에 마우스를 못 잡고 키보드로만 사이트를 쓴다. 이 씨를 떠올리면 ‘이건 키보드로 되나’, ‘지금 내가 어디 있는지 보이나’를 묻게 된다. 핵심 ②(키보드 접근)가 이 씨를 위한 항목이다.

셋째, ‘잘 안 보이고 안 들리는 박 씨’다. 박 씨는 노안으로 작은 글씨가 흐릿하고, 약간의 난청도 있다. 박 씨는 특별한 보조기기를 쓰진 않지만, 흐린 글씨와 소리 없는 영상 앞에서 매번 답답해한다. 박 씨를 떠올리면 ‘이 글자, 흐릿한 눈으로도 읽힐까’, ‘이 영상, 소리 없이도 알 수 있나’를 묻게 된다. 핵심 ③(색 대비)과 ④(자막)가 박 씨를 위한 항목이다.

이 세 사람 — 김 씨, 이 씨, 박 씨 — 을 점검 내내 어깨 너머에 세워두자. 각 항목을 볼 때마다 ‘이 화면을 이 사람이 만나면 어떨까’를 물으면, ‘예/아니오’의 판단이 한결 분명해진다. 접근성 점검의 비결은 거창한 지식이 아니라, 이렇게 구체적인 ‘한 사람의 처지’를 끝까지 놓지 않는 상상력에 있다.

본론 2 — 핵심 5항목, 하나씩 직접 따라 하기

여기서부터가 본론이다. 각 항목마다 ‘무엇을 보는가 → 어떻게 직접 확인하는가 → 자주 발견되는 문제(익명 사례) → 어떻게 고치는가’를 한 묶음으로 풀어간다. 곁들이는 사례는 전부 익명 처리한 ‘전형’이다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 패턴을 보여주려는 거다. 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 나타난다. 읽으면서 ‘우리도 저런데’ 싶은 게 나와도 자책할 필요 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다.

■ 핵심 ① 대체 텍스트(alt) — ‘보지 않고도 알 수 있는가’

가장 먼저 볼 것은 대체 텍스트다. 화면을 못 보는 사용자는 화면 낭독기(스크린리더)라는 프로그램으로 사이트를 ‘듣는다’. 글자는 낭독기가 소리 내어 읽어준다. 그런데 이미지는? 이미지에 ‘대체 텍스트’가 적혀 있지 않으면, 낭독기는 ‘이미지’ 혹은 파일 이름만 읽거나 아예 건너뛴다. 그 이미지가 ‘이번 달 신청 마감일 안내 포스터’였다면, 화면을 못 보는 사용자에게 그 정보는 통째로 사라진다.

[직접 확인하는 법] 가장 간단한 방법은 ‘이미지가 다 사라진 화면을 상상해보는 것’이다. 우리 사이트의 메인과 주요 안내 페이지를 열고, 화면 속 이미지를 손으로 가려보라. 그 이미지가 가려진 채로도 ‘무슨 내용인지’ 옆의 글만으로 알 수 있으면 다행이다. 만약 핵심 정보가 ‘이미지 안에만’ 들어 있다면 — 예컨대 마감일, 신청 방법, 연락처가 전부 포스터 그림 속 글자라면 — 그건 위험 신호다. 좀 더 정확히 보려면 이미지에 마우스를 잠시 올려두거나, 브라우저에서 ‘이미지 표시 끄기’를 켜보면 대체 텍스트가 드러난다. 빈칸이거나 ‘image1.jpg’ 같은 파일명만 뜬다면 그 이미지엔 대체 텍스트가 없는 것이다.

[자주 보이는 문제] 가장 흔한 건 ‘공지·행사 정보를 통째로 이미지 한 장에 담는’ 패턴이다. 디자인이 예뻐 보이니까 포스터 이미지 하나를 떡 올려두고 끝낸다. 보는 사람에겐 깔끔하지만, 못 보는 사람에겐 ‘아무 정보도 없는 페이지’가 된다. 이 패턴이 특히 위험한 건, 그 안에 담긴 게 ‘신청 마감일’이나 ‘제출 서류’처럼 놓치면 손해를 보는 정보일 때다. 멋스러운 포스터 한 장 때문에, 어떤 사용자는 마감일을 영영 모른 채 신청 기회를 놓친다. 두 번째로 흔한 건 ‘장식용 이미지에까지 불필요한 설명을 잔뜩 붙이는’ 정반대 실수다. 의미 없는 배경 무늬나 구분선 이미지에 긴 설명이 붙으면, 낭독기 사용자는 ‘아무 의미 없는 말’을 한참 들어야 해서 오히려 방해가 된다. 세 번째는 ‘파일명이 그대로 읽히는’ 경우다. 대체 텍스트를 안 적으면 낭독기가 ‘이공이육공팔일육 점 제이피지’ 같은 파일명을 그대로 읽어, 사용자는 그 의미 없는 소리를 들으며 당혹스러워한다. 대체 텍스트는 ‘의미 있는 이미지엔 꼭, 장식 이미지엔 비워두기’가 원칙이다.

[어떻게 고치나] 원칙은 단순하다. ‘이미지를 안 보고 글만 들어도 같은 정보가 전달되게’ 만드는 것이다. 정보가 담긴 이미지(포스터, 안내도, 그래프)에는 그 핵심 내용을 글로 옮긴 대체 텍스트를 달거나, 더 좋게는 본문에도 같은 내용을 글로 한 번 더 적어둔다. 마감일이 8월 16일이면 포스터에만 적지 말고 본문에 ‘신청 마감: 8월 16일’이라고 글로 쓰는 식이다. 이렇게 하면 못 보는 사용자뿐 아니라, 이미지가 안 뜨는 느린 환경의 사용자, 그리고 검색엔진까지 모두가 그 정보를 읽는다. 접근성을 챙기면 결국 ‘모두에게’ 이로워지는 대표적인 예다.

대체 텍스트는 ‘콘텐츠 담당자가 매일 만드는’ 영역이라, 한 번 고치고 끝나는 게 아니라 ‘앞으로 올리는 모든 이미지에 적용되는 습관’으로 자리 잡아야 한다. 그래서 가장 효과적인 개선은 ‘이미지 올릴 때 대체 텍스트 칸을 비우면 등록이 안 되게’ 운영 규칙을 만드는 것이다. 기술보다 습관이 먼저인 영역이다.

대체 텍스트를 잘 적는 요령도 짚어두자. 핵심은 ‘이 이미지가 페이지에서 하는 역할’을 적는 것이지, ‘이미지에 보이는 모든 것’을 묘사하는 게 아니다. 예를 들어 신청 마감을 알리는 포스터라면 ‘파란 배경에 사람들이 웃고 있는 그림’이 아니라 ‘○○ 신청 마감 8월 16일 안내 포스터’라고 적어야 한다. 사용자가 알고 싶은 건 그림의 모양이 아니라 그 안에 담긴 ‘정보’이기 때문이다. 반대로 차트나 그래프처럼 ‘숫자가 핵심인 이미지’는, 짧은 대체 텍스트만으로는 부족하니 본문에 표나 글로 같은 데이터를 풀어 적어주는 게 좋다. ‘이 그래프는 옆의 표와 같은 내용입니다’ 한 줄만 덧붙여도, 그래프를 못 보는 사용자가 길을 찾는다.

또 하나, 같은 이미지라도 ‘쓰이는 맥락’에 따라 대체 텍스트가 달라져야 한다. 같은 기관 로고라도 머리글에서 ‘홈으로’ 가는 링크 역할이면 ‘○○기관 홈’처럼 적고, 본문 한가운데 장식으로 들어갔다면 비워두는 게 맞다. 대체 텍스트는 ‘그 이미지가 그 자리에서 무엇을 하는가’에 따라 달라지는 살아 있는 문장이지, 파일에 한 번 박아두고 끝나는 꼬리표가 아니다. 이 감각만 익혀두면, 어떤 이미지를 만나도 ‘여기엔 뭐라고 적어야 하나’가 자연스럽게 떠오른다.

■ 핵심 ② 키보드 접근 — ‘마우스를 떼도 다 되는가’

두 번째는 키보드 접근이다. 마우스를 쓰기 어려운 사용자 — 손 떨림이 있는 분, 한 손만 쓰는 분, 보조기기로 키보드 신호를 보내는 분 — 은 모든 조작을 키보드로 한다. 화면을 못 보는 사용자도 마우스 대신 키보드로 사이트를 누빈다. 그래서 ‘마우스 없이도 모든 기능이 되는가’는 접근성의 가장 기본적인 관문이다.

[직접 확인하는 법] 이 점검은 정말 단순하다. 마우스에서 손을 떼라. 그리고 키보드의 Tab 키만으로 페이지를 처음부터 끝까지 돌아다녀 보라. Tab을 누를 때마다 초점이 메뉴 → 검색창 → 본문 링크 → 버튼으로 옮겨가야 하고, 지금 초점이 ‘어디에 있는지’가 테두리나 강조 표시로 눈에 보여야 한다. 링크와 버튼은 엔터로 눌려야 하고, 메뉴는 화살표로 펼쳐져야 한다. 이렇게 키보드만으로 ‘로그인 → 검색 → 신청서 작성 → 제출’까지 한 바퀴 돌아보면, 마우스로는 멀쩡해 보이던 사이트의 허점이 줄줄이 나온다.

[자주 보이는 문제] 첫째, ‘초점 표시가 없다’. Tab을 눌러도 지금 내가 어디 있는지 화면에 아무 표시가 없으면, 키보드 사용자는 그야말로 ‘눈 감고 미로를 걷는’ 신세가 된다. 디자인을 깔끔하게 한다며 초점 테두리를 일부러 없애버린 경우가 의외로 많은데, 이건 접근성 측면에서 치명적이다. 둘째, ‘마우스로만 되는 기능’. 메뉴가 마우스를 올려야만 펼쳐지고 키보드로는 안 열린다거나, 닫기 버튼이 키보드로는 닿지 않는 팝업 같은 것들이다. 셋째, ‘초점 순서가 뒤죽박죽’. Tab을 눌렀는데 초점이 화면 위아래로 정신없이 튀어 다니면, 사용자는 길을 잃는다. 넷째, ‘키보드 함정’. 어떤 영역에 한번 들어가면 Tab으로 빠져나오질 못하는 경우인데, 주로 외부에서 가져온 위젯이나 광고 영역에서 생긴다.

[어떻게 고치나] 핵심은 ‘마우스로 되는 모든 것은 키보드로도 되어야 한다’는 원칙을 지키는 것이다. 우선 ‘초점 표시’를 절대 없애지 말 것. 디자인이 거슬린다면 없애는 게 아니라 ‘더 예쁘게 보이게’ 다듬으면 된다. 다음으로, 마우스 동작에만 의존하는 기능을 키보드 동작으로도 작동하게 보완한다. 그리고 화면에 보이는 순서대로 초점이 자연스럽게 흐르도록 정리한다. 이 항목은 개발 영역에 가깝지만, 담당자가 ‘키보드로 안 되는 곳’을 콕 집어 외주나 개발팀에 전달하는 것만으로도 절반은 해결된 셈이다. ‘여기 Tab으로 안 닿아요’라는 한 문장이, 추상적인 ‘접근성 챙겨주세요’보다 백배 효과적이다.

키보드 점검에서 의외로 중요한 게 ‘건너뛰기 링크’다. 사이트에 들어가면 보통 머리글에 메뉴가 잔뜩 있는데, 키보드 사용자가 매 페이지마다 그 메뉴를 Tab으로 다 지나야 본문에 닿는다면 얼마나 답답하겠는가. 그래서 잘 만든 사이트는 페이지 맨 앞에 ‘본문 바로가기’ 같은 건너뛰기 링크를 둔다. 평소엔 안 보이다가 Tab을 처음 누르면 나타나, 한 번에 본문으로 점프하게 해준다. 우리 사이트에서 페이지를 열자마자 Tab을 한 번 눌러보라. ‘본문 바로가기’ 비슷한 게 튀어나오면 합격이고, 아무것도 없이 곧장 첫 메뉴로 초점이 가면 이 편의 장치가 빠진 것이다. 사소해 보이지만, 매일 키보드로 사이트를 쓰는 사용자에겐 ‘매번 메뉴 스무 개를 지나느냐, 한 번에 본문으로 가느냐’의 큰 차이다.

또 하나 자주 놓치는 건 ‘팝업·모달의 초점 가두기’다. 신청 도중 ‘정말 제출하시겠습니까?’ 같은 확인창이 뜰 때, 그 창이 떠 있는 동안에는 초점이 창 안에만 머물러야 한다. 그런데 초점 관리가 안 되어 있으면, Tab을 누를 때 초점이 창 뒤편의 안 보이는 화면으로 빠져나가 버린다. 키보드 사용자는 ‘분명 창이 떠 있는데 내 초점은 어디 갔지’ 하고 혼란에 빠진다. 점검할 때 확인창이 뜬 상태에서 Tab을 여러 번 눌러보라. 초점이 창 안의 ‘확인’과 ‘취소’ 버튼 사이만 오가면 잘된 것이고, 창 밖으로 새 나가면 보강이 필요하다. 이런 세밀한 부분은 사람 눈으로도 잡을 수 있으니, 신청·결제처럼 중요한 흐름의 팝업은 꼭 키보드로 한 번 점검해두자.

■ 핵심 ③ 색 대비 — ‘흐릿한 눈으로도 읽히는가’

세 번째는 색 대비다. 글자색과 배경색의 차이가 충분하지 않으면, 시력이 약한 사용자나 색각이 다른 사용자, 심지어 햇빛 아래에서 휴대폰을 보는 평범한 사용자조차 글을 읽기 어렵다. 회색 배경에 옅은 회색 글씨, 파란 배경에 살짝 어두운 파란 글씨 같은 ‘세련돼 보이지만 안 읽히는’ 조합이 대표적 함정이다.

[직접 확인하는 법] 가장 쉬운 방법은 ‘화면을 흑백으로 바꿔보는 것’이다. 운영체제의 색 필터에서 ‘회색조(흑백)’를 켜면 색이 다 사라지고 명암만 남는다. 이 상태에서도 글자가 또렷이 읽히면 대비가 충분한 것이고, 글자가 배경에 묻혀 ‘있는지 없는지’ 헷갈리면 대비가 부족한 것이다. 색맹·저시력 사용자가 보는 화면이 대략 이렇다고 생각하면 된다. 또 다른 방법은 ‘화면 밝기를 최대한 낮추고’ 보는 것이다. 밝기를 낮춰도 읽히면 합격, 안 읽히면 보강이 필요하다. 특히 본문 글자, 버튼 안 글자, 입력칸 안내 글씨, 링크 색을 집중해서 보라.

[자주 보이는 문제] 첫째, ‘옅은 회색 안내문’이다. 보조 설명이나 날짜, 작성자 같은 정보를 멋스럽게 보이려고 옅은 회색으로 처리하는 경우가 많은데, 정작 그 정보가 필요한 사람이 못 읽는다. 둘째, ‘배경 이미지 위의 글자’다. 사진 위에 흰 글씨를 얹으면, 사진의 밝은 부분에선 글씨가 사라진다. 셋째, ‘색으로만 구분하는 정보’다. 빨강은 마감, 초록은 진행 중처럼 색만으로 상태를 표시하면, 색각이 다른 사용자는 둘을 구별하지 못한다. 색에 더해 모양이나 글자(‘마감’, ‘진행중’)를 같이 써야 한다.

[어떻게 고치나] 글자와 배경의 명암 차이를 충분히 확보하는 게 기본이다. 흑백으로 봤을 때 또렷이 읽히는 정도면 대체로 안전하다. 옅은 회색으로 ‘덜 중요해 보이게’ 만들고 싶은 마음은 이해하지만, 정보의 중요도는 색의 진하기가 아니라 ‘위치와 크기’로 표현하는 게 옳다. 배경 이미지 위 글자는 어두운 반투명 막을 한 겹 깔아 가독성을 확보한다. 그리고 ‘색으로만 구분하지 말 것’ — 이건 색 대비 항목에서 가장 자주 놓치는 원칙이다. 색은 ‘거들 뿐’, 정보 자체는 글자와 모양으로도 전달되어야 한다.

색 대비는 ‘기초(디자인)’ 영역과 맞닿아 있어서, 한번 ‘우리 브랜드 색과 그 위에 올릴 글자색’의 안전한 조합을 정해두면 그 뒤로는 고민할 일이 줄어든다. 매번 눈대중으로 색을 고르지 말고, ‘이 배경엔 이 글자색’이라는 검증된 짝을 정해 모두가 공유하는 게 근본 해법이다.

색 대비가 ‘남 일이 아닌’ 이유를 한 번 더 짚자. 색각이 다른 사람은 생각보다 흔하다. 특히 적록색약은 남성 중 적지 않은 비율로 나타나, 어느 조직이든 ‘색으로만 구분한 정보’를 못 읽는 사람이 곁에 있다고 보면 된다. 그뿐 아니라, 멀쩡한 시력을 가진 사람도 ‘밝은 야외에서 휴대폰을 볼 때’는 사실상 저시력자와 비슷한 처지가 된다. 햇빛 아래에선 화면이 하얗게 떠서 옅은 글자가 통째로 사라진다. 그러니 색 대비는 ‘소수를 위한 배려’가 아니라 ‘모두가 어떤 환경에서든 읽을 수 있게’ 하는 기본기다. 충분한 대비를 확보한 사이트는, 시력이 약한 사용자에게도 좋지만 출퇴근길 버스에서 흔들리며 보는 평범한 사용자에게도 한결 편하다.

링크 색에 대한 함정도 하나 짚자. 본문 속 링크를 ‘색만 다르게’ 표시하는 경우가 많은데 — 예컨대 검은 본문에 파란 글씨로 링크 — 색각이 다른 사용자는 그 파랑과 검정을 구별하지 못해 ‘여기가 링크인 줄도 모르고’ 지나친다. 그래서 링크는 색에 더해 밑줄 같은 ‘모양 단서’를 함께 주는 게 안전하다. 이것도 ‘색으로만 구분하지 말 것’ 원칙의 한 갈래다. 색은 거들 뿐이고, 정보의 본체는 글자·모양·위치로 전달되어야 한다는 이 원칙은, 색 대비 항목 전체를 관통하는 가장 중요한 한 줄이다.

■ 핵심 ④ 자막·대체수단 — ‘소리 없이도 전해지는가’

네 번째는 영상·음성 콘텐츠의 자막과 대체수단이다. 공공 사이트에도 안내 영상, 홍보 영상, 정책 설명 음성 같은 멀티미디어가 점점 늘고 있다. 그런데 자막이 없으면 청각장애인은 그 영상에서 아무것도 얻지 못한다. 소리를 키울 수 없는 환경(사무실, 도서관, 대중교통)에 있는 평범한 사용자도 마찬가지다. 자막은 ‘못 듣는 사람’만이 아니라 ‘지금 들을 수 없는 사람’ 모두를 위한 것이다.

[직접 확인하는 법] 우리 사이트의 영상을 하나 열고, 소리를 완전히 끈 채로 본다. 소리 없이도 ‘무슨 내용인지’ 자막으로 따라갈 수 있으면 합격이다. 자막이 아예 없거나, 영상 화면에 자막이 ‘구워져’ 있긴 한데 글자가 너무 작거나 흐려서 안 읽힌다면 보강이 필요하다. 음성만 있는 콘텐츠(안내 음성, 팟캐스트 형식)라면, 그 내용을 글로 옮긴 ‘대본’이 함께 제공되는지 확인한다. 한 가지 더, 영상이 ‘자동 재생’되며 소리부터 터져 나오지 않는지도 함께 보자. 갑작스러운 소리는 화면 낭독기를 쓰는 사용자에게 큰 방해가 된다.

[자주 보이는 문제] 가장 흔한 건 ‘자막 없는 안내 영상’이다. 외부 영상 플랫폼에서 가져와 그대로 붙여놓고 자막은 신경 쓰지 않는 경우가 많다. 두 번째는 ‘영상 안에만 정보가 있는’ 패턴이다. 신청 절차나 변경 사항을 영상으로만 안내하고 글 설명을 안 달면, 영상을 못 보거나 안 보는 사용자는 정보를 놓친다. 세 번째는 ‘자동 재생 소리’다. 페이지를 열자마자 배경 음악이나 안내 음성이 터지면, 사용자는 당황하고 낭독기 사용자는 어느 소리가 낭독인지 구별하지 못한다.

[어떻게 고치나] 영상에는 자막을 제공하는 게 원칙이다. 별도 자막 파일을 붙이거나, 어렵다면 영상 아래 본문에 핵심 내용을 글로 요약해두는 것만으로도 큰 차이가 난다. 음성 콘텐츠엔 대본을 함께 제공한다. 그리고 ‘소리는 사용자가 스스로 켜게’ 두자. 자동 재생되며 소리가 나오는 설정은 끄는 게 좋다. 멀티미디어 접근성은 ‘영상 하나에 글 설명 한 단락 더하기’라는 작은 습관으로 대부분 해결된다. 자막 제작이 부담스럽다면, 적어도 ‘이 영상의 내용은 본문에도 글로 있다’는 상태를 만드는 것을 1차 목표로 삼자.

자막을 둘러싼 흔한 오해 하나를 풀고 가자. ‘영상 안에 글자를 박아 넣으면 자막 아니냐’는 생각인데, 그건 절반만 맞다. 화면에 구워 넣은 글자는 ‘보이는 자막’일 뿐, 화면을 못 보는 사용자에겐 여전히 전해지지 않고, 글자를 키우거나 끄고 싶은 사용자도 손댈 수 없다. 진짜 접근성을 갖춘 자막은 ‘텍스트 데이터로 따로 존재해, 사용자가 켜고 끄고 크기를 조절할 수 있는’ 형태다. 물론 처음부터 그런 자막을 갖추기 어렵다면, 화면에 박힌 자막이라도 ‘없는 것보단 백배 낫다’. 다만 그게 끝이 아니라 ‘1단계’임을 알고, 형편이 되는 대로 텍스트 자막과 본문 요약으로 나아가는 게 좋다.

그리고 자막의 ‘품질’도 챙기자. 요즘은 자동 자막 기능으로 손쉽게 자막을 만들 수 있지만, 자동 자막은 전문 용어나 기관 이름, 정책 명칭을 엉뚱하게 받아 적는 경우가 많다. 특히 공공 콘텐츠는 정확한 절차와 기한이 생명인데, 자막이 ‘8월 16일’을 ‘8월 60일’로 적어버리면 차라리 없느니만 못하다. 그래서 자동 자막을 쓰더라도 ‘사람이 한 번 훑어 고치는’ 검수가 필요하다. 자막은 ‘있느냐 없느냐’만큼이나 ‘맞느냐 틀리느냐’도 중요한, 사용자에게 직접 정보를 전하는 통로다.

■ 핵심 ⑤ 입력 라벨·오류 안내 — ‘안 보여도 채울 수 있는가’

마지막은 입력 양식의 라벨과 오류 안내다. 공공 사이트의 진짜 ‘일’은 대부분 신청·예약·민원 같은 ‘양식 채우기’에서 일어난다. 그런데 바로 이 양식이 접근성에서 가장 자주, 가장 심각하게 무너진다. 양식에서 막히면 사용자는 ‘하려던 일 자체’를 못 하게 되기 때문이다.

[직접 확인하는 법] 신청 양식 한 페이지를 열고, 두 가지를 본다. 첫째, ‘각 입력칸에 무엇을 적는지’가 칸 바깥의 글(라벨)로 명확히 적혀 있는가. 칸 안에 흐릿하게 들어간 안내문(‘이름을 입력하세요’ 같은)만 있고 바깥 라벨이 없으면, 입력을 시작하는 순간 그 안내가 사라져 ‘여기가 무슨 칸이었지’ 헷갈린다. 화면을 못 보는 사용자는 그 흐린 글씨를 처음부터 못 읽는 경우가 많다. 둘째, ‘일부러 틀리게 채워서 제출’해보라. 필수 칸을 비우거나 형식에 안 맞게 적고 제출했을 때, ‘어느 칸이, 왜 틀렸고, 어떻게 고치라’고 그 칸 옆에 구체적으로 알려주면 합격이다.

[자주 보이는 문제] 첫째, ‘칸 안 안내문만 있고 바깥 라벨이 없는’ 양식이다. 디자인은 깔끔해 보이지만, 입력 중엔 무슨 칸인지 알 수 없고 낭독기는 빈칸 앞에서 ‘편집창’이라고만 읽는다. 둘째, ‘맨 위 빨간 한 줄’ 오류다. 폼을 잘못 채우면 화면 맨 위에 ‘입력을 확인하세요’ 한 줄만 뜨고, 정작 어느 칸이 문제인지는 안 알려준다. 사용자는 칸을 하나하나 뒤지며 범인을 찾아야 한다. 셋째, ‘색으로만 표시하는 오류’다. 틀린 칸 테두리만 빨갛게 만들고 글 설명을 안 달면, 색각이 다른 사용자나 낭독기 사용자는 무엇이 틀렸는지 모른다. 넷째, ‘필수 항목 표시를 별표(*)로만’ 하는 경우다. 별표가 무슨 뜻인지 모르는 사용자도 있고, 낭독기는 별표를 그냥 ‘별’이라고 읽어 넘기기도 한다.

[어떻게 고치나] 모든 입력칸에 ‘바깥 라벨’을 붙이는 게 기본 중 기본이다. 칸 안 흐린 안내문은 라벨을 대신할 수 없고, 어디까지나 ‘보조’여야 한다. 오류는 ‘그 칸 바로 옆에, 글로, 구체적으로’ 알려준다. ‘전화번호 형식이 올바르지 않습니다. 숫자만 입력해주세요’처럼 무엇이·왜·어떻게가 한 문장에 담겨야 한다. 색만으로 오류를 표시하지 말고 글과 아이콘을 함께 쓴다. 필수 항목은 별표 대신 ‘(필수)’라고 글로 적는 게 안전하다. 양식 접근성은 ‘사이트의 가장 중요한 일이 일어나는 곳’의 접근성이라, 다섯 항목 중 가장 공들여 봐야 할 곳이다.

오류 안내를 잘 만드는 데는 ‘타이밍’도 중요하다. 사용자가 모든 칸을 다 채우고 제출 버튼을 누른 다음에야 ‘세 번째 칸이 틀렸습니다’라고 알려주면, 사용자는 한참 위로 거슬러 올라가 그 칸을 찾아야 한다. 가능하면 ‘그 칸을 벗어나는 순간’ 바로 알려주는 게 친절하다. 전화번호 칸을 다 적고 다음 칸으로 넘어가려는데 형식이 틀렸다면, 그 자리에서 ‘숫자만 입력해주세요’라고 알려주면 사용자는 즉시 고친다. 다만 이때도 ‘다 적기도 전에 빨갛게 윽박지르는’ 건 곤란하다. 사용자가 아직 입력 중인데 ‘아직 부족합니다’라고 다그치면 오히려 위축된다. ‘칸을 다 적고 벗어날 때’가 알려주기 좋은 시점이다.

그리고 오류 메시지의 ‘말투’도 접근성의 일부다. ‘잘못된 값입니다’ 같은 차갑고 막연한 말은, 무엇을 어떻게 고치라는 건지 알 수 없어 사용자를 더 막막하게 만든다. 같은 상황이라도 ‘생년월일은 8자리 숫자로 입력해주세요. 예: 19900101’처럼 구체적인 예시까지 곁들이면, 누구나 한 번에 알아듣는다. 특히 인지가 어려운 사용자나 디지털에 익숙하지 않은 어르신에게는, 이 ‘예시 한 줄’의 유무가 신청을 끝내느냐 중도에 포기하느냐를 가른다. 오류 안내는 사용자를 ‘틀렸다고 지적하는’ 자리가 아니라 ‘끝까지 도와주는’ 자리여야 한다. 그 한 끗 차이가, 양식을 ‘넘기 힘든 벽’에서 ‘함께 넘는 문턱’으로 바꾼다.

마지막으로, 양식에서 ‘시간 제한’이 있다면 그것도 점검하자. 보안을 이유로 일정 시간이 지나면 세션이 끊기고 입력 내용이 날아가는 사이트가 있는데, 천천히 입력하는 사용자 — 화면 낭독기로 한 칸씩 확인하며 적는 분, 손이 불편해 천천히 타이핑하는 분, 가족에게 물어가며 적는 어르신 — 에게는 이 시간 제한이 치명적이다. 다 적었는데 ‘시간이 만료되었습니다’가 떠서 처음부터 다시 해야 한다면, 그건 ‘사실상 못 쓰게 만드는’ 장벽이다. 시간 제한이 꼭 필요하다면 ‘연장하기’ 버튼을 함께 제공하거나, 입력 내용이 날아가지 않게 임시 저장하는 배려가 필요하다. 양식 접근성은 이렇게 ‘다 채우는 데까지’가 아니라 ‘끝까지 무사히 제출하는 데까지’를 책임지는 일이다.

본론 3 — 점수로 환산하고, 다음 행동으로 잇기

■ ‘아니오’를 점수로 바꿔보기

다섯 항목을 다 봤다면, 이제 ‘예/아니오’를 거칠게라도 점수로 환산해보자. 정밀한 산식은 아니지만, 추세를 잡는 데는 충분하다. 각 항목을 ‘예=2점, 부분적으로 예=1점, 아니오=0점’으로 매기면 만점은 10점이다.

· 8~10점: 접근성 기초가 비교적 탄탄하다. 도구로 33개 전부를 점검해 세밀한 마감을 보완할 단계다.

· 5~7점: ‘일부는 되는데 빠진 곳이 있는’ 상태다. 가장 점수가 낮은 항목 한두 개부터 우선 잡자.

· 4점 이하: 실제 사용자 중 상당수가 ‘아예 못 쓰는’ 상황일 가능성이 높다. 미루지 말고 개선 계획을 세워야 한다.

여기서 강조하고 싶은 건, 점수 자체보다 ‘어느 항목에서 0점이 나왔는가’다. 평균이 7점이어도 ‘대체 텍스트’가 0점이면, 화면을 못 보는 사용자에겐 그 사이트가 ‘텅 빈 페이지’다. 접근성은 평균이 아니라 ‘가장 약한 고리’가 전체 경험을 결정한다. 그러니 점수표를 볼 때 평균보다 ‘0점 항목’을 먼저 보라. 0점이 하나라도 있다면, 그건 ‘일부 사용자에겐 그 사이트가 통째로 닫혀 있다’는 뜻이다.

이 ‘가장 약한 고리’ 관점은 접근성을 이해하는 데 결정적이다. 일반적인 품질이라면 ‘평균이 높으면 좋은 것’이지만, 접근성은 다르다. 사용자 한 사람의 입장에서 보면, 다른 항목이 아무리 좋아도 ‘자신이 막히는 그 한 항목’이 0점이면 사이트 전체가 막힌 것이나 다름없기 때문이다. 화면을 못 보는 김 씨에게는 대체 텍스트가, 마우스를 못 쓰는 이 씨에게는 키보드 접근이 ‘바로 그 한 항목’이다. 그래서 접근성 개선의 첫 번째 원칙은 ‘잘하는 걸 더 잘하기’가 아니라 ‘0점을 없애기’다. 모든 항목을 골고루 1점이라도 받는 사이트가, 어떤 항목은 만점인데 어떤 항목은 0점인 사이트보다 ‘더 많은 사람에게 열려 있다’. 점수를 볼 때 이 사실을 꼭 기억하자. 우리의 목표는 ‘평균 점수 올리기’가 아니라 ‘아무도 막히지 않게 하기’다.

■ ‘아니오 메모’를 작업 지시서로

점검의 가치는 ‘발견’이 아니라 ‘기록’에서 완성된다고 앞서 말했다. 이제 ‘아니오’ 옆에 적어둔 메모들을 모아, 우선순위를 붙여보자. 우선순위는 두 가지로 정한다. 하나는 ‘영향받는 사람이 얼마나 많은가’, 다른 하나는 ‘고치기가 얼마나 쉬운가’다. 영향이 크고 고치기 쉬운 것부터 손대는 게 정석이다.

예컨대 ‘대체 텍스트 누락’과 ‘입력 라벨 누락’은 영향이 크면서도 비교적 운영·콘텐츠 차원에서 빨리 손볼 수 있는 경우가 많다. 반면 ‘키보드 초점 순서 정리’ 같은 건 개발이 필요해 시간이 더 걸린다. 그러니 ‘빨리 되는 것부터 먼저, 시간 걸리는 것은 계획을 잡아’ 두 갈래로 나누면, 막막하던 개선이 ‘이번 주에 할 것’과 ‘다음 분기에 할 것’으로 구체화된다.

그리고 이 메모는 외주 업체나 개발팀과의 소통에서 빛을 발한다. ‘접근성 좀 챙겨주세요’는 받는 쪽도 막막하다. 하지만 ‘신청 페이지 1번 입력칸에 바깥 라벨이 없습니다’, ‘메인 배너 이미지에 대체 텍스트가 비어 있습니다’처럼 구체적이면, 바로 작업 지시가 된다. 자가 점검의 진짜 결과물은 점수가 아니라, 이런 ‘구체적인 문장들의 목록’이다.

특히 외주로 사이트를 운영하는 기관이라면, 이 ‘구체적인 목록’의 가치가 더 크다. 외주 계약서에 ‘접근성을 준수한다’는 한 줄만 적혀 있으면, 막상 문제가 생겼을 때 ‘무엇이 어떻게 준수되어야 하는지’를 두고 서로 다른 해석이 부딪친다. 반면 ‘이 페이지의 이 요소가 이 항목을 위반했다’는 구체적인 목록이 손에 있으면, 보수 요청이 명확해지고 책임 소재도 분명해진다. 자가 점검과 자동 검사로 만든 이 목록은, 단지 사이트를 고치는 데만 쓰이는 게 아니라 ‘외주 관리의 근거 자료’로도 든든하게 쓰인다. 막연한 ‘잘 좀 해주세요’가 아니라 ‘여기 이걸 이렇게’라고 짚을 수 있을 때, 비로소 개선이 실제로 일어난다.

또 한 가지, 개선 결과를 ‘기록으로 남기는’ 습관도 들이자. 무엇을 발견했고, 무엇을 어떻게 고쳤고, 무엇이 다음 분기로 넘어갔는지를 간단히 적어두면, 담당자가 바뀌어도 그 흐름이 끊기지 않는다. 공공기관은 인사 이동이 잦아, 애써 쌓은 접근성 노하우가 담당자 한 명과 함께 사라지는 일이 흔하다. ‘점검 → 개선 → 기록’의 사이클이 문서로 남아 있으면, 새 담당자가 와도 ‘지난번엔 여기까지 했구나’ 하고 바로 이어받는다. 접근성은 한 사람의 영웅적 노력이 아니라, 이렇게 차곡차곡 이어지는 기록의 릴레이로 지켜진다.

■ 정기 점검으로 ‘추세’ 보기

이 체크리스트는 ‘한 번 하고 끝’이 아니라 ‘정기적으로 반복’할 때 진가가 드러난다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 페이지가 늘어나며 계속 변한다. 오늘 ‘예’였던 항목이 반년 뒤 새로 올라온 이미지·영상 때문에 ‘아니오’가 되어 있을 수 있다. 그래서 분기에 한 번쯤 같은 다섯 항목으로 다시 점검하면, 접근성이 좋아지고 있는지 나빠지고 있는지 추세가 보인다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다.

특히 접근성은 ‘새로 추가되는 콘텐츠’에서 자주 무너진다. 처음 사이트를 만들 땐 신경 써서 라벨도 달고 자막도 넣었는데, 운영하면서 급하게 올리는 공지·이미지·영상엔 점점 빠진다. 그래서 ‘새 콘텐츠를 올릴 때마다 핵심 5를 체크’하는 짧은 습관이, 분기 점검만큼이나 중요하다. 큰 점검과 작은 습관, 이 둘이 함께 가야 사이트 접근성이 시간이 지나도 무너지지 않는다.

■ ‘완벽’이 아니라 ‘방향’을 목표로

마지막으로, 접근성 개선에 임하는 마음가짐 하나를 보태고 싶다. 접근성은 ‘100점 아니면 0점’의 세계가 아니다. 어제보다 오늘 이미지 하나에 대체 텍스트가 더 붙었다면, 그만큼 누군가에게 사이트가 더 열린 것이다. 처음부터 33개 항목을 완벽히 충족하려 들면 부담에 짓눌려 아예 시작을 못 한다. 그러니 ‘완벽’이 아니라 ‘어제보다 나아지는 방향’을 목표로 삼자.

현장에서 가장 안타까운 경우는 ‘완벽하게 하려다 아무것도 못 하는’ 상황이다. ‘제대로 하려면 외주를 다시 줘야 하고, 예산이 필요하고, 전면 개편이…’ 하며 미루다 보면, 정작 ‘오늘 당장 대체 텍스트 열 개 다는’ 작은 개선조차 영영 안 일어난다. 접근성은 거대한 프로젝트가 아니라, 매일의 작은 선택이 쌓여 만들어지는 것이다. 오늘 핵심 5항목을 점검하고 그중 가장 쉬운 하나만 손봐도, 우리 사이트는 어제보다 조금 더 ‘모두에게 열린’ 곳이 된다. 그 작은 한 걸음을, 미루지 말고 오늘 떼자.

본론 4 — 눈으로 5분, 도구로 33개: 자동 검사가 메우는 빈틈

■ 사람 눈의 한계, 그리고 도구의 자리

지금까지 ‘사람 눈과 손으로’ 핵심 5항목을 점검하는 법을 길게 다뤘다. 그런데 솔직히 인정하자. 사람 눈에는 한계가 분명하다.

첫째, ‘다 못 본다’. 공공 사이트는 보통 수십에서 수백 페이지다. 한 사람이 모든 페이지의 모든 이미지, 모든 입력칸, 모든 버튼을 손으로 확인하는 건 불가능에 가깝다. 핵심 5항목을 본다 해도, 결국 ‘대표 페이지 몇 개’만 보게 된다. 그런데 정작 문제는 ‘잘 안 보던 하위 페이지’에 숨어 있을 때가 많다.

둘째, ‘일관성이 없다’. 오늘 점검한 사람과 다음 분기에 점검할 사람의 기준이 다르고, 같은 사람도 컨디션에 따라 후하게 보거나 박하게 본다. 자가 점검은 ‘감’을 잡는 데는 좋지만, ‘객관적인 수치’로 비교하긴 어렵다.

셋째, ‘색 대비 같은 건 눈으로 정확히 못 잰다’. 흑백으로 바꿔보는 방법으로 ‘대충’은 알 수 있지만, ‘이 조합이 기준을 충족하는가’를 정확히 판정하려면 명도 대비를 수치로 계산해야 한다. 이건 사람 눈이 아니라 계산기의 일이다.

바로 이 빈틈을 메우는 게 자동 검사 도구다. 도구는 지치지 않고 모든 페이지를 훑고, 언제나 같은 기준으로 판정하며, 색 대비 같은 수치는 정확히 계산한다. 사람 눈이 ‘대표 페이지의 큰 문제’를 잡는다면, 도구는 ‘모든 페이지의 작은 문제까지’ 빠짐없이 긁어모은다. 둘은 경쟁이 아니라 분업이다.

다만 도구에도 한계가 있다는 점은 솔직하게 말해두고 싶다. 자동 검사는 ‘대체 텍스트가 있는가 없는가’는 정확히 잡지만, ‘그 대체 텍스트가 이미지 내용을 제대로 설명하는가’까지는 판단하기 어렵다. ‘image1.jpg’라고 적힌 무의미한 대체 텍스트는 ‘있긴 있으니’ 통과시켜버릴 수 있다. 자막이 ‘달려 있는가’는 알아도 ‘그 자막이 정확한가’는 사람이 봐야 한다. 그래서 ‘도구가 다 잡아주겠지’ 하고 손을 놓으면 안 된다. 도구가 ‘기계적으로 확인 가능한 것’을 빠짐없이 잡아주는 동안, 사람은 ‘의미와 품질’을 챙기는 — 이 역할 분담이 맞물려야 접근성이 진짜로 좋아진다. 오늘 자가 점검법을 길게 다룬 것도 그래서다. 도구를 쓰더라도 ‘사람이 봐야 할 것’을 아는 담당자라야, 도구의 결과를 제대로 읽고 보완할 수 있다.

■ ViewCheck가 하는 ‘접근성 자동 검사’

여기서 우리가 만드는 ViewCheck 이야기를 잠깐 하겠다. ViewCheck는 공공 웹사이트의 KRDS 준수와 품질을 자동으로 진단하는 도구다. 핵심은 행정안전부 「전자정부 웹사이트 품질관리 지침」 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 사이트 전체에 걸쳐 자동으로 검사한다는 점이다.

오늘 주제인 접근성과 관련해, ViewCheck는 웹 접근성 한국형 지침인 KWCAG 33개 항목을 자동으로 점검한다. 오늘 우리가 사람 눈으로 본 핵심 5항목 — 대체 텍스트, 키보드 접근, 색 대비, 자막, 입력 라벨 — 은 물론이고, 사람 눈으로는 일일이 확인하기 어려운 나머지 항목까지 도구가 모든 페이지를 돌며 검사한다. 사람이 ‘대표 페이지 다섯 곳’을 5분 보는 동안, 도구는 ‘사이트 전체 수백 페이지’를 빠짐없이 훑는 셈이다.

ViewCheck는 접근성만 보는 게 아니다. KRDS 디자인 준수를 846개 규칙(디자인 기초 DS 120개 + 부품 CP 446개 + 기본 패턴 BP 108개 + 서비스 패턴 SP 172개)으로 세분해 판정한다. 월요일·수요일 글에서 다룬 ‘색·글꼴·간격이 일관적인가’, ‘버튼·폼이 제대로 작동하는가’ 같은 것들이 이 846규칙 안에 다 들어 있다. 접근성은 그 7대 영역과 846규칙이 맞물려 돌아가는 큰 그림의 한 축이다. 예컨대 오늘 본 ‘색 대비’는 접근성 항목이면서 동시에 디자인 기초(DS) 영역과도 닿아 있고, ‘입력 라벨’은 접근성이면서 부품(CP) 영역의 폼 규칙과도 겹친다. ViewCheck는 이렇게 여러 영역에 걸친 문제를 한 번의 진단으로 교차해서 보여준다.

진단을 돌리면, 결과 화면 상단에 점수 카드가 뜬다. 7대 영역과 KRDS 네 카테고리(DS·CP·BP·SP)의 점수가 한눈에 보이고, 그 아래로 ‘어느 페이지의 어느 요소가 어떤 항목을 위반했는지’가 구체적인 목록으로 펼쳐진다. 오늘 사람 눈으로 ‘아니오’를 적고 메모를 남긴 그 작업을, 도구가 사이트 전체에 대해 자동으로 해주는 셈이다. 그것도 ‘이미지 alt가 비었다’, ‘이 입력칸에 라벨이 없다’ 수준의 구체적인 위치까지 짚어준다. 사람이 ‘아니오 메모’를 손으로 적느라 한나절을 보내야 할 일을, 도구는 사이트 전체에 대해 수십 초에서 수 분 만에 끝낸다. 그렇게 만들어진 목록이 그대로 ‘작업 지시서’가 되니, 점검과 개선 사이의 거리가 확 줄어든다.

■ ‘자가 점검 → 자동 검사’의 이상적인 순서

그러면 자가 점검과 자동 검사를 어떻게 엮어 쓰는 게 좋을까. 추천하는 순서는 이렇다.

먼저 오늘 배운 핵심 5항목을 사람 눈으로 본다. 5분이면 ‘우리 사이트가 대략 어느 수준인지’ 감이 온다. 이 과정에서 각 항목이 ‘무슨 뜻인지’, ‘왜 중요한지’를 몸으로 익힌다. 이게 중요하다. 항목의 의미를 모르면, 자동 검사 결과지를 받아도 ‘숫자는 많은데 뭘 봐야 할지 모르는’ 상태가 되기 때문이다.

그다음 자동 검사를 돌려 ‘사이트 전체의 정확한 그림’을 얻는다. 사람 눈으로 본 대표 페이지의 감과, 도구가 전수 검사한 결과를 비교하면 ‘아, 메인은 괜찮은데 하위 페이지가 문제였구나’ 같은 통찰이 나온다. 그리고 자동 검사 결과지의 항목들이, 앞서 자가 점검으로 의미를 익혀둔 덕분에 ‘그때 그 불편했던 게 이거구나’로 살아 움직인다.

마지막으로 자동 검사가 짚어준 구체적 위치를 ‘작업 지시서’로 삼아 고친다. 도구는 ‘무엇이·어디서 문제인지’를 알려주지만, 그 우선순위를 정하고 실제로 고치는 건 결국 사람의 몫이다. 자가 점검으로 익힌 ‘왜 중요한가’의 감각이, 그 우선순위 판단을 든든하게 받쳐준다.

이렇게 ‘사람의 감 → 도구의 전수 → 사람의 판단’으로 한 바퀴 돌면, 막막하던 접근성 개선이 손에 잡히는 일이 된다. 도구는 사람을 대체하지 않는다. 사람이 ‘큰 문제와 의미’를 보고, 도구가 ‘빠짐없이 정확히’ 받쳐주는 — 그 협업이 접근성을 실제로 좋아지게 만든다.

한 가지 덧붙이면, 자동 검사의 진짜 가치는 ‘반복’에서 나온다. 앞서 분기마다 자가 점검을 반복하라고 했는데, 자동 검사도 마찬가지다. 처음 한 번 돌려 ‘현재 상태’를 찍어두고, 개선 작업을 한 뒤 다시 돌려 ‘얼마나 나아졌는지’를 같은 기준으로 비교하면, 우리 노력이 숫자로 보인다. 사람 눈은 ‘지난번보다 나아졌나’를 정확히 기억하지 못하지만, 도구는 늘 같은 잣대로 재기 때문에 ‘이번 분기에 접근성 점수가 몇 점 올랐다’를 또렷이 보여준다. 이 ‘추세’가 윗선 보고에도, 팀의 동기 부여에도 큰 힘이 된다. 개선이 ‘느낌’이 아니라 ‘기록’으로 남으니, 다음 개선을 밀어붙일 근거가 된다.

그리고 접근성을 따로 떼어 보지 않고, 행정안전부 7대 영역과 KRDS 846규칙이라는 큰 그림 안에서 함께 보는 것도 중요하다. 오늘 다룬 접근성은 그 자체로도 중요하지만, ‘좋은 공공 웹사이트’라는 더 큰 목표의 한 조각이기도 하다. 색 대비가 좋아지면 디자인 기초도 정돈되고, 입력 라벨이 분명해지면 양식 패턴도 탄탄해지고, 키보드 접근이 갖춰지면 부품 품질도 올라간다. 접근성을 챙기는 일이 곧 사이트 전체의 품질을 끌어올리는 일과 맞물려 있는 것이다. 그래서 ‘접근성만 따로 점검’하기보다, 사이트 전체 품질을 한 번에 보는 진단을 통해 접근성을 그 안에서 함께 챙기는 편이 효율적이다.

마무리

오늘 길게 다뤘지만, 핵심은 다섯 문장으로 줄어든다. 의미 있는 이미지엔 대체 텍스트를 달자. 마우스를 떼고 키보드만으로 다 되게 하자. 글자와 배경은 흑백으로 봐도 또렷하게 하자. 영상엔 자막을, 음성엔 대본을 붙이자. 입력칸엔 바깥 라벨을, 오류엔 친절한 안내를 달자. 이 다섯만 챙겨도, ‘일부 사용자에게 통째로 닫혀 있던 사이트’가 ‘모두에게 열린 사이트’로 한 걸음 나아간다.

다시 강조하지만, 접근성은 평균이 아니라 ‘가장 약한 고리’가 결정한다. 아홉 항목이 완벽해도 대체 텍스트 하나가 비어 있으면, 화면을 못 보는 사용자에겐 그 페이지가 텅 비어 있다. 그러니 오늘 점검에서 ‘0점 항목’이 하나라도 나왔다면, 그걸 ‘우리 사이트가 누군가에겐 닫혀 있다’는 신호로 진지하게 받아들이자. 그리고 그건 부끄러워할 일이 아니라, 고칠 거리를 찾았다는 반가운 일이다.

그리고 이건 ‘착한 일’만이 아니라 ‘해야 하는 일’임을 잊지 말자. 공공 웹사이트의 접근성은 의무이고, 행정안전부 품질관리 지침에서 가장 무게가 실린 영역이다. 무엇보다, 우리 기관의 서비스를 가장 필요로 하는 사람일수록 그 정보에 접근하기 어려운 처지일 때가 많다. 접근성은 그 사람들에게 ‘당신도 이 서비스를 쓸 수 있다’고 문을 열어주는 일이다. 그래서 나는 접근성을 ‘기술의 문제’이기 전에 ‘태도의 문제’라고 부르고 싶다.

오늘 핵심 5항목을 직접 점검해봤다면, 이제 ‘사이트 전체의 정확한 그림’을 확인할 차례다. 사람 눈으로는 대표 페이지 몇 곳밖에 못 보지만, 도구는 모든 페이지의 모든 요소를 빠짐없이 훑는다. krds.viewcheck.co.kr에 들어가 우리 기관 사이트 주소를 넣으면, KWCAG 33개 항목을 포함한 접근성과 KRDS 846규칙 준수 여부를 자동으로 진단해, 결과 화면 상단의 점수 카드와 그 아래 구체적인 위반 목록으로 보여준다. 무료로 한 번 돌려보는 것만으로도, 오늘 사람 눈으로 잡은 감이 ‘사이트 전체의 숫자와 위치’로 또렷해진다. 자가 점검으로 감을 잡았다면, 다음 한 걸음은 자동 검사로 확정하는 것 — 오늘 바로 그 한 걸음을 떼보길 권한다.

마지막으로, 이 글을 동료 한 명에게 공유해주면 좋겠다. 접근성은 한 사람이 챙긴다고 지켜지는 게 아니라, 사이트에 손대는 모두가 조금씩 챙길 때 비로소 유지된다. 콘텐츠 담당자는 대체 텍스트와 자막을, 양식 담당자는 라벨과 오류 안내를, 개발 담당자는 키보드 접근과 색 대비를 — 각자 자기 자리에서 핵심 한두 항목씩만 책임져도 사이트는 눈에 띄게 달라진다. 오늘의 5분이, 누군가에겐 ‘드디어 이 사이트를 쓸 수 있게 된’ 순간으로 이어지길 바란다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #전자정부 #품질관리지침 #대체텍스트 #키보드접근 #색대비 #자막 #자가점검체크리스트 #ViewCheck