웹 접근성, 권장이 아니라 법입니다 (장애인차별금지법)

공감·문제제기

“접근성이요? 그거 나중에 시간 남으면 챙기려고요.”

공공 웹 담당자들과 이야기를 나누다 보면 이 말을 정말 자주 듣는다. 악의가 있어서 하는 말이 아니다. 당장 처리해야 할 일이 산더미인데, ‘눈에 잘 안 보이는’ 접근성까지 챙길 여유가 없다는 솔직한 토로다. 메인 화면 개편하랴, 민원 폭주에 대응하랴, 보안 점검에 품질관리 지침까지 맞추랴 — 하루가 어떻게 가는지 모르는 담당자에게 접근성은 ‘여유 생기면 하는 일’의 맨 끝줄에 밀려나 있다.

나도 그 마음을 안다. 솔직히 처음엔 나도 접근성을 ‘착한 일’ 정도로 여겼다. 시각장애인이나 거동이 불편한 분들을 배려하는, 하면 좋고 안 해도 크게 탈은 안 나는 ‘선택적 미덕’ 같은 거라고 생각했다. 그런데 어느 날 한 선배가 무심코 던진 한마디에 정신이 번쩍 들었다. “그거 안 지키면 소송 걸려.” 농담인 줄 알았는데 진담이었다.

그날 이후로 접근성을 보는 내 시선이 완전히 바뀌었다. 접근성은 ‘배려’가 아니라 ‘의무’였다. 그것도 도덕적 의무가 아니라 ‘법적’ 의무. 우리나라에는 「장애인차별금지 및 권리구제 등에 관한 법률」, 줄여서 장애인차별금지법이라는 게 있고, 이 법은 ‘정보 접근에서 장애를 이유로 차별하지 말 것’을 명문으로 규정하고 있다. 웹사이트도 그 ‘정보’에 포함된다. 다시 말해, 장애가 있는 분이 우리 사이트를 제대로 쓸 수 없게 만들어 두면, 그건 ‘배려가 부족한 것’이 아니라 ‘법을 위반한 것’이 될 수 있다는 뜻이다.

이 글은 바로 그 이야기를 하려고 쓴다. ‘접근성은 권장이 아니라 법이다’라는 한 문장을, 공공 웹을 처음 맡은 담당자도 고개를 끄덕일 수 있게 풀어볼 작정이다. 어려운 법률 용어나 기술 용어는 최대한 쉬운 비유로 바꾸겠다. 휠체어 경사로 이야기부터, 시각장애인이 화면을 ‘듣는’ 방식, 그리고 우리나라 공공 웹이 따라야 하는 KWCAG라는 기준까지 — 차근차근 짚어 가려 한다.

미리 결론부터 말하면 이렇다. 웹 접근성은 ‘장애가 있는 일부 사람을 위한 특별 서비스’가 아니다. ‘모든 사람이 차별 없이 정보에 닿을 수 있게 하는 최소한의 약속’이다. 그리고 공공 영역에서는 이 약속이 법으로 못 박혀 있다. 그러니 “여유 생기면 하겠다”가 아니라 “처음부터 챙겨야 하는 것”이라는 게 이 글의 핵심 메시지다.

조금 더 솔직한 이야기를 보태자면, 공공 웹 담당자라는 자리는 접근성에 관해 늘 ‘끼인 처지’다. 위에서는 “예산도 없는데 그것까지 해야 하느냐”는 압박이 오고, 아래에서는 외주 업체가 “그거 다 맞추면 단가 올라간다”고 난색을 표한다. 정작 그 사이에 끼인 담당자는 ‘이게 정말 안 하면 안 되는 일인지’조차 확신하지 못한 채, 막연한 죄책감과 막연한 안도 사이를 오간다. 이 글은 그 막연함을 걷어내려는 글이다. 접근성이 왜 ‘안 하면 안 되는 일’인지, 그 근거가 어디에 있는지를 분명히 해두면, 적어도 담당자가 윗선과 업체 사이에서 휘둘리지 않을 수 있다.

또 하나 미리 안심시켜 드릴 게 있다. 이 글은 접근성을 ‘무서운 규제’로 겁주려는 글이 아니다. 오히려 그 반대다. 접근성은 한번 제대로 이해하고 나면, ‘별나라 이야기’가 아니라 ‘상식의 연장’이라는 걸 알게 된다. 그리고 그 상식을 점검하는 일은 생각보다 자동화하기 쉽다. 사람이 수천 페이지를 일일이 들여다보지 않아도, 도구가 대신 훑어주는 시대가 됐다. 그래서 이 글의 끝에서는 ‘그래서 우리는 무엇부터 하면 되는지’, 그리고 그 점검을 어떻게 손쉽게 시작할 수 있는지까지 이야기하려 한다.

솔직히 고백하면, 나도 한동안 접근성을 ‘남의 일’처럼 여겼다. 내 주변에 시각장애가 있는 분이 없었고, 내가 만든 사이트를 그런 분이 쓴다는 상상을 구체적으로 해본 적이 없었다. 그런데 우연히 한 시각장애인 사용자가 공공 사이트를 쓰는 영상을 본 적이 있다. 스크린 리더가 빠르게 화면을 읽어 내려가는데, 어떤 버튼 앞에서 그분이 한참을 멈췄다. “이게 뭐지?” 하고 혼잣말을 하면서 이리저리 더듬는 모습. 그 버튼은 우리 같으면 한눈에 ‘아, 신청 버튼이네’ 하고 알았을 평범한 아이콘 버튼이었다. 그 짧은 멈춤을 보고 나서야, 내가 만든 ‘멀쩡한 화면’이 누군가에게는 ‘막힌 벽’일 수 있다는 걸 비로소 실감했다. 접근성은 그렇게, 한 번 그 입장을 ‘보고’ 나면 다시는 가볍게 여길 수 없게 되는 주제다.

이 글의 흐름을 미리 일러두면 이렇다. 먼저 ‘웹 접근성’이라는 말 자체를 휠체어 경사로에 빗대어 쉽게 풀고, 장애가 있는 분들이 실제로 웹을 어떻게 ‘듣고 더듬어’ 쓰는지를 그려본다. 그다음 ‘접근성이 법이다’라는 말의 근거를 장애인차별금지법에서 짚고, 공공 웹이 따라야 하는 KWCAG 33항목이라는 기준이 무엇인지 설명한다. 이어서 실무에서 반복되는 전형적인 접근성 실수를 익명 사례로 보여주고, 마지막으로 ‘우리는 무엇부터 시작하면 되는지’를 단계별로 정리한다. 처음부터 끝까지 ‘어려운 용어를 쉬운 비유로 바꾸는 것’을 원칙으로 삼았으니, 편하게 읽어 내려가면 된다.

본론 1 — 개념·왜 중요한가

■ 웹 접근성이라는 말부터 풀어보자 — 경사로 이야기

‘웹 접근성’이라는 단어가 추상적으로 들린다면, 건물 입구의 경사로를 떠올리면 쉽다.

오래된 관공서 건물을 생각해보자. 입구에 계단만 있고 경사로가 없으면, 휠체어를 탄 분은 그 건물에 들어갈 수가 없다. 건물 안에 아무리 좋은 민원 창구가 있어도, 애초에 ‘들어가는 길’이 막혀 있으면 그 서비스는 그분에게 존재하지 않는 것이나 마찬가지다. 경사로는 바로 그 ‘들어가는 길’을 모두에게 열어주는 장치다.

웹 접근성은 이 경사로를 ‘웹사이트’에 놓는 일이다. 시각장애가 있는 분, 손을 자유롭게 쓰기 어려운 분, 색을 구분하기 어려운 분, 청각에 어려움이 있는 분 — 이런 분들이 우리 사이트에 ‘들어와서’ 필요한 정보를 얻고 일을 처리할 수 있게 길을 터주는 것이다. 계단만 있는 건물처럼, ‘마우스로만 쓸 수 있는 사이트’ ‘눈으로만 읽을 수 있는 사이트’는 누군가에게는 입구가 막힌 건물과 같다.

