연한 회색 글씨, ‘안 보인다’는 민원의 정체

연한 회색 글씨, ‘안 보인다’는 민원의 정체

반응형

【 공감·문제제기 】

“글씨가 안 보여요.” 공공 사이트 담당자가 가장 많이 받는 민원 중 하나가 이거다. 그런데 정작 담당자 본인 모니터에서는 멀쩡하게 잘 보인다. 그래서 처음엔 다들 이렇게 생각한다. ‘저 분 모니터가 이상한 거 아닐까’, ‘브라우저 설정 문제겠지’, ‘나이가 있으셔서 그런가’. 그렇게 민원 한 건을 ‘개인 사정’으로 분류해 넘긴다. 그런데 같은 민원이 한 달에 몇 번씩, 다른 사람한테서 계속 들어온다면? 그건 더 이상 개인 사정이 아니다. 사이트 자체가 ‘어떤 사람들에게는 안 보이게’ 만들어져 있다는 뜻이다.

오늘 이야기는 바로 그 ‘안 보인다’는 민원의 정체다. 결론부터 솔직하게 말하면, 그 민원의 상당수는 ‘연한 회색 글씨’ 때문이다. 요즘 웹디자인 유행이 그렇다. 깔끔하고 세련돼 보이려고 글자를 진한 검정 대신 연한 회색으로 깔고, 보조 설명은 더 연하게, 안내 문구는 거의 흰 바탕에 묻힐 만큼 흐리게 쓴다. 디자인하는 사람의 큰 모니터, 좋은 시력, 어두운 실내에서는 그게 ‘고급스럽다’. 그런데 화면을 밝은 야외에서 보는 사람, 저가형 모니터를 쓰는 사람, 나이가 들어 대비 감지 능력이 떨어진 사람, 저시력 사용자에게는 그 연한 회색이 그냥 ‘안 보이는 글씨’다.

나도 처음엔 이게 그렇게 심각한 문제인 줄 몰랐다. 디자인 트렌드니까, 예쁘니까, 다들 그렇게 하니까. 그런데 공공 웹사이트를 점검하는 일을 하다 보니 생각이 완전히 바뀌었다. 민간 쇼핑몰이라면 ‘글씨 안 보이면 다른 데서 사면 되지’가 통한다. 하지만 공공 서비스는 다르다. 어떤 사람이 ‘안 보여서’ 신청서를 못 읽으면, 그 사람은 받아야 할 지원금을 못 받고, 신고해야 할 걸 못 하고, 알아야 할 권리를 놓친다. 대체재가 없다. 그 사이트가 유일한 창구다. 그러니 ‘안 보인다’는 민원은 공공 사이트에서는 단순한 불만이 아니라 ‘서비스에서 누군가 배제되고 있다’는 경고음이다.

이번 주 주제가 ‘색대비·자막·스크린리더’, 즉 웹 접근성(KWCAG)인 이유가 여기 있다. 접근성이라고 하면 흔히 ‘장애인을 위한 특별 배려’ 정도로 생각하는데, 실제 현장에서 접근성 문제를 가장 많이 겪는 건 ‘평범한 다수’다. 노안이 온 50대, 밝은 햇빛 아래에서 휴대폰을 보는 사람, 화면을 끝까지 키워본 적 없는 어르신, 소리를 못 켜는 사무실에서 영상을 보는 직장인. 접근성은 소수를 위한 게 아니라 ‘모두가 어떤 상황에서든 쓸 수 있게’ 만드는 일이다. 그리고 그 출발점이 바로 오늘 다룰 세 가지 — 색대비, 자막, 스크린리더다.

이 글은 누구를 탓하려는 게 아니다. 연한 회색 글씨를 깐 디자이너도, 자막 없이 영상을 올린 담당자도 나쁜 마음으로 그런 게 아니다. 그냥 ‘안 보이는 사람의 입장’을 한 번도 직접 겪어본 적이 없을 뿐이다. 보이는 사람은 안 보이는 사람의 세계를 상상하기 어렵다. 그래서 오늘은 가상의 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관 사례를 통해 ‘무엇이 어떻게 안 보이게 되는지’를 최대한 구체적으로 그려보려 한다. 보이기 시작해야 고칠 마음이 생긴다. 안 보이던 게 보이는 순간, 우리 사이트의 연한 회색 글씨가 갑자기 달라 보일 거다.

한 가지 더 짚고 시작하자. 접근성 문제는 ‘조용히’ 손해를 낸다. 디자인이 깨지면 누가 봐도 안다 — 글자가 겹치거나 버튼이 화면 밖으로 튀어나가면 바로 민원이 들어온다. 그런데 ‘안 보이는 글씨’는 다르다. 그 글씨가 안 보이는 사람은 대개 민원을 넣지 않는다. 그냥 ‘아, 나는 못 읽나 보다’ 하고 조용히 떠난다. 화가 나서 항의하는 게 아니라, 자책하면서 포기하는 거다. “내 눈이 나빠서”, “내가 기계를 잘 못 다뤄서”. 그래서 접근성 문제는 민원 통계에 잘 잡히지도 않는다. 들어온 민원은 ‘빙산의 일각’이고, 말없이 떠난 사람이 그 아래 훨씬 많다. ‘민원이 별로 없으니 괜찮다’고 안심하는 게 가장 위험한 이유가 이거다. 민원이 없는 게 ‘문제가 없어서’가 아니라 ‘포기한 사람들이 말없이 사라져서’일 수 있다.

그리고 이건 단지 친절의 문제가 아니라 ‘의무’의 문제이기도 하다. 공공기관 웹사이트의 접근성은 법과 지침으로 보장하도록 돼 있다. 누군가가 장애나 환경 때문에 공공 서비스에서 배제되지 않도록 하는 건 ‘잘하면 좋은 것’이 아니라 ‘반드시 해야 하는 것’이다. 민간 서비스라면 ‘우리 고객층이 아니니까’ 하고 넘길 수도 있겠지만, 공공 서비스에는 ‘우리 고객이 아닌 국민’이라는 게 없다. 모든 국민이 다 우리 사용자다. 그 전제 위에서 보면, 접근성은 선택지가 아니라 출발선이다.

 

【본론 1 — 색대비, ‘안 보인다’의 진짜 원인】

■ 연한 회색이 ‘세련됨’이 아니라 ‘장벽’이 되는 순간

먼저 색대비가 뭔지부터 짚자. 색대비(contrast)는 글자색과 배경색이 ‘얼마나 차이 나느냐’를 수치로 표현한 거다. 흰 바탕에 검은 글씨는 대비가 최대치에 가깝다. 흰 바탕에 연한 회색 글씨는 대비가 낮다. 이 차이를 비율로 나타낸 게 ‘명도 대비비’인데, 웹 접근성 기준에서는 본문 글자라면 배경과 4.5대 1 이상의 대비를 권한다. 큰 글자(굵은 제목 등)는 조금 완화해서 3대 1 이상. 이 숫자가 중요한 게 아니라, ‘대비에는 지켜야 할 최소선이 있다’는 사실이 핵심이다.

문제는 요즘 디자인 트렌드가 이 최소선을 아무렇지 않게 넘나든다는 거다. ○○시의 한 안내 페이지를 점검한 적이 있다. 메인 안내문은 그럭저럭 읽혔는데, 정작 가장 중요한 ‘신청 마감일’과 ‘유의사항’이 연한 회색으로 깔려 있었다. 디자이너 입장에서는 ‘본문보다 덜 중요한 보조 정보니까 연하게’ 처리한 거다. 그런데 사용자 입장에서 ‘마감일’과 ‘유의사항’은 절대 보조 정보가 아니다. 오히려 가장 놓치면 안 되는 정보다. 디자인의 ‘시각적 위계’와 정보의 ‘실제 중요도’가 거꾸로 뒤집힌 거다. 가장 중요한 정보가 가장 안 보이는 색으로 칠해져 있었다.

