포커스 링

이 표시에 이름이 붙기 전까지 이것은 "브라우저가 멋대로 그리는 파란 테두리" 였습니다. 시안에는 없는데 화면에는 나타나니 디자이너 눈에는 오류로 보였고, 개발자는 한 줄을 써서 지웠습니다. 지우는 데 드는 비용이 없었다는 점이 문제였습니다.

페이지덱에서도 같은 일이 있었습니다. 시안 검수 자리에서 민서가 버튼에 생기는 파란 테두리를 지워 달라고 했고, 태오가 그날 지웠습니다. 둘 다 마우스로만 써 봤으니 몇 달 동안 아무도 이상한 점을 느끼지 못했습니다. 문제는 공공기관 고객사의 접근성 검토서에서 드러났습니다. 탭 키만으로 화면을 넘겨 본 검토자가, 엔터를 눌렀더니 자기가 누른 적 없는 버튼이 동작했다고 적어 보냈습니다.

키보드만 쓰는 사용자에게는 이 테두리가 마우스 커서에 해당합니다. 커서를 지우면 아무도 마우스를 못 쓴다는 데는 모두가 동의하면서, 같은 일을 키보드 쪽에서는 아무렇지 않게 해 왔던 겁니다. 포커스 링이라는 이름은 그 테두리를 장식이 아니라 갖춰야 할 요소로 부르려고 붙었습니다.

브라우저는 화면의 조작 가능한 요소 가운데 언제나 하나에만 포커스를 두고 그 둘레에 테두리를 그립니다. 포커스는 키보드 입력이 전달되는 자리를 뜻합니다. 타자를 치면 글자가 들어갈 입력창, 엔터를 누르면 눌릴 버튼이 포커스를 가진 요소입니다.

한 번의 조작은 세 단계로 나뉩니다.

1. 사용자가 탭 키를 누르면 포커스가 다음 순서의 요소로 옮겨 갑니다. 순서는 보통 화면에 적힌 순서를 따르고, 시프트와 함께 누르면 거꾸로 갑니다.
2. 포커스를 받은 요소 둘레에 브라우저가 테두리를 그립니다. 이 테두리가 포커스 링입니다.
3. 엔터나 스페이스를 누르면 테두리가 둘러진 요소가 실행됩니다. 2번이 빠지면 3번이 도박이 됩니다.

테두리는 있기만 해서는 안 되고 눈에 보여야 합니다. WCAG는 웹 표준을 만드는 국제 단체가 낸 접근성 지침으로, 포커스 표시가 갖출 조건이 숫자로 적혀 있습니다. 두께는 2픽셀 이상, 테두리 색과 그 뒤에 깔린 색의 밝기 차이는 3 대 1 이상입니다. 흰 배경 위의 파란 테두리는 이 값을 넘지만, 파란 버튼 위에 같은 테두리를 그리면 두 색이 거의 붙어 있어 있으나 마나 합니다.

마우스로 눌렀을 때까지 테두리가 남는 게 싫어 지우는 경우가 많은데, 골라서 보여 주는 방법이 있습니다. 브라우저는 키보드로 이동해 온 포커스와 마우스 클릭으로 생긴 포커스를 구분하므로, 키보드로 왔을 때만 링을 그리도록 지정하면 됩니다. 마우스 사용자의 화면은 깨끗해지고 키보드 사용자는 자기 위치를 잃지 않습니다.

이 말이 가장 자주 오가는 자리는 디자인 시스템입니다. 버튼이나 입력창의 상태를 정의할 때 기본·마우스 올림·누름·비활성과 나란히 포커스 상태를 한 칸 더 그려 둡니다. 한 번 정해 두면 화면마다 다시 판단할 일이 없고, 빠뜨리면 그 컴포넌트를 쓰는 모든 화면에서 같이 빠집니다.

직접 만든 컴포넌트에서도 자주 등장합니다. 시맨틱 마크업은 요소의 뜻에 맞는 태그를 쓰는 작성법인데, 버튼용 태그로 만든 버튼에는 포커스와 테두리가 저절로 따라옵니다. 모양만 버튼처럼 꾸민 상자는 탭 키로 아예 닿지 않아 테두리를 그릴 기회조차 없습니다. 링이 안 보인다는 신고가 오면 색부터 고치기 전에 이 자리를 먼저 봅니다.

모달 창처럼 화면 위에 덮이는 요소에서는 링의 위치가 곧 사용자의 위치입니다. 창이 열리면 포커스를 창 안으로 옮기고, 탭으로 창 바깥까지 나가지 않게 가두고, 닫으면 창을 열었던 버튼으로 되돌립니다. 마지막을 빠뜨리면 포커스가 화면 맨 처음으로 튕겨 가서, 목록 스무 번째 항목을 보던 사람이 다시 스무 번 탭을 눌러야 합니다.

접근성 검토서에도 단골로 적힙니다. 키보드 내비게이션은 마우스 없이 모든 기능에 닿게 만드는 일이고, 포커스 링은 그 길 위에서 현재 위치를 알려 주는 표지입니다.

"여기 포커스 링이 브랜드 컬러 버튼 위에서 안 보여요. 흰 링을 한 겹 덧대죠."

같은 계열 색이 겹쳐 밝기 차이가 모자라니, 대비가 확보되는 테두리를 하나 더 두르자는 제안입니다.

"이 드롭다운은 탭으로 안 잡히는데요. 포커스 링 문제가 아니라 마크업 문제예요."

테두리가 안 그려지는 게 아니라 포커스 자체가 그 요소에 가지 않는다는 뜻이고, 고칠 자리가 색이 아니라 태그라는 말입니다.

"마우스로 눌렀을 때만 링을 빼 주세요. 키보드는 그대로 두고요."

보기 싫다는 요구와 접근성 요건이 부딪힐 때 실무에서 합의되는 지점입니다.

페이지덱에서는 검토 지적을 받은 뒤로 이 대화가 디자인 시스템 쪽으로 옮겨 갔습니다. 민서가 버튼 컴포넌트 정의에 포커스 상태를 한 칸 추가하고, 밝은 배경과 어두운 배경 양쪽에서 쓰도록 안쪽 흰 선과 바깥쪽 진한 선을 겹친 두 겹 링으로 그렸습니다. 태오는 그 값을 공통 스타일에 한 번 넣어 두고, 키보드로 이동했을 때만 나타나도록 조건을 걸었습니다.

QA 점검 항목에도 한 줄이 들어갔습니다. 새 화면이 올라오면 마우스에서 손을 떼고 탭 키만으로 끝까지 눌러 보는 절차입니다. 색각 이상 고려처럼 도구가 필요한 항목과 달리 30초면 되므로, 시연 화면을 만드는 수아도 한 번씩 돌려 봅니다.

가장 흔한 오해는 포커스 링을 디자인을 해치는 요소로 보는 것입니다. 시안에 없던 테두리가 화면에만 생기니 잔여물처럼 보이고, 마우스로 써 보면 눌렀던 버튼에 테두리가 남아 거슬립니다. 그런데 거슬리는 쪽은 마우스 클릭 직후이고, 필요한 쪽은 키보드로 이동하는 중입니다. 둘은 구분해 처리할 수 있으니 통째로 지울 이유가 없습니다. 지우면 키보드만 쓰는 사용자는 결제 버튼과 취소 버튼 중 어느 쪽에 서 있는지 모르는 채로 엔터를 누르게 됩니다.

브라우저 기본값이 있으니 따로 디자인할 필요가 없다는 생각도 자주 봅니다. 어디서나 나타나긴 하니 넘기기 쉽습니다. 하지만 기본값은 흰 배경을 가정하고 만들어진 색이라 브랜드 색을 깐 버튼이나 어두운 화면 위에서는 밝기 차이가 모자라 사실상 사라집니다. 링이 있다고 믿고 넘어간 화면이 검수에서 없는 것으로 판정되면, 컴포넌트마다 색을 다시 고르는 일이 한꺼번에 몰립니다.