키보드 접근성 체크리스트

반응형

키보드 접근성 체크리스트

【도입 — 공감·문제제기】

이번 주는 ‘키보드와 초점’이라는 주제로 한 주를 보냈다. 월요일엔 키보드만으로 사이트를 쓰는 사람들이 누구인지, 수요일엔 초점(focus)이라는 게 대체 뭐고 왜 보여야 하는지를 다뤘다. 오늘은 가장 손에 잡히는 이야기다. ‘우리 사이트가 키보드만으로도 제대로 쓰이는가’를 담당자가 직접, 마우스를 손에서 떼고 자기 손으로 확인해보는 체크리스트다.

먼저 솔직하게 한 가지 고백부터 하자. 나도 이 일을 시작하기 전엔 키보드 접근성이라는 말을 들으면 ‘그거 장애인 몇 명 쓰는 거 아니야?’ 하고 한 귀로 흘렸다. 부끄럽지만 사실이다. 그런데 마우스를 책상 서랍에 넣어두고 하루만 우리 사이트를 키보드로 써보고 나서 생각이 완전히 바뀌었다. 키보드만으로는 신청 버튼을 누를 수가 없었다. 정확히 말하면 누를 수는 있는데, ‘지금 내 커서가 어디 있는지’가 화면에 안 보여서 길을 잃었다. 분명 마우스로 볼 땐 멀쩡하던 그 사이트가, 키보드를 쥐는 순간 깜깜한 미로가 됐다. 그날의 당혹감을 잊을 수가 없다.

키보드 접근성은 ‘소수를 위한 배려’가 아니다. 생각보다 훨씬 많은 사람이 매일 키보드로 웹을 쓴다. 손 떨림이 있어 작은 마우스 포인터를 정확히 못 맞추는 어르신, 마우스를 쓰면 손목이 아픈 사무직, 노트북 터치패드가 고장 나 키보드로 버티는 사람, 화면을 못 보고 소리로 사이트를 ‘듣는’ 시각장애인 — 이들에게 키보드는 선택이 아니라 유일한 길이다. 그리고 공공 사이트는 ‘누구도 배제하지 않아야 한다’는 게 그냥 좋은 말이 아니라 법으로 정해진 의무다. 민간 쇼핑몰이라면 ‘우리 주 고객은 마우스 잘 쓰는 사람들이니까’라고 변명이라도 할 수 있지만, 공공 사이트는 ‘우리 국민 중 누구도’ 못 쓰면 안 된다. 그게 공공의 책임이다.

오늘 체크리스트의 핵심 도구는 딱 하나다. ‘마우스를 손에서 떼는 것.’ 거창한 장비도, 전문 지식도, 결재도 필요 없다. 그냥 마우스를 책상 옆으로 밀어두고 Tab 키, 화살표 키, Enter 키, Space 키만으로 우리 사이트를 한 바퀴 돌아보면 된다. 이 단순한 행동 하나가, 마우스로는 절대 안 보이던 우리 사이트의 허점을 줄줄이 드러낸다. 장담컨대 처음 해보면 ‘우리 사이트가 이 정도였어?’ 하고 놀랄 거다. 나도 그랬으니까.

분명히 해둘 게 있다. 이 체크리스트는 KWCAG 33항목을 다 따지는 정밀 진단이 아니다. 그건 사람이 손으로 할 수 있는 일이 아니고, 그래서 도구가 필요하다. 오늘 다룰 건 그중에서도 ‘키보드와 초점’에 직접 관련된, 가장 자주 걸리고 영향이 큰 핵심 항목만 추린 자가 점검표다. 일종의 셀프 건강 체크다. 정밀 검사는 자동 진단 도구에 맡기되, 그 전에 ‘우리 사이트가 키보드로 대충 쓸 만한지’를 내 손으로 가늠해보는 용도다.

준비물은 간단하다. 우리 기관 사이트, 그리고 키보드가 달린 컴퓨터 한 대. 노트북이면 더 좋다. 마우스(혹은 터치패드)를 의식적으로 안 쓰겠다는 마음, 그게 전부다. 펜과 종이(혹은 메모 앱)에 ‘예/아니오’를 적어가며 따라오면 된다. 한 가지 요령을 미리 알려주면, 점검 내내 ‘오른손을 마우스에 올리지 않겠다’고 스스로 약속하는 게 좋다. 우리는 마우스에 너무 익숙해서, 막히는 순간 자기도 모르게 손이 마우스로 간다. 그 순간 점검은 의미를 잃는다. 키보드 사용자는 마우스로 도망칠 수 없으니까. 그러니 오늘만큼은 마우스를 아예 책상에서 치워두길 권한다.

마음가짐도 하나 다잡자. 이건 ‘시험’이 아니라 ‘건강검진’이다. ‘아니오’가 많이 나올수록 점검이 잘된 거다. 문제를 많이 찾았다는 건 고칠 거리를 많이 확보했다는 뜻이고, 그건 우리 사이트가 좋아질 여지가 그만큼 크다는 뜻이다. 반대로 모든 항목에 ‘예’를 적고 있다면, 점검이 잘된 게 아니라 ‘너무 후하게 보고 있는’ 건 아닌지 의심해야 한다. 좋은 점검자는 자기 사이트에 엄격하다. 특히 키보드 접근성은 ‘되긴 되는데 불편한’ 회색 지대가 많아서, 애매하면 ‘아니오’로 적는 게 맞다. 키보드 사용자에게 ‘되긴 되는데 불편한’은 곧 ‘못 쓰는 것’이나 마찬가지이기 때문이다.

그리고 이 점검은 ‘한 번 하고 끝’이 아니라 ‘정기적으로 반복’할 때 진가가 드러난다. 사이트는 살아 있는 생물 같아서, 콘텐츠가 추가되고 새 위젯이 붙고 페이지가 늘어나면서 계속 변한다. 오늘 키보드로 잘 되던 신청 폼이, 반년 뒤 외부 결제 모듈을 새로 붙이면서 키보드로는 못 누르게 바뀌어 있을 수 있다. 그래서 분기에 한 번쯤 같은 체크리스트로 다시 점검하면, 사이트의 키보드 접근성이 좋아지고 있는지 나빠지고 있는지 추세가 보인다. 오늘의 점검은 그 첫 번째 기준점을 찍는 일이다. 자, 마우스 치워두고 시작하자.

 

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

■ 왜 하필 ‘키보드’인가 — 접근성의 가장 기본 뼈대

웹 접근성에는 다룰 게 많다. 색 대비, 대체텍스트, 자막, 명도, 글자 크기… 그런데 왜 이번 주는 굳이 ‘키보드’ 하나에 집중했을까. 이유는 단순하다. 키보드 접근성이 ‘접근성의 가장 밑바닥 뼈대’이기 때문이다.

생각해보자. 시각장애인이 쓰는 화면 낭독기(스크린 리더)는 결국 ‘키보드로 화면을 훑는’ 방식으로 작동한다. 손이 불편해 마우스를 못 쓰는 사람도 키보드(혹은 키보드를 흉내 내는 보조기기)로 웹을 쓴다. 즉, 다양한 보조기술들이 ‘키보드로 조작 가능한가’라는 공통의 토대 위에 서 있다. 그래서 키보드 접근성이 무너지면, 그 위에 쌓인 다른 접근성 노력이 통째로 무너진다. 대체텍스트를 아무리 꼼꼼히 달아놨어도, 그 이미지 버튼을 키보드로 누를 수 없으면 시각장애인은 그 기능을 못 쓴다. 색 대비를 아무리 맞춰놨어도, 그 메뉴에 키보드로 도달할 수 없으면 의미가 없다.

KWCAG(한국형 웹 콘텐츠 접근성 지침)에도 ‘키보드 사용 보장’과 ‘초점 이동’이 핵심 항목으로 들어 있다. 행정안전부 「전자정부 웹사이트 품질관리 지침」의 7대 영역 중 ‘접근성’ 영역이 바로 이걸 따진다. 그러니까 키보드 접근성은 ‘있으면 좋은 부가 기능’이 아니라, 공공 사이트가 갖춰야 할 ‘최소 자격’이다. 이게 안 되면 나머지를 아무리 잘해도 ‘접근성 미달’ 판정을 피하기 어렵다.

 

