초점이 안 보이는 웹 사이트, 키보드 사용자는 길을 잃는다

반응형

초점이 안 보이는 웹 사이트, 키보드 사용자는 길을 잃는다

【 공감·문제제기 】

오늘은 좀 불편한 이야기부터 꺼내야겠다. 우리가 만든 사이트를 마우스 없이 한번 써본 적이 있는지 묻고 싶다. 마우스를 손에서 떼고, 오직 키보드의 Tab 키와 화살표, 그리고 Enter만으로 메인 화면에서 신청 완료까지 가본 적이 있는가. 솔직히 말하면, 나도 이 일을 하기 전까지는 한 번도 그렇게 써본 적이 없었다. 마우스가 늘 손에 있었으니까. 그런데 어느 날, 한 점검 현장에서 담당자분이 지나가듯 던진 말이 나를 멈춰 세웠다. "키보드로만 쓰는 분들도 있다는데, 우리 사이트는 그게 되긴 되나요?" 그 자리에서 Tab 키를 눌러봤다. 그리고 나는, 지금 내 초점이 화면 어디에 가 있는지 도무지 알 수가 없었다.

이게 오늘 글의 출발점이다. 마우스를 쓰는 사람에게는 화면 위 어딘가에서 깜빡이는 커서가 있고, 누르고 싶은 버튼에 손을 가져가면 그 자리에 정확히 닿는다. 그런데 키보드만 쓰는 사람에게는 그런 게 없다. 대신 '지금 내가 선택한 요소가 무엇인가'를 알려주는 단 하나의 신호에 의존한다. 바로 초점(focus) 표시다. 버튼이나 링크, 입력칸에 키보드 초점이 가면 그 둘레에 테두리가 생기거나 배경이 살짝 바뀌어서 '지금 여기예요'라고 알려주는 그 신호. 그게 보이지 않으면, 키보드 사용자는 글자 그대로 길을 잃는다.

생각해보면 무서운 일이다. 마우스 사용자에게는 '커서가 사라진 화면'이나 마찬가지인데, 우리는 그 화면을 매일 누군가에게 내밀고 있는 셈이다. 그리고 더 무서운 건, 만드는 사람이 그 사실을 거의 인지하지 못한다는 점이다. 왜냐하면 만드는 사람은 마우스를 쓰니까. 마우스로 클릭하면 다 잘 되니까, '잘 만들었다'고 믿어버린다. 키보드만 쓰는 사용자가 어디서 막히는지는, 마우스를 손에서 떼보기 전까지는 절대 보이지 않는다.

오늘 글은 그래서 일부러 '안 보이는 쪽'을 들여다본다. 초점이 안 보이는 사이트가 키보드 사용자에게 실제로 어떤 경험인지, 무엇이 어떻게 잘못되는지를 가상의 ○○시, A광역지자체, 한중앙부처, B공공기관, C기관 사례로 구체적으로 풀어보려 한다. 미리 말해두지만, 이 사례들은 특정 기관 이야기가 아니다. 공공 사이트를 점검하다 보면 기관 규모나 종류와 상관없이 반복적으로 만나는 '전형적인 패턴'들이다. 내 사이트에 하나라도 해당되는 게 있는지 체크하면서 읽어주면 좋겠다.

한 가지 미리 짚어둘 게 있다. 이 글은 누구를 탓하려는 글이 아니다. 초점이 안 보이는 사이트를 만든 건 담당자가 무심해서도, 외주가 실력이 없어서도 아니다. 그냥 '마우스를 쓰는 사람들끼리 만들면' 자연스럽게 일어나는 일이다. 자기가 겪지 않는 불편은 보이지 않는 법이니까. 그러니 '우리 사이트가 이렇네' 싶은 대목이 나와도 자책할 필요 없다. 원인을 알면 고칠 수 있고, 고치는 출발점이 바로 이런 패턴을 '이름 붙여' 인식하는 일이다. 키보드로 막히는 지점에 이름을 붙일 수 있게 되면, 그건 더 이상 '왠지 모르게 불편한 사이트'가 아니라 '여기를 고치면 되는 사이트'가 된다.

그리고 또 하나. 이 문제는 결코 소수만의 이야기가 아니다. 키보드로만 웹을 쓰는 사람은 우리 생각보다 훨씬 많다. 손을 떨거나 정교한 마우스 조작이 어려운 분, 시각장애로 화면 낭독기(스크린리더)를 쓰는 분, 마우스 없이 노트북 키보드만으로 일하는 분, 일시적으로 팔을 다쳐 한 손만 쓰는 분, 심지어 단순히 키보드가 더 빠르다고 느끼는 파워 유저까지. 공공 서비스는 '누구나' 쓸 수 있어야 한다는 게 대전제다. 그 누구나 안에는 당연히 키보드 사용자도 들어 있다. 초점이 안 보이는 사이트는 그 '누구나'에서 적지 않은 사람을 조용히 빼버리는 사이트다.

사실 이 글을 쓰면서 한 가지 마음에 걸리는 게 있었다. '키보드 접근성'이라고 하면 많은 분들이 '아, 그건 전문가가 할 일이지' 하고 미리 벽을 친다는 거다. 코드를 모르면 어쩔 수 없는 영역이라고 생각하는 거다. 그런데 막상 들여다보면, 오늘 이야기할 다섯 가지 문제 중 상당수는 코드를 한 줄도 몰라도 '있는지 없는지'는 누구나 확인할 수 있다. 마우스를 치우고 Tab 키를 눌러보는 것만으로 충분하니까. 진단은 누구나 할 수 있고, 수정은 개발자에게 정확히 요청하면 된다. 그러니 '나는 기술을 모르니까' 하고 미리 물러서지 말고, 일단 끝까지 읽어주면 좋겠다. 이 글의 목표 중 하나는, 접근성을 '전문가만의 영역'에서 '담당자 누구나 챙길 수 있는 일'로 끌어내리는 거다.

또 하나 솔직히 털어놓자면, 나도 이 일을 하기 전엔 접근성을 좀 '추상적인 의무' 정도로 여겼다. 지켜야 한다니까 지키는, 그런 숙제 같은 거. 그런데 실제로 키보드만 쓰는 분이 우리가 점검한 사이트에서 신청을 끝까지 못 하고 포기하는 걸 본 뒤로 생각이 완전히 바뀌었다. 그건 숙제가 아니라 사람의 문제였다. 어떤 사람은 지원금을 신청하지 못하고, 어떤 사람은 민원을 넣지 못하고, 어떤 사람은 자격 확인을 못 한다. 화면 위 작은 테두리 하나가 누군가에게는 행정 서비스에 닿을 수 있느냐 없느냐를 가른다. 그 무게를 알고 나면, 접근성은 더 이상 추상적인 단어가 아니게 된다.

이 글에서 다룰 큰 흐름은 이렇다. 먼저 '초점'과 '키보드 접근'이 정확히 무엇인지, 왜 중요한지를 짚는다. 그다음 점검 현장에서 거의 매번 만나는 다섯 가지 붕괴 패턴을 익명 사례로 구체적으로 보여준다. 마지막으로 이걸 어떻게 점검하고 고칠 수 있는지, 그리고 그 점검을 사람이 일일이 하지 않고 자동으로 잡아내는 방법까지 이야기한다. 자, 그럼 마우스를 잠깐 내려놓고 시작해보자.

 

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

■ '키보드 접근'이란 정확히 무슨 뜻인가

먼저 용어부터 정리하자. '키보드 접근성'이라고 하면 막연하게 들리는데, 실제로는 아주 구체적인 약속이다. '마우스로 할 수 있는 모든 일은 키보드로도 할 수 있어야 한다'는 것. 이게 핵심이다.

