자동 접근성 테스트 (Accessibility Testing, a11y)는 디지털 포용성 확보를 위한 이니셔티브가 발전하면서 특히 중요해졌습니다. 처음에는 수동으로 검사를 수행했으며, 이로 인해 종종 치명적인 결함이 놓치거나 늦게 발견되는 경우가 많았습니다. 현대의 접근 방식은 특수 도구를 통한 자동화 및 CI/CD에 a11y 검사를 통합하는 것을 포함합니다.
문제의 역사: 접근성에 대한 첫 번째 검사는 전적으로 수동으로 이루어졌으며, 이는 시간 소모가 크고 인간 요소에 의존했습니다. 표준(WCAG, Section 508)이 등장함에 따라 axe, pa11y, Lighthouse와 같은 도구들이 개발되어 과정을 크게 자동화할 수 있었습니다.
문제: 주요 어려움은 자동화로 모든 접근성 측면을 다루기 어렵다는 것입니다 (예: 복잡한 그래픽 콘텐츠에 대한 적절한 대안 또는 스크린 리더를 위한 텍스트의 적합성). 또한 특정 위젯, 비동기 인터페이스 지원 및 테스트 파이프라인 내에서 a11y 플러그인 설정에서 종종 어려움이 발생합니다.
해결책: 표준 체크(auto-checks)와 수동 비즈니스 프로세스 검증을 결합하여 접근성 전문가를 참여시키는 것이 중요합니다. 좋은 관행은 pull request와 주요 릴리스 시 a11y 스캐너를 통합하여 "접근성 기술적 부채"를 생성하지 않도록 하는 것입니다.
주요 특징:
속임수 질문 1
"전체 접근성을 보장하기 위해 자동 스캐너만 사용하는 것으로 충분한가요?"
답변: 아니요, 자동 도구는 접근성 요구 사항의 약 30-50%만 충족합니다. 나머지 부분은 수동 테스트와 실제 보조 기술로만 발견할 수 있습니다.
속임수 질문 2
"단지 role="button" 같은 속성을 추가하기만 하면 요소가 접근 가능해질까요?"
답변: 항상 그런 것은 아닙니다. 올바른 초점 관리, 키보드 지원, 이벤트 처리 및 스크린 리더에 대한 설명 텍스트를 제공해야 합니다.
속임수 질문 3
"접근성 테스트가 CI를 많이 지연시킨다면, 월 1회만 실행하는 것이 의미가 있을까요?"
답변: 아니요, 이러한 테스트는 변경이 있을 때마다 실행되어야 하며, 그렇지 않으면 접근성과 관련된 회귀를 제때 발견하기 어렵고 수정이 더 복잡하고 비용이 많이 듭니다.
팀은 한 번 Lighthouse를 실행하고 확인 목록에 체크를 하기로 결정했습니다. 몇 가지 오류를 발견하고 수정했지만, 나중에 실제 은행 애플리케이션에서 시각 장애인 사용자가 카드를 올바르게 발급할 수 없었음이 밝혀졌습니다: 중요한 메시지가 읽히지 않았고, 버튼이 스크린 리더에 대해 "보이지 않는" 상태였습니다.
장점:
단점:
처음부터 a11y 검사기가 파이프라인 및 프로젝트 규정에 통합되었고, 보조 기술을 이용한 수동 검사가 정기적으로 시행되었으며 외부 전문가와의 인터뷰도 진행되었습니다. 그 결과 시각 장애인 고객들이 은행의 웹 인터페이스를 편리하게 사용할 수 있었습니다.
장점:
단점: