Chapter 08

내비게이션

처음 가 보는 큰 병원에서 사람들이 가장 먼저 찾는 것은 진료실이 아니라 안내판이다. "지금 여기", 가려는 곳의 방향, 돌아 나가는 길. 웹사이트도 건물과 같다. 첫 화면으로 들어오는 사람보다 검색 결과나 메시지 속 링크를 눌러 어느 방 한가운데로 곧장 떨어지는 사람이 더 많다. 그 사람에게 화면은 세 가지를 알려 줘야 한다. 지금 어디에 있는지, 어디로 갈 수 있는지, 어떻게 돌아가는지. 이 장은 그 안내판을 휴대폰 크기의 화면에 세우는 방법을 다룬다. 메뉴를 펼쳐 둘지 숨길지, 현재 위치를 어떻게 표시할지, 링크에 무엇이라고 적을지, 검색 칸이 꼭 필요한지.

길 찾기의 세 질문

건축과 도시 설계에는 길 찾기(Wayfinding)라는 분야가 있다. 사람이 낯선 공간에서 자기 위치를 알고 목적지까지 가는 과정을 돕는 안내판, 지도, 색, 조명의 설계다. 웹사이트의 내비게이션(Navigation)은 같은 일을 화면에서 한다. 사이트 안에서 페이지와 페이지를 오가게 하는 메뉴, 링크, 빵부스러기, 검색을 모두 이르는 말이다. 좋은 내비게이션은 누가 어느 페이지로 떨어져도 다음 세 질문에 답한다.

  1. 지금 어디에 있나. 이 페이지의 이름과, 사이트 안에서 이 페이지가 속한 갈래.
  2. 어디로 갈 수 있나. 사이트의 큰 갈래들과, 지금 여기서 이어지는 곳.
  3. 어떻게 돌아가나. 한 단계 위로, 첫 화면으로.

세 질문에 답하려면 먼저 사이트의 지도가 있어야 한다. 페이지를 어떤 갈래로 묶고 어떤 이름을 붙여 어떤 순서로 놓을지 정하는 일을 정보 구조(Information architecture)라고 한다. 메뉴는 그 지도의 맨 윗층을 화면에 꺼내 놓은 것이다. 책방 E의 새 사이트는 작아서 지도도 단순하다.

깊이 0깊이 1깊이 2깊이 3 첫 화면 행사 일정모임 신청 신간책방 소개 행사 상세행사 상세 지난 행사책 상세 오시는 길지난 행사 기록 맨 윗층 네 갈래가 메뉴가 된다 진한 칸은 메뉴에 꺼내 놓는 갈래. 다섯 번째 후보 "오시는 길"은 깊이 2에 둔다.
그림 1. 책방 E 새 사이트의 지도(정보 구조). 페이지가 스무 개 남짓인 작은 사이트라 깊이는 많아야 3이다. 깊이가 얕을수록 길을 잃을 일이 적지만, 맨 윗층의 갈래가 너무 많아지면 메뉴가 길어진다. 넓이와 깊이는 서로 맞바꾸는 관계다. 이 그림은 이 장의 케이스에서 서윤이 정한 지도이며, 오시는 길을 어디에 둘지는 이 장에서 따져 본다.

메뉴는 모든 페이지에서 같은 자리, 같은 순서, 같은 이름으로 나와야 한다. 페이지마다 메뉴 순서가 바뀌면 사람은 메뉴를 다시 읽어야 하고, 자리를 외워 둔 사람은 엉뚱한 곳을 누른다. WCAG 2.2는 이것을 성공 기준 3.2.3(일관된 내비게이션, AA)과 3.2.4(일관된 식별, AA)로 요구한다. 키보드나 화면 낭독기로 쓰는 사람에게는 반대 문제도 있다. 페이지마다 같은 메뉴를 처음부터 다시 지나가야 본문에 닿는다. 그래서 페이지 맨 앞에 "본문 바로 가기" 링크를 두어 되풀이되는 덩어리를 건너뛰게 한다(성공 기준 2.4.1, 블록 건너뛰기, A).

휴대폰의 메뉴 패턴