■ ‘초점(focus)’이 뭐고, 왜 그렇게 중요한가

키보드 접근성을 이야기할 때 빠지지 않는 단어가 ‘초점’이다. 처음 듣는 사람은 ‘사진 초점 맞추는 그거?’ 하고 갸웃하는데, 웹에서의 초점은 ‘지금 키보드 입력을 받는 그 요소’를 말한다. 마우스에는 포인터가 있어서 ‘지금 어디를 가리키는지’ 눈에 보인다. 키보드에는 그 역할을 하는 게 바로 초점이다.

Tab 키를 한 번 누르면 초점이 다음 버튼이나 링크로 옮겨간다. 그때 그 요소 주변에 테두리나 밑줄, 색 변화 같은 ‘초점 표시(focus indicator)’가 떠야, 키보드 사용자가 ‘아, 지금 내가 여기 와 있구나’를 안다. 이 초점 표시가 없으면 어떻게 될까. 키보드 사용자는 Tab을 눌러도 화면에 아무 변화가 안 보이니, ‘지금 내 커서가 어디 있는지’를 전혀 모르게 된다. 마우스 포인터가 화면에서 사라진 채로 클릭해야 하는 상황을 상상해보라. 그게 초점 표시가 없는 사이트를 키보드로 쓰는 사용자의 일상이다.

더 답답한 건, 초점 표시는 원래 브라우저가 ‘기본으로’ 보여주게 되어 있다는 점이다. 아무것도 안 하면 파란 테두리든 점선이든 알아서 뜬다. 그런데 많은 사이트가 ‘그 테두리가 보기 싫다’는 이유로 CSS에서 그걸 일부러 꺼버린다. ‘outline: none’ 한 줄로 초점 표시를 통째로 없애는 거다. 디자이너 눈엔 깔끔해 보이지만, 키보드 사용자에겐 ‘유일한 길안내 표지판’을 뽑아버린 셈이다. 그래서 초점 관련 문제의 상당수는 ‘없어서’가 아니라 ‘있던 걸 일부러 껐기 때문에’ 생긴다. 이게 키보드 접근성의 아이러니다. 가만히 뒀으면 됐을 걸, 손을 대서 망친다.

 

■ 키보드만으로 쓴다는 게 어떤 경험인지

말로만 들으면 잘 안 와닿으니, 키보드 사용자의 실제 경험을 한번 따라가 보자. 그가 우리 사이트에서 ‘민원 신청’을 하려고 한다.

먼저 페이지가 열리면 Tab 키를 누른다. 초점이 첫 번째 링크로 간다. 그런데 화면 어디에도 표시가 안 뜬다. 어디로 갔는지 알 수가 없다. 그래도 Tab을 계속 누른다. 한참을 눌러야 한다. 왜냐하면 상단 메뉴, 로그인, 검색창, 배너의 모든 링크를 하나씩 다 거쳐야 본문에 도달하기 때문이다. 마우스 사용자라면 ‘신청’ 버튼을 바로 클릭하면 되지만, 키보드 사용자는 그 버튼까지 ‘걸어서’ 가야 한다. 그 길이 50번의 Tab이라면, 그는 Tab을 50번 눌러야 한다.

겨우 신청 폼에 도착했다. 첫 입력칸에 초점이 갔는데, 이 칸이 뭘 적는 칸인지 안 보인다. 라벨이 칸 안에 흐린 글씨로만 있다가 사라졌기 때문이다. 화면 낭독기를 쓴다면 ‘편집창’이라고만 읽어줄 뿐 ‘이름’인지 ‘전화번호’인지 안 알려준다. 그는 짐작으로 적는다. 다음 칸으로 가려고 Tab을 누른다. 그런데 초점이 엉뚱한 곳으로 튄다. 화면상으로는 위에서 아래로 칸이 배열돼 있는데, 코드상 순서가 뒤죽박죽이라 초점이 옆 배너로, 다시 맨 아래 푸터로 점프해버린다. 그는 완전히 길을 잃는다.

이 모든 과정에서 그가 ‘어디 있는지’ 알려주는 표시는 하나도 없었다. 결국 그는 신청을 포기한다. 그리고 전화를 건다. 온라인으로 5분이면 끝날 일이, 통화 대기 20분과 창구 방문으로 바뀐다. 이 한 사람의 좌절은 ‘개인의 불운’이 아니다. 우리 사이트의 구조적 결함이 만든 ‘필연’이다. 그리고 같은 결함은 그 사람뿐 아니라, 키보드를 쓰는 모든 사용자에게 똑같이 작동한다.

여기서 짚고 넘어갈 게 있다. 이 시나리오의 어떤 장면도 ‘특별히 악의적으로 만든 사이트’의 이야기가 아니다. 오히려 ‘평범하게, 마우스를 기준으로 잘 만든’ 보통의 공공 사이트에서 그대로 벌어지는 일이다. 만든 사람은 나쁜 의도가 전혀 없었다. 그저 ‘마우스로 잘 되니까 됐다’고 여겼을 뿐이다. 바로 그 ‘마우스로는 잘 된다’는 안심이, 키보드 사용자에겐 벽이 된다. 그래서 키보드 접근성 문제는 ‘누군가의 잘못’이라기보다 ‘마우스 중심으로 일해온 관성’의 결과에 가깝다. 관성은 의식적으로 깨야 보인다. 그 의식적 깨뜨림이 바로 ‘마우스를 잠깐 치워보는 것’이다. 잠깐 그의 입장이 되어 같은 길을 걸어보면, 그동안 안 보이던 벽이 손에 만져진다. 그리고 한번 그 벽을 만져본 담당자는, 다시는 ‘마우스로 되니까 됐다’고 쉽게 말하지 못한다.

 

■ 이 점검이 ‘비용 0’이라는 것

이 점검의 가장 큰 매력은 돈이 안 든다는 거다. 외부 컨설팅을 부르거나 비싼 도구를 사기 전에, 지금 당장 마우스만 치우면 시작할 수 있다. 결재도 필요 없고, 누구의 허락도 필요 없다. 그저 우리 사이트를 ‘키보드 사용자의 손’으로 한 바퀴 돌아보는 것뿐이다.

그리고 이 자가 체크는 ‘대화의 출발점’을 만들어준다. 사이트 개선은 혼자 하는 일이 아니다. 담당 부서, 윗선, 외주 업체가 함께 움직여야 한다. 그런데 ‘우리 사이트 접근성 좀 별로인 것 같아요’라는 막연한 말로는 누구도 안 움직인다. 반면 ‘제가 키보드만으로 신청을 해봤는데, 초점이 안 보여서 끝까지 못 갔습니다. 11개 항목 중 7개가 아니오였어요’라고 하면, 이야기가 구체적인 안건이 된다. 자가 체크는 막연한 문제의식을 ‘말로 꺼낼 수 있는 근거’로 바꿔준다. 손에 쥔 점검 결과 하나가, 미뤄지던 개선 논의를 시작하게 만드는 방아쇠가 된다.

자가 체크가 ‘정밀 진단’을 대체하는 건 아니라는 점도 분명히 해두자. 둘은 역할이 다르다. 자가 체크는 ‘빠르고 거칠게’ 핵심 흐름을 짚는 일이고, 정밀 진단은 ‘느리지만 정확하게’ 모든 페이지의 모든 요소를 따지는 일이다. 키보드 접근성에 빗대면, 자가 체크는 ‘대표 흐름 하나를 키보드로 끝까지 가보는 것’이고, 정밀 진단은 ‘사이트 전체 페이지에서 초점 안 보이는 요소가 몇 개인지 세는 것’이다. 사람은 후자를 못 한다. 한 페이지에 버튼·링크가 수십 개인데, 그게 다 초점이 보이는지 사람이 일일이 세는 건 불가능하다. 그래서 ‘감은 사람이, 셈은 도구가’ 맡는 분업이 정답이다.

 

■ ‘마우스 사용자에겐 안 보인다’는 함정

