[접근성연구·고령] '여기를 클릭'이 알려주지 않는 것
'여기를 클릭하세요'. '더보기'. '확인'. '바로가기'. 이런 라벨은 분명히 글자가 있습니다. 아이콘만 덩그러니 놓인 버튼은 아닙니다. 그런데도 사용자는 누르기 전에 망설입니다. 무엇을 클릭하는 건지, 무엇을 더 보는 건지, 무엇을 확인하는 건지가 글자에 담겨 있지 않기 때문입니다. 라벨이 있다는 사실과 라벨이 의미를
![[접근성연구·고령] '여기를 클릭'이 알려주지 않는 것](https://xbbhievqdmccsexxrdtn.supabase.co/storage/v1/object/sign/covers/content/5cn4i0lx-88324.jpeg?token=eyJraWQiOiJzdG9yYWdlLXVybC1zaWduaW5nLWtleV8yOWQwYWZmNy1mOWJhLTRkNmUtYmZlZi0yMzg2NTc0ZWUzODQiLCJhbGciOiJIUzI1NiJ9.eyJ1cmwiOiJjb3ZlcnMvY29udGVudC81Y240aTBseC04ODMyNC5qcGVnIiwic2NvcGUiOiJkb3dubG9hZCIsImlhdCI6MTc4NDQ2NTcxNSwiZXhwIjoyMDk5ODI1NzE1fQ.h3wfCLA9_s2qacP925EdbP7ep8AhzBCOMP4rBQuW8v8)
모호한 라벨 점검 관점
〈디지털 접근성 연구 ⑩〉 — 이 글은 규정이 아니라 하나의 연구 관점입니다. 앞 편(⑨)이 "아이콘만으로는 부족하다 — 라벨이 필요하다"를 다뤘다면, 이번 편은 "그래서 라벨이 붙어 있더라도 여전히 모호할 수 있는 경우를 어떻게 직접 점검하나"를 점검의 관점에서 봅니다. 특정 도구가 아니라, 누구나 따라 할 수 있는 방법을 정리합니다. 인용한 기준은 출처와 함께 적고, 관찰한 장면은 익명으로 옮깁니다.
들어가며 — 글자는 있는데, 뜻은 없는
'여기를 클릭하세요'. '더보기'. '확인'. '바로가기'. 이런 라벨은 분명히 글자가 있습니다. 아이콘만 덩그러니 놓인 버튼은 아닙니다. 그런데도 사용자는 누르기 전에 망설입니다. 무엇을 클릭하는 건지, 무엇을 더 보는 건지, 무엇을 확인하는 건지가 글자에 담겨 있지 않기 때문입니다. 라벨이 있다는 사실과 라벨이 의미를 전한다는 사실은 다른 문제입니다.
앞 편에서 우리는 아이콘이 의미를 혼자 짊어질 때 생기는 어려움을 보았습니다. 그 결론은 '라벨을 붙이자'였습니다. 그러나 라벨을 붙이는 것만으로는 충분하지 않습니다. 붙인 라벨이 실제로 무엇을 하는지 말해 주는가라는 다음 질문이 남습니다. 이번 편은 그 질문을 점검의 관점에서 다룹니다. 모호한 라벨을 어떻게 알아보고, 어떻게 직접 확인하며, 무엇을 기준으로 다듬을지를 정리합니다.
1. '모호한 라벨'은 어떤 모습인가 — 유형부터 알아두기
점검을 하려면 먼저 무엇을 찾을지 알아야 합니다. 우리가 공공 웹에서 반복해 마주친 모호한 라벨에는 몇 가지 전형이 있습니다.
1-1. 위치를 가리키는 라벨 — '여기', '이곳'
'여기를 클릭'은 동작이 아니라 위치를 가리킵니다. 그 자리에 손가락을 대라는 말일 뿐, 누른 결과가 무엇인지는 말하지 않습니다. 화면을 눈으로 보는 사용자에게도 불친절하지만, 보조 기술로 듣는 사용자에게는 더 심각합니다. 링크 목록을 차례로 듣다 보면 '여기', '여기', '여기'가 반복되어, 각 링크가 어디로 가는지 분간할 수 없게 됩니다.
1-2. 너무 짧아 맥락이 빠진 라벨 — '확인', '신청', '보기'
'확인'은 무엇을 확인하는지, '신청'은 무엇을 신청하는지, '보기'는 무엇을 보는지가 생략돼 있습니다. 같은 화면에 '확인' 버튼이 여러 개 있으면 혼란은 배가됩니다. 짧은 라벨이 늘 나쁜 것은 아니지만, 맥락이 없으면 짧음은 모호함이 됩니다.
1-3. 결과를 숨기는 라벨 — '계속', '다음', '제출'
'다음'은 다음에 무슨 일이 일어나는지 말하지 않습니다. 그것이 단순히 다음 입력 단계인지, 결제가 확정되는 순간인지, 신청이 최종 접수되는 시점인지 구분되지 않습니다. 결과가 큰 동작일수록, 라벨이 결과를 숨기면 사용자는 더 불안해집니다.
1-4. 내부 용어로 된 라벨 — 만든 쪽의 말
'민원 발급 처리', '전자 사전 등록'처럼 기관 내부의 업무 용어가 그대로 버튼이 되는 경우입니다. 만든 사람에게는 자명하지만, 사용자에게는 한 번 더 번역이 필요한 말입니다. 이 문제는 다음 편(011·012)의 '쉬운 말'과 직접 이어집니다.
이 네 유형을 머릿속에 넣어 두면, 화면을 볼 때 모호한 라벨이 눈에 들어오기 시작합니다.
1-5. 네 유형을 한 장으로 — 무엇이, 왜 빠졌나
위 네 유형을 나란히 놓으면, 모호함이 생기는 원인이 조금씩 다르다는 것이 보입니다. 아래 표는 각 유형에서 '라벨에 무엇이 빠져 있는가'를 정리한 것입니다. 이 표는 특정 서비스의 실측이 아니라 여러 화면에서 반복 관찰된 경향을 요약한 연구용 정리입니다.
| 모호 유형 | 대표 라벨 | 빠진 정보 | 누가 가장 불편한가 |
|---|---|---|---|
| 위치 지시형 | 여기를 클릭, 이곳 | 동작·대상 모두 | 보조 기술 사용자(링크 목록 청취) |
| 맥락 누락형 | 확인, 신청, 보기 | 대상(목적어) | 같은 화면에 동일 라벨 여럿일 때 모두 |
| 결과 은폐형 | 다음, 계속, 제출 | 결과의 무게(되돌림 가능 여부) | 결제·최종 접수 직전 사용자 |
| 내부 용어형 | 민원 발급 처리 | 일상어 번역 | 행정 용어에 익숙지 않은 사용자 |
표의 오른쪽 끝 열이 중요합니다. 같은 '모호함'이라도 누구에게 더 무겁게 작용하는지가 다릅니다. 위치 지시형은 소리로 듣는 사용자에게, 결과 은폐형은 되돌리기 어려운 동작을 앞둔 사용자에게 특히 무겁습니다. 그래서 점검의 우선순위(7장)도 '누가 얼마나 잃는가'를 기준으로 잡게 됩니다.
2. 점검의 기준 — 표준은 무엇을 말하나
모호한 라벨을 점검하는 일은 취향의 문제가 아닙니다. 참고할 수 있는 기준이 있습니다.
WCAG는 '맥락 안에서의 링크 목적(Link Purpose in Context, 2.4.4)'을 다루며, 더 엄격한 수준에서는 '링크만으로의 목적(Link Purpose, Link Only, 2.4.9)'을 다룹니다. 핵심은 링크나 버튼의 텍스트만으로(또는 그 맥락과 함께) 어디로 가고 무엇을 하는지 알 수 있어야 한다는 것입니다. '여기를 클릭'처럼 동일한 텍스트가 서로 다른 목적지에 반복되는 패턴은 이 기준이 경계하는 대표적 사례입니다.
또한 '레이블 또는 지시문(3.3.2)'은 입력 요소가 무엇을 요구하는지 분명히 하라고 봅니다. 버튼·링크·입력란 모두에 공통으로 흐르는 원칙은 하나입니다. 사용자가 행동의 결과를 예측할 수 있어야 한다는 것. 모호한 라벨은 이 예측을 막습니다.
점검의 출발점은 이 한 문장으로 요약됩니다. "이 라벨만 읽고도, 누르면 무슨 일이 일어날지 알 수 있는가?" 알 수 없다면 다듬을 후보입니다.
3. 직접 해 보는 점검 — 다섯 가지 방법
여기서부터는 도구 없이도 할 수 있는 점검 방법입니다. 순서대로 따라 하면 모호한 라벨의 대부분을 찾아낼 수 있습니다.
3-1. '맥락 떼어내기' 점검
라벨을 주변 설명에서 떼어내 그 글자만 따로 읽어 봅니다. 예를 들어 '여기를 클릭', '더보기', '확인'을 종이에 그 글자만 적어 놓고, 처음 보는 사람에게 "이 버튼을 누르면 무슨 일이 일어날 것 같나요?"라고 물어봅니다. 답이 갈리거나 "모르겠다"가 나오면, 그 라벨은 맥락에 지나치게 기대고 있는 것입니다. 보조 기술 사용자는 종종 이런 '맥락 떼어진' 상태로 라벨을 듣습니다.
3-2. '같은 라벨 찾기' 점검
한 화면, 또는 한 흐름 안에서 동일한 라벨이 여러 번 등장하는지 셉니다. '확인'이 셋, '신청'이 둘, '여기를 클릭'이 다섯 개라면, 사용자는 그것들을 구분할 단서가 없습니다. 같은 글자가 다른 동작을 가리키는 곳은 우선 점검 대상입니다.
3-3. '결과 예측' 점검
각 버튼 옆에 '누르면 무슨 일이 일어나는가'를 한 줄로 적어 봅니다. 그 한 줄이 라벨과 크게 다르다면, 라벨이 결과를 숨기고 있는 것입니다. 특히 '다음', '계속', '제출'처럼 흐름을 진전시키는 버튼에서 결과의 무게(되돌릴 수 있는지, 비용이 발생하는지)를 함께 적어 두면, 어디를 더 분명히 해야 하는지가 드러납니다.
3-4. '소리로 듣기' 점검
스크린리더로 화면을 읽혀 봅니다. 많은 운영체제에 기본 스크린리더가 내장되어 있어, 특별한 설치 없이도 시도할 수 있습니다. 링크 목록만 따로 읽어 주는 기능을 쓰면, '여기', '여기', '여기'처럼 반복되는 모호한 라벨이 곧바로 드러납니다. 눈으로 볼 때는 주변 설명 덕분에 괜찮아 보이던 라벨이, 소리로 들으면 얼마나 모호한지가 분명해집니다.
3-5. '처음 온 사람' 점검
그 서비스를 한 번도 써 보지 않은 사람, 특히 디지털에 덜 익숙한 분에게 실제로 한 가지 과업을 부탁해 봅니다. "여기서 ○○ 신청을 한번 해 보시겠어요?" 그리고 어디서 망설이는지, 어떤 버튼 앞에서 "이게 뭐예요?"라고 묻는지를 가만히 관찰합니다. 멈춤이 생기는 라벨이 바로 모호한 라벨입니다. 이 방법은 가장 단순하면서도 가장 정확한 점검 중 하나라고 우리는 봅니다.
3-6. 다섯 점검을 한 장으로 — 비용과 효과
다섯 가지 점검은 각각 드는 시간과 잡아내는 결함의 종류가 다릅니다. 한정된 시간에 무엇부터 할지 정할 때 도움이 되도록 정리합니다.
| 점검 방법 | 드는 시간 | 도구 필요 | 주로 잡아내는 결함 | 자동화 가능성 |
|---|---|---|---|---|
| 맥락 떼어내기 | 적음 | 종이/메모 | 맥락 의존 라벨 | 부분 가능 |
| 같은 라벨 찾기 | 적음 | 없음 | 중복 라벨 | 가능(텍스트 집계) |
| 결과 예측 | 보통 | 없음 | 결과 은폐형 | 어려움(판단 필요) |
| 소리로 듣기 | 보통 | 스크린리더 | 링크 목적 불명 | 부분 가능 |
| 처음 온 사람 | 큼 | 실사용자 | 모든 유형(실증) | 불가(사람 필요) |
표에서 보듯, '같은 라벨 찾기'처럼 기계가 잘하는 점검과 '처음 온 사람'처럼 사람만 할 수 있는 점검이 섞여 있습니다. 우리는 점검을 '기계가 걸러낼 수 있는 것을 먼저 빠르게 처리하고, 사람의 시간은 판단이 필요한 곳에 쓰는' 방식으로 배분하기를 권합니다. 자동 점검이 '같은 라벨 5개'를 표시해 주면, 사람은 그중 무엇을 어떻게 고칠지에 집중할 수 있습니다.
4. 찾았다면, 어떻게 다듬나 — 다시 쓰기의 관점
모호한 라벨을 찾았다면 다음은 다시 쓰기입니다. 우리는 몇 가지 단순한 기준을 제안합니다.
첫째, 위치 대신 동작을 씁니다. '여기를 클릭' → '신청서 내려받기'. 무엇을 하는지가 라벨에 들어가면, 떼어내 읽어도 뜻이 통합니다.
둘째, 목적어를 채웁니다. '확인' → '입력 내용 확인', '신청' → '교육 신청'. 같은 화면에 비슷한 버튼이 여럿일 때, 목적어 하나가 혼동을 없앱니다.
셋째, 결과의 무게를 드러냅니다. 되돌릴 수 없는 동작이라면 라벨에 그 사실을 담는 편이 안전합니다. '제출' 대신 '신청 최종 제출'처럼, 이 버튼이 흐름의 끝이라는 신호를 주는 것입니다.
넷째, 사용자의 말로 옮깁니다. 내부 업무 용어를 사용자가 쓰는 일상어에 가깝게 바꿉니다. 이때 줄이려다 다시 모호해지지 않도록, '짧게'보다 '분명하게'를 우선에 둡니다.
다섯째, 보이는 글자와 읽히는 이름을 맞춥니다. 화면에 보이는 라벨과 보조 기술이 읽는 이름이 다르면, 듣는 사용자와 보는 사용자가 서로 다른 정보를 받습니다. 둘을 일치시키는 것이 기본입니다(앞 편에서 언급한 '레이블 인 네임'과 같은 맥락).
이 다섯 기준을 실제 라벨에 적용하면 어떻게 달라지는지, 다시 쓰기 전후를 나란히 놓아 봅니다. 아래 예시는 가상의 일반화된 사례이며 특정 서비스의 문구가 아닙니다.
| 다시 쓰기 전(모호) | 다시 쓰기 후(분명) | 적용한 기준 |
|---|---|---|
| 여기를 클릭 | 신청서 내려받기 | 위치→동작 |
| 확인 | 입력 내용 확인 | 목적어 채움 |
| 신청 (목록에 여럿) | 교육 신청 / 자료 신청 | 대상 구분 |
| 제출 (최종 접수) | 신청 최종 제출 | 결과 무게 표시 |
| 민원 발급 처리 | 증명서 발급 신청 | 사용자 말로 |
| 아래 버튼을 눌러 진행하시기 바랍니다 | 본인 인증 시작 | 군더더기 덜기 |
표의 마지막 행이 중요한 균형을 보여 줍니다. 다시 쓰기는 '늘리기'가 아닙니다. 오히려 군더더기가 많은 라벨은 줄이면서 핵심 정보(동작·대상)를 남기는 쪽이 더 분명해집니다. 이 균형은 8장에서 다시 다룹니다.
5. 점검을 한 번으로 끝내지 않으려면
라벨은 한 번 다듬는다고 영원히 명확하게 남지 않습니다. 화면은 계속 바뀌고, 새 버튼이 추가되며, 급하게 만든 페이지에서 다시 '여기를 클릭'이 등장합니다. 우리는 점검을 일회성 이벤트가 아니라 반복되는 습관으로 두기를 권합니다.
가장 단순한 방법은 라벨에 대한 작은 약속을 팀이 공유하는 것입니다. '위치를 가리키는 라벨은 쓰지 않는다', '같은 동작에는 같은 라벨을 쓴다', '결과가 큰 버튼은 결과를 라벨에 담는다' 같은 몇 줄짜리 원칙입니다. 이런 약속이 있으면, 새로 만드는 사람도 모호한 라벨을 덜 만들게 됩니다.
또한 새 화면을 공개하기 전에 §3의 점검 중 한두 가지만이라도 통과시키는 습관을 들이면 좋습니다. 특히 '맥락 떼어내기'와 '소리로 듣기'는 시간이 적게 들면서도 효과가 큽니다.
6. 우리가 공공 웹에서 관찰한 장면들 — 익명으로
- 어떤 안내 페이지에는 '여기를 클릭'으로 시작하는 링크가 한 화면에 여러 개 있었습니다. 눈으로 보면 각각 다른 안내처럼 보였지만, 소리로 들으면 모두 '여기'로만 들렸습니다.
- 어떤 신청 흐름의 마지막 버튼은 '확인'이었습니다. 그 버튼이 신청을 최종 접수하는 순간이라는 것을, 라벨만으로는 알기 어려웠습니다. 누른 뒤에야 '접수되었습니다'를 보고 알게 되는 구조였습니다.
- 어떤 목록 페이지에는 항목마다 '보기' 버튼이 달려 있었습니다. 무엇을 보는지는 항목 제목을 함께 읽어야만 알 수 있었는데, 그 연결이 보조 기술에서는 끊겨 있었습니다.
이 장면들의 공통점은, 라벨이 '있었다'는 것입니다. 없어서가 아니라, 있는 라벨이 충분히 말하지 않아서 생긴 멈춤들입니다.
한 흐름을 익명으로 끝까지 따라가 보겠습니다. 어느 신청 서비스는 세 단계로 이뤄져 있었고, 각 단계 하단에 똑같이 '다음'이라는 버튼이 놓여 있었습니다. 1단계의 '다음'은 단순히 입력을 이어 가는 버튼이었지만, 3단계의 '다음'은 신청을 최종 접수하는 버튼이었습니다. 세 버튼의 글자는 같았지만, 누른 결과의 무게는 전혀 달랐습니다. 한 사용자는 3단계에서도 "아직 한 번 더 확인하는 단계가 있겠지"라고 생각하며 '다음'을 눌렀고, 곧바로 '접수되었습니다' 안내를 보고 당황했습니다. 되돌릴 수 없는 동작이 '되돌릴 수 있을 것 같은 라벨' 뒤에 숨어 있었던 것입니다. 만약 3단계 버튼이 '신청 최종 제출'이었다면, 그 사용자는 누르기 전에 한 번 더 살폈을 것입니다. 우리는 이 장면을 "같은 글자, 다른 무게" 사례로 기록합니다. 라벨의 명확함이 단어 하나가 아니라 흐름 전체의 문제라는 것을 보여 주는 장면입니다(9장에서 이어집니다).
7. 무엇부터 점검하면 좋을까 — 우선순위
모든 라벨을 한 번에 점검하기는 어렵습니다. 우리는 다음 순서를 제안합니다.
먼저 결과가 크고 되돌리기 어려운 버튼입니다. 결제·신청 최종 제출·삭제처럼, 모호함이 곧 손실로 이어질 수 있는 곳입니다. 다음은 모든 사용자가 지나는 길목의 라벨 — 첫 화면, 내비게이션, 검색 버튼 등입니다. 그다음은 한 화면에 같은 라벨이 반복되는 곳입니다. 마지막으로 내부 용어가 그대로 노출된 라벨을 사용자의 말로 옮기는 작업으로 넘어갑니다.
기준은 한결같습니다. '여기서 사용자가 결과를 잘못 예측하면 잃는 것이 큰가.' 클수록 먼저 점검하는 편이 좋다고 봅니다.
8. '짧음'과 '분명함' 사이 — 흔한 오해 풀기
라벨 점검을 이야기하면 자주 나오는 오해가 있습니다. "그러면 라벨을 길게 쓰라는 말인가?"라는 반문입니다. 우리는 '길게'가 아니라 '분명하게'를 권합니다. 둘은 같지 않습니다. 긴 라벨이 늘 분명한 것도, 짧은 라벨이 늘 모호한 것도 아닙니다.
핵심은 꼭 필요한 정보가 라벨 안에 있는가입니다. '내려받기'는 짧지만 무엇을 하는지 분명합니다. 반대로 '아래 버튼을 눌러 해당 절차를 진행하시기 바랍니다'는 길지만 정작 무엇을 하는지는 흐릿합니다. 길이가 아니라, '동작'과 '대상'이 담겼는지가 분명함을 가릅니다. 그래서 다시 쓰기의 목표는 '늘리기'가 아니라 '빠진 정보 채우기'입니다. '확인'에 빠진 목적어 하나를 채워 '입력 내용 확인'으로 만드는 것이지, 무작정 문장을 길게 늘이는 것이 아닙니다.
여기에 더해, 화면의 제약도 함께 고려해야 합니다. 모바일처럼 공간이 좁은 곳에서는 라벨이 길면 줄이 바뀌거나 잘립니다. 그래서 우리는 '동작+대상'을 가장 짧게 담는 표현을 찾는 것을 권합니다. '교육 신청서를 내려받으시겠습니까'가 아니라 '신청서 내려받기'처럼, 군더더기를 덜되 핵심은 남기는 것입니다. 분명함과 간결함은 충돌하는 것처럼 보이지만, 빠진 정보를 채우고 군더더기를 덜면 둘은 대개 같은 자리에서 만납니다.
9. 라벨 점검의 한계 — 결국 흐름 전체를 봐야 한다
라벨 하나하나를 다듬는 점검은 강력하지만, 그것만으로 모든 모호함이 사라지지는 않습니다. 라벨은 흐름 안에서 작동하기 때문입니다. 같은 '다음' 버튼이라도, 그 앞에 무슨 안내가 있었는지, 그 버튼을 누른 뒤 어디로 가는지에 따라 사용자가 느끼는 모호함의 크기가 달라집니다. 그래서 라벨 점검은 흐름 점검과 함께 가야 온전해집니다.
예를 들어, '다음'이라는 라벨 자체는 짧지만, 그 버튼 위에 '다음 단계: 본인 인증'이라는 안내가 분명히 있다면 모호함은 크게 줄어듭니다. 반대로 아무 안내 없이 '다음'만 덩그러니 있으면, 같은 라벨이라도 사용자는 무슨 일이 일어날지 알 수 없습니다. 이처럼 라벨의 명확함은 라벨 글자만의 문제가 아니라, 그 라벨이 놓인 맥락 전체의 문제이기도 합니다.
그래서 우리는 라벨 점검을 '단어 고치기'로만 보지 않습니다. 라벨을 떼어내 읽어 보는 점검(§3-1)이 중요한 것은, 그것이 '맥락이 사라졌을 때도 라벨이 견디는가'를 보기 때문입니다. 맥락이 충분한 곳에서는 짧은 라벨도 견디고, 맥락이 빈약한 곳에서는 라벨이 더 많은 정보를 짊어져야 합니다. 결국 라벨 점검의 끝은 '이 라벨이 이 흐름의 이 자리에서 충분히 말하고 있는가'라는 질문으로 모입니다. 단어 하나를 보되 흐름 전체를 함께 보는 것 — 그것이 라벨 점검을 제대로 하는 방법이라고 우리는 봅니다.
10. 한 장 요약 — 모호한 라벨 점검의 핵심
이번 편의 관점을 한자리에 모읍니다.
| 단계 | 핵심 질문 | 도구/방법 | 근거의 성격 |
|---|---|---|---|
| 찾기 | 이 라벨만 읽고 결과를 알 수 있나 | 4유형 대조표 | 관찰 |
| 점검 | 떼어내도, 소리로도 통하나 | 5가지 점검법 | 관찰·표준(2.4.4) |
| 다시 쓰기 | 동작·대상·결과가 담겼나 | before/after 대조 | 우리의 관점 |
| 흐름 보기 | 이 자리에서 충분히 말하나 | 맥락 함께 점검 | 우리의 관점 |
| 습관화 | 새 화면에도 같은 약속이 적용되나 | 팀 라벨 원칙 | 우리의 관점 |
표를 가로지르는 한 문장은 이렇습니다. "라벨은 누르기 전에 결과를 예측하게 돕는 일을 한다." 그 일을 하지 못하는 라벨은, 글자가 있어도 비어 있는 라벨입니다. 점검의 목적은 완벽한 문구를 찾는 것이 아니라, 사용자가 멈추는 자리를 줄이는 것입니다.
맺으며 — 라벨의 일은 '예측을 돕는 것'
좋은 라벨은 사용자가 누르기 전에 결과를 예측하게 돕습니다. '여기를 클릭'은 그 일을 하지 못합니다. 위치만 가리킬 뿐, 결과를 말하지 않기 때문입니다. 라벨에 글자가 있다는 사실에 안심하지 말고, 그 글자가 실제로 무엇을 하는지 말하고 있는지를 한 번 더 들여다보는 일 — 그것이 이번 편이 제안하는 점검의 핵심입니다.
점검은 거창하지 않습니다. 라벨을 떼어내 읽어 보고, 같은 라벨을 세어 보고, 소리로 들어 보고, 처음 온 사람에게 물어보는 것. 이 단순한 동작들이, '있지만 말하지 않는 라벨'을 '있고 또 말하는 라벨'로 바꾸는 출발점이 됩니다. 앞 편의 '아이콘에 라벨을 더하자'와 이번 편의 '그 라벨이 말하게 하자'는, 결국 같은 목표의 앞뒤 절반입니다. 버튼이 자기가 하는 일을 분명히 말하게 하는 것 — 우리는 그것을 명확함의 기본으로 봅니다.
다음 편 예고 (011): [접근성연구·고령] 행정용어와 사용자 언어의 거리 — 라벨과 안내문을 채우는 '말' 자체가 어려울 때, 쉬운 말 쓰기를 기준의 관점에서 다룹니다.
참고한 공개 자료(출처):
- WCAG 2.1 성공 기준 2.4.4 Link Purpose (In Context) / 2.4.9 Link Purpose (Link Only) / 3.3.2 Labels or Instructions (W3C WAI)
- 한국형 웹 콘텐츠 접근성 지침(KWCAG 2.2) — 링크·컨트롤 텍스트 명확성 관련 항목
- 행동 결과 예측·링크 목적의 명시성 등 일반 인터랙션 설계 원리(통설)
관련 글
[접근성연구·디지털포용] 한 사람이 여러 벽을 동시에
앞 편(081)에서 디지털 포용이 여러 갈래의 사용자를 하나의 목표로 묶는다고 봤다. 그리고 끝에서 한 가지를 남겼다 — 현실의 한 사람은 여러 조건을 동시에 가질 수 있다고. 이 시리즈를 닫는 이번 편은 그 '겹침'을 정면으로 본다. 영역의 경계를 가로질러, 조건이 겹칠 때 접근성이 어떻게 더 가팔라지는지를 관찰한다.
[접근성연구·디지털포용] 디지털포용법이 말하는 '포용'
앞 편(080)에서 초고령사회라는 인구구조의 신호를 봤다. 그리고 끝에서 한 가지를 분명히 했다 — 디지털 격차는 고령에만 있는 것이 아니라고. 이번 편은 그 여러 갈래의 격차를 '디지털 포용(digital inclusion)'이라는 하나의 정책 틀에서 함께 본다. 이 시리즈는 그동안 사용자를 영역별로 나눠 다뤘다. 고령
[접근성연구·디지털포용] 초고령사회, 공공웹은 준비됐나
공공앱 세 편(077~079)으로 매체의 확장을 닫았다. 이제 시선을 한 번 더 넓힌다. 지금까지 이 시리즈는 주로 '한 사람이 화면 앞에서 겪는 어려움'을 다뤘다. 고령(001~014), 저시력(029~043), 키보드(047~049)처럼, 개별 사용자의 자리에서 벽을 봤다. 이번 묶음(080~082)은 그 시선을 거시