색 대비·자막·스크린리더 점검표

색 대비·자막·스크린리더 점검표

반응형

【 공감·문제제기 】

이번 주 월요일엔 웹 접근성이 왜 ‘선택이 아니라 의무’인지, 수요일엔 키보드만으로 사이트를 끝까지 돌아다닐 수 있는지를 다뤘다. 오늘은 그중에서도 담당자들이 가장 자주 놓치고, 동시에 가장 빨리 고칠 수 있는 세 가지를 깊게 파보려 한다. 색 대비, 자막, 그리고 스크린리더. 이 셋은 ‘눈에 잘 안 보이는 접근성’의 대표 선수들이다. 마우스로 슬쩍 둘러보면 멀쩡해 보이지만, 막상 시력이 약한 사용자나 소리를 못 듣는 사용자, 화면을 못 보는 사용자의 자리에 앉아보면 그제야 균열이 드러난다.

솔직히 고백하자면, 나도 처음 이 일을 시작했을 때는 ‘색 대비’라는 말을 그냥 흘려들었다. ‘글자 색이 좀 연하면 어때, 보이면 됐지’ 싶었다. 그런데 어느 날 햇빛 쨍한 야외에서 스마트폰으로 한 공공 사이트를 열어보다가 깨달았다. 연회색 글씨에 흰 배경. 화면을 손으로 가려가며 각도를 이리저리 틀어봐도 글자가 도무지 안 읽혔다. 실내 모니터에선 멀쩡하던 그 글자가, 바깥 빛 아래에선 거의 사라져 있었다. 그때 알았다. 색 대비는 ‘디자인 취향’의 문제가 아니라 ‘읽을 수 있느냐 없느냐’의 문제라는 걸. 그리고 시력이 멀쩡한 나조차 못 읽었다면, 노안이 온 어르신이나 저시력 사용자에게 그 페이지는 ‘없는 페이지’나 마찬가지라는 걸.

오늘 글은 정밀한 이론서가 아니다. ‘우리 사이트의 색 대비·자막·스크린리더가 지금 어떤 상태인지’를 담당자가 직접, 그것도 특별한 도구 없이 자기 눈과 귀로 가늠해보게 만드는 실무 점검표다. 물론 끝에는 도구 이야기도 나온다. 사람의 눈으로 거칠게 훑은 뒤, 정밀한 확인은 자동 검사에 맡기는 게 가장 효율적이기 때문이다. 하지만 도구를 돌리기 전에 ‘무엇을 보는 것인지’를 알아야 결과지의 숫자가 의미를 가진다. 그래서 오늘은 그 ‘무엇’을 먼저 익히는 데 집중한다.

미리 분명히 해두자. 이 점검표는 웹 접근성의 모든 항목을 다 따지는 종합 진단이 아니다. 우리나라 웹 접근성 지침인 KWCAG는 33개 항목으로 이뤄져 있고, 그 안에는 오늘 다루는 세 주제 말고도 수많은 항목이 있다. 다만 색 대비·자막·스크린리더 이 셋은 ‘위반이 가장 흔하고, 영향받는 사용자가 가장 많고, 고치는 방법은 비교적 명확한’ 항목들이라, 접근성 개선의 첫 단추로 삼기에 가장 좋다. 첫 단추부터 잘 끼우면, 그다음 단추들은 한결 수월하게 따라온다.

준비물은 단출하다. 우리 기관 사이트, 데스크탑, 그리고 스마트폰 하나. 가능하면 화면을 읽어주는 ‘스크린리더’ 기능을 한 번이라도 켜볼 마음의 준비. 그게 전부다. 펜과 종이(혹은 메모 앱)를 옆에 두고 ‘예/아니오’를 적어가며 따라오면 된다. 그리고 한 가지 마음가짐. 이건 ‘우리 사이트를 흠잡는 일’이 아니라 ‘아직 우리 사이트를 제대로 못 쓰고 있던 누군가를 위해, 문을 조금 더 넓게 여는 일’이다. 그렇게 생각하면 ‘아니오’가 나올 때마다 부끄럽기보다 반갑다. 고칠 거리를 하나 찾았다는 뜻이니까.

한 가지 더 미리 일러둘 게 있다. 오늘 다루는 세 주제는 ‘서로 다른 사용자’를 위한 것 같지만, 실은 깊이 얽혀 있다. 색 대비는 ‘잘 안 보이는’ 사용자를, 자막은 ‘잘 안 들리는’ 사용자를, 스크린리더는 ‘아예 못 보는’ 사용자를 향한다. 그런데 현실의 사용자는 이렇게 칼로 나뉘지 않는다. 한 사람이 동시에 여러 어려움을 겪기도 하고, 같은 사람이 상황에 따라 다른 어려움에 놓이기도 한다. 평소엔 멀쩡히 보던 사람도 햇빛 아래선 저시력 사용자처럼 되고, 회의 중엔 소리를 못 켜 청각장애 사용자처럼 자막에 의지하며, 운전 중엔 화면을 못 보니 스크린리더처럼 ‘듣기’에 기댄다. 즉 접근성은 ‘특별한 소수’가 아니라 ‘특정 상황의 모두’를 위한 것이기도 하다. 이걸 ‘상황적 장애’라고 부른다. 오늘 점검표를 ‘남을 위한 배려’로만 여기지 말고 ‘언젠가의 나를 위한 준비’로도 받아들이면, 점검에 임하는 마음이 한결 가까워진다.

자, 그럼 색부터 시작하자.

 

【본론】

■ 1. 색 대비, 왜 ‘취향’이 아니라 ‘기준’인가

색 대비라는 말이 어렵게 들릴 수 있는데, 핵심은 단순하다. ‘글자 색과 배경 색이 얼마나 또렷이 구분되는가’다. 검은 글씨에 흰 배경은 대비가 강하다. 연회색 글씨에 흰 배경은 대비가 약하다. 대비가 약할수록 글자는 흐릿하게 ‘번져’ 보이고, 시력이 약한 사람일수록 그 번짐은 ‘안 보임’으로 넘어간다.

웹 접근성 지침은 이 대비를 ‘느낌’이 아니라 ‘숫자’로 따진다. 글자 색과 배경 색의 밝기 차이를 비율로 환산해서, 일반 본문 크기 글자는 그 비율이 최소 4.5대 1 이상이어야 한다고 본다. 제목처럼 크고 굵은 글자는 조금 너그러워서 3대 1 이상이면 통과로 본다. 이 숫자를 외울 필요는 없다. 다만 ‘우리가 눈으로 멀쩡하다고 느끼는 것과, 기준이 요구하는 또렷함 사이엔 꽤 큰 간격이 있다’는 사실만 기억하면 된다. 우리 눈은 ‘읽으려고 애쓰면 읽히는’ 정도를 ‘괜찮다’고 착각한다. 하지만 접근성 기준은 ‘애쓰지 않아도 편히 읽히는’ 수준을 요구한다.

왜 ‘비율’로 따질까. 이게 흥미로운 지점이다. 사람의 눈은 색의 ‘이름’이 아니라 ‘밝기 차이’로 글자를 읽는다. 같은 ‘파랑’이라도 아주 밝은 파랑이냐 짙은 파랑이냐에 따라 흰 배경과의 대비가 천차만별이다. 그래서 ‘무슨 색이냐’가 아니라 ‘얼마나 밝고 어두운 차이가 나느냐’가 읽힘을 좌우한다. 이 때문에 ‘예쁜 색을 골랐는데 왜 안 읽히지’ 하는 일이 생긴다. 색 자체는 고왔지만 배경과의 밝기 차이가 작았던 것이다. 거꾸로, 화려하지 않아도 밝기 차이만 충분하면 또렷이 읽힌다. 그래서 색을 고를 땐 ‘이 색이 예쁜가’와 ‘이 색이 배경과 충분히 밝기 차이가 나는가’를 따로 따져야 한다. 두 질문은 전혀 다른 질문이고, 접근성은 후자를 본다.

흥미롭게도 이 ‘비율’ 기준은 사람이 눈대중으로는 거의 못 맞춘다. 4.5대 1과 4.0대 1은 숫자로는 가깝지만, 경계선 근처의 색들은 눈으로 ‘이게 통과인지 미달인지’ 가늠하기가 사실상 불가능하다. 바로 이 지점이 ‘사람의 점검’과 ‘도구의 점검’이 갈라지는 곳이다. 사람은 ‘확실히 흐린 것’과 ‘확실히 또렷한 것’은 잘 가려내지만, ‘아슬아슬한 경계선’은 도구가 숫자로 재줘야 정확히 안다. 그래서 색 대비야말로 ‘사람 점검으로 감 잡고, 도구로 확정하기’가 가장 잘 들어맞는 영역이다.

왜 이렇게까지 엄격할까. 세 가지 이유가 겹친다. 첫째, 사람의 시력은 제각각이다. 같은 화면을 봐도 20대의 눈과 70대의 눈은 전혀 다르게 받아들인다. 노안이 오면 또렷함을 인지하는 능력이 떨어져서, 젊은 눈엔 ‘충분히 진한’ 회색이 어르신 눈엔 ‘흐릿한 안개’가 된다. 둘째, 화면 환경이 제각각이다. 같은 색이라도 고급 모니터에선 또렷하지만 오래된 저가 모니터나 햇빛 아래 스마트폰에선 뭉개진다. 셋째, 색을 다르게 보는 사람들이 있다. 흔히 ‘색약’이라 부르는, 특정 색 조합을 구분하기 어려운 사람들 말이다. 남성 스무 명 중 한 명꼴로 이런 특성을 갖고 있다는 통계도 있다. 빨강과 초록으로만 ‘성공/실패’를 표시하면, 이들에겐 둘이 비슷한 색으로 보여 구분이 안 된다.

그래서 색 대비 기준은 ‘까다로운 디자이너의 고집’이 아니라 ‘가장 약한 조건의 사용자도 읽을 수 있게 하는 안전 마진’이다. 가장 약한 조건을 통과하면, 그 위의 모든 조건은 자동으로 통과한다. 어르신도 읽히면 청년은 당연히 읽히고, 햇빛 아래서도 읽히면 실내에선 당연히 편하다. 접근성은 이렇게 ‘바닥을 높이는’ 일이고, 바닥을 높이면 천장에 있던 사람도 더 편해진다.

여기서 흔히 나오는 오해 하나를 짚자. “우리 사이트는 젊은 사람들이 주로 쓰니까 색 대비는 좀 양보해도 되지 않나요?” 공공 사이트엔 이 논리가 통하지 않는다. 공공 서비스는 ‘특정 연령대’를 위한 게 아니라 ‘모든 국민’을 위한 것이기 때문이다. 민원을 신청하고, 복지 혜택을 확인하고, 재난 정보를 받는 일은 나이·시력·환경을 가리지 않는다. 오히려 디지털에 덜 익숙하고 시력이 약한 사용자일수록 그 서비스가 더 절실한 경우가 많다. 색 대비를 양보한다는 건, 바로 그 절실한 사용자에게 ‘당신은 잘 안 보여도 됩니다’라고 말하는 것과 같다.

색 대비를 둘러싼 또 다른 흔한 착각은 ‘배경이 흰색이면 안전하다’는 믿음이다. 흰 배경 자체는 좋은 출발점이지만, 그 위에 어떤 글자를 얹느냐가 관건이다. 흰 바탕에 연회색 글씨는 ‘깔끔해 보여서’ 디자이너들이 즐겨 쓰는 조합인데, 바로 그 조합이 대비 미달의 단골이다. 보조 설명, 날짜 표기, 작은 안내문, 입력칸 아래 도움말 같은 ‘덜 중요해 보이는’ 텍스트일수록 색을 흐리게 빼는 경향이 있다. 그런데 정작 그 ‘덜 중요해 보이는’ 글자가 사용자에겐 ‘꼭 필요한 안내’인 경우가 많다. 신청 마감일, 제출 서류 목록, 수수료 안내 같은 정보가 흐린 회색으로 묻혀 있으면, 시력이 약한 사용자는 가장 중요한 정보를 가장 놓치기 쉬운 형태로 마주하게 된다. 그래서 색 대비를 점검할 때는 ‘크고 진한 제목’이 아니라 ‘작고 흐린 보조 텍스트’부터 의심해야 한다. 큰 글자는 웬만하면 통과하지만, 작은 글자는 같은 색이라도 더 또렷해야 읽히기 때문이다.

한 가지 더 짚을 게 있다. 색 대비는 ‘글자와 배경’ 사이만의 문제가 아니다. 버튼의 테두리, 입력칸의 경계선, 그래프의 색 구분, 표의 줄 구분선 같은 ‘선과 면’의 대비도 똑같이 중요하다. 입력칸 경계가 너무 흐리면 ‘여기가 칸인지’조차 분간이 안 되고, 그래프의 막대들이 비슷한 색이면 어느 게 어느 항목인지 헷갈린다. 특히 공공 사이트엔 통계·예산·현황을 보여주는 표와 그래프가 많은데, 이 시각 자료들이 ‘색만으로’ 항목을 구분하면 색약 사용자에겐 무용지물이 된다. 그래프를 그릴 땐 색에 더해 무늬(빗금·점)나 직접 라벨을 붙여, ‘색을 못 봐도 구분되게’ 만드는 게 원칙이다. 정보를 전달하는 모든 시각 요소는 색 대비의 점검 대상이라고 보면 된다.

■ 2. 색 대비, 5분 자가 점검표

이론은 이쯤 하고, 직접 우리 사이트를 봐보자. 아래 항목에 ‘예/아니오’로 답해보라.

[색 대비 점검표]

가-1. 본문 글자가 배경과 또렷이 구분되는가? 멀찍이 떨어져서 봐도 ‘번짐’ 없이 읽히는가?

→ 자주 보이는 문제: 연회색 안내문, 흐린 보조 설명, 옅은 푸른 링크. ‘있어 보이려고’ 색을 흐리게 뺀 텍스트가 가장 많이 걸린다.

가-2. 중요한 정보를 ‘색만으로’ 구분하고 있지는 않은가?

→ 자주 보이는 문제: ‘필수 항목은 빨간색’ ‘완료는 초록, 미완료는 빨강’처럼 색 하나에만 의존. 색약 사용자에겐 구분이 안 된다. 색에 더해 별표·아이콘·글자(‘필수’) 같은 ‘두 번째 단서’가 함께 있어야 한다.

가-3. 버튼 글자와 버튼 배경의 대비가 충분한가?

→ 자주 보이는 문제: 연한 파랑 배경에 흰 글씨, 또는 옅은 회색 배경에 회색 글씨. ‘세련돼 보이려다’ 정작 글자가 안 읽힌다.

가-4. 링크가 ‘색만으로’ 구분되지 않고 밑줄 같은 추가 표시가 있는가?

→ 자주 보이는 문제: 본문과 링크가 색만 살짝 다르고 밑줄이 없어, 색약 사용자나 흑백 인쇄 시 어디가 링크인지 모른다.

가-5. 햇빛 아래 스마트폰에서, 화면 밝기를 중간으로 두고도 본문이 읽히는가?

→ 자주 보이는 문제: 실내 모니터 기준으로만 색을 정해, 야외·모바일에서 무너진다.

이 다섯 항목을 점검할 때 한 가지 더 봐야 할 게 있다. ‘초점이 맞은 상태’와 ‘마우스를 올린 상태’의 색 대비다. 버튼이나 링크에 마우스를 올리거나 키보드로 초점을 맞췄을 때, 그 색이 바뀌면서 오히려 대비가 더 나빠지는 경우가 있다. 예를 들어 평소엔 진한 파랑 버튼인데, 마우스를 올리면 연한 하늘색으로 바뀌면서 흰 글자가 안 읽히게 되는 식이다. 평상 상태만 점검하고 ‘상호작용 상태’는 빼먹기 쉬운데, 사용자는 바로 그 ‘누르려는 순간’에 글자를 읽어야 하니, 상호작용 상태의 대비야말로 놓치면 안 된다. 점검할 때 버튼에 마우스를 올려보고, 키보드로 초점을 옮겨보며 ‘그 순간에도 글자가 또렷한가’를 함께 확인하자.

이 다섯 항목을 점검하는 가장 쉬운 요령을 하나 알려주겠다. 바로 ‘회색으로 만들어 보기’다. 우리 사이트 화면을 캡처한 뒤, 사진 앱이나 편집 도구에서 채도를 0으로 내려 흑백으로 바꿔보라. 색이 사라지고 ‘밝기’만 남는다. 이 흑백 화면에서도 글자가 또렷이 읽히고, 빨강/초록으로 구분하던 상태 표시가 여전히 구분된다면, 색 대비와 색 의존성 양쪽을 다 통과한 셈이다. 반대로 흑백으로 만들었더니 글자가 배경에 묻히거나, ‘성공/실패’ 표시가 똑같은 회색 덩어리로 보인다면, 거기가 바로 손볼 곳이다. 흑백 변환은 ‘색약 사용자의 눈’을 잠깐 빌려보는 가장 간단한 방법이다.

또 하나, ‘멀리서 보기’도 효과적이다. 모니터에서 두세 걸음 물러나거나, 화면을 눈에서 멀찍이 떼고 본문을 읽어보라. 가까이서 또렷하던 글자가 멀어지면서 흐려진다면, 그건 대비가 빠듯하다는 신호다. 저시력 사용자가 느끼는 답답함을 ‘거리’로 흉내 내보는 것이다.

색 대비 문제의 근본 원인은 거의 항상 같다. ‘예뻐 보이려고’ 색을 흐리게 뺐다는 것이다. 진한 검정 대신 부드러운 회색, 강한 파랑 대신 옅은 하늘색. 디자인 감각으로는 그게 더 ‘세련돼’ 보인다. 하지만 세련됨과 읽힘이 충돌할 때, 공공 사이트는 망설임 없이 읽힘을 택해야 한다. 멋은 ‘읽힌 다음에’ 따지는 것이다. 안 읽히는 멋은 멋이 아니라 장애물이다.

여기서 자주 듣는 반론이 있다. “그럼 화면이 너무 시커멓고 투박해지지 않나요?” 그렇지 않다. 대비를 지키면서도 충분히 단정하고 세련된 화면을 만들 수 있다. 핵심은 ‘흐리게 빼는 것’ 말고 다른 방법으로 위계를 만드는 것이다. 보조 텍스트를 흐리게 만들어 ‘덜 중요해 보이게’ 하는 대신, 글자 크기를 조금 줄이거나, 위치를 들여 쓰거나, 여백으로 묶어주면 된다. 색의 진하기로 위계를 표현하는 건 가장 손쉽지만 가장 위험한 방법이다. 같은 진한 색이라도 크기·굵기·간격을 달리하면 ‘무엇이 더 중요한지’가 충분히 드러난다. 디자인의 고수일수록 색의 흐림에 기대지 않고 다른 수단으로 위계를 잡는다. 흐림으로 위계를 만드는 건 사실 ‘쉬운 길’이지, ‘세련된 길’이 아니다.

색 대비를 한번 제대로 잡아두면 의외의 곳에서도 덕을 본다. 인쇄물이 그렇다. 공공 사이트의 안내 페이지는 종종 흑백으로 출력되어 민원 창구에 비치되거나 안내문으로 배포된다. 화면에서 색으로만 구분하던 정보는 흑백 출력 순간 전부 뭉개진다. 하지만 처음부터 대비와 ‘색 외의 단서’를 챙겨둔 페이지는 흑백으로 뽑아도 멀쩡하다. 화면 접근성을 위해 한 일이, 종이 위에서도 똑같이 빛을 발하는 것이다. 좋은 접근성 설계는 이렇게 매체를 가리지 않고 효과를 낸다.

 

■ 3. 자막, ‘소리를 못 듣는 사용자’를 위한 다리

이제 자막으로 넘어가자. 자막이라고 하면 흔히 ‘영화 자막’을 떠올리지만, 웹 접근성에서 말하는 자막은 그보다 넓다. 사이트에 올라간 모든 ‘소리 있는 콘텐츠’가 대상이다. 홍보 영상, 정책 설명 동영상, 안내 음성, 행사 생중계까지. 이 소리들을 못 듣는 사용자도 똑같이 내용을 알 수 있게 해주는 ‘텍스트로 된 다리’가 자막이다.

여기서 중요한 인식 전환 하나. 자막은 ‘청각장애인만을 위한 것’이 아니다. 물론 소리를 못 듣는 사용자에게는 자막이 ‘유일한 통로’다. 하지만 그 외에도 자막의 덕을 보는 사람은 훨씬 많다. 시끄러운 지하철에서 이어폰 없이 영상을 보는 사람, 도서관처럼 소리를 못 켜는 공간에 있는 사람, 한국어가 서툴러 소리만으론 못 알아듣고 글자로 보면 이해하는 사람, 발음이 빠르거나 전문 용어가 많아 ‘다시 보기’가 필요한 사람. 이 모두가 자막의 수혜자다. 자막은 ‘소수를 위한 배려’로 시작했지만, 막상 달아놓으면 ‘다수가 더 편해지는’ 기능이다.

공공 사이트에서 자막이 특히 중요한 이유가 있다. 공공 콘텐츠는 ‘알아야 손해를 안 보는’ 정보를 자주 담는다. 지원금 신청 방법, 재난 시 행동 요령, 제도 변경 안내 같은 것들. 이런 정보를 영상으로만, 그것도 자막 없이 올리면, 소리를 못 듣는 사용자는 ‘남들 다 아는 정보를 나만 모르는’ 상황에 놓인다. 정보 격차가 곧 권리의 격차로 이어지는 것이다. 그래서 공공 영상의 자막은 ‘있으면 좋은 것’이 아니라 ‘없으면 차별이 되는 것’이다.

특히 ‘재난·안전’ 정보의 자막은 한순간 생명과도 직결된다. 화재 대피 요령, 지진 행동 수칙, 감염병 예방 안내 같은 영상이 자막 없이 음성으로만 흘러가면, 소리를 못 듣는 사용자는 정작 가장 절박한 순간에 가장 필요한 정보로부터 차단된다. 평소의 정책 안내라면 ‘조금 불편한’ 정도지만, 재난 정보의 단절은 ‘위험’으로 직결된다. 그래서 어떤 영상부터 자막을 달아야 할지 우선순위를 정한다면, ‘안전·재난·생계’와 직결된 콘텐츠가 맨 앞에 와야 한다. 자막을 다는 일이 단순한 ‘친절’을 넘어 ‘안전망’의 일부라는 걸 잊지 말자. 영상 하나에 자막을 다는 데 드는 약간의 수고가, 누군가에겐 ‘제때 알았느냐 못 알았느냐’를 가른다.

자막에도 종류와 수준이 있다. 가장 기본은 ‘말소리를 글자로 옮긴’ 자막이다. 누가 무슨 말을 하는지를 따라 적은 것이다. 한 걸음 더 나아간 자막은 ‘소리 정보’까지 담는다. ‘(박수 소리)’ ‘(경고음)’ ‘(잔잔한 음악)’처럼, 말 외의 의미 있는 소리도 괄호로 알려준다. 영상에서 갑자기 경고음이 울리며 화면이 바뀌는데 자막에 아무 표시가 없으면, 소리를 못 듣는 사용자는 ‘왜 갑자기 분위기가 바뀌었지’ 하고 맥락을 놓친다. 좋은 자막은 ‘들리는 것 전부’를 텍스트로 옮긴다.

■ 4. 자막, 5분 자가 점검표

우리 사이트의 영상·음성 콘텐츠를 떠올리며 아래에 답해보라.

[자막 점검표]

나-1. 사이트에 올라간 영상에 자막이 ‘달려 있는가’? (영상 위에 글자가 같이 나오거나, 켜고 끌 수 있는 자막 버튼이 있는가)

→ 자주 보이는 문제: 홍보 영상은 자막이 있는데, 정작 ‘정책 설명’ 같은 정보성 영상엔 자막이 없다. 중요도가 거꾸로다.

나-2. 자막이 ‘말한 그대로’ 정확한가? 자동 생성 자막이 엉뚱하게 적혀 있지는 않은가?

→ 자주 보이는 문제: 자동 자막을 그대로 두어, 전문 용어나 고유명사가 엉터리로 받아 적혀 오히려 혼란을 준다. 자동 자막은 ‘초안’일 뿐, 사람이 한 번 손봐야 한다.

나-3. 말소리 외의 ‘의미 있는 소리’도 자막에 표시되는가? (경고음, 박수, 배경음악 등)

→ 자주 보이는 문제: 대사만 옮기고 소리 정보는 빠져, 영상의 분위기·맥락 전환을 놓친다.

나-4. 자막 글자가 배경 영상에 묻히지 않고 또렷이 읽히는가?

→ 자주 보이는 문제: 흰 자막이 밝은 화면 위에 떠서 안 읽힌다. 자막 뒤에 반투명 검은 띠를 깔면 해결되는데, 그 처리가 안 돼 있다.

나-5. 음성만 있는 콘텐츠(예: 안내 음성, 팟캐스트형 자료)에 ‘글로 된 내용(스크립트)’이 함께 제공되는가?

→ 자주 보이는 문제: 영상엔 자막을 신경 쓰면서, ‘소리만 있는’ 콘텐츠는 대체 텍스트 없이 올린다.

자막을 점검하는 가장 정직한 방법은 ‘소리를 꺼보는 것’이다. 우리 사이트의 대표 영상 두세 개를 골라, 음소거 상태로 끝까지 봐보라. 소리 없이도 영상이 ‘무슨 이야기를 하는지’ 다 이해된다면 자막이 제 역할을 하는 것이다. 반대로 음소거하니 ‘그림만 흘러가고 무슨 말인지 하나도 모르겠다’면, 그 영상은 소리를 못 듣는 사용자에게 ‘텅 빈 화면’이나 다름없다. 이 ‘음소거 시청’은 청각장애 사용자의 경험을 가장 가깝게 흉내 내보는 방법이다. 단 5분이면 우리 영상들의 자막 상태가 한눈에 드러난다.

자막을 둘러싼 흔한 핑계가 “자막 다는 데 시간과 비용이 많이 든다”는 것이다. 과거엔 일리가 있었다. 영상마다 일일이 받아 적고 시간을 맞춰야 했으니까. 하지만 지금은 자동 자막 생성 기술이 꽤 좋아져서, ‘바닥부터’가 아니라 ‘초안을 다듬는’ 방식으로 일할 수 있다. 자동으로 받아 적은 초안에서 틀린 곳, 특히 기관명·정책명 같은 고유명사만 손보면 된다. 이렇게 보면 자막은 ‘큰 결심’이 필요한 일이 아니라 ‘올릴 때 한 단계 더 거치는’ 습관에 가깝다. 영상을 올리는 절차에 ‘자막 확인’을 한 칸 끼워 넣는 것, 그게 핵심이다.

한 가지 덧붙이면, 자막은 검색에도 이롭다. 영상 속 말소리는 검색 엔진이 못 읽지만, 자막으로 옮긴 텍스트는 읽는다. 즉 자막을 달면 그 영상의 내용이 검색에 잡히게 되어, 더 많은 사용자가 찾아올 수 있다. 접근성을 위해 단 자막이 ‘더 많은 방문’이라는 덤까지 가져다주는 셈이다. 접근성과 효율이 충돌하기는커녕 같은 방향을 보는 좋은 예다.

자막을 이야기할 때 빼놓을 수 없는 게 ‘수어(수화)’와 ‘대본 제공’의 구분이다. 자막은 ‘소리를 글자로’ 옮긴 것이고, 일부 공공 영상엔 화면 한쪽에 수어 통역이 함께 들어가기도 한다. 둘은 보완 관계다. 청각장애인 중에는 한국어 문장보다 수어가 더 편한 분들이 있어서, 중요한 정책 발표나 재난 안내 같은 핵심 콘텐츠엔 자막과 수어를 함께 제공하는 게 가장 좋다. 다만 모든 영상에 수어를 넣는 건 현실적으로 부담이 크니, ‘영향이 큰 핵심 콘텐츠’부터 우선 적용하는 게 합리적이다. 반대로 영상이 아니라 ‘소리만 있는’ 콘텐츠—예를 들어 음성 안내나 라디오형 자료—는 자막 대신 ‘전체 내용을 글로 풀어둔 대본’을 함께 올리면 된다. 화면이 없으니 자막을 얹을 자리가 없는 대신, 그 옆에 텍스트 링크 하나로 ‘여기 전체 내용이 글로 있습니다’를 제공하는 것이다. 콘텐츠의 형태에 따라 자막·대본·수어 중 알맞은 다리를 골라 놓는 게 핵심이다.

자막의 ‘타이밍’도 의외로 중요하다. 자막이 말보다 너무 빨리 뜨거나 늦게 사라지면, 화면의 입 모양과 글자가 어긋나 오히려 산만해진다. 또 한 번에 너무 긴 문장을 통째로 띄우면 읽는 속도가 영상 속도를 못 따라간다. 좋은 자막은 한 번에 한두 줄씩, 말의 호흡에 맞춰 끊어 보여준다. 자동 생성 자막을 다듬을 때 내용의 ‘정확성’만 보기 쉬운데, ‘끊어 읽기’와 ‘타이밍’까지 한번 점검하면 자막의 질이 한 단계 올라간다. 이것도 거창한 작업이 아니라, 음소거로 한 번 보면서 ‘읽을 만한 속도인가’를 체감하는 것으로 충분히 확인된다.

 

■ 5. 스크린리더, ‘화면을 못 보는 사용자’의 눈

이제 가장 낯설지만 가장 중요한 이야기다. 스크린리더. 화면을 못 보는 시각장애 사용자는 ‘화면을 읽어주는 프로그램’을 통해 사이트를 쓴다. 이 프로그램이 화면의 글자와 버튼, 링크를 순서대로 소리 내어 읽어주면, 사용자는 그 소리를 듣고 키보드로 조작한다. 즉 이들에게 사이트는 ‘보는 것’이 아니라 ‘듣는 것’이다.

여기서 결정적인 사실 하나. 스크린리더는 화면을 ‘보이는 대로’ 읽지 않는다. 화면 뒤에 숨은 ‘코드’를 읽는다. 우리 눈엔 버튼처럼 보여도, 코드상으로 그게 ‘버튼’이라고 표시돼 있지 않으면 스크린리더는 그걸 버튼으로 안 읽는다. 이미지가 화면엔 큼직하게 떠 있어도, 코드에 ‘이 이미지는 무엇이다’라는 설명(대체텍스트)이 없으면 스크린리더는 그냥 ‘이미지’라고만 읽거나 아예 건너뛴다. 그래서 ‘눈으로 보기엔 멀쩡한’ 사이트가 스크린리더로는 ‘뒤죽박죽 외계어’가 되는 일이 흔하다.

이 지점이 색 대비·자막과 스크린리더의 큰 차이다. 색 대비와 자막은 ‘눈으로·귀로’ 어느 정도 확인이 된다. 하지만 스크린리더 문제는 ‘직접 들어보지 않으면’ 보이지 않는다. 화면만 봐선 코드 속 사정을 알 수 없기 때문이다. 그래서 스크린리더 점검은 ‘한 번이라도 켜서 들어보는’ 경험이 무엇보다 값지다.

겁먹을 필요 없다. 요즘 대부분의 컴퓨터와 스마트폰엔 스크린리더가 기본으로 들어 있다. 설정에서 ‘화면 읽기’ ‘음성 안내’ 같은 접근성 기능을 켜면 된다. 처음엔 빠른 음성이 낯설고 어지러울 수 있다. 그건 당연하다. 매일 그걸로 사이트를 쓰는 사용자들도 처음엔 그랬다. 다만 우리는 ‘능숙하게 쓰려는’ 게 아니라 ‘우리 사이트가 들어줄 만한지’만 확인하면 되니, 몇 분만 켜봐도 충분하다.

처음 켜보는 분들을 위해 팁을 하나 주자면, 음성 속도를 ‘느리게’로 낮춰두고 시작하라. 익숙한 사용자들은 우리가 못 따라갈 만큼 빠른 속도로 듣지만, 처음엔 한 글자 한 글자 또박또박 읽히게 해야 ‘무슨 말을 하는지’ 따라갈 수 있다. 그리고 처음부터 복잡한 신청 페이지를 고르지 말고, 비교적 단순한 안내 페이지 하나로 연습 삼아 시작하는 게 좋다. 단순한 페이지로 ‘아, 이렇게 읽고 이렇게 넘어가는구나’ 하는 흐름을 익힌 뒤, 점차 복잡한 페이지로 옮겨가면 부담이 훨씬 덜하다. 또 스크린리더를 켤 땐 ‘끄는 방법’을 먼저 익혀두는 게 좋다. 처음엔 화면이 안 보이거나 조작이 꼬여 당황하기 쉬운데, 끄는 단축키나 설정 위치를 미리 알아두면 마음 편히 켜볼 수 있다.

■ 6. 스크린리더, 5분 자가 점검표

스크린리더를 켠 상태에서, 혹은 코드를 살짝 들여다보며 아래를 점검해보라.

[스크린리더 점검표]

다-1. 의미 있는 이미지에 ‘대체텍스트’가 있는가? 스크린리더가 그 이미지를 ‘무엇이다’라고 읽어주는가?

→ 자주 보이는 문제: 대체텍스트가 비어 있거나, ‘이미지’ ‘사진1’ ‘배너’처럼 무의미하게 채워져 있다. 정작 그 이미지가 담은 정보(예: 행사 일정 포스터의 날짜·장소)는 어디에도 글로 없다.

다-2. 버튼과 링크가 ‘무엇을 하는지’ 읽히는가?