키보드 접근성 문제가 유독 오래 방치되는 데는 구조적인 이유가 있다. 바로 ‘만든 사람도, 윗선도, 대부분의 방문자도 마우스를 쓰기 때문에 그 문제가 안 보인다’는 점이다. 사이트를 만드는 개발자와 디자이너는 마우스로 작업한다. 검수하는 담당자도 마우스로 클릭하며 확인한다. 결재하는 윗선도 마우스로 본다. 그러니 ‘초점이 안 보인다’거나 ‘키보드로 제출이 안 된다’는 문제는, 마우스를 쥔 그 누구의 눈에도 띄지 않는다. 마우스로는 전부 멀쩡하게 작동하니까. 문제를 겪는 건 오직 ‘키보드로만 쓰는 사용자’뿐인데, 그들은 사이트를 만들거나 검수하는 자리에 거의 없다. 결국 ‘문제를 겪는 사람’과 ‘문제를 고칠 수 있는 사람’이 서로 만나지 못한 채, 결함이 오래 살아남는다.

이 함정에서 빠져나오는 가장 빠른 방법이 바로 오늘 우리가 하는 일이다. ‘마우스를 치우고, 잠깐이라도 키보드 사용자가 되어보는 것.’ 거창한 보조기기도 필요 없다. 그저 마우스를 서랍에 넣고 Tab과 Enter만으로 우리 사이트를 써보는 5분이면, 평소엔 보이지 않던 결함들이 눈앞에 드러난다. ‘아, 이게 이렇게 막혀 있었구나’ 하는 그 한 번의 체감이, 보고서 백 장보다 강력하다. 직접 막혀보고 길을 잃어봐야 비로소 ‘이건 고쳐야 한다’는 마음이 생긴다. 그래서 키보드 자가 점검은 ‘문제를 발견하는 일’인 동시에 ‘고칠 의지를 만드는 일’이기도 하다.

그리고 한 가지 덧붙이면, 키보드 접근성을 잘 챙긴 사이트는 ‘마우스 사용자에게도’ 더 좋은 사이트가 되는 경우가 많다. 초점이 또렷이 보이면 마우스를 쓰다가 키보드로 갈아타도 매끄럽고, Tab 순서가 깔끔하면 폼을 빠르게 채우는 ‘파워 유저’도 편하다. 함정 없는 팝업, ESC로 닫히는 모달, 본문 바로가기 링크 — 이 모든 게 사실은 ‘모두에게’ 편리하다. 접근성은 ‘소수를 위한 특별 대우’가 아니라, ‘결국 다수까지 이롭게 하는 기본기’라는 걸 키보드 점검을 해보면 자연스레 알게 된다.

【본론 2 — 키보드 접근성 체크리스트 (자가 점검 항목)】

이제 본격적으로 점검표를 펼치자. 오늘 체크리스트는 키보드·초점에 관련된 핵심 항목을 다섯 묶음으로 나눴다. 각 묶음에서 핵심 질문 몇 개씩만 던진다. 전부 ‘예/아니오’로 답할 수 있게 만들었다. 묶음은 이렇다.

· K. 키보드 도달성: 모든 기능에 키보드로 갈 수 있나

· F. 초점 가시성: 지금 어디 있는지 보이나

· O. 이동 순서: Tab 순서가 자연스러운가

· T. 함정 탈출: 갇히지 않고 빠져나올 수 있나

· S. 지름길·낭독: 반복을 건너뛰고 소리로 읽히나

왜 이 다섯일까. 키보드로 사이트를 쓰는 경험을 순서대로 따라가 보면 자연스레 이 다섯이 나온다. 먼저 원하는 기능까지 ‘갈 수 있어야’ 하고(K), 가는 동안 ‘내가 어디 있는지 보여야’ 하고(F), 그 이동 ‘순서가 말이 돼야’ 하고(O), 어딘가에 ‘갇히지 않아야’ 하고(T), 매번 똑같은 메뉴를 안 거치게 ‘지름길이 있어야’ 한다(S). 이 다섯을 차례로 보면, 키보드 사용자의 여정을 처음부터 끝까지 빠짐없이 훑게 된다. 곁들이는 사례들은 전부 익명 처리했다. 특정 기관을 흉보려는 게 아니라, 어디서나 반복되는 ‘전형’을 보여주려는 거다. 읽으면서 ‘우리도 저런데’ 싶은 게 나와도 자책할 필요 없다. 대부분이 겪는 일이고, 대부분이 같은 방법으로 풀어왔다.

각 항목을 볼 때 ‘예/아니오’만 적지 말고, ‘아니오’ 옆에 한 줄 메모를 남기길 권한다. 이를테면 ‘F-2 아니오 — 신청 페이지 제출 버튼에 초점 테두리 안 보임’처럼. 이 한 줄이 나중에 ‘무엇을 고쳐야 하는지’를 정확히 짚어주는 작업 지시서가 된다. 점검의 가치는 ‘발견’이 아니라 ‘기록’에서 완성된다. 자, 하나씩 가보자.

 

■ K. 키보드 도달성 체크

K-1. 마우스 없이 Tab 키만으로, 페이지의 모든 메뉴·링크·버튼에 도달할 수 있는가?

→ 자주 보이는 문제: 마우스를 올려야만 펼쳐지는 드롭다운 메뉴. 키보드로는 하위 항목에 영영 못 간다.

K-2. 마우스로만 작동하는 기능(드래그, 더블클릭, 마우스 오버 등)이 키보드로도 되는가?

→ 자주 보이는 문제: 지도 확대, 슬라이드 배너 넘김, 달력 날짜 선택이 마우스 전용이라 키보드로는 멈춰버린다.

K-3. 버튼·링크가 Enter 또는 Space 키로 실제로 눌리는가?

→ 자주 보이는 문제: 보기엔 버튼인데 사실은 ‘클릭만 받는 그림’이라, 키보드로는 초점도 안 가고 눌리지도 않는다.

이 세 항목은 키보드 접근성의 ‘출발선’이다. 여기서 ‘아니오’가 나오면, 그 기능은 키보드 사용자에게 ‘아예 없는 기능’이다. 점검하는 법은 단순하다. 마우스를 치우고, Tab을 눌러 그 기능까지 초점이 가는지 보고, 도착했으면 Enter나 Space로 눌러본다. 가장 흔히 걸리는 게 ‘메인 메뉴’다. 마우스를 올리면 스르륵 펼쳐지는 그 멋진 드롭다운이, 키보드로는 펼쳐지지 않는 경우가 정말 많다. 마우스 사용자는 한 번에 가는 하위 메뉴를, 키보드 사용자는 ‘갈 방법이 없어’ 발이 묶인다. K 영역은 다섯 묶음 중에서도 가장 치명적이다. 도달조차 못 하면, 나머지 점검은 의미가 없으니까.

K 영역을 점검할 때 요령 하나. ‘마우스를 올려야만 뭔가 일어나는’ 모든 요소를 의심하라. 메뉴가 펼쳐지든, 설명 풍선이 뜨든, 이미지가 바뀌든 — 마우스 오버에 반응하는 건 십중팔구 키보드로는 똑같이 안 된다. 마우스에는 ‘올려놓기(hover)’라는 상태가 있지만 키보드에는 그게 없기 때문이다. 그래서 hover에만 의존해 만든 기능은 키보드 사용자에게 통째로 사라진다. 우리 사이트에서 ‘마우스를 올렸을 때만 보이는’ 게 있다면, 그걸 키보드로도 꺼낼 수 있는지 반드시 확인해야 한다.

K 영역에서 또 하나 자주 걸리는 게 ‘외부에서 가져다 붙인 위젯’이다. 지도, 캘린더, 챗봇, 동영상 플레이어, 외부 결제 모듈 같은 것들 말이다. 이것들은 우리가 직접 만든 게 아니라 외부 서비스를 그대로 갖다 끼운 거라, 우리 사이트의 다른 부분은 키보드로 멀쩡한데 그 위젯만 ‘섬’처럼 키보드가 안 통하는 경우가 흔하다. 특히 지도 위젯은 악명이 높다. 마우스로는 드래그해서 움직이고 휠로 확대하지만, 키보드로는 ‘여기 지도가 있다’는 것만 알 뿐 안으로 들어가 조작할 방법이 없는 경우가 많다. 그래서 K 영역을 볼 때는 ‘우리가 만든 부분’과 ‘남이 만들어 붙인 부분’을 나눠서, 특히 후자를 더 의심하며 키보드로 찔러봐야 한다. 외부 위젯이 키보드로 안 된다면, 최소한 그 기능을 ‘다른 방법으로도 쓸 수 있는 길’을 함께 두는 게 차선책이다. 예컨대 지도로만 보여주던 위치를, 글로 된 주소와 약도 설명으로도 제공하는 식이다.

