스크린리더로 들어가 보면 막히는 공공 사이트

공감·문제제기

한번 직접 해보시라. 모니터를 끄거나 눈을 감고, 마우스를 책상 구석으로 치워버린 다음, 키보드와 화면 읽어주는 프로그램(스크린리더)만으로 자주 들어가는 공공 사이트에 접속해서 민원 신청 하나를 끝까지 해보는 거다. 나는 이 일을 직업으로 하는 사람인데도, 처음 이 실험을 해봤을 때 솔직히 식은땀이 났다. 메인 화면에서 신청 페이지로 넘어가는 그 첫 단계부터 막혔다. 분명히 화면 어딘가에 ‘신청하기’ 버튼이 있다는 걸 눈으로는 아는데, 스크린리더는 그걸 ‘버튼’이라고 읽어주지 않았다. ‘이미지’라고만 읽거나, 아예 아무 말도 하지 않고 지나가 버렸다. 눈을 뜨면 5초면 끝날 일이, 눈을 감으니 시작조차 못 하는 일이 됐다.

오늘 글은 그 이야기다. 월요일에 ‘접근성은 왜 법적 의무인가’를 큰 틀에서 다뤘다면, 오늘은 한 발 더 들어가서 ‘실제로 스크린리더로 공공 사이트에 들어가 보면 어디서 어떻게 막히는가’를 익명 현장 사례로 풀어보려 한다. 가상의 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관 이야기를 빌려서, 무엇이 어떻게 잘못되는지를 가능한 한 구체적으로 보여줄 생각이다. 실제 기관 이름이나 도메인은 한 글자도 적지 않는다. 누구를 흉보려는 글이 아니라, 어디서나 똑같이 반복되는 ‘전형적인 막힘’을 드러내려는 글이기 때문이다.

먼저 솔직히 말하면, 접근성 문제는 ‘티가 안 난다’는 게 가장 무섭다. 디자인이 촌스러우면 누구나 알아본다. 페이지가 안 뜨면 민원이 빗발친다. 그런데 접근성은 다르다. 화면을 보는 사람에게는 멀쩡해 보인다. 버튼도 잘 보이고, 글자도 잘 읽히고, 클릭하면 다 동작한다. 그래서 만든 사람도, 검수한 사람도, 윗선도 ‘문제없다’고 믿는다. 문제는 ‘화면을 보지 않는 사람’에게만 보인다. 눈이 안 보이는 분, 손이 자유롭지 않아 마우스를 못 쓰는 분, 시력이 약해 화면을 크게 키워 쓰는 분 — 이런 분들에게만 사이트가 ‘벽’이 된다. 그리고 이분들은 대개 민원을 넣지 않는다. 그냥 조용히 포기하고 떠난다. 그래서 담당자는 문제가 있다는 사실조차 모른 채 몇 년을 보낸다.

여기서 한 가지 분명히 해두자. 웹 접근성은 ‘배려’나 ‘선의’의 영역이 아니다. 적어도 공공 사이트에서는 그렇다. 대한민국에는 모든 국민이 정보에 차별 없이 접근할 수 있도록 보장하라는 법적 의무가 있고, 행정안전부의 「전자정부 웹사이트 품질관리 지침」은 접근성을 7대 품질 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성) 중 하나로 명시한다. 즉 접근성은 ‘잘하면 좋은 것’이 아니라 ‘안 하면 안 되는 것’이다. 그런데도 현장에서 접근성이 자꾸 뒤로 밀리는 이유는 단순하다. 안 보이니까. 눈에 보이는 디자인은 챙기면서, 눈에 안 보이는 접근성은 ‘나중에’로 미룬다. 그 ‘나중’이 영영 오지 않는 사이트가 너무 많다.

이 글의 목적은 그 ‘안 보이는 벽’을 눈에 보이게 만드는 거다. 스크린리더라는 도구를 통해 사이트에 ‘다른 방식으로’ 들어가 보면, 평소엔 안 보이던 균열이 한꺼번에 드러난다. 그 균열들을 하나하나 이름 붙여 보여줄 생각이다. 이름을 붙일 수 있으면 알아볼 수 있고, 알아볼 수 있으면 고칠 수 있다. 오늘 글을 다 읽고 나면, 적어도 ‘우리 사이트에 이런 벽이 있을 수 있겠구나’ 하는 감은 생길 거다. 그 감 하나가 시작이다.

마지막으로 미리 일러둘 게 있다. 오늘 사례에 등장하는 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관은 전부 가상이다. 특정 기관을 지목하는 게 아니라, 점검 현장에서 ‘거의 매번’ 만나는 전형을 익명의 옷을 입혀 보여주는 것뿐이다. 그러니 읽으면서 ‘우리도 저런데’ 싶은 대목이 나와도 자책하지 마시라. 대부분의 사이트가 겪는 일이고, 대부분이 같은 방법으로 풀어왔다. 중요한 건 알아보는 눈을 갖추는 것이다.

그리고 한 가지 더. 이 글을 읽는 분이 ‘나는 개발자가 아니라 잘 모르겠다’ 싶어도 괜찮다. 오늘 이야기는 코드를 짤 줄 알아야 이해되는 게 아니다. ‘이 사이트가 보지 않는 사람에게도 똑같이 열려 있는가’라는 아주 단순한 질문, 그 하나만 품고 읽으면 된다. 기획자든, 디자이너든, 콘텐츠 담당자든, 사업 발주를 맡은 분이든 — 각자 자리에서 할 수 있는 일이 분명히 있다. 발주 문서에 한 줄을 넣는 일, 콘텐츠를 이미지가 아니라 글자로 올리는 습관, 새 페이지를 검수할 때 키보드로 한 번 눌러보는 일. 접근성은 개발팀 혼자의 숙제가 아니라, 사이트를 만지는 모든 사람이 조금씩 나눠 지는 책임이다.

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

■ 스크린리더가 ‘읽는’ 건 화면이 아니라 ‘코드’다

가장 먼저 깨야 할 오해부터 짚자. 많은 분들이 스크린리더를 ‘화면을 카메라로 찍어 읽어주는 기계’쯤으로 상상한다. 그게 아니다. 스크린리더는 화면의 ‘그림’을 보는 게 아니라, 그 화면을 만든 ‘코드(HTML)’를 읽는다. 정확히 말하면, 브라우저가 코드를 해석해서 만든 ‘접근성 트리’라는 구조를 따라 위에서 아래로 훑으며, 각 요소가 ‘무엇인지’와 ‘뭐라고 적혀 있는지’를 음성으로 바꿔준다.

이게 왜 중요하냐면, ‘눈에 보이는 것’과 ‘코드에 적힌 것’이 다를 수 있기 때문이다. 화면에는 멀쩡한 파란색 ‘신청하기’ 버튼이 보여도, 코드상으로는 그게 그냥 ‘클릭되는 그림’일 뿐이라면, 스크린리더는 그걸 ‘버튼’이라고 인식하지 못한다. 사람 눈에는 버튼인데 기계 눈에는 버튼이 아닌 거다. 이 간극이 바로 접근성 문제의 출발점이다. 화면을 보는 사람은 멀쩡하다고 하고, 스크린리더를 쓰는 사람은 막혔다고 한다. 둘 다 거짓말이 아니다. 같은 사이트를 ‘다른 통로’로 들어갔을 뿐이다.

그래서 접근성을 챙긴다는 건 ‘화면을 예쁘게 만드는 일’과 완전히 다른 작업이다. 화면 뒤에 숨은 코드가, 화면이 전달하는 의미를 똑같이 전달하도록 ‘의미를 코드에 심는’ 일이다. 버튼은 코드에서도 버튼이어야 하고, 제목은 코드에서도 제목이어야 하고, 이미지에는 그 이미지가 무엇인지 설명하는 대체 텍스트가 붙어 있어야 한다. 이 ‘의미 심기’가 빠지면, 아무리 화면이 멀쩡해도 스크린리더에게는 의미 없는 글자 덩어리만 남는다.

