컴포넌트와 상태

화면의 부품

웹 페이지는 수많은 작은 부품으로 이루어진다. 버튼, 링크, 입력 칸, 체크 상자, 카드, 탭, 알림 띠. 이렇게 한 번 설계해 두고 여러 화면에서 되풀이해 쓰는 화면의 부품을 컴포넌트(Component)라고 한다. 같은 버튼을 행사 페이지에서도, 신청 폼에서도, 신간 목록에서도 쓰므로, 버튼 하나를 잘 만들면 사이트 전체가 좋아지고 하나를 잘못 만들면 그 실수가 사이트 전체에 퍼진다. 6장에서 색과 글자를 토큰으로 정리한 것은 이 부품들을 만들 재료를 마련한 일이었다. 이 장은 그 재료로 부품을 조립한다.

부품을 고를 때 가장 먼저 물을 것은 생김새가 아니라 하는 일이다. 웹에서 가장 흔히 헷갈리는 두 부품이 링크와 버튼이다. 링크(Link)는 다른 곳으로 데려간다. 다른 페이지, 같은 페이지의 다른 자리, 내려받을 파일. 버튼(Button)은 지금 이 자리에서 무언가를 한다. 신청서를 보내고, 메뉴를 열고, 장바구니에 담는다. 생김새는 바꿀 수 있다. 버튼처럼 생긴 링크("행사 전체 보기")도, 링크처럼 생긴 버튼("더 불러오기")도 있다. 하지만 HTML에서는 하는 일에 맞는 요소를 써야 한다. 링크는 <a href>, 버튼은 <button>이다.

<div>에 누르기 동작만 붙인 "가짜 버튼"은 마우스로는 잘 눌린다. 그래서 디자이너도 개발자도 문제를 모르고 지나간다. 그런데 키보드의 Tab 키로는 그 자리에 갈 수 없고, Enter나 스페이스로 누를 수도 없으며, 화면 낭독기는 그것이 버튼인 줄 모른다. 진짜 <button>은 이 모든 것을 브라우저가 공짜로 해 준다. 웹 표준은 이것을 부품의 이름, 역할, 값이 기계에 전달되어야 한다는 요구로 적어 둔다(WCAG 2.2 성공 기준 4.1.2, 이름·역할·값). 접근성 전체는 11장에서 다루고, 이 장에서는 부품이 사람에게 대답하는 방식, 곧 상태에 집중한다.

상태: 부품이 대답하는 방식

같은 버튼도 때에 따라 다른 얼굴을 한다. 부품이 지금 어떤 처지에 있는지를 상태(State)라고 한다. 버튼의 상태는 대개 여섯 가지로 정리한다. 아무 일도 없을 때의 기본, 마우스 포인터를 올렸을 때의 호버(Hover), 키보드로 다가와 지금 입력을 받을 차례가 되었을 때의 포커스(Focus), 누르고 있는 순간의 눌림(Active, Pressed), 지금은 누를 수 없을 때의 비활성(Disabled), 누른 뒤 처리를 기다리는 로딩(Loading).

디자인 시안이 기본 상태 하나만 그려져 있으면, 나머지 다섯 상태는 개발자가 짐작으로 채우거나 브라우저의 기본값으로 남는다. 아래 시뮬레이터의 위쪽은 버튼 하나의 여섯 상태를 나란히 놓은 상태 표(State matrix)다. "첫 시안"은 호버 색만 정해 둔 버튼, "다섯 상태 + 로딩"은 상태마다 다른 단서를 준 버튼이다. 아래쪽에는 같은 두 설계로 만든 진짜 버튼이 있다. 마우스를 올려 보고, 페이지를 누른 다음 Tab 키로 다가가 보고, 눌러 본다.

첫 시안의 문제는 색이 아니라 침묵이다. 포커스가 왔는데 말하지 않고, 누를 수 없는데 말하지 않고, 처리 중인데 말하지 않는다. 사람은 대답이 없으면 다시 누른다. 그래서 로딩 상태가 없는 신청 버튼은 같은 신청을 두세 번 보내게 만든다. 서버에서 중복을 막는 일은 개발자의 몫이지만, "처리 중"이라고 말하는 일은 디자인의 몫이다.

개선안이 상태마다 쓴 단서를 다시 보자. 호버는 색만 조금 어둡게 했다. 호버는 포인터가 바로 그 자리에 있을 때만 생기므로 작은 변화로 충분하다. 포커스는 색이 아니라 링이다. 눌림은 더 어두운 색에 더해 버튼이 2 px 내려앉고 아래 그림자가 사라진다. 비활성은 회색으로 바뀌면서 글자도 "신청 마감"으로 바뀐다. 로딩은 돌아가는 표시와 "신청 중…"이다. 상태를 색 하나로만 알리면 색을 구별하기 어려운 사람(ColorBook 13장), 햇빛 아래의 휴대폰 화면, 흑백으로 보는 사람에게는 상태가 사라진다(WCAG 2.2 성공 기준 1.4.1, 색의 사용).