넓은 화면에서 메뉴는 대개 문제가 아니다. 화면 위쪽에 링크 다섯 개를 한 줄로 놓으면 된다. 문제는 폭 360 안팎의 휴대폰이다. 링크 다섯 개가 한 줄에 들어가지 않거나, 들어가더라도 사용자가 글자를 키우면 두 줄 세 줄로 깨진다. 휴대폰에서 자주 쓰는 메뉴 패턴은 세 가지다.

패턴모습얻는 것잃는 것
위 링크 줄머리 띠 아래에 링크를 한두 줄로 펼친다모든 갈래가 보인다. 구현이 가장 단순하다항목이 많거나 글자가 크면 여러 줄로 깨지고 첫 화면의 높이를 먹는다
아래 탭 바화면 아래에 3~5개의 탭을 아이콘과 글자로 고정한다늘 보이고, 엄지가 닿기 쉽다는 설명이 많다. 현재 위치를 표시하기 좋다칸이 다섯 개를 넘기 어렵다. 화면 아래쪽 높이를 늘 차지한다
햄버거 메뉴세 줄 아이콘(☰) 하나 뒤에 메뉴 전체를 숨긴다항목 수에 제한이 없고 화면이 깔끔하다메뉴가 있다는 것, 무엇이 있는지가 보이지 않는다. 누르는 횟수가 하나 는다

아래 시뮬레이터는 책방 E의 메뉴 다섯 개(행사 일정, 모임 신청, 신간, 책방 소개, 오시는 길)를 세 패턴으로 휴대폰 목업에 올린 것이다. 목업의 폭과 사용자의 글자 크기 설정을 바꿔 본다. 실제 창 폭은 바뀌지 않는다.

SIMULATOR

같은 메뉴, 세 가지 패턴

보이는 메뉴—
메뉴가 차지한 높이—
가장 좁은 누르는 면—
해볼 것: ① 위 링크 줄에서 폭 360, 글자 100%로 본다. 다섯 링크가 두 줄에 들어간다. ② 글자를 160% 이상으로 올린다. 링크가 서너 줄로 늘어 "다음 모임" 카드가 아래로 밀려난다. 1장에서 도경의 휴대폰에 메뉴가 깨진 모습이다. ③ 아래 탭 바로 바꾼다. 네 칸은 글자가 커져도 칸 폭이 그대로이고, 글자가 길면 두 줄이 된다. 다섯 번째 "오시는 길"은 들어갈 자리가 없다. ④ 햄버거로 바꾼다. 화면은 가장 넓게 쓰지만 보이는 메뉴는 0개다. ⑤ 폭을 320으로 줄이고 세 패턴을 다시 본다. (목업의 보이는 높이는 600으로 두었다. 메뉴 글자 15 px, 탭 글자 12 px을 기준으로 설정 비율만큼 키우고, 누르는 면은 7장에서 정한 최소 44 px을 지키도록 그렸다. 탭 바는 기기 아래쪽의 안전 영역을 빼고 그렸다.)

세 패턴은 한 가지를 서로 맞바꾼다. 화면 면적과 보이는 메뉴다. 위 링크 줄은 모든 메뉴를 보여 주는 대신 글자가 커질수록 첫 화면을 크게 먹는다. 아래 탭 바는 늘 같은 높이로 네댓 개를 보여 주지만 그 이상은 담지 못한다. 햄버거는 면적을 가장 아끼지만 메뉴를 하나도 보여 주지 않는다. 어느 쪽이 옳은지는 메뉴의 수와, 사이트를 쓰는 사람이 가장 자주 가는 곳이 몇 군데인지에 달려 있다. 자주 가는 곳이 네 군데 안쪽이면 그 넷은 보이게 두고, 나머지만 다른 자리로 보내는 설계가 많다.