조금 더 풀어보자. 사이트에는 사용자가 '조작'하는 요소들이 있다. 링크를 눌러 다른 페이지로 가고, 버튼을 눌러 신청을 제출하고, 입력칸에 글자를 넣고, 드롭다운에서 항목을 고르고, 탭을 눌러 화면을 전환하고, 메뉴를 열어 하위 항목을 본다. 마우스 사용자는 이걸 전부 '클릭'과 '이동'으로 한다. 키보드 사용자는 이걸 전부 '키'로 해야 한다. Tab 키로 다음 요소로 이동하고, Shift+Tab으로 이전 요소로 돌아가고, Enter나 스페이스로 누르고, 화살표로 항목 사이를 옮긴다.

그래서 키보드 접근성은 세 가지 조건이 동시에 충족돼야 성립한다. 첫째, 모든 조작 요소에 키보드로 '도달'할 수 있어야 한다(도달 가능성). 둘째, 도달한 요소를 키보드로 '실행'할 수 있어야 한다(조작 가능성). 셋째, 지금 어디에 초점이 가 있는지 '보여야' 한다(초점 가시성). 이 셋 중 하나라도 빠지면 키보드 사용자는 막힌다.

이 셋을 일상의 비유로 바꿔보자. 어두운 방에서 손전등 하나로 물건을 찾는 상황을 떠올려보면 된다. 도달 가능성은 '손전등이 방의 모든 구석을 비출 수 있는가'다. 비추지 못하는 사각지대가 있으면 거기 있는 물건은 영영 못 찾는다. 조작 가능성은 '비춘 물건을 집을 수 있는가'다. 보이긴 하는데 집을 수가 없으면 소용이 없다. 그리고 초점 가시성은 '손전등이 켜져 있는가'다. 손전등이 꺼져 있으면 방에 아무리 물건이 잘 정리돼 있어도 아무것도 못 찾는다. 초점 표시는 키보드 사용자에게 바로 그 손전등의 불빛이다.

오늘 글 제목이 '초점이 안 보이는 사이트'인 이유가 여기 있다. 세 조건 중에서도 '초점 가시성'이 가장 흔하게, 가장 어이없게 무너지기 때문이다. 도달과 조작은 그래도 어느 정도 되는데, 정작 '지금 어디에 있는지'를 안 보여줘서 사용자가 길을 잃는 경우가 압도적으로 많다. 손전등을 꺼버린 사이트가 그만큼 많다는 뜻이다.

이 세 조건을 한 줄로 요약하면 이렇게 외워둘 수 있다. '갈 수 있고(도달), 할 수 있고(조작), 보인다(가시성).' 키보드 사용자가 한 가지 행동을 완수하려면 이 셋이 동시에 충족돼야 한다. 어느 하나라도 빠지면 사슬이 끊긴다. 갈 수 없으면 시작도 못 하고, 할 수 없으면 도착해도 소용없고, 안 보이면 갈 수 있고 할 수 있어도 어디로 가는지를 모른다. 그래서 키보드 접근성을 점검할 때 나는 늘 이 세 단어를 순서대로 떠올린다. 갈 수 있나, 할 수 있나, 보이나. 이 세 질문에 모두 '예'라고 답할 수 있으면 그 요소는 키보드 접근성을 갖춘 거다.

 

■ 초점 표시는 왜 사라지는가

여기서 좀 황당한 사실을 하나 짚어야겠다. 사실 웹 브라우저는 기본적으로 초점 표시를 '알아서' 보여준다. 아무 처리도 안 하면, 버튼이나 링크에 키보드 초점이 갈 때 브라우저가 둘레에 점선이나 파란 테두리를 자동으로 그려준다. 즉 초점 표시는 '없는 걸 새로 만들어야 하는' 게 아니라, 원래 '있는 걸 그냥 두면 되는' 것이다.

그런데 왜 수많은 사이트에서 초점 표시가 사라졌을까. 이게 오늘 글에서 가장 중요하게 짚고 싶은 대목이다. 답은 좀 허탈하다. '디자이너 눈에 그 테두리가 거슬려서 일부러 지웠기' 때문이다.

브라우저가 그려주는 기본 초점 테두리는 솔직히 예쁘지 않다. 투박한 점선이거나, 디자인과 안 어울리는 파란 외곽선이다. 그래서 화면을 깔끔하게 만들고 싶은 마음에, 그 테두리를 없애는 한 줄을 코드에 넣는 경우가 정말 많다. 그 한 줄이 사이트 전체의 모든 초점 표시를 한꺼번에 꺼버린다. 마우스 사용자에게는 아무 영향이 없으니 아무도 문제를 눈치채지 못한다. 하지만 그 순간, 키보드 사용자에게는 손전등이 꺼진다.

핵심은 이거다. 초점 테두리를 '없애는' 건 괜찮다. 단, 없앤 자리에 '더 보기 좋은 우리만의 초점 표시'를 반드시 새로 넣어야 한다. 기본 테두리가 거슬리면, 우리 디자인에 어울리는 초점 스타일을 직접 설계해서 입히면 된다. 둘레를 우리 브랜드 색 테두리로 감싸거나, 배경을 살짝 강조하거나, 그림자를 더하거나. 문제는 '없애기만 하고 새로 안 넣는' 경우다. 거슬린다고 손전등을 꺼놓고, 새 손전등을 안 사주는 것. 이게 초점 표시가 사라지는 가장 흔한 경로다.

그래서 초점 가시성 문제는 '기술이 어려워서' 생기는 게 아니다. '키보드 사용자를 떠올리지 못해서' 생긴다. 만드는 사람이 마우스만 쓰니까, 그 테두리가 누군가에게는 생명줄이라는 걸 모르는 거다. 이건 실력의 문제가 아니라 시야의 문제다. 그리고 시야의 문제는, 한 번 인식하기만 하면 의외로 쉽게 풀린다. '아, 이 테두리를 함부로 지우면 안 되는구나'를 아는 순간, 그다음부터는 안 지우거나 대체 표시를 넣게 되니까.

 

■ 행정안전부 지침과 KWCAG 안에서 키보드·초점의 위치

이 문제가 단순히 '있으면 좋은 배려'가 아니라 '지켜야 할 기준'이라는 점도 짚고 넘어가자. 행정안전부의 「전자정부 웹사이트 품질관리 지침」은 공공 웹사이트가 갖춰야 할 품질을 7대 영역으로 정리한다. 호환성, 접근성, 개방성, 접속성, 편의성, 효율성, 신뢰성. 오늘 다루는 키보드와 초점은 이 중 '접근성' 영역의 핵심에 해당한다.

그리고 그 접근성을 구체적인 검사 항목으로 풀어둔 것이 한국형 웹 콘텐츠 접근성 지침, KWCAG다. KWCAG는 33개 항목으로 공공 웹의 접근성을 점검하는데, 키보드 접근과 초점 표시는 그 안에서도 비중이 큰 항목들이다. '키보드 사용 보장', '초점 이동과 표시', '응답 시간 조절' 같은 항목들이 바로 오늘 이야기와 직결된다.

여기서 한 가지 오해를 풀자. 접근성을 '장애인을 위한 특별 배려' 정도로만 생각하는 경우가 있는데, 그건 절반만 맞는 이야기다. 접근성은 '특정 누군가를 위한 추가 기능'이 아니라 '모두를 위한 기본 품질'이다. 키보드로 잘 쓰이는 사이트는 마우스 사용자에게도 더 견고하고, 스크린리더로 잘 읽히는 사이트는 검색엔진에도 잘 읽히고, 글자 대비가 좋은 사이트는 밝은 야외에서 폰을 보는 모든 사람에게 편하다. 접근성을 챙기면 결과적으로 모든 사용자의 경험이 좋아진다. 그래서 접근성은 '비용'이 아니라 '품질의 다른 이름'이다.

특히 공공 사이트는 이 기준에서 자유로울 수 없다. 민간 쇼핑몰은 불편하면 다른 데로 가면 그만이지만, 공공 서비스는 대체재가 없다. 그 기관에서만 처리할 수 있는 민원, 그 사이트에서만 할 수 있는 신청이 있다. 그러니 그 사이트가 키보드 사용자에게 막혀 있으면, 그 사용자에게는 그 행정 서비스 자체가 닫혀 있는 거나 다름없다. 선택의 여지가 없는 서비스일수록 접근성의 무게가 커진다. 공공 사이트의 접근성이 단순한 권장이 아니라 의무로 다뤄지는 이유가 여기 있다.

 