한 가지 비유를 들어보자. 잘 만든 사이트의 코드는 ‘목차와 소제목이 잘 잡힌 책’과 같다. 눈으로 봐도 좋고, 누가 소리 내어 읽어줘도 ‘지금이 1장이고, 이게 소제목이고, 이건 본문이고’가 또렷이 전달된다. 반대로 접근성이 무너진 사이트의 코드는 ‘목차도 없고 소제목 표시도 없이 글자만 빽빽한 종이 뭉치’다. 눈으로 훑으면 굵기나 크기로 대충 구조를 짐작하지만, 소리로만 들으면 어디가 제목이고 어디가 본문인지 전혀 알 수 없다. 스크린리더 사용자는 바로 이 ‘소리로만 듣는’ 상황에 놓인 사람이다.

그래서 접근성을 처음 접하는 담당자분께 나는 늘 이렇게 권한다. ‘우리 사이트를 눈으로 보지 말고, 한 번만 귀로 들어보세요.’ 화면을 끄고 스크린리더를 켠 채 사이트를 위에서 아래로 ‘들어’ 보면, 평소엔 너무 익숙해서 안 보이던 문제들이 한꺼번에 귀에 들어온다. ‘이미지’, ‘이미지’, ‘링크’, ‘편집창’ 같은 무의미한 단어가 줄줄이 들리는 구간이 있다면, 거기가 바로 코드에 의미가 안 심긴 자리다. 화면에서는 그렇게 멀쩡하던 곳이, 귀로 들으면 ‘아무것도 말해주지 않는’ 빈자리로 드러난다. 이 경험을 한 번만 해보면 ‘접근성이 왜 코드의 문제인가’가 단번에 이해된다. 백 마디 설명보다 5분의 직접 청취가 낫다.

또 하나 짚어둘 것은, 이 ‘코드에 심은 의미’가 스크린리더만을 위한 게 아니라는 점이다. 코드에 제목·버튼·표·라벨 같은 의미가 또렷이 심긴 사이트는 검색엔진도 더 잘 이해하고, 자동 번역도 더 정확해지고, 나중에 기능을 추가하거나 디자인을 바꿀 때도 훨씬 다루기 쉽다. 즉 접근성을 위해 코드의 의미를 챙기는 일은, 결과적으로 사이트 전체의 ‘건강’을 챙기는 일이 된다. 접근성을 잘한 사이트가 검색에도 강하고 유지보수도 쉬운 건 우연이 아니다. ‘의미가 또렷한 코드’라는 같은 뿌리에서 나오는 열매이기 때문이다.

■ ‘보이는 멀쩡함’이 만든 거대한 착시

공공 사이트 담당자분들과 이야기해 보면, 가장 자주 듣는 말이 ‘우리 사이트는 잘 보이는데요?’다. 맞다. 잘 보인다. 문제는 ‘보이는 것’으로 접근성을 판단할 수 없다는 데 있다. 접근성은 ‘안 보고도 쓸 수 있는가’, ‘마우스 없이도 쓸 수 있는가’, ‘소리로만 들어도 이해되는가’의 문제이기 때문이다.

이 착시는 조직 전체에 퍼져 있다. 디자이너는 화면을 예쁘게 만들고, 개발자는 화면대로 동작하게 만들고, 검수자는 화면을 클릭해 보고 ‘정상’ 판정을 내린다. 이 모든 과정이 ‘화면을 보는 사람’의 시선으로만 이뤄진다. 그 누구도 눈을 감고 키보드만으로 끝까지 가보지 않는다. 그래서 ‘보이는 멀쩡함’이라는 거대한 합의가 만들어지고, 그 합의 바깥에 있는 사용자는 통계에도, 회의에도, 보고서에도 등장하지 않는다.

여기서 짚고 싶은 건, 이게 누구의 잘못도 아니라는 점이다. 디자이너가 무심해서도, 개발자가 게을러서도 아니다. 그냥 ‘다른 방식으로 사이트를 쓰는 사람의 경험’을 점검할 도구와 절차가 없었을 뿐이다. 사람은 자기가 쓰는 방식으로만 사이트를 점검한다. 마우스와 눈으로 점검하면 마우스와 눈으로 쓰는 사람의 문제만 발견된다. 키보드와 귀로 쓰는 사람의 문제는, 일부러 키보드와 귀로 점검하지 않으면 영영 안 보인다. 그래서 접근성 점검은 ‘착한 마음’이 아니라 ‘점검 방식의 전환’에서 시작된다.

그리고 이 ‘안 보이는 사용자’의 규모를 가볍게 보면 안 된다. 흔히 접근성을 ‘소수의 시각장애인을 위한 것’으로만 생각하는데, 실제로는 훨씬 넓다. 손을 다쳐 일시적으로 마우스를 못 쓰는 사람, 노화로 시력이 약해진 어르신, 손떨림이 있어 작은 버튼을 정확히 못 누르는 사람, 밝은 야외에서 화면이 잘 안 보이는 사람, 시끄러운 곳에서 영상의 소리를 못 듣는 사람 — 접근성은 이 모두를 위한 것이다. 게다가 누구나 나이가 든다. 지금 멀쩡한 우리도 언젠가는 글자가 작아 보이고, 손이 떨리고, 화면 대비가 흐릿하게 느껴질 날이 온다. 접근성은 ‘남을 위한 배려’이기도 하지만, 결국 ‘미래의 나를 위한 준비’이기도 하다.

여기서 ‘상황적 장애’라는 개념도 알아두면 좋다. 장애가 꼭 영구적인 것만은 아니라는 이야기다. 아기를 한 팔로 안고 다른 손으로만 신청을 하는 부모는 그 순간 ‘한 손 사용자’다. 운전 중이라 화면을 못 보고 음성으로만 정보를 받아야 하는 사람은 그 순간 ‘시각을 못 쓰는 사용자’다. 데이터가 부족해 이미지를 안 띄우고 글자만 보는 사람은 그 순간 ‘이미지를 못 보는 사용자’다. 이렇게 누구나 ‘특정 상황에서’ 일시적으로 접근성의 도움을 받는다. 그래서 접근성을 잘 챙긴 사이트는 ‘장애인만 편한 사이트’가 아니라 ‘모두가 어떤 상황에서든 편한 사이트’가 된다. 경사로가 휠체어 사용자만을 위한 게 아니라 유아차를 끄는 부모, 무거운 짐을 든 택배기사 모두에게 편한 것과 똑같다. 접근성은 결국 ‘잘 만든 사이트’의 다른 이름이다.

특히 공공 사이트는 이 점을 더 무겁게 받아들여야 한다. 민간 서비스라면 불편한 사용자가 ‘다른 회사 서비스’로 갈 선택지라도 있다. 그런데 공공 서비스는 대체재가 없다. 특정 지자체의 민원, 특정 부처의 신청은 그곳에서만 할 수 있다. 그 사이트가 막혀 있으면 사용자에게는 ‘다른 데서 하면 되지’가 통하지 않는다. 그냥 그 서비스 자체를 못 받게 되는 거다. 화면을 보는 다수에게는 잘 작동하는 서비스가, 보지 못하는 소수에게는 ‘존재하지만 받을 수 없는 서비스’가 되는 셈이다. 공공성이라는 말의 무게를 생각하면, 접근성은 ‘있으면 좋은 기능’이 아니라 ‘공공 서비스의 자격 요건’에 가깝다.

■ KWCAG 33항목이라는 ‘점검 체크리스트’

그렇다면 접근성을 어떻게 점검할까. 막연히 ‘잘 챙기자’로는 안 된다. 기준이 있어야 한다. 한국에는 한국형 웹 콘텐츠 접근성 지침, 즉 KWCAG가 있고, 이 지침은 접근성을 33개의 구체적인 항목으로 나눠 점검하게 한다. ‘대체 텍스트가 있는가’, ‘키보드로 모든 기능을 쓸 수 있는가’, ‘초점이 어디 있는지 보이는가’, ‘색만으로 정보를 전달하지 않는가’, ‘제목과 라벨이 명확한가’ 같은 항목들이다.