포커스: 키보드의 커서

모든 사람이 마우스나 손가락으로 웹을 쓰지는 않는다. 손을 정밀하게 움직이기 어려운 사람, 화면을 보지 않고 화면 낭독기로 쓰는 사람, 빠른 입력을 좋아하는 사람은 키보드로 페이지를 돌아다닌다. Tab 키를 누르면 다음 링크나 버튼으로, Shift+Tab을 누르면 이전으로 간다. 이때 지금 입력을 받을 부품이 어디인지 보여 주는 표시가 포커스 표시(Focus indicator)다. 글을 쓸 때 깜빡이는 커서와 같은 일을 한다. 커서가 보이지 않는 문서 편집기를 상상해 보면 포커스 표시가 없는 웹 페이지가 어떤지 알 수 있다.

브라우저는 포커스 받은 부품에 기본 링을 그려 준다. 그런데 이 링이 시안과 어울리지 않는다며 CSS 한 줄 outline: none으로 지워 버리는 일이 아주 흔하다. 마우스로 누를 때도 링이 생겨 보기 싫다는 이유다. 그 문제는 이제 :focus-visible이라는 선택자로 풀 수 있다. 브라우저가 "이 포커스는 키보드로 온 것이라 표시가 필요하다"고 판단할 때만 해당하는 상태라, 마우스로 누를 때는 링이 생기지 않고 키보드로 올 때만 생긴다.

.btn:focus-visible {
  outline: 3px solid #22342a;   /* 짙은 색 링 */
  outline-offset: 2px;          /* 버튼에서 2px 띄운다 */
}

포커스 표시에 관한 WCAG 2.2의 성공 기준은 여럿이다. 2.4.7(포커스 보임, AA)은 키보드로 조작할 수 있는 화면에서 포커스 표시가 보여야 한다고 요구한다. 1.4.11(텍스트가 아닌 콘텐츠의 대비, AA)은 부품의 상태를 알아보는 데 필요한 시각 정보가 이웃한 색과 3:1 이상 대비되어야 한다고 요구하고, 포커스 링도 여기에 든다. 2.2에서 새로 생긴 2.4.11(포커스 가려지지 않음 최소, AA)은 포커스 받은 부품이 고정된 머리 띠나 쿠키 알림에 완전히 가려지지 않아야 한다고 하고, 2.4.13(포커스 모양, AAA)은 링의 면적이 부품 둘레에 2 CSS px 두께로 두른 것 이상이고 포커스 전후의 같은 화소가 3:1 이상 달라져야 한다고 더 엄격하게 정한다.

포커스 링이 어려운 이유는 버튼이 늘 같은 바탕 위에 있지 않기 때문이다. 흰 본문 위의 버튼, 크림색 알림 띠 위의 버튼, 짙은 바닥글 위의 버튼에 같은 링을 쓰면 어딘가에서는 링이 바탕에 녹는다. 아래에서 버튼을 끌어 바탕을 바꿔 가며 링 스타일을 비교한다.

바탕이 하나뿐인 사이트라면 짙은 링 하나로 충분하다. 바탕이 여러 가지라면 두 가지 방법이 있다. 바탕마다 링 색을 바꾸는 규칙을 정하거나(어두운 영역 안에서는 밝은 링), 서로 대비가 큰 두 색을 겹친 이중 링을 쓴다. 이중 링은 규칙이 하나라 개발자가 실수할 여지가 적고, 바탕 위에 사진이 깔린 곳처럼 바탕색을 미리 알 수 없는 자리에서도 버틴다. 마지막 단계에서 본 것처럼, 링을 아무리 잘 만들어도 버튼 자체가 바탕에 녹으면 소용없다. 책방 초록 띠 위에는 크림색 버튼을 놓는 식으로 부품의 변형을 따로 둔다.

크기는 내용이 정한다

그래픽 디자인 도구에서 버튼을 그리면 사각형부터 그리게 된다. 가로 120, 세로 36. 그 안에 글자를 넣는다. 화면이 이 그림대로만 보인다면 문제가 없다. 하지만 2장에서 본 것처럼 사람들은 휴대폰과 브라우저의 글자 크기 설정을 바꾼다. 한도경처럼 글자를 가장 크게 해 두고 쓰는 사람에게 120×36 상자 안의 "모임 신청하기"는 상자 밖으로 넘치거나 잘린다. 번역된 페이지에서 글자 수가 늘어날 때도 같은 일이 생긴다.