붙박이 탭 바가 가리는 것 화면 아래에 고정한 탭 바나 위에 고정한 머리 띠는 그 아래의 본문을 늘 가린다. 키보드로 Tab을 누르며 내려가다가 포커스 받은 링크가 탭 바 뒤에 숨으면 사람은 지금 어디 있는지 모른다. WCAG 2.2는 이것을 성공 기준 2.4.11(포커스 가려지지 않음 최소, AA)로 새로 넣었다. CSS의 scroll-padding-bottom에 탭 바 높이를 주면 브라우저가 포커스 받은 요소를 탭 바 위로 스크롤해 준다. 화면을 200%로 확대한 사람에게는 고정된 띠가 화면의 절반을 차지할 수도 있으니, 확대한 상태에서도 한 번 확인한다(11장).

숨긴 메뉴의 대가

햄버거 메뉴는 2010년대에 휴대폰 웹과 앱에서 빠르게 퍼졌다. 그만큼 "햄버거 메뉴는 나쁘다"와 "이제 모두 세 줄 아이콘을 안다"는 주장도 함께 돌았다. 근거는 어디까지 있을까.

자주 인용되는 연구는 사용성 연구 회사 닐센 노먼 그룹의 Kara Pernice와 Raluca Budiu가 2016년에 발표한 보고(「Hamburger Menus and Hidden Navigation Hurt UX Metrics」)다. 같은 사이트를 메뉴가 보이는 판, 일부만 보이는 판, 숨긴 판으로 만들어 사용자 과제를 비교했다. 보고의 요지는, 메뉴를 숨기면 사람들이 메뉴를 덜 쓰고 과제가 더 오래 걸리고 더 어렵게 느꼈으며, 그 차이는 넓은 화면에서 더 컸다는 것이다. 휴대폰에서도 숨긴 메뉴는 덜 쓰였다. 이 결과는 그 시점, 그 사이트들, 그 과제에 대한 것이다. 세 줄 아이콘이 무엇인지 아는 사람이 그 뒤로 더 늘었을 수 있고, 사이트와 사람에 따라 결과가 달라질 수 있다. 하지만 원리는 단순하고 오래 간다. 보이지 않는 것은 쓰이지 않는다. 숨긴 메뉴를 쓰려면 사람이 먼저 "여기에 메뉴가 있을 것"이라고 짐작하고, 아이콘을 알아보고, 열어 봐야 한다.

아래는 이 짐작의 단계를 곱셈으로 적은 단순한 모형이다. 실험 자료가 아니라 교육용 가정이다. 책방 E 사이트에 처음 온 손님 100명이 "모임 신청" 또는 "오시는 길"을 찾는다.

$$P(\text{찾음}) = P(\text{메뉴가 있다고 알아챔}) \times P(\text{메뉴 안에서 알아봄})$$
보이는 탭 바에서는 첫 항이 거의 1이다. 햄버거에서는 첫 항이 "세 줄 아이콘을 메뉴로 알아보고 열어 볼 확률"이 된다. 두 번째 항은 메뉴 이름이 찾는 것과 얼마나 잘 맞는지에 달려 있다. 이 장의 모형은 두 항 모두 가정한 값을 쓴다.
SIMULATOR

손님 100명의 길 찾기(교육용 가정)

찾은 손님—
포기하고 전화로—
찾기까지 누름—
해볼 것: ① 탭 바 넷에서 "모임 신청"을 찾는다. 열에 아홉이 한 번에 찾는다. ② 햄버거(아이콘만)로 바꾸고 확률 슬라이더를 0.9에서 0.3까지 내린다. 찾는 사람의 수가 그 확률을 그대로 따라 내려간다. ③ "메뉴" 글자를 붙인 햄버거로 바꾼다. 모형은 글자가 열어 보지 않던 사람의 절반을 더 열게 한다고 가정했다. ④ "오시는 길"을 찾는다. 탭 바에 자리가 없어 "책방 소개" 안에 넣었으므로, 탭 바 설계도 이번에는 완벽하지 않다. 넷을 펼치고 하나를 안으로 보내는 결정에도 대가가 있다. (모형의 가정: 보이는 메뉴를 알아챌 확률 0.95, 메뉴 안에서 맞는 이름을 알아볼 확률 0.95, "오시는 길"이 "책방 소개" 안에 있으리라 짐작할 확률 0.7, 짐작하지 못한 사람이 바닥글에서 찾을 확률 0.4. 모두 이 장이 정한 교육용 가정이며 실제 값은 사이트와 사람에 따라 다르다. 점 100개는 같은 확률로 시드를 고정해 뽑았다.)