이 33항목의 좋은 점은, 막연한 ‘접근성’을 ‘점검 가능한 목록’으로 바꿔준다는 거다. ‘우리 사이트 접근성 어때?’라는 질문은 너무 넓어서 누구도 답하기 어렵다. 하지만 ‘대체 텍스트가 모든 이미지에 있나?’, ‘키보드만으로 신청을 끝낼 수 있나?’ 같은 질문은 하나하나 ‘예/아니오’로 답할 수 있다. 33개의 예/아니오가 모이면, 우리 사이트의 접근성 수준이 또렷한 그림으로 그려진다.

그리고 이 33항목은 ‘기초·운용·이해·견고성’ 같은 큰 원칙 아래 묶인다. 거칠게 풀면 이렇다. 인식할 수 있어야 하고(안 보여도 들리거나 만져져야 하고), 운용할 수 있어야 하고(마우스 없이도 조작돼야 하고), 이해할 수 있어야 하고(읽고 쓰는 흐름이 헷갈리지 않아야 하고), 견고해야 한다(다양한 기기·보조기술과 잘 맞아야 한다). 오늘 보여줄 익명 사례들은 대부분 이 네 원칙 중 한두 군데가 무너진 경우다. 사례를 읽으면서 ‘이건 인식의 문제구나’, ‘이건 운용의 문제구나’ 하고 분류해 보면 머릿속이 한결 정리될 거다.

한 가지 흔한 오해를 미리 풀어두자. ‘33항목을 다 지키려면 사이트를 완전히 새로 만들어야 하는 거 아니냐’고 겁을 먹는 경우가 있다. 그렇지 않다. 33항목 중 상당수는 ‘이미 잘 지키고 있는’ 것들이다. 점검을 해보면 보통 몇 개의 항목에서만 집중적으로 문제가 터진다 — 대체 텍스트, 키보드 접근, 초점 표시, 색 대비, 라벨, 제목 구조 같은 단골들이다. 그러니 ‘전부 다 갈아엎자’가 아니라 ‘어디가 막혔는지 먼저 찾고, 그 항목부터 메우자’가 현실적인 접근이다. 33항목은 ‘넘어야 할 산’이 아니라 ‘점검할 목록’이다. 목록이 있으니 오히려 막막하지 않은 거다.

■ 막힘은 ‘기능’이 아니라 ‘사람’의 문제다

여기서 잠깐, 통계나 항목 이야기에서 벗어나 ‘사람’ 이야기를 하고 싶다. 우리가 점검하는 건 결국 코드지만, 그 코드 너머에는 실제로 그 사이트를 쓰려다 막힌 사람이 있다. 가상의 한 장면을 그려보자. 시각장애가 있는 한 시민이 가상의 ○○시 사이트에서 ‘기초생활 관련 지원 신청’을 하려 한다. 마감이 내일이다. 스크린리더로 한 단계 한 단계 더듬어 신청 페이지까지 갔는데, 마지막 ‘제출’ 버튼이 코드상 버튼이 아니라 ‘클릭되는 그림’이라 키보드로 눌리지 않는다. 화면을 보는 사람이라면 마우스로 0.3초면 끝낼 그 한 번의 클릭을, 이 시민은 끝내 하지 못한다. 결국 누군가에게 전화로 부탁하거나, 직접 기관을 찾아가야 한다. 마감이 내일인데.

이 장면은 가상이지만, 이런 일은 어딘가에서 실제로 일어난다. 그리고 이 일의 무게는 ‘버튼 하나 안 눌린다’는 기술적 문장으로는 다 담기지 않는다. 그 한 번의 막힘이 누군가에게는 ‘제때 받았어야 할 지원을 못 받는’ 결과로 이어진다. 접근성을 ‘체크리스트 항목 채우기’로만 생각하면 이 무게가 안 느껴진다. 그래서 나는 점검을 할 때 늘 ‘이 막힌 자리에서 실제로 누가 멈춰 섰을까’를 떠올리려 한다. 그렇게 생각하면 ‘이 정도는 나중에’라는 말이 잘 안 나온다. 접근성은 기능 명세가 아니라, 누군가의 ‘오늘’을 가능하게 하느냐 마느냐의 문제이기 때문이다.

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

이제 구체적인 막힘 패턴들을 보자. 스크린리더와 키보드만으로 공공 사이트에 들어가 봤을 때 거의 매번 만나는 단골 사례들이다. 미리 말해두면, 이 패턴들은 따로 노는 게 아니라 대개 한 사이트에서 함께 나타난다. 대체 텍스트가 부실한 사이트는 십중팔구 키보드 초점도 엉망이고, 폼 라벨도 빠져 있고, 제목 구조도 무너져 있다. 왜냐하면 이 모든 게 ‘코드에 의미를 심는 작업을 빠뜨렸다’는 하나의 원인에서 비롯되기 때문이다. 그래서 패턴 하나가 보이면 ‘나머지도 있겠구나’ 하고 함께 점검하는 게 효율적이다. 반대로 말하면, 접근성을 제대로 한 번 챙기면 이 여러 패턴이 동시에 좋아진다.

■ 막힘 패턴 1: 알 수 없는 이미지 — 대체 텍스트의 부재

가상의 ○○시 사이트에 스크린리더로 들어가 봤다고 하자. 메인 화면 상단에는 보통 큼직한 배너가 있고, 그 배너 안에 ‘이번 달 주요 행사 안내’ 같은 핵심 정보가 들어 있다. 그런데 이 배너가 한 장의 이미지로 만들어져 있고, 그 이미지에 대체 텍스트(alt)가 없으면, 스크린리더는 뭐라고 읽을까. 운이 좋으면 ‘이미지’라고만 읽고, 운이 나쁘면 그 이미지의 파일 이름을 그대로 읽는다. ‘배너 최종 수정본 2 복사본.png’ 같은 걸 또박또박 읽어주는 거다.

생각해 보라. 화면을 보는 사람은 그 배너에서 행사 정보를 0.5초 만에 읽는다. 스크린리더 사용자는 같은 자리에서 ‘이미지’ 혹은 정체불명의 파일명을 듣는다. 결국 그 사용자에게 이 사이트의 가장 중요한 안내는 ‘존재하지 않는 정보’다. 정보가 거기 ‘있는데도 없는’ 상태. 이게 대체 텍스트 부재의 본질이다.

대체 텍스트는 ‘이미지가 전달하는 의미를 글로 적어두는 것’이다. 별것 아닌 것 같지만, 여기엔 꽤 깊은 판단이 필요하다. 모든 이미지에 무조건 설명을 붙이면 되는 게 아니다. 의미를 담은 이미지(정보·기능)에는 그 의미를 적되, 순수하게 장식인 이미지에는 오히려 ‘빈 대체 텍스트’를 줘서 스크린리더가 건너뛰게 해야 한다. 안 그러면 장식용 그림 하나하나를 다 읽느라 사용자가 본론에 닿기도 전에 지친다. 즉 대체 텍스트는 ‘다 붙이기’가 아니라 ‘의미 있는 건 붙이고 장식은 비우기’의 섬세한 작업이다.

현장에서 가장 흔한 실수는 두 가지다. 하나는 핵심 정보 이미지에 대체 텍스트가 아예 없는 것(정보 손실), 다른 하나는 장식 이미지에까지 ‘이미지’, ‘아이콘’ 같은 무의미한 텍스트가 잔뜩 붙어 있는 것(소음 과다). 둘 다 사용자를 괴롭힌다. 앞엣것은 정보를 빼앗고, 뒤엣것은 정보를 찾기 어렵게 만든다. 좋은 대체 텍스트는 ‘필요한 곳에 꼭 필요한 만큼’이다.

특히 ‘아이콘 버튼’이 함정이다. 요즘 사이트는 글자 없이 아이콘만으로 기능을 표현하는 경우가 많다. 돋보기 아이콘은 검색, 삼선 아이콘은 메뉴, 엑스 아이콘은 닫기 — 화면을 보는 사람은 그림만 봐도 안다. 그런데 이 아이콘이 ‘글자 없는 그림’으로만 만들어져 있으면, 스크린리더는 ‘버튼’이라고만 읽거나 아예 아무 말도 못 한다. 사용자는 ‘이게 무슨 버튼인지’ 모른 채 그냥 지나친다. 검색을 하려는데 검색 버튼이 ‘이름 없는 버튼’으로만 들리면, 검색 기능 자체에 닿을 수가 없다. 그래서 아이콘 버튼에는 반드시 ‘이게 무슨 기능인지’를 알려주는 숨은 이름을 코드에 심어야 한다. 화면에는 그림만 보이더라도, 귀로는 ‘검색’이라고 들리게 하는 것 — 이게 아이콘 버튼 접근성의 핵심이다.