그리고 K 영역에서 가장 헷갈리는 게 K-3, ‘버튼처럼 생겼는데 진짜 버튼인가’이다. 화면상으로는 똑같이 네모난 파란 버튼인데, 어떤 건 진짜 버튼이라 키보드로 초점이 가고 Enter로 눌리고, 어떤 건 ‘버튼처럼 꾸민 그림’이라 키보드로는 초점조차 안 간다. 둘은 눈으로는 구분이 안 된다. 오직 마우스를 치우고 Tab으로 초점을 보내봐야 정체가 드러난다. ‘진짜 버튼’은 Tab을 누르면 초점이 와서 멈추고, ‘가짜 버튼’은 초점이 그냥 지나쳐 버린다. 그래서 K-3 점검은 ‘눈을 믿지 말고 Tab을 믿어라’가 핵심이다. 마우스로는 둘 다 잘 눌려서 만든 사람은 차이를 평생 모를 수 있지만, 키보드 사용자에겐 하나는 ‘기능’이고 하나는 ‘없는 것’이다.

 

■ F. 초점 가시성 체크

F-1. Tab 키를 누를 때, ‘지금 초점이 어디 있는지’ 테두리나 강조 표시가 눈에 보이는가?

→ 자주 보이는 문제: 초점 표시가 통째로 꺼져 있어, 키보드 사용자가 화면 어디에 와 있는지 전혀 모른다.

F-2. 그 초점 표시가 ‘배경과 충분히 구분될 만큼 또렷’한가? (너무 흐리거나 얇지 않은가)

→ 자주 보이는 문제: 표시는 있는데 연한 회색 1픽셀 선이라, 사실상 안 보이는 것과 같다.

F-3. 버튼, 링크뿐 아니라 입력칸, 체크박스, 드롭다운에도 초점 표시가 보이는가?

→ 자주 보이는 문제: 버튼엔 있는데 입력칸엔 없거나, 커스텀 디자인한 체크박스만 초점 표시가 빠져 있다.

F 영역이 오늘의 핵심이다. ‘초점이 보이는가’ 하나만 제대로 봐도 키보드 접근성의 절반은 점검한 셈이다. 점검법은 이렇다. 마우스를 치우고 Tab을 한 번씩 천천히 누르며, 누를 때마다 ‘화면 어딘가가 또렷하게 강조되는가’를 본다. 강조가 보이면 통과, ‘어디가 바뀌었는지 한참 찾아야’ 하면 아니오다. 이때 중요한 건 ‘있다/없다’만 보지 말고 ‘충분히 또렷한가’까지 보는 거다. 흐린 1픽셀 선은 ‘있어도 없는 것’이다. 멀찍이 떨어져서 봐도 ‘아, 저기 있구나’ 하고 한눈에 들어와야 진짜 초점 표시다.

앞서 말했듯, 초점 표시 문제의 대부분은 ‘없어서’가 아니라 ‘끄거나 가렸기 때문에’ 생긴다. 브라우저는 원래 초점 표시를 알아서 보여준다. 그런데 ‘그 파란 테두리가 디자인을 해친다’는 이유로 그걸 일부러 없애는 경우가 많다. 그러니 F 영역에서 ‘아니오’가 나왔다면, 해법은 의외로 간단할 때가 많다. ‘껐던 걸 다시 켜는 것’ 혹은 ‘브랜드 색에 맞는 또렷한 표시로 바꿔주는 것’이다. 없는 걸 새로 만드는 게 아니라, 가렸던 걸 다시 드러내는 일이라 비용이 크지 않다. F 영역의 ‘아니오’를 ‘예’로 바꾸는 건, 키보드 접근성 점수를 가장 적은 비용으로 끌어올리는 길이다.

F 영역에서 의외로 많이 놓치는 게 ‘커스텀 요소’다. 기본 버튼·링크는 초점이 잘 보이는데, 디자이너가 예쁘게 새로 만든 체크박스, 토글 스위치, 별점 같은 ‘직접 만든 부품’에는 초점 표시가 빠져 있는 경우가 흔하다. 기본 부품을 안 쓰고 새로 만들면, 브라우저가 챙겨주던 초점 표시도 함께 사라지기 때문이다. 그래서 F 영역을 볼 때는 ‘평범한 버튼’만 보지 말고, ‘좀 특이하게 생긴 요소들’을 일부러 찾아가 Tab으로 초점을 맞춰봐야 한다. 예쁜 부품일수록 초점이 안 보일 확률이 높다는 걸 기억하자.

F 영역을 점검할 때 한 가지 현실적인 요령을 더 보태면, ‘모니터 밝기를 살짝 낮추거나 한 발 물러나서’ 보는 것이다. 초점 표시가 ‘있긴 있는데 너무 흐려서 사실상 안 보이는’ 경우를 잡아내기 위해서다. 코앞에서 화면을 뚫어져라 보면 연한 회색 1픽셀 선도 ‘보인다’고 우기게 되지만, 한 발 물러나서 평범한 사용 거리에서 보면 ‘저게 강조된 건지 아닌지’ 헷갈린다. 그 헷갈림이 곧 ‘아니오’의 신호다. 키보드 사용자는 화면에 코를 박고 쓰지 않는다. 보통의 거리에서, 보통의 밝기로, 빠르게 Tab을 누르며 ‘지금 어디 와 있지’를 순간적으로 파악해야 한다. 그러니 점검도 그 ‘보통의 조건’에서 해야 진짜다. 또 하나, 흰 배경 위에서만 보지 말고 색이 있는 배경, 이미지 위에 얹힌 버튼에서도 초점이 보이는지 봐야 한다. 흰 바탕에선 또렷하던 표시가, 짙은 배너 위 버튼에선 배경에 묻혀 사라지는 경우가 있기 때문이다. 초점 표시는 ‘어떤 배경 위에서도’ 보여야 제 몫을 한다.

 

■ O. 이동 순서(Tab order) 체크

O-1. Tab을 연달아 누를 때, 초점이 ‘위에서 아래로, 왼쪽에서 오른쪽으로’ 자연스럽게 흐르는가?

→ 자주 보이는 문제: 화면 배열과 초점 순서가 달라, 본문 입력칸을 채우다 갑자기 푸터로 튄다.

O-2. 화면에 ‘보이는 순서’와 키보드로 ‘도달하는 순서’가 일치하는가?

→ 자주 보이는 문제: 나중에 끼워 넣은 배너나 팝업이 초점 순서 맨 앞으로 끼어들어, 본문에 가기 전에 광고부터 거친다.

O-3. 신청·검색 같은 핵심 흐름에서, 초점 순서만 따라가도 ‘일을 끝까지 마칠’ 수 있는가?

→ 자주 보이는 문제: 제출 버튼이 초점 순서에서 빠져 있어, 다 채워놓고도 키보드로는 제출을 못 한다.

이동 순서는 ‘초점이 보이는가’ 다음으로 중요하다. 초점이 보여도 순서가 엉망이면, 키보드 사용자는 화면을 위아래로 정신없이 오가며 멀미를 한다. 점검법은 마우스를 치우고 Tab만 연달아 누르며, 초점이 ‘예상한 대로’ 움직이는지 눈으로 따라가는 거다. 신청 폼이라면 첫 칸 → 둘째 칸 → 셋째 칸 → 제출 버튼 순으로 자연스럽게 흘러야 한다. 그런데 셋째 칸을 채우고 Tab을 눌렀더니 초점이 오른쪽 배너로, 다시 맨 아래 푸터 링크로 튄다면, 그건 ‘화면에 보이는 순서’와 ‘코드상 순서’가 어긋난 거다. 사용자는 ‘내가 뭘 잘못 눌렀나’ 당황하다 흐름을 잃는다.