여기서 중요한 포인트가 하나 있다. 경사로는 휠체어 이용자만을 위한 게 아니라는 점이다. 무거운 짐을 끄는 사람, 유아차를 미는 부모, 다리를 다쳐 깁스를 한 사람, 캐리어를 끄는 여행자 — 경사로가 있으면 이 모두가 편해진다. 웹 접근성도 똑같다. 화면을 읽어주는 기능은 시각장애인만이 아니라, 운전 중에 정보를 듣고 싶은 사람에게도 도움이 된다. 또렷한 색 대비는 색약인 분만이 아니라, 햇빛 아래에서 화면을 보는 모든 사람에게 이롭다. 접근성을 챙기면 ‘특정 소수’가 아니라 ‘전체 사용자’의 경험이 좋아진다. 이걸 두고 흔히 ‘커브컷 효과’라고 부른다. 보도블록의 턱을 깎아 만든 경사면이 휠체어를 위한 것이었지만, 결국 모두가 그 덕을 보는 것처럼 말이다.

조금 더 깊이 들어가 보자. 사람들은 ‘장애’를 ‘영구적인 상태’로만 생각하는 경향이 있다. 하지만 접근성의 관점에서 보면 장애는 훨씬 넓은 스펙트럼이다. 팔이 하나 없는 영구적 장애도 있지만, 팔이 부러져 한동안 깁스를 한 일시적 장애도 있고, 한 손에 아이를 안고 다른 손으로만 폰을 만져야 하는 상황적 장애도 있다. 밝은 햇빛 아래선 누구나 화면이 잘 안 보이고, 시끄러운 지하철에선 누구나 소리를 못 듣는다. 즉, 접근성은 ‘장애인을 위한 것’이라기보다 ‘누구나 처할 수 있는 불리한 상황 전체를 위한 것’에 가깝다. 이 관점을 한번 받아들이면, 접근성이 ‘남의 일’이 아니라 ‘언젠가 내 일’이라는 게 자연스럽게 와닿는다.

그리고 공공 서비스는 이 ‘들어가는 길’을 막으면 안 되는 가장 무거운 책임을 진 영역이다. 민간 쇼핑몰이라면 불편한 사용자가 다른 쇼핑몰로 가면 그만이다. 하지만 증명서를 떼고, 복지를 신청하고, 세금을 내는 공공 서비스는 ‘다른 곳으로 갈 수가 없다.’ 그 기관 사이트가 유일한 창구다. 유일한 창구의 입구를 막아두는 건, 단순한 불편을 넘어 ‘권리의 박탈’에 가깝다. 그래서 공공 웹의 접근성은 ‘있으면 좋은 것’이 아니라 ‘없으면 안 되는 것’이다.

■ 그들은 웹을 ‘본다’기보다 ‘듣고 더듬는다’

접근성을 진짜로 이해하려면, 장애가 있는 분들이 ‘실제로 웹을 어떻게 쓰는지’를 한 번이라도 그려봐야 한다. 우리는 화면을 ‘눈으로’ 보고 ‘마우스로’ 클릭하는 걸 너무 당연하게 여기지만, 모두가 그렇게 쓰는 건 아니다.

전맹 시각장애가 있는 분을 떠올려보자. 이분은 화면을 ‘보지’ 못한다. 대신 ‘스크린 리더’라는 프로그램이 화면의 내용을 음성으로 읽어준다. 화면 위에서부터 아래로, 코드에 적힌 순서대로 “제목, ○○ 안내. 링크, 민원 신청. 버튼, 다음 단계…” 이런 식으로 또박또박 읽어 내려간다. 이분에게 웹페이지는 ‘보이는 그림’이 아니라 ‘들리는 목소리의 흐름’이다.

여기서 문제가 생긴다. 만약 어떤 버튼에 글자 라벨 없이 그림(아이콘)만 들어 있다면? 스크린 리더는 그 그림을 읽지 못한다. “버튼”이라고만 읽거나, 아예 읽지 못하고 건너뛴다. 사용자는 ‘여기 뭔가 누를 게 있는 것 같은데, 누르면 뭐가 되는 거지?’ 하고 멈춰 선다. 눈으로 보는 사람에게는 돋보기 모양 아이콘이 ‘검색’임이 한눈에 보이지만, 듣는 사람에게는 그 아이콘에 ‘검색’이라는 글자 설명이 숨겨져 있지 않으면 그저 정체불명의 버튼일 뿐이다.

이미지도 마찬가지다. 사진이나 그림에는 ‘대체 텍스트’라는 게 붙어 있어야 한다. 화면에 보이지 않는, 그러나 스크린 리더가 읽어주는 ‘이 이미지는 무엇이다’라는 글 설명이다. 행사 안내 포스터를 이미지 한 장으로만 올려두고 대체 텍스트를 안 달면, 시각장애인에게 그 행사는 ‘존재하지 않는 행사’가 된다. 날짜도, 장소도, 신청 방법도 그 이미지 안에 갇혀버리는 것이다.

스크린 리더 사용자의 경험을 조금 더 구체적으로 그려보자. 이분들은 화면 전체를 한눈에 ‘훑어’ 볼 수 없다. 우리는 페이지에 들어가는 순간 ‘아, 위에 메뉴가 있고, 가운데 본문이 있고, 오른쪽에 검색이 있구나’를 0.5초 만에 파악하지만, 듣는 사람은 그게 불가능하다. 처음부터 끝까지 순서대로 들어야 전체 구조를 짐작할 수 있다. 그래서 ‘제목(헤딩)을 잘 달아두는 것’이 무척 중요하다. 잘 정리된 제목은 책의 목차 같은 역할을 해서, 스크린 리더 사용자가 ‘제목만 빠르게 건너뛰며’ 원하는 부분으로 점프할 수 있게 해준다. 반대로 제목 없이 글이 줄줄 이어진 페이지는, 듣는 사람에게 ‘목차 없는 두꺼운 책’처럼 막막하다. 어디쯤 가야 원하는 정보가 나오는지 가늠할 수가 없다.

손을 자유롭게 쓰기 어려운 분들도 생각해보자. 이런 분들은 마우스를 정밀하게 움직이기 어려워 키보드만으로 사이트를 쓰는 경우가 많다. 탭(Tab) 키를 눌러 다음 요소로 이동하고, 엔터로 누르는 식이다. 그런데 어떤 화면은 마우스를 올려야만 메뉴가 펼쳐지거나, 키보드로는 도무지 닿을 수 없는 버튼이 있다. 마우스로만 쓸 수 있게 만들어진 사이트는, 키보드 사용자에게 ‘손잡이 없는 문’과 같다. 분명히 문은 있는데 열 방법이 없는 것이다.

여기에 더해, 반복되는 메뉴를 ‘건너뛰는’ 장치도 중요하다. 모든 페이지 맨 위에는 보통 같은 메뉴가 줄지어 있다. 마우스 사용자는 본문이 보이는 곳을 바로 클릭하면 되지만, 키보드나 스크린 리더 사용자는 페이지를 옮길 때마다 그 긴 메뉴를 처음부터 다시 거쳐야 한다. 페이지를 열 때마다 똑같은 메뉴 스무 개를 매번 듣고 지나가야 한다고 상상해보라. 금세 지친다. 그래서 ‘본문으로 바로 가기’ 같은 건너뛰기 장치를 맨 앞에 두는 것이 KWCAG의 중요한 항목 중 하나다. 작은 장치 하나가 누군가의 수고를 크게 덜어준다.

색만으로 정보를 전달하는 경우도 흔한 함정이다. ‘필수 항목은 빨간색으로 표시했습니다’라는 안내. 색을 구분하기 어려운 분에게 이건 아무 정보도 아니다. 빨강과 초록을 비슷하게 보는 분에게 ‘빨간 글씨’는 그냥 ‘검은 글씨’와 다를 바 없다. 그래서 접근성에서는 ‘색만으로 정보를 전달하지 말 것’을 강조한다. 색과 함께 별표(*)나 ‘필수’라는 글자처럼, 색맹·색약인 분도 알아챌 수 있는 두 번째 단서를 함께 줘야 한다.