그래서 웹의 부품은 크기를 고정하지 않고 내용 + 안쪽 여백 + 최소값으로 정한다. 버튼의 폭은 글자 폭에 좌우 여백을 더한 만큼, 높이는 글줄 높이에 위아래 여백을 더한 만큼이되 손가락으로 누르기에 모자라지 않게 최소 높이를 둔다. 글자 크기는 6장에서 정한 대로 rem으로 적어 사용자 설정을 따른다. 아래에서 휴대폰 화면(폭 360)의 행사 카드에 들어간 두 버튼을 두 방식으로 짜고 글자 크기를 키워 본다.

안쪽 여백으로 짠 버튼은 글자가 두 배가 되어도 읽힌다. 대신 화면을 더 차지하고, 줄이 바뀌고, 옆의 부품을 밀어낸다. 이것은 실패가 아니라 웹이 원래 그렇게 움직이는 방식이다. 디자이너의 일은 "글자가 커졌을 때 무엇이 어디로 가는가"까지 정해 두는 것이다. 두 버튼이 한 줄에 들어가지 않으면 주 버튼을 위로 쌓는다, 버튼 글자는 두 줄까지 허용한다, 같은 규칙들이다. 3장에서 정한 간격 단계와 "안쪽 간격 < 바깥 간격" 규칙이 여기서 그대로 쓰인다.

손가락이 닿는 크기

마우스 포인터의 끝은 화소 하나다. 손가락은 그렇지 않다. 화면에 닿는 손가락 끝의 면적은 넓고, 사람은 자기가 누른 자리를 정확히 알지 못하며, 손가락 끝이 누르려는 곳을 가린다. 버스 안이나 걸으면서 한 손 엄지로 누르면 더 흔들린다. 그래서 같은 자리를 노리고 여러 번 눌러도 닿는 자리는 노린 점 둘레에 흩어진다. 손가락이나 포인터로 누를 수 있는 부품의 면을 터치 타깃(Touch target, 누르는 면)이라고 한다. 눈에 보이는 모양보다 누르는 면을 더 크게 잡을 수도 있다.

누르는 면의 크기에 관해서는 성격이 다른 기준 몇 가지가 함께 돌아다닌다. 하나로 섞어 쓰면 안 된다.

2.5.8의 24는 "이보다 작으면 많은 사람이 누르기 어렵다"는 최소선이지 목표가 아니다. 이 기준에는 예외가 있다. 누르는 면이 24보다 작아도, 그 면의 가운데에 지름 24 CSS px의 원을 그렸을 때 그 원이 다른 타깃이나 다른 작은 타깃의 원과 겹치지 않으면 통과한다. 크기가 모자라면 간격으로 메우라는 뜻이다. 문장 안의 링크처럼 글줄에 섞인 타깃도 예외다. 44와 48은 앱 플랫폼의 설계 지침에서 왔고, 단위(pt, dp)가 CSS px와 같은 개념은 아니지만 휴대폰에서는 대체로 비슷한 크기가 된다.

아래 시뮬레이터는 휴대폰의 행사 날짜 줄이다. 칩 하나를 노리고 손가락으로 여러 번 누른 자리를 점으로 찍는다. 노린 칩에 닿으면 초록, 옆 칩에 닿으면 빨강, 아무것도 없는 틈이나 줄 밖에 닿으면 회색이다. 칩을 눌러 노릴 칩을 바꿀 수 있다.

잘못 누르기를 정하는 것은 칩 크기 하나가 아니라 이웃한 칩까지의 거리다. 칩의 가운데에서 옆 칩의 가장자리까지가 멀수록 흩어진 손가락이 옆 칩에 닿기 어렵다. 그 거리는 칩 크기의 절반에 간격을 더한 것이다. 그래서 칩을 키우는 것과 간격을 넓히는 것은 둘 다 잘못 누르기를 줄인다. 다른 점은, 칩을 키우면 노린 칩에 닿는 비율도 오르지만 간격을 넓히면 그 몫이 "반응 없음"으로 간다는 것이다. 화면 폭에 여유가 있으면 칩을 키우고, 폭이 모자라면 적어도 간격을 둔다.

피츠의 법칙: 멀고 작으면 느리다

심리학자 폴 피츠(Paul M. Fitts)는 1954년 논문(「The information capacity of the human motor system in controlling the amplitude of movement」, Journal of Experimental Psychology)에서 사람이 손을 뻗어 목표를 짚는 데 걸리는 시간을 다뤘다. 목표가 멀수록, 목표가 작을수록 시간이 더 걸린다는 것, 그리고 그 관계가 거리와 크기의 비의 로그로 잘 정리된다는 것이다. 이것을 피츠의 법칙(Fitts's law)이라고 한다. 오늘날 화면 설계에서 가장 많이 쓰는 형태는 스콧 매켄지(I. Scott MacKenzie)가 1992년 논문(「Fitts' law as a research and design tool in human-computer interaction」, Human–Computer Interaction)에서 정리한 섀넌 형식이다.

