가장 많이 틀리는 접근성 5대 실수

공감·문제제기

월요일 글에서 웹 접근성이 왜 ‘선택이 아니라 의무’인지, KWCAG 33항목이 큰 틀에서 무엇을 보는지를 훑었다. 오늘은 그 추상적인 이야기를 현장 바닥으로 끌어내리려 한다. ‘접근성을 지키자’는 구호는 다들 안다. 문제는 늘 그렇듯 ‘그래서 뭘 어떻게 틀리고 있느냐’는 거다. 그래서 오늘 글은 솔직하게, 점검 현장에서 거의 매번 마주치는 ‘가장 많이 틀리는 접근성 5대 실수’를 익명 사례로 풀어보려 한다.

먼저 고백 같은 이야기부터 하고 싶다. 나는 공공 사이트를 꽤 많이 들여다봤는데, 접근성 문제를 만든 담당자들을 보며 ‘이 사람들이 게을러서 이렇게 됐구나’라고 느낀 적은 거의 없다. 오히려 대부분은 성실했다. 야근하며 콘텐츠를 채우고, 민원에 시달리며 페이지를 고치고, 위에서 내려온 사업을 기한 안에 올리느라 정신이 없었다. 접근성을 ‘안 지킨’ 게 아니라 ‘지킬 여유도, 지킬 방법을 알 기회도 없었던’ 경우가 훨씬 많았다. 그러니 오늘 사례를 읽으며 ‘우리도 저런데’ 싶은 게 나와도 너무 자책하지 않았으면 한다. 이건 누구 탓을 하려는 글이 아니라, ‘어디서 자주 미끄러지는지’를 함께 알아보려는 글이다.

접근성이 특히 까다로운 이유는, 잘못돼도 ‘티가 안 난다’는 데 있다. 색이 제각각이거나 글꼴이 뒤섞이면 그래도 화면을 보는 사람 눈에는 어수선하게라도 보인다. 그런데 접근성은 다르다. 멀쩡히 잘 보이는 화면이, 화면을 ‘못 보는’ 사용자에게는 완전히 막힌 벽일 수 있다. 만든 사람은 마우스로 잘 클릭되고 눈으로 잘 읽히니 ‘문제없네’ 하고 넘어가지만, 키보드만 쓰는 사용자, 화면 낭독기(스크린리더)로 듣는 사용자, 색을 잘 구분 못 하는 사용자에게는 그 화면이 지뢰밭이다. 즉 접근성 문제는 ‘만든 사람 눈에는 안 보이는 문제’라는 게 가장 무섭다. 보이지 않으니 고칠 생각도 안 든다.

여기서 한 가지 숫자를 떠올려 보자. 흔히 ‘장애인을 위한 배려’라고만 생각하지만, 접근성의 혜택을 받는 사람은 훨씬 넓다. 노안이 온 어르신, 한 손에 짐을 들고 한 손으로만 휴대폰을 쓰는 사람, 밝은 야외에서 화면이 잘 안 보이는 사람, 데이터를 아끼려 이미지를 끈 사람, 사고로 일시적으로 한쪽 팔을 못 쓰는 사람 — 이 모두가 접근성의 수혜자다. 접근성을 ‘소수를 위한 특별 대우’로 오해하면 우선순위에서 밀리지만, ‘다수의 일상적 불편을 줄이는 기본기’로 보면 이야기가 달라진다. 공공 서비스는 ‘누구도 빠뜨리지 않는다’가 대전제인 서비스다. 그 대전제를 가장 직접적으로 시험하는 게 바로 접근성이다.

그리고 공공 사이트에서 접근성은 ‘하면 좋은 것’이 아니라 ‘안 하면 안 되는 것’이다. 우리나라에는 웹 접근성을 보장하라는 법적 근거가 있고, 행정안전부와 NIA가 관련 기준과 점검을 운영한다. 한국형 웹 콘텐츠 접근성 지침인 KWCAG는 그 기준의 뼈대다. 즉 접근성은 담당자의 ‘선의’에 맡겨진 영역이 아니라, 지켜야 할 ‘의무’가 명문화된 영역이다. 그런데도 현장에서 자꾸 미끄러지는 건, 의무인 줄은 아는데 ‘구체적으로 무엇을 어떻게’가 막막하기 때문이다. 오늘 글은 그 막막함을 다섯 개의 구체적인 실수로 쪼개서, ‘아 이거구나’ 하고 손에 잡히게 만드는 게 목적이다.

한 가지 더 짚고 싶은 게 있다. 접근성은 ‘민간 서비스’와 ‘공공 서비스’가 무게가 다르다. 민간 쇼핑몰이 접근성이 부실하면, 불편한 사용자는 다른 쇼핑몰로 가면 된다. 선택지가 있다. 그런데 공공 서비스는 ‘대체재’가 없다. 어떤 지원금을 신청하려면 그 기관 사이트밖에 길이 없고, 어떤 민원을 넣으려면 그 행정 사이트밖에 없다. 즉 공공 사이트의 접근성 실패는 ‘불편’으로 끝나지 않고 ‘권리의 박탈’로 이어진다. 다른 데로 갈 수가 없으니까. 받을 자격이 있는 지원을, 행정의 화면 하나가 막혀서 못 받는다면 그건 단순한 불친절이 아니라 행정의 실패다. 그래서 공공 사이트의 접근성은 ‘배려’라는 부드러운 말보다 ‘책임’이라는 무거운 말이 더 어울린다. 우리가 만든 화면이 누군가의 권리를 가로막을 수 있다는 무게를 안고 일해야 한다는 뜻이다.

또 하나, 접근성을 잘 챙기면 ‘민원이 줄어든다’는 현실적 이점도 있다. 화면이 막혀 신청을 못 한 사람은 전화로, 방문으로 문의를 한다. 그 응대에 또 인력이 든다. 즉 접근성이 부실한 사이트는 ‘온라인으로 끝났어야 할 일’을 자꾸 오프라인으로 끌어내려, 결국 행정의 일을 늘린다. 반대로 접근성이 좋은 사이트는 ‘누구나 온라인에서 스스로 처리’하게 만들어 행정 부담을 줄인다. 접근성은 시민을 위한 일인 동시에, 일하는 공무원 자신을 위한 일이기도 하다. 이건 결코 ‘비용만 드는 착한 일’이 아니다.

오늘 다룰 다섯 가지는 KWCAG 33항목 전체가 아니라, 그중에서도 ‘가장 자주, 가장 크게 틀리는’ 핵심만 골랐다. 대체 텍스트, 키보드 접근, 색 대비, 폼 라벨, 제목과 구조 — 이 다섯이다. 점검을 해보면 거의 모든 사이트가 이 다섯 중 최소 두세 개는 틀린다. 그리고 다행히도, 이 다섯은 ‘알면 막을 수 있는’ 종류의 실수다. 대단한 기술이나 큰 예산이 필요한 게 아니라, ‘이걸 챙겨야 한다’는 사실 자체를 아느냐 모르느냐의 차이가 결과를 가른다. 그래서 오늘 글의 진짜 가치는 ‘아는 것’에 있다. 끝까지 읽고 나면 적어도 ‘우리 사이트에서 이 다섯 개부터 점검해 봐야겠다’는 체크리스트 하나가 손에 남을 거다.

왜 하필 이 다섯을 골랐는지도 잠깐 짚고 싶다. 접근성 점검을 오래 하다 보면, 33개 항목이 ‘다 똑같이 자주 틀리는’ 게 아니라는 걸 알게 된다. 어떤 항목은 거의 모든 사이트가 잘 지키고, 어떤 항목은 거의 모든 사이트가 어긴다. 그리고 ‘거의 모든 사이트가 어기는’ 항목들이 공교롭게도 사용자에게 미치는 타격이 가장 크다. 빈도도 높고 피해도 큰 항목들 — 그게 오늘의 다섯이다. 다시 말해 ‘적은 노력으로 가장 큰 개선을 얻을 수 있는’ 지점만 추린 거다. 접근성을 처음 손대는 기관이라면, 33개를 동시에 붙잡고 씨름하기보다 이 다섯부터 잡는 게 현실적이다. 가장 아픈 곳, 가장 흔한 곳부터 막는 게 순서다.