여기서 특히 위험한 게 ‘이미지로 된 글자’다. 가상의 A광역지자체가 공지문이나 안내문을 깔끔하게 디자인하겠다며 글 전체를 한 장의 이미지로 만들어 올렸다고 하자. 화면으로 보면 더없이 정돈돼 보인다. 그런데 그 이미지에 대체 텍스트가 없거나, 있어도 긴 본문을 다 담지 못하면, 스크린리더 사용자에게 그 공지는 통째로 사라진다. 글자를 이미지로 만드는 순간, 그 글자는 ‘읽히는 텍스트’가 아니라 ‘읽을 수 없는 그림’이 된다. 검색에도 안 걸리고, 복사도 안 되고, 화면을 키워도 흐릿해진다. 공공 정보를 이미지로 박는 건, 좋은 의도와 정반대의 결과를 낳는 대표적인 함정이다.

이 ‘이미지로 된 글자’ 문제는 의외로 뿌리가 깊다. 디자인 부서에서 보도자료나 카드뉴스를 예쁘게 만들어 이미지로 내보내고, 그걸 그대로 사이트에 올리는 흐름이 굳어져 있으면, 아무리 접근성을 외쳐도 매번 ‘읽을 수 없는 그림’이 새로 쌓인다. 그래서 이건 개발의 문제가 아니라 ‘콘텐츠를 만드는 습관’의 문제이기도 하다. 핵심 정보는 이미지가 아니라 글자로 올리고, 디자인이 들어간 카드뉴스를 쓰더라도 같은 내용을 글자로 함께 제공하는 것 — 이 작은 운영 원칙 하나가 수많은 ‘사라진 정보’를 살린다. 보기 좋게 만든 이미지가 누군가에게는 ‘닫힌 문’이 될 수 있다는 걸, 콘텐츠를 만드는 모든 사람이 알아야 한다.

대체 텍스트를 ‘잘’ 쓰는 것도 생각보다 기술이 필요하다. 같은 사진이라도 어떤 맥락에 쓰였느냐에 따라 적어야 할 내용이 달라진다. 행사 안내 배너의 사진이라면 ‘무슨 행사인지, 언제 어디서 하는지’가 들어가야 하고, 인물 사진이 그저 분위기용 장식이라면 길게 묘사할 필요 없이 짧게 처리하는 게 낫다. 핵심은 ‘이 이미지가 화면에서 사라졌을 때 사용자가 놓치는 정보가 무엇인가’를 떠올려 그걸 적는 거다. 화면을 보는 사람이 그 이미지에서 얻는 것과 똑같은 것을, 보지 못하는 사람도 글로 얻게 하는 것. 그게 대체 텍스트의 목표다.

■ 막힘 패턴 2: 키보드로는 갈 수 없는 길

스크린리더 사용자 상당수는 마우스를 쓰지 않는다. 키보드의 탭(Tab) 키로 요소를 하나씩 옮겨 다니고, 엔터나 스페이스로 누른다. 그래서 ‘모든 기능을 키보드만으로 쓸 수 있는가’는 접근성의 핵심 중의 핵심이다. 그런데 가이드 없이 만든 사이트는 이 ‘키보드 길’이 자주 끊긴다.

가상의 한중앙부처 사이트에서 흔히 보는 장면이 있다. 메인 메뉴에 마우스를 올리면 하위 메뉴가 주르륵 펼쳐진다. 화면으로 보면 멋지다. 그런데 키보드로 탭을 눌러 메뉴까지 가서 엔터를 쳐봐도 하위 메뉴가 안 열린다. 그 메뉴가 ‘마우스 올림(hover)’에만 반응하도록 만들어졌기 때문이다. 키보드 사용자에게는 하위 메뉴로 가는 길 자체가 없는 셈이다. 마우스로는 두 단계면 닿는 페이지가, 키보드로는 영영 못 닿는 페이지가 된다.

또 다른 장면. 가상의 B공공기관 사이트에서 신청 폼을 채우다가, 중간에 작은 팝업(모달)이 떠서 약관 동의를 받는다고 하자. 마우스 사용자는 팝업 안의 ‘동의’를 누르고 닫으면 그만이다. 그런데 키보드 사용자가 탭을 누르면, 초점이 팝업 안이 아니라 팝업 뒤의 본문으로 새어 나간다. 화면에는 팝업이 떠 있는데, 초점은 그 뒤 안 보이는 영역을 떠돌아다닌다. 사용자는 지금 자기가 뭘 조작하고 있는지 알 수 없게 된다. 이걸 ‘초점 가둠(focus trap)’이 안 됐다고 한다. 팝업이 떠 있는 동안에는 초점이 팝업 안에만 머물러야 하는데, 그 처리가 빠진 거다.

키보드 길에서 또 하나 빠지기 쉬운 게 ‘건너뛰기 링크(skip link)’다. 공공 사이트는 보통 페이지 맨 위에 로고, 메뉴, 검색창 같은 머리 영역이 길게 깔린다. 화면을 보는 사람은 본문으로 눈을 휙 옮기면 그만이지만, 키보드 사용자는 탭을 눌러 그 긴 머리 영역을 하나하나 통과해야 본문에 닿는다. 페이지마다 같은 메뉴를 수십 번 거쳐야 본문에 도착하는 거다. 이걸 막으려고 ‘본문 바로가기’ 링크를 맨 앞에 두는데, 가이드 없는 사이트는 이게 없거나, 있어도 작동하지 않는 경우가 많다. 작은 링크 하나가 키보드 사용자의 ‘매 페이지 수십 번의 헛수고’를 없애준다. 안 보이는 곳에 있지만, 있는 것과 없는 것의 차이가 어마어마하다.

그리고 ‘탭 순서’ 자체가 엉킨 경우도 흔하다. 화면상으로는 위에서 아래, 왼쪽에서 오른쪽으로 자연스럽게 배치돼 있는데, 탭을 눌러보면 초점이 위로 갔다 아래로 갔다 엉뚱하게 튀어 다닌다. 화면 배치와 코드 순서가 따로 놀기 때문이다. 키보드 사용자는 ‘다음에 어디로 갈지’를 예측할 수 없게 되고, 신청 폼을 채우다가 초점이 갑자기 페이지 끝으로 날아가면 길을 잃는다. 탭 순서는 ‘눈으로 읽는 순서’와 같아야 한다. 이것 역시 표준 부품과 올바른 코드 구조를 따르면 자연스럽게 맞춰지는 부분이다.

키보드 길이 끊기는 더 근본적인 이유는, 앞서 말한 ‘버튼이 버튼이 아닌’ 문제와 맞닿아 있다. 진짜 버튼이나 링크로 만든 요소는 브라우저가 기본적으로 키보드로 갈 수 있게 해준다. 그런데 그냥 ‘클릭되는 그림’으로 버튼 흉내만 낸 요소는 키보드 탭 순서에 끼지 못한다. 그래서 마우스로는 눌리는데 키보드로는 닿을 수조차 없다. 화면상의 모양이 아니라 ‘코드상의 정체’가 키보드 접근성을 좌우하는 거다. 결국 ‘버튼은 코드에서도 버튼이어야 한다’는 원칙 하나가, 대체 텍스트와 키보드 접근성 양쪽을 동시에 살린다.

■ 막힘 패턴 3: 초점이 어디 있는지 보이지 않는다

키보드로 사이트를 쓸 때, 사용자는 ‘지금 초점이 어디 있는지’를 시각적 신호로 안다. 탭을 누를 때마다 ‘여기 와 있어요’ 하고 외곽선이나 강조 표시가 따라다녀야 한다. 이걸 ‘초점 표시(focus indicator)’라고 한다. 그런데 이 표시가 ‘보기 안 좋다’는 이유로 일부러 지워진 사이트가 정말 많다.