모형의 숫자는 가정이지만 구조는 분명하다. 햄버거 메뉴의 성적은 거의 전부 "열어 볼 확률" 하나에 달려 있고, 그 값은 디자이너가 정할 수 없다. 사이트를 쓰는 사람들이 정한다. 아이콘 옆에 "메뉴"라는 글자를 붙이는 것은 그 값을 조금이라도 끌어올리려는 흔한 방법이다. 반대로 메뉴를 펼쳐 두면 자리가 모자라 일부를 다른 곳으로 보내야 하고, 보낸 곳을 찾는 데 또 다른 짐작이 든다. 결정은 "무엇을 숨기면 덜 아픈가"의 문제다. 가장 자주 찾는 것은 보이게, 가끔 찾는 것은 한 단계 안쪽에.

"메뉴는 일곱 개까지"는 근거가 아니다 메뉴 항목 수를 말할 때 조지 밀러(George A. Miller)의 1956년 논문(「The magical number seven, plus or minus two」, Psychological Review)이 자주 인용된다. 그러나 그 논문은 사람이 짧은 시간 기억에 붙잡아 둘 수 있는 덩어리의 수를 다룬 것이다. 메뉴는 외우는 것이 아니라 눈앞에 보면서 고르는 것이라, 그 숫자를 메뉴 항목의 한도로 쓰는 것은 잘못 옮긴 것이다. 항목 수를 정하는 실제 기준은 화면에 들어가는가, 이름이 서로 겹치지 않는가, 사람들이 찾는 것과 맞는가다. "세 번 클릭 안에 모든 페이지에 닿아야 한다"는 규칙도 근거가 확인되지 않은 통설이다. 누르는 횟수보다 각 단계에서 "이 길이 맞다"는 확신이 이어지는지가 더 중요하다는 관찰이 많다(아래 링크 문구 절).
메뉴 이름은 손님의 말로 메뉴의 갈래와 이름은 사이트를 만드는 사람의 말이 아니라 쓰는 사람의 말로 지어야 한다. 이를 확인하는 간단한 방법이 카드 분류(Card sorting)다. 페이지 이름을 카드에 하나씩 적어 손님 몇 사람에게 주고 비슷한 것끼리 묶은 다음 묶음에 이름을 붙여 달라고 한다. 서점 사람에게는 "프로그램"이 자연스러워도 손님은 "행사"나 "모임"이라고 부를 수 있다. 다섯 명만 해 봐도 이름이 갈리는 카드가 드러난다. 결과는 통계가 아니라 대화의 재료로 쓴다.

"지금 여기" 표시

지하철 노선도의 "현재 역" 표시처럼, 메뉴에는 지금 보고 있는 페이지가 어느 갈래에 속하는지 표시한다. 이것을 현재 위치 표시(Current location indicator)라고 한다. 검색에서 행사 상세 페이지로 곧장 떨어진 사람도 메뉴의 "행사 일정"이 켜져 있으면 자기가 어느 갈래에 있는지 안다. WCAG 2.2의 성공 기준 2.4.8(위치, AAA)은 사이트 안에서 사용자의 위치 정보를 알 수 있게 하라고 권한다.

현재 위치를 색 하나로만 표시하면 7장의 버튼 상태와 같은 문제가 생긴다. 색을 구별하기 어려운 사람과 햇빛 아래의 화면에서 표시가 사라진다(성공 기준 1.4.1). 화면 낭독기 사용자에게는 색도 굵기도 전해지지 않는다. 그래서 눈에 보이는 단서를 둘 이상 겹치고, 기계가 읽는 표시를 따로 단다.

<nav aria-label="주 메뉴">
  <a href="/events/" aria-current="page">행사 일정</a>
  <a href="/join/">모임 신청</a>
  …
</nav>