그리고 한 가지 마음가짐을 미리 부탁하고 싶다. 접근성을 ‘점수 따기 게임’으로만 보지 말자는 거다. 물론 점검 점수는 중요하고, 오늘 글도 ‘점수로 보이게 만들자’는 이야기를 한다. 하지만 그 점수 뒤에는 늘 ‘진짜 사람’이 있다. 대체 텍스트가 없어서 공지를 못 들은 시각장애 어르신, 키보드 함정에 걸려 신청을 포기한 지체장애 청년, 회색 글자를 못 읽고 그냥 떠난 노안의 민원인 — 이들은 통계의 한 줄이 아니라, 우리 행정이 마땅히 닿아야 할 시민이다. 점수를 올리는 일이 곧 ‘이 시민들에게 서비스가 가닿게 하는 일’이라는 걸 잊지 않았으면 한다. 그래야 접근성 작업이 ‘귀찮은 숙제’가 아니라 ‘마땅한 책임’으로 느껴진다.

마지막으로 미리 일러둘 것 하나. 아래 사례들은 전부 익명이다. ○○시, A광역지자체, 한중앙부처, B공공기관, C기관 같은 가상의 이름으로 표현했다. 특정 기관을 흉보려는 게 절대 아니고, 어디서나 반복되는 ‘전형’을 보여주려는 거다. 실제로 이 패턴들은 규모가 크든 작든, 예산이 많든 적든 놀랄 만큼 비슷하게 나타난다. 그러니 ‘우리 얘기 같은데’ 싶어도 그건 당신 기관만의 문제가 아니라 거의 모두가 겪는 일이라는 뜻이다. 자, 이제 하나씩 들여다보자.

본론 1 — 실수 ①: 대체 텍스트(alt) 없는 이미지

■ ‘이미지 안의 정보’가 통째로 사라지는 순간

가장 흔하고, 가장 크게 손해 보는 실수가 이것이다. 이미지에 대체 텍스트(흔히 alt 텍스트라 부른다)가 없는 경우다.

대체 텍스트가 뭔지부터 짚자. 웹페이지에 이미지를 넣을 때, 그 이미지가 ‘무엇을 담고 있는지’를 글로 적어두는 게 대체 텍스트다. 눈으로 보는 사용자에게는 이 글이 보이지 않는다. 그런데 화면을 못 보는 사용자가 화면 낭독기로 페이지를 들을 때, 낭독기는 이 대체 텍스트를 읽어준다. 즉 대체 텍스트는 ‘이미지를 듣는 사용자에게 그림을 설명해 주는 목소리’다. 이게 없으면 낭독기는 그 자리에서 “이미지”라고만 말하거나, 더 심하면 파일 이름을 그대로 읽어버린다. 사용자는 “이미지, 이미지, 이미지”만 듣다가, 혹은 “디에스시공공일사일이점제이피지”라는 외계어를 듣다가 무슨 정보인지 전혀 알 수 없게 된다.

한 광역지자체(A광역지자체라 하자) 사이트를 점검한 적이 있다. 메인 화면 한가운데에 큼직한 배너가 걸려 있었다. ‘청년 월세 지원 신청, 8월 31일 마감’ 같은 핵심 공지가 담긴 배너였다. 그런데 이 배너가 통째로 ‘글자 없는 이미지’ 한 장으로 만들어져 있었고, 대체 텍스트가 비어 있었다. 눈으로 보는 사람에게는 더없이 잘 보이는 공지였지만, 화면 낭독기로 듣는 사용자에게는 그 자리가 그냥 ‘침묵’이었다. 가장 중요한 정보가 가장 보이는 자리에 있는데, 정작 그 정보가 ‘필요한’ 사용자 일부에게는 존재하지조차 않았던 거다.

■ 왜 이런 일이 반복될까

이게 반복되는 이유는 단순하다. 만든 사람 눈에는 멀쩡히 ‘보이기’ 때문이다. 배너에 글자가 큼지막하게 박혀 있으니 ‘정보 전달 끝났다’고 느낀다. 그 글자가 ‘이미지 안에 그려진 그림으로서의 글자’이지, ‘기계가 읽을 수 있는 텍스트’가 아니라는 걸 의식하지 못한다. 사람 눈에는 글자지만 컴퓨터에는 그냥 점들의 모음, 즉 그림일 뿐이다. 이 차이를 모르면 ‘다 보이는데 왜 접근성에서 걸리지?’ 하고 억울해한다.

또 하나의 흔한 함정은 ‘장식 이미지’와 ‘정보 이미지’를 구분하지 못하는 거다. 모든 이미지에 무조건 설명을 길게 다는 게 정답은 아니다. 페이지를 예쁘게 꾸미는 순수 장식용 이미지(배경 무늬, 구분선 같은)는 오히려 대체 텍스트를 비워서 낭독기가 건너뛰게 하는 게 맞다. 반대로 정보가 담긴 이미지(공지 배너, 도표, 안내 그림)는 그 정보를 빠짐없이 글로 옮겨야 한다. 이 둘을 거꾸로 하면 — 장식 이미지마다 “파란색 배경 이미지” 같은 쓸데없는 설명이 줄줄 읽히고, 정작 중요한 정보 배너는 비어 있는 — 최악의 조합이 된다. 실제로 점검하다 보면 이 ‘거꾸로 된’ 사이트가 의외로 많다.

■ 가장 까다로운 건 ‘도표와 인포그래픽’

대체 텍스트가 정말 어려워지는 건 도표나 인포그래픽 앞에서다. 한중앙부처(가상) 사이트에서 본 사례인데, 연도별 예산 집행 현황을 보여주는 막대그래프 이미지가 있었다. 눈으로 보면 한눈에 ‘올해 예산이 작년보다 늘었구나’가 들어온다. 그런데 대체 텍스트는 “예산 그래프”라고만 적혀 있었다. 화면을 못 보는 사용자에게 ‘예산 그래프’라는 다섯 글자는 사실상 아무 정보도 아니다. 그래프가 보여주려던 ‘추세’와 ‘숫자’가 통째로 증발한 거다.

이런 경우 정답은 ‘그래프가 전달하려는 핵심을 글로 풀어주는’ 것이다. 예컨대 “연도별 예산 집행 현황: 재작년 대비 작년 5% 증가, 올해 12% 증가”처럼 추세와 핵심 수치를 적어준다. 데이터가 복잡하면 본문이나 별도 표로 같은 내용을 텍스트로 제공하고, 이미지의 대체 텍스트에서는 “자세한 수치는 아래 표 참조” 식으로 안내하는 방법도 있다. 핵심은 ‘이미지를 못 봐도 같은 정보를 얻을 수 있는 길을 만들어 두는 것’이다.

■ 이게 왜 ‘손해’로 직결되는가

대체 텍스트는 접근성만의 문제가 아니라는 점도 알아두면 좋다. 검색 엔진도 이미지를 ‘볼’ 수는 없어서, 대체 텍스트를 읽어 그 이미지가 무엇인지 파악한다. 즉 대체 텍스트가 잘 달린 사이트는 검색 노출에도 유리하다. 접근성을 챙겼더니 검색까지 좋아지는, 일석이조의 영역이다. 반대로 대체 텍스트가 텅 빈 사이트는 ‘접근성도 잃고 검색 노출도 잃는’ 이중 손해를 본다.

대체 텍스트를 잘 쓰는 요령도 몇 가지 일러두고 싶다. 첫째, ‘길이는 내용에 맞게’다. 단순한 아이콘 하나에 장문의 설명을 다는 건 오히려 방해가 되고, 복잡한 안내 그림에 ‘그림’ 한 단어만 다는 건 정보 누락이다. 그 이미지가 ‘눈으로 보는 사람에게 주는 정보의 양’만큼만 글로 옮기면 된다. 둘째, ‘맥락을 고려한다’다. 같은 사진이라도 어떤 페이지에서는 ‘분위기를 전하는 장식’이고, 어떤 페이지에서는 ‘핵심 증거 자료’일 수 있다. 그래서 대체 텍스트는 ‘이 이미지가 이 위치에서 무슨 역할을 하는가’를 기준으로 써야 한다. 셋째, ‘중복을 피한다’다. 바로 옆 본문에 이미 같은 내용이 글로 적혀 있다면, 이미지의 대체 텍스트에서 그걸 그대로 반복할 필요는 없다. 사용자가 같은 말을 두 번 듣게 만들지 않는 배려다.

그리고 흔히 놓치는 ‘링크가 걸린 이미지’ 이야기도 해야겠다. 메뉴나 버튼이 글자가 아니라 이미지로만 만들어진 경우, 그 이미지의 대체 텍스트가 없으면 화면 낭독기 사용자는 ‘이 링크가 어디로 가는 링크인지’ 전혀 알 수 없다. 로고를 누르면 첫 화면으로 가는 게 보통인데, 로고 이미지에 대체 텍스트가 없으면 낭독기는 그냥 “링크”라고만 읽는다. 사용자는 ‘어디로 가는 링크인지 모를’ 링크 앞에서 멈칫한다. 이미지가 ‘기능’까지 겸하고 있을 때는 대체 텍스트가 ‘이게 무슨 그림인가’를 넘어 ‘이걸 누르면 무슨 일이 일어나는가’까지 담아야 한다. 예컨대 검색 버튼 모양의 돋보기 아이콘에는 ‘돋보기 그림’이 아니라 ‘검색’이라고 적는 게 맞다.

정리하면, 대체 텍스트 실수는 ‘가장 흔하지만 가장 고치기 쉬운’ 실수다. 새로 개발할 게 있는 것도 아니고, 이미 있는 이미지에 ‘이 그림이 무슨 정보를 담고 있는가’를 한 줄씩 적어주면 된다. 다만 그 한 줄을 ‘제대로’ 적는 게 핵심이다. 파일 이름도 아니고, “이미지”도 아니고, 그 이미지가 사용자에게 전하려던 ‘진짜 내용’을 적어야 한다. 이것만 챙겨도 접근성 점수에서 큰 구멍 하나가 메워진다. 그리고 솔직히, 이 작은 습관 하나가 몸에 배면 그다음부터는 거의 자동으로 챙겨진다. 새 이미지를 올릴 때마다 ‘이거 못 보는 사람에겐 뭐라고 들릴까’를 한 번 떠올리는 것, 그 한 번의 떠올림이 사이트 전체의 접근성을 바꾼다.

본론 2 — 실수 ②: 키보드만으로는 못 쓰는 사이트

■ 마우스를 뺏어보면 비로소 보인다

두 번째 실수는 ‘키보드만으로는 사이트를 쓸 수 없는’ 경우다. 이건 만든 사람이 가장 놓치기 쉬운 동시에, 가장 치명적인 실수다.

세상에는 마우스를 못 쓰거나 안 쓰는 사용자가 생각보다 많다. 손을 정밀하게 움직이기 어려운 지체장애 사용자, 화면 낭독기로 사이트를 듣는 시각장애 사용자(이들은 키보드의 탭 키로 화면을 이동한다), 손목 부상으로 일시적으로 마우스를 못 쓰는 사용자, 그리고 단순히 키보드가 빠르다고 느끼는 파워 유저까지. 이 모든 사용자에게 ‘키보드로 접근 가능한가’는 곧 ‘이 사이트를 쓸 수 있느냐 없느냐’의 문제다.

테스트는 의외로 간단하다. 지금 당신 기관 사이트를 열고, 마우스에서 손을 떼라. 그리고 키보드의 탭(Tab) 키만 눌러서 메뉴, 검색창, 신청 버튼까지 이동해 보라. 엔터로 눌러보고, 화살표로 메뉴를 펼쳐보라. 이 단순한 테스트를 통과하지 못하는 공공 사이트가 정말 많다. 탭을 눌러도 초점이 엉뚱한 데로 튀거나, 아예 특정 메뉴로는 도달하지 못하거나, 펼침 메뉴가 키보드로는 절대 열리지 않는다.

■ B공공기관에서 본 ‘갇혀버린 신청서’

기억에 남는 사례 하나. B공공기관(가상) 사이트의 온라인 신청 폼이었다. 마우스로는 멀쩡히 작동했다. 그런데 키보드 탭으로 항목을 하나씩 넘어가다가, 중간의 한 입력칸에서 초점이 ‘갇혀’ 버렸다. 탭을 아무리 눌러도 다음 칸으로 넘어가지 않고 같은 자리만 맴돌았다. 마우스를 쓸 수 없는 사용자라면, 그 신청서는 거기서 끝이다. 아무리 신청하고 싶어도 그 칸을 넘어갈 방법이 없으니, 서비스 자체를 이용할 수 없는 거다.

이런 ‘키보드 함정(keyboard trap)’은 보통 화려한 외부 위젯이나 직접 만든 특수 입력 요소에서 생긴다. 날짜를 고르는 달력, 자동완성이 붙은 검색창, 팝업 형태의 약관 동의창 — 이런 ‘평범한 입력칸이 아닌’ 요소들이 키보드 처리를 제대로 안 해두면 함정이 된다. 만든 사람은 마우스로만 테스트하니 끝까지 모른다. 마우스로는 모든 게 매끄럽게 작동하니까.

■ ‘지금 어디에 있는지’ 보여주는 신호: 포커스

키보드 접근에서 또 하나 핵심은 ‘포커스 표시’다. 키보드로 화면을 이동하면, 지금 초점이 어느 요소에 가 있는지가 눈에 보여야 한다. 보통 선택된 요소 둘레에 테두리(아웃라인)가 생기는 식이다. 이걸 ‘포커스 링’이라고 부른다. 그런데 디자인을 ‘깔끔하게’ 한다며 이 포커스 표시를 일부러 없애버리는 경우가 많다. 보기에 거슬린다는 이유다.

포커스 표시를 없애면 어떻게 될까. 키보드 사용자는 ‘지금 내가 화면의 어디에 있는지’를 알 수 없게 된다. 마치 불 꺼진 방에서 손으로 더듬는 것과 같다. 탭을 눌러 이동은 되는데, 어디로 이동했는지 안 보이니 엔터를 눌러도 무엇이 눌릴지 알 수가 없다. ‘깔끔함’을 위해 포커스를 지운 대가가, 어떤 사용자에게는 ‘사이트를 통째로 쓸 수 없게 되는’ 결과로 돌아온다. 미관과 접근성이 충돌하는 것처럼 보이지만, 사실 잘 설계된 포커스 표시는 충분히 보기 좋게 만들 수 있다. ‘없애는 것’이 아니라 ‘예쁘게 보이게 만드는 것’이 정답이다.

■ 순서도 중요하다

키보드 접근에는 ‘이동 순서’라는 숨은 함정도 있다. 탭을 눌렀을 때 초점이 이동하는 순서가, 화면에 보이는 순서와 따로 놀면 사용자는 혼란에 빠진다. 위에서 아래로, 왼쪽에서 오른쪽으로 자연스럽게 흐르는 게 정상인데, 화면 배치를 복잡하게 짠 사이트에서는 초점이 위로 갔다가 아래로 튀고, 오른쪽 끝으로 갔다가 다시 왼쪽으로 돌아오는 식으로 제멋대로 움직인다. 눈으로 보는 사람은 마우스로 원하는 곳을 바로 클릭하니 이 문제를 못 느낀다. 키보드 사용자만 어지러운 순서를 그대로 따라가야 한다.

■ 팝업과 모달의 함정

키보드 접근에서 의외로 자주 터지는 곳이 ‘팝업창(모달)’이다. 약관 동의창, 알림창, 이미지 확대창처럼 화면 위에 겹쳐 뜨는 창들 말이다. 이 창이 뜰 때 ‘초점’이 그 창 안으로 옮겨가야 하고, 창이 떠 있는 동안에는 초점이 그 창 안에만 머물러야 하며, 창을 닫으면 원래 있던 자리로 초점이 돌아와야 한다. 이 세 가지가 안 지켜지면 키보드 사용자는 길을 잃는다. 흔한 실수는 팝업이 떴는데 초점은 여전히 뒤쪽 본문에 남아 있는 경우다. 화면에는 팝업이 큼지막하게 떠 있는데, 탭을 누르면 엉뚱하게 팝업 뒤에 가려진 본문 요소들로 초점이 이동한다. 눈으로 보는 사람은 팝업을 보고 있는데 키보드 초점은 보이지 않는 뒤편을 헤매는, 완전히 어긋난 상황이 벌어진다. 또 팝업을 ‘ESC 키로 닫을 수 없는’ 경우도 많다. 마우스로는 닫기 버튼을 누르면 되지만, 키보드 사용자에게는 ESC가 가장 직관적인 닫기 수단인데 그게 막혀 있으면 답답하다.

■ 작은 테스트, 큰 발견

다시 한번 강조하지만, 키보드 접근성은 ‘테스트가 쉽다’는 게 큰 장점이다. 특별한 도구도, 전문 지식도 필요 없다. 그냥 마우스에서 손을 떼고 탭 키와 엔터 키, 화살표 키, ESC 키만으로 사이트의 주요 흐름을 처음부터 끝까지 해보면 된다. 메인 화면에서 메뉴를 펼치고, 검색을 하고, 신청 폼을 채우고, 제출까지 가보라. 이 ‘5분 테스트’만 해봐도 자기 사이트의 키보드 문제 절반은 바로 드러난다. 그리고 이 테스트의 좋은 점은, 한 번 해보면 ‘아 키보드 사용자는 이렇게 답답하구나’가 몸으로 느껴진다는 거다. 머리로 아는 것과 몸으로 겪는 건 다르다. 직접 갇혀보고, 직접 길을 잃어봐야 ‘이걸 꼭 고쳐야겠다’는 절박함이 생긴다.

키보드 접근성은 결국 ‘마우스라는 편리한 도구 하나를 빼앗겼을 때도 모든 걸 할 수 있는가’를 묻는 질문이다. 그리고 이 질문에 ‘예’라고 답할 수 있는 사이트는 놀랍게도 모두에게 더 견고하다. 마우스가 고장 난 사용자, 트랙패드가 불편한 사용자, 음성으로 조작하는 사용자에게도 키보드로 잘 짜인 사이트는 더 잘 작동한다. 접근성을 챙기면 ‘특정 소수’만 좋아지는 게 아니라 사이트 전체의 기본기가 단단해진다. 키보드 테스트가 그걸 가장 잘 보여준다.

본론 3 — 실수 ③: 색 대비가 모자란 글자

■ ‘예쁜데 안 읽히는’ 화면의 정체

세 번째 실수는 색 대비, 정확히는 ‘배경과 글자의 색 대비가 모자라서 글이 잘 안 읽히는’ 경우다. 이건 디자인을 ‘세련되게’ 하려다 자주 빠지는 함정이다.

요즘 유행하는 디자인을 보면 회색 톤이 많다. 흰 배경에 연한 회색 글자, 파스텔 배경에 비슷한 톤의 글자, 사진 위에 흐릿하게 얹은 흰 글자 — 분명히 ‘있어 보이는’ 화면이다. 그런데 이 ‘은은함’이 누군가에게는 ‘안 보임’이 된다. 시력이 약한 어르신, 색각이 다른 사용자, 그리고 의외로 ‘밝은 야외에서 휴대폰을 보는 멀쩡한 시력의 사용자’에게도 연한 회색 글자는 거의 안 읽힌다.

색 대비에는 명확한 기준 수치가 있다. 배경색과 글자색의 밝기 차이를 ‘대비비(contrast ratio)’라는 값으로 계산하는데, 본문 같은 일반 텍스트는 이 값이 일정 기준(통상 4.5 대 1) 이상이어야 하고, 큰 글자는 조금 완화된 기준(3 대 1)을 적용한다. 숫자가 어렵게 들리겠지만 핵심은 단순하다 — ‘배경과 글자가 충분히 차이 나야 누구나 읽을 수 있다’는 거다. 연한 회색 글자가 멋있어 보여도, 그게 기준 미달이면 ‘일부 사용자는 읽지 말라’는 것과 같다.

■ C기관의 ‘회색 안내문’

C기관(가상) 사이트에서 본 장면. 중요한 안내 문구가 연한 회색으로 적혀 있었다. 디자인적으로는 ‘부드럽고 차분한’ 느낌이었다. 그런데 그 회색이 흰 배경과 대비가 너무 약해서, 화면을 조금만 밝은 곳에서 보면 글자가 배경에 묻혀 보였다. 더 아이러니한 건, 그 묻힌 글자가 ‘개인정보 처리 관련 중요 안내’였다는 점이다. 가장 잘 읽혀야 할 정보를 가장 안 읽히는 색으로 적어둔 셈이다.

이런 일이 생기는 건, 만든 사람의 환경이 ‘최상의 조건’이기 때문이다. 디자이너는 보통 좋은 모니터를, 적당한 실내 조명에서, 정상 시력으로 본다. 그 조건에서는 연한 회색도 충분히 읽힌다. 하지만 실제 사용자는 깨진 액정으로, 햇빛 쨍한 버스 정류장에서, 노안이 온 눈으로 본다. ‘내 환경에서 읽히니까 괜찮다’는 판단이 가장 위험하다. 색 대비는 ‘가장 안 좋은 조건의 사용자’를 기준으로 잡아야 한다.

■ 색‘만’으로 정보를 구분하는 함정

색 대비와 짝을 이루는 또 하나의 실수가 ‘색만으로 정보를 구분하는’ 거다. 예를 들어 표에서 ‘빨간 글씨는 마감, 검은 글씨는 진행 중’이라고만 표시하면, 색을 구분하기 어려운 사용자는 둘을 구별할 수 없다. ‘필수 입력 항목은 빨간색’이라고만 표시한 폼도 마찬가지다. 색맹·색약 사용자에게 그 빨간색은 그냥 평범한 글자다.

해법은 ‘색에 더해 다른 단서를 함께 주는’ 거다. 마감 항목에는 색뿐 아니라 ‘[마감]’이라는 글자나 아이콘을 붙이고, 필수 항목에는 빨간색뿐 아니라 별표(*)나 ‘필수’라는 글자를 붙인다. 색은 어디까지나 ‘보조 신호’여야지, ‘유일한 신호’가 되면 안 된다. 이걸 ‘색에 의존하지 않기’ 원칙이라고 한다.

■ 자동 검사가 가장 빛나는 영역

색 대비는 사람이 눈대중으로 판단하기 가장 어려운 영역이다. ‘이 정도면 읽히겠지’라는 감은 사람마다 다르고, 같은 사람도 그날 컨디션에 따라 다르다. 그래서 색 대비야말로 ‘자동 검사’가 가장 정확하고 빠르게 잡아주는 영역이다. 배경색과 글자색을 읽어 대비비를 계산하고, 기준 미달인 조합을 콕 집어준다. 사람이 수백 군데를 일일이 들여다볼 필요 없이, 기계가 한 번에 ‘여기 12군데가 대비 미달입니다’라고 알려주는 거다.

■ ‘비활성’과 ‘약한 회색’의 경계

색 대비에서 한 가지 헷갈리는 지점이 ‘일부러 흐리게 한 요소’다. 비활성 상태의 버튼이나, 보조적인 부가 설명은 ‘덜 중요하다’는 뜻으로 흐리게 처리하는 경우가 있다. 이런 의도적 흐림은 어느 정도 용인된다. 하지만 문제는 ‘진짜로 읽어야 할 본문’까지 그런 흐린 톤으로 칠해버리는 거다. 디자인 트렌드를 따라 ‘전체적으로 은은하게’ 만들다 보면, 정작 사용자가 꼭 읽어야 할 안내문이 ‘덜 중요한 부가 설명’과 같은 톤이 돼버린다. 중요도의 위계를 색의 진하기로 표현하는 건 좋지만, 그 위계의 ‘가장 옅은 단계’조차 읽을 수 있는 최소 대비는 넘겨야 한다. 흐리게 하더라도 ‘안 보일 만큼’ 흐리게는 하지 말라는 거다.

