브라우저 안에서만 계산
키보드 초점 표시 설계기·수동검사표
초점 색과 배경 대비, outline 제거 위험을 계산하고 순서·함정·가림은 수동 검사표로 분리합니다.
무엇을 결정할 수 있나요?
마우스 대신 키보드 Tab 키만으로 웹사이트를 탐색하는 지체 장애인이나 전맹/저시력 사용자에게 '키보드 초점 표시자(Focus Indicator)'는 마우스 커서와 같은 유일한 시각적 나침반입니다. CSS에 :focus { outline: none; }을 걸어두고 대체 스타일을 지정하지 않거나, 상단 고정 헤더 뒤로 초점이 숨어버리는 현상은 사용자가 자신이 페이지의 어디에 위치해 있는지 완전히 길을 잃게 만듭니다.
본 도구는 포커스 링의 두께, 주변 배경과의 3.0:1 이상의 비텍스트 명암비(WCAG 2.4.13), 그리고 scroll-margin-top 오프셋을 통한 WCAG 2.2 2.4.11 초점 가림(Focus Obscured) 방지 여부를 종합적으로 검증합니다.
사용자 조작성을 극대화하기 위한 모던 CSS의 :focus-visible 가상 클래스 활용법과 반응형 고정 헤더 높이 연동 테크닉을 안내합니다.
이 페이지의 고유 질문: 초점 색상 대비가 통과해도 실제 키보드 사용성 검사가 왜 남는가?
로컬 계산 도구
값을 입력해 검사하기
입력값은 브라우저 상태에서만 처리하며 서버·URL·Analytics로 보내거나 저장하지 않습니다.
자동으로 확인하는 범위
- outline 색과 배경의 대비
- 굵기·offset을 포함한 CSS 후보
- outline:none과 대체 표시 유무
- 순서·함정·가림·복합 위젯은 수동 체크리스트
입력값과 단위
- 배경·경계·초점색
- 컴포넌트 인접 영역과 사용자 정의 표시 색
- 굵기·offset
- outline 또는 box-shadow 설계값
- outline 제거
- 기본 포커스 링 제거 여부 및 대체 표시 유무
판정할 때 지키는 원칙
- outline:none이고 대체 표시가 없으면 fail입니다.
- 사용자 정의 표시의 비텍스트 대비가 3:1 미만이면 해당 색상 하위검사를 fail로 표시합니다.
- 브라우저 기본 outline과 실제 키보드 흐름은 manual_review입니다.
자체 검증 도식
수정 전·후 예제
기본 표시만 제거한 버튼
대체 표시 없음
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, 스크롤 컨테이너가 현재 초점을 완전히 가리는지는 실제 뷰포트와 키보드 이동에서 확인해야 합니다.
판단 순서
- 마우스를 치우고 페이지 처음부터 Tab을 시작한다.
- 현재 초점을 시각적으로 추적한다.
- Shift+Tab으로 역순을 확인한다.
- modal과 복합 위젯의 기대 키를 실행한다.
- 360px와 200% 확대에서 가림을 확인한다.
- OS·브라우저·날짜와 실패 위치를 기록한다.
실패했을 때 복구
- 대체 표시 없이 outline을 제거한 규칙을 삭제합니다.
- 키보드 흐름이 DOM 순서와 다르면 임의 tabindex 양수를 제거하고 구조를 고칩니다.
- 고정 영역 가림은 scroll-padding/margin 또는 레이아웃을 조정한 뒤 같은 경로를 재검사합니다.
회귀 테스트와 검수 증거
아래 fixture는 실제 고객 사례가 아니라 판정 로직이 같은 입력에 같은 결과를 내는지 확인하는 공개 회귀 자료입니다. 현장 사용 경험으로 과장하지 않습니다.
| Fixture ID | 입력 | 기대 결과 |
|---|---|---|
focus-none | outline: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·화살표키가 위젯 역할에 맞게 동작하는가?
공식 상세 근거
- WCAG 2.2 Success Criterion 2.4.7 — Focus Visible
- WCAG 2.2 Success Criterion 2.4.11 — Focus Not Obscured (Minimum)
- WCAG 2.2 Success Criterion 2.4.13 — Focus Appearance
- WCAG 2.2 Success Criterion 1.4.11 — Non-text Contrast
이번 공개 검수 범위
초점 대비·면적 계산과 실제 키보드 수동 질문의 분리 대조, Chromium 표본 검수
- 테스트 증거: 초점 색상·면적·outline 제거 단위 테스트와 Playwright 키보드 흐름
- 콘텐츠 검토: outline 통념과 sticky footer fixture를 도구 본문에 통합
- 미검사·한계: NVDA·VoiceOver 미검사
- 미검사·한계: 강제색 모드와 실제 sticky 가림 수동 표본 미완료
자주 묻는 질문
WCAG 2.2에서 초점 표시자에 요구하는 최소 기준은 무엇인가요?
성공 기준 2.4.7(Focus Visible, Level A)에 따라 초점 표시자는 반드시 눈에 보여야 하며, 2.4.13(Focus Appearance, Level AAA)에 따라 최소 2px 이상의 두께와 주변 배경 대비 최소 3.0:1 이상의 명암비를 확보해야 합니다.
상단 고정 헤더 아래로 초점이 가려지는 버그는 어떻게 고치나요?
키보드 초점을 받을 수 있는 모든 요소나 제목 태그에 CSS scroll-margin-top 속성을 선언하고, 상단 고정 헤더의 높이(예: 80px)만큼 오프셋을 지정하면 브라우저가 자동으로 헤더 아래 여백을 두고 스크롤을 멈춥니다.
:focus와 :focus-visible의 차이점은 무엇인가요?
:focus는 마우스 클릭 시에도 파란 테두리가 생겨 디자이너들이 outline: none으로 지워버리는 원인이 되었습니다. 반면 :focus-visible은 키보드 Tab 키로 이동했을 때만 스마트하게 표시되므로, 디자인을 해치지 않고 키보드 접근성을 100% 보장할 수 있습니다.