aria-current="page"는 WAI-ARIA의 속성으로, 화면 낭독기가 그 링크를 "현재 페이지"라고 읽게 한다. CSS에서도 [aria-current="page"]로 같은 표시를 칠할 수 있어, 보이는 표시와 읽히는 표시가 한 곳에서 함께 바뀐다. 아래에서 메뉴 항목이나 탭을 눌러 현재 페이지를 바꾸고 표시 방식을 비교한다.

SIMULATOR

현재 위치를 알리는 단서

메뉴를 눌러 페이지를 바꾼다
현재 항목의 단서—
현재와 다른 항목의 글자색 대비—
화면 낭독기가 읽는 것—
해볼 것: ① "색만"에서 넓은 화면 메뉴와 휴대폰 탭 바를 본다. 초록과 회색의 차이는 보이지만 두 글자색 사이의 대비는 2:1 안쪽이다. ② 제2색각으로 보기를 켠다. 초록과 회색이 비슷한 탁한 색이 되어 현재 위치가 거의 사라진다. ③ "색 + 굵기 + 막대"로 바꾼다. 색이 사라져도 굵기와 막대가 남는다. 흑백 보기를 켜도 마찬가지다. ④ 메뉴에서 "오시는 길"을 누른다. 탭 바에는 오시는 길이 없으므로 그것을 품은 "책방 소개" 탭이 켜진다. 현재 위치 표시는 페이지가 아니라 갈래를 가리킨다. ⑤ aria-current를 켜고 꺼 본다. 눈에 보이는 표시와 상관없이 화면 낭독기가 읽는 내용이 바뀐다. (대비는 현재 항목과 다른 항목의 글자색끼리 잰 WCAG 대비비다. 제2색각 보기는 Machado 외 2009 모형의 근사다.)

현재 위치 표시는 "색 + 굵기 + 막대"처럼 서로 다른 성질의 단서를 겹칠 때 튼튼해진다. 막대나 밑줄 같은 모양 단서는 색과 상관없이 남고, 굵기는 흑백에서도 남는다. 탭 바에서는 아이콘을 속이 빈 모양에서 꽉 찬 모양으로 바꾸는 방법도 흔하다. 단서를 겹치되 위계는 지킨다. 현재 위치 표시가 페이지 제목보다 더 크게 외치면 안 된다.

서윤의 웹 개편 노트

CASE 서윤웹 개편 노트 · 8장

세 줄 아이콘 대신 펼친 네 칸

7장 끝에서 도경이 던진 질문("신청 페이지로 가는 길은 어디 있니?")이 이 장의 출발이었다. 서윤의 휴대폰 시안은 오른쪽 위의 세 줄 아이콘 뒤에 메뉴 다섯 개를 모두 숨겨 두었다. 서윤과 지후에게 그 아이콘은 너무 익숙해서 아무도 의심하지 않았다. 도경은 화면을 한참 내려 보다가 결국 주인에게 전화를 걸었다. 주인이 "모임 신청을 전화로 받느라 하루가 다 간다"고 했던, 바로 그 전화였다.

서윤은 이 장의 첫 시뮬레이터로 세 패턴을 비교했다. 메뉴 다섯 개를 위 링크 줄로 펼치면 폭 360에서는 두 줄이었지만, 도경처럼 글자를 크게 키우면 서너 줄로 깨져 "다음 모임"이 첫 화면 아래로 밀렸다. 2장에서 정한 "첫 화면에는 다음 모임 하나만"을 지킬 수 없었다. 아래 탭 바는 네 칸까지는 글자가 커져도 버텼다. 문제는 다섯 번째였다. 서윤은 주인과 지난달 전화 문의를 함께 떠올려 보았다. 가장 많은 것은 모임 신청, 다음이 행사 날짜, 신간 입고였다. "오시는 길"은 처음 오는 손님 몇 사람이 묻는 정도였다(가상, 주인의 기억에 기댄 어림). 그래서 오시는 길을 탭 바에서 빼서 "책방 소개" 페이지 맨 위와 모든 페이지의 바닥글에 두기로 했다.