이게 왜 심각하냐면, 이런 페이지는 ‘대부분의 사람’에게는 문제없이 보인다는 거다. 그래서 담당자는 문제를 인지조차 못 한다. 점검을 나가 “이 마감일 글씨, 대비가 기준 미달입니다”라고 알려드리면 다들 깜짝 놀란다. “저는 잘 보이는데요?” 맞다. 담당자는 보인다. 디자이너도 보인다. 결재한 윗선도 보인다. 그 페이지를 만들고 검토한 모든 사람이 ‘잘 보이는 눈과 좋은 환경’을 가졌기 때문이다. 정작 안 보이는 사람들은 그 의사결정 테이블에 없었다. 접근성 문제가 무서운 이유가 바로 이거다 — 문제를 겪는 사람이 문제를 만드는 자리에 없다.

연한 회색 글씨가 안 보이는 상황을 구체적으로 떠올려 보자. 첫째, 야외다. 점심시간에 밖에서 휴대폰으로 공공 사이트에 들어가 민원 처리 방법을 찾는다. 햇빛 때문에 화면 자체가 잘 안 보이는데, 글씨까지 연하면 그냥 ‘하얀 화면’으로 보인다. 둘째, 저가형 화면이다. 모두가 색 재현이 좋은 고급 모니터를 쓰는 게 아니다. 오래된 노트북, 저가형 태블릿에서는 연한 회색과 흰 배경의 차이가 거의 사라진다. 셋째, 나이다. 사람은 나이가 들수록 미세한 명도 차이를 구분하는 능력이 떨어진다. 젊은 디자이너에게는 또렷한 회색이, 70대 어르신에게는 ‘아무것도 없는 빈 공간’으로 보인다. 공공 서비스의 핵심 사용자층이 누구인지 생각하면, 이건 결코 작은 문제가 아니다.

여기서 ‘디자이너의 환경’ 이야기를 잠깐 짚고 가야겠다. 디자인을 만드는 사람의 작업 환경은 평균적인 사용자와 너무 다르다. 색이 정확한 고급 모니터, 어둡고 조용한 실내, 화면 밝기를 적정하게 맞춘 상태, 그리고 대개 젊고 시력이 좋은 눈. 이 ‘최적의 조건’에서 보면 연한 회색도 충분히 또렷하다. 문제는 사용자의 99%가 그 최적 조건에 있지 않다는 거다. 사용자는 밝기를 최대로 켠 야외에서, 색이 누런 저가 화면에서, 노안이 온 눈으로, 그것도 한 손으로 다른 일을 하며 본다. 디자이너의 ‘잘 보인다’와 사용자의 ‘안 보인다’ 사이의 간극이 바로 여기서 생긴다. 그래서 접근성을 챙기는 첫걸음은 ‘내 환경이 표준이 아니다’를 인정하는 거다. 내 눈에 멋있게 보이는 연한 회색이, 정작 그 정보가 가장 필요한 사람에게는 보이지 않을 수 있다는 사실을 늘 의심해야 한다.

한 가지 더. ‘연하게 처리하는 디자인’ 자체가 나쁜 건 아니다. 정보에 위계를 주는 건 좋은 디자인이다. 문제는 ‘연하게 처리하는 정도’가 기준선을 넘어가는 거다. 본문보다 덜 중요한 정보를 ‘약간 차분하게’ 만드는 것과, ‘읽을 수 없을 만큼 흐리게’ 만드는 건 전혀 다른 이야기다. 위계를 주되, 그 가장 흐린 글자조차 기준 대비를 넘기게 만드는 것 — 그게 ‘접근성을 지키면서도 위계가 살아 있는’ 디자인이다. 위계와 가독성은 둘 중 하나를 포기해야 하는 게 아니라, 둘 다 지킬 수 있는 선이 분명히 존재한다. 그 선을 아는 게 전문성이다.

■ ‘색으로만 구분’하면 누군가는 정보를 통째로 놓친다

색대비와 짝을 이루는 또 하나의 함정이 ‘색에만 의존한 정보 전달’이다. A광역지자체의 신청 현황 페이지를 본 적이 있다. 신청 상태를 색으로만 구분해 놓았더라. 초록 점은 ‘처리 완료’, 빨간 점은 ‘반려’, 노란 점은 ‘검토 중’. 디자인은 깔끔했다. 문제는 색을 구분하기 어려운 사용자에게는 이 셋이 전부 ‘비슷한 회색 점’으로 보인다는 거다. 색맹·색약을 가진 사람은 생각보다 많다. 특히 적록색약은 남성에게 드물지 않게 나타난다. 그런 사용자에게 ‘초록과 빨강으로 구분’은 ‘구분 없음’과 같다.

해결은 의외로 간단하다. 색‘만’으로 구분하지 말고, 색에 ‘하나 더’를 얹으면 된다. 처리 완료에는 체크 모양을, 반려에는 엑스 모양을, 검토 중에는 시계 모양을 함께 넣는 식이다. 글자를 붙여도 된다. ‘완료/반려/검토중’이라고 짧게 라벨을 다는 거다. 색은 빠르게 인지하는 보조 신호로 남기고, 모양이나 글자로 ‘진짜 정보’를 전달하면, 색을 못 보는 사람도 똑같이 정보를 얻는다. 이게 접근성의 기본 원칙 중 하나인 ‘색에만 기대지 마라’다. 색은 거들 뿐, 정보의 핵심은 색이 아닌 다른 수단으로도 전달돼야 한다.

여기서 흔한 오해 하나를 풀자. “우리 사용자 중에 색약이 몇 명이나 되겠냐”는 식의 계산이다. 이건 위험한 발상이다. 접근성은 ‘몇 명이냐’의 문제가 아니라 ‘배제되는 사람이 있느냐 없느냐’의 문제다. 공공 서비스는 단 한 사람도 ‘색을 못 봐서’ 신청을 못 하는 일이 있어서는 안 된다는 원칙 위에 서 있다. 게다가 색에 모양·글자를 더하는 처리는 색약자만을 위한 게 아니다. 흑백으로 인쇄했을 때도, 화면 밝기를 최저로 낮췄을 때도, 색이 깨져 보이는 환경에서도 정보가 살아남는다. 접근성을 챙기면 ‘모든 환경에서 더 튼튼한 화면’이 되는 부수 효과가 따라온다.

조금 더 구체적인 사례를 들어보자. 한중앙부처의 한 통계 페이지에서 막대그래프를 본 적이 있다. 항목별로 색만 다르게 칠해놓고, 그 색이 무엇을 뜻하는지는 ‘범례’로만 표시해 두었다. 범례도 작은 색 동그라미 옆에 글자를 붙인 형태였다. 색을 구분하기 어려운 사용자에게 이 그래프는 ‘비슷한 회색 막대 여러 개’와 ‘비슷한 회색 동그라미 여러 개’였다. 막대가 어느 항목인지 짝지을 수가 없으니, 그래프 전체가 의미를 잃는다. 이걸 해결하려면 색 외에 ‘패턴’(빗금, 점 등)을 더하거나, 막대마다 값을 직접 표기하거나, 막대 끝에 항목명을 직접 붙이면 된다. 색은 ‘빠르게 구분되게’ 돕는 보조 역할로 남기고, 정보의 본체는 색이 아닌 다른 수단이 떠받치게 하는 거다. 이렇게 하면 색약자뿐 아니라 흑백 출력물을 보는 사람, 작은 화면에서 색이 뭉개져 보이는 사람에게도 그래프가 살아난다.

그리고 이건 ‘링크 색’에서도 똑같이 적용된다. 본문 안에 링크를 색만으로 표시하는 경우가 많다. 파란 글씨가 링크, 검은 글씨가 일반 텍스트. 그런데 색을 구분하기 어려운 사용자에게는 ‘다 같은 회색 글씨’다. 어디가 눌리는 링크인지 알 수가 없다. 그래서 링크에는 색과 함께 밑줄을 함께 쓰는 게 좋다. 밑줄이 ‘여기는 링크다’를 색과 무관하게 알려준다. 한때 ‘밑줄이 촌스럽다’며 없애는 게 유행이었는데, 접근성 관점에서는 본문 속 링크의 밑줄은 단순한 장식이 아니라 ‘색을 못 봐도 알 수 있는 신호’다. 미감과 기능 사이에서, 본문 링크만큼은 기능 쪽에 무게를 두는 게 공공 사이트의 정답에 가깝다.

 

