버튼에 적힌 한 마디, 입력칸 위의 이름표, 잘못됐을 때 뜨는 한 줄, 이런 짧은 말들이 사용자를 멈춰 세우기도 하고 나아가게도 합니다. 이 작은 말들도 결국 마크업 위에 놓입니다. 어떻게 적느냐에 따라 화면이 어떻게 달라지는지 코드로 보겠습니다.
30.1 버튼은 벌어질 일을 적기
확인이나 제출 같은 두루뭉술한 말은 누르면 무슨 일이 일어나는지 알려 주지 않습니다. 버튼 라벨에 실제 행동을 담아 줍니다.
<button>확인</button>
<button>제출</button>
이렇게 적으면 사용자는 누르기 전에 잠시 망설입니다. 아래처럼 그 버튼이 하는 일을 그대로 적어 주면 고민이 사라집니다.
<button>12,000원 결제하기</button>
<button>글 올리기</button>
금액까지 얹은 결제하기 버튼은 누르면 무슨 일이 벌어질지 스스로 밝힙니다. 버튼의 말은 그 버튼이 하는 일을 비추는 거울이어야 합니다.
30.2 아이콘 버튼엔 이름을 달기
그림만 있는 아이콘 버튼은 눈으로는 알아봐도 화면 낭독기에는 이름 없는 버튼으로 읽힙니다. 보이지 않는 이름을 붙여 줍니다.
<button><svg ... /></button>
이 버튼은 낭독기가 그냥 버튼이라고만 읽어 무엇을 하는 버튼인지 알 수 없습니다. aria-label 로 역할을 적어 줍니다.
<button aria-label="장바구니 열기">
<svg aria-hidden="true" ... />
</button>
이제 낭독기가 장바구니 열기 버튼이라고 또렷이 읽습니다. 안쪽 아이콘엔 aria-hidden="true" 를 줘 중복해 읽히지 않게 합니다.
30.3 placeholder를 라벨로 쓰지 않기
칸 안의 흐린 안내글로 이름표를 대신하면, 입력을 시작하는 순간 그 안내가 사라져 무슨 칸이었는지 잊게 됩니다. 라벨은 따로 두어야 합니다.
<input type="email" placeholder="이메일">
이러면 입력 중엔 이 칸이 무엇을 받는지 안 보입니다. 라벨을 밖으로 꺼내고 placeholder는 예시로만 씁니다.
<label for="email">이메일</label>
<input id="email" type="email"
placeholder="[email protected]">
라벨은 입력 중에도 늘 남아 있고, placeholder는 형식을 보여 주는 예시 역할을 맡습니다. for 와 id 를 이어 두면 라벨을 눌러도 칸에 커서가 들어갑니다.
30.4 도움말은 칸에 연결하기
비밀번호 규칙 같은 도움말을 그냥 옆에 적어 두면 낭독기는 그것이 어느 칸의 설명인지 모릅니다. 칸과 도움말을 묶어 줍니다.
<label for="pw">비밀번호</label>
<input id="pw" type="password"
aria-describedby="pw-hint">
<p id="pw-hint">8자 이상, 숫자 하나를 포함하세요</p>
aria-describedby 가 도움말 문단을 칸에 이어 주어, 칸에 커서가 닿으면 낭독기가 규칙까지 함께 읽어 줍니다. 눈으로 보는 사람과 듣는 사람이 같은 안내를 받습니다.
30.5 글자 수는 눈에 보이게 세기
길이 제한이 있는 칸은 얼마나 남았는지 보여 주지 않으면 사용자가 다 쓰고 나서야 잘립니다. 남은 글자 수를 곁에 표시합니다.
<label for="bio">소개</label>
<textarea id="bio" maxlength="80"
aria-describedby="bio-count"></textarea>
<span id="bio-count">0 / 80</span>
maxlength 로 상한을 걸고, 곁의 0 / 80 표시가 입력에 따라 갱신되면 사용자는 남은 여유를 늘 알 수 있습니다. 한도가 얼마 안 남으면 그 숫자를 붉게 바꿔 미리 알려 주면 더 친절합니다.
30.6 빈 상태와 에러는 다음 걸음을 담기
텅 빈 화면에 없음이라고만 적거나, 에러에 오류 발생이라고만 띄우면 사용자는 무엇을 해야 할지 막막합니다. 다음에 할 일을 함께 적습니다.
<div class="empty">저장한 글이 없습니다.</div>
<div class="error">오류가 발생했습니다.</div>
이 두 문구는 상황만 알릴 뿐 길을 열어 주지 않습니다. 무엇을 하면 되는지를 담아 다시 씁니다.
<div class="empty">
아직 저장한 글이 없어요.
<a href="/write">첫 글 써 보기</a>
</div>
<p class="error">카드 번호를 다시 확인해 주세요.</p>
빈 화면은 다음 행동으로 이어지는 초대가 되고, 에러는 나무람 대신 어디를 고치면 되는지 짚어 줍니다. 같은 상황도 어떤 말로 전하느냐에 따라 사용자의 마음이 달라집니다.
30.7 링크는 목적을 담기
여기를 누르세요나 더 보기 같은 링크는 그 말만 떼어 놓으면 어디로 가는지 알 수 없습니다. 링크 글자 자체에 도착지를 담습니다.
<a href="/refund">여기</a>를 눌러 환불하세요.
낭독기가 링크만 훑을 때 여기라는 말은 아무 정보도 주지 못합니다. 목적을 링크 안으로 옮깁니다.
<a href="/refund">환불 신청하기</a>
이제 링크만 봐도 어디로 가는지 알 수 있어, 훑어보는 눈에도 듣는 귀에도 또렷합니다. 링크의 말은 그 자체로 목적지의 이름표가 되어야 합니다.
30.8 확인 버튼엔 예/아니요 대신 행동을
무언가를 되묻는 두 버튼에 예와 아니요만 적으면, 물음을 대충 읽은 사용자가 엉뚱한 쪽을 누릅니다. 각 버튼에 벌어질 일을 적어 줍니다.
<p>이 글을 삭제할까요?</p>
<button>아니요</button>
<button>예</button>
버튼만 봐서는 예가 삭제인지 취소인지 헷갈립니다. 물음을 안 읽어도 알 수 있게 바꿉니다.
<p>이 글을 삭제할까요?</p>
<button>그대로 두기</button>
<button class="danger">삭제하기</button>
이제 버튼의 말이 저마다 제 할 일을 밝혀, 사용자가 물음을 다 읽지 않아도 헷갈리지 않습니다. 위험한 쪽엔 danger 색을 얹어 한 번 더 눈에 띄게 합니다.
30.9 금지가 아니라 방법을 알려 주기
같은 규칙도 안 된다는 부정보다 이렇게 하면 된다는 긍정으로 적으면 사용자가 덜 위축됩니다. 에러 문구의 방향을 바꿔 봅니다.
<p class="error">아이디는 공백을 포함할 수 없습니다.</p>
틀렸다는 사실만 전하는 말입니다. 무엇을 하면 되는지로 방향을 돌립니다.
<p class="hint">아이디는 공백 없이 영문과 숫자로 적어 주세요.</p>
같은 규칙인데도 나무람이 아니라 안내로 읽힙니다. 사용자를 주인공에 놓고 할 수 있는 것을 비춰 주는 말이 훨씬 힘이 됩니다.
30.10 정리
마이크로카피는 화면 곳곳에 놓인 작은 이정표라, 짧아도 사용자가 망설이는 길목마다 힘을 발휘합니다. 버튼엔 벌어질 일을, 아이콘엔 이름을, 빈 화면과 에러엔 다음 걸음을 담는 이 작은 손질만으로도 화면은 훨씬 덜 헷갈립니다. 작은 말이라고 대충 넘기면 정작 중요한 길목에서 사용자를 놓칩니다.