→ 자주 보이는 문제: ‘여기를 클릭’ ‘바로가기’ ‘더보기’처럼 맥락 없는 말만 읽혀, 무슨 버튼인지 모른다. ‘○○ 신청 바로가기’처럼 목적이 드러나야 한다.

다-3. 제목이 ‘제목답게’ 표시돼 있는가? (큰 글씨로 보이기만 하는 게 아니라, 코드상으로도 제목 단계가 매겨져 있는가)

→ 자주 보이는 문제: 제목을 그냥 큰 글씨·굵은 글씨로만 처리해, 스크린리더가 ‘제목’으로 인식 못 한다. 그러면 사용자가 제목만 빠르게 훑어 원하는 곳으로 점프하는 ‘목차 탐색’을 못 쓴다.

다-4. 입력칸마다 ‘무엇을 적는 칸인지’ 라벨이 코드로 연결돼 있는가?

→ 자주 보이는 문제: 화면엔 ‘이름’이라고 적혀 있지만 그게 입력칸과 코드로 묶여 있지 않아, 스크린리더가 ‘빈 입력칸’이라고만 읽는다. 사용자는 무슨 칸인지 모른 채 마주한다.

다-5. 화면을 키보드 Tab 키로 이동할 때, 읽히는 순서가 ‘위에서 아래로, 보이는 순서대로’ 자연스러운가?

→ 자주 보이는 문제: 화면 배치와 코드 순서가 어긋나, 스크린리더가 엉뚱한 곳으로 튀며 읽는다. 사용자는 길을 잃는다.

스크린리더 점검의 핵심은 ‘눈을 감고 들어보기’다. 스크린리더를 켜고, 모니터를 잠깐 끄거나 눈을 감은 채, 우리 사이트의 대표 페이지 하나를 처음부터 끝까지 ‘들어서만’ 이해해보라. 메인 페이지에서 ‘민원 신청’을 찾아 들어가는 흐름 정도면 충분하다. 들려오는 소리만으로 ‘지금 어디에 있고’ ‘무엇을 누르면 되는지’가 그려진다면 통과다. 반대로 ‘이미지, 이미지, 링크, 링크, 빈 칸’ 같은 정체불명의 소리만 이어진다면, 시각장애 사용자에게 우리 사이트는 ‘안갯속’이다.

이 경험은 처음엔 충격적일 수 있다. ‘우리 사이트가 이렇게 들렸구나’ 하는 당혹감 말이다. 하지만 그 당혹감이야말로 개선의 출발점이다. 한 번이라도 ‘들어본’ 담당자는 다시는 대체텍스트를 비워두지 못하고, ‘여기를 클릭’ 같은 버튼 이름을 쓰지 못한다. 보이지 않던 사용자가 갑자기 ‘선명한 한 사람’으로 다가오기 때문이다.

스크린리더로 들어볼 때 특히 주의해서 들어야 할 ‘함정 구간’ 몇 곳을 미리 일러두겠다. 첫째, 팝업과 알림창이다. 화면엔 큼직하게 뜨는 안내창인데, 스크린리더가 그 등장을 안 읽고 지나가면 사용자는 ‘무슨 일이 일어났는지’ 모른 채 멈춰 있게 된다. 신청을 마쳤는데 ‘완료되었습니다’ 창이 안 읽히면, 사용자는 ‘된 건가 안 된 건가’ 알 수 없다. 둘째, 표다. 표는 ‘가로 제목’과 ‘세로 제목’이 만나 의미가 생기는 구조인데, 코드가 그 관계를 안 알려주면 스크린리더는 숫자만 줄줄이 읽어 ‘이 숫자가 어느 항목인지’ 알 수 없게 된다. 공공 사이트의 통계·현황 표가 특히 여기서 자주 막힌다. 셋째, ‘아이콘만 있는 버튼’이다. 돋보기 모양 검색 버튼, X 모양 닫기 버튼처럼 글자 없이 그림만 있는 버튼은, 코드에 이름이 안 붙어 있으면 ‘버튼’이라고만 읽히거나 아예 안 읽힌다. 이 세 곳—팝업, 표, 아이콘 버튼—을 의식하고 들으면, 들어볼 때 ‘여기가 왜 이렇게 답답하지’ 싶던 지점의 정체가 풀린다.

여기서 한 가지 위로의 말을 보태고 싶다. 스크린리더 점검은 처음이 가장 어렵고, 두 번째부터는 훨씬 쉽다. 처음엔 빠른 음성과 낯선 조작에 어지럽지만, 한 페이지만 끝까지 들어보면 ‘아, 이렇게 듣고 이렇게 움직이는 거구나’ 하는 감이 잡힌다. 그 감을 한 번 잡으면, 다음부턴 새 페이지를 올릴 때마다 ‘이게 소리로 어떻게 들릴까’가 자연스럽게 머릿속에 그려진다. 화면을 만들면서 동시에 ‘소리로 시청각화’하는 능력이 생기는 것이다. 이건 어떤 매뉴얼로도 못 가르치는, 오직 한 번 ‘들어봐야’ 생기는 감각이다.

스크린리더 문제의 뿌리는 대개 ‘화면만 보고 만든다’는 데 있다. 만드는 사람은 눈으로 보며 작업하니, 코드 속 ‘이름표’가 비어 있어도 화면이 멀쩡하면 ‘다 됐다’고 여긴다. 하지만 스크린리더는 바로 그 ‘이름표’를 읽는다. 그래서 해법도 명확하다. 만들 때 ‘화면에 어떻게 보이나’뿐 아니라 ‘소리로 어떻게 읽히나’를 한 번 더 챙기는 것. 이미지를 넣을 땐 그 의미를 한 줄로 적고, 버튼엔 목적이 드러나는 이름을 붙이고, 제목은 제목답게 표시하는 것. 이 작은 습관들이 모이면, 화면을 못 보는 사용자에게도 우리 사이트가 ‘읽어줄 만한 곳’이 된다.

대체텍스트를 적을 때 자주 헷갈리는 지점이 있어 짚고 넘어가자. ‘모든 이미지에 설명을 다 적어야 하나?’라는 질문이다. 답은 ‘아니오’다. 이미지에도 종류가 있다. 정보를 담은 이미지—예컨대 행사 포스터, 통계 그래프, 안내도—는 그 정보를 글로 옮겨 적어야 한다. 포스터라면 ‘무슨 행사, 언제, 어디서’가 대체텍스트에 들어가야지, ‘포스터 이미지’라고만 적으면 정작 중요한 정보는 빠진 셈이다. 반대로 순전히 ‘장식’인 이미지—내용과 무관한 배경 무늬, 구분선 역할의 그림—는 오히려 대체텍스트를 ‘비워두는’ 게 맞다. 장식 이미지마다 스크린리더가 ‘배경 그림, 배경 그림’ 하고 읽으면 사용자는 의미 없는 소리에 시달린다. 즉 ‘의미 있는 이미지는 의미를 적고, 장식 이미지는 비운다’가 원칙이다. 무엇이 의미 있는 이미지인지 헷갈릴 땐 ‘이 이미지를 글로 바꿔도 정보가 안 줄어드나’를 떠올리면 된다. 줄어드는 게 있다면 그건 의미 있는 이미지다.

제목 구조 이야기도 한 번 더 깊이 들어가 보자. 스크린리더 사용자는 페이지를 처음부터 끝까지 다 듣지 않는다. 그건 너무 오래 걸린다. 대신 ‘제목만 빠르게 건너뛰며’ 원하는 곳을 찾는다. 마치 우리가 긴 문서를 볼 때 목차나 굵은 소제목만 훑어 원하는 부분으로 점프하는 것과 같다. 그런데 이 ‘제목 점프’가 작동하려면, 제목이 코드상으로 ‘제목 1단계, 2단계, 3단계’처럼 위계가 매겨져 있어야 한다. 화면에 큰 글씨로 보이는 것만으론 부족하다. 큰 글씨는 ‘보이는 제목’일 뿐, 코드가 ‘이건 제목이다’라고 알려주지 않으면 스크린리더는 그냥 일반 문장으로 읽고 지나간다. 그러면 사용자는 목차 점프를 못 쓰고 페이지 전체를 처음부터 다 들어야 한다. 제목 위계를 제대로 매기는 일은, 시각장애 사용자에게 ‘목차’와 ‘빠른 길’을 동시에 쥐여주는 것과 같다. 게다가 제목 위계가 잘 잡힌 페이지는 검색 엔진도 구조를 더 잘 이해하니, 여기서도 접근성과 검색 효율이 손을 잡는다.