■ 대비를 ‘눈대중’으로 맞추는 게 불가능한 이유

여기서 많은 담당자가 막막해한다. “그럼 색을 얼마나 진하게 해야 기준을 통과하는데요?” 좋은 질문이다. 그리고 답은 ‘눈대중으로는 절대 못 맞춘다’는 거다. 색대비비는 사람 눈이 아니라 수식으로 계산된다. 글자색과 배경색 각각의 밝기를 공식에 넣어 비율을 구하는데, 이건 사람이 ‘대충 진해 보이니까 됐겠지’로 판단할 수 있는 영역이 아니다. 미묘하게 통과하는 조합과 미묘하게 미달하는 조합을 눈으로 구별하는 건 거의 불가능하다.

한중앙부처의 한 페이지에서 실제로 이런 일이 있었다. 담당자가 ‘글씨가 흐리다’는 민원을 받고 나름대로 색을 진하게 조정했다. 그런데 점검해 보니 여전히 기준 미달이었다. 본인은 ‘충분히 진하게 했다’고 생각했지만, 실제 대비비는 4.5대 1에 못 미쳤다. 눈으로는 분명 진해졌는데, 수치로는 여전히 모자랐던 거다. 반대 경우도 있다. 디자이너가 ‘너무 연한 거 아닌가’ 걱정한 색이 실제로는 기준을 넉넉히 통과하는 경우. 사람 눈의 ‘느낌’과 실제 ‘수치’는 자주 어긋난다. 그래서 대비는 반드시 ‘측정’해야 한다. 느낌으로 하면 틀린다.

그래서 잘 운영되는 사이트는 색을 ‘팔레트’로 관리한다. 미리 ‘이 글자색과 이 배경색 조합은 대비 통과’라고 검증해 둔 색 묶음을 정해두고, 그 안에서만 색을 고른다. 즉흥적으로 ‘이 정도 회색이면 멋있겠다’ 하고 색을 박는 게 아니라, 검증된 조합 안에서 쓰는 거다. 이렇게 하면 누가 페이지를 만들어도 대비 미달이 나오지 않는다. 색대비는 ‘만들 때마다 신경 쓰는 일’이 아니라 ‘처음에 안전한 팔레트를 정해두면 자동으로 지켜지는 일’이 돼야 한다. KRDS가 공공 표준 색 체계를 제시하는 이유도 여기 있다. 표준 안에서 고르면, 적어도 ‘대비 때문에 안 보이는’ 사고는 막을 수 있다.

대비를 다룰 때 자주 놓치는 게 또 있다. ‘배경이 단색이 아닐 때’다. 글자 위에 흰 글씨를 올리는데, 그 글자가 사진이나 그라데이션 위에 깔리는 경우다. 배너 이미지 위에 텍스트를 얹는 디자인이 그렇다. 사진의 밝은 부분 위 흰 글씨는 대비가 부족해 안 읽힌다. 사진은 부분마다 밝기가 달라서, 어떤 글자는 읽히고 어떤 글자는 사라진다. 이걸 막으려면 글자 뒤에 반투명한 어두운 막을 깔거나, 글자에 그림자를 주거나, 이미지를 전체적으로 어둡게 처리해 글자가 늘 충분한 대비를 갖게 해야 한다. ‘예쁜 사진 위 멋진 글씨’는 디자인 욕심이 나는 구도지만, 그 글씨가 정보라면 ‘어떤 배경 위에서도 읽히는가’를 반드시 확인해야 한다. 특히 공공 사이트 메인 배너는 ‘무슨 정책을 알리는 글’인 경우가 많아서, 그 글이 사진에 묻히면 핵심 메시지가 통째로 사라지는 셈이다.

그리고 ‘상태에 따라 변하는 색’도 챙겨야 한다. 비활성화된 버튼, 입력칸의 안내 문구(placeholder), 이미 방문한 링크 같은 것들은 보통 ‘연하게’ 처리된다. 그게 ‘비활성’이라는 신호이기 때문이다. 그런데 이 연한 정도가 지나치면, 비활성 버튼에 적힌 글자나 입력칸 안내 문구가 아예 안 읽힌다. 특히 입력칸 안내 문구는 ‘여기 무엇을 입력하라’는 중요한 정보인 경우가 많은데, 너무 연하면 사용자가 그 칸에 뭘 넣어야 할지 모른다. 비활성·안내 같은 상태 표시도 ‘읽을 수 있는 최소선’은 지켜야 한다. 연하게 하되, 사라지게 하지는 말 것 — 이게 상태 색의 원칙이다.

 

【본론 2 — 자막, ‘안 들리는 사람’을 위한 최소한의 배려】

■ 영상은 늘었는데 자막은 그대로

요즘 공공 사이트에 영상이 부쩍 늘었다. 정책 홍보 영상, 사용법 안내 영상, 기관장 인사말, 행사 영상. 영상이 글보다 친근하고 전달력이 좋으니 자연스러운 흐름이다. 그런데 점검을 다니다 보면, 그 많은 영상 중 자막이 제대로 달린 게 의외로 적다. B공공기관의 정책 안내 영상 시리즈를 본 적이 있는데, 음성으로만 핵심 내용을 설명하고 자막은 전혀 없었다. 영상미는 훌륭했지만, 소리를 못 듣는 사람에게는 ‘움직이는 그림’에 불과했다.

자막이 필요한 사람을 생각해 보자. 가장 먼저 떠오르는 건 청각장애인이다. 맞다. 하지만 자막의 수혜자는 그보다 훨씬 넓다. 소리를 켤 수 없는 사무실에서 영상을 보는 직장인, 이어폰이 없어 음소거로 보는 지하철 승객, 한국어가 아직 서툴러 글로 보면 더 잘 이해하는 외국인 주민, 발음이 빨라 음성만으로는 놓치는 어르신. 자막은 ‘안 들리는 사람’만을 위한 게 아니라 ‘지금 들을 수 없는 모든 상황’을 위한 거다. 실제로 자막을 켜고 영상을 보는 사람의 비율은 우리 생각보다 훨씬 높다. 자막은 소수를 위한 특별 기능이 아니라 다수가 일상적으로 쓰는 기능이다.

생각해 보면 우리도 이미 자막에 의존해 산다. 시끄러운 카페에서, 잠든 가족 옆에서, 회의 중 몰래 영상을 볼 때 — 소리를 끄고 자막으로 본 경험이 누구에게나 있다. 그런 ‘일시적 청각 제약’은 누구에게나 수시로 찾아온다. 즉 자막은 ‘남’을 위한 배려가 아니라 ‘언젠가의 나’를 위한 준비이기도 하다. 이렇게 생각하면 자막을 챙기는 일이 한결 가깝게 느껴진다. ‘특별한 누군가’를 위해서가 아니라, ‘소리를 못 쓰는 모든 순간의 모든 사람’을 위해서 다는 거다.

자막에는 단순히 ‘대사 받아쓰기’를 넘어서는 부분도 있다. 영상에 중요한 소리 정보가 있다면 — 예를 들어 경고음이 울리거나, 배경에서 안내 방송이 나온다면 — 그 ‘소리의 존재’도 자막으로 알려줘야 한다. 대사만 옮기고 ‘딩동, 알림음’ 같은 정보를 빠뜨리면, 자막만 보는 사람은 그 순간 무슨 일이 일어났는지 모른다. 공공 영상에서 이게 특히 중요한 건, 안내·경고·확인 같은 ‘소리로 강조한 정보’가 자주 등장하기 때문이다. 자막은 ‘들리는 말’만이 아니라 ‘들려야 할 정보 전부’를 글로 옮기는 작업이다.

 

■ ‘자동 자막’으로 충분하다는 착각