지후는 넓은 화면에서도 탭 바를 쓰자고 했지만, 서윤은 넓은 화면에서는 다섯 개를 모두 머리 띠에 펼치는 쪽을 골랐다. 자리가 넉넉한데 숨길 이유가 없었다. 현재 위치 표시는 시뮬레이터에서 제2색각 보기를 켜자 초록 글자만으로는 사라지는 것을 보고 굵기와 막대를 더했다. 지후는 같은 표시를 [aria-current="page"] 선택자로 칠하기로 했다. 그러면 표시를 다는 것을 잊을 수 없다. 행사 상세 페이지에는 빵부스러기를 넣었다. 넓은 화면에서는 "홈 › 행사 일정 › 그림책 함께 읽기", 휴대폰에서는 "‹ 행사 일정" 한 단계만 보인다. 행사 카드의 "자세히 보기"는 모두 행사 이름 링크로 바꿨다. 신간은 지금 40권 안팎이라 검색 칸은 만들지 않고 분류(그림책, 소설, 시, 에세이, 인문) 둘러보기로 시작한다.

시안을 바꾼 다음 주, 도경은 탭 바의 "모임 신청"을 첫 화면에서 바로 눌렀다. 서윤은 그 장면을 시험 기록이 아니라 "한 사람의 한 번"으로 적었다. 같은 시험을 화면 낭독기를 쓰는 사람과도 해 봐야 한다는 메모도 남겼다.

항목서윤의 선택확인한 것
휴대폰 메뉴아래 탭 바 넷: 행사 일정 · 모임 신청 · 신간 · 책방 소개(아이콘 + 글자, 글자는 두 줄까지)폭 320·글자 200%에서도 칸 폭 80 px, 높이 56 px 이상(기기 안전 영역 별도)
다섯 번째 메뉴오시는 길은 "책방 소개" 맨 위와 모든 페이지의 바닥글모형에서 찾는 비율이 줄어드는 대가를 알고 고름
넓은 화면 메뉴머리 띠에 다섯 개 모두 펼침, 햄버거 없음모든 페이지에서 같은 자리·순서·이름(3.2.3)
현재 위치책방 초록 + 굵게(800) + 막대 3 px(탭 바는 위, 넓은 화면은 밑줄), aria-current="page"제2색각·흑백에서도 막대와 굵기가 남음
빵부스러기깊이 2 이상 페이지에만. 넓은 화면은 전체, 휴대폰은 "‹ 바로 위 갈래" 하나nav aria-label="현재 위치", 구분 기호는 CSS
링크 문구"자세히 보기" 쓰지 않음. 행사 이름·책 제목을 링크로링크 목록만으로 다섯 곳 구별
찾기검색 칸 없이 신간 분류 다섯 갈래로 둘러보기. 신간이 수백 권으로 늘면 다시 검토2.4.5는 메뉴 + 바닥글의 사이트맵 링크로
붙박이 탭 바scroll-padding-bottom을 탭 바 높이만큼Tab으로 내려가도 포커스가 탭 바 뒤에 숨지 않음(2.4.11)
이 장에서 정한 것휴대폰은 메뉴 다섯 개 중 넷(행사 일정, 모임 신청, 신간, 책방 소개)을 아래 탭 바로 펼쳐 두고, 오시는 길은 책방 소개 안과 바닥글로 보낸다. 넓은 화면은 다섯 개 모두 펼친다. 현재 위치는 색·굵기·막대 세 단서와 aria-current로 표시한다. 행사 상세에는 빵부스러기(휴대폰은 한 단계 위만)를 둔다. 링크 문구는 갈 곳의 이름으로 쓴다. 이 장의 발견성·검색 모형은 교육용 가정이라, 숫자가 아니라 구조만 근거로 썼다.
아직 남은 문제도경이 탭 바로 모임 신청 페이지에 닿았지만, 그 다음 화면에서 다시 멈췄다. 칸마다 회색 글씨만 있고 이름표가 없는 신청서, 전화번호를 적는 방식이 정해져 있는 칸, 다 적고 보내자 맨 위에 한꺼번에 뜨는 빨간 글씨.
다음 단계9장: 모임 신청 폼을 다시 짠다.