버튼과 링크의 이름도 다시 강조하고 싶다. ‘여기를 클릭’ ‘바로가기’ ‘더보기’ 같은 말은 화면에선 앞뒤 맥락과 함께 보이니 문제가 안 된다. 사용자가 ‘아, 이 표 옆의 더보기는 이 표를 더 보라는 거구나’ 하고 눈으로 파악하기 때문이다. 하지만 스크린리더 사용자는 종종 ‘링크만 모아서’ 듣는다. 그러면 ‘더보기, 더보기, 더보기, 바로가기, 바로가기’ 하는 정체불명의 목록만 들린다. 어느 더보기가 무엇의 더보기인지 알 길이 없다. 그래서 버튼·링크 이름은 ‘그 자체로 목적이 드러나게’ 적어야 한다. ‘민원 신청 더보기’ ‘예산 현황 바로가기’처럼. 글자 몇 개 더 붙이는 수고가, 누군가에겐 ‘길을 찾느냐 헤매느냐’를 가른다.

 

■ 7. 세 가지를 한 번에 묶는 ‘통합 점검 루틴’

지금까지 색 대비·자막·스크린리더를 따로 봤는데, 실무에선 이 셋을 ‘하나의 루틴’으로 묶어두는 게 훨씬 효율적이다. 매번 따로 점검하면 빠뜨리기 쉽고, 묶어두면 ‘콘텐츠를 올릴 때마다 자동으로 챙기는’ 습관이 된다. 내가 권하는 루틴은 이렇다.

첫째, ‘올리기 전 3분 점검’. 새 페이지나 콘텐츠를 공개하기 직전, 세 가지만 확인한다. ① 흑백으로 바꿔봤을 때 글자가 읽히나(색 대비), ② 영상이라면 음소거하고도 이해되나(자막), ③ 이미지엔 설명을 적었나·버튼 이름은 목적이 드러나나(스크린리더). 이 3분이 공개 후의 민원과 수정을 크게 줄여준다.

둘째, ‘분기마다 깊게 한 바퀴’. 분기에 한 번은 대표 페이지 서너 개를 골라, 실제로 스크린리더를 켜서 끝까지 들어보고, 영상을 음소거로 보고, 화면을 흑백으로 만들어 본다. 평소의 ‘빠른 점검’이 놓친 깊은 문제를 잡는 시간이다. 같은 페이지를 분기마다 점검하면, 우리 사이트의 접근성이 나아지는지 나빠지는지 추세까지 보인다.

셋째, ‘새로 들어오는 사람에게 부탁하기’. 사이트를 잘 모르는 동료나 신규 입사자에게 ‘이 페이지에서 ○○를 해보라’고 부탁하고 옆에서 지켜본다. 익숙한 사람은 익숙해서 안 보이는 문제를, 처음 온 사람은 처음이라 바로 본다. 특히 ‘이거 글자가 잘 안 보이는데요’ ‘이 버튼 뭐 하는 건지 모르겠어요’ 같은 무심한 한마디가 우리가 놓친 접근성 구멍을 정확히 짚어준다.

이 세 루틴의 공통점은 ‘거창하지 않다’는 것이다. 큰 예산도, 외부 전문가도, 긴 회의도 필요 없다. 그저 ‘올릴 때 한 번 더 보기’ ‘분기마다 한 번 깊게 보기’ ‘남의 눈 빌리기’ 세 가지를 습관으로 만드는 것뿐이다. 접근성은 ‘한 번 크게 손보고 끝내는 프로젝트’가 아니라 ‘매일 조금씩 챙기는 살림’에 가깝다. 살림은 한 번 대청소했다고 끝나지 않는다. 매일 조금씩 치워야 깨끗하게 유지된다. 접근성도 똑같다.

이 루틴을 조직에 정착시키는 작은 요령도 하나 나누고 싶다. ‘점검 결과를 기록으로 남기는 것’이다. 점검만 하고 머릿속에 담아두면, 며칠만 지나도 ‘분명 어디가 흐렸는데 어디였더라’가 된다. 그래서 ‘아니오’가 나온 항목 옆엔 반드시 한 줄짜리 메모를 붙여두길 권한다. 이를테면 ‘다-1 아니오 — 메인 배너 이미지에 행사 날짜·장소가 alt에 안 들어감’처럼. 이 한 줄이 나중에 ‘무엇을 고칠지’ 정확히 짚어주는 작업 지시서가 된다. 점검의 가치는 ‘발견’이 아니라 ‘기록’에서 완성된다. 그리고 이 기록을 분기마다 비교하면, 우리 사이트가 좋아지고 있는지 추세가 한눈에 보인다. ‘지난 분기엔 대체텍스트 누락이 12건이었는데 이번엔 4건으로 줄었다’ 같은 변화가 숫자로 잡히면, 접근성 개선이 ‘막연한 노력’이 아니라 ‘성과가 보이는 일’이 된다.

한 가지 더, 이 루틴을 ‘담당자 한 사람의 일’로 두지 않는 것도 중요하다. 콘텐츠를 올리는 사람, 양식을 기획하는 사람, 외주를 관리하는 사람—사이트에 손을 대는 모두가 조금씩 접근성을 만든다. 그래서 ‘올리기 전 3분 점검’은 특정 부서의 숙제가 아니라, 무언가를 공개하는 모든 사람의 ‘마지막 한 단계’가 되어야 한다. 외주 업체에 일을 맡길 때도 마찬가지다. 계약서나 발주 단계에서 ‘색 대비 기준 준수, 영상 자막 제공, 이미지 대체텍스트 작성’을 명시해두면, 나중에 ‘왜 이건 안 했냐’며 실랑이할 일이 없다. 접근성은 ‘완성된 결과물을 검수하는 단계’보다 ‘만들기 시작하는 단계’에서 못 박아 두는 게 훨씬 싸고 확실하다.

 

■ 8. ‘아니오’가 많이 나왔다면 — 자책 대신 우선순위

여기까지 점검표 열다섯 항목을 따라왔다면, 아마 ‘아니오’가 적잖이 나왔을 것이다. 그게 정상이다. 앞서 말했듯 ‘아니오’가 많다는 건 점검을 제대로 했다는 뜻이고, 고칠 거리를 그만큼 많이 확보했다는 뜻이다. 중요한 건 ‘다 한꺼번에 고치려는 욕심’을 내려놓는 것이다. 모든 이미지에 대체텍스트를 달고, 모든 영상에 자막을 입히고, 모든 색을 손보려 들면, 일이 너무 커져서 시작도 못 하고 미뤄진다.

그래서 우선순위를 권한다. 기준은 단순하다. ‘영향받는 사용자가 많고, 고치기 쉬운 것’부터다. 보통은 이런 순서가 된다.

가장 먼저: ‘가장 많이 찾는 페이지’의 색 대비. 방문자 대다수가 거치는 메인·주요 안내·대표 신청 페이지의 글자 대비부터 잡는다. 영향받는 사람이 가장 많고, 색은 비교적 손보기 쉽다.

그다음: ‘정보성 영상’의 자막. 홍보 영상보다 ‘알아야 손해를 안 보는’ 정책·제도·재난 안내 영상에 자막부터 단다. 자동 자막 초안을 다듬는 방식이면 부담도 작다.

그다음: ‘대표 흐름’의 스크린리더 점검. 가장 많이 쓰는 신청·검색 흐름 하나를 골라, 이미지 대체텍스트·버튼 이름·입력칸 라벨을 챙긴다. 모든 페이지를 다 손보는 대신, ‘가장 많이 지나는 길’부터 닦는 것이다.

이렇게 ‘많은 사람이 지나는 길’부터 닦아 나가면, 적은 노력으로 가장 많은 사용자가 혜택을 본다. 접근성 개선은 ‘완벽’을 한 번에 노리는 게 아니라, ‘오늘보다 나은 내일’을 꾸준히 쌓는 일이다. 어제 못 들어오던 한 사람이 오늘 들어올 수 있게 됐다면, 그날의 개선은 충분히 성공이다.

여기서 한 가지 흔한 함정을 경고하고 싶다. ‘완벽주의의 마비’다. 접근성 점검을 하다 보면 고칠 게 너무 많아 보여서, ‘이걸 언제 다 하나’ 하는 막막함에 아예 손을 못 대는 경우가 많다. 그런데 접근성은 ‘0점 아니면 100점’이 아니다. 50점에서 60점으로 올라가는 것도 ‘열 명 중 한 명이 더 들어올 수 있게 된’ 분명한 진전이다. 그래서 나는 늘 ‘오늘 한 개’를 권한다. 오늘 메인 배너 이미지 하나에 제대로 된 대체텍스트를 달았다면, 그걸로 오늘 몫은 다 한 것이다. 내일은 다음 이미지 하나. 이렇게 ‘하루 한 개’만 꾸준히 해도, 한 달이면 스무 개가 넘는 이미지가 고쳐진다. 완벽을 노리다 아무것도 못 하는 것보다, 불완전하게라도 꾸준히 나아가는 쪽이 언제나 낫다.