청각에 어려움이 있는 분들도 잊으면 안 된다. 공공기관은 정책 설명이나 행사 안내를 동영상으로 만드는 경우가 많은데, 자막이 없으면 청각장애가 있는 분은 그 내용을 알 길이 없다. 영상 속 목소리가 아무리 중요한 안내를 담고 있어도, 자막이라는 ‘글로 된 통로’가 없으면 그 정보는 일부 사용자에게 닿지 않는다. 자막은 청각장애인만을 위한 것도 아니다. 소리를 켤 수 없는 사무실에서, 시끄러운 지하철에서, 영상을 ‘소리 없이 보는’ 모든 사람에게 자막은 고마운 장치다. 여기서도 커브컷 효과가 그대로 작동한다.

이렇게 ‘듣고 더듬어’ 웹을 쓰는 분들의 입장을 한 번이라도 그려보면, 접근성이 왜 ‘디자인 위에 덧칠하는 장식’이 아니라 ‘처음부터 설계에 녹아 있어야 하는 뼈대’인지 이해가 된다. 경사로를 건물 다 짓고 나서 억지로 붙이면 어색하고 위험하듯, 접근성도 나중에 갖다 붙이면 누더기가 된다. 처음부터 ‘모두가 들어올 수 있는 입구’를 염두에 두고 설계해야 자연스럽다.

한 가지 더 덧붙이고 싶은 건, ‘다른 방식으로 웹을 쓰는 사람’이 생각보다 훨씬 많다는 사실이다. 우리는 흔히 ‘장애가 있는 사람은 소수’라고 여기지만, 앞서 말한 일시적·상황적 어려움까지 더하면 그 범위는 훨씬 넓어진다. 노안이 와서 작은 글씨가 흐릿한 어르신, 마우스보다 키보드가 익숙한 사람, 한 손에 짐을 든 채 폰을 만지는 사람, 밝은 야외에서 화면이 안 보이는 사람 — 따지고 보면 ‘완벽하게 이상적인 조건에서 웹을 쓰는 사람’이 오히려 소수일지도 모른다. 접근성은 그 ‘이상적이지 않은 다수’를 모두 품으려는 노력이다. 이렇게 보면 접근성은 ‘특별한 배려’가 아니라 ‘현실적인 보편 설계’에 더 가깝다.

■ 그래서, 접근성은 ‘권장’이 아니라 ‘법’이다

여기까지 읽었다면 접근성이 ‘좋은 일’이라는 건 충분히 와닿았을 거다. 그런데 이 글의 제목은 ‘좋은 일’이 아니라 ‘법’이라고 못 박았다. 왜 그럴까.

우리나라에는 「장애인차별금지 및 권리구제 등에 관한 법률」이 있다. 보통 줄여서 ‘장애인차별금지법’이라고 부른다. 이 법의 핵심 정신은 단순하다. ‘장애가 있다는 이유로 차별받지 않을 권리’를 보장하는 것이다. 그리고 이 ‘차별’의 범위에는 ‘정보 접근에서의 차별’이 명확히 포함된다.

여기서 ‘정보 접근’이 바로 웹과 연결된다. 오늘날 대부분의 행정 정보와 서비스가 웹사이트와 모바일 앱을 통해 제공된다. 그렇다면 그 웹사이트를 장애가 있는 분이 쓸 수 없게 만들어 둔 것은, ‘정보 접근에서 장애를 이유로 차별한 것’이 될 수 있다. 즉, 접근성이 안 된 공공 웹은 단순히 ‘불친절한’ 게 아니라 ‘차별의 도구’가 될 위험을 안고 있다는 뜻이다.

이게 ‘권장이 아니라 법’이라는 말의 핵심이다. 누군가의 호의나 여유에 기대는 ‘하면 좋은 일’이 아니라, 안 하면 ‘차별’이라는 법적 평가를 받을 수 있는 ‘해야만 하는 일’이라는 것. 특히 공공 영역은 ‘모든 국민에게 차별 없이 서비스를 제공할’ 가장 무거운 의무를 진 주체이기 때문에, 이 기준이 더 엄격하게 적용된다.

조금 더 현실적인 이야기를 해보자. 법적 의무라고 하면 ‘처벌’부터 떠올리기 쉬운데, 실무에서 더 자주 마주치는 건 ‘진정과 시정 요구’다. 접근성이 안 된 사이트에 대해 당사자나 단체가 문제를 제기하면, 기관은 이를 들여다보고 고쳐야 하는 상황에 놓인다. 이미 만들어진 사이트를 사후에 뜯어고치는 건, 처음부터 잘 만드는 것보다 훨씬 비싸고 번거롭다. 그래서 ‘법적 의무니까 어쩔 수 없이 한다’가 아니라, ‘나중에 더 큰 비용을 치르지 않으려면 처음부터 챙기는 게 이득이다’라는 실리적 계산으로 접근해도 답은 같다.

또 하나 짚어둘 것은, 접근성은 ‘기관의 평판’과도 직결된다는 점이다. 공공기관은 국민의 신뢰를 먹고 사는 조직이다. ‘장애인이 쓸 수 없는 공공 사이트’라는 사실이 알려지면, 그건 단순한 기능 결함이 아니라 ‘이 기관이 국민 일부를 배제하고 있다’는 이미지로 번진다. 반대로 접근성을 잘 챙긴 기관은 ‘모두를 위한 행정’이라는 신뢰를 얻는다. 접근성은 법적 리스크인 동시에 평판 자산이기도 하다.

여기서 오해 하나를 풀고 가자. ‘법적 의무’라고 하면 마치 엄청나게 까다롭고 전문적인 일처럼 느껴지지만, 실제로 접근성이 요구하는 것의 상당수는 ‘기본을 지키는 것’에 가깝다. 이미지에 설명을 달고, 버튼에 이름을 붙이고, 키보드로도 조작되게 하고, 색만으로 정보를 전달하지 않는 것 — 이런 것들은 별난 기술이 아니라 ‘꼼꼼함’의 문제다. 법이 요구하는 건 화려한 기능이 아니라, ‘아무도 배제되지 않게 하는 기본기’다.

조금 다른 각도에서도 생각해보자. 법이라는 게 보통 ‘하지 말 것’을 정하는 경우가 많은데, 접근성 관련 법은 결이 조금 다르다. ‘차별하지 말라’는 금지의 형태를 띠지만, 실질적으로는 ‘모두가 닿을 수 있게 하라’는 적극적인 요청에 가깝다. 그래서 이 법을 ‘피해야 할 함정’으로 보면 늘 쫓기는 기분이 되지만, ‘지향해야 할 방향’으로 보면 오히려 일에 의미가 생긴다. 내가 만든 사이트가 누군가에게 ‘닫혀 있던 문’을 열어준다는 건, 행정 실무에서 좀처럼 느끼기 어려운 종류의 보람이다. 법이라는 딱딱한 표현 뒤에는 ‘아무도 소외되지 않는 행정’이라는 따뜻한 지향이 있다.

또 하나, 공공 영역이 접근성에서 앞장서야 하는 데는 상징적인 이유도 있다. 공공기관이 ‘모두를 위한 웹’의 본보기를 보이면, 그 기준은 자연스럽게 사회 전체로 번진다. 반대로 공공 사이트조차 누군가를 배제한다면, ‘그 정도는 괜찮다’는 잘못된 신호를 사회에 주게 된다. 공공이 가진 무게가 그만큼 크다. 접근성을 잘 챙긴 공공 웹은 단지 그 사이트 하나가 좋아지는 데서 그치지 않고, ‘이게 표준이다’라는 메시지를 사회에 던지는 셈이다.

■ 그 기준이 바로 KWCAG다 — 33항목의 정체

“접근성을 지키라는 건 알겠는데, 그래서 구체적으로 뭘 어떻게 하라는 거예요?” 당연히 나올 질문이다. ‘잘하라’는 말만으로는 무엇을 해야 할지 알 수 없다. 그래서 우리나라에는 공공 웹이 따라야 하는 구체적인 접근성 기준이 정해져 있다. 그게 바로 KWCAG(Korean Web Content Accessibility Guidelines), 한국형 웹 콘텐츠 접근성 지침이다.

