테스트와 지속적 개선

초록 체크마크 너머

🔄 Quick Recall: 이전 레슨에서 포용적 설계를 실제 시나리오에 적용했어요 — 폼, 내비게이션, 에러 상태, 온보딩. 다양한 능력의 사용자를 위해 인터랙션을 설계했어요. 이번에는 접근성이 지속적으로 개선되도록 테스트와 측정 시스템을 구축해요 — 연 1회 감사가 아니라 상시 모니터링.

대부분 조직이 접근성을 프로젝트로 취급해요: 감사하고, 고치고, 끝. 하지만 웹사이트는 끊임없이 변해요 — 새 기능, 새 콘텐츠, 새 팀원. 지속적 테스트 없이는 접근성이 시간이 지나면 퇴보해요. AI 기반 테스트 도구가 지속적 모니터링을 실용적으로 만들어줘요.

접근성 테스트의 세 층

세 층 모두 필요해요. 어느 것도 단독으로는 충분하지 않아요.

1층: 자동화 테스트

자동화 테스트 도구

한국에서는 KWACC(한국웹접근성평가센터)의 자동 평가 도구도 KWCAG 2.2 기준에 맞춰 활용할 수 있어요.

✅ Quick Check: 자동화 접근성 테스트가 주간이 아닌 매 PR마다 실행돼야 하는 이유는? 접근성 회귀는 개발 중에 잡을 때 수정 비용이 가장 낮기 때문이에요. 10분 전 PR에서 대비 이슈를 도입한 개발자는 몇 초 만에 고칠 수 있어요. 주간 스캔에서 잡힌 같은 이슈는 컨텍스트 전환, 조사, 새 PR이 필요해요 — 10배의 노력이에요.

2층: 수동 전문가 리뷰

자동화 도구가 평가할 수 없는 것들:

• 탭 순서가 논리적인지
• 스크린 리더 발표가 맥락에서 의미 있는지
• 콘텐츠가 인지적으로 명확한지
• 애니메이션이 모든 상태에서 사용자 설정을 존중하는지
• 에러 메시지가 실제로 도움이 되는지

수동 감사 체크리스트

키보드 테스트:

• 모든 인터랙티브 요소에 Tab으로 접근 가능?
• 탭 순서가 논리적(시각적 흐름과 일치)?
• 드롭다운, 모달, 툴팁이 마우스 없이 조작 가능?
• 키보드 트랩이 있는가(Tab으로 들어갈 수는 있지만 나올 수 없는)?
• 모든 포커스 요소에 포커스 표시기가 보이는가?

스크린 리더 테스트:

• 페이지를 순차적으로 읽으면 의미가 통하는가?
• 헤딩이 설명적이고 적절히 중첩돼 있는가?
• 이미지에 의미 있는(단순 존재가 아닌) 대체 텍스트가 있는가?
• 폼 안내가 입력 전에 발표되는가?
• 동적 업데이트가 발표되는가(aria-live 영역)?

3층: 사용자 테스트

5-8명 참가자를 장애 유형별로 모집하고, 본인의 기기와 보조 기술로 테스트해요. 핵심은 페이지가 아닌 과업을 테스트하는 거예요.

테스트 과업 예시:

1. “사이트에서 X를 찾으세요” — 내비게이션 테스트
2. “회원가입을 완료하세요” — 폼 테스트
3. “반품 정책을 찾으세요” — 콘텐츠 테스트
4. “장바구니에 항목을 추가하고 결제하세요” — 인터랙션 테스트

진행 상황 측정

✅ Quick Check: ‘완료 시간 비율’(보조 기술 사용자 vs 비AT 사용자)이 가장 중요한 접근성 지표 중 하나인 이유는? 준수가 아닌 실제 사용성을 측정하기 때문이에요. 시력 있는 마우스 사용자가 결제를 2분에 완료하는데 스크린 리더 사용자가 20분 걸리면, 기술적으로는 접근 가능하지만 실질적으로는 사용 불가예요. 2배 이하 목표는 도전적이지만 잘 설계된 인터페이스에서 달성 가능해요.

핵심 정리

• 접근성 테스트는 세 층이 필요: 자동화 스캔(구조적 준수), 수동 전문가 리뷰(인터랙션 품질), 보조 기술 사용자와의 사용자 테스트(실제 사용성)
• 자동화 스캔 점수(도구가 감지하는 30%의 이슈)를 유일한 성공 지표로 사용하면 안 돼요 — 나머지 70%는 인간 평가가 필요
• 자동화 접근성 테스트를 매 PR에 실행(주간이 아닌)해서 수정 비용이 가장 낮을 때 회귀를 잡으세요
• 5-8명 참가자가 본인의 기기와 설정으로 하는 사용자 테스트가 어떤 준수 검사로도 식별할 수 없는 경험적 이슈를 드러내요
• 완료 시간 비율(AT 사용자 vs 비AT 사용자)이 궁극적 접근성 지표 — 핵심 작업에서 2배 이하를 목표로

Up next: 마지막 레슨에서 모든 것을 완전한 접근성 프로그램으로 조립해요 — 조직 구조, 팀 관행, 지속적 개선 프로세스.