■ 초점은 '커서'가 아니라 '현재 위치'다 — 둘을 헷갈리지 말자

여기서 용어 하나를 더 깔끔하게 정리하고 가자. 사람들이 흔히 헷갈리는 게, 마우스 커서와 키보드 초점을 같은 거라고 생각하는 거다. 둘은 완전히 다르다. 마우스 커서는 '내 손이 지금 가리키는 지점'이고, 키보드 초점은 '지금 키보드 입력을 받고 있는 요소'다. 마우스 커서는 화면 위 아무 데나 떠다닐 수 있지만, 키보드 초점은 반드시 '조작 가능한 요소' 위에만 머문다. 버튼, 링크, 입력칸 같은 것들 위에만.

이 차이를 이해하면 왜 초점 표시가 그렇게 중요한지가 더 분명해진다. 마우스 사용자는 커서가 늘 보이니까, 어디를 누를지 미리 확인하고 누른다. 손을 움직이는 동안 커서가 따라오니, 누르기 전에 '여기 누르면 되겠구나'를 안다. 그런데 키보드 사용자에게는 그 미리보기가 없다. Tab을 누르는 순간 초점이 다음 요소로 '점프'한다. 그 점프한 자리가 어디인지를 알려주는 게 초점 표시뿐이다. 초점 표시가 없으면 사용자는 '내가 방금 어디로 점프했는지'를 모른 채 다음 동작을 결정해야 한다. 마우스로 치면 커서를 안 보고 클릭하는 것과 같다.

그래서 초점 표시는 '장식적인 테두리'가 아니라 '기능적인 커서'다. 마우스 사용자의 커서를 함부로 없애면 아무도 사이트를 못 쓰듯, 키보드 사용자의 초점 표시를 없애면 그들은 사이트를 못 쓴다. 둘은 정확히 같은 무게의 장치다. 다만 한쪽은 모두에게 보이고, 다른 한쪽은 키보드를 쓸 때만 보인다는 차이가 있을 뿐이다. 만드는 사람이 마우스만 쓰니까 한쪽은 '당연히 있어야 하는 것'으로, 다른 한쪽은 '없어도 되는 장식'으로 잘못 인식하는 거다.

한 가지 더. 초점 표시는 '있기만' 하면 되는 게 아니라 '잘 보여야' 한다. 초점 테두리를 남겨두긴 했는데 색이 배경과 비슷해서 거의 안 보이거나, 너무 얇아서 눈에 안 들어오면 없는 거나 마찬가지다. 손전등을 켜긴 켰는데 빛이 너무 약해서 발밑이 안 보이는 격이다. 그래서 좋은 초점 표시는 '주변과 충분히 대비되는 또렷한 표시'여야 한다. 두께도 충분하고, 색도 배경과 분명히 구분되고, 누가 봐도 '아, 지금 여기구나'를 단번에 알 수 있어야 한다. 초점 표시의 품질은 곧 키보드 사용자가 길을 잃지 않는 속도를 결정한다.

 

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

이제 구체적인 붕괴 패턴들을 보자. 점검 현장에서 거의 매번 만나는 단골 사례들이다. 다섯 가지 패턴은 따로 떨어진 게 아니라 대개 함께 나타난다. 초점 표시를 지운 사이트는 십중팔구 키보드 함정도 있고, 탭 순서도 엉켜 있다. 왜냐하면 이 모든 게 '키보드 사용자를 떠올리지 않고 만들었다'는 하나의 원인에서 비롯되기 때문이다. 그래서 패턴 하나가 보이면 '나머지도 있겠구나' 하고 함께 점검하는 게 효율적이다. 반대로 말하면, 키보드로 한 번 처음부터 끝까지 써보는 습관 하나만 들이면 이 다섯 가지가 동시에 보이기 시작한다.

읽기 전에 다시 한번 일러둔다. 아래 사례들은 전부 익명 처리한 것이다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 '전형'을 보여주려는 거다. 실제로 이 패턴들은 규모가 크든 작든, 예산이 많든 적든 거의 똑같이 나타난다. 잘 만든 사이트라고 안 나오는 게 아니라 '덜 나오는' 정도의 차이일 뿐이다.

또 하나 미리 일러두자면, 이 다섯 패턴은 '심각한 순서'가 아니라 '자주 만나는 순서'에 가깝게 배열했다. 어떤 사이트는 패턴 4(도달 불가)가 가장 치명적일 수 있고, 어떤 사이트는 패턴 1(초점 안 보임)이 모든 페이지에 깔려 있어 가장 광범위할 수 있다. 그러니 '몇 번 패턴이니까 덜 중요하다'는 식으로 읽지 말고, 우리 사이트에 어떤 게 있는지를 체크하는 마음으로 읽어주면 좋겠다. 다섯 개를 다 외울 필요도 없다. 읽다 보면 '아, 우리도 이거 있는데' 싶은 게 한둘은 걸릴 텐데, 그 하나를 알아본 것만으로도 이미 절반은 고친 셈이다.

 

■ 붕괴 패턴 1: 초점 표시를 통째로 지운 사이트 (A광역지자체)

가장 흔하고, 가장 치명적인 패턴부터 보자. A광역지자체의 한 서비스 페이지를 키보드로 점검한 적이 있다. 마우스를 손에서 떼고 Tab 키를 눌러 화면을 훑어 내려갔다. 그런데 아무리 Tab을 눌러도 화면에 변화가 없었다. 분명히 초점은 이동하고 있었다 — Enter를 누르면 어떤 링크가 작동했으니까 — 그런데 '지금 어디에 초점이 있는지'가 화면에 전혀 표시되지 않았다.

이게 무슨 경험이냐면, 눈을 감고 계단을 내려가는 것과 비슷하다. 발은 한 칸씩 내려가는데 지금 몇 번째 칸인지 알 수가 없다. 신청 버튼을 누르려고 Tab을 몇 번 눌러야 하는지, 지금 그 버튼에 도착했는지, 아니면 지나쳤는지 알 길이 없다. 결국 사용자는 '대충 이쯤이겠지' 하고 Enter를 누르는 도박을 하게 된다.

그 도박의 결과가 어떨지 상상해보자. 운 좋게 신청 버튼이 눌리면 다행이지만, 한 칸 어긋나서 '취소'나 '뒤로 가기'가 눌리면 그동안 입력한 게 다 날아간다. 더 나쁜 경우엔 의도치 않은 다른 신청이 제출돼버린다. 키보드 사용자는 매 단계가 이런 식의 작은 도박이 된다. 마우스 사용자는 보고 누르니 도박할 일이 없는데, 키보드 사용자는 안 보이니 매번 운에 맡겨야 한다. 이게 얼마나 피로한 일인지는, 실제로 한번 눈 감고 사이트를 써보면 단번에 안다. 한두 페이지만 그렇게 써봐도 진이 빠진다. 우리가 그 피로를 매일 누군가에게 강요하고 있었다는 사실이, 점검을 하다 보면 마음을 무겁게 한다.

원인을 코드에서 확인해보니 예상대로였다. 초점 테두리를 없애는 한 줄이 전역 스타일에 들어 있었고, 그걸 대체할 초점 표시는 어디에도 없었다. 누군가 '점선 테두리가 보기 싫다'는 이유로 지운 뒤, 새 표시를 넣는 걸 잊은 거다. 악의는 없었다. 다만 그 테두리가 누군가에게는 화면 위의 유일한 이정표라는 걸 몰랐을 뿐이다.

