브라우저 안에서만 계산

키보드 초점 표시 설계기·수동검사표

초점 색과 배경 대비, outline 제거 위험을 계산하고 순서·함정·가림은 수동 검사표로 분리합니다.

무엇을 결정할 수 있나요?

사용자 정의 outline의 색상과 인접 배경 대비를 계산하고 복사 가능한 CSS 후보를 만듭니다.

초점 순서, 키보드 함정, sticky 영역에 의한 가림은 색상 계산으로 알 수 없으므로 실제 Tab 이동 기록과 분리합니다.

이 페이지의 고유 질문: 초점 색상 대비가 통과해도 실제 키보드 사용성 검사가 왜 남는가?

로컬 계산 도구

값을 입력해 검사하기

입력값은 브라우저 상태에서만 처리하며 서버·URL·Analytics로 보내거나 저장하지 않습니다.

표시 방식

자동으로 확인하는 범위

  • outline 색과 배경의 대비
  • 굵기·offset을 포함한 CSS 후보
  • outline:none과 대체 표시 유무
  • 순서·함정·가림·복합 위젯은 수동 체크리스트

입력값과 단위

배경·경계·초점색
컴포넌트 인접 영역과 사용자 정의 표시 색
굵기·offset
outline 또는 box-shadow 설계값
outline 제거
기본 포커스 링 제거 여부 및 대체 표시 유무

판정할 때 지키는 원칙

  • outline:none이고 대체 표시가 없으면 fail입니다.
  • 사용자 정의 표시의 비텍스트 대비가 3:1 미만이면 해당 색상 하위검사를 fail로 표시합니다.
  • 브라우저 기본 outline과 실제 키보드 흐름은 manual_review입니다.

자체 검증 도식

초점 표시 시각화 및 고정 영역(Sticky Footer) 가림 방지 도식3px solid outline으로 3대1 대비를 충족하더라도 고정 하단 바 뒤로 초점이 숨겨지면 WCAG 2.2 2.4.11 초점 가림 방지 기준을 만족하지 못합니다. scroll-padding으로 안전 여백을 확보해야 합니다.WCAG 2.2 2.4.11 초점 가림(Focus Not Obscured) 및 2.4.7 가시성고정 하단 바 뒤에 가려진 초점페이지 본문 스크롤 영역초점 도달 버튼고정 하단 바 (position: fixed)FAIL (2.4.11): 초점 대상이 완전히 가려짐scroll-padding 적용 후 완전 노출:focus-visible 3px고정 하단 바 (position: fixed)PASS: scroll-padding-bottom으로 안전 간격 확보
자체 검증 도식: 선명한 3px 초점 링을 제공하더라도 fixed header나 footer 뒤로 초점 대상이 가려지면 WCAG 2.4.11 실패입니다. `scroll-padding` CSS를 통해 키보드 포커스 시 충분한 시야를 확보해야 합니다.

수정 전·후 예제

기본 표시만 제거한 버튼

대체 표시 없음

button:focus { outline: none; }

키보드 초점 후보

button:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

색상 후보를 다시 계산하고 강제색 모드에서도 표시가 남는지 확인합니다.

가려진 초점

색상은 통과하지만 footer가 가림

.sticky-footer { position: fixed; bottom: 0; }

스크롤 여백과 실제 재검사

main { scroll-padding-block-end: 6rem; }
:focus-visible { scroll-margin-block: 1rem; }

가림 문제는 CSS 후보 적용 후 키보드로 실제 스크롤 위치를 재검사해야 합니다.

실무 판단 가이드

outline을 되살린 뒤에도 검사가 남는다

먼저 바로잡을 통념

outline:none만 제거하거나 대비 3:1을 맞추면 키보드 접근성 검사가 끝난다.

보이는 표시가 있어도 초점이 논리적 순서로 이동하고 모든 조작 요소에 도달하며 빠져나올 수 있어야 합니다.

고정 header·footer, modal, 스크롤 컨테이너가 현재 초점을 완전히 가리는지는 실제 뷰포트와 키보드 이동에서 확인해야 합니다.