KWCAG는 국제적으로 통용되는 웹 접근성 기준을 한국 환경에 맞게 정리한 것으로, 공공 웹이 지켜야 할 접근성 항목을 구체적으로 나열해둔 ‘체크리스트’라고 보면 된다. 우리 프로젝트에서는 이를 33항목으로 다룬다. 이 33개 항목이 결국 ‘우리 사이트가 접근성을 지켰는지 안 지켰는지’를 판단하는 기준선이 된다.

33개라고 하면 또 막막할 수 있는데, 큰 줄기로 묶어보면 이해하기 쉽다. 국제 표준은 접근성을 네 가지 원칙으로 정리하는데, 이 틀을 빌리면 KWCAG 항목들도 자연스럽게 분류된다.

첫째, ‘인식의 용이성’이다. 사용자가 콘텐츠를 ‘인식할 수 있어야 한다’는 원칙이다. 이미지에 대체 텍스트를 다는 것, 동영상에 자막을 다는 것, 색에만 의존하지 않는 것, 글자와 배경의 색 대비를 충분히 두는 것 같은 항목이 여기 속한다. 한마디로 ‘보이지 않거나 들리지 않는 사람도 내용을 받아들일 수 있게 하라’는 것이다.

둘째, ‘운용의 용이성’이다. 사용자가 화면을 ‘조작할 수 있어야 한다’는 원칙이다. 키보드만으로 모든 기능을 쓸 수 있게 하는 것, 깜빡이는 콘텐츠로 발작을 유발하지 않는 것, 시간제한을 함부로 두지 않는 것, 반복되는 메뉴를 건너뛸 수 있게 하는 것 같은 항목이 여기 들어간다. ‘마우스를 못 쓰거나, 빠르게 조작하기 어려운 사람도 끝까지 쓸 수 있게 하라’는 것이다.

셋째, ‘이해의 용이성’이다. 콘텐츠와 조작 방식을 ‘이해할 수 있어야 한다’는 원칙이다. 페이지의 언어를 명시하는 것, 입력 양식에 명확한 라벨을 붙이는 것, 오류가 났을 때 무엇이 잘못됐고 어떻게 고쳐야 하는지 친절히 안내하는 것 같은 항목이다. ‘읽고 쓰는 데 어려움이 있는 사람도 헤매지 않게 하라’는 것이다.

넷째, ‘견고성’이다. 다양한 기술 환경에서 ‘안정적으로 작동해야 한다’는 원칙이다. 스크린 리더 같은 보조기술이 콘텐츠를 제대로 해석할 수 있도록 코드를 표준에 맞게 짜는 것이 핵심이다. ‘어떤 보조기술을 쓰든 내용이 깨지지 않게 하라’는 것이다.

이 네 원칙(인식·운용·이해·견고)을 머리에 넣어두면, KWCAG 33항목이 어디에 어떻게 흩어져 있는지 큰 그림이 잡힌다. 항목 하나하나를 외울 필요는 없다. ‘아, 이건 인식의 문제구나’ ‘이건 키보드로 못 쓰니까 운용의 문제구나’ 하고 분류할 수 있으면, 점검할 때 무엇을 봐야 할지 감이 온다. 운전자가 도로교통법 조항을 다 외우지 않아도 ‘신호 지키기, 안전거리, 보행자 보호’라는 큰 원칙으로 운전하는 것과 같은 이치다.

그리고 여기서 KWCAG와 앞서 이야기한 KRDS의 관계도 한번 짚어두자. KRDS는 공공 웹의 디자인 전반을 다루는 846개의 큰 틀이고, 접근성은 그 틀 안에 깊숙이 녹아 있는 핵심 가치다. KRDS의 컴포넌트 규칙들이 ‘버튼에 이름을 붙여라, 폼에 라벨을 달아라, 색 대비를 지켜라’를 요구하는 것 자체가 결국 KWCAG가 말하는 접근성과 같은 방향을 가리킨다. 둘은 따로 노는 게 아니라, 같은 목표를 향해 서로를 떠받치는 관계다. KRDS를 잘 지키면 접근성도 상당 부분 따라오고, 접근성을 챙기면 KRDS의 핵심을 자연스럽게 충족하게 된다.

조금 더 풀어보면 이렇다. KRDS의 네 영역(DS·CP·BP·SP)을 접근성의 렌즈로 다시 들여다보면, 각 영역마다 접근성이 스며 있는 지점이 보인다. DS의 ‘색 대비’ 규칙은 그 자체로 KWCAG의 인식 항목과 맞닿아 있다. 글자와 배경의 명도 차가 충분해야 저시력인 분도, 햇빛 아래 화면을 보는 사람도 글을 읽을 수 있다. CP의 ‘버튼·폼 라벨’ 규칙은 운용·이해 항목과 직결된다. 부품 하나하나에 이름이 제대로 붙어 있어야 보조기술이 그걸 읽어 안내할 수 있다. BP의 ‘오류 안내’ 패턴은 이해 항목과 맞물린다. 무엇이 틀렸고 어떻게 고쳐야 하는지를 친절히 알려주는 흐름이 곧 접근성이다. SP의 ‘서비스 여정’은 견고성과 운용을 아우른다. 검색부터 신청 완료까지 어느 한 단계도 끊기지 않아야, 보조기술 사용자도 끝까지 일을 마칠 수 있다. 이렇게 보면 KRDS와 접근성은 별개의 숙제가 두 개 있는 게 아니라, 하나의 좋은 설계가 두 기준을 동시에 만족시키는 구조다.

그래서 나는 접근성을 ‘KRDS에 덧붙는 별도 작업’으로 보지 말라고 권한다. 오히려 ‘KRDS를 제대로 따르는 과정에서 자연스럽게 챙겨지는 것’으로 보는 편이 마음이 편하다. 일을 두 배로 늘리는 게 아니라, 한 번 잘 만들면 두 마리 토끼가 함께 잡힌다는 관점. 이 관점이 담당자의 부담을 크게 덜어준다.

■ 접근성은 ‘비용’이 아니라 ‘투자’다

접근성을 ‘추가 비용’으로만 보는 시각이 여전히 많다. “그거 맞추면 단가 올라가잖아요”라는 업체의 말, “예산도 빠듯한데 거기까지…”라는 윗선의 말. 이 말들이 틀린 건 아니지만, 절반만 맞는 이야기다.

먼저, 접근성을 ‘처음부터’ 챙기면 추가 비용은 생각보다 크지 않다. 이미지에 대체 텍스트를 다는 것, 버튼에 이름을 붙이는 것, 키보드 동작을 함께 지원하는 것 — 이런 일들은 ‘설계 단계에서 습관처럼’ 하면 추가 공수가 거의 들지 않는다. 비용이 폭발하는 건 ‘다 만들어 놓고 나중에 뜯어고칠 때’다. 경사로를 건물 설계 도면에 처음부터 넣으면 자연스러운 일이지만, 다 지어진 건물에 경사로를 붙이려면 벽을 부수고 구조를 손봐야 하는 것과 같다. 즉, 접근성의 비용은 ‘하느냐 마느냐’보다 ‘언제 하느냐’에서 갈린다.

다음으로, 접근성은 ‘리스크를 줄이는 투자’다. 앞서 이야기했듯 접근성이 안 된 공공 웹은 법적 진정과 시정 요구의 대상이 될 수 있다. 그 상황이 닥치면 급하게, 비싸게, 그것도 외부의 압박 속에서 고쳐야 한다. 평소에 차곡차곡 챙겨두면 그런 ‘소방 작업’을 피할 수 있다. 보험에 가입하는 것과 비슷하다. 평소엔 손해처럼 느껴지지만, 막상 일이 터졌을 때 그 가치가 드러난다.