고치는 방법은 의외로 간단하다. 지웠던 그 자리에 우리 사이트에 어울리는 초점 표시를 새로 입히면 된다. 브랜드 색의 또렷한 테두리, 충분히 두꺼워서 한눈에 보이는 굵기, 배경과 대비가 분명한 색. 이렇게만 해줘도 키보드 사용자는 화면 위에서 자기 위치를 또렷이 볼 수 있게 된다. 손전등이 다시 켜지는 거다. 비용이 큰 작업도 아니다. 전역 스타일 몇 줄이면 사이트 전체의 모든 버튼과 링크에 초점 표시가 한꺼번에 살아난다.

이 사례에서 한 가지 더 짚고 싶은 게 있다. 담당자분께 이 문제를 보여드렸을 때 처음 나온 반응이 "어, 그런데 우리 사이트 멀쩡하게 잘 돌아가는데요?"였다. 당연하다. 마우스로 보면 멀쩡하니까. 그래서 그 자리에서 함께 마우스를 치우고 키보드로 신청 페이지까지 가보는 실험을 했다. Tab을 누르며 화면을 내려가는데, 담당자분도 자기 사이트에서 자기가 지금 어디 있는지 못 찾았다. 그 순간 표정이 바뀌었다. "아… 이게 이런 거였구나." 백 마디 설명보다 그 한 번의 체험이 더 강했다. 초점 문제는 말로 들으면 추상적인데, 직접 키보드로 길을 잃어보면 단번에 와닿는다. 그래서 나는 점검 결과를 보고할 때 가능하면 담당자가 직접 키보드로 써보게 한다. 본 사람만이 고칠 마음을 먹기 때문이다.

그리고 이 문제는 '한 번 고치면 끝'이라는 점에서 의외로 가성비가 좋은 개선이다. 색 난립이나 글꼴 정리 같은 건 흩어진 걸 일일이 찾아 고쳐야 하지만, 초점 표시는 보통 전역 스타일 한곳에서 관리되기 때문에 그 한 곳만 제대로 잡으면 사이트의 모든 요소에 한꺼번에 적용된다. 적은 노력으로 가장 많은 사용자에게 가장 큰 변화를 주는 개선인 셈이다. 접근성 개선을 어디서부터 시작해야 할지 막막하다면, 나는 늘 '초점 표시부터'라고 답한다. 비용 대비 효과가 가장 확실하기 때문이다.

■ 붕괴 패턴 2: 들어가면 못 나오는 키보드 함정 (○○시)

두 번째 패턴은 더 답답하다. '키보드 함정(keyboard trap)'이라고 부른다. ○○시의 한 페이지에 떠 있는 팝업 창에서 이 문제를 만났다. 사용자가 무언가를 신청하려고 하면 안내 팝업이 떴는데, 마우스로는 'X' 버튼이나 '확인'을 눌러 닫으면 그만이었다. 그런데 키보드로는 그 팝업에서 빠져나올 수가 없었다.

상황은 이랬다. Tab을 눌러 팝업 안의 요소들을 돌아다닐 수는 있었다. 그런데 마지막 요소에서 Tab을 한 번 더 누르면, 팝업 밖으로 나가는 게 아니라 다시 팝업의 첫 요소로 돌아왔다. 빙글빙글 도는 거다. 팝업 안에 갇혔다. ESC 키도 안 먹혔고, 닫기 버튼에 초점을 줘서 Enter를 눌러도 반응이 없었다. 키보드 사용자에게 그 팝업은 들어가면 못 나오는 방이었다.

처음 이걸 마주했을 때 나는 내가 뭘 잘못 누른 줄 알았다. Tab을 다시 처음부터 천천히 눌러봤다. 결과는 같았다. 몇 번을 시도해도 그 작은 안내 팝업 안을 맴돌 뿐, 바깥으로 나가는 길이 없었다. 그 순간의 막막함이 아직도 생생하다. 화면 뒤편에 내가 가야 할 신청 양식이 분명히 보이는데, 그 사이를 가로막은 팝업을 넘어갈 방법이 없는 거다. 보이는데 닿을 수가 없다는 것. 그게 키보드 함정이 주는 특유의 답답함이다.

이게 왜 무서운 패턴이냐면, 사용자가 '실수해서 막힌' 게 아니라 '정상적으로 사용하다가 갇힌' 거라서 그렇다. 빠져나갈 방법이 없으니, 사용자가 할 수 있는 건 브라우저를 통째로 닫고 처음부터 다시 시작하는 것뿐이다. 신청하던 내용이 다 날아가는 건 덤이다. 한두 번 이런 일을 겪으면, 사용자는 그 사이트를 다시 찾지 않는다.

키보드 함정은 보통 외부 요소나 직접 만든 복잡한 컴포넌트에서 생긴다. 팝업, 날짜 선택기, 자동완성 목록, 슬라이드 메뉴 같은 것들. 마우스로는 바깥을 클릭하면 자연스럽게 빠져나와지니까 만든 사람은 함정인 줄 모른다. 하지만 키보드에는 '바깥을 클릭한다'는 개념이 없다. 그래서 컴포넌트 안에 '나가는 길'을 명시적으로 만들어줘야 한다. 마지막 요소에서 Tab을 누르면 자연스럽게 다음으로 넘어가게 하거나, ESC로 언제든 닫히게 하거나, 닫기 버튼이 키보드로도 확실히 작동하게 하거나.

이 패턴이 알려주는 교훈은 분명하다. '들어갈 수 있으면 나갈 수도 있어야 한다.' 너무 당연한 말 같지만, 키보드 관점에서 이 당연함을 검증하지 않으면 함정은 조용히 만들어진다. 그리고 한번 만들어진 함정은, 마우스를 쓰는 누구의 눈에도 띄지 않은 채 키보드 사용자만 골탕먹인다.

키보드 함정에는 사실 한 가지 더 미묘한 버전이 있다. '갇히는' 것까진 아닌데 '엉뚱한 데로 빠지는' 경우다. 예를 들어 팝업이 떴는데, 키보드 초점은 여전히 팝업 뒤쪽의 본문에 머물러 있는 경우다. 사용자는 화면에 뜬 팝업을 조작하려고 Tab을 누르는데, 정작 초점은 팝업 뒤에 가려진 본문 요소들을 헤매고 있다. 팝업이 떴으면 초점도 팝업 안으로 따라 들어가야 하는데, 그 연결이 빠진 거다. 마우스 사용자는 팝업을 바로 클릭하니 문제를 모르지만, 키보드 사용자는 '분명히 팝업이 떴는데 왜 거기 손이 안 닿지' 하며 혼란에 빠진다. 그래서 팝업을 만들 때는 '뜰 때 초점을 팝업 안으로 옮기고, 닫을 때 초점을 원래 자리로 돌려놓는' 처리가 함께 들어가야 한다. 이게 빠지면 팝업은 키보드 사용자에게 '보이지만 닿지 않는 유령'이 된다.

이런 디테일이 어렵게 느껴질 수 있는데, 핵심 원칙 하나만 기억하면 된다. '마우스가 자연스럽게 하는 일을, 키보드에는 명시적으로 만들어줘야 한다'는 것. 마우스는 바깥을 클릭해 빠져나오고, 팝업을 바로 눌러 들어간다. 그 '자연스러움'이 키보드에는 없으니, 우리가 코드로 그 길을 깔아줘야 한다. 이 원칙 하나만 떠올려도 키보드 함정의 대부분은 예방된다.

 

■ 붕괴 패턴 3: 탭 순서가 뒤죽박죽인 화면 (한중앙부처)

세 번째는 '탭 순서'의 문제다. 한중앙부처의 한 신청 양식을 키보드로 채워본 적이 있다. 화면을 보면 위에서 아래로, 왼쪽에서 오른쪽으로 항목이 깔끔하게 배열돼 있었다. 그런데 Tab을 눌러 입력칸을 옮겨 다녀보니, 초점이 화면 순서대로 가지 않았다.

