리디자인을 거쳐도 살아남는 포커스 상태: 키보드 우선 체크리스트

:focus-visible {
  outline: 2px solid currentColor;
...

:root { --focus-ring: #1a1a1a; }
[data-theme=

배경이 예측 불가능한 요소(예: 사진이나 비디오 위에 놓인 버튼)의 경우, 대비되는 색상으로 두 번째 링을 추가하여 최소한 절반은 항상 보이도록 합니다:

흰색 링과 검은색 헤일로(halo)입니다. 그 뒤에 무엇이 있든 둘 중 하나는 반드시 승리합니다. 저는 실제로 이중 레이어가 필요한 곳에서만 `box-shadow`를 사용하고, 폴백(fallback)이 더 중요하기 때문에 클리핑 위험을 감수할 것입니다.

어떤 대비 도구로도 비율을 확인하세요. 아웃라인 색상을 고르고 배경을 선택한 다음 숫자를 읽으세요. 3:1 미만이라면 아웃라인을 두꺼운 2px로 늘리거나 색상을 변경하세요. 은은하게 보이게 하려고 링을 얇게 만들지 마세요. 필요로 하는 사람에게는 '은은함'과 '보이지 않음'이 같은 것이기 때문입니다.

그 사이에, 포커스가 강제 색상 모드(forced-colors mode)에서도 작동하는지 확인하세요. Windows의 고대비 모드는 사용자의 색상을 완전히 무시하며, `box-shadow`가 때때로 실패하는 곳에서 `outline`은 그 재정의를 견뎌냅니다. 이것이 제가 아웃라인을 기본값으로 사용하는 또 다른 이유입니다.

## 페이지 전체를 Tab 키로 이동하기 (마우스 분리)

이것은 CSS 검사가 놓치는 모든 것을 잡아내는 테스트입니다. 저는 마우스를 치워두고, 마치 다른 선택지가 없는 것처럼 시작부터 끝까지 페이지 전체를 Tab 키로 이동합니다.

순서는 시각적 레이아웃을 따라야 합니다. 위에서 아래로, 왼쪽에서 오른쪽으로, 읽는 순서대로 말이죠. 만약 포커스가 헤더에서 푸터로 갔다가 다시 중간으로 점프한다면, DOM(문서 객체 모델) 순서가 시각적 순서와 일치하지 않는 것이고, 키보드 사용자는 지도가 없는 상태로 페이지를 돌아다니게 됩니다.

이것은 리디자인 후에 끊임없이 깨집니다. 왜냐하면 CSS는 DOM을 건드리지 않고도 시각적으로 요소를 이동시킬 수 있게 해주기 때문입니다. 플렉스박스(flexbox)의 `order`나 그리드 배치(grid placement)를 사용하여 HTML의 가장 아래에 위치하는 사이드바를 왼쪽에 두게 만들 수 있습니다. 보기에는 완벽하지만, Tab 순서는 틀립니다. Tab 순서를 고치지 말고 DOM 순서를 고치세요. 양수 값을 가진 `tabindex`는 저항하세요. 그것은 다음 사람의 작업을 더 어렵게 만드는 임시방편일 뿐입니다.

제가 확인하는 것들:

- 모든 정지 지점(stop)마다 보이는 포커스 링을 제공하고, 소리 없이 건너뛰는 부분이 없어야 합니다.

- 숨겨진 요소 중 포커스를 받을 수 있는 것이 없어야 합니다. 모바일 메뉴가 닫혀 있다면, 그 링크들은 탭 순서에 포함되어서는 안 됩니다.

- 트랩(trap)이 없어야 합니다. 모든 모달(modal), 드롭다운(dropdown), 날짜 선택기(date picker)에서 Tab 키를 이용해 빠져나올 수 있어야 합니다. 만약 무언가를 열었는데, 탈출구 없이 그 안에서 Tab 순환만 계속된다면 그것은 트랩이며, 이때 Escape 키가 이를 닫아야 합니다.

- 스킵 링크(skip link)를 첫 번째 정지 지점으로 두어, 키보드 사용자가 모든 페이지에서 네 개의 메뉴 항목을 차례로 탭하는 대신 내비게이션(nav)을 건너뛰고 메인 콘텐츠로 바로 이동할 수 있게 해야 합니다.

모달 트랩은 컴포넌트 교체 후에 문제가 발생하는 부분입니다. 좋은 모달은 열려 있는 동안 의도적으로 포커스를 가두었다가, 닫힐 때 그것을 연 버튼으로 포커스를 되돌려줍니다. 반면 나쁜 모달은 영원히 포커스를 가두거나, 사용자가 완전히 길을 잃게 만드는 페이지 상단으로 다시 던져버립니다. 모든 오버레이(overlay)를 열어보고, Tab 키로 순회하며, Escape 키를 누른 후, 포커스가 합리적인 곳에 착지하는지 확인하세요.

또한 화면 크기를 좁게 조정한 후에도 Tab 순회를 해봐야 합니다. 모바일 레이아웃은 요소들의 순서를 재배열하고 일부를 숨기기 때문입니다. 데스크톱의 탭 순서는 완벽할 수 있지만, 모바일 버전은 엉망일 수 있습니다.

이 워크(walk)를 주요 화면마다 한 번씩 실행하세요. 몇 분밖에 걸리지 않으며, 실제로 키보드 사용자가 되어보는 것과 가장 유사합니다. 만약 이 목록에서 단 하나의 항목만 수행해야 한다면, 이것을 수행하세요. [RAXXO가 따르는 모든 도구의 명령 명명 규칙](https://dev.to/blogs/lab/the-command-naming-convention-every-raxxo-tool-follows)에서의 명명 및 구조에 대한 규율은 같은 정신입니다. 예측 가능한 순서를 통해 아무도 길을 잃지 않게 하는 것입니다.

## 핵심 요약 (Bottom Line)

이 네 가지 검사를 순서대로 실행하면, 리디자인이 도입하는 거의 모든 포커스 회귀(focus regression)를 잡아낼 수 있습니다. `:focus-visible`을 적용하고, 링에 2px의 오프셋을 주며, 어두운 모드(dark mode)를 포함한 모든 배경색과 대비되는 3:1의 명암비를 유지하도록 설정한 다음, 마우스를 치우고 전체 페이지를 Tab 키로 순회해 보세요.

만약 하나만 남겨야 한다면, 그것은 탭 워크입니다. CSS는 스타일시트에서 완벽해 보일 수 있지만 실제 흐름에서는 실패할 수 있으며, 이를 알 수 있는 유일한 방법은 키보드 사용자가 페이지를 사용하는 방식대로 테스트하는 것입니다.

이것을 배포 전 루틴에 추가하면 근육 기억(muscle memory)이 됩니다. 저는 이것을 나머지 출시 게이트들과 같은 장소에 보관하는데, 기억해야 하는 체크리스트는 바쁜 날 건너뛰기 쉽기 때문입니다.

제가 이렇게 기본값을 설정하고 구축하는 모든 곳에 상속받는 전체적인 그림을 원한다면, [Claude Blueprint](https://dev.to/pages/claude-blueprint)가 전체 접근 방식을 설명합니다. 마우스를 분리하고 홈페이지로 탭해 보세요. 적어도 하나의 막히는 지점(dead stop)을 찾게 될 것입니다.