마지막으로, 접근성은 ‘전체 사용자의 만족도’를 끌어올리는 투자다. 앞서 말한 커브컷 효과를 떠올려보자. 명확한 라벨, 또렷한 색 대비, 키보드 지원, 친절한 오류 안내 — 이 모든 게 장애가 있는 분만이 아니라 ‘모든 사용자’의 경험을 좋게 만든다. 접근성이 좋은 사이트는 대체로 ‘누가 써도 편한 사이트’다. 그러니 접근성에 들이는 노력은 소수를 위한 비용이 아니라, 다수를 위한 품질 향상이기도 하다. 한 번의 투자로 여러 가치를 동시에 거두는 셈이다.

■ 담당자들이 자주 묻는 접근성 오해들

접근성을 처음 진지하게 들여다보는 담당자들이 공통적으로 던지는 질문, 혹은 흔히 갖는 오해 몇 가지를 풀어두자. 이 오해들이 풀리면 접근성이 한결 가깝게 느껴진다.

첫 번째 오해. “우리 사이트엔 장애인이 별로 안 들어와요.” 이 말은 위험한 착각이다. 접근성이 안 된 사이트는 ‘장애가 있는 분이 들어왔다가 못 쓰고 나간’ 경우가 많은데, 그건 방문 기록에 ‘이탈’로만 남을 뿐 ‘접근성 때문에 떠났다’고 표시되지 않는다. 즉, ‘장애인이 안 온다’가 아니라 ‘못 써서 못 온다’일 가능성이 크다. 입구가 막힌 건물에 휠체어 이용자가 안 오는 걸 두고 ‘여긴 휠체어 이용자가 원래 안 와’라고 말하는 것과 같다. 인과가 거꾸로다.

두 번째 오해. “접근성은 디자인을 못생기게 만든다.” 전혀 그렇지 않다. 앞의 사례에서 봤듯, 버튼에 보조기술용 이름을 붙이는 일은 화면 디자인을 한 픽셀도 바꾸지 않는다. 색 대비를 충분히 두는 것은 오히려 화면을 더 또렷하고 읽기 좋게 만든다. 접근성과 미감은 충돌하는 게 아니라, 잘 설계하면 같이 간다. ‘접근성을 챙기면 못생겨진다’는 건 접근성을 ‘나중에 억지로 덧붙일 때’ 생기는 오해일 뿐이다.

세 번째 오해. “접근성은 전문가만 할 수 있는 어려운 일이다.” 물론 깊이 들어가면 전문성이 필요한 영역도 있다. 하지만 앞서 본 것처럼 접근성이 요구하는 것의 상당수는 ‘기본을 빠뜨리지 않는 꼼꼼함’이다. 그리고 그 꼼꼼함을 점검하는 일은 자동 도구가 상당 부분 대신해준다. 담당자가 직접 코드를 짤 필요도, 스크린 리더 전문가가 될 필요도 없다. ‘무엇이 빠졌는지’를 도구가 알려주면, 그걸 업체에 정확히 요구하는 것만으로도 큰 진전이다.

네 번째 오해. “한 번 접근성을 맞춰두면 끝이다.” 아쉽게도 아니다. 사이트는 살아 있는 생물이라 끊임없이 새 페이지가 추가되고 콘텐츠가 바뀐다. 오늘 잘 맞춰둔 사이트도, 다음 달 새로 올린 공지에서 대체 텍스트가 빠지면 그만큼 접근성이 무너진다. 그래서 접근성은 ‘한 번의 공사’가 아니라 ‘지속적인 관리’다. 주기적으로 진단을 돌려 ‘새로 생긴 문제’를 잡아주는 습관이 필요한 이유다.

본론 2 — 흔한 실수·사례 (익명)

개념만 들으면 ‘그래서 실제로 뭐가 문제인데?’ 싶을 수 있다. 그래서 실무에서 자주 마주치는 접근성 문제를 익명으로 풀어보겠다. 아래 사례들은 특정 기관 이야기가 아니라, 공공 사이트를 점검하다 보면 패턴처럼 반복되는 전형적인 문제들이다.

미리 양해를 구하자면, 여기서 드는 사례에는 어떤 실제 기관명도, 도메인도, 식별 가능한 정보도 들어 있지 않다. 모두 여러 사이트에서 공통적으로 관찰되는 ‘유형’을 익명으로 재구성한 것이다. 특정 기관을 비판하려는 게 아니라, ‘기준 없이 만들면 누구에게나 일어나는 일’임을 보여주려는 의도다. 읽다가 ‘어, 우리 사이트 얘긴가?’ 싶은 대목이 있다면, 그건 그만큼 흔한 문제라는 뜻이지 당신 기관만의 문제가 아니다.

■ 사례 하나: 이름 없는 버튼들

한 기초 단위 지자체(○○구라고 하자) 사이트를 점검한 적이 있다고 치자. 화면은 깔끔했다. 상단에 돋보기 모양 검색 버튼, 옆에 종 모양 알림 버튼, 그 옆에 사람 모양 로그인 버튼이 나란히 있었다. 눈으로 보면 누구나 ‘아, 검색·알림·로그인이구나’ 하고 안다.

그런데 스크린 리더로 그 화면을 ‘들어’ 보면 전혀 다른 세상이 펼쳐진다. “버튼. 버튼. 버튼.” 이게 끝이다. 세 개의 버튼이 모두 ‘버튼’이라고만 읽힌다. 아이콘에 글자 설명이 숨겨져 있지 않아서, 스크린 리더는 그 그림이 무엇을 뜻하는지 알 도리가 없다. 눈으로 보는 사람에게는 명확한 세 기능이, 듣는 사람에게는 정체불명의 세 ‘버튼’으로 뭉뚱그려지는 것이다.

이게 바로 KWCAG ‘인식·운용’ 차원의 대표적인 문제다. 해법은 의외로 간단하다. 각 버튼에 화면에는 안 보이지만 보조기술은 읽을 수 있는 이름(레이블)을 달아주면 된다. ‘검색’ ‘알림’ ‘로그인’이라는 글자 정보를 코드 안에 심어두는 것이다. 디자인은 한 픽셀도 바뀌지 않는다. 눈으로 보는 사람은 여전히 깔끔한 아이콘을 보고, 듣는 사람은 비로소 “검색 버튼, 알림 버튼, 로그인 버튼”이라고 또렷이 듣게 된다. 적은 노력으로 큰 차이를 만드는 전형적인 사례다.

이 사례에서 정작 중요한 건, 담당자나 업체가 ‘게을러서’ 이렇게 만든 게 아니라는 점이다. 대부분은 ‘아이콘에 이름을 따로 달아야 한다’는 사실 자체를 몰랐을 뿐이다. 눈으로 보면 멀쩡하니, 문제가 있다는 걸 알아챌 계기가 없었던 것이다. 이게 접근성의 까다로운 지점이다. 만든 사람 눈에는 아무 문제가 없어 보인다. 문제는 ‘다른 방식으로 쓰는 사람’의 화면에서만 드러난다. 그래서 접근성은 ‘내 눈’이 아니라 ‘도구의 눈’으로 점검해야 한다.

■ 사례 둘: 마우스 없이는 갈 수 없는 길

또 다른 흔한 문제는 ‘키보드로 닿을 수 없는 기능’이다. 어떤 한중앙부처 산하 B공공기관 사이트에서, 상단 메뉴가 마우스를 올려야만 펼쳐지는 구조로 돼 있었다고 치자. 마우스를 쓰는 사람에게는 자연스럽다. 메뉴에 마우스를 가져다 대면 하위 메뉴가 스르륵 펼쳐진다.

하지만 키보드만 쓰는 사용자에게 이건 막다른 길이다. 탭 키로 메뉴까지는 이동할 수 있어도, ‘마우스를 올리는’ 동작을 키보드로는 흉내 낼 수 없으니 하위 메뉴가 영영 펼쳐지지 않는다. 메뉴 안에 있는 ‘민원 신청’ ‘서식 다운로드’ 같은 핵심 기능에 키보드 사용자는 닿을 수가 없다. 분명히 메뉴는 보이는데, 그 안으로 들어가는 길이 없는 것이다.