“요즘 자동으로 자막 달아주는 기능 있잖아요, 그거 켜면 되는 거 아닌가요?” 자주 받는 질문이다. 자동 자막은 분명 큰 발전이고, 없는 것보다 백배 낫다. 하지만 공공 정보에서는 그것만으로 부족할 때가 많다. C기관의 한 영상에서 자동 자막을 본 적이 있는데, 기관명과 정책명, 전문 용어가 줄줄이 오타로 나왔다. 비슷한 발음의 엉뚱한 단어로 바뀌어, 자막만 읽으면 무슨 말인지 알 수 없는 대목이 많았다. 정책 이름이 틀리고 금액 단위가 틀리면, 자막이 오히려 잘못된 정보를 전달하는 셈이 된다.

공공 정보는 정확성이 생명이다. 신청 자격, 지원 금액, 마감일, 제출 서류 — 이런 정보가 자막에서 틀리면 사용자가 손해를 본다. 그래서 자동 자막을 ‘초안’으로 쓰되, 사람이 한 번 검수해서 고치는 과정이 필요하다. 특히 숫자, 고유명사, 날짜는 반드시 확인해야 한다. 자동 자막을 켜는 데서 끝내지 말고, ‘틀린 데 없는지 한 번 보는’ 작은 수고를 더하는 것 — 그게 공공 영상 자막의 최소 기준이다.

검수 부담이 걱정된다면 발상을 살짝 바꿔보자. 영상을 만들 때 보통 ‘대본’이 먼저 있다. 그 대본을 그대로 자막의 바탕으로 쓰면, 자동 인식의 오타를 처음부터 피할 수 있다. 즉 ‘영상 만들고 나서 자막을 받아쓰기’가 아니라 ‘이미 있는 대본을 자막으로 옮기기’로 순서를 바꾸는 거다. 대본이 없는 즉석 인터뷰 같은 거라면 자동 자막을 초안으로 쓰되 핵심 정보만 빠르게 검수하면 된다. 자막을 ‘영상 끝나고 추가하는 귀찮은 일’이 아니라 ‘제작 과정의 한 단계’로 넣어두면, 부담이 훨씬 줄고 품질도 올라간다. 좋은 습관은 ‘나중에 챙기는 것’이 아니라 ‘흐름 안에 끼워 넣는 것’이다.

그리고 영상에 음성이 전혀 없는 경우 — 화면에 글자와 그림만 나오는 ‘무음 안내 영상’ 같은 것 — 도 함정이 있다. 이런 영상은 자막이 필요 없어 보이지만, 정작 ‘화면을 못 보는 사람’에게는 아무 정보도 전달되지 않는다. 소리도 없고 대체 설명도 없으니, 스크린리더 사용자에게는 ‘재생은 되는데 아무것도 안 들리는’ 영상이다. 이런 영상은 별도의 ‘대본 텍스트’를 영상 곁에 함께 제공해, 보지 않고도 내용을 알 수 있게 해야 한다. 결국 핵심은 같다 — 어떤 정보든 ‘하나의 감각에만 실리지 않게’ 하는 것. 소리에 실은 건 글로, 화면에만 실은 건 소리나 글로도 닿게 만드는 것이 접근성의 일관된 원칙이다.

■ 영상만이 아니라 ‘소리로 전달되는 모든 것’

자막 이야기를 조금 더 넓히면, 핵심은 ‘소리로만 전달되는 정보가 있으면 안 된다’는 거다. 영상의 음성 설명도 그렇고, 알림음으로만 ‘완료됐다’를 알려주는 것도 그렇다. 어떤 사이트는 신청이 끝나면 ‘딩’ 하는 소리만 나고 화면에는 별 변화가 없었다. 소리를 못 듣거나 음소거 상태인 사용자는 신청이 됐는지 안 됐는지 알 수가 없다. 소리로 알려주는 건 좋다. 다만 ‘소리로만’ 알려주면 안 된다. 소리에는 항상 ‘눈으로 보이는 신호’를 짝지어야 한다. 완료되면 소리와 함께 ‘신청이 완료되었습니다’라는 화면 메시지가 떠야 한다.

반대 경우도 있다. ‘눈으로만’ 전달되는 정보. 이건 다음 본론에서 다룰 스크린리더 이야기와 이어진다. 결국 접근성의 큰 원칙 하나는 ‘하나의 감각에만 정보를 싣지 마라’다. 소리에 실은 정보는 글로도, 글로 실은 정보는 소리로도 닿을 수 있어야 한다. 사람마다 쓸 수 있는 감각이 다르기 때문이다. 자막은 그 원칙을 ‘소리→글’ 방향에서 지키는 가장 기본적인 장치다.

 

【본론 3 — 스크린리더, ‘눈으로 안 보는’ 사용자의 세계】

■ 화면을 ‘읽어주는’ 도구가 있다

스크린리더(screen reader)는 화면의 내용을 음성으로 읽어주는 보조기술이다. 시각장애인이 컴퓨터와 휴대폰을 쓰는 핵심 도구다. 화면을 보는 대신 ‘듣고’, 마우스 대신 키보드나 손가락 제스처로 이동한다. 우리가 눈으로 한눈에 파악하는 화면을, 스크린리더 사용자는 위에서 아래로 순서대로 ‘읽어 내려가며’ 파악한다. 이 차이를 이해하는 게 스크린리더 접근성의 출발점이다.

여기서 많은 담당자가 놀란다. “우리 사이트, 눈으로 보면 멀쩡한데 스크린리더로는 왜 엉망인가요?” 이유는 간단하다. 스크린리더는 ‘보이는 모양’이 아니라 ‘코드에 적힌 내용’을 읽기 때문이다. 사람 눈에는 버튼처럼 보여도, 코드상으로 버튼이라고 표시돼 있지 않으면 스크린리더는 그게 버튼인지 모른다. 이미지가 예쁘게 떠 있어도, 그 이미지에 ‘무엇을 담은 그림인지’ 설명이 적혀 있지 않으면 스크린리더는 ‘이미지’라고만 읽고 지나간다. 즉 ‘보이는 화면’과 ‘코드가 말하는 화면’이 다를 수 있고, 스크린리더는 후자를 읽는다.

이 ‘보이는 화면 vs 코드가 말하는 화면’의 간극이 접근성에서 가장 이해하기 어려우면서도 가장 중요한 개념이다. 비유하자면 이렇다. 화면을 보는 사용자에게 우리 사이트는 ‘잘 꾸며진 매장’이다. 진열대가 보기 좋게 배치돼 있고, 어디가 계산대인지 한눈에 보인다. 그런데 스크린리더 사용자에게 우리 사이트는 ‘불이 꺼진 매장에서 누군가가 옆에서 읽어주는 안내문’ 같은 거다. 그 안내문에 “여기는 계산대입니다”라고 적혀 있어야 계산대인 줄 안다. 화면에 계산대처럼 ‘보이게’ 꾸며놨어도, 안내문에 그 정보가 없으면 스크린리더 사용자는 계산대의 존재 자체를 모른다. 그래서 ‘눈으로 멀쩡한’ 사이트가 스크린리더로는 엉망일 수 있다. 우리는 ‘보이는 화면’만 정성껏 꾸미고, ‘읽히는 화면’은 신경 쓰지 않았던 거다.

그럼 이 ‘읽히는 화면’은 어떻게 챙길까. 핵심은 ‘의미를 코드에 담는 것’이다. 버튼은 코드상으로도 버튼이어야 하고(버튼처럼 보이는 다른 요소가 아니라), 제목은 제목으로 표시돼야 하고, 목록은 목록으로 표시돼야 한다. 이렇게 ‘이건 무엇이다’를 코드가 알고 있어야 스크린리더가 “버튼, 신청하기”, “제목 수준 2, 신청 자격”처럼 정확히 안내한다. 반대로 모든 걸 그냥 ‘네모 칸’으로만 만들어놓고 보이는 모양만 꾸미면, 스크린리더는 그게 제목인지 본문인지 버튼인지 구분 못 하고 밋밋하게 읽어 내려간다. 그래서 접근성은 ‘보이는 디자인’을 넘어 ‘코드가 의미를 갖게 만드는 일’이다. 이건 개발 단계에서 챙겨야 하는 부분이라, 디자인만 예쁘게 한다고 해결되지 않는다.

 