O 영역의 문제는 대개 ‘나중에 뭔가를 끼워 넣으면서’ 생긴다. 처음 만들 땐 순서가 멀쩡했는데, 운영하다 배너를 추가하고 팝업을 붙이고 외부 위젯을 삽입하면서 초점 순서가 뒤엉킨다. 특히 ‘긴급 공지’ 같은 팝업이 초점 순서 맨 앞으로 끼어들면, 키보드 사용자는 페이지에 들어서자마자 광고부터 거쳐야 본문에 닿는다. 그래서 O 영역은 ‘새 요소를 붙일 때마다’ 다시 점검하는 게 좋다. 한 번 맞춰놨다고 영원히 유지되는 게 아니다. 사이트가 변하면 초점 순서도 함께 흔들린다.

O 영역에서 가장 뼈아픈 ‘아니오’는 O-3이다. 다 채워놓고 제출을 못 하는 경우다. 사용자가 키보드로 한참 폼을 채웠는데, 정작 ‘제출’ 버튼이 초점 순서에서 빠져 있어 그 버튼에 영영 도달할 수 없다면, 그동안의 노력이 통째로 무너진다. 더 답답한 건 이게 마우스로는 멀쩡해 보인다는 점이다. 마우스 사용자는 그냥 제출 버튼을 클릭하면 되니까. 그래서 만든 사람은 이 문제를 평생 모를 수 있다. O-3은 반드시 ‘마우스를 치우고 핵심 흐름을 끝까지 키보드로 완주’해봐야만 발견된다. 우리 사이트에서 가장 많이 쓰는 신청·검색 흐름 하나만이라도, 시작부터 ‘제출 완료’까지 키보드로 끝까지 가보길 강력히 권한다.

 

■ T. 함정 탈출(키보드 트랩) 체크

T-1. 팝업·달력·동영상 같은 요소에 초점이 들어갔을 때, 다시 빠져나올 수 있는가?

→ 자주 보이는 문제: 팝업 안에 초점이 갇혀, Tab을 아무리 눌러도 팝업 밖으로 못 나간다. 페이지를 닫는 수밖에 없다.

T-2. 팝업(모달)이 떴을 때, ESC 키로 닫을 수 있는가?

→ 자주 보이는 문제: 닫기 버튼이 마우스로만 눌리고, 키보드로는 그 버튼에 초점도 안 가서 영영 못 닫는다.

T-3. 자동으로 넘어가는 슬라이드·캐러셀이 키보드 조작을 방해하지 않는가?

→ 자주 보이는 문제: 자동 재생 배너에 초점이 닿을 때마다 화면이 멋대로 넘어가, 키보드 사용자가 조작을 못 한다.

‘키보드 트랩’은 키보드 접근성에서 가장 악질적인 문제다. 도달은 했는데 빠져나올 수가 없다. 마우스 사용자는 그냥 다른 데를 클릭하면 그만이지만, 키보드 사용자는 Tab과 화살표 키밖에 없으니, 갇히면 정말로 갇힌다. 페이지를 통째로 닫고 다시 여는 수밖에 없다. 점검법은 의심스러운 요소(팝업, 달력, 동영상 플레이어, 외부 위젯)마다 일부러 초점을 넣어보고, Tab을 계속 눌러 ‘다시 밖으로 나올 수 있는지’ 확인하는 거다. 나올 수 있으면 통과, 같은 자리만 빙빙 돌면 트랩이다.

T 영역에서 특히 자주 걸리는 게 ‘팝업(모달)’이다. 공공 사이트는 긴급 공지, 만족도 조사, 안내 알림 같은 팝업을 자주 띄운다. 그런데 이 팝업들이 ‘ESC로 못 닫고, 닫기 버튼에 초점도 안 가는’ 경우가 흔하다. 마우스 사용자는 닫기 X를 클릭하면 되지만, 키보드 사용자는 그 X에 도달할 방법이 없어 페이지를 떠나야 한다. 들어오자마자 못 닫는 팝업에 갇혀 쫓겨나는 셈이다. 그래서 T-2(ESC로 닫기)는 팝업을 자주 쓰는 사이트라면 꼭 챙겨야 한다. ‘떴으면 닫을 수 있어야’ 한다는 건 너무 당연한데, 의외로 많이 빠져 있다.

자동 재생 슬라이드(T-3)도 키보드 사용자에겐 골칫거리다. 메인 상단의 그 화려한 자동 배너가, 초점이 닿을 때마다 멋대로 넘어가면 키보드 사용자는 ‘읽으려는데 자꾸 바뀌는’ 상황에 빠진다. 그래서 자동 슬라이드에는 ‘멈춤’ 기능이 키보드로도 작동해야 하고, 좌우 화살표로 직접 넘길 수 있어야 한다. 움직임을 사용자가 통제할 수 있게 해주는 것 — 그게 자동 요소를 다룰 때의 기본 예의다.

 

■ S. 지름길·낭독 체크

S-1. 매 페이지마다 반복되는 메뉴를 건너뛰고 ‘본문으로 바로 가기’ 같은 지름길이 있는가?

→ 자주 보이는 문제: 본문에 가려면 매번 상단 메뉴 수십 개를 Tab으로 다 거쳐야 한다. 페이지를 옮길 때마다 반복된다.

S-2. 화면 낭독기로 들었을 때, 버튼·링크·입력칸이 ‘무엇인지’ 제대로 읽히는가?

→ 자주 보이는 문제: 이미지 버튼이 ‘버튼’이라고만 읽히고 무슨 버튼인지 안 읽혀, 무엇을 누르는지 알 수 없다.

S-3. 입력칸에 ‘이 칸이 무엇인지’ 라벨이 코드 차원에서 연결돼 있는가? (시각적 라벨만이 아니라)

→ 자주 보이는 문제: 눈으로는 라벨이 보이는데 코드상 연결이 안 돼 있어, 낭독기는 ‘무슨 칸인지’ 못 읽어준다.

S 영역은 키보드 접근성의 ‘완성도’를 가르는 부분이다. S-1의 ‘건너뛰기 링크(skip navigation)’는 작아 보여도 효과가 크다. 페이지마다 반복되는 상단 메뉴를, 본문 읽으러 온 키보드 사용자가 매번 다 거치는 건 엄청난 고역이다. 페이지를 열 번 옮기면 그 수십 번의 Tab을 열 번 반복해야 한다. ‘본문 바로가기’ 링크 하나만 맨 앞에 둬도, 키보드 사용자는 Tab 한두 번으로 본문에 도착한다. 점검법은 페이지를 열고 Tab을 처음 눌렀을 때 ‘본문 바로가기’ 같은 링크가 뜨는지 보는 거다. 평소엔 숨어 있다가 Tab을 누르면 나타나게 만든 경우가 많으니, 첫 Tab을 유심히 보자.

S-2와 S-3은 화면 낭독기와 직결된다. 키보드 접근성은 결국 ‘소리로 듣는 사용자’를 위한 토대라고 했다. 그러니 키보드로 도달 가능한 것에서 한 발 더 나아가, 그 요소가 ‘무엇인지 제대로 읽히는가’까지 봐야 완성이다. 이미지로 만든 버튼이 ‘버튼’이라고만 읽히고 ‘검색 버튼’인지 ‘메뉴 버튼’인지 안 읽히면, 듣는 사용자는 ‘이게 무슨 버튼이지’ 하며 멈춘다. 입력칸도 마찬가지다. 눈으로 보면 ‘이름’이라는 라벨이 칸 옆에 있어도, 그게 코드 차원에서 그 칸과 ‘연결’돼 있지 않으면 낭독기는 둘을 따로 읽어, 사용자는 어느 라벨이 어느 칸인지 못 짝지운다. 이건 화면 낭독기를 켜고 직접 들어봐야 알 수 있어서 자가 체크가 좀 까다롭지만, 운영체제에 기본 내장된 낭독기를 켜서 핵심 폼 하나만이라도 들어보면 큰 도움이 된다.

