사용자 선택과 토큰 시스템으로 시작하세요
prefers-color-scheme을 사용해 시스템 설정을 기본값으로 삼으세요. 토글을 제공한다면 접근 가능한 이름과 키보드 조작이 가능한 컨트롤을 사용하고 활성 선택을 프로그래밍적으로 노출하세요. 수동 선택은 해당 브라우저 컨텍스트에서 우선권을 갖도록 하고, 다른 기기나 시크릿 세션으로 자동으로 이어진다고 약속하지 마세요.
색상 이름은 외형이 아니라 역할로 명명하세요: canvas, surface, text, muted text, border, link, accent, error, success, focus, disabled 등. 두 테마 모두에서 모든 역할을 매핑하세요. 이렇게 하면 라이트 전용 회색이 다크 모드로 유입되는 것을 막고 수정을 재사용할 수 있게 합니다. 다크가 본질적으로 더 접근성이 높거나 보편적으로 선호되는 것은 아니며, 접근 가능하게 만들어야 하는 또 다른 경험입니다.
저장된 선택을 우선하고 시스템 선호도를 그 다음으로 하는 등 팀이 동일한 결과를 테스트할 수 있도록 문서화하세요.
기본값뿐 아니라 hover, focus, selected, invalid, disabled, loading, empty, visited-link 상태를 포함하세요.
렌더링된 테마에서 대비를 측정하세요
WCAG 2.2 Success Criterion 1.4.3은 일반 텍스트와 텍스트로 된 이미지에 대해 최소 4.5:1을, 큰 텍스트에는 3:1을 요구합니다. 반올림하지 마세요: 4.499:1은 4.5:1을 충족하지 않습니다. 얇은 서체는 계산된 색상보다 약해 보일 수 있으니 더 견고한 서체나 추가 여백을 사용하세요.
각 렌더된 전경(foreground)과 인접한 배경을 검사하세요. 사진, 그라데이션, 반투명 패널, 비디오 위의 텍스트는 배경이 변화하므로 단일 토큰 계산으로는 가독성을 증명할 수 없습니다. 불투명한 배경, 적절한 오버레이 또는 다른 배치 방식을 사용한 뒤 현실적인 뷰포트에서 검사하세요.
WCAG 2.1 Success Criterion 1.4.11에 따라 활성 컨트롤, 필수 상태 또는 의미 있는 그래픽을 식별하는 데 필요한 시각 정보는 인접 색상과 3:1 대비가 필요합니다.
색상 변경에 텍스트, 아이콘, 패턴, 위치 또는 다른 명확한 신호를 병행하세요; 오류와 선택 상태는 미묘한 색조에만 의존하면 안 됩니다.
키보드 포커스, 양식, 상태 변화를 보호하세요
두 테마에서 Tab으로 순회하세요. 링크, 버튼, 입력, 메뉴, 대화상자, 커스텀 위젯, 테마 컨트롤에서 포커스가 가시적이어야 합니다. 브라우저 아웃라인을 제거하지 말되, 교체하는 경우 모든 표면과 상태에서 테스트하세요. 오프셋 아웃라인은 블렌딩 글로우보다 더 명확한 경우가 많습니다.
WCAG 2.2의 Focus Appearance는 AAA 기준으로 AA 충족을 증명하지는 않지만 유용한 목표입니다: 포커스 표시 영역은 적어도 2 CSS-pixel 둘레만큼 크고, 포커스된 픽셀과 포커스되지 않은 픽셀 간에 3:1 대비가 있어야 합니다. 또한 오류, 필수, 선택 및 사용 불가 상태가 의미를 유지하는지 확인하세요.
입력 힌트, 입력 값, 레이블, 도움말 텍스트, 오류 텍스트, invalid 테두리, 체크박스 표시, 라디오 선택, 제출 상태를 개별적으로 테스트하세요.
체크아웃이나 규제 대상 흐름의 경우 제공자 샌드박스를 사용하고 필요 시 자격 있는 접근성 및 보안 검토를 받으세요. 이는 교육적 안내이며 준수 또는 보안 평가가 아닙니다.
이미지, 임베디드 자산, 브라우저 제공 UI를 처리하세요
로고, 일러스트, 스크린샷, 차트, 아이콘, 이미지에 고정된 텍스트를 두 테마에서 검토하세요. 재사용된 라이트 로고는 사라질 수 있고 차트 범례는 주변 HTML이 통과하더라도 실패할 수 있습니다. 목적에 맞는 자산이나 안정적인 배경을 제공하세요. 지침, 상태 또는 데이터를 전달하는 이미지는 이해 가능하게 유지되어야 합니다.
라이트와 다크 스킴 지원을 선언한 다음 선택된 테마에 맞게 페이지 내용을 스타일링하세요. color-scheme 속성은 브라우저 캔버스, 스크롤바, 폼 컨트롤 등 브라우저 UI를 정렬합니다. 관련 메타데이터를 문서 상단에 배치하세요. 임베디드 SVG는 부모 스킴에 반응할 수 있으니 제3자 iframe 및 위젯을 끝까지 테스트하세요.
시맨틱 HTML 컨트롤을 선호하세요. forced-color 동작은 ARIA 역할을 추가한 일반 요소가 아니라 네이티브 시맨틱을 사용합니다.
다운로드되거나 캐시된, 로드가 느린, 실패한 이미지 상태를 검사하세요. 특히 텍스트나 동작 신호가 미디어 위에 놓인 경우에 주의하세요.
forced-colors를 존중하고 릴리스 전체를 테스트하세요
forced-colors 모드는 Windows High Contrast와 같이 사용자가 선택한 제한된 팔레트를 적용합니다. 브라우저는 색을 교체하고 그림자를 제거하며 텍스트 백플레이트를 추가할 수 있습니다. 오버라이드를 차단하지 마세요. 그림자가 제공하던 경계가 사라지는 등 컴포넌트가 의미를 잃는 곳에는 실제 테두리 같은 표적 수정을 하세요. 에뮬레이션은 모든 기기, 브라우저, 확장, 확대 수준 또는 보조 기술 조합을 대변할 수 없습니다.
출시 전에 라우트 및 상호작용 매트릭스를 라이트, 다크, forced-colors 설정에서 실행하세요. Chrome DevTools는 두 조건을 에뮬레이트할 수 있으니 검토를 가속화하고 우선 흐름은 수동으로 탐색하세요. 스캐너는 후보를 찾지만 접근성 자체를 판정하지 못합니다. SIU는 중요한 테마 자산과 상호작용을 사전검증(preflight)하고 릴리스 게이트를 기록하며 심각한 표현 회귀에 대비한 테스트된 롤백 경로를 유지합니다; 이는 다운타임 모니터링이 아닙니다.
랜딩, 내비게이션, 검색, 계정 접근, 양식, 오류 페이지, 인증된 화면, 자재 변환 흐름을 포함하세요.
테스트한 URL, 브라우저 버전, 설정, 예외, 담당자, 롤백 트리거를 저장해 실제 사실에서 수정 작업을 시작하세요.