이건 KWCAG ‘운용의 용이성’ 중에서도 ‘키보드 접근성’ 항목에 해당한다. 해법은 ‘마우스를 올렸을 때’뿐 아니라 ‘키보드로 초점을 맞췄을 때나 엔터로 눌렀을 때’도 메뉴가 펼쳐지게 만드는 것이다. 이렇게 해두면 마우스 사용자도, 키보드 사용자도, 그리고 키보드 비슷하게 작동하는 보조기기를 쓰는 사용자도 모두 같은 길로 들어갈 수 있다.

여기서 한 가지 더 짚어둘 게 있다. 키보드 접근성은 ‘초점이 지금 어디 있는지 보이는가’와도 연결된다. 키보드로 탭을 눌러 이동할 때, 지금 초점이 어느 버튼에 가 있는지 화면에 테두리 같은 표시가 떠야 한다. 그런데 어떤 사이트는 ‘디자인이 지저분해 보인다’는 이유로 이 초점 표시를 일부러 없애버린다. 마우스 사용자에겐 거슬리지 않을지 몰라도, 키보드 사용자에겐 ‘내가 지금 어디 있는지 모르는 채로 어둠 속을 더듬는’ 상황이 된다. 초점 표시는 지저분한 게 아니라 ‘길 안내 표지판’이다. 없애면 안 된다.

■ 사례 셋: 색깔로만 말하는 안내문

세 번째는 ‘색에만 기댄 정보 전달’이다. A광역지자체의 한 신청 페이지에서, 입력 양식의 필수 항목을 ‘빨간 글씨’로만 표시했다고 치자. ‘빨간색으로 표시된 항목은 반드시 입력해 주세요’라는 안내와 함께.

색을 또렷이 구분하는 사람에게는 아무 문제가 없다. 빨간 글씨가 눈에 확 들어온다. 하지만 적록색약이 있는 분에게 빨강과 검정은 비슷하게 보인다. ‘어디가 필수 항목이지?’ 한참을 헤매다, 결국 필수 항목을 빠뜨린 채 ‘제출’을 누른다. 그러면 오류가 뜨고, 또 어디가 틀렸는지 색으로만 표시돼서 다시 헤맨다. 악순환이다.

이건 KWCAG ‘인식의 용이성’ 중 ‘색에 무관한 콘텐츠 인식’ 항목의 전형적인 위반이다. 해법은 ‘색은 그대로 쓰되, 색 말고 다른 단서를 하나 더 주는 것’이다. 필수 항목 옆에 별표(*)를 붙이거나 ‘(필수)’라는 글자를 넣으면, 색을 구분하기 어려운 분도 ‘아, 여기가 필수구나’ 하고 안다. 색을 빼라는 게 아니라, 색에만 의존하지 말라는 것이다. 단서를 ‘두 겹’으로 주면 더 많은 사람이 정보를 놓치지 않는다.

■ 사례 넷: 읽어주는 순서가 뒤죽박죽인 화면

네 번째는 조금 덜 알려졌지만 의외로 흔한 문제다. 바로 ‘읽는 순서가 엉킨 화면’이다. C기관의 한 안내 페이지에서, 눈으로 보면 ‘제목 → 본문 → 신청 버튼’ 순으로 위에서 아래로 자연스럽게 배치돼 있었다고 치자. 그런데 스크린 리더로 들어보니, ‘신청 버튼’을 먼저 읽고, 그다음 본문 중간을 읽고, 마지막에 제목을 읽는 식으로 순서가 뒤죽박죽이었다.

이유는 화면에 ‘보이는 순서’와 코드에 ‘적힌 순서’가 다르기 때문이다. 디자인을 맞추느라 요소들의 위치를 화면상에서만 이리저리 옮겨두면, 코드 안의 순서는 그대로인 채로 겉모습만 바뀐다. 눈으로 보는 사람은 위치만 보니 문제가 없지만, 코드 순서대로 읽는 스크린 리더 사용자에게는 ‘이야기의 순서가 뒤엉킨 책’을 읽는 꼴이 된다. 결론을 먼저 듣고, 도입을 나중에 듣는 황당한 경험이다.

이건 KWCAG의 ‘이해의 용이성’과 ‘견고성’에 동시에 걸치는 문제다. 해법은 ‘화면에 보이는 순서’와 ‘코드에 적힌 순서’를 일치시키는 것이다. 시각적 배치를 위해 순서를 흐트러뜨릴 일이 있어도, 보조기술이 읽는 흐름이 논리적으로 자연스럽게 유지되도록 신경 써야 한다. 눈으로만 점검하면 절대 안 잡히는 문제라, 이런 항목일수록 도구의 점검이 빛을 발한다.

이 네 사례를 관통하는 공통점이 있다. 네 경우 모두 ‘눈으로 보는 일반적인 사용자에게는 멀쩡해 보인다’는 것이다. 만든 사람도, 검수한 사람도, 윗선도 화면을 ‘눈으로’ 보기 때문에 문제를 못 느낀다. 문제는 오직 ‘다른 방식으로 쓰는 사람’의 입장에서만 드러난다. 그래서 접근성 점검의 핵심은 ‘내 감각을 잠시 내려놓고, 다른 감각으로 화면을 다시 보는 것’이다. 그리고 사람이 매번 그렇게 점검하기는 어렵기 때문에, 도구의 힘을 빌리는 게 현실적인 답이 된다.

또 하나 강조하고 싶은 건, 이런 문제들이 ‘악의’나 ‘무능’에서 비롯된 게 아니라는 점이다. 대부분은 ‘몰라서’ 혹은 ‘눈에 안 보여서’ 생긴다. 만드는 사람도, 검수하는 사람도 자기 눈으로만 화면을 보기 때문에, 다른 감각으로 쓰는 사용자의 벽을 체감할 기회가 없다. 그래서 접근성은 ‘더 열심히 하라’고 다그친다고 해결되지 않는다. ‘다른 눈’을 빌려와야 비로소 보인다. 그 다른 눈이 바로 자동 진단 도구다.

본론 3 — 자동 검사라는 현실적 해법

■ 사람이 수천 페이지를 다 볼 수는 없다

앞의 사례들을 읽으며 ‘그럼 이걸 다 일일이 확인해야 하나’ 하고 한숨이 나왔을 수도 있다. 맞다. 그게 가장 큰 현실적 벽이다.

공공 사이트는 보통 페이지가 수백, 많게는 수천 개에 이른다. 부서마다, 사업마다, 공지마다 페이지가 쌓인다. 이 모든 페이지의 모든 버튼에 이름이 붙어 있는지, 모든 이미지에 대체 텍스트가 있는지, 모든 기능이 키보드로 되는지, 모든 색 대비가 충분한지를 사람이 일일이 확인하는 건 사실상 불가능하다. 한 페이지를 꼼꼼히 점검하는 데만도 시간이 꽤 걸리는데, 그게 수천 배라면 답이 안 나온다.

게다가 사람의 점검은 일관되지 않다. 같은 사람이 봐도 오전과 오후가 다르고, 사람이 바뀌면 기준도 바뀐다. 어제는 잡아낸 문제를 오늘은 놓치기도 한다. 피곤하면 대충 보게 되고, 익숙해지면 ‘이 정도면 됐겠지’ 하고 넘어가게 된다. 접근성처럼 ‘꼼꼼함’이 생명인 일에서, 사람의 변덕은 치명적인 약점이다.

그래서 접근성 점검의 상당 부분은 ‘자동화’가 답이다. 다행히 접근성 항목의 많은 부분은 기계가 판정하기에 적합하다. ‘이미지에 대체 텍스트 속성이 있는가 없는가’ ‘버튼에 이름이 붙어 있는가’ ‘글자와 배경의 색 대비 수치가 기준을 넘는가’ ‘페이지에 언어가 명시돼 있는가’ 같은 항목들은, 코드를 들여다보면 기계가 빠르고 정확하게 판정할 수 있다. 사람이 수천 페이지를 며칠에 걸쳐 볼 일을, 도구는 몇 분 만에 훑는다. 그것도 졸지 않고, 변덕 없이, 매번 같은 기준으로.