가상의 C기관 사이트가 그런 경우라고 하자. 디자인을 깔끔하게 하겠다며 초점이 갔을 때 생기는 외곽선을 전부 없앴다. 마우스 사용자에게는 아무 문제가 없다. 그런데 키보드 사용자가 탭을 누르면, 분명히 초점은 이동하는데 화면에는 아무 변화가 없다. 사용자는 ‘내가 지금 어디 있는지’를 전혀 알 수 없다. 눈을 가린 채 깜깜한 방에서 손으로 더듬어 가구를 찾는 것과 같다. 어디가 신청 버튼이고 어디가 메뉴인지, 엔터를 치면 뭐가 눌릴지 짐작도 못 한 채 그냥 탭만 반복하게 된다.

이게 특히 안타까운 이유는, 해결이 어렵지 않은데도 ‘미관’이라는 이유로 일부러 망가뜨렸다는 점이다. 초점 표시는 ‘기본으로 켜져 있는’ 기능이다. 그냥 두면 작동한다. 오히려 그걸 ‘없애는’ 코드를 일부러 넣어서 망가뜨린 경우가 대부분이다. 보기 싫으면 없앨 게 아니라, 사이트 디자인에 어울리는 더 예쁜 초점 표시로 ‘바꾸면’ 된다. 표준은 초점 표시를 ‘지우지 말고, 충분히 또렷하게 보이게 하라’고 안내한다. 미관과 접근성은 충돌하지 않는다. 둘 다 챙길 수 있는데, ‘둘 중 하나’라고 오해해서 접근성을 버리는 게 문제다.

■ 막힘 패턴 4: 색만으로 말하는 정보

‘필수 항목은 빨간색으로 표시했습니다.’ 이 한 문장이 접근성에서는 위험 신호다. 색을 구분하기 어려운 사용자에게 빨간색은 그냥 검은색과 비슷하게 보인다. 그러니 ‘빨강=필수’라는 약속은 그분들에게 전달되지 않는다. 색만으로 정보를 전달하면, 색을 못 보는 사람은 그 정보를 통째로 놓친다.

가상의 ○○시 민원 신청 폼을 다시 떠올려 보자. 필수 입력 칸을 빨간 글씨나 빨간 테두리로만 표시했다면, 색약·색맹 사용자는 어디가 필수인지 모른 채 빈칸으로 제출하고, ‘필수 항목을 입력하세요’라는 오류만 반복해서 만난다. 정작 어디가 필수인지는 끝까지 알 수 없다. 해결은 간단하다. 색에 더해 ‘기호(*)’나 ‘필수’라는 글자, 혹은 모양 차이를 함께 주면 된다. 색은 ‘거들 뿐’, 정보의 본체는 글자나 기호로도 전달돼야 한다.

색 문제는 ‘대비’로도 이어진다. 연한 회색 배경에 조금 더 연한 회색 글씨, 옅은 파랑 배경에 흰 글씨 — 디자인상으로는 세련돼 보이지만, 시력이 약한 사용자나 밝은 야외의 사용자에게는 글자가 배경에 묻혀 안 읽힌다. KWCAG는 글자와 배경 사이에 충분한 명도 대비를 두라고 요구한다. 이건 ‘예쁨’의 문제가 아니라 ‘읽힘’의 문제다. 아무리 멋진 글이라도 안 읽히면 없는 글이다. 그리고 이 대비 문제는 앞서 말한 ‘색이 통제 불능인 사이트’에서 특히 심해진다. 매번 다른 색을 눈대중으로 박으니, 어떤 조합은 우연히 대비가 충분하고 어떤 조합은 한참 미달인데, 그걸 일일이 확인할 방법이 없기 때문이다.

색 대비는 글자에만 해당하는 게 아니다. 버튼의 테두리, 입력 칸의 윤곽선, 그래프의 선과 영역 같은 ‘비텍스트 요소’도 충분한 대비가 필요하다. 옅은 회색 테두리의 입력 칸은 시력이 약한 사용자에게 ‘여기가 입력하는 칸이라는 사실’ 자체가 안 보인다. 어디에 글자를 넣어야 할지 모르는 거다. 그래픽으로 정보를 전달하는 통계 페이지도 마찬가지다. 비슷비슷한 연한 색의 막대 그래프는, 색을 구분하기 어려운 사용자에게 ‘구분되지 않는 한 덩어리’로 보인다. 그래서 표준은 글자뿐 아니라 ‘의미를 전달하는 모든 요소’에 대비 기준을 둔다. 색은 거들 뿐, 정보는 모양·위치·글자로도 함께 전달돼야 한다는 원칙이 여기서도 반복된다.

■ 막힘 패턴 5: 제목과 구조가 없는 ‘글자 벽’

스크린리더 사용자는 페이지 전체를 처음부터 끝까지 다 듣지 않는다. 그러기엔 너무 길다. 대신 ‘제목(heading)’만 빠르게 훑어 페이지 구조를 파악하고, 원하는 부분으로 건너뛴다. 마치 눈으로 페이지를 스캔하듯, 귀로 제목을 스캔하는 거다. 그래서 제목이 코드에 제대로 표시돼 있는지가 결정적으로 중요하다.

문제는, 화면상으로는 ‘제목처럼 보이는데’ 코드상으로는 제목이 아닌 경우가 너무 많다는 거다. 가상의 한중앙부처 정책 안내 페이지를 보자. 화면에는 큼직하고 굵은 글씨로 ‘신청 자격’, ‘제출 서류’, ‘처리 기간’ 같은 소제목들이 보기 좋게 박혀 있다. 그런데 코드를 까보니 그게 전부 ‘크고 굵게 만든 그냥 본문 글자’다. 진짜 제목 표시가 안 돼 있다. 그러면 스크린리더 사용자에게 이 페이지는 ‘제목이 하나도 없는 글자 벽’이 된다. 건너뛸 지점이 없으니, 원하는 정보(예: 처리 기간)를 찾으려면 페이지를 처음부터 끝까지 다 들어야 한다.

제목 구조에는 ‘순서’도 중요하다. 큰 제목 아래 중간 제목, 그 아래 작은 제목 식으로 단계가 차곡차곡 쌓여야 한다. 그런데 디자인상 글자 크기를 맞추겠다고 단계를 건너뛰거나 뒤죽박죽 섞으면, 스크린리더 사용자는 페이지의 ‘목차’를 잘못 그리게 된다. 큰 제목 다음에 갑자기 가장 작은 제목이 나오면, ‘중간 내용이 빠진 건가’ 하고 혼란스러워한다. 제목은 페이지의 뼈대다. 뼈대가 어긋나면, 보이지 않는 사용자에게는 페이지 전체가 어긋나 보인다.

이 ‘구조 없음’ 문제는 표(table)에서도 똑같이 반복된다. 공공 사이트엔 통계표, 일정표, 요금표가 많다. 화면으로 보면 행과 열이 또렷해서 ‘몇 행 몇 열 값’을 바로 읽는다. 그런데 표의 머리글(헤더)이 코드에 표시돼 있지 않으면, 스크린리더는 그냥 ‘숫자, 숫자, 숫자’를 줄줄이 읽기만 한다. 그 숫자가 ‘무슨 항목의 어느 시점 값’인지 연결해 주지 못한다. 사용자는 숫자의 바다에서 길을 잃는다. 표에 머리글을 제대로 심어두면, 스크린리더는 ‘2분기, 처리 건수, 1234’처럼 행과 열의 의미를 함께 읽어줘서, 안 보고도 표를 ‘읽을’ 수 있게 된다.

