DevRoutine — 매일 기술 면접 질문

접근성을 고려한 focus 스타일은 키보드 사용자와 보조 기술 사용자가 현재 위치를 명확히 알 수 있도록 설계하는 시각적 신호입니다. 예쁜 outline을 만드는 문제가 아니라, 마우스 없이도 서비스를 사용할 수 있게 하는 기본 내비게이션 장치입니다.

핵심 개념

focus 표시가 없으면 Tab 이동 중 현재 위치를 알 수 없어 사용이 사실상 불가능해집니다.
:focus-visible은 키보드 탐색 등 focus 표시가 필요한 상황에만 스타일을 적용할 수 있게 해줍니다.
색상만으로 의존하지 말고 두께, offset, 배경 대비 등 여러 단서를 함께 사용해야 합니다.

동작 방식 또는 판단 기준

이 주제를 이해할 때는 다음 순서로 보면 실무 적용이 쉬워집니다.

무엇을 해결하려는가: 성능, 표현력, 안정성, 접근성 중 어떤 문제를 줄이려는지 확인합니다.
전제 조건은 무엇인가: 정렬 여부, 브라우저 지원, 네트워크 특성, 동시성 조건처럼 성립해야 하는 조건을 점검합니다.
비용은 어디서 발생하는가: 시간 복잡도, 메모리, 캐시, 재시도, 렌더링 비용처럼 병목 지점을 나눠 봅니다.
실패 시 어떤 문제가 생기는가: 잘못 적용했을 때의 버그나 운영 리스크를 함께 고려합니다.

실제 예시

CSS

:where(a, button, input, select, textarea, [tabindex]):focus {
  outline: none;
}

:where(a, button, input, select, textarea, [tabindex]):focus-visible {
  outline: 3px solid #2563eb;
  outline-offset: 3px;
  box-shadow: 0 0 0 5px rgba(37, 99, 235, 0.18);
}

.button:focus-visible {
  border-radius: 8px;
}

HTML

<button class="button">저장</button>
<a href="/settings">설정으로 이동</a>

실무에서 주의할 점

outline: none만 선언하고 대체 스타일을 제공하지 않는 것이 가장 흔한 접근성 버그입니다.
outline이 부모의 overflow: hidden에 잘리면 focus가 보이지 않을 수 있습니다.
비활성처럼 보이는 낮은 대비의 focus 링은 실제 사용자에게 도움이 되지 않습니다.

실무 적용 가이드

Tab, Shift+Tab, Enter, Space, Esc 흐름을 실제로 테스트합니다.
디자인 시스템에 focus token을 만들고 모든 인터랙티브 컴포넌트가 공유하게 합니다.
커스텀 컴포넌트는 semantic element를 우선 사용하고 불가피하면 ARIA와 키보드 이벤트를 함께 구현합니다.

함께 연결해서 보면 좋은 키워드

Accessibility, focus-visible, keyboard navigation, WCAG

정리

접근성을 고려한 focus 스타일은 키보드 사용자와 보조 기술 사용자가 현재 위치를 명확히 알 수 있도록 설계하는 시각적 신호입니다. 다만 개념 자체보다 중요한 것은 적용 조건과 한계를 함께 이해하는 것입니다. 작은 예제에서는 단순해 보여도 실제 서비스에서는 성능, 보안, 유지보수성, 접근성 요구사항이 함께 얽히므로, 문제의 성격을 먼저 파악한 뒤 적절한 도구로 선택하는 것이 좋습니다.

접근성을 고려한 focus 스타일은 어떻게 설계해야 하나요?

답변 포인트

정답 및 해설