■ 다크 모드와 이미지 위 글자

요즘은 어두운 배경의 ‘다크 모드’를 지원하는 사이트도 늘었다. 그런데 밝은 모드에서 대비를 잘 맞춰놨어도, 다크 모드로 바꾸면 대비가 깨지는 경우가 있다. 색을 단순히 ‘반전’만 시키면 어떤 조합은 오히려 대비가 더 나빠진다. 그래서 다크 모드를 지원한다면 그 모드에서도 따로 대비를 점검해야 한다. 또 하나 까다로운 건 ‘이미지나 사진 위에 얹은 글자’다. 배경 사진이 밝은 부분과 어두운 부분이 섞여 있으면, 같은 흰 글자라도 어떤 위치에서는 잘 읽히고 어떤 위치에서는 묻힌다. 이럴 때는 글자 뒤에 반투명한 어두운 막을 깔아 배경을 일정하게 눌러주거나, 글자에 외곽선·그림자를 줘서 어떤 배경 위에서도 읽히게 만드는 처리가 필요하다. ‘예쁜 배경 사진 위의 글자’는 십중팔구 대비 점검에서 걸리는 단골이다.

색 대비 실수는 그래서 ‘발견만 하면 고치기 쉬운’ 실수다. 어디가 미달인지만 알면, 글자색을 한두 단계 진하게 하거나 배경을 조정하면 끝난다. 문제는 ‘어디가 미달인지 모른다’는 거였는데, 그건 자동 검사가 해결해 준다. 색 대비는 미관과 가독성 사이에서 균형을 잡는 일이지만, 그 균형의 기준선만큼은 ‘감’이 아니라 ‘수치’로 잡아야 한다는 걸 기억하자. 디자이너의 ‘예쁘다’는 감각과 사용자의 ‘읽힌다’는 현실 사이에, 대비비라는 객관적 다리를 놓는 것 — 그게 색 대비 점검의 본질이다.

본론 4 — 실수 ④: 라벨 없는 입력칸과 부실한 폼

■ 공공 사이트의 심장, 그러나 가장 자주 막히는 곳

네 번째 실수는 폼(입력 양식)에서 나온다. 그리고 이건 공공 사이트에서 특히 뼈아픈 실수다. 왜냐하면 공공 사이트의 존재 이유 대부분이 ‘신청·접수·민원’ 같은 ‘입력을 받는’ 일이기 때문이다. 폼이 막히면 서비스 자체가 막힌다.

가장 흔한 실수는 ‘입력칸에 라벨이 없는’ 거다. 라벨이란 그 입력칸이 ‘무엇을 적는 칸인지’ 알려주는 이름표다. 이름을 적는 칸이면 ‘이름’, 전화번호를 적는 칸이면 ‘전화번호’ 같은 식이다. 눈으로 보는 사용자는 칸 옆이나 위의 글자를 보고 ‘아 여기는 이름 적는 곳이구나’ 안다. 그런데 이 라벨이 ‘기계가 인식할 수 있는 형태로’ 연결돼 있지 않으면, 화면 낭독기 사용자는 그 칸이 무슨 칸인지 알 수 없다. 낭독기는 그냥 “입력란, 편집 가능”이라고만 읽어준다. 무엇을 입력하라는 건지 알 수 없는 칸 앞에서 사용자는 멈춘다.

특히 함정인 게 ‘플레이스홀더(placeholder)’만으로 라벨을 대신하는 경우다. 입력칸 안에 흐릿한 글자로 ‘이름을 입력하세요’라고 적어두는 그것 말이다. 보기엔 깔끔하다. 라벨을 따로 안 두고 칸 안에 안내문을 넣으니 공간도 아낀다. 그런데 이 플레이스홀더는 사용자가 글자를 입력하기 시작하면 사라진다. 그래서 입력 도중에 ‘내가 지금 뭘 적는 칸이었지?’ 헷갈려도 확인할 길이 없다. 게다가 플레이스홀더는 보통 연한 회색이라 색 대비도 미달이고, 화면 낭독기가 제대로 못 읽는 경우도 많다. 한 마디로 ‘라벨 대신 플레이스홀더’는 접근성에서 거의 실수의 종합 선물 세트다.

■ ○○시의 ‘무엇이 틀렸는지 안 알려주는 신청서’

○○시(가상) 사이트의 한 신청 폼을 점검했을 때 일이다. 항목을 채우고 ‘제출’을 눌렀더니 페이지 어딘가가 살짝 바뀌면서 제출이 안 됐다. 무엇이 잘못됐는지는 알려주지 않았다. 알고 보니 전화번호 형식이 안 맞았던 건데, 그 오류 메시지가 화면 한참 위에 작게 떴고, 색으로만(빨간 테두리) 표시됐으며, 화면 낭독기에는 그 오류가 ‘읽히지’ 않았다. 눈으로 보는 사용자도 ‘뭐가 틀렸지?’ 하고 한참 헤맸고, 낭독기 사용자는 아예 ‘제출이 왜 안 되는지’조차 알 수 없었다.

폼에서 ‘오류 안내’는 정말 중요하다. 사람은 입력하다 실수하기 마련이고, 좋은 폼은 그 실수를 ‘친절하게’ 알려준다. ‘어느 칸이’ ‘왜’ 잘못됐는지를 그 칸 바로 옆에, 글자로, 그리고 화면 낭독기도 읽을 수 있는 방식으로 알려줘야 한다. ‘전화번호는 숫자만 입력하세요’처럼 구체적으로. 그냥 빨간 테두리만 그려놓고 ‘알아서 찾아라’ 하면, 그건 사용자를 미로에 가두는 거다.

■ 묶음의 문제: 라디오 버튼과 체크박스

폼에는 ‘묶음’의 문제도 있다. 성별을 고르는 라디오 버튼, 약관에 동의하는 체크박스처럼 ‘여러 선택지가 한 질문에 묶이는’ 경우다. 이때 ‘이 선택지들이 무슨 질문에 대한 것인지’를 기계가 알 수 있게 묶어줘야 한다. 그렇지 않으면 화면 낭독기 사용자는 ‘남성, 라디오 버튼’ ‘여성, 라디오 버튼’이라는 선택지만 듣고, 정작 ‘이게 성별을 묻는 질문’이라는 맥락은 듣지 못한다. 선택지는 들리는데 질문이 안 들리니, 무엇을 고르는 건지 알 수 없다.

■ 폼은 ‘완주율’의 문제

폼 접근성은 결국 ‘사용자가 끝까지 입력을 마칠 수 있느냐’의 문제다. 공공 서비스에서 신청 폼을 중간에 포기하게 만드는 건, 단순히 ‘불편’이 아니라 ‘서비스를 못 받게 막는’ 결과를 낳는다. 청년 지원금을 신청하려던 사람이 폼이 막혀 포기하면, 그 사람은 받을 자격이 있었는데도 못 받는다. 접근성이 부실한 폼은 ‘자격이 있는 사람의 권리’를 행정의 부주의로 가로막는 셈이다.

■ ‘필수’ 표시와 입력 형식 안내

폼에서 또 자주 보는 실수가 ‘필수 항목 표시’의 부실함이다. 어떤 칸이 꼭 채워야 하는 칸이고 어떤 칸이 선택인지를 사용자가 미리 알아야 하는데, 이걸 색으로만(빨간 별표) 표시하거나 아예 표시하지 않는 경우가 많다. 그러면 사용자는 다 채웠다고 생각하고 제출했다가 ‘필수 항목 누락’ 오류를 만나고, 어디가 빠졌는지 찾느라 헤맨다. 필수 항목은 ‘별표’ 같은 기호와 함께 ‘필수’라는 글자로도 명시하고, 그게 화면 낭독기에도 ‘이 칸은 필수입니다’라고 전달되게 해야 한다. 입력 형식 안내도 마찬가지다. 전화번호를 하이픈 없이 적어야 하는지, 날짜를 어떤 순서로 적어야 하는지 같은 건 ‘틀린 다음에 혼내는’ 게 아니라 ‘틀리기 전에 알려주는’ 게 좋은 폼이다. 칸 옆에 ‘예: 숫자만 입력’ 같은 안내를 미리 두면 오류 자체가 줄어든다.

