브라우저 안에서만 계산
키보드 초점 표시 설계기·수동검사표
초점 색과 배경 대비, 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입니다.
자체 검증 도식
수정 전·후 예제
기본 표시만 제거한 버튼
대체 표시 없음
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 가림 수동 표본 미완료
자주 묻는 질문
브라우저 기본 outline이면 자동 통과인가요?
아닙니다. 기본 스타일이 실제 배경에서 보이고 가려지지 않는지 해당 브라우저와 운영체제에서 확인합니다.
대비 3:1이면 초점 검사가 끝나나요?
아닙니다. 순서, 함정, 가림, 키 동작은 별도의 수동 검사입니다.