■ 대체 텍스트가 없으면 그림은 ‘침묵’한다

가장 흔한 문제가 이미지의 대체 텍스트(alt) 누락이다. 대체 텍스트는 ‘이 그림이 무엇을 담고 있는지’를 글로 적어두는 거다. 스크린리더는 이 글을 읽어 사용자에게 그림의 내용을 전달한다. ○○시의 한 페이지에서, 가장 중요한 정보가 그림 속에 들어 있었다. 행사 일정과 장소가 예쁜 포스터 이미지 하나로 만들어져 있었던 거다. 보는 사람에게는 한눈에 들어오는 정보지만, 그 이미지에 대체 텍스트가 없었다. 스크린리더 사용자에게 그 페이지는 ‘이미지. 이미지.’만 반복되는 텅 빈 페이지였다. 정작 핵심 정보인 일정과 장소를 통째로 못 받은 거다.

‘텍스트를 이미지로 만드는 것’ 자체가 접근성의 큰 적이다. 글로 쓸 수 있는 정보를 그림으로 만들면, 스크린리더가 못 읽고, 글자 확대도 안 되고, 검색도 안 된다. 행사 일정 같은 정보는 그림이 아니라 글로 써야 한다. 디자인이 아쉽다면, 보기 좋은 그림은 따로 넣되 정보는 글로도 함께 제공하면 된다. 그리고 의미 없는 장식용 이미지에는 ‘대체 텍스트를 비워두는’ 처리를 한다. 그래야 스크린리더가 장식까지 일일이 읽느라 사용자를 지치게 하지 않는다. 핵심은 ‘정보가 있는 그림에는 설명을, 장식용 그림에는 빈 처리를’이다.

 

■ 키보드만으로 끝까지 갈 수 있는가

스크린리더 사용자 상당수는 마우스를 쓰지 않고 키보드로만 사이트를 이동한다. 탭 키를 눌러 다음 요소로, 엔터로 선택. 그래서 ‘키보드만으로 모든 기능을 쓸 수 있는가’가 접근성의 중요한 시험대다. A광역지자체의 한 신청 페이지를 키보드로만 진행해 본 적이 있다. 중간까지는 잘 갔는데, 마지막 ‘신청하기’ 버튼에 도무지 초점이 닿지 않았다. 그 버튼이 코드상 진짜 버튼이 아니라 ‘버튼처럼 꾸민 다른 요소’였기 때문이다. 마우스로는 눌리는데 키보드로는 닿지 않는 버튼. 키보드 사용자에게 그 신청은 ‘끝까지 갈 수 없는 길’이었다.

키보드 접근성은 사실 ‘직접 해보면’ 가장 빨리 이해된다. 지금 우리 사이트를 열어놓고 마우스에서 손을 떼보길 권한다. 탭 키만 눌러서 화면 위 요소들을 하나씩 옮겨 다녀 보는 거다. 잘 만든 사이트라면 탭을 누를 때마다 ‘논리적인 순서’로 초점이 이동하고, 지금 어디에 초점이 있는지 또렷하게 보인다. 못 만든 사이트는 금방 티가 난다. 탭을 눌러도 초점이 어디 갔는지 안 보이거나, 엉뚱한 순서로 튀거나, 어떤 요소는 아예 건너뛰어서 닿지 않는다. 특히 직접 만든 드롭다운 메뉴, 팝업창, 탭 전환 같은 ‘복잡한 요소’에서 막히는 일이 잦다. 이런 건 마우스로 쓸 때는 멀쩡하지만, 키보드로는 ‘열 수는 있는데 닫을 수가 없는’ 함정이 되기도 한다.

여기서 ‘키보드 함정(keyboard trap)’이라는 말도 알아두면 좋다. 어떤 요소에 초점이 들어갔는데 빠져나올 방법이 없는 상황이다. 예를 들어 팝업이 떴는데, 탭을 아무리 눌러도 초점이 팝업 안에서만 맴돌거나 반대로 팝업 밖으로 새어 나가 정작 ‘닫기’ 버튼에 못 닿는 경우. 마우스 사용자는 그냥 화면 아무 데나 눌러 닫지만, 키보드 사용자는 거기 갇힌다. 사이트를 처음부터 다시 여는 것 말고는 방법이 없다. 이런 함정은 직접 만든 인터랙티브 요소에서 자주 생긴다. 그래서 새로운 ‘움직이는 요소’를 만들 때는 반드시 ‘키보드로 열고, 쓰고, 닫는’ 전 과정을 확인해야 한다.

여기에 더해 ‘지금 어디에 초점이 있는지’를 보여주는 신호도 중요하다. 키보드로 이동할 때, 현재 선택된 요소에 테두리 같은 표시가 떠야 사용자가 자기 위치를 안다. 그런데 디자인을 ‘깔끔하게’ 한다고 이 초점 표시를 일부러 없애버린 사이트가 많다. 마우스 쓰는 사람에게는 없어도 되지만, 키보드 사용자에게는 이게 사라지면 ‘불 꺼진 방에서 더듬는’ 상황이 된다. 초점 표시는 미관을 위해 지워도 되는 장식이 아니라, 누군가에게는 길을 찾는 유일한 등불이다.

 

■ ‘읽는 순서’와 ‘말이 되는 이름’

스크린리더는 위에서 아래로 순서대로 읽는다고 했다. 그래서 ‘읽는 순서’가 논리적이어야 한다. 그런데 화면을 예쁘게 배치하느라 코드 순서가 뒤죽박죽이면, 스크린리더는 엉뚱한 순서로 읽는다. 본문을 읽다가 갑자기 광고 배너로 튀고, 다시 본문으로 돌아오는 식이다. 보는 사람에게는 배치가 멀쩡해도, 듣는 사람에게는 ‘이야기가 중간에 끊겨 딴 데로 새는’ 경험이 된다.

그리고 ‘이름’이다. 버튼이나 링크에 ‘여기 클릭’, ‘더보기’, ‘바로가기’처럼 모호한 이름만 붙어 있으면, 스크린리더 사용자는 그게 어디로 가는 무엇인지 알 수 없다. 화면을 보는 사람은 ‘더보기’ 옆 제목을 보고 맥락을 잡지만, 스크린리더로 링크만 쭉 훑는 사용자에게는 ‘더보기, 더보기, 더보기’만 줄줄이 들린다. 그래서 링크와 버튼에는 ‘무엇을 하는지가 그 자체로 드러나는 이름’을 붙여야 한다. ‘신청서 다운로드’, ‘민원 처리 현황 보기’처럼. 이름 하나가 누군가에게는 길 안내판이 된다.

스크린리더 사용자가 페이지를 ‘훑는’ 방식을 알면 이게 왜 중요한지 더 와닿는다. 화면을 못 보는 사용자는 페이지를 처음부터 끝까지 다 듣는 게 아니라, ‘링크만 모아 듣기’, ‘제목만 모아 듣기’ 같은 기능으로 빠르게 구조를 파악한다. 우리가 눈으로 페이지를 ‘쓱’ 훑어 원하는 곳으로 가듯, 그들은 제목과 링크 목록을 ‘쓱’ 듣고 원하는 곳으로 간다. 그런데 제목이 ‘제목’으로 표시돼 있지 않으면 ‘제목만 모아 듣기’가 작동을 안 하고, 링크 이름이 다 ‘더보기’면 ‘링크 목록’이 무의미해진다. 결국 그 사용자는 페이지를 처음부터 끝까지 한 줄씩 다 들어야 원하는 정보를 찾는다. 보는 사람에게는 3초면 될 일이 듣는 사람에게는 3분이 되는 거다. 좋은 제목 구조와 명확한 링크 이름은 그 ‘3분을 3초로’ 줄여주는 배려다.