이름 칸에서 Tab을 눌렀더니 초점이 갑자기 화면 아래쪽 '주소' 칸으로 뛰었다. 거기서 또 Tab을 누르니 다시 위로 올라와 '연락처'로 갔다. 화면에 보이는 순서와 키보드가 도는 순서가 완전히 따로 놀았다. 마우스 사용자에게는 아무 문제가 없다. 보고 싶은 칸을 그냥 클릭하면 되니까. 하지만 키보드 사용자는 Tab이 정해주는 순서대로 따라갈 수밖에 없는데, 그 순서가 화면과 안 맞으니 정신이 사납고 자꾸 헷갈린다.

이런 일은 보통 화면을 '눈에 보이는 위치'와 '코드상의 순서'가 어긋나게 짰을 때 생긴다. 디자인을 맞추려고 요소를 시각적으로는 이리저리 옮겨놨는데, 코드상의 순서는 그대로라서 키보드가 코드 순서대로 도는 거다. 또는 탭 순서를 인위적으로 지정하는 값을 잘못 넣어서 순서가 꼬이는 경우도 있다.

탭 순서가 엉키면 사용자는 '내가 뭘 빠뜨렸나' 하는 불안에 시달린다. 분명히 위에서 아래로 채웠다고 생각했는데, 어느 칸은 건너뛰어진 것 같고 어느 칸은 두 번 지나간 것 같다. 양식이 길수록 이 혼란은 커진다. 결국 신청을 끝내고도 '제대로 낸 게 맞나' 하는 찜찜함이 남는다. 공공 신청은 한 번 잘못 내면 다시 처리받기까지 며칠이 걸리기도 하니, 이 찜찜함은 가볍지 않다.

해법은 '보이는 순서와 키보드 순서를 일치시키는' 것이다. 화면에서 위에 있는 게 키보드에서도 먼저 오고, 왼쪽에 있는 게 먼저 오게. 가장 좋은 방법은 코드를 화면에 보이는 자연스러운 순서대로 짜고, 탭 순서를 인위적으로 건드리지 않는 거다. 자연스러운 순서로 짜두면 키보드는 알아서 그 순서를 따라간다. 결국 탭 순서 문제도 '키보드로 한 번 채워보면' 1분 만에 발견되는 문제다. 안 채워봐서 안 보였을 뿐이다.

탭 순서 이야기를 하면서 꼭 덧붙이고 싶은 게 있다. 탭 순서를 '인위적으로 지정하는 값'을 쓰는 걸 가급적 피하라는 거다. 어떤 요소에 '이건 무조건 제일 먼저 초점이 가게 해줘' 하는 식으로 순서를 강제로 정해버리면, 당장은 그 요소가 먼저 와서 만족스러울지 몰라도 나중에 페이지가 조금만 바뀌면 전체 순서가 와르르 무너진다. 강제로 1번을 정해두면 나머지 요소들이 그 1번 뒤에서 또 자기들끼리 순서 다툼을 하게 되고, 결국 아무도 예측 못 하는 순서가 된다. 그래서 베테랑일수록 탭 순서를 손으로 지정하지 않는다. 코드 순서를 화면 순서와 맞춰두는 것만으로 충분하기 때문이다. '건드리지 않는 게 가장 좋은 처리'인 드문 경우다.

탭 순서가 잘 맞는지를 확인하는 작은 요령도 하나 공유한다. 페이지를 열고 Tab을 천천히 누르면서, 초점이 가는 자리를 눈으로 따라가 보는 거다. 그 경로가 자연스러운 'ㄹ자' 또는 'Z자'를 그리면 잘 된 거다. 위에서 시작해 오른쪽으로 갔다가 다음 줄로 내려와 다시 왼쪽부터, 우리가 글을 읽는 그 순서대로. 만약 초점이 위아래로 펄쩍펄쩍 뛰거나 좌우로 왔다 갔다 하면 순서가 꼬인 거다. 이 'Tab으로 글 읽듯 따라가 보기'는 누구나 1분이면 할 수 있는 점검이다.

■ 붕괴 패턴 4: 키보드로는 아예 닿지 않는 메뉴 (B공공기관)

네 번째는 '도달 가능성' 자체가 무너진 경우다. B공공기관의 메인 화면 상단에는 마우스를 올리면 펼쳐지는 큰 메뉴가 있었다. 마우스 사용자에게는 편리했다. 마우스를 메뉴에 올리면 하위 항목들이 주르륵 펼쳐지고, 원하는 걸 클릭하면 된다. 그런데 키보드로 그 메뉴에 접근하려 하자, 하위 항목에 전혀 닿을 수가 없었다.

이유는 그 메뉴가 '마우스를 올린다'는 동작에만 반응하도록 만들어졌기 때문이다. 키보드에는 '마우스를 올린다'는 개념이 없다. Tab으로 메뉴 제목까지는 갈 수 있어도, 거기서 하위 항목을 펼치는 방법이 없었다. 결국 키보드 사용자는 그 메뉴 아래에 있는 모든 페이지에 영영 닿을 수 없었다. 메인 화면의 가장 중요한 길목이 키보드 사용자에게는 막힌 벽이었던 거다.

이건 앞의 초점 문제보다 한 단계 더 근본적인 문제다. 초점이 안 보이는 건 '어디 있는지 모르는' 거지만, 도달이 안 되는 건 '아예 갈 수가 없는' 거다. 사이트의 절반이 키보드 사용자에게는 존재하지 않는 셈이다. 점검하면서 이런 메뉴를 만나면 마음이 무거워진다. 메인 화면의 핵심 동선이 막혀 있다는 건, 그 사이트가 키보드 사용자를 처음부터 사용자로 상정하지 않았다는 뜻이기 때문이다.

해법은 '마우스를 올리는 동작에만 의존하지 않는' 거다. 마우스를 올렸을 때 펼쳐지는 건 그대로 두되, 키보드로 그 메뉴에 초점이 갔을 때도 똑같이 펼쳐지게 하고, 화살표로 하위 항목 사이를 옮길 수 있게 하고, Enter로 선택되게 만들면 된다. 마우스의 길과 키보드의 길을 둘 다 열어두는 것. 어느 한쪽만 열려 있으면 반쪽짜리 사이트가 된다.

이 패턴이 특히 위험한 건, 메뉴처럼 '모두가 매일 쓰는 핵심 요소'에서 잘 생긴다는 점이다. 구석진 페이지의 사소한 버튼이 아니라, 사이트의 대문 격인 메뉴가 막히면 그 영향은 사이트 전체로 번진다. 그래서 키보드 점검을 할 때 나는 항상 메인 화면의 주 메뉴부터 키보드로 열어본다. 거기가 뚫려 있어야 나머지로 갈 수 있으니까.

이 도달 불가 문제는 메뉴 말고도 여러 곳에서 나타난다. 대표적인 게 '이미지로 만든 버튼'이다. 글자 대신 그림 하나를 버튼처럼 보이게 만들어 놓고, 클릭만 처리해둔 경우. 마우스로는 그림을 클릭하면 작동하지만, 키보드로는 그게 '눌 수 있는 요소'라는 걸 인식조차 못 한다. Tab을 눌러도 그 그림에는 초점이 가지 않는다. 화면에는 분명히 버튼처럼 생긴 게 있는데, 키보드 사용자에게는 그냥 '눌리지 않는 그림'인 거다. 또 다른 경우는 직접 만든 체크박스나 토글이다. 보기엔 체크박스인데 실제로는 그림과 클릭 처리만으로 흉내 낸 거라, 키보드로는 켜고 끌 수가 없다.

이런 '흉내 낸 요소'들의 공통점은, 겉모습만 조작 요소처럼 만들고 '진짜 조작 요소가 갖춰야 할 키보드 동작'은 빼먹었다는 거다. 진짜 버튼, 진짜 링크, 진짜 입력칸은 브라우저가 알아서 키보드 동작을 붙여준다. 그런데 그림으로 흉내 낸 가짜 요소에는 그게 없다. 그래서 가능하면 흉내 내지 말고 진짜 요소를 쓰는 게 정답이다. 굳이 흉내 내야 한다면, 키보드로 도달 가능하게 만들고 Enter나 스페이스에 반응하도록 동작을 직접 붙여줘야 한다. 겉모습을 흉내 낼 때는 속까지 흉내 내야 한다는 게 핵심이다.

 