또 하나 권하고 싶은 건 ‘작은 승리를 공유하기’다. 접근성 개선은 눈에 잘 안 띄는 일이라, 열심히 해도 ‘티가 안 나는’ 경우가 많다. 그래서 동력을 잃기 쉽다. 이럴 때 ‘이번 달엔 주요 영상 다섯 개에 자막을 달았습니다’ ‘대체텍스트 누락을 30건에서 10건으로 줄였습니다’ 같은 작은 성과를 팀이나 윗선에 짧게라도 공유하면, 그 일이 ‘인정받는 일’이 되고, 인정받는 일은 계속하게 된다. 접근성은 마라톤이라, 중간중간 ‘여기까지 왔다’는 이정표를 스스로 세워주는 게 끝까지 가는 비결이다.

 

■ 9. 눈과 귀로 거칠게, 도구로 정밀하게

지금까지 소개한 점검표는 전부 ‘사람의 눈과 귀로’ 하는 것이다. 이 방식의 장점은 분명하다. 비용이 안 들고, 지금 당장 할 수 있고, ‘사용자의 경험’을 몸으로 느낄 수 있다. 하지만 한계도 또렷하다. 사람의 눈은 색 대비 비율을 ‘숫자로’ 재지 못한다. 4.5대 1에 아슬아슬하게 못 미치는 색을 눈으로 잡아내긴 어렵다. 사람이 사이트의 수백 페이지·수천 개 이미지의 대체텍스트를 일일이 확인하는 것도 현실적으로 불가능하다. 손으로 하는 점검은 ‘대표적인 몇 곳’의 ‘대표적인 문제’를 잡는 데까진 훌륭하지만, ‘사이트 전체’를 ‘빠짐없이’ 훑기엔 사람의 시간이 턱없이 부족하다.

그래서 가장 좋은 방법은 둘을 합치는 것이다. 사람의 눈과 귀로 ‘무엇이 문제인지, 왜 문제인지’의 감각을 익히고, 그 위에서 자동 검사 도구로 ‘어디가, 얼마나, 몇 개나’ 문제인지를 빠짐없이 확정하는 것. 손 점검이 ‘방향’을 잡아주고, 도구가 ‘전수 조사’를 해준다. 이 둘이 만나야 접근성 개선이 ‘느낌’에서 ‘근거’로 올라선다.

여기서 ViewCheck 이야기를 잠깐 하겠다. ViewCheck는 공공 웹사이트를 KRDS 기준으로 자동 진단하는 서비스다. KRDS는 우리나라 공공 웹의 디자인·구현 표준으로, 846개 규칙(기초 DS 120개, 부품 CP 446개, 흐름 BP 108개, 서비스 SP 172개)으로 이뤄져 있다. ViewCheck는 사이트 주소만 넣으면 이 846규칙을 자동으로 따져보고, 어느 페이지가 어느 규칙을 어긋났는지를 정리해준다.

오늘 다룬 색 대비·자막·스크린리더는 우리나라 웹 접근성 지침인 KWCAG의 33개 항목과 맞닿아 있다. ViewCheck는 이 KWCAG 항목들도 함께 점검한다. 사람 손으로는 한두 페이지 색 대비를 눈대중으로 보는 게 고작이지만, ViewCheck는 사이트의 여러 페이지를 한꺼번에 돌며 ‘색 대비가 기준에 못 미치는 글자’ ‘대체텍스트가 빠진 이미지’ ‘제목 단계가 어긋난 곳’ 같은 걸 숫자와 목록으로 뽑아준다. 손 점검에서 ‘아 여기가 좀 흐린데’ 하고 느낀 그 감각을, 도구가 ‘이 페이지의 이 글자, 대비 3.2대 1, 기준 미달’처럼 또렷한 근거로 바꿔주는 것이다.

특히 다중 페이지 진단이 강점이다. 공공 사이트는 페이지가 수십, 수백 개인데, 손으로는 그중 몇 개밖에 못 본다. 하필 점검 안 한 페이지에 문제가 몰려 있으면, ‘우리 괜찮은 줄 알았는데’ 하는 사각지대가 생긴다. 자동 진단은 그 사각지대를 줄여준다. ‘대표 페이지는 멀쩡한데 하위 안내 페이지들에서 대체텍스트 누락이 무더기로 나온다’ 같은, 사람 눈으론 놓치기 쉬운 패턴을 잡아주는 것이다.

진단 결과는 화면 상단의 점수 카드로 한눈에 들어온다. 접근성을 비롯한 여러 영역의 점수가 카드 형태로 정리돼, ‘우리 사이트가 지금 어느 수준이고, 어디부터 손봐야 하는지’를 빠르게 가늠할 수 있다. 숫자로 된 점수가 ‘막연한 불안’을 ‘구체적인 할 일’로 바꿔준다.

오해는 말자. ViewCheck가 사람 점검을 ‘대체’하는 건 아니다. 도구는 ‘기준에 어긋난 것’을 잡아내는 데 강하지만, ‘이 대체텍스트가 의미를 제대로 담았는가’ 같은 ‘질’의 판단은 결국 사람의 몫이다. 그래서 오늘 글이 권하는 순서는 ‘손으로 감 잡고 → 도구로 전수 확인 → 다시 사람이 질을 다듬기’다. 도구와 사람은 경쟁자가 아니라 한 팀이다.

조금 더 풀어 설명하면 이렇다. 자동 검사는 ‘이미지에 대체텍스트가 비어 있다’는 사실은 100% 정확히 잡아낸다. 비어 있는 칸은 코드로 명확하게 드러나기 때문이다. 하지만 ‘대체텍스트에 ＜배너＞라고 적혀 있다’는 걸 도구가 본다면, 그게 ‘채워져 있긴 한데 의미가 없는’ 경우인지까지 기계가 판단하긴 어렵다. 색 대비도 마찬가지다. ‘이 글자의 대비가 3.2대 1로 기준 미달’이라는 숫자는 도구가 정확히 뽑아주지만, ‘이 흐린 글자가 사실 중요한 안내인지 단순 장식인지’는 사람이 봐야 안다. 그래서 가장 똑똑한 방식은 도구가 뽑아준 ‘후보 목록’을 사람이 ‘우선순위와 질’의 관점에서 다시 정리하는 것이다. 도구는 ‘여기 백 군데가 의심스럽다’를 빠르게 알려주고, 사람은 그중 ‘진짜 급한 열 군데’를 골라낸다. 이 분업이 접근성 개선을 가장 빠르고 정확하게 만든다.

행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공 웹이 갖춰야 할 품질을 호환성·접근성·개방성·접속성·편의성·효율성·신뢰성의 7대 영역으로 정리해두고 있다. 오늘 다룬 색 대비·자막·스크린리더는 이 가운데 ‘접근성’ 영역의 핵심이다. ViewCheck는 이 접근성뿐 아니라 7대 영역과 KRDS 846규칙을 두루 살피니, 우리 사이트가 ‘접근성은 챙겼는데 다른 영역에서 새고 있지는 않은지’까지 한 화면에서 가늠할 수 있다. 접근성 한 가지만 따로 보는 게 아니라, 사이트의 품질 전체를 한 흐름으로 점검하게 되는 셈이다. 오늘은 접근성이 주제지만, 사이트의 건강은 어느 한 영역만으로 결정되지 않는다는 점도 기억해두면 좋다.

 

■ 10. 접근성은 ‘비용’이 아니라 ‘설계’다

마지막으로 인식 하나를 바로잡고 싶다. 많은 현장에서 접근성을 ‘추가 비용’이나 ‘나중에 챙길 숙제’로 여긴다. 사이트를 다 만든 뒤에 ‘접근성도 좀 신경 쓰자’며 덧붙이는 식이다. 그런데 이렇게 ‘나중에’ 하면 거의 항상 더 비싸고 더 어렵다. 이미 만들어진 구조를 뜯어고쳐야 하기 때문이다.