여기에 더해 ‘건너뛰기 링크’라는 작은 장치도 큰 도움이 된다. 모든 페이지 맨 위에는 보통 로고, 메뉴, 검색창 같은 ‘공통 머리 부분’이 있다. 화면을 보는 사람은 이걸 그냥 시선으로 넘기지만, 키보드·스크린리더 사용자는 페이지를 옮길 때마다 이 머리 부분을 매번 다 거쳐야 본문에 닿는다. 페이지를 열 때마다 메뉴 수십 개를 듣고 나서야 본문이 시작되는 거다. 이걸 줄여주는 게 ‘본문 바로가기’ 같은 건너뛰기 링크다. 페이지 맨 처음에 ‘본문으로 건너뛰기’를 두면, 사용자가 한 번에 본문으로 점프할 수 있다. 보는 사람 눈에는 잘 안 띄지만, 매 페이지마다 메뉴를 다시 듣는 수고를 덜어주는 작은 친절이다.

 

【본론 4 — ‘안 보이는 사람’을 어떻게 발견하는가: 접근성 자동 검사】

■ 사람이 일일이 다 잡을 수 없다

지금까지 색대비, 자막, 스크린리더 세 영역을 봤다. 여기서 현실적인 고민이 든다. “이걸 다 어떻게 일일이 확인하죠?” 맞는 걱정이다. 페이지가 수십, 수백 개인 공공 사이트에서 모든 글자의 대비비를 손으로 재고, 모든 이미지에 대체 텍스트가 있는지 확인하고, 모든 버튼을 키보드로 눌러보는 건 사람 손으로는 사실상 불가능하다. 한두 페이지는 몰라도, 사이트 전체를 그렇게 점검하는 건 끝이 없다.

그래서 필요한 게 ‘접근성 자동 검사’다. 색대비 미달, 대체 텍스트 누락, 모호한 링크 이름, 잘못된 구조 같은 ‘기계가 잡을 수 있는 문제’는 자동으로 검사하는 거다. 사람은 자동 검사가 잡지 못하는 ‘맥락적 판단’(예: 대체 텍스트가 있긴 한데 내용이 적절한가)에 집중하고, 기계는 ‘있다/없다, 통과/미달’처럼 명확한 판정을 빠르게 끝낸다. 이렇게 역할을 나누면 수백 페이지짜리 사이트도 점검이 가능해진다. 접근성은 ‘열심히 신경 쓰는 일’이 아니라 ‘체계적으로 검사하는 일’이 돼야 지속된다.

여기서 한 가지 강조하고 싶은 게 있다. 자동 검사는 ‘모든 걸’ 잡아주지 못한다. 색대비 미달은 100% 정확히 잡지만, ‘이 자막 내용이 영상과 맞는가’ 같은 건 기계가 판단 못 한다. 그래서 ‘자동 검사만 통과하면 접근성 완료’라고 생각하면 안 된다. 자동 검사는 ‘기계가 확실히 잡을 수 있는 부분을 빠짐없이, 반복적으로’ 걸러주는 도구다. 그 위에 사람의 판단을 얹어야 진짜 접근성이 완성된다. 자동 검사는 출발점이자 토대이지 결승선이 아니다.

그래도 자동 검사가 잡아주는 영역이 생각보다 넓다. 색대비 미달은 글자색과 배경색을 읽어 수식으로 계산하면 되니 정확하게 잡힌다. 대체 텍스트가 ‘있는지 없는지’는 코드를 보면 바로 안다. 이미지에 설명이 비어 있는 곳, 링크 이름이 비어 있는 곳, 입력칸에 라벨이 안 붙은 곳, 제목 구조가 뒤죽박죽인 곳, 문서의 언어 설정이 빠진 곳 — 이런 ‘구조적인 빠짐’은 기계가 한눈에 골라낸다. 사람이 수백 페이지를 일일이 보며 “여기 대체 텍스트 빠졌네”를 찾는 건 끔찍하게 지치는 일이지만, 기계는 같은 일을 몇 초 만에, 몇 번을 반복해도 지치지 않고 한다. 사람의 시간은 ‘기계가 못 잡는 판단’에 써야 한다. 자동 검사는 사람의 시간을 아껴서 더 중요한 데 쓰게 해주는 도구인 셈이다.

그리고 자동 검사의 진짜 가치는 ‘반복’에 있다. 접근성은 한 번 점검하고 끝나는 게 아니라 계속 유지해야 하는 거라고 했다. 콘텐츠가 새로 올라올 때마다, 페이지가 추가될 때마다 다시 점검해야 하는데, 그걸 매번 사람이 하긴 어렵다. 자동 검사는 정기적으로 돌려도 비용이 거의 들지 않으니, ‘매주 사이트 전체를 점검한다’ 같은 게 현실적으로 가능해진다. 사람이 분기에 한 번 큰 점검을 한다면, 그 사이의 빈틈을 자동 검사가 메우는 식이다. ‘가끔 크게 점검’과 ‘자주 가볍게 점검’이 합쳐지면, 접근성이 무너지기 전에 잡아낼 수 있다. 무너진 다음에 고치는 것보다 무너지기 전에 막는 게 언제나 싸다.

 

■ KWCAG 33항목과 7대 영역 속의 접근성

한국의 웹 접근성 기준은 KWCAG(한국형 웹 콘텐츠 접근성 지침)로 정리돼 있다. 큰 원칙은 네 가지다. 첫째, 인식의 용이성 — 모든 정보는 ‘인식할 수 있게’ 제공돼야 한다. 색대비, 대체 텍스트, 자막이 다 여기 들어간다. 둘째, 운용의 용이성 — 키보드만으로도 ‘조작할 수 있게’ 해야 한다. 셋째, 이해의 용이성 — 콘텐츠를 ‘이해할 수 있게’ 명확히 해야 한다. 넷째, 견고성 — 다양한 기술과 보조기기에서 ‘튼튼하게’ 동작해야 한다. 이 네 원칙 아래 세부 검사 항목들이 펼쳐지는데, 그게 KWCAG 33항목이다.

이 접근성은 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성) 중 ‘접근성’ 영역의 핵심을 이룬다. 공공 사이트는 이 7대 영역을 두루 충족해야 ‘품질 좋은 사이트’로 인정받는데, 그중에서도 접근성은 ‘모두가 쓸 수 있는가’라는 공공성의 본질과 가장 직결된 영역이다. 호환성이나 효율성이 ‘잘 돌아가는가’의 문제라면, 접근성은 ‘누구도 빠뜨리지 않는가’의 문제다. 공공 서비스의 정신에 가장 가까운 영역인 셈이다.

KRDS 846개 규칙도 이 접근성과 촘촘히 맞물려 있다. KRDS는 DS(디자인 스타일) 120개, CP(컴포넌트) 446개, BP(기본 패턴) 108개, SP(서비스 패턴) 172개로 이루어지는데, 오늘 다룬 색대비는 DS 영역의 색 기준과, 버튼·링크의 키보드 접근성은 CP·BP 영역과, 신청 흐름 전체의 접근성은 SP 영역과 연결된다. 접근성은 따로 떨어진 별개 항목이 아니라, 디자인 시스템 전체에 ‘실처럼 꿰어져 있는 가치’다. 그래서 KRDS를 잘 지키면 접근성도 상당 부분 자동으로 따라오고, 반대로 접근성을 고민하면 KRDS의 많은 규칙이 자연스럽게 채워진다.

이 ‘맞물려 있다’는 게 실무에서 왜 중요하냐면, 접근성과 디자인 표준을 ‘따로따로’ 챙기면 일이 두 배가 되기 때문이다. 디자인 가이드 한 번 만들고, 접근성 점검 또 따로 하고, 둘이 어긋나면 다시 맞추고. 이렇게 분리하면 비효율적일 뿐 아니라 ‘디자인 따로, 접근성 따로’ 노는 사이트가 나오기 쉽다. 반면 KRDS처럼 ‘처음부터 접근성을 품은 표준’을 쓰면, 표준을 따르는 것만으로 색대비·키보드 접근성·구조의 상당 부분이 한꺼번에 챙겨진다. 색을 표준 팔레트에서 고르면 대비가 자동으로 맞고, 버튼을 표준 컴포넌트로 만들면 키보드 접근성이 기본 탑재되는 식이다. 접근성을 ‘추가로 하는 일’이 아니라 ‘표준을 따르면 따라오는 결과’로 만드는 것 — 그게 가장 지속 가능한 접근성 전략이다.