여기에 더해, 표를 ‘레이아웃 용도’로 쓰는 오래된 습관도 여전히 남아 있다. 진짜 데이터 표가 아니라 화면을 칸칸이 나누려고 표 구조를 끌어다 쓰는 경우다. 화면으로는 깔끔해 보이지만, 스크린리더는 그걸 ‘데이터 표’로 오해해서 ‘몇 행 몇 열짜리 표입니다’ 하고 안내한 뒤 빈 칸들을 줄줄이 읽는다. 사용자는 ‘무슨 표지?’ 하며 의미 없는 칸을 헤맨다. 구조는 ‘보이는 모양’이 아니라 ‘의미’를 위한 것이어야 한다. 줄을 맞추려고 표를 쓰는 게 아니라, 정말로 ‘행과 열로 의미가 짜인 데이터’일 때만 표를 써야 한다는 원칙이 그래서 중요하다.

■ 막힘 패턴 6: 라벨 없는 입력 칸과 멋대로 움직이는 화면

폼은 공공 서비스의 심장이다. 민원을 넣고, 신청을 하고, 개인정보를 입력하는 그 모든 일이 폼에서 일어난다. 그런데 이 폼이 접근성에서 가장 자주 무너지는 곳이기도 하다. 핵심은 ‘라벨(label)’이다. 입력 칸 옆에 ‘이름’, ‘연락처’, ‘생년월일’ 같은 안내 글자가 있어야, 사용자는 그 칸에 뭘 넣어야 하는지 안다. 그런데 화면상으로는 그 글자가 입력 칸 옆에 ‘보이는데’, 코드상으로는 그 글자와 입력 칸이 ‘연결’돼 있지 않은 경우가 많다.

가상의 B공공기관 신청 폼을 키보드와 스크린리더로 채워본다고 하자. 탭을 눌러 첫 번째 입력 칸에 초점이 가면, 스크린리더는 ‘이름을 입력하세요’가 아니라 그냥 ‘편집창’이라고만 읽는다. 옆에 분명히 ‘이름’이라는 글자가 보이는데, 그 글자가 이 칸의 라벨로 ‘연결’돼 있지 않아서 읽어주지 못하는 거다. 사용자는 지금 이 칸이 이름 칸인지 연락처 칸인지 알 수 없다. 칸이 열 개쯤 되면, 어디에 뭘 넣어야 할지 전혀 감을 못 잡고 결국 신청을 포기한다.

더 까다로운 건 ‘플레이스홀더(placeholder)’만 믿는 경우다. 입력 칸 안에 흐릿한 글씨로 ‘이름을 입력하세요’라고 적어두고, 별도 라벨은 두지 않는 디자인이다. 화면으로는 깔끔하지만, 글자를 입력하기 시작하면 그 안내 글씨가 사라져서 ‘여기가 무슨 칸이었지?’를 다시 알 수 없게 된다. 게다가 플레이스홀더는 대비가 약해 시력이 약한 사용자에게는 잘 안 보이고, 스크린리더가 라벨처럼 안정적으로 읽어주지도 못한다. 안내 글씨는 ‘칸 안의 흐린 글자’가 아니라 ‘칸에 연결된 명확한 라벨’이어야 한다.

오류 처리도 빼놓을 수 없다. 폼을 잘못 채우면 ‘어디가 왜 틀렸는지’를 알려줘야 하는데, 이 오류 안내가 색깔로만(빨간 테두리) 표시되거나, 화면 맨 위에 잠깐 떴다 사라지거나, 아예 스크린리더가 읽지 못하는 방식으로 표시되면, 키보드·스크린리더 사용자는 ‘제출이 안 되는데 왜 안 되는지’를 모른 채 같은 자리를 맴돈다. 좋은 폼은 오류가 났을 때 ‘어느 칸이’ ‘무엇 때문에’ 틀렸는지를 그 칸 가까이에, 글자로, 스크린리더가 읽을 수 있게 안내한다.

그리고 ‘멋대로 움직이는 화면’ 이야기도 해야겠다. 자동으로 넘어가는 배너, 가만히 있어도 깜빡이거나 흐르는 애니메이션, 일정 시간이 지나면 저절로 로그아웃되거나 페이지가 바뀌는 처리 — 이런 것들이 접근성에서는 큰 장벽이 된다. 스크린리더로 한 글자씩 천천히 읽어 나가는 사용자에게, 화면이 멋대로 휙휙 바뀌면 ‘방금 읽던 게 어디 갔지’ 하고 길을 잃는다. 신청 폼을 천천히 채우는데 시간 제한 때문에 갑자기 세션이 끊겨 처음부터 다시 해야 한다면, 그 좌절감은 이루 말할 수 없다. 표준은 ‘움직임은 멈출 수 있게, 시간 제한은 늘리거나 끌 수 있게’ 하라고 안내한다. 사용자마다 읽고 조작하는 속도가 다르다는 걸 인정하는 것, 그게 배려의 시작이다.

■ 막힘 패턴 7: 똑같은 ‘여기 클릭’과 정체불명의 링크

스크린리더 사용자는 페이지의 링크만 따로 모아 훑어보는 기능을 자주 쓴다. 링크 목록을 쭉 듣고 원하는 곳으로 바로 가는 거다. 그래서 링크의 ‘글자’가 그 자체로 어디로 가는지를 설명해야 한다. 그런데 가이드 없는 사이트의 링크는 ‘여기 클릭’, ‘바로가기’, ‘더보기’ 같은 정체불명의 글자로 가득하다.

가상의 A광역지자체 공지 목록을 떠올려 보자. 공지 열 건이 나란히 있고, 각 공지 끝에 ‘자세히 보기’ 링크가 붙어 있다. 화면으로 보면 어느 공지의 ‘자세히 보기’인지 위치로 알 수 있다. 그런데 스크린리더로 링크 목록만 들으면 ‘자세히 보기, 자세히 보기, 자세히 보기…’가 열 번 반복될 뿐이다. 어느 게 무슨 공지의 링크인지 전혀 구분이 안 된다. 사용자는 결국 링크 목록을 포기하고 페이지 전체를 다시 더듬어야 한다. 링크 글자는 ‘앞뒤 맥락 없이도 어디로 가는지’가 드러나야 한다. ‘○○ 행사 안내 자세히 보기’처럼 말이다.

새 창으로 열리는 링크도 미리 알려줘야 한다. 클릭했더니 예고 없이 새 창이 뜨면, 화면을 보는 사람은 새 창이 떴다는 걸 눈으로 알지만, 스크린리더 사용자는 ‘뒤로 가기’를 눌러도 안 돌아가서 당황한다. ‘새 창 열림’이라는 안내를 링크에 함께 심어두면, 사용자는 마음의 준비를 하고 누른다. 작은 배려 하나가 큰 혼란을 막는다.

본론 3 — 왜 자꾸 이런 일이 반복되나

■ 접근성은 ‘마지막에 덧칠하는 것’이 아니다

지금까지의 사례를 보면 한 가지 공통점이 보인다. 전부 ‘나중에 챙기려다 놓친’ 것들이라는 점이다. 디자인을 다 끝내고, 화면을 다 만들고, 출시 직전에 ‘아 맞다 접근성’ 하면서 급하게 대체 텍스트 몇 개 붙이고 끝낸다. 그래서 늘 부족하다. 접근성은 다 만든 케이크 위에 글씨를 얹듯 ‘마지막에 덧칠하는 것’이 아니라, 반죽 단계부터 섞여 들어가야 하는 ‘재료’다.

왜 그럴까. 앞서 본 문제들은 대부분 ‘코드의 뼈대’에 관한 것이기 때문이다. 버튼을 진짜 버튼으로 만들었는지, 제목을 진짜 제목으로 표시했는지, 폼 라벨을 입력 칸에 제대로 연결했는지 — 이건 다 만들 때 결정되는 ‘구조’의 문제다. 일단 잘못된 구조로 다 만들어 놓고 나면, 나중에 접근성만 따로 떼어 고치는 게 거의 새로 만드는 수준의 작업이 된다. 그래서 접근성은 ‘처음부터’ 챙기는 게 압도적으로 싸다. 디자인 부채와 똑같다. 쌓이기 전에 막는 게 싸고, 쌓인 뒤에 갚으면 몇 배로 든다.