식에서 가장 중요한 것은 시간이 거리나 크기 하나가 아니라 둘의 비에 달려 있다는 점이다. 멀리 있는 목표도 크면 쉽고, 가까운 목표도 아주 작으면 어렵다. 그리고 로그 때문에 이미 큰 목표를 더 키우는 효과는 점점 줄어든다. 아래에서 목표를 끌어 거리를 바꾸고, 폭을 바꿔 그래프 위의 점이 어떻게 움직이는지 본다.

피츠의 법칙이 화면 설계에 주는 처방은 단순하다. 자주 누르는 것은 크게, 가깝게. "신청하기"처럼 그 페이지의 목적인 버튼은 크게 만들고, 사람의 손이나 포인터가 이미 있는 자리 가까이 둔다. 반대로 "신청 취소"처럼 실수로 누르면 곤란한 것은 일부러 작게, 멀리 두기도 한다. 피츠의 법칙을 거꾸로 쓰는 것이다. 마우스를 쓰는 넓은 화면에서는 화면 가장자리도 특별하다. 포인터가 화면 끝에서 멈추기 때문에 가장자리에 붙은 목표는 움직이는 방향으로 폭이 끝없이 넓은 것과 같다. 운영체제들이 메뉴 막대나 작업 표시줄을 화면 끝에 두는 이유로 자주 설명된다. 손가락에는 이 효과가 없다. 화면 끝을 넘어 손가락이 멈추지는 않기 때문이다.

호버가 없는 기기

호버는 마우스의 상태다. 손가락에는 "올려 두기"가 없다. 화면에 닿는 순간이 곧 누르는 순간이다. 그런데 넓은 화면에서 설계를 시작하면 정보를 호버 뒤에 숨기기 쉽다. 행사 카드에 포인터를 올리면 "남은 자리"와 "신청하기"가 나타나는 식이다. 화면이 깔끔해 보이기 때문이다. 이 정보는 휴대폰에서 어떻게 될까. 브라우저마다 다르다. 어떤 브라우저는 첫 탭을 호버로 처리해 숨은 정보를 보여 주고 두 번째 탭에서야 누른 것으로 친다. 어떤 브라우저는 첫 탭에 곧바로 카드의 링크로 넘어가 숨은 정보를 볼 기회가 없다. 키보드 사용자에게는 :hover만으로 숨긴 정보가 아예 나타나지 않는다.

원칙은 하나다. 호버는 꾸밈으로만 쓰고, 정보와 동작은 호버 없이도 닿게 한다. 호버로 그림자를 짙게 하거나 색을 조금 바꾸는 것은 좋다. 그러나 남은 자리, 가격, 신청 버튼처럼 결정에 필요한 것은 늘 보이게 둔다. CSS에는 기기의 포인터 성격을 묻는 미디어 쿼리가 있다(Media Queries Level 4). (hover: hover)는 주된 입력 장치가 호버할 수 있는지, (pointer: coarse)는 주된 포인터가 손가락처럼 정밀하지 않은지를 묻는다. 호버 꾸밈을 @media (hover: hover) 안에 넣으면 휴대폰에서 탭한 뒤 호버 색이 남아 있는 어색한 모습을 막을 수 있다. 다만 노트북에 터치스크린이 달린 경우처럼 한 기기에 여러 입력이 섞여 있을 수 있으므로, 이 질문은 꾸밈을 고를 때만 쓰고 정보를 숨길지 말지를 정하는 데는 쓰지 않는다.

@media (hover: hover) {
  .card:hover { box-shadow: 0 4px 16px rgb(0 0 0 / .12); }
}
/* 남은 자리와 신청 버튼은 미디어 쿼리 밖, 늘 보이게 */

호버나 포커스로 나타나는 내용(말풍선 같은 것)을 꼭 써야 할 때도 규칙이 있다. WCAG 2.2 성공 기준 1.4.13(호버나 포커스로 나타나는 콘텐츠, AA)은 그 내용을 Esc 키 등으로 닫을 수 있어야 하고, 포인터를 그 내용 위로 옮겨도 사라지지 않아야 하며, 사람이 치우기 전까지 머물러야 한다고 요구한다. 화면 확대를 쓰는 사람이 말풍선을 읽으려고 포인터를 옮기다가 말풍선이 사라지는 일을 막기 위해서다.

서윤의 웹 개편 노트