물론 모든 접근성 항목이 100% 자동으로 판정되는 건 아니다. ‘이 대체 텍스트가 이미지의 의미를 제대로 설명하고 있는가’ 같은 ‘의미의 적절성’은 결국 사람의 판단이 필요하다. 그래서 가장 좋은 방식은 ‘기계가 거를 수 있는 건 기계가 빠짐없이 거르고, 사람은 기계가 표시해준 의심 지점에 집중하는’ 역할 분담이다. 사람이 백지에서 수천 페이지를 뒤지는 게 아니라, 도구가 짚어준 곳을 사람이 확인하는 식이다. 이러면 점검의 양도, 누락도 확 줄어든다.

■ ViewCheck — 접근성을 자동으로 훑어주는 진단

이쯤에서 자연스럽게 우리 서비스 이야기를 꺼내려 한다. 바로 이 ‘자동 접근성 검사’를 누구나 손쉽게 쓸 수 있게 만든 게 ViewCheck다.

ViewCheck는 공공 웹사이트의 KRDS 준수 여부와 웹 품질을 자동으로 진단해주는 서비스다. 사이트 주소만 넣으면, 그 사이트의 여러 페이지를 자동으로 돌아다니며 KRDS 846규칙(디자인 기반 요소 DS 120개, 컴포넌트 CP 446개, 기본 패턴 BP 108개, 서비스 패턴 SP 172개)을 점검한다. 그리고 그 안에 오늘 이야기한 접근성, 즉 KWCAG 33항목 점검이 함께 들어 있다.

접근성 측면에서 ViewCheck가 자동으로 훑는 것들을 몇 가지만 들면 이렇다. 이미지에 대체 텍스트가 빠져 있지는 않은지, 버튼이나 링크에 이름이 없는 건 아닌지, 입력 양식에 라벨이 제대로 연결돼 있는지, 글자와 배경의 색 대비가 기준에 못 미치지는 않는지, 페이지에 언어가 명시돼 있는지, 키보드로 초점을 옮길 때 표시가 보이는지 — 앞서 사례로 든 문제들의 상당수를 자동으로 잡아낸다. 사람이 한 페이지씩 스크린 리더로 들어보고, 키보드로 더듬어보고, 색 대비를 재보는 수고를, 도구가 대신 빠르게 처리한다.

특히 공공 웹의 핵심인 ‘다중 페이지’ 점검이 중요하다. 메인 화면 하나만 접근성이 좋다고 사이트 전체가 좋은 게 아니다. 메인은 멀쩡한데 깊숙한 신청 페이지에서 접근성이 무너지는 경우가 허다하다. ViewCheck는 사이트의 여러 페이지를 함께 점검해, ‘어느 페이지에서 어떤 접근성 항목이 걸리는지’를 보여준다. ‘우리 사이트 메인은 괜찮은데 정작 민원 신청 흐름에서 키보드 접근이 막혀 있더라’ 같은, 사람이 놓치기 쉬운 사각지대를 비춰주는 것이다.

그리고 ViewCheck는 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)을 함께 본다. 접근성은 그 7대 영역 중 하나이고, 나머지 영역들과 맞물려 ‘우리 사이트가 공공 웹으로서 전반적으로 어느 수준인지’를 한눈에 보여준다. 접근성만 따로 떼어 보는 게 아니라, 사이트의 품질 전체 그림 속에서 접근성의 위치를 가늠할 수 있다는 게 강점이다.

여기서 한 가지 강조하고 싶은 건, 자동 진단이 ‘사람을 대신하는 것’이 아니라 ‘사람을 돕는 것’이라는 점이다. 앞서도 말했듯 ‘이 대체 텍스트가 정말 적절한가’ 같은 의미의 판단은 결국 사람의 몫이다. ViewCheck가 하는 일은 ‘사람이 봐야 할 곳을 정확히 짚어주는 것’이다. 수천 페이지 중에서 ‘여기, 여기, 여기가 의심스럽다’고 표시해주면, 담당자는 백지에서 헤매는 대신 그 지점들만 집중해서 확인하면 된다. 점검의 출발점을 ‘막막한 전부’에서 ‘구체적인 몇 곳’으로 바꿔주는 것. 이게 자동 진단이 실무자에게 주는 가장 큰 선물이다.

비용 측면에서도 의미가 크다. 외부 전문가에게 사이트 전체 접근성 점검을 맡기는 건 시간도 돈도 적지 않게 든다. 물론 깊이 있는 전문 컨설팅이 필요한 순간이 있지만, ‘평소에 우리 사이트가 어떤 상태인지’를 수시로 확인하는 일까지 매번 외부에 맡길 수는 없다. 자동 진단은 그 ‘일상적인 건강검진’을 담당자가 직접, 자주, 부담 없이 할 수 있게 해준다. 그렇게 평소에 챙겨두면, 정작 중요한 전문 점검은 ‘정말 필요한 곳’에만 집중해서 받을 수 있다.

■ 결과를 ‘읽을 수 있게’ 보여준다

자동 진단의 가치는 ‘많이 찾아내는 것’만이 아니라 ‘찾은 걸 알아보기 쉽게 보여주는 것’에 있다. 아무리 많은 문제를 찾아내도, 그게 알아볼 수 없는 형태로 쏟아지면 담당자는 또 막막해진다.

ViewCheck는 진단이 끝나면 결과 화면 상단에 점수 카드를 보여준다. ‘우리 사이트가 지금 어느 수준인지’를 한눈에 들어오는 숫자와 카드 형태로 정리해주는 것이다. 접근성이 지금 몇 점인지, 어떤 항목에서 주로 걸리는지가 직관적으로 드러난다. 윗선에 보고할 때도, 외주 업체에 개선을 요구할 때도, 이 점수 카드 한 장이면 ‘느낌’이 아니라 ‘근거’로 이야기할 수 있다.

“좀 더 신경 써 주세요”가 아니라 “접근성 점수가 지금 이 수준이고, 이미지 대체 텍스트 누락이 이만큼, 버튼 이름 누락이 이만큼이니 이걸 먼저 잡아 주세요”라고 말할 수 있게 되는 것이다. 모호한 요구가 구체적인 요구가 되고, 구체적인 요구는 검수 가능한 요구가 된다. 접근성처럼 ‘눈에 잘 안 보이는’ 일일수록, 이렇게 숫자와 항목으로 만들어 손에 쥐여주는 게 큰 힘이 된다.

■ 그래서 우리는 무엇부터 시작하면 될까

여기까지 읽고 ‘좋아, 그래서 당장 뭘 해야 하지?’ 싶은 담당자를 위해, 현실적인 시작 단계를 정리해보겠다. 한꺼번에 다 하려 들면 또 막막해지니, ‘작게 시작해서 점점 키우는’ 순서로 권한다.

첫 단계는 ‘현황 파악’이다. 우리 사이트가 지금 접근성 측면에서 어디에 서 있는지부터 알아야 한다. 좋은 점도 나쁜 점도 모르는 채로는 무엇을 고쳐야 할지 정할 수 없다. 자동 진단을 한 번 돌려 ‘우리 사이트 접근성이 지금 몇 점이고, 어떤 항목이 주로 걸리는지’를 확인하는 게 출발점이다. 이 한 번의 점검이 ‘막연한 불안’을 ‘구체적인 과제 목록’으로 바꿔준다.

두 번째 단계는 ‘영향 큰 것부터 잡기’다. 진단 결과를 보면 보통 몇 가지 문제가 ‘여러 페이지에서 반복’되는 걸 발견하게 된다. 예를 들어 ‘이미지 대체 텍스트 누락’이 사이트 전반에 깔려 있다거나, ‘버튼 이름 누락’이 공통 메뉴마다 박혀 있다거나. 이렇게 ‘넓게 퍼진 공통 문제’부터 잡으면, 한 번의 수정으로 수많은 페이지가 동시에 개선된다. 가장 적은 노력으로 가장 큰 효과를 내는 지점이다.