■ 시간 제한이라는 또 다른 벽

공공 폼에는 보안을 이유로 ‘일정 시간 안에 입력을 마쳐야 하는’ 시간 제한이 걸린 경우가 많다. 그런데 이 시간 제한이 너무 짧으면 접근성에 큰 벽이 된다. 화면 낭독기로 한 항목씩 들으며 천천히 입력하는 사용자, 손을 천천히 움직이는 사용자, 키보드로 또박또박 채우는 사용자는 비장애인보다 시간이 더 걸린다. 그런데 제한 시간이 짧으면, 거의 다 채운 폼이 시간 초과로 통째로 날아간다. 처음부터 다시 입력해야 하니 좌절감이 크다. 시간 제한이 꼭 필요하다면, 최소한 ‘시간이 곧 끝난다’는 경고를 미리 주고, ‘시간을 연장할 수 있는’ 선택지를 함께 제공해야 한다. 보안과 접근성이 충돌하는 듯 보이지만, 조금만 배려하면 둘 다 챙길 수 있다.

그리고 폼 접근성을 챙기면 ‘모든 사용자’의 완주율이 함께 올라간다. 라벨이 명확하고, 오류 안내가 친절하고, 묶음이 잘된 폼은 비장애인에게도 더 쉽다. 어르신도, 급하게 모바일로 신청하는 사람도, 처음 그 서비스를 쓰는 사람도 덜 헤맨다. 접근성 좋은 폼은 곧 ‘완성도 높은 폼’이고, 완성도 높은 폼은 모두의 신청을 더 매끄럽게 만든다. 폼 하나 잘 고치는 게 민원 감소로, 신청 완료율 상승으로, 결국 ‘서비스가 제대로 가닿는’ 결과로 이어진다. 공공 사이트에서 폼은 ‘마지막 한 걸음’이다. 사용자가 정보를 찾고 마음을 먹고 여기까지 왔는데, 마지막 폼에서 막혀 돌아선다면 그동안의 모든 게 헛수고가 된다. 그래서 폼은 가장 정성 들여 챙겨야 할 곳이다.

본론 5 — 실수 ⑤: 제목과 구조가 없는 페이지

■ ‘목차 없는 책’ 같은 화면

다섯 번째 실수는 조금 추상적으로 들리지만, 알고 나면 가장 강력한 무기가 되는 영역이다. 바로 ‘제목과 구조’다. 페이지의 내용이 제목(헤딩)으로 잘 나뉘어 있고, 그 제목들이 올바른 위계로 정리돼 있느냐는 문제다.

웹페이지에는 ‘제목’을 나타내는 단계가 있다. 가장 큰 제목(H1)부터 그 아래 중제목(H2), 소제목(H3)으로 이어지는 위계다. 이걸 책에 비유하면 H1은 책 제목, H2는 장 제목, H3은 절 제목쯤 된다. 이 위계가 잘 잡혀 있으면, 화면 낭독기 사용자는 ‘제목만 빠르게 훑어서’ 페이지의 구조를 파악하고 원하는 곳으로 바로 건너뛸 수 있다. 마치 눈으로 보는 사람이 페이지를 위에서 아래로 스윽 스캔하며 ‘아 여기 신청 방법이 있네’ 하고 찾는 것처럼.

그런데 많은 공공 사이트가 이 제목 구조를 ‘모양’으로만 만들고 ‘구조’로는 안 만든다. 무슨 뜻이냐면, 글자를 크고 굵게 만들어서 ‘보기에는 제목처럼’ 보이게 했지만, 기계가 읽을 때 ‘이건 제목이다’라고 인식할 수 있는 형태로는 안 만들어둔 거다. 눈으로 보는 사람에게는 똑같이 제목처럼 보이지만, 화면 낭독기에는 그냥 ‘크고 굵은 평범한 글자’일 뿐이다. 그러면 낭독기 사용자는 ‘제목으로 건너뛰기’ 기능을 쓸 수 없게 되고, 페이지를 처음부터 끝까지 순서대로 다 들어야 원하는 정보에 도달한다. 목차 없는 두꺼운 책을 처음부터 다 읽어야 원하는 챕터를 찾는 것과 같다.

■ 한중앙부처의 ‘평평한 페이지’

다시 한중앙부처(가상) 사례. 정책 안내 페이지였는데, 내용은 풍부했다. 사업 개요, 신청 자격, 신청 방법, 문의처가 다 들어 있었다. 문제는 이 네 덩어리가 ‘제목 구조’ 없이 그냥 평평하게 나열돼 있었다는 거다. 눈으로 보는 사람은 글자 크기 차이로 어렴풋이 구분했지만, 화면 낭독기 사용자에게는 그냥 ‘끝없는 글의 평지’였다. ‘신청 자격’ 부분만 빠르게 확인하고 싶어도 건너뛸 방법이 없어서, 사업 개요부터 줄줄 다 들어야 했다.

■ 구조는 ‘모두를 위한 길’

제목 구조의 좋은 점은, 접근성을 넘어 ‘모두에게’ 이롭다는 거다. 제목이 잘 잡힌 페이지는 눈으로 보는 사람에게도 한눈에 구조가 들어온다. 어디에 무슨 정보가 있는지 빠르게 파악되니 정보를 더 빨리 찾는다. 검색 엔진도 제목 구조를 읽어 ‘이 페이지가 무엇에 관한 것인지’ 더 잘 이해한다. 즉 제목 구조를 제대로 잡는 건 접근성·가독성·검색 노출을 한 번에 챙기는 일이다.

여기에 더해, 페이지 전체에 ‘영역 구분’을 명확히 해두는 것도 구조의 일부다. 머리말(헤더), 주요 메뉴(내비게이션), 본문(메인), 꼬리말(푸터) 같은 큰 덩어리를 기계가 알 수 있게 표시해 두면, 화면 낭독기 사용자는 ‘본문으로 바로 가기’ 같은 기능을 쓸 수 있다. 매번 똑같은 상단 메뉴를 처음부터 다 듣지 않고, 그날그날 달라지는 본문으로 곧장 건너뛰는 거다. 이걸 ‘건너뛰기 링크’라고도 하는데, 작은 배려 하나가 매 페이지마다 사용자의 시간을 크게 아껴준다.

■ 구조는 ‘처음부터 챙기면 공짜, 나중에 고치면 대공사’

제목 구조의 특징은, 처음 만들 때 챙기면 거의 ‘공짜’라는 거다. 글자를 그냥 크게 만드는 대신 ‘이건 제목이다’라고 제대로 표시하는 건 수고가 거의 안 든다. 그런데 이미 평평하게 만들어진 수백 페이지를 나중에 구조로 다시 짜려면 그건 대공사가 된다. 그래서 제목과 구조야말로 ‘설계 단계에서 챙기는 게 압도적으로 싼’ 영역이다. 그리고 다행히 이것도 자동 검사가 잘 잡아준다. ‘이 페이지에는 H1이 없습니다’, ‘제목 단계가 H2에서 H4로 건너뛰었습니다’ 같은 구조적 문제를 기계가 콕 집어준다.

여기서 ‘제목 단계 건너뛰기’가 왜 문제인지 한 번 더 짚자. 제목은 H1, H2, H3 순으로 차근차근 내려가야 한다. 그런데 ‘디자인상 글자 크기가 마음에 든다’는 이유로 H2 다음에 곧장 H4를 쓰는 경우가 있다. 눈으로 보는 사람에게는 그냥 글자 크기 차이일 뿐이지만, 화면 낭독기 사용자에게는 ‘중간 단계가 사라진 목차’가 된다. 책으로 치면 1장 다음에 갑자기 1장의 3절이 나오고 1절·2절이 없는 셈이다. 사용자는 ‘내가 뭘 놓쳤나’ 하고 혼란스럽다. 그래서 제목은 ‘보이는 크기’가 아니라 ‘내용의 위계’를 따라 순서대로 매겨야 한다. 크기는 나중에 따로 조절하면 되는 거고, 단계 자체는 논리를 지켜야 한다. 이건 작은 규칙 같지만, 페이지를 ‘구조로’ 이해하는 사용자에게는 길잡이 그 자체다.