■ 붕괴 패턴 5: '본문 바로가기'가 없어 매번 메뉴를 통과해야 하는 사이트 (C기관)

다섯 번째 패턴은 좀 더 미묘하지만, 한번 알면 그 불편함이 또렷이 보인다. C기관의 사이트는 앞의 네 문제는 그럭저럭 피해 갔다. 초점도 보였고, 함정도 없었고, 탭 순서도 괜찮았다. 그런데 한 가지가 빠져 있었다 — '본문 바로가기' 링크다.

대부분의 사이트는 페이지 맨 위에 로고, 검색창, 그리고 길고 긴 주 메뉴가 있다. 마우스 사용자는 보고 싶은 본문으로 그냥 스크롤하거나 클릭하면 된다. 하지만 키보드 사용자는 Tab으로 한 요소씩 지나가야 한다. 그래서 본문에 닿으려면 매 페이지마다 상단의 그 수십 개 메뉴 항목을 전부 Tab으로 통과해야 한다. 페이지를 옮길 때마다 똑같은 메뉴를 처음부터 또 통과하고, 또 통과하고. 본문 한 줄 읽으려고 메뉴 사십 번을 누르는 셈이다.

이 문제를 해결하는 게 바로 '본문 바로가기(skip to content)' 링크다. 페이지 맨 앞에 '본문으로 바로가기' 같은 링크를 숨겨두었다가, 키보드 사용자가 Tab을 처음 누르면 그 링크가 화면에 나타나고, 누르면 반복되는 메뉴를 건너뛰고 본문으로 곧장 점프하게 해주는 장치다. 마우스 사용자에게는 평소 안 보이니 디자인을 해치지도 않는다. 키보드 사용자에게만 '지름길'을 열어주는 작은 배려다.

C기관 사이트에는 이 지름길이 없었다. 그래서 키보드 사용자는 페이지를 옮길 때마다 그 긴 메뉴를 묵묵히 통과해야 했다. 치명적인 결함은 아니지만, 매 페이지마다 쌓이는 이 피로는 결코 작지 않다. 사이트를 몇 페이지만 돌아다녀도 '왜 이렇게 번거롭지' 하는 지침이 쌓이고, 결국 사용자는 그 사이트를 멀리하게 된다. 본문 바로가기는 한 줄짜리 작은 장치지만, 키보드 사용자의 하루를 훨씬 가볍게 만든다.

이 패턴이 특히 안타까운 건, '거의 다 잘 만든 사이트'에서 이 하나가 빠지는 경우가 많기 때문이다. C기관 사이트는 앞의 네 문제를 다 피해 간, 나름 신경 써서 만든 사이트였다. 그런데도 본문 바로가기 하나가 없어서 키보드 사용자에게 은근한 피로를 줬다. 이건 '몰라서'라기보다 '거기까진 미처 생각 못 해서'에 가깝다. 본문 바로가기는 마우스 사용자에게는 보이지도 않으니, 만드는 사람이 떠올릴 계기 자체가 적다. 그래서 이 패턴은 '키보드 사용자의 동선을 끝까지 따라가 봤느냐'를 가르는 시금석 같은 항목이다. 초점·함정·순서·도달까지는 챙겼어도, '매 페이지마다 반복되는 피로'까지 생각이 미쳤느냐는 한 단계 더 깊은 배려다.

그리고 본문 바로가기는 비용이 거의 0에 가까운 개선이라는 점도 강조하고 싶다. 새로운 디자인을 짜야 하는 것도, 큰 구조를 바꿔야 하는 것도 아니다. 페이지 맨 앞에 숨은 링크 하나를 더하고, 키보드로 Tab을 처음 눌렀을 때만 나타나게 하면 된다. 마우스 사용자의 화면은 전혀 바뀌지 않는다. 들이는 노력에 비해 키보드 사용자가 얻는 편안함이 압도적으로 큰, 가성비 최고의 배려 중 하나다. '작은 한 줄이 누군가의 하루를 가볍게 한다'는 말이 가장 잘 들어맞는 사례가 바로 이 본문 바로가기다.

이 다섯 가지 패턴을 다시 한번 정리하면 이렇다. 초점이 안 보이고(패턴 1), 들어가면 못 나오고(패턴 2), 순서가 엉키고(패턴 3), 아예 닿지 못하고(패턴 4), 매번 같은 길을 통과해야 하는(패턴 5) 것. 전부 마우스 사용자에게는 보이지 않고, 키보드 사용자에게만 또렷이 보이는 문제들이다. 그래서 이걸 잡는 가장 확실한 첫걸음은, 만드는 사람이 직접 마우스를 내려놓고 키보드로 자기 사이트를 써보는 것이다.

다섯 패턴을 보다 보면 한 가지 공통점이 더 보인다. 전부 '마우스라는 편리한 도구가 가려놓은 문제'라는 점이다. 마우스는 너무 똑똑하고 너무 너그러워서, 우리가 만든 사이트의 빈틈을 알아서 메워준다. 닿기 어려운 요소도 정확히 짚어주고, 순서가 엉켜도 보고 싶은 데로 바로 가게 해주고, 함정에 빠져도 바깥을 클릭해 빠져나오게 해준다. 그 너그러움 덕분에 우리는 사이트가 멀쩡한 줄 안다. 그런데 그 너그러움이 사라진 환경 — 키보드만 있는 환경 — 에 두면, 가려져 있던 빈틈이 한꺼번에 드러난다. 그래서 키보드 점검은 단순히 '키보드 사용자를 위한 점검'이 아니라, '우리 사이트의 진짜 구조를 드러내는 엑스레이'에 가깝다. 마우스가 가려주던 걸 걷어내고 뼈대를 보는 일인 것이다.

그리고 이 다섯 패턴은 서로 얽혀 있다는 점도 기억하자. 한 사이트에서 한 패턴만 깔끔하게 나오는 경우는 드물다. 초점이 안 보이는 사이트는 대개 탭 순서도 신경 쓰지 않았고, 도달 안 되는 메뉴가 있는 사이트는 본문 바로가기도 없다. 왜냐하면 이 모두가 '키보드 사용자를 한 번도 떠올리지 않았다'는 단 하나의 뿌리에서 자라기 때문이다. 그래서 좋은 소식이 하나 있다. 뿌리가 하나면 처방도 하나로 통한다는 것. '키보드로 직접 써보고, 그 경험을 설계에 반영하는' 습관 하나만 들이면 다섯 패턴이 동시에 줄어든다. 한 그루의 나무를 키우면 다섯 개의 열매가 함께 열리는 셈이다.

 

 

【본론 3 — 어떻게 점검하고 고치는가】

■ 가장 정직한 점검: 마우스를 치우고 직접 써보기

지금까지 다섯 패턴을 봤으니, 이제 '그래서 어떻게 확인하느냐'를 이야기하자. 가장 정직하고 강력한 점검법은 돈 한 푼 안 든다. 마우스를 책상 서랍에 넣고, 키보드만으로 메인 화면부터 신청 완료까지 한 번 가보는 거다.

이 단순한 실험이 무서운 이유는, 우리가 평소에 보지 못하던 게 한꺼번에 보이기 때문이다. Tab을 눌렀는데 초점이 어디 갔는지 안 보이면 패턴 1이다. 어떤 요소에서 빙글빙글 돌면 패턴 2다. 순서가 화면과 안 맞으면 패턴 3이다. 닿을 수 없는 메뉴가 있으면 패턴 4다. 본문 가기까지 메뉴를 한참 통과해야 하면 패턴 5다. 다섯 패턴이 전부 이 한 번의 실험에서 드러난다.

