테스트Medium#250
접근성 테스트에서는 어떤 항목을 자동화할 수 있고 무엇은 수동 확인이 필요한가요?
#테스트#Accessibility#a11y#UI테스트
답변 포인트
자동 규칙 검사와 실제 사용성 검토를 기준으로 정의, 장점, 한계, 예시를 함께 설명해보세요.
정답 및 해설
빠른 요약
자동 도구는 ARIA 오류, 라벨 누락, 일부 대비 문제를 찾을 수 있지만 키보드 흐름과 스크린 리더 사용성은 수동 확인이 필요합니다. 실무 예시: 테스트는 구현 방식보다 사용자가 기대하는 동작과 비즈니스 규칙을 검증할수록 오래 살아남습니다.
접근성 테스트는 자동화로 많은 기계적 문제를 찾을 수 있지만, 실제 사용성이 좋은지는 수동 확인이 필요합니다. 자동화와 키보드/스크린리더 점검을 함께 해야 합니다.
자동화 가능한 항목
axe, Lighthouse, jest-axe, Playwright accessibility scan으로 다음을 확인할 수 있습니다.
- 이미지의
alt누락 - form label 연결 누락
- 버튼/링크의 accessible name 부재
- 색 대비 기준 미달
- 잘못된 ARIA 속성
- heading 계층 구조 문제 일부
TypeScript
import { axe } from 'jest-axe';
const { container } = render(<SignupForm />);
expect(await axe(container)).toHaveNoViolations();수동 확인이 필요한 항목
자동 도구는 “alt가 존재한다”는 것은 찾지만, 그 설명이 적절한지는 판단하기 어렵습니다. 또한 키보드만으로 논리적인 순서로 이동되는지, focus가 모달 안에 갇히는지, 스크린리더에서 문맥이 자연스러운지는 직접 확인해야 합니다.
실무 체크리스트
- Tab/Shift+Tab으로 모든 인터랙션이 가능한지 확인합니다.
- focus outline을 제거하지 않습니다.
- 모달은 focus trap과 Escape 닫기를 제공합니다.
- 에러 메시지는 시각적으로만 표시하지 말고 입력과 연결합니다.
- 색상만으로 상태를 전달하지 않습니다.
면접 답변 포인트
접근성 테스트는 자동화로 명백한 규칙 위반을 빠르게 잡고, 키보드 내비게이션·스크린리더·대체 텍스트 품질은 수동으로 확인해야 합니다. 자동 점수는 출발점이지 충분조건이 아닙니다.