■ 표(테이블)의 구조도 ‘구조’다

제목 구조와 같은 맥락에서 ‘표’ 이야기도 짧게 해야겠다. 공공 사이트에는 표가 정말 많다. 사업 일정표, 요금표, 자격 기준표, 통계표… 그런데 이 표들이 ‘보기에만 표’이고 ‘구조로는 표가 아닌’ 경우가 많다. 표에는 ‘제목 칸(머리행)’이 있어야 한다. 가로축이 무엇을 뜻하고 세로축이 무엇을 뜻하는지를 기계가 알 수 있게 표시해 둬야, 화면 낭독기 사용자가 ‘이 칸의 값은 어느 항목, 어느 시점의 값인지’를 알 수 있다. 머리행 표시가 없으면 낭독기는 표 안의 숫자들을 그냥 죽 읽어줄 뿐, 그 숫자가 ‘무엇에 대한 숫자인지’ 맥락을 주지 못한다. 표가 클수록 이 문제는 심각해진다. 또 하나, 표를 ‘칸 맞추기 용도’로만 쓰는 것도 흔한 실수다. 진짜 데이터 표가 아니라 단순히 화면 배치를 위해 표를 쓰면, 낭독기 사용자는 ‘있지도 않은 데이터 표’를 칸칸이 듣게 되어 혼란스럽다. 표는 ‘진짜 표 형태의 데이터’에만 쓰는 게 맞다.

■ 링크 글자도 구조의 일부

페이지 구조와 맞닿은 또 하나의 단골 실수가 ‘링크 글자’다. ‘여기를 클릭’, ‘자세히 보기’, ‘바로가기’ 같은 글자가 한 페이지에 수십 개씩 똑같이 박혀 있는 경우다. 눈으로 보는 사람은 그 링크 주변의 문맥을 함께 보니 ‘아 이 자세히 보기는 청년 지원 안내로 가는 거구나’ 안다. 그런데 화면 낭독기 사용자는 ‘링크만 모아서 훑어보는’ 기능을 자주 쓴다. 그러면 ‘자세히 보기, 자세히 보기, 자세히 보기…’만 줄줄 들리고, 각각이 어디로 가는 링크인지 전혀 알 수 없다. 그래서 링크 글자는 ‘그 자체로 어디로 가는지 알 수 있게’ 쓰는 게 좋다. ‘자세히 보기’ 대신 ‘청년 월세 지원 자세히 보기’처럼. 작은 차이 같지만, 링크만 따로 듣는 사용자에게는 결정적인 차이다.

지금까지 다섯 가지를 봤다. 대체 텍스트, 키보드 접근, 색 대비, 폼 라벨, 제목 구조. 이 다섯에는 공통점이 하나 있다. 모두 ‘만든 사람 눈에는 안 보이는’ 문제라는 거다. 마우스로, 좋은 모니터로, 정상 시력으로 보면 다 괜찮아 보인다. 문제는 ‘다른 조건의 사용자’에게만 나타난다. 그래서 접근성은 ‘내 눈을 믿지 말고, 다른 사용자의 처지를 상상하거나, 도구로 검사해야’ 비로소 보이는 영역이다.

본론 6 — 그래서, 사람 손으로 다 잡을 수 있을까

■ ‘점검하라’는 말의 막막함

여기까지 읽고 ‘좋아, 우리 사이트도 이 다섯 개를 점검해야겠다’고 마음먹었다고 하자. 그런데 바로 다음 벽에 부딪힌다. ‘어떻게?’

공공 사이트는 보통 페이지가 수백, 많게는 수천 개다. 부서마다, 사업마다 페이지가 쌓여 있다. 이 모든 페이지에서 대체 텍스트가 빠진 이미지를 찾고, 키보드로 막히는 곳을 확인하고, 색 대비가 미달인 글자를 골라내고, 라벨 없는 입력칸을 점검하고, 제목 구조가 무너진 페이지를 찾는다? 사람 손으로 하면 한 사이트를 점검하는 데만 몇 주가 걸린다. 그것도 ‘제대로 볼 줄 아는’ 전문가가 붙어야 한다. 대부분의 담당자는 본업만으로도 벅차다. 접근성 점검에 몇 주를 통째로 쓸 여유가 있는 기관은 거의 없다.

게다가 사람이 하면 ‘놓친다’. 수백 페이지를 일일이 눈으로 보다 보면 집중력이 떨어지고, 비슷한 화면이 반복되면 ‘아까 본 거랑 비슷하니 됐겠지’ 하고 넘어간다. 색 대비처럼 눈대중이 어려운 항목은 사람이 보면 들쭉날쭉 판단한다. 결국 ‘점검은 했는데 빠진 게 많은’ 어정쩡한 결과가 나오기 일쑤다.

■ 자동 검사가 메우는 빈틈

바로 이 지점에서 ‘자동 접근성 검사’가 진가를 발휘한다. 오늘 다룬 다섯 가지 실수는 상당 부분 ‘기계가 더 정확하고 빠르게’ 잡아낼 수 있는 종류다. 대체 텍스트가 빠진 이미지, 라벨 없는 입력칸, 색 대비 미달, 제목 구조의 누락이나 건너뜀, 키보드로 접근 불가능한 요소 — 이런 것들은 페이지의 구조를 읽어내면 기계적으로 판별이 가능하다. 사람이 며칠 걸려 찾을 걸 도구는 몇 초 만에, 그것도 빠짐없이 찾는다.

물론 자동 검사가 ‘전부’는 아니다. 솔직하게 말하면, 접근성에는 사람의 판단이 꼭 필요한 영역도 있다. 예를 들어 대체 텍스트가 ‘있긴 한데 내용이 적절한지’는 결국 사람이 봐야 한다. ‘이미지’라고만 적힌 건 기계도 걸러내지만, ‘적당히 그럴듯하지만 핵심을 놓친’ 설명은 사람이 읽어봐야 안다. 그래서 가장 좋은 방식은 ‘자동 검사로 큰 구멍을 빠르게 메우고, 남은 미묘한 부분은 사람이 보강하는’ 것이다. 자동 검사는 사람을 대체하는 게 아니라, 사람이 ‘정말 사람의 판단이 필요한 곳’에 집중할 수 있게 해주는 도구다.

■ 점수로 보면 비로소 움직인다

자동 검사의 또 다른 힘은 ‘눈에 보이는 결과’를 준다는 거다. 앞서 계속 강조했듯, 접근성 문제의 가장 큰 적은 ‘안 보임’이다. 안 보이니 심각성을 못 느끼고, 못 느끼니 우선순위에서 밀린다. 그런데 자동 검사가 ‘이 사이트는 접근성 항목 중 몇 개가 통과, 몇 개가 미통과’라고 점수로 보여주면, 그제야 ‘아 이걸 손봐야겠구나’가 피부로 와닿는다. 막연한 ‘접근성 챙겨야지’가 ‘이 12개 항목을 고치면 점수가 올라간다’는 구체적 할 일로 바뀌는 거다. 보이기 시작하면 움직이게 된다.

■ 정기적으로, 반복적으로

그리고 자동 검사의 진짜 가치는 ‘한 번’이 아니라 ‘반복’에 있다. 사이트는 살아 있는 생물 같아서, 한 번 고쳐놔도 새 페이지가 붙고 콘텐츠가 쌓이면서 접근성이 다시 망가진다. 오늘 대체 텍스트를 다 채워놨어도, 다음 주에 누군가 새 배너를 대체 텍스트 없이 올리면 거기서 또 구멍이 생긴다. 그래서 접근성은 ‘한 번 통과하고 끝’이 아니라 ‘꾸준히 점검하며 유지하는’ 일이다. 사람이 매번 수백 페이지를 다시 들여다보는 건 불가능하지만, 자동 검사는 주기적으로 돌리기만 하면 ‘이번 달에 새로 생긴 문제’를 바로바로 잡아준다. 건강검진을 정기적으로 받는 것과 같다. 한 번 검진받고 평생 안심하는 게 아니라, 주기적으로 점검해 ‘새로 생긴 문제’를 일찍 발견하는 거다. 자동 검사는 그 정기 검진을 ‘몇 분 만에, 빠짐없이’ 해주는 도구다.