세 번째 단계는 ‘핵심 흐름 챙기기’다. 모든 페이지를 똑같이 챙길 수 없다면, 적어도 ‘국민이 꼭 거쳐야 하는 흐름’만큼은 빠짐없이 접근 가능하게 만들어야 한다. 민원을 신청하는 흐름, 증명서를 발급받는 흐름, 중요한 안내를 확인하는 흐름. 이런 핵심 여정에서 키보드가 막히거나 라벨이 빠져 있으면, 그건 곧 ‘누군가는 그 서비스를 아예 이용할 수 없다’는 뜻이다. 우선순위를 둘 때는 ‘얼마나 많은 사람이, 얼마나 중요한 일을 위해 그 페이지를 거치는가’를 기준으로 삼으면 된다.

네 번째 단계는 ‘습관으로 만들기’다. 한 번 고쳐놓아도, 새 페이지를 만들 때마다 접근성을 빠뜨리면 다시 원점이다. 그래서 ‘새로 만들거나 개편할 때마다 접근성을 기본 점검 항목에 넣는 것’이 중요하다. 외주 발주 시 접근성을 검수 기준에 명시하고, 산출물을 받을 때 자동 진단으로 한 번 확인하는 절차를 두면, 접근성이 ‘특별히 챙기는 일’이 아니라 ‘당연히 거치는 절차’가 된다. 이렇게 절차에 녹아들면, 담당자가 바뀌어도 품질이 유지된다.

이 네 단계를 관통하는 정신은 하나다. ‘완벽’이 아니라 ‘진전’을 목표로 삼는 것. 접근성은 한 번에 100점을 맞는 시험이 아니라, 어제보다 오늘 한 걸음 더 나아가는 꾸준함의 영역이다. 첫걸음이 가장 어렵게 느껴지지만, 사실 첫걸음은 ‘현재 상태를 확인하는 것’ 하나면 충분하다.

덧붙여, 이 과정에서 ‘기록을 남기는 것’도 권하고 싶다. 진단 결과를 시점별로 보관해두면, ‘우리가 지난 분기 대비 얼마나 나아졌는지’를 숫자로 보여줄 수 있다. 접근성은 눈에 잘 안 보이는 일이라 ‘열심히 했는데 티가 안 나는’ 답답함이 따르기 마련인데, 이렇게 변화를 기록해두면 그 노력이 ‘성과’로 드러난다. 윗선에 보고할 때도 “접근성 점수가 지난번보다 이만큼 올랐습니다”라는 한 줄이, 막연한 ‘열심히 했어요’보다 훨씬 설득력 있다. 보이지 않는 일을 보이게 만드는 것, 그것도 담당자가 챙겨야 할 중요한 기술이다.

아래는 실제 ViewCheck로 사이트를 진단했을 때, 웹 접근성(KWCAG) 분석 결과가 어떻게 정리돼 나오는지를 보여주는 화면이다. 어느 항목이 통과했고 어디가 걸렸는지, 사이트 전체의 접근성 수준이 한눈에 들어온다.

마무리

여기까지 긴 글을 읽어준 분들에게 먼저 고맙다는 말을 전하고 싶다. 접근성은 화려한 주제가 아니다. 하지만, 반듯이 시켜야만한다. 눈에 잘 띄지도 않고, 챙겨도 당장 칭찬받는 일도 아니다. 그런데도 끝까지 읽었다는 건, 이미 ‘모두를 위한 공공 웹’이라는 방향에 마음이 가 있다는 뜻일 거다.

오늘 한 이야기를 짧게 정리해보자. 웹 접근성은 ‘장애가 있는 일부 사람을 위한 특별 배려’가 아니라, ‘누구나 차별 없이 정보에 닿을 수 있게 하는 최소한의 약속’이다. 건물에 경사로를 놓듯, 웹에도 ‘들어오는 길’을 모두에게 열어야 한다. 그리고 공공 영역에서 이건 호의가 아니라 의무다. 장애인차별금지법은 정보 접근에서의 차별을 금지하고, 웹사이트도 그 ‘정보’에 포함된다. ‘권장이 아니라 법’이라는 제목은 과장이 아니라 사실이다.

그 의무를 구체적으로 어떻게 지킬지를 알려주는 게 KWCAG 33항목이고, 이는 인식·운용·이해·견고라는 네 원칙으로 묶인다. 이미지에 설명을 달고, 버튼에 이름을 붙이고, 키보드로도 쓸 수 있게 하고, 색에만 기대지 않는 것 — 대부분은 별난 기술이 아니라 ‘꼼꼼함’의 문제다. 그리고 이 꼼꼼함을 수천 페이지에 빠짐없이 적용하는 건 사람만으로는 불가능에 가깝기에, 자동 검사가 현실적인 답이 된다.

그래서 마지막으로 권하고 싶은 건 거창한 게 아니다. ‘일단 우리 사이트가 지금 어디에 서 있는지부터 확인해보자’는 것이다. 접근성은 ‘완벽하게 다 고친 다음에 시작하는 일’이 아니라, ‘현재 상태를 알고 거기서부터 한 걸음씩 나아가는 일’이다. 그리고 그 첫걸음, 즉 ‘현재 상태 확인’은 생각보다 훨씬 간단하다.

krds.viewcheck.co.kr 에 들어가 진단 결과를 체험할 수 있다. 몇 분 뒤면 KRDS 846규칙 준수 현황과 함께, 오늘 이야기한 웹 접근성(KWCAG) 점검 결과가 점수 카드로 정리돼 나온다. ‘우리 사이트의 접근성이 지금 몇 점인지’, ‘어떤 항목에서 주로 걸리는지’를 눈으로 확인하는 것만으로도, 막연하던 접근성이 ‘손에 잡히는 과제’로 바뀐다.

그 결과가 좋게 나오면 안심하고, 아쉽게 나오면 ‘무엇부터 잡으면 되는지’ 우선순위가 생긴다. 어느 쪽이든 손해 볼 게 없다. 접근성은 미루면 미룰수록 사후에 더 비싸지고, 일찍 챙길수록 모두에게 이득인 일이다. ‘여유 생기면 하는 일’이 아니라 ‘오늘 한 번 확인해보는 일’로 바꿔보자. 그 한 번의 확인이, 누군가에게는 막혀 있던 입구가 열리는 시작이 될 수 있다.

처음 이 글을 열 때 “접근성이요? 나중에 시간 남으면…”이라고 생각했다면, 글을 닫는 지금은 그 문장이 조금 달리 들렸으면 한다. 접근성은 시간이 남아서 하는 일이 아니라, 모든 국민이 차별 없이 행정 서비스에 닿게 하는 ‘기본 책무’다. 그리고 그 책무는 거창한 결심이 아니라 ‘우리 사이트가 지금 어떤지 한 번 들여다보는’ 작은 행동에서 시작된다. 그 작은 행동을 도와주는 도구가 이미 손 닿는 곳에 있다는 것, 그게 오늘 이 글이 가장 전하고 싶었던 이야기다.

다음 글에서는 오늘 큰 틀로만 짚은 KWCAG 33항목을, 인식·운용·이해·견고 네 원칙으로 나눠 하나씩 더 구체적으로 풀어볼 예정이다. ‘이미지 대체 텍스트는 어디까지 써야 적당한지’ ‘색 대비는 어느 정도면 충분한지’ ‘키보드 접근은 무엇을 어떻게 확인하는지’ 같은, 실무에서 바로 써먹을 수 있는 이야기를 이어가려 한다. 오늘 글이 ‘왜 해야 하는가’였다면, 다음 글은 ‘무엇을 어떻게 하는가’에 더 가까울 것이다.

모두가 들어올 수 있는 공공 웹, 그건 거창한 이상이 아니라 ‘기본을 지키는 것’에서 출발한다. 그 기본의 현재 위치를, 오늘 한 번 확인해보길 권한다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #장애인차별금지법 #정보접근성 #스크린리더 #전자정부 #공공웹사이트 #디지털포용 #접근성진단 #ViewCheck