핵심 정리

  1. 내비게이션은 어느 페이지로 떨어진 사람에게도 세 질문에 답해야 한다. 지금 어디에 있나, 어디로 갈 수 있나, 어떻게 돌아가나. 메뉴는 모든 페이지에서 같은 자리·순서·이름으로(WCAG 3.2.3).
  2. 휴대폰의 메뉴 패턴(위 링크 줄, 아래 탭 바, 햄버거)은 화면 면적과 보이는 메뉴를 맞바꾼다. 가장 자주 가는 곳은 보이게, 가끔 가는 곳은 한 단계 안쪽에.
  3. 숨긴 메뉴는 덜 쓰인다는 보고가 있다(닐센 노먼 그룹, 2016). 결과는 조건에 따라 다를 수 있지만, 숨긴 메뉴의 성적은 "열어 볼 확률"에 달려 있고 그 값은 디자이너가 정할 수 없다. "메뉴 일곱 개", "세 번 클릭"은 근거가 아니다.
  4. 현재 위치는 색만이 아니라 굵기·막대 같은 단서를 겹쳐 표시하고 aria-current="page"를 단다. 표시는 페이지가 아니라 갈래를 가리킬 수 있다.
  5. 빵부스러기는 걸어온 길이 아니라 지도에서의 위치다. 휴대폰에서는 가운데를 줄이거나 한 단계 위만 보이게 줄인다.
  6. 링크 문구는 갈 곳의 이름으로 쓴다(WCAG 2.4.4, 2.4.9). 검색은 대상이 많고 이름을 알 때 이긴다. 작은 사이트는 잘 짠 둘러보기로 충분할 수 있고, 닿는 방법은 두 가지 이상 둔다(2.4.5).

확인 퀴즈

1. 닐센 노먼 그룹의 2016년 보고(Pernice, Budiu)가 숨긴 내비게이션에 대해 보고한 내용과 그 해석으로 가장 알맞은 것은?

보고는 숨긴 내비게이션이 쓰임과 과제 지표를 낮췄고 그 차이가 넓은 화면에서 더 컸다고 했다. 그 시점, 그 사이트, 그 과제의 결과라 일반화에는 주의가 필요하지만, 숨긴 것을 쓰려면 먼저 알아채고 열어야 한다는 구조는 남는다.

2. 메뉴의 현재 위치를 표시하는 방법으로 가장 알맞은 것은?

색 하나로만 알리면 색을 구별하기 어려운 사람과 흑백에서는 표시가 사라진다(1.4.1). 굵기·막대 같은 다른 성질의 단서를 겹치고, 화면 낭독기를 위해 aria-current를 단다. 항목을 빼면 메뉴의 자리와 순서가 페이지마다 바뀌고(3.2.3), 지나치게 크게 하면 위계가 무너진다.

3. 행사 카드 다섯 개에 모두 "자세히 보기" 링크가 있다. 화면 낭독기의 링크 목록으로 페이지를 훑는 사람을 생각할 때 가장 알맞은 고침은?

링크 목록에서는 주변 글 없이 링크 문구만 보인다. 같은 문구 다섯 개는 서로 구별되지 않는다. 갈 곳의 이름을 링크 문구로 쓰면 2.4.4와 2.4.9를 함께 만족하고, 눈으로 훑는 사람에게도 정보 냄새가 강해진다. 색, 밑줄, 간격은 문구의 뜻을 바꾸지 못한다.

4. 검색에서 행사 상세 페이지로 곧장 들어온 사람에게 "홈 › 행사 일정 › 그림책 함께 읽기"라는 빵부스러기가 보인다. 이 빵부스러기에 대한 설명으로 옳은 것은?

웹의 빵부스러기는 대개 지나온 길이 아니라 사이트 구조 속의 위치를 보여 준다. 그래서 검색으로 들어온 사람에게도 같은 줄이 보이고, 링크는 사이트의 위층 페이지로 간다. 지나온 길은 뒤로 가기가 맡는다. 빵부스러기는 위치를 알리는 여러 방법 중 하나이며(2.4.8은 AAA 권고), 얕은 페이지에는 필요 없을 수 있다.