물론 표준을 따른다고 접근성이 100% 보장되는 건 아니다. 표준은 ‘부품’을 보장할 뿐, 그 부품을 ‘어떻게 조립하고 어떤 내용을 채우는가’는 여전히 사람의 몫이다. 표준 버튼을 썼어도 그 버튼에 ‘여기 클릭’이라는 모호한 이름을 붙이면 접근성이 깨지고, 표준 이미지 컴포넌트를 썼어도 대체 텍스트를 안 적으면 의미가 없다. 그래서 ‘표준 + 점검’이 함께 가야 한다. 표준이 80%를 받쳐주고, 점검이 나머지 20%의 빈틈을 메우는 구조. 오늘 글의 결론이 ‘자동 검사 + 사람 판단’으로 모이는 것도 같은 맥락이다.

 

【본론 5 — 현장에서 자주 보는 ‘접근성 오해’ 정리】

■ 오해 1: “우리 사이트는 장애인이 잘 안 들어와요”

가장 흔하고 가장 위험한 오해다. 첫째, 들어오는 사람 수를 ‘정확히’ 알 방법이 없다. 안 보여서 못 쓰고 떠난 사람은 통계에 ‘방문’으로조차 안 잡힌다. ‘장애인이 안 온다’가 아니라 ‘장애인이 못 들어와서 안 보이는 것’일 수 있다. 통계에 ‘안 온다’고 찍힌 게 사실은 ‘못 들어와서 안 보이는 것’일 수 있다는 이 역설을, 담당자는 늘 의심해야 한다. 둘째, 접근성의 수혜자는 장애인만이 아니다. 앞에서 봤듯 노안, 야외, 음소거, 외국인 등 ‘일시적·상황적 제약’을 가진 다수가 접근성의 덕을 본다. ‘소수를 위한 비용’이 아니라 ‘다수를 위한 기본’으로 봐야 한다. 셋째, 제약은 누구에게나 ‘일시적으로’ 찾아온다. 팔을 다쳐 한 손만 쓸 때, 안약을 넣어 눈이 흐릿할 때, 시끄러운 곳에 있을 때 — 멀쩡한 사람도 잠시 ‘제약 있는 사용자’가 된다. 그러니 접근성은 ‘다른 누군가’가 아니라 ‘언젠가의 우리 모두’를 위한 것이다.

 

■ 오해 2: “접근성 챙기면 디자인이 촌스러워진다”

이것도 흔한 걱정인데, 사실과 다르다. 색대비를 지키면서도 충분히 세련될 수 있다. 연한 회색 대신 적당히 진한 회색을 쓰면 ‘차분하면서도 읽히는’ 디자인이 된다. 자막은 영상 위에 깔끔하게 얹을 수 있고, 대체 텍스트는 사용자 눈에 보이지도 않으니 디자인을 해치지 않는다. 초점 표시도 브랜드 색에 맞춰 예쁘게 만들 수 있다. 접근성과 미감은 대립하는 게 아니다. 오히려 ‘제약 안에서 좋은 답을 찾는 것’이 디자인의 본질이다. 진짜 좋은 디자인은 ‘예쁘면서 모두에게 쓰이는’ 디자인이다. 한쪽을 위해 다른 쪽을 포기해야 한다는 생각 자체가 낡은 거다. 실제로 세계적으로 인정받는 잘 만든 서비스들은 거의 예외 없이 접근성이 탄탄하다. ‘예쁘기만 하고 못 쓰는’ 디자인은 결국 ‘덜 좋은 디자인’일 뿐이다. 모두가 편히 쓰는 화면이 사실은 가장 세련된 화면이라는 걸, 좋은 디자이너일수록 안다.

 

■ 오해 3: “한 번 잘 만들면 접근성은 끝난다”

접근성은 ‘완료’되는 게 아니라 ‘유지’되는 거다. 처음 만들 때 완벽했어도, 운영하면서 새 페이지가 붙고 콘텐츠가 쌓이면 접근성은 다시 무너진다. 마치 청소와 같다. 한 번 대청소를 했다고 영원히 깨끗한 집이 되는 게 아니듯, 한 번 점검했다고 영원히 접근성 좋은 사이트가 되는 건 아니다. 담당자가 무심코 올린 포스터 이미지에 대체 텍스트가 빠지고, 새로 추가한 영상에 자막이 없고, 외부에서 가져온 위젯이 색대비를 깨뜨린다. 그래서 접근성은 ‘한 번의 작업’이 아니라 ‘계속 돌아가는 점검 습관’이어야 한다. 새 콘텐츠를 올릴 때마다, 정기적으로 사이트를 다시 검사하면서 접근성이 유지되는지 확인하는 것 — 이게 진짜 접근성 관리다. 자동 검사가 빛을 발하는 지점이 바로 여기다. 사람이 매번 전수 점검하긴 어렵지만, 자동 검사는 정기적으로 반복해도 지치지 않는다.

 

■ 오해 4: “접근성은 개발자가 알아서 하는 거다”

접근성을 기술 문제로만 보는 시각인데, 절반만 맞다. 대체 텍스트의 ‘내용’을 정하는 건 콘텐츠 담당자고, 색을 고르는 건 디자이너고, 자막을 검수하는 건 운영자다. 개발자가 구조를 잘 잡는 것도 중요하지만, 접근성은 기획·디자인·콘텐츠·개발이 모두 조금씩 책임을 나눠야 지켜진다. ‘누구 하나의 일’로 떠넘기면 반드시 구멍이 생긴다. 접근성은 사이트를 만지는 모든 사람의 공동 책임이다. 거꾸로 말하면, 각자 자기 자리에서 작은 습관 하나씩만 더하면 큰 부담 없이 지켜지는 것이기도 하다.

각자의 ‘작은 습관’을 구체적으로 그려보자. 콘텐츠 담당자는 이미지를 올릴 때 ‘이 그림이 뭘 담고 있지’를 한 줄로 적는 습관을 들이면 된다. 영상을 올릴 때 자막을 함께 챙기고, 자동 자막이라면 숫자·이름이 맞는지 한 번 보는 것. 디자이너는 색을 고를 때 ‘이 조합이 대비 기준을 넘나’를 확인하고, 정보는 색에만 싣지 않으며, 초점 표시를 지우지 않는 것. 개발자는 버튼을 진짜 버튼으로 만들고, 제목·목록 같은 구조를 의미에 맞게 짜고, 키보드로 끝까지 갈 수 있게 만드는 것. 기획자는 처음부터 ‘이 기능을 키보드로도 쓸 수 있나’, ‘소리로만 전달되는 정보는 없나’를 요구사항에 넣는 것. 이렇게 각자 자기 일에 ‘접근성 한 줄’씩만 더하면, 누구도 큰 부담을 지지 않으면서 사이트 전체가 접근성을 갖춘다. 문제는 한 사람에게 다 떠넘길 때 생긴다. 개발자에게 “접근성 알아서 해주세요” 하면, 정작 디자인 단계에서 깨진 대비나 콘텐츠 단계에서 빠진 대체 텍스트는 개발자가 손쓸 수 없다.

 

【본론 6 — 그래서 무엇부터 할 것인가: 작은 실천 목록】

말로만 ‘접근성 중요하다’고 하면 막막하다. 그래서 오늘부터 바로 해볼 수 있는 작은 것들을 정리해 본다. 거창한 개편이 아니라, 지금 우리 사이트에서 당장 확인할 수 있는 항목들이다. 한꺼번에 다 하려 하지 말고, 하나씩 짚어가며 ‘우리 사이트는 어떤가’를 확인하는 마음으로 읽으면 된다.

첫째, 가장 중요한 정보의 글자색부터 확인하자. 마감일, 유의사항, 신청 자격 같은 ‘놓치면 안 되는 정보’가 연한 회색으로 깔려 있지 않은지 본다. 보조 정보를 흐리게 처리하는 디자인은 흔하지만, ‘진짜 중요한 정보’만큼은 또렷한 색으로 보장해야 한다.