■ ‘담당자 한 명’의 부담을 덜어준다

마지막으로, 자동 검사는 ‘담당자 개인의 부담’을 크게 덜어준다. 접근성 점검을 사람 손으로만 하려면, 담당자가 그 전문 지식을 다 익혀야 하고, 그 시간을 다 내야 하고, 빠뜨린 책임까지 져야 한다. 이건 한 사람이 감당하기엔 너무 큰 짐이다. 그런데 도구가 ‘무엇이 문제인지’를 객관적으로 짚어주면, 담당자는 그 결과를 근거로 윗선에 보고하고, 외주 업체에 수정을 요청하고, 개선 계획을 세울 수 있다. ‘제 느낌엔 접근성이 좀 부족한 것 같습니다’가 아니라 ‘점검 결과 33항목 중 11개가 미통과이며, 그중 우선 고쳐야 할 항목은 이것입니다’라고 말할 수 있게 되는 거다. 객관적 근거는 일을 추진하는 힘이 된다. 자동 검사는 담당자에게 그 ‘추진할 근거’를 쥐여준다.

마무리

긴 글을 여기까지 따라와 줘서 고맙다. 오늘 다룬 ‘가장 많이 틀리는 접근성 5대 실수’를 마지막으로 한 번 정리하자.

첫째, 대체 텍스트 없는 이미지. 이미지 안의 정보가 화면을 못 보는 사용자에게는 통째로 사라진다. 장식 이미지는 비우고, 정보 이미지는 그 내용을 글로 빠짐없이 옮기자.

둘째, 키보드만으로는 못 쓰는 사이트. 마우스에서 손을 떼고 탭 키로만 사이트를 끝까지 써보자. 갇히는 곳, 도달 못 하는 곳, 그리고 지금 어디 있는지 안 보이는 ‘포커스 실종’을 잡아야 한다.

셋째, 색 대비가 모자란 글자. 연한 회색이 멋있어 보여도, 기준 미달이면 누군가는 못 읽는다. 그리고 색‘만’으로 정보를 구분하지 말고 글자나 아이콘을 함께 주자.

넷째, 라벨 없는 입력칸과 부실한 폼. 공공 사이트의 심장인 신청·민원 폼이 막히면 서비스 자체가 막힌다. 라벨을 명확히, 오류 안내를 친절히, 묶음을 제대로.

다섯째, 제목과 구조가 없는 페이지. 글자를 크게만 만들지 말고 ‘제목’으로 제대로 표시해, 목차 있는 책처럼 누구나 원하는 곳으로 건너뛸 수 있게 하자.

이 다섯의 공통점을 다시 한번 강조하고 싶다. 모두 ‘만든 사람 눈에는 안 보이는’ 실수다. 그래서 선의만으로는 안 잡힌다. ‘다른 사용자의 처지를 상상하는 마음’과 ‘빠짐없이 찾아주는 도구’, 이 둘이 함께 가야 비로소 잡힌다. 접근성은 거창한 게 아니다. 누군가를 빠뜨리지 않으려는 마음을, 구체적인 점검으로 실천하는 것 — 그게 전부다. 그리고 그 점검의 첫걸음은 ‘우리 사이트가 지금 어디서 미끄러지고 있는지’를 아는 거다.

여기서 한 가지 오해를 풀고 싶다. 많은 담당자가 ‘접근성은 한 번에 완벽하게 다 고쳐야 한다’는 부담 때문에 아예 시작을 못 한다. 33항목을 다 통과시켜야 한다고 생각하면 엄두가 안 나는 거다. 그런데 접근성은 ‘0점 아니면 100점’이 아니다. 오늘 다룬 다섯 개 중 하나만 고쳐도 그만큼 더 많은 사용자가 사이트를 쓸 수 있게 된다. 대체 텍스트 하나만 채워도 시각장애 사용자에게 그 정보가 닿고, 색 대비 하나만 고쳐도 어르신이 그 안내를 읽는다. 완벽을 기다리느라 아무것도 안 하는 것보다, 오늘 하나라도 고치는 게 훨씬 낫다. ‘작게 시작해서 꾸준히 넓혀가는’ 게 접근성의 현실적인 정답이다. 그러니 부담 갖지 말고, 일단 가장 흔한 다섯 개부터 손대보자. 시작이 절반이다.

그리고 접근성을 잘 챙긴 사이트는, 결국 ‘좋은 사이트’가 된다는 걸 기억하자. 오늘 글 내내 반복해서 본 것처럼, 접근성을 위한 노력 대부분은 ‘특정 소수’만이 아니라 ‘모든 사용자’를 이롭게 한다. 명확한 라벨, 친절한 오류 안내, 또렷한 색 대비, 잘 잡힌 제목 구조, 키보드로도 매끄러운 흐름 — 이건 장애인만이 아니라 어르신도, 바쁜 직장인도, 처음 온 사용자도 모두 편하게 쓰는 사이트의 조건이다. 접근성은 ‘일부를 위한 양보’가 아니라 ‘전체의 품질을 끌어올리는 기준’이다. 그래서 접근성을 챙기는 일은 곧 사이트 전체를 더 좋게 만드는 일이다. 손해 보는 일이 아니라, 모두가 이득 보는 일이다.

바로 그 ‘아는 일’을 빠르고 정확하게 돕는 게 ViewCheck다. ViewCheck는 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역(호환성·접근성·개방성·접속성·편의성·효율성·신뢰성)과 KRDS 846규칙(디자인 시스템 DS 120 + 컴포넌트 CP 446 + 기본 패턴 BP 108 + 서비스 패턴 SP 172)을 자동으로 진단해 준다. 그중에서도 오늘 다룬 웹 접근성은 KWCAG 33항목을 기준으로 점검한다. 사람이 며칠씩 들여다봐야 할 일을, 사이트 주소 하나만 넣으면 자동으로 훑어 ‘어디가, 무엇이, 왜 미통과인지’를 점수와 함께 보여준다. 대체 텍스트 누락, 색 대비 미달, 폼 라벨 부실, 제목 구조 문제처럼 오늘 이야기한 항목들이 결과 화면에 한눈에 정리돼 나온다.

금요일 글에서는 오늘 짚은 다섯 가지 실수를 ‘실제로 어떻게 고치는지’, 그 구체적인 개선 방법과 우선순위 잡는 법을 이어서 다루려 한다. 오늘이 ‘무엇이 문제인지 아는’ 편이었다면, 금요일은 ‘그래서 어떻게 고치는지’ 편이다. 그때 또 만나자. 그전에, 오늘 배운 다섯 가지로 당신 사이트를 한 번 슥 둘러보는 것만으로도 이미 절반은 시작한 거다.

끝으로 한마디만 덧붙이고 싶다. 접근성은 결국 ‘상상력’의 문제다. 나와 다른 조건에 놓인 사람을 떠올리는 힘, 화면을 못 보는 사람이 이 페이지를 어떻게 들을지, 마우스를 못 쓰는 사람이 이 버튼에 어떻게 닿을지를 잠깐 상상하는 힘 말이다. 그 상상이 어려우면 도구의 힘을 빌리면 된다. 도구는 우리가 미처 상상하지 못한 사용자의 처지를 ‘점수와 목록’으로 대신 보여준다. 마음과 도구, 그 둘이 만나는 자리에서 ‘누구도 빠뜨리지 않는 사이트’가 만들어진다. 오늘 글이 그 자리로 가는 작은 출발점이 되었으면 좋겠다. 길었던 글, 끝까지 읽어줘서 다시 한번 고맙다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #접근성검사 #대체텍스트 #색대비 #키보드접근성 #전자정부 #공공사이트 #디지털포용 #ViewCheck