처음 해보면 십중팔구 당황한다. '우리 사이트가 이렇게 쓰기 어려웠나' 싶을 거다. 그런데 그 당황이 좋은 신호다. 키보드 사용자가 매일 겪는 경험을 잠깐이나마 직접 체험한 거니까. 그 경험을 한 번 해본 사람과 안 해본 사람은, 그다음부터 화면을 보는 눈이 완전히 달라진다. 초점 테두리를 함부로 지우지 않게 되고, 새 컴포넌트를 만들 때 '이거 키보드로 되나'를 먼저 떠올리게 된다.

이 실험을 할 때 쓰는 키는 사실 몇 개 안 된다. Tab은 다음 요소로, Shift+Tab은 이전 요소로, Enter와 스페이스는 누르기, 화살표는 목록이나 항목 사이 이동, ESC는 닫기. 이 몇 개만 알면 어떤 사이트든 키보드로 끝까지 돌아볼 수 있다. 어렵지 않다. 다만 평소에 안 써봤을 뿐이다. 처음엔 Tab을 어디까지 눌러야 하나 답답하겠지만, 그 답답함 자체가 사이트의 문제를 알려주는 신호다. 잘 만든 사이트는 키보드로도 답답하지 않게 흘러간다. Tab 몇 번이면 핵심 행동에 닿고, 초점이 늘 보이고, 막히는 데가 없다. 그 매끄러움을 한 번 경험하면, 거꾸로 우리 사이트가 어디서 걸리는지가 선명하게 대비돼 보인다.

또 하나 추천하는 방법은 '체크리스트를 만들어 두고 매번 같은 순서로 점검'하는 거다. 메인 화면에서 주 메뉴를 키보드로 열 수 있는가, 초점이 모든 단계에서 보이는가, 신청 양식의 탭 순서가 화면과 맞는가, 팝업에서 키보드로 빠져나올 수 있는가, 본문 바로가기가 있는가. 이렇게 다섯 가지를 고정된 순서로 점검하면, 점검자가 바뀌어도 같은 항목을 같은 기준으로 확인하게 된다. 사람마다 보는 게 다른 문제를 줄이는 작은 장치다.

 

■ 사람의 점검만으로는 부족한 이유

그런데 여기서 현실적인 한계가 있다. 사람이 직접 키보드로 써보는 점검은 강력하지만, 사이트 전체를 매번 그렇게 점검하기는 어렵다. 공공 사이트는 페이지가 수십, 수백 개다. 부서마다 새 페이지가 계속 올라오고, 콘텐츠가 매일 바뀐다. 그 모든 페이지를 사람이 일일이 키보드로 끝까지 써보는 건 현실적으로 불가능하다.

게다가 사람의 점검은 '놓침'이 있다. 한 페이지를 점검하는 데 집중력이 든다. 비슷한 페이지를 수십 개 보다 보면 눈이 무뎌지고, 어느 순간부터는 문제를 봐도 그냥 지나친다. 또 점검하는 사람마다 기준이 조금씩 달라서, A가 잡은 걸 B는 놓치기도 한다. 사람이 하는 점검의 숙명적 한계다.

그래서 필요한 게 '자동 검사'다. 키보드 함정이 있는지, 초점 표시가 없는지, 탭 순서가 어떤지, 본문 바로가기가 있는지 — 이런 것들은 상당 부분 기계가 자동으로 잡아낼 수 있다. 사람이 백 페이지를 일일이 키보드로 누르는 대신, 자동 검사가 백 페이지를 동시에 훑어 문제 지점을 표시해주는 거다. 사람은 그 결과를 보고 '진짜 문제인지'를 판단하는 데 집중하면 된다. 자동 검사가 '넓게 훑는' 역할을, 사람이 '깊게 판단하는' 역할을 나눠 맡는 셈이다.

물론 자동 검사가 모든 걸 잡지는 못한다. '초점 표시가 있긴 한데 너무 흐려서 잘 안 보인다' 같은 미묘한 판단은 결국 사람의 눈이 필요하다. 하지만 자동 검사가 잡을 수 있는 것만 먼저 걸러줘도, 사람이 봐야 할 양이 확 줄어든다. 자동이 90을 걸러주면 사람은 10에 집중하면 되는 거다. 그게 자동 검사의 진짜 가치다.

여기서 자동 검사의 또 다른 큰 장점을 짚고 싶다. '꾸준함'이다. 사람은 컨디션에 따라 점검 품질이 달라진다. 피곤한 날엔 놓치고, 바쁜 날엔 대충 본다. 하지만 자동 검사는 언제 돌려도 같은 기준으로 같은 항목을 본다. 그래서 '매주 정기적으로 사이트 전체를 자동 점검'하는 식의 운영이 가능해진다. 콘텐츠가 매일 바뀌고 페이지가 계속 늘어나는 공공 사이트에서, 이 '꾸준한 자동 점검'은 사람의 손으로는 흉내 낼 수 없는 강점이다. 한 번 잘 만든 사이트도 시간이 지나면 부서별로 새 페이지가 붙으며 다시 망가지기 마련인데, 정기 자동 점검이 있으면 그 균열을 초기에 잡을 수 있다.

또 하나, 자동 검사는 '근거'를 남긴다. 사람이 '여기 좀 이상해요'라고 말하면 주관적으로 들리지만, 자동 검사가 '이 페이지의 이 요소가 어느 항목을 어겼습니다'라고 짚어주면 객관적인 근거가 된다. 이 근거는 특히 외주 업체에 수정을 요청할 때 큰 힘이 된다. '예쁘게 다시 해주세요'가 아니라 '이 항목을 이렇게 고쳐주세요'라고 명확히 요청할 수 있으니, 발주처와 업체 사이의 소모적인 의견 다툼이 줄어든다. 자동 검사 결과는 발주처와 업체가 함께 보는 '공통의 언어'가 되는 셈이다.

 

■ 고치는 것보다 중요한 건 '다시 안 망가지게' 하는 것

마지막으로 한 가지 더. 지금 있는 문제를 고치는 것만큼 중요한 게, '앞으로 다시 안 망가지게' 만드는 거다. 초점 표시를 어렵게 살려놨는데 다음 개편 때 누가 또 거슬린다고 지워버리면 도로 원점이다.

그래서 고치는 작업과 함께 '약속'을 남겨두는 게 좋다. '초점 표시는 함부로 지우지 않는다, 굳이 바꾸려면 대체 표시를 반드시 넣는다' 같은 규칙을 문서로 남기고, 새 페이지를 만들거나 외주를 줄 때 그 규칙을 함께 전달하는 거다. 사람의 기억에만 의존하면 담당자가 바뀌는 순간 사라지지만, 문서로 남으면 조직의 기억으로 이어진다. KRDS 같은 공식 기준을 발주 문서에 한 줄 넣어두는 것도 같은 맥락이다. '우리 사이트는 키보드 접근성을 지킵니다'를 사람이 아니라 기준에 새겨두는 것. 그래야 한 번의 개선이 일회성으로 끝나지 않고 계속 유지된다.

정리하면 접근성은 '한 번 고치고 끝'이 아니라 '계속 지켜내는' 일이다. 그리고 그 '계속 지켜내기'를 사람의 의지에만 맡기면 흔들린다. 규칙으로 남기고, 자동 점검으로 꾸준히 확인하는 두 바퀴가 함께 굴러야 사이트가 시간이 지나도 무너지지 않는다. 고치는 건 시작이고, 유지하는 게 진짜 일이다.

 

【ViewCheck 소개 — 접근성 자동 검사】

여기서 우리 이야기를 잠깐 하려 한다. 사실 이 자동 검사가 우리가 ViewCheck를 만든 이유 중 하나다.

ViewCheck는 공공 웹사이트를 KRDS 기준으로 자동 진단하는 서비스다. KRDS는 공공 웹의 디자인과 사용성을 위한 표준 규칙 묶음인데, ViewCheck는 이를 846개의 규칙으로 잘게 나눠 검사한다. 구체적으로는 기초가 되는 디자인 스타일(DS) 120개, 버튼·입력칸 같은 컴포넌트(CP) 446개, 폼·검증 같은 기본 패턴(BP) 108개, 신청·검색 같은 서비스 패턴(SP) 172개로 구성된다. 846개를 한 번에 자동으로 돌려서, 우리 사이트가 어느 규칙을 지키고 어느 규칙을 어겼는지를 한눈에 보여준다.