둘째, 색‘만’으로 구분하는 곳이 있는지 찾자. 상태 표시, 그래프, 안내가 색 차이에만 기대고 있다면, 모양이나 글자를 하나 더 얹는다. 작은 변화지만 색을 못 보는 사용자에게는 ‘정보를 받느냐 못 받느냐’의 차이가 된다.

셋째, 영상에 자막이 있는지, 자막 내용이 정확한지 본다. 자동 자막을 켰다면 숫자·고유명사·날짜 위주로 한 번 검수한다. 새로 올리는 영상은 처음부터 자막을 챙긴다.

넷째, 이미지에 대체 텍스트가 있는지, 특히 ‘정보가 담긴 이미지’가 있는지 확인한다. 행사 일정처럼 글로 쓸 수 있는 정보가 이미지로만 돼 있으면, 글로도 함께 제공한다.

다섯째, 마우스를 떼고 키보드(탭·엔터)만으로 신청 같은 핵심 흐름을 끝까지 가본다. 중간에 막히는 데가 있으면 그게 누군가에게는 ‘넘을 수 없는 벽’이다. 초점 표시가 보이는지도 함께 확인한다.

여기에 하나 더 보태자면, 화면을 200% 정도로 확대해 보는 것도 좋은 점검이다. 글자를 크게 키워야 읽을 수 있는 사용자가 많은데, 확대했을 때 글자끼리 겹치거나, 내용이 화면 밖으로 잘려 나가거나, 가로 스크롤이 생겨 읽기 불편해지는 사이트가 적지 않다. 확대해도 내용이 깨지지 않고 잘 흐르는지 — 이건 ‘글자를 키워야 보이는’ 사용자에게 결정적이다. 브라우저 확대 한 번이면 금방 확인된다.

이 여섯 가지를 한 번씩만 해봐도, ‘안 보인다’는 민원의 상당수가 어디서 오는지 감이 잡힌다. 그리고 한 가지 깨닫게 된다 — 이걸 매번 사람 손으로 전수 점검하는 건 너무 고되다는 것. 그래서 ‘자동 검사 + 사람 판단’의 조합이 필요한 거다. 기계가 명확한 미달을 빠짐없이 골라주고, 사람은 그 위에서 맥락을 챙기는 분업. 이게 지속 가능한 접근성 관리의 핵심이다. 처음 점검하면 미달 항목이 생각보다 많이 나와 당황할 수도 있다. 하지만 그건 ‘우리 사이트가 유독 나빠서’가 아니라 ‘대부분의 사이트가 그렇기’ 때문이다. 중요한 건 시작하는 거다. 한 번 점검해서 미달을 눈으로 확인하는 순간, 그 다음부터는 새 페이지를 만들 때 자연스럽게 챙기게 된다.

마지막으로, 접근성을 ‘부담’이 아니라 ‘기본기’로 받아들이자고 권하고 싶다. 처음엔 신경 쓸 게 많아 보이지만, 한번 습관이 되면 새 페이지를 만들 때 자연스럽게 챙기게 된다. 그리고 그 습관이 쌓인 사이트는, 어떤 사용자가 어떤 환경에서 들어와도 ‘안 보여서’, ‘안 들려서’, ‘못 눌러서’ 돌아서는 일이 없는 사이트가 된다. 그게 공공 서비스가 도달해야 할 모습이고, 사실 그렇게 만든 사이트는 비장애인에게도 더 편하고 더 또렷한 사이트다. 접근성은 누군가를 위한 ‘특별 대우’가 아니라, 모두를 위한 ‘좋은 기본’이다.

【 마무리 】

오늘 우리는 ‘안 보인다’는 민원 한 줄에서 출발해 꽤 멀리 왔다. 연한 회색 글씨가 왜 누군가에게는 ‘빈 화면’이 되는지, 색대비를 왜 눈대중이 아니라 수치로 재야 하는지, 색에만 기댄 정보가 왜 누군가를 통째로 배제하는지 봤다. 자막이 청각장애인만이 아니라 ‘지금 들을 수 없는 모든 상황’을 위한 것임을, 스크린리더 사용자에게는 ‘보이는 화면’이 아니라 ‘코드가 말하는 화면’이 전부임을 봤다. 그리고 이 모든 걸 사람 손으로 다 잡기 어렵기에 ‘접근성 자동 검사’가 필요하다는 데까지 왔다.

핵심을 한 줄로 줄이면 이렇다 — 접근성은 소수를 위한 배려가 아니라 ‘아무도 빠뜨리지 않는 기본’이다. 그리고 그 기본은 ‘느낌’이 아니라 ‘점검’으로 지켜진다. 우리 눈에 잘 보인다고 모두에게 보이는 게 아니고, 우리에게 잘 들린다고 모두에게 들리는 게 아니다. 그래서 ‘내 눈, 내 귀’가 아니라 ‘기준과 측정’으로 확인해야 한다. 그게 공공 서비스가 ‘모두의 서비스’가 되는 길이다.

처음에 던졌던 질문으로 돌아가 보자. “글씨가 안 보여요”라는 민원. 이제 우리는 안다. 그건 그 사람의 눈이 나빠서가 아니라, 우리 사이트의 글씨가 ‘어떤 환경에서는 안 보이게’ 만들어져 있어서일 가능성이 높다는 것을. 그리고 그 민원 한 건 뒤에는, 말없이 떠난 훨씬 많은 사람이 있다는 것도. 민원을 ‘처리해야 할 불만’으로만 보면 한 건 한 건 응대하다 끝나지만, ‘신호’로 보면 사이트를 근본적으로 바꿀 단서가 된다. ‘안 보인다’는 한마디를 가볍게 넘기지 않는 것 — 거기서 접근성이 시작된다.

그런데 막상 ‘우리 사이트 접근성이 지금 어떤 상태인지’ 알려면 어디서부터 봐야 할지 막막할 거다. 색대비 하나하나 재고, 이미지마다 대체 텍스트 확인하고, 키보드로 전 페이지를 돌아보는 건 현실적으로 벅차다. 그래서 ViewCheck를 권한다. ViewCheck는 공공 웹사이트의 KRDS 846규칙 준수 여부와 함께, 웹 접근성(KWCAG 33항목)을 자동으로 진단해 준다. 색대비 미달, 대체 텍스트 누락, 키보드 접근성, 자막 관련 항목 같은 ‘기계가 확실히 잡을 수 있는 문제’를 빠짐없이 걸러서, 어느 페이지의 무엇이 기준에 못 미치는지 한눈에 보여준다. 위에서 본 캡쳐 화면처럼, 웹 접근성 분석 탭에서 우리 사이트의 접근성 점수와 미달 항목을 바로 확인할 수 있다.

진단은 시작일 뿐이지만, 그 시작이 없으면 아무것도 바뀌지 않는다. 우리 사이트의 ‘안 보이는 구석’을 한 번이라도 눈으로 확인한 담당자와, 한 번도 본 적 없는 담당자 사이에는 큰 차이가 생긴다. 보고 나면 더 이상 모른 척할 수 없기 때문이다. 그 ‘보는 일’을 ViewCheck가 빠르고 정확하게 도와준다.

다음 주에는 접근성의 또 다른 축인 ‘모바일·확대·반응형’ 환경에서의 접근성을 다뤄볼 생각이다. 화면을 키웠을 때 깨지는 레이아웃, 가로로 눕혔을 때 사라지는 버튼, 손가락으로 누르기엔 너무 작은 영역 — ‘안 보인다’의 또 다른 얼굴들이다. 오늘 색대비·자막·스크린리더가 ‘인식’의 문제였다면, 다음 주는 ‘조작’의 문제로 넘어간다. 우리 사이트가 누구에게도 ‘넘을 수 없는 벽’을 세우지 않도록, 함께 하나씩 점검해 가자.

 

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #색대비 #자막 #스크린리더 #대체텍스트 #전자정부품질관리 #접근성자동검사 #공공서비스 #ViewCheck