현장에서 보면, ‘출시 직전 접근성 점검’이라는 말 자체가 이미 늦은 신호다. 그 시점엔 화면도, 흐름도, 코드 구조도 다 굳어 있다. 거기서 발견되는 접근성 문제는 ‘조금 손보면 되는 일’이 아니라 ‘뼈대를 다시 짜야 하는 일’인 경우가 많다. 그런데 일정은 코앞이고 예산은 바닥났으니, 결국 ‘일단 출시하고 나중에 고치자’가 된다. 그 ‘나중’이 안 온다는 건 앞에서 이미 말한 대로다. 반대로 기획 단계에서부터 ‘이 버튼은 키보드로 눌리는가’, ‘이 이미지엔 어떤 설명을 붙일까’, ‘필수 표시는 색 말고 무엇으로 할까’를 함께 정해두면, 추가 비용 없이 접근성이 ‘기본으로’ 따라온다. 같은 일을 언제 하느냐의 차이가, 비용과 품질을 모두 가른다.

여기서 KRDS 이야기를 자연스럽게 꺼내야겠다. 행정안전부가 만든 공공 디자인 시스템 KRDS는 버튼·입력칸·폼·표 같은 부품을 ‘접근성을 이미 갖춘 상태’로 표준화해 둔다. 즉 KRDS를 따라 만들면, 버튼은 처음부터 코드에서도 버튼이고, 폼 라벨은 처음부터 입력 칸에 연결돼 있고, 제목 구조는 처음부터 단계가 맞다. 접근성을 ‘나중에 덧칠’하는 게 아니라 ‘처음부터 내장’하는 셈이다. 접근성을 위한 가장 현실적인 출발점이, 사실은 ‘좋은 디자인 시스템을 따르는 것’인 이유가 여기 있다.

이걸 다른 각도로 보면, 접근성을 ‘담당자 개인의 선의’에 맡기지 않아도 된다는 뜻이기도 하다. 매번 새 페이지를 만들 때마다 ‘이번엔 대체 텍스트 잊지 말아야지’, ‘초점 표시 지우지 말아야지’를 사람이 일일이 기억하는 건 현실적으로 지속되기 어렵다. 사람은 잊고, 바쁘면 빠뜨리고, 담당자가 바뀌면 처음부터 다시 시작한다. 반면 접근성이 ‘부품에 내장’돼 있으면, 그 부품을 가져다 쓰는 것만으로 접근성이 기본으로 따라온다. 의지력에 기대지 않고 ‘구조’로 보장되는 거다. 좋은 시스템은 사람이 실수해도 큰 사고가 안 나게 받쳐준다. 접근성을 디자인 시스템에 녹여두는 건, 결국 ‘실수해도 괜찮은 안전망’을 까는 일이다.

그리고 이건 비용 측면에서도 합리적이다. 접근성을 ‘별도 프로젝트’로 떼어내 따로 예산을 잡고, 따로 컨설팅을 받고, 따로 전수 점검을 하려면 큰돈이 든다. 반면 처음부터 표준 부품으로 만들면 접근성이 ‘기본값’이 되어 추가 비용이 거의 들지 않는다. 나중에 떼어내 고치는 게 비싸고, 처음부터 녹여 넣는 게 싸다. 이 단순한 사실을 알면, ‘우리는 예산이 없어 접근성을 못 챙긴다’는 말이 실은 앞뒤가 바뀐 이야기라는 게 보인다. 예산이 없을수록 더더욱 ‘처음부터 표준대로’ 만들어야 나중에 비싼 청구서를 피할 수 있다.

■ 846개 규칙 안에 접근성이 녹아 있다

KRDS의 846개 규칙(DS 120 + CP 446 + BP 108 + SP 172)은 단순히 ‘예쁘게 만드는 법’이 아니다. 그 안에는 접근성을 지키는 구체적 요건이 곳곳에 박혀 있다. 색 대비를 충분히 둘 것, 버튼·링크의 역할을 코드로 명확히 할 것, 폼에 라벨을 연결할 것, 초점 표시를 또렷이 둘 것, 키보드로 모든 기능을 쓸 수 있게 할 것 — 이런 요건들이 디자인 시스템(DS), 컴포넌트(CP), 기본 패턴(BP), 서비스 패턴(SP) 곳곳에 스며 있다.

이게 중요한 이유는, 접근성을 ‘별도의 일’로 따로 챙기지 않아도 된다는 데 있다. KRDS를 제대로 따르는 것 자체가 접근성의 상당 부분을 자동으로 충족시킨다. 디자인과 접근성이 따로 노는 게 아니라 같은 기준 안에서 함께 굴러가는 거다. 물론 KRDS를 따른다고 접근성이 100% 완성되는 건 아니다. 대체 텍스트의 내용을 ‘무엇으로 적을지’ 같은 건 사람의 판단이 필요하고, 실제 스크린리더로 끝까지 가보는 점검도 따로 해야 한다. 하지만 출발점이 ‘접근성을 갖춘 표준 부품’이라면, 나머지 점검의 부담이 훨씬 가벼워진다.

조금 더 풀어보자면, 846개 규칙은 ‘디자인 시스템(DS) 120개, 컴포넌트(CP) 446개, 기본 패턴(BP) 108개, 서비스 패턴(SP) 172개’로 나뉜다. 이 네 층은 앞서 비유한 ‘건물’처럼 차곡차곡 쌓인다. 맨 아래 DS는 색·글꼴·간격 같은 기초인데, 여기서 색 대비 기준이 지켜지면 ‘색만으로 정보를 전달하는’ 문제와 ‘대비 미달’ 문제가 바닥에서부터 예방된다. 그 위 CP는 버튼·입력칸·폼·표 같은 부품인데, 이게 표준대로면 ‘버튼이 코드에서도 버튼’이고 ‘라벨이 칸에 연결’되고 ‘표에 머리글이 심긴다’. 그 위 BP·SP는 폼 흐름과 신청·검색 같은 서비스 패턴인데, 여기서 오류 안내·초점 흐름·시간 제한 같은 운용 단계의 접근성이 챙겨진다. 즉 오늘 본 일곱 가지 막힘 패턴 대부분이, 이 네 층의 어딘가에서 표준을 빠뜨렸기 때문에 생긴 것들이다. 거꾸로 말하면, 846규칙을 기준으로 점검하면 ‘어느 층에서 무엇이 빠졌는지’가 구조적으로 드러난다.

■ ‘점검을 안 해서’ 모를 뿐, 문제는 이미 거기 있다

마지막으로 짚고 싶은 건, 이 모든 문제가 ‘점검을 안 해서 안 보일 뿐’ 이미 사이트에 존재한다는 사실이다. 대체 텍스트가 없는 배너, 키보드로 못 닿는 메뉴, 안 보이는 초점, 색으로만 표시된 필수 항목 — 이건 지금 이 순간에도 누군가의 화면에서 ‘벽’이 되고 있다. 다만 그 사람이 민원을 넣지 않으니 담당자가 모를 뿐이다.

이 ‘침묵하는 불만’이 접근성 문제의 가장 무서운 특징이다. 보통의 불편은 민원이라는 신호로 돌아온다. 페이지가 느리면 ‘느리다’는 항의가 오고, 정보가 틀리면 ‘틀렸다’는 지적이 온다. 그런데 접근성은 ‘막힌 사람’ 본인이 신고하기 가장 어려운 영역이다. 신청 페이지가 막혀서 신청을 못 했는데, 그 ‘신청을 못 했다’는 사실을 어디에 어떻게 알리겠는가. 막힌 사람은 대개 조용히 떠나고, 떠난 사람은 통계에 ‘이탈’로조차 안 남을 때가 많다. 그래서 담당자는 ‘우리 사이트 접근성에 문제없다’고 믿게 된다. 불만이 안 들어오니까. 하지만 ‘불만이 없는 것’과 ‘문제가 없는 것’은 전혀 다르다. 침묵은 만족의 신호가 아니라, 포기의 신호일 수 있다. 접근성을 능동적으로 점검해야 하는 이유가 바로 이것이다. 사용자가 말해주길 기다리면, 그 신호는 영영 오지 않는다.