오늘 이야기한 키보드와 초점은 그중에서도 접근성과 직결되는 영역이다. ViewCheck는 KRDS 846규칙 점검과 함께, 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역, 그리고 한국형 웹 접근성 지침 KWCAG 33항목을 함께 자동으로 검사한다. 즉 '키보드로 조작 가능한가', '초점이 잘 보이는가', '도달할 수 없는 요소는 없는가' 같은 항목들을 사람이 일일이 누르지 않아도 자동으로 훑어준다.

진단 방법은 정말 간단하다. krds.viewcheck.co.kr에 우리 사이트 주소를 넣기만 하면 된다. 그러면 자동으로 페이지를 돌며 접근성을 포함한 여러 항목을 분석하고, 결과를 점수와 함께 정리해준다. 화면 상단에는 카테고리별 점수 카드(OverviewCards)가 뜨는데, 여기서 디자인·컴포넌트·접근성 같은 영역이 각각 몇 점인지, 어디가 약한지를 바로 파악할 수 있다.

접근성 분석 탭에 들어가면 더 자세히 볼 수 있다. KWCAG 33항목 중 어떤 항목이 통과하고 어떤 항목이 미통과인지, 그 미통과가 어느 페이지의 어느 요소에서 발생했는지까지 짚어준다. 오늘 다룬 다섯 패턴 같은 문제들이 사이트 어디에 숨어 있는지를, 사람이 백 페이지를 일일이 키보드로 눌러보지 않아도 자동으로 모아 보여주는 거다. 한 페이지가 아니라 사이트 전체를 한꺼번에 본다는 점이 특히 중요하다. 접근성 문제는 한 페이지만 고친다고 끝나는 게 아니라 사이트 전체에서 일관되게 지켜져야 하니까.

한 가지 더 강조하고 싶은 건, ViewCheck가 접근성만 보는 도구가 아니라는 점이다. 오늘은 키보드와 초점, 즉 접근성 이야기에 집중했지만, 실제 진단을 돌리면 앞서 말한 행정안전부 7대 영역 전반을 함께 본다. 색·글꼴·간격 같은 디자인 기초가 일관된지, 버튼과 입력칸 같은 컴포넌트가 표준을 지키는지, 신청 같은 서비스 흐름이 매끄러운지까지 한 번에 진단한다. 접근성 문제는 보통 디자인 기초나 컴포넌트 문제와 함께 나타나기 때문에, 이렇게 여러 영역을 한꺼번에 보는 게 실질적인 도움이 된다. 초점이 안 보이는 버튼은 십중팔구 위계도 없고 글자도 제각각인 경우가 많으니까. 한 화면에서 여러 영역의 점수를 동시에 보면, 우리 사이트가 어디서부터 손봐야 하는지 우선순위가 잡힌다.

오해는 말아달라. ViewCheck가 사람의 점검을 완전히 대체한다는 뜻은 아니다. 앞서 말했듯 '초점 표시가 너무 흐리다' 같은 미묘한 판단은 결국 사람의 눈이 필요하다. ViewCheck는 그 사람이 봐야 할 양을 확 줄여주는 도구다. 자동 검사가 넓게 훑어 의심 지점을 모아주면, 담당자는 그 지점들만 집중해서 확인하면 된다. 백 페이지를 다 뒤지는 대신, 표시된 곳만 보면 되는 거다. 한정된 시간과 인력으로 접근성을 챙겨야 하는 공공기관 담당자에게는, 이 '훑어주는 힘'이 실질적인 도움이 된다.

그리고 이게 공짜로 시작할 수 있다는 점도 분명히 말해두고 싶다. krds.viewcheck.co.kr에 들어가 사이트 주소만 넣으면 무료로 진단을 체험할 수 있다. 거창한 계약이나 설치 과정이 필요 없다. 그냥 우리 사이트가 키보드 사용자에게 어떤지, 접근성 점수가 몇 점인지 궁금할 때 부담 없이 한 번 돌려보면 된다. 결과를 받아 보고 '생각보다 괜찮네' 하면 다행이고, '어, 여기가 문제였구나' 하면 그게 바로 개선의 출발점이다. 어느 쪽이든 우리 사이트의 진짜 상태를 아는 게 모든 일의 첫걸음이다.

 

【 마무리 】

오늘 이야기를 정리해보자. 키보드만으로 웹을 쓰는 사람에게 초점 표시는 화면 위의 유일한 이정표다. 그 손전등이 꺼지면 사용자는 길을 잃는다. 그리고 그 손전등은 대부분 '거슬려서 일부러 지웠다가 새로 안 넣어서' 꺼진다. 기술이 어려워서가 아니라, 키보드 사용자를 떠올리지 못해서 생기는 문제다.

다섯 가지 붕괴 패턴을 익명 사례로 봤다. 초점 표시를 통째로 지운 사이트, 들어가면 못 나오는 키보드 함정, 화면과 따로 노는 탭 순서, 키보드로는 닿지 않는 메뉴, 본문 바로가기가 없어 매번 메뉴를 통과해야 하는 사이트. 전부 마우스 사용자에게는 안 보이고 키보드 사용자에게만 또렷한 문제들이다.

그리고 이 모든 문제를 잡는 가장 정직한 첫걸음은, 만드는 사람이 마우스를 내려놓고 직접 키보드로 자기 사이트를 써보는 일이다. 단 한 번만 해봐도 시야가 달라진다. 다만 사이트 전체를 매번 그렇게 점검하긴 어려우니, 넓게 훑는 일은 자동 검사에 맡기고 사람은 깊게 판단하는 데 집중하는 게 현실적인 답이다.

오늘 글을 읽고 딱 하나만 가져간다면, 나는 '마우스를 치우고 Tab을 눌러보라'는 그 한 문장이면 충분하다고 생각한다. 거창한 이론도, 복잡한 도구도 필요 없다. 지금 우리 사이트를 열고, 마우스에서 손을 떼고, Tab을 한 번 눌러보면 된다. 초점이 보이는가. 안 보인다면, 오늘 글에서 이야기한 그 문제가 우리 사이트에도 있는 거다. 보인다면, 그 다음 단계로 넘어가 신청까지 키보드로 가보면 된다. 그 짧은 실험 하나가, '키보드 사용자도 우리 사용자'라는 당연한 사실을 몸으로 깨닫게 해준다. 그리고 그 깨달음이 모든 개선의 출발점이다.

생각해보면 좋은 접근성은 대단한 기술이 아니라 '한 번 더 떠올리는 마음'에서 나온다. 이 버튼을 키보드로도 누를 수 있나, 이 초점이 다른 사람 눈에도 보일까, 이 팝업에서 키보드로 나갈 수 있나. 이런 질문을 만들 때마다 한 번씩 더 떠올리는 사람이 만든 사이트는, 결국 더 많은 사람을 품는다. 기술은 그 마음을 실현하는 도구일 뿐이다. 마음이 먼저고 기술은 그다음이다.

마지막으로 한마디만 더. 접근성은 누군가를 위한 특별한 배려가 아니라, 모두를 위한 기본 품질이다. 키보드로 잘 쓰이는 사이트는 결국 모두에게 더 견고하고 친절한 사이트다. 그리고 공공 서비스는 '누구나' 쓸 수 있어야 한다는 약속 위에 서 있다. 그 약속 안에 키보드 사용자도 분명히 들어 있다는 걸, 오늘 글이 한 번 더 떠올리게 했기를 바란다. 마우스를 잠깐 내려놓는 작은 실험에서, 더 많은 사람을 품는 사이트가 시작된다.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #키보드접근성 #초점표시 #포커스링 #전자정부 #디지털접근성 #공공디자인 #UX #ViewCheck