판단 순서

  1. 마우스를 치우고 페이지 처음부터 Tab을 시작한다.
  2. 현재 초점을 시각적으로 추적한다.
  3. Shift+Tab으로 역순을 확인한다.
  4. modal과 복합 위젯의 기대 키를 실행한다.
  5. 360px와 200% 확대에서 가림을 확인한다.
  6. OS·브라우저·날짜와 실패 위치를 기록한다.

실패했을 때 복구

  • 대체 표시 없이 outline을 제거한 규칙을 삭제합니다.
  • 키보드 흐름이 DOM 순서와 다르면 임의 tabindex 양수를 제거하고 구조를 고칩니다.
  • 고정 영역 가림은 scroll-padding/margin 또는 레이아웃을 조정한 뒤 같은 경로를 재검사합니다.

회귀 테스트와 검수 증거

아래 fixture는 실제 고객 사례가 아니라 판정 로직이 같은 입력에 같은 결과를 내는지 확인하는 공개 회귀 자료입니다. 현장 사용 경험으로 과장하지 않습니다.

키보드 초점 표시 설계기·수동검사표 회귀 입력과 기대 결과
Fixture ID입력기대 결과
focus-noneoutline:none, 대체 표시 없음fail
focus-blue#005fcc / #ffffff, 3px색상 하위검사 결과 + 흐름 manual_review
focus-gray#aaaaaa / #ffffff, 2px약 2.323:1, 색상 하위검사 fail

대표 fixture 검증 기록

검사 환경
브라우저 및 테스트 환경: 대표 fixture 기반 자동 테스트 및 DOM 파서 검증; 실제 화면낭독기 수동 검사는 미검사
예상 결과
색상 하위검사는 pass 가능하지만 가림은 manual_review이며 실제 키보드 검사에서 별도 판정
자동 결과
초점 색상 대비와 면적 계산을 수행하며, 고정 영역에 의한 가림 여부는 수동 검토 항목으로 안내합니다. (실제 키보드 조작과 강제색 모드는 수동 검토 필요)
재검사 방법
작은 뷰포트와 200% 확대에서 Tab으로 버튼을 다시 찾아 완전히 보이는지 기록합니다.

자동 결과 뒤에 남는 검사

  • Tab 순서
  • 고정 영역 가림
  • 강제색 모드
  • modal·복합 위젯 키 동작

자동 판정의 한계

  • 실제 Tab 순서와 키보드 함정
  • modal과 복합 위젯의 포커스 관리
  • sticky header·footer 가림
  • 브라우저 기본 outline과 강제색 모드
  • 시간이 지나 표시가 사라지는 동작

반드시 남는 수동 확인

  • Tab과 Shift+Tab 순서가 작업 흐름과 맞는가?
  • 모든 조작 요소에 초점이 도달하고 빠져나올 수 있는가?
  • 고정 영역이나 modal이 초점을 완전히 가리지 않는가?
  • Enter·Space·화살표키가 위젯 역할에 맞게 동작하는가?

공식 상세 근거

로직 버전 focus-indicator-1.0.0 · 공개 검수일 2026-08-04 · 검수 책임 서호영 (운영·콘텐츠 검토 책임)

이번 공개 검수 범위

초점 대비·면적 계산과 실제 키보드 수동 질문의 분리 대조, Chromium 표본 검수

  • 테스트 증거: 초점 색상·면적·outline 제거 단위 테스트와 Playwright 키보드 흐름
  • 콘텐츠 검토: outline 통념과 sticky footer fixture를 도구 본문에 통합
  • 미검사·한계: NVDA·VoiceOver 미검사
  • 미검사·한계: 강제색 모드와 실제 sticky 가림 수동 표본 미완료

자주 묻는 질문

브라우저 기본 outline이면 자동 통과인가요?

아닙니다. 기본 스타일이 실제 배경에서 보이고 가려지지 않는지 해당 브라우저와 운영체제에서 확인합니다.

대비 3:1이면 초점 검사가 끝나나요?

아닙니다. 순서, 함정, 가림, 키 동작은 별도의 수동 검사입니다.