그래서 접근성에서 가장 먼저 해야 할 일은 ‘고치기’가 아니라 ‘보기’다. 우리 사이트에 어떤 벽이 있는지를 먼저 봐야 한다. 보이지 않는 문제는 고칠 수가 없다. 그리고 이 ‘보기’는 사람이 일일이 33항목을 손으로 점검하기엔 너무 방대하고 시간이 많이 든다. 페이지가 수백 개인 공공 사이트에서, 모든 페이지의 모든 이미지·버튼·폼·제목을 사람이 하나하나 확인하는 건 현실적으로 불가능에 가깝다. 바로 여기서 ‘자동 검사’가 필요해진다.

물론 ‘자동 검사가 전부냐’ 하면 그건 아니다. 솔직하게 말하자. 접근성의 일부 항목은 기계가 100% 판단하기 어렵다. 예를 들어 대체 텍스트가 ‘있느냐 없느냐’는 기계가 잡아내지만, 그 대체 텍스트가 ‘이미지의 의미를 제대로 담았느냐’는 결국 사람이 봐야 한다. 그래서 가장 좋은 방식은 ‘자동 검사로 넓게 훑어 명백한 문제를 빠르게 잡고, 사람의 점검으로 미묘한 부분을 마무리하는’ 2단계다. 자동 검사는 ‘사람을 대체하는 것’이 아니라 ‘사람이 정말 봐야 할 곳에 집중하게 해주는’ 도구다. 수백 페이지에서 ‘대체 텍스트가 아예 없는 이미지 200개, 라벨 없는 입력 칸 80개, 대비 미달 텍스트 150곳’을 먼저 자동으로 추려주면, 사람은 그 목록을 들고 효율적으로 고쳐 나갈 수 있다. 맨손으로 수백 페이지를 더듬는 것과는 비교가 안 된다.

그리고 자동 검사의 또 다른 힘은 ‘반복 점검’에 있다. 접근성은 한 번 고쳤다고 끝나는 게 아니다. 새 페이지가 올라오고, 콘텐츠가 바뀌고, 기능이 추가될 때마다 새로운 벽이 생긴다. 디자인 부채가 쌓이듯 ‘접근성 부채’도 시간이 가면 다시 쌓인다. 그래서 정기적으로 점검해 ‘새로 생긴 문제’를 그때그때 잡아야 하는데, 이걸 사람이 매번 손으로 하기는 어렵다. 자동 검사를 주기적으로 돌리면, 접근성을 ‘한 번의 프로젝트’가 아니라 ‘꾸준히 관리하는 상태’로 유지할 수 있다. 건강검진을 한 번 받고 끝내는 게 아니라 주기적으로 받는 것과 같다.

마무리

자, 이제 오늘 긴 이야기를 한 문장으로 줄이면 이렇다. ‘화면을 보면 멀쩡한 사이트가, 스크린리더로 들어가 보면 곳곳에서 막힌다. 그 막힘은 이미 존재하지만, 점검하지 않으면 보이지 않는다.’

우리는 일곱 가지 막힘 패턴을 봤다. 대체 텍스트가 없어 정보가 사라지는 이미지, 키보드로는 닿을 수 없는 메뉴와 팝업, 어디 있는지 보이지 않는 초점, 색으로만 말하는 정보, 제목과 구조가 없는 글자 벽, 라벨 없는 입력 칸과 멋대로 움직이는 화면, 그리고 정체불명의 똑같은 링크들. 이것들은 따로 노는 게 아니라 ‘코드에 의미를 심는 작업을 빠뜨렸다’는 하나의 원인에서 함께 자란다. 그래서 하나가 보이면 나머지도 의심하고, 하나를 제대로 챙기면 나머지도 함께 좋아진다.

그리고 우리는 그 해법의 출발점도 봤다. 접근성은 마지막에 덧칠하는 게 아니라 처음부터 내장하는 것이고, 그 ‘처음부터 내장’을 가장 현실적으로 도와주는 게 KRDS 같은 표준이며, 접근성은 행정안전부 7대 품질 영역 중 하나로 못 박힌 ‘법적 의무’라는 사실이다. 잘하면 좋은 게 아니라, 안 하면 안 되는 것. 그게 공공 사이트의 접근성이다.

이제 가장 중요한 한 걸음이 남았다. ‘우리 사이트엔 어떤 벽이 있을까’를 확인하는 일이다. 막연한 걱정만으로는 아무것도 바뀌지 않는다. 실제로 우리 사이트의 이미지·버튼·폼·제목·색 대비가 KWCAG 33항목을 얼마나 지키고 있는지, 어디가 막혀 있는지를 ‘보는’ 것부터 시작해야 한다.

ViewCheck는 바로 그 ‘보기’를 자동으로 해준다. 사이트 주소만 넣으면, 페이지마다 접근성 항목을 자동으로 점검해서 어떤 이미지에 대체 텍스트가 없는지, 어디서 키보드 초점이 끊기는지, 어떤 색 조합이 대비 기준에 미달인지, 제목 구조가 어디서 무너졌는지를 한눈에 보여준다. KRDS 846규칙 진단과 함께 웹 접근성(KWCAG) 분석이 한 화면에 정리되니, ‘우리 사이트가 어디서 막혀 있는가’를 처음으로 ‘눈으로’ 확인할 수 있다. 사람이 수백 페이지를 일일이 손으로 점검할 필요 없이, 자동 검사가 그 방대한 일을 대신한다.

특히 좋은 점은, 결과가 ‘점수 몇 점’으로 끝나지 않는다는 거다. 분석 결과 상단의 점수 카드에서 전체 윤곽을 잡은 뒤, 웹 접근성 분석 탭으로 들어가면 ‘어느 페이지의 어떤 요소가 어떤 항목을 어겼는지’가 구체적으로 나온다. 그냥 ‘접근성 70점입니다’가 아니라, ‘이 배너 이미지에 대체 텍스트가 없습니다’, ‘이 입력 칸에 라벨이 연결돼 있지 않습니다’처럼 ‘고칠 자리’를 콕 집어준다. 막연한 평가가 아니라 ‘할 일 목록’을 손에 쥐여주는 셈이다. 담당자 입장에서는 ‘무엇을 어디서부터 고쳐야 할지’가 분명해지니, 막막함이 한결 줄어든다. 더 좋은 건, 행정안전부 7대 품질 영역 전반을 함께 진단하니 접근성 하나만이 아니라 사이트의 전반적인 품질 상태를 같은 자리에서 파악할 수 있다는 점이다.

그리고 결과를 받아 들고 너무 놀라지 마시라. 처음 진단을 돌리면 생각보다 많은 항목이 빨간불로 뜰 수 있다. 하지만 그건 ‘우리 사이트가 형편없다’는 뜻이 아니라, ‘그동안 안 보이던 것이 드디어 보이기 시작했다’는 뜻이다. 거의 모든 사이트가 처음엔 그렇다. 중요한 건 그 목록을 손에 쥐고 ‘하나씩’ 메워 가는 거다. 오늘 대체 텍스트를 채우고, 다음엔 초점 표시를 살리고, 그다음엔 폼 라벨을 연결하고. 그렇게 한 항목씩 닫혀 있던 문을 열다 보면, 어느새 ‘보지 않는 사람도, 마우스를 못 쓰는 사람도, 시력이 약한 사람도’ 똑같이 들어올 수 있는 사이트가 된다. 그게 공공 서비스가 본래 가야 할 모습이고, 그 첫걸음이 ‘우리 사이트를 한번 들여다보는 일’이다.

다음 주에는 키보드만으로 사이트를 끝까지 써보는 ‘키보드 내비게이션’ 이야기로 한 걸음 더 들어가 볼 생각이다. 오늘 글에서 ‘키보드로는 갈 수 없는 길’을 잠깐 맛봤다면, 다음엔 그 길을 어떻게 뚫는지를 더 구체적으로 다룬다. 접근성은 한 번에 다 챙기는 게 아니라 한 항목씩 차근차근 메워가는 일이다. 오늘 한 항목, 다음 주 또 한 항목. 그렇게 쌓이면 어느새 ‘누구나 들어올 수 있는 사이트’가 된다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #스크린리더 #대체텍스트 #키보드접근성 #전자정부 #행정안전부 #공공디자인시스템 #접근성진단 #ViewCheck