웹 접근성 및 WCAG 표준

WCAG 2.1은 POUR이라는 약어로 기억되는 네 가지 원칙을 중심으로 구성됩니다. 인식 가능(Perceivable): 사용자는 모든 정보와 UI 구성 요소를 최소한 하나의 감각을 통해 인식할 수 있어야 합니다. 요구사항: 모든 이미지에는 설명적인 대체 텍스트가 있어야 합니다. 모든 비디오 콘텐츠에는 캡션이 있어야 합니다. 색상이 정보를 전달하는 유일한 방법이 아니어야 합니다(예: 오류 상태는 빨간색 외에 텍스트나 아이콘을 사용). 텍스트는 배경과 충분한 색상 대비를 유지해야 합니다(일반 텍스트는 4.5:1, AA 준수 기준 큰 텍스트는 3:1). 운용 가능(Operable): 모든 기능은 키보드만으로 조작 가능해야 합니다(마우스를 사용할 수 없는 운동 장애 사용자는 Tab, Enter, 화살표 키, Escape를 사용하여 모든 워크플로를 탐색, 활성화 및 완료할 수 있어야 합니다). 요구사항: 포커스 상태가 명확하게 보여야 합니다. 키보드 트랩이 없어야 합니다(사용자는 항상 모든 UI 요소에서 벗어날 수 있어야 합니다). 스크린 리더 사용자를 위한 건너뛰기 탐색 링크가 있어야 합니다. 이해 가능(Understandable): 인터페이스는 언어, 동작 및 오류 처리 측면에서 이해 가능해야 합니다. 요구사항: 페이지 언어가 HTML에 지정되어야 합니다. 양식 필드에는 보이는 레이블이 있어야 합니다. 오류 메시지는 무엇이 잘못되었는지, 어떻게 수정해야 하는지 명확하게 식별해야 합니다. UI 동작은 예측 가능해야 합니다(포커스 시 예기치 않은 컨텍스트 변경이 없어야 합니다). 견고함(Robust): 콘텐츠는 보조 기술에 의해 안정적으로 해석될 수 있어야 합니다. 요구사항: 시맨틱 HTML(제목 계층, 랜드마크 요소, ARIA 역할을 적절하게 사용). 양식 요소에는 관련 레이블이 있어야 합니다. 사용자 지정 대화형 구성 요소는 올바른 ARIA 패턴을 구현해야 합니다.

접근성 테스트는 자동 스캐닝과 수동 테스트를 조합해야 합니다. 자동화 도구는 WCAG 문제의 약 30~40%를 찾아내고, 보조 기술 및 장애인 사용자 연구를 통한 수동 테스트가 나머지를 찾아냅니다. 자동 테스트 도구: Axe(브라우저 확장 프로그램 + CI 통합 — 가장 널리 사용되고 정확한 자동화 도구); WAVE(WebAIM의 브라우저 확장 프로그램 — 문제의 시각적 주석에 유용); Lighthouse(Chrome DevTools에 내장 — 접근성 감사 포함). 자동 테스트는 모든 풀 리퀘스트에서 CI 파이프라인에서 실행되어야 하며, 새로운 접근성 위반이 발생하면 빌드를 실패시켜야 합니다. 수동 테스트 프로토콜: 키보드 탐색 감사(키보드만 사용하여 모든 워크플로 탐색 — Tab으로 앞으로 이동, Shift+Tab으로 뒤로 이동, Enter/Space로 활성화, Escape로 닫기). 모든 트랩이나 깨진 경로를 문서화합니다. 스크린 리더 테스트: NVDA + Firefox(Windows, 무료) 및 VoiceOver + Safari(macOS, 내장)로 테스트합니다. 핵심 사용자 흐름을 탐색하고 올바르게 발표되지 않거나, 컨텍스트가 누락되었거나, 혼란을 야기하는 요소를 식별합니다. 색상 대비 확인: 디자인 시스템 및 제품의 모든 텍스트/배경 조합에 대해 색상 대비 분석 도구(ColorContrastChecker, Colour Contrast Analyser 앱)를 사용합니다. 장애인 사용자 테스트: 관련 장애(시각, 운동, 인지)를 가진 2~3명의 사용자와 분기별 유용성 세션을 통해 자동화 도구가 생성할 수 없는 정성적 통찰력을 얻습니다.

VPAT(Voluntary Product Accessibility Template)는 ITI(Information Technology Industry Council)에서 발행하는 표준화된 문서로, 제품이 각 WCAG 2.1 기준 및 섹션 508 요구사항(미국 연방 접근성 법률)을 어떻게 충족하는지 설명합니다. 엔터프라이즈 및 정부 조달 팀은 공급업체 평가의 일환으로 완성된 VPAT(공식적으로는 ACR, Accessibility Conformance Report라고 함)를 요구합니다. VPAT 없이는 많은 정부, 의료, 금융 서비스 및 교육 부문 거래가 자동으로 실격 처리됩니다. 이는 접근성을 위한 보안 설문지라고 할 수 있습니다. VPAT 섹션: 각 WCAG 성공 기준에 대해 VPAT은 다음을 기록합니다. 지원(Supports, 제품이 기준을 완전히 충족함); 부분 지원(Partially Supports, 제품이 일부 요구사항은 충족하지만 전부는 아님, 설명 포함); 미지원(Does Not Support, 제품이 이 기준을 충족하지 않음, 설명 포함); 해당 없음(Not Applicable, 이 기준이 이 제품 유형에 적용되지 않음). VPAT의 정직성과 정확성: 제품이 충족하지 않는 기준에 대해 '지원'을 주장하는 VPAT은 법적 책임이 있습니다. VPAT은 접근성 감사 결과(자동 + 수동 테스트)와 법률 검토를 조합하여 준비되어야 합니다. Product Ops는 VPAT 작성을 조율합니다. 감사를 위해 외부 접근성 컨설턴트를 참여시키고, 검토를 위해 법무팀을 참여시키며, 제품 변경에 따라 분기별 업데이트 주기를 유지합니다(업데이트 없이 12개월 이상 된 VPAT은 조달 팀에서 신뢰할 수 없는 것으로 간주합니다).