접근성은 ‘설계의 일부’로 처음부터 끼워 넣을 때 가장 싸고 가장 자연스럽다. 색을 정할 때 처음부터 대비 기준을 지키면, 나중에 색을 다 갈아엎을 일이 없다. 영상을 올리는 절차에 처음부터 ‘자막 확인’을 넣으면, 쌓인 무자막 영상을 한꺼번에 손볼 일이 없다. 이미지를 넣는 습관에 ‘설명 한 줄 적기’를 처음부터 끼우면, 수천 개 이미지의 대체텍스트를 소급해 채울 일이 없다. ‘처음부터’가 ‘나중에’보다 언제나 싸다.

그리고 거듭 강조하지만, 접근성은 ‘소수를 위한 양보’가 아니라 ‘모두를 위한 개선’이다. 색 대비를 높이면 어르신도, 햇빛 아래 사용자도, 저가 모니터 사용자도 다 편해진다. 자막을 달면 청각장애인뿐 아니라 지하철의 직장인도, 한국어가 서툰 사용자도 덕을 본다. 스크린리더를 챙기면 시각장애인뿐 아니라, 그 과정에서 정돈된 제목과 명확한 버튼 이름 덕에 모든 사용자가 길을 덜 헤맨다. 접근성은 ‘바닥을 높이는’ 일이고, 바닥이 높아지면 모두가 그 위에서 더 편히 선다.

공공 사이트라면 더 그렇다. 공공 서비스의 본질은 ‘누구도 배제하지 않는 것’이다. 시력이 약하다고, 소리를 못 듣는다고, 화면을 못 본다고 해서 받아야 할 정보를 못 받고 신청해야 할 일을 못 한다면, 그건 단순한 ‘불편’이 아니라 ‘권리의 박탈’이다. 색 대비를 높이고, 자막을 달고, 스크린리더가 읽을 수 있게 만드는 일은, 결국 ‘우리 기관의 문을 모두에게 똑같이 여는 일’이다. 그 문을 여는 첫걸음이 오늘의 점검표였길 바란다.

접근성을 ‘설계의 일부’로 챙기면 또 하나 좋은 점이 있다. 사이트 전체의 ‘구조’가 단단해진다는 것이다. 대체텍스트를 챙기려면 ‘이 이미지가 무슨 의미인가’를 매번 생각하게 되고, 버튼 이름을 명확히 하려면 ‘이 버튼이 정확히 무슨 일을 하는가’를 따지게 되며, 제목 위계를 매기려면 ‘이 페이지의 정보가 어떤 층으로 짜여 있나’를 정리하게 된다. 이 과정 자체가 사이트를 더 논리적이고 정돈된 구조로 만든다. 그래서 접근성을 잘 챙긴 사이트는 ‘장애가 있는 사용자에게만’ 친절한 게 아니라, 모든 사용자에게 더 명확하고, 검색 엔진에게 더 잘 읽히고, 나중에 유지·보수하는 개발자에게도 더 다루기 쉬운 사이트가 된다. 접근성은 ‘착한 일’이면서 동시에 ‘잘 만드는 일’이다. 둘은 한 몸이다.

마지막으로, 접근성을 한 사람의 ‘선의’에만 기대지 말자는 당부를 하고 싶다. 선의는 귀하지만 사람이 바뀌면 사라진다. 담당자가 바뀌고, 외주가 바뀌고, 시간이 흐르면 어렵게 쌓은 접근성도 조금씩 무너진다. 그래서 접근성은 ‘선의’가 아니라 ‘절차’로 박아 두어야 한다. 콘텐츠를 올리는 절차에 자막 확인을 넣고, 이미지를 등록하는 화면에 대체텍스트 칸을 필수로 만들고, 분기마다 자동 진단을 돌리는 일정을 잡아두는 것. 이렇게 절차에 녹여두면, 누가 담당하든 접근성이 ‘저절로 챙겨지는’ 사이트가 된다. 사람이 아니라 시스템이 접근성을 지키게 만드는 것 — 그게 ‘지속 가능한 접근성’의 진짜 모습이다.

【 마무리 】

오늘 우리는 웹 접근성의 세 기둥을 짚었다. 색 대비는 ‘읽을 수 있게’, 자막은 ‘들을 수 없어도 알 수 있게’, 스크린리더는 ‘볼 수 없어도 쓸 수 있게’ 만드는 다리다. 그리고 이 셋을 점검하는 방법은 의외로 소박했다. 화면을 흑백으로 바꿔 글자가 읽히는지 보고, 영상을 음소거로 틀어 이해되는지 보고, 스크린리더를 켜 눈을 감고 들어보는 것. 특별한 도구도, 큰 예산도 없이 ‘사용자의 자리에 잠깐 앉아보는 것’만으로 우리 사이트의 약점이 드러난다.

다시 한번 마음가짐을 정리하자. 첫째, ‘아니오’를 두려워 말 것. 많이 찾을수록 잘 점검한 것이다. 둘째, 한 번에 다 고치려 들지 말 것. ‘많은 사람이 지나는 길’부터 닦으면 된다. 셋째, 손 점검과 자동 진단을 함께 쓸 것. 사람의 눈으로 감을 잡고 도구로 전수 확인할 때, 접근성은 ‘느낌’에서 ‘근거’로 올라선다. 넷째, 접근성을 ‘나중 숙제’가 아니라 ‘처음 설계’로 챙길 것. 처음부터가 언제나 더 싸고 더 자연스럽다.

오늘 다룬 열다섯 개의 점검 항목을, 부담 없이 한 장에 적어 책상 앞에 붙여두길 권한다. ‘흑백으로 바꿔 글자가 읽히나’ ‘색 말고 다른 단서도 있나’ ‘영상은 음소거로도 이해되나’ ‘자막은 정확하고 또렷한가’ ‘이미지엔 의미 있는 설명이 있나’ ‘버튼 이름은 목적이 드러나나’ ‘제목은 제목답게 매겨졌나’ — 이 짧은 질문들이 콘텐츠를 올릴 때마다 한 번씩 떠오르게만 해도, 우리 사이트는 매일 조금씩 더 많은 사람에게 열린다. 거창한 결심보다 ‘책상 앞의 작은 점검표 한 장’이 사이트를 바꾼다. 그리고 그 변화는 어느 날 갑자기가 아니라, 오늘 올린 페이지 하나, 내일 다는 자막 하나, 모레 채우는 대체텍스트 하나가 쌓여 천천히 이뤄진다.

그리고 오늘 익힌 ‘손으로 하는 감각’ 위에, ‘도구로 하는 정밀함’을 한 겹 얹어보길 권한다. 우리 사이트가 색 대비·대체텍스트·제목 구조 같은 KWCAG 항목과 KRDS 846규칙을 얼마나 지키고 있는지, 사이트 주소만 넣으면 무료로 한 번 진단해볼 수 있다. krds.viewcheck.co.kr 에 들어가 우리 기관 사이트를 넣어보라. 화면 상단에 뜨는 점수 카드 하나가, 오늘 손으로 더듬어 잡은 그 감각을 또렷한 숫자와 목록으로 바꿔 보여줄 것이다. 막연히 ‘우리 사이트 접근성 괜찮나’ 걱정하던 마음이, ‘여기 이 페이지, 이 이미지부터 고치면 되겠구나’ 하는 구체적인 할 일로 바뀌는 순간을 직접 느껴보길 바란다.

접근성은 거창한 결심이 아니라 작은 습관에서 자란다. 오늘 이 점검표로 단 한 페이지라도 들여다봤다면, 그리고 단 한 곳이라도 ‘아 여기 고쳐야겠다’ 싶은 곳을 찾았다면, 당신은 이미 ‘모두에게 열린 사이트’를 향해 한 걸음 내디딘 것이다. 그 한 걸음이, 어제까지 우리 사이트의 문 앞에서 돌아섰던 누군가를 안으로 들이는 길이 된다.

그리고 그 누군가는 멀리 있지 않다. 노안이 온 부모님일 수도, 햇빛 아래서 급히 정보를 찾는 동료일 수도, 소리를 못 켜는 공간에 앉은 나 자신일 수도 있다. 접근성을 챙긴다는 건 결국 ‘언젠가의 우리 모두’를 위해 사이트의 문을 조금 더 넓게 열어두는 일이다. 오늘의 작은 점검이 그 넓은 문의 첫 경첩을 다는 일이었길 바란다. 다음 주엔 또 다른 주제로 찾아오겠다. 그때까지, 우리 사이트를 ‘처음 온 사용자의 눈과 귀’로 한 번 더 살펴보는 습관이 자리 잡길 진심으로 응원한다. 작은 점검 하나가 누군가의 하루를 바꾼다는 걸 기억하면서.

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