S 영역에서 한 가지 덧붙이면, ‘건너뛰기 링크’는 ‘있다’만으로는 부족하고 ‘실제로 본문으로 정확히 데려다주는가’까지 봐야 한다. 가끔 본문 바로가기 링크가 있긴 한데, 눌러도 엉뚱한 곳으로 가거나 초점이 본문이 아닌 빈 곳에 떨어지는 경우가 있다. 이러면 ‘있으나 마나’다. 그러니 S-1을 점검할 때는 링크가 보이는 것에 그치지 말고, Enter를 눌러 ‘초점이 진짜 본문 첫머리로 옮겨가는지’까지 확인하자. 작은 기능일수록 ‘되는 척만 하는’ 경우가 많아서, 끝까지 눌러봐야 진짜가 가려진다.

이렇게 다섯 묶음, 열 몇 개 항목을 마우스 없이 한 바퀴 돌고 나면, 우리 사이트가 키보드 사용자에게 어떤 곳인지 감이 잡힐 거다. ‘예’가 많으면 다행이고, ‘아니오’가 많으면 고칠 거리를 그만큼 많이 확보한 거다. 어느 쪽이든 점검은 성공이다. 그리고 점검을 마쳤다면, 가장 많이 나온 ‘아니오’가 어느 묶음인지를 한번 보자. 그게 우리 사이트의 ‘가장 약한 고리’이고, 거기서부터 손대는 게 효율적이다. 보통 F(초점 가시성)에서 ‘아니오’가 가장 많이 나오는데, 앞서 말했듯 F는 비용 대비 효과가 가장 좋은 영역이라 거기부터 잡으면 같은 노력으로 가장 큰 개선을 얻는다.

【본론 3 — 점검 후 무엇을 어떻게 고칠까 (단계별 실행법)】

체크리스트로 ‘아니오’를 찾았다면, 이제 ‘그래서 뭘 어떻게 고치나’가 궁금할 거다. 여기서는 발견한 문제를 실제로 손보는 단계별 실행법을 정리한다. 한꺼번에 다 고치려 들면 지쳐 나가떨어지니, 효과 큰 것부터 차례로 가는 게 핵심이다.

■ 1단계 — ‘초점부터 켜라’ (가장 싸고 효과 큰 일)

만약 F 영역(초점 가시성)에서 ‘아니오’가 나왔다면, 무조건 여기부터 손대라. 이유는 두 가지다. 첫째, 효과가 가장 크다. 초점이 보이기만 해도 키보드 사용자의 ‘길 잃음’이 단번에 해소된다. 둘째, 비용이 가장 작다. 앞서 말했듯 초점 표시는 대개 ‘없어서’가 아니라 ‘꺼서’ 안 보이는 거라, ‘껐던 걸 되살리는’ 일이라 손이 적게 간다.

실무적으로는 외주 업체나 개발 담당에게 이렇게 전하면 된다. ‘CSS에서 outline을 없앤 부분을 찾아, 브랜드 색에 맞는 또렷한 초점 표시로 되살려 달라.’ 디자인이 걱정된다면 ‘기본 파란 테두리 대신, 우리 사이트 색에 어울리는 두껍고 또렷한 테두리’를 요청하면 된다. 초점 표시를 ‘없애는 것’이 아니라 ‘예쁘게 다듬는 것’이 정답이다. 이 한 가지만 제대로 해도 키보드 접근성 점수가 눈에 띄게 오른다.

 

■ 2단계 — ‘핵심 흐름 하나를 끝까지 통하게’

다음은 사용자가 가장 많이 쓰는 흐름 하나를 골라, 키보드로 ‘시작부터 끝까지’ 완주되게 만드는 일이다. 모든 페이지의 모든 기능을 다 고칠 순 없으니, ‘가장 많이 쓰는 흐름 하나’에 집중하는 게 현실적이다. 민원 신청이 잦은 곳이라면 그 신청 흐름을, 자료 검색이 잦은 곳이라면 검색 흐름을 고른다.

그 흐름을 키보드로 따라가며 막히는 지점을 다 적는다. 메뉴에서 못 펼쳐지는가(K), 초점이 안 보이는가(F), 순서가 튀는가(O), 어디 갇히는가(T), 제출 버튼에 도달 못 하는가(O-3) — 막히는 곳마다 메모하고, 그걸 ‘이 흐름이 키보드로 끝까지 되게 해달라’는 한 묶음의 요청으로 정리해 전달한다. 흩어진 자잘한 수정 요청보다, ‘이 흐름 하나를 완주되게’라는 분명한 목표가 일을 훨씬 잘 굴러가게 한다. 가장 많이 쓰는 흐름 하나가 키보드로 매끄러워지면, 사용자 대다수가 그 혜택을 본다.

 

■ 3단계 — ‘함정부터 없애라’

키보드 트랩(T)이 발견됐다면 우선순위를 높여야 한다. 트랩은 ‘불편’이 아니라 ‘차단’이기 때문이다. 사용자를 가둬 페이지를 떠나게 만드는 건, 그 자체로 ‘서비스 실패’다. 특히 자주 뜨는 팝업이 ESC로 안 닫히거나 닫기 버튼에 초점이 안 가면, 그건 모든 키보드 사용자를 매번 내쫓는 셈이라 빨리 고쳐야 한다. ‘떴으면 닫을 수 있게, 들어갔으면 나올 수 있게’ — 이 단순한 원칙만 지켜도 트랩은 사라진다.

 

■ 4단계 — ‘지름길과 라벨을 채워라’

여유가 생기면 S 영역을 손본다. ‘본문 바로가기’ 링크를 맨 앞에 하나 넣어주는 건 작은 작업이지만, 페이지를 자주 옮기는 키보드 사용자에겐 매번 수십 번의 Tab을 아껴주는 큰 선물이다. 입력칸과 라벨을 코드 차원에서 연결하고, 이미지 버튼에 ‘무슨 버튼인지’ 설명을 달아주는 일도 이 단계에서 한다. 화면에 ‘보이는 것’을 넘어 ‘들리는 것’까지 챙기는 단계라고 보면 된다.

 

■ 외주에 맡길 때 ‘무엇을’ 요구해야 하나

공공 사이트는 직접 고치기보다 외주 업체에 맡기는 경우가 많다. 그런데 ‘접근성 좀 신경 써 주세요’라는 막연한 요청으로는 원하는 결과가 안 나온다. 너무 두루뭉술해서 업체도 ‘어디까지 해야 하나’ 가늠을 못 하고, 결과물을 받아도 ‘이게 잘된 건지’ 검수할 기준이 없다. 그래서 오늘 같은 체크리스트가 외주 관리에서 특히 빛을 발한다. ‘키보드만으로 신청 흐름이 끝까지 완주되어야 한다(O-3)’, ‘모든 초점 표시가 브랜드 색으로 또렷하게 보여야 한다(F-1, F-2)’, ‘모든 팝업은 ESC로 닫혀야 한다(T-2)’ 같은 구체적 항목을 계약서나 검수 기준에 적어두면, 업체도 ‘무엇을 해야 하는지’ 분명히 알고, 우리도 ‘됐는지 안 됐는지’를 마우스 치우고 직접 확인할 수 있다. 막연한 ‘잘 해주세요’를 ‘이 항목들을 통과시켜 주세요’로 바꾸는 것 — 그게 외주 결과물의 품질을 끌어올리는 가장 확실한 방법이다. 그리고 납품받은 뒤에도 반드시 오늘 체크리스트로 ‘우리 손으로’ 한 번 더 키보드 점검을 하길 권한다. 업체가 ‘됐다’고 한 것과, 우리가 마우스를 치우고 직접 써본 것은 다를 수 있다.

 

■ 단계별로 가되, 기록을 남겨라

이 모든 과정에서 잊지 말 것은 ‘기록’이다. 고치기 전 상태를 적어두고, 고친 뒤 다시 키보드로 점검해 ‘무엇이 나아졌는지’를 남긴다. 이 전후 기록이 있어야, 윗선에 ‘우리가 이만큼 개선했다’고 보여줄 수 있고, 다음 점검 때 ‘어디까지 했는지’를 이어갈 수 있다. 접근성 개선은 한 번에 끝나는 일이 아니라, 분기마다 조금씩 쌓아가는 일이다. 그 ‘쌓임’을 눈에 보이게 만드는 게 기록이다.

여기서 한 가지 한계도 솔직히 인정하자. 사람의 손으로 하는 자가 점검은 ‘대표 흐름 몇 개’를 보는 게 한계다. 공공 사이트는 페이지가 수십, 수백 개인데, 그 모든 페이지의 모든 버튼이 초점이 보이는지 사람이 일일이 셀 수는 없다. ‘우리가 점검한 그 페이지’는 멀쩡해도, 사용자가 많이 쓰는 안쪽의 어떤 페이지엔 초점이 통째로 꺼진 폼이 방치돼 있을 수 있다. 그래서 자가 점검으로 감을 잡았다면, 그다음엔 ‘사이트 전체를 빠짐없이 세어주는’ 도구의 손을 빌릴 차례다.

 

【본론 4 — 자가 점검을 ‘숫자’로 확정하기】

지금까지 한 자가 점검은 ‘사람의 감각’을 기르는 일이었다. 마우스를 치우고 직접 막혀보고 길을 잃어봤으니, 키보드 사용자의 불편이 ‘머리’가 아니라 ‘몸’으로 이해됐을 거다. 이 감각은 무엇과도 바꿀 수 없는 자산이다. 그런데 감각만으로는 부족한 지점이 있다. 바로 ‘규모’와 ‘근거’다.

규모 이야기부터 하자. 자가 점검으로는 페이지 몇 개를 직접 키보드로 돌아볼 수 있을 뿐이다. 사람은 한 페이지의 버튼·링크가 50개일 때, 그게 다 초점이 보이는지 일일이 셀 수 없다. ‘대충 보이네’로 뭉뚱그릴 뿐이다. 게다가 사이트 전체가 수백 페이지라면, 손으로는 표본 몇 개만 보고 전체를 짐작하는 수밖에 없다. 그런데 정작 키보드 접근성 문제는 ‘사용자가 많이 쓰는 안쪽 페이지’에 숨어 있는 경우가 많다. 메인은 멀쩡한데 신청 폼은 엉망인 식이다. 자동 진단은 이걸 다르게 한다. 사이트의 여러 페이지를 한꺼번에 훑어, 초점이 안 보이는 요소가 몇 개인지, 키보드로 도달 못 하는 기능이 어느 페이지에 몇 건인지를 ‘숫자’로 세어준다. 사람이 표본으로 놓치기 쉬운 방치된 안쪽 페이지를, 도구는 빠짐없이 짚는다.

근거 이야기도 중요하다. 공공기관에서 무언가를 바꾸려면 ‘왜 바꿔야 하는지’를 설득해야 하는데, 그 설득의 가장 강력한 무기가 ‘객관적 근거’다. ‘제가 키보드로 써보니 좀 불편하더라고요’와 ‘접근성 영역 미준수가 OO건, 그중 초점 미표시가 OO건입니다’는 회의실에서의 무게가 전혀 다르다. 후자는 누구도 ‘그건 네 주관이잖아’라고 반박할 수 없다. 게다가 그 숫자가 KWCAG, 그리고 행정안전부 「전자정부 웹사이트 품질관리 지침」 7대 영역 중 접근성이라는 공식 기준에 근거하면, 권위까지 얹힌다. 막연한 문제의식에 ‘공식 기준이라는 권위’와 ‘숫자라는 객관성’을 입혀, 미뤄지던 개선을 실제로 움직이게 만드는 것 — 이게 자동 진단이 실무에서 발휘하는 가장 큰 힘이다.

여기서 ViewCheck 이야기를 잠깐 하겠다. ViewCheck는 우리 사이트 주소만 넣으면 KRDS 846규칙(DS 120 + CP 446 + BP 108 + SP 172)을 기준으로 자동 진단을 돌려주는 도구다. 846규칙 중 접근성·키보드·초점과 관련된 항목들이, 오늘 우리가 손으로 점검한 그 ‘아니오’들을 자동으로 잡아낸다. 사람이 셀 수 없던 ‘초점 안 보이는 요소가 몇 개인지’, ‘키보드로 도달 못 하는 기능이 어느 페이지에 있는지’를 숫자로 정리해준다. 게다가 한 페이지가 아니라 여러 페이지를 한꺼번에 돌려, ‘메인은 괜찮은데 신청 페이지가 약하다’ 같은 페이지별 편차까지 보여준다. 자가 점검이 ‘감’을 줬다면, 자동 진단은 그 감을 ‘흔들림 없는 숫자’로 고정해준다.

또 하나의 이점은 ‘반복 점검의 비용이 0에 수렴한다’는 거다. 자가 점검은 할 때마다 사람의 시간을 쓴다. 페이지가 많으면 그 시간이 만만치 않다. 반면 자동 진단은 한 번 주소를 넣어두면, 다음 점검 때도 같은 기준으로 같은 페이지들을 일관되게 분석한다. 사람이 그날 컨디션에 따라 후하게/박하게 보는 ‘들쭉날쭉함’도 없다. 같은 기준으로 매번 측정하니, ‘작년 이맘때보다 키보드 접근성이 좋아졌나’를 따질 때 사람의 기억보다 훨씬 믿을 만하다.

물론 자동 진단이 모든 걸 대신하진 않는다. 화면 낭독기로 들었을 때 ‘설명이 자연스러운가’ 같은 건 결국 사람이 들어봐야 안다. 그래서 가장 좋은 방식은 ‘분업’이다. 자동 진단은 사람이 일일이 세기 힘든 걸 대신 세어주고, 사람은 그 위에서 ‘무엇을 먼저 고칠지’, ‘이 개선이 우리 사용자에게 정말 도움이 되는지’를 판단한다. 오늘 마우스를 치우고 한 자가 점검은, 바로 그 ‘사람의 판단력’을 기르는 연습이기도 했다.

자, 오늘 자가 점검에서 ‘아니오’가 많이 나왔다면, 그 막연한 불안을 구체적인 점수와 항목으로 바꿔보자. 분석을 돌리면 결과 화면 맨 위에 점수 카드가 한눈에 뜨는데, 거기서 접근성 영역이 몇 점인지, 어떤 항목이 빨강인지를 바로 확인할 수 있다. 아래 캡쳐는 웹 접근성(KWCAG) 분석 탭 결과 화면이다. (기관 식별 정보는 가린 것이다.)

【본론 5 — 자주 듣는 오해와 솔직한 답】

키보드 접근성 이야기를 꺼내면 현장에서 꼭 나오는 반응들이 있다. 그중 자주 듣는 오해 몇 가지에, 솔직하게 답해보려 한다. 변명 없이, 겪어본 사람의 입장에서.

■ “우리 사이트 이용자 중에 키보드만 쓰는 사람이 몇이나 되겠어요?”

가장 많이 듣는 말이다. 그런데 이 질문 자체에 함정이 있다. 통계에 안 잡히는 이유가 ‘그런 사람이 없어서’가 아니라 ‘못 쓰고 떠났기 때문’일 수 있다는 거다. 키보드로 신청을 시도하다 초점이 안 보여 포기한 사람은, 우리 통계에 ‘방문은 했지만 신청 못 한 사람’으로만 남거나 아예 흔적도 안 남는다. ‘이용자가 적다’가 아니라 ‘이용을 못 해서 안 보이는’ 것일 수 있다. 게다가 키보드 사용자는 ‘시각장애인’만이 아니다. 손 떨림이 있는 어르신, 손목이 아픈 사람, 터치패드가 고장 난 사람, 그냥 키보드가 빠른 사람까지 — 생각보다 넓다. 무엇보다 공공 사이트는 ‘몇 명이냐’로 따질 문제가 아니다. 단 한 명이라도 ‘국민이기에’ 못 쓰면 안 되는 게 공공의 원칙이다.

 

■ “접근성은 개발 다 끝나고 마지막에 챙기면 되는 거 아닌가요?”

이게 가장 비싸게 치르는 오해다. 접근성을 ‘마지막 단계의 검수 항목’쯤으로 여기면, 이미 다 만들어진 사이트를 뜯어고쳐야 한다. 초점 순서를 다시 짜고, 마우스 전용으로 만든 기능을 키보드용으로 다시 만드는 건, 처음부터 고려해 만드는 것보다 몇 배 더 든다. 반면 ‘만드는 도중에’ 마우스를 치우고 한 번씩 점검하면, 문제를 그 자리에서 작게 잡는다. 그래서 오늘 체크리스트를 ‘다 만든 사이트 검수용’으로만 쓰지 말고, ‘새 페이지를 만들 때마다 옆에 두고 보는 상시 기준’으로 삼으라고 권하는 거다. 가장 싼 접근성은 ‘나중에 고치는 접근성’이 아니라 ‘처음부터 챙기는 접근성’이다.

 

■ “초점 테두리, 디자인 망치지 않나요?”

디자이너들이 가장 걱정하는 부분이다. 솔직히 인정하자. 브라우저 기본 초점 테두리는 예쁘지 않다. 그래서 많은 사이트가 그걸 꺼버린다. 하지만 ‘끄는 것’과 ‘예쁘게 다듬는 것’은 다르다. 초점 표시를 없애는 대신, 우리 브랜드 색에 어울리는 또렷하고 단정한 표시로 바꾸면 된다. 디자인을 해치지 않으면서도 키보드 사용자에게 길을 안내할 수 있다. ‘초점 표시는 디자인의 적’이 아니라 ‘디자인이 품어야 할 요소’다. 잘 만든 사이트들은 초점 표시까지 브랜드의 일부로 디자인한다. 없애는 게 능사가 아니라, ‘우리답게 또렷하게’가 정답이다.

 

■ “자동 진단 도구만 돌리면 되는 거 아니에요? 굳이 손으로 점검을 왜?”

도구는 ‘셀 수 있는 것’을 센다. 초점 표시가 코드상 꺼졌는지, 라벨이 연결됐는지 같은 건 도구가 빠르고 정확하게 잡는다. 하지만 ‘초점 순서가 사용자 입장에서 자연스러운가’, ‘이 흐름을 처음 온 사람이 키보드로 끝까지 마칠 수 있는가’ 같은 ‘경험의 질’은 결국 사람이 직접 써봐야 안다. 그래서 도구와 사람은 경쟁 관계가 아니라 분업 관계다. 도구가 ‘무엇이 빠졌는지’ 목록을 주면, 사람은 그 위에서 ‘무엇이 가장 불편한지’를 판단한다. 오늘 손으로 한 점검은 바로 그 ‘사람의 판단력’을 기르는 일이었고, 그 감각이 있어야 도구의 결과지도 제대로 읽힌다.

이런 오해들의 공통점이 있다. 전부 ‘마우스를 쓰는 사람의 시선’에서 나온 말이라는 거다. 마우스를 치워보면 이 오해들은 대부분 저절로 풀린다. 직접 막혀보면 ‘몇 명이나 쓰겠어’라는 말이 안 나오고, 직접 고쳐보면 ‘디자인 망친다’는 걱정이 ‘이렇게 다듬으면 되는구나’로 바뀐다. 그래서 모든 답의 출발점은 같다. 일단 마우스를 치워보는 것.

 

【 마무리 】

이번 주를 한 줄로 정리하면 이렇다. ‘마우스를 손에서 떼는 순간, 우리 사이트의 진짜 모습이 보인다.’ 월요일엔 키보드로 웹을 쓰는 사람들이 누구인지, 수요일엔 초점이 왜 보여야 하는지, 그리고 오늘은 그걸 내 손으로 직접 점검하는 체크리스트를 다뤘다. 핵심은 하나다. ‘막연한 느낌’을 ‘구체적인 점검’으로 바꾸는 것. 그게 개선의 시작이다.

오늘 다섯 묶음(키보드 도달성·초점 가시성·이동 순서·함정 탈출·지름길/낭독)의 점검 결과는 꼭 날짜와 함께 적어두길 바란다. 그게 우리 사이트의 접근성 개선 여정에서 첫 번째 기준점이 된다. 한 가지만 더 당부하면, 이 글을 ‘읽기만 하고’ 닫지 말고 지금 바로 마우스를 옆으로 치우고 우리 사이트를 한 탭에 띄워 Tab 키 몇 번이라도 눌러보길 바란다. 읽고 고개를 끄덕이는 것과, 직접 마우스 없이 우리 화면을 돌아다녀 보는 것은 남는 게 완전히 다르다. 단 1분이라도, 마우스를 치우고 Tab을 눌러보면 ‘아, 우리 초점이 안 보이는구나’ 같은 발견 하나는 분명히 건진다.

오늘 글을 읽으며 ‘우리도 저런데’ 싶은 항목이 한두 개 떠올랐다면, 그것만으로도 절반은 온 거다. 문제를 ‘이름 붙여 인식한’ 순간부터 개선이 시작되기 때문이다. 이제 막연한 ‘우리 사이트 좀 불편한 것 같다’가 ‘초점 표시가 꺼져 있구나’, ‘메뉴가 키보드로 안 펼쳐지는구나’, ‘제출 버튼에 키보드로 도달을 못 하는구나’ 같은 구체적인 진단으로 바뀌었다. 구체적인 진단은 구체적인 행동으로 이어진다. 그리고 그 행동은 거창할 필요가 없다. 오늘 찾은 ‘아니오’ 중 가장 아픈 것 하나만 골라 손대도, 우리 사이트는 어제보다 더 많은 사람에게 열린 사이트가 된다.

한 가지 더 기억해 둘 것. 점검 결과가 안 좋게 나왔다고 자책할 필요는 전혀 없다. 대부분의 공공 사이트가 비슷한 과정을 거친다. 마우스를 기준으로 만들고, 마우스로만 테스트하다 보면 키보드 사용자의 불편이 안 보이는 게 자연스럽다. 중요한 건 ‘지금 마우스를 치워보고 알아차렸다’는 것이고, 알아차린 순간부터는 얼마든지 좋아질 수 있다는 점이다. 오늘 점검은 ‘우리 사이트가 나쁘다’를 확인하는 자리가 아니라, ‘우리 사이트를 더 많은 사람에게 열어줄 출발점’을 찍는 자리다.

생각해보면, 접근성이 좋은 공공 사이트와 그렇지 않은 사이트의 차이는 ‘처음부터 완벽했는가’가 아니라 ‘쓰는 사람의 입장에서 한 번이라도 돌아봤는가’에서 갈린다. 어떤 사이트든 처음엔 어딘가 부족하다. 다만 그 부족함을 ‘마우스를 치우고 직접 겪어보며 메워온’ 사이트는 시간이 갈수록 더 많은 사람에게 열리고, ‘마우스 쓰는 사람만 보고 방치한’ 사이트는 보이지 않는 벽이 점점 두꺼워진다. 오늘 자가 점검은 그 벽을 ‘알아차리고 허무는’ 가장 가벼운 첫 단계다. 거창한 예산도, 외부 전문가도 필요 없이, 마우스 하나만 치우고 우리 사이트를 키보드 사용자의 손으로 돌아보는 것 — 모든 ‘열린 사이트’가 그렇게 시작했다.

끝으로, 오늘 체크리스트는 ‘출력해서 책상에 붙여두는 것’도 권한다. 새 페이지를 만들거나 외주 결과물을 받을 때, 이 항목들을 옆에 두고 ‘마우스 없이 한 번 돌려보기’를 습관으로 삼으면, ‘완성한 다음에 접근성 문제를 발견하는’ 일을 크게 줄일 수 있다. 만들기 전과 만든 후가 아니라 ‘만드는 도중에’ 키보드로 점검하는 것 — 그게 접근성 부채를 애초에 쌓지 않는 가장 싼 방법이다. 점검은 ‘다 만든 뒤 잘못을 찾는 일’이 아니라, ‘만드는 내내 옆에 두고 보는 기준’일 때 가장 큰 힘을 낸다. 오늘의 항목들이 우리 팀의 그런 ‘상시 기준’이 되기를 바란다.

다음 주에는 ‘색만으로 정보를 전달하면 왜 위험한가’를 주제로, 색 대비와 색 의존성이라는 또 다른 접근성 영역을 깊이 다룬다. 마우스를 치우는 오늘의 습관에, 다음 주엔 ‘색을 빼고 보는’ 습관 하나를 더 얹어보자.

키워드/태그: #KRDS #공공웹 #웹접근성 #KWCAG #키보드접근성 #초점표시 #자가진단 #체크리스트 #정부웹사이트 #공공UX #접근성검사 #ViewCheck