접근성 테스트는 정적 HTML 페이지를 점검하는 것에서 복잡한 JavaScript 기반 애플리케이션을 다루는 것으로 진화했습니다. 초기 웹 접근성은 의미 있는 마크업과 이미지에 대한 대체 텍스트에 중점을 두었습니다. 현대의 싱글 페이지 애플리케이션(SPAs)은 페이지를 새로 고치지 않고 동적으로 콘텐츠가 업데이트되기 때문에 스크린 리더가 변경 사항을 감지하기 어렵게 만들며 도전 과제를 도입했습니다.
핵심 문제는 동적 인터페이스에서 ARIA 라이브 지역 및 포커스 관리와 관련이 있습니다. 실시간 데이터 스트림이 DOM을 업데이트할 때 NVDA나 JAWS와 같은 스크린 리더가 중요한 변경 사항을 발표하지 못하거나 더 나쁜 경우 본질적이지 않은 업데이트로 사용자에게 방해가 될 수 있습니다. 모달 다이얼로그는 포커스를 부적절하게 가두거나 닫을 때 트리거 요소로 포커스를 되돌리지 못하는 방식으로 이 문제를 더욱 복잡하게 만들어 WCAG 2.1 성공 기준 1.3.1 및 2.4.3을 위반합니다.
키보드 탐색 테스트, 스크린 리더 검증 및 인지 흐름 분석을 결합한 체계적인 수동 테스트 프로토콜을 구현하십시오. 첫 번째로 모든 인터랙티브 요소가 마우스에 비 의존적으로 Tab 키 탐색을 통해 접근 가능한지 확인합니다. 두 번째로 실제 스크린 리더로 테스트하여 라이브 지역이 적절한 정중 설정(aria-live="polite" 대 "assertive")을 사용하는지 검증합니다. 세 번째로 브라우저 개발자 도구를 사용하여 포커스 순서를 문서화하여 논리적 순서가 시각적 레이아웃과 일치하는지 확인합니다.
저는 리액트로 구축된 재무 거래 대시보드를 테스트하는 업무를 맡았습니다. 이 대시보드는 실시간 암호 화폐 가격 업데이트를 표시하고 사용자가 모달 다이얼로그를 통해 거래를 실행할 수 있게 해주었습니다. 이 애플리케이션은 시각 장애로 인해 스크린 리더에 의존하는 전문 트레이더를 대상으로 하였으며, 가격 알림을 즉시 통지하면서 업무 흐름의 연속성을 유지해야 했습니다. 놓친 알림은 사용자의 상당한 재정적 손실로 이어질 수 있었기 때문에 Stakes가 높았습니다.
초기 테스트 중에 가격 하락 알림이 스크린 리더 사용자에게 발표되지 않는 것을 발견하여 그들이 중요한 거래 기회를 놓치는 결과를 초래했습니다. 또한 거래 확인 모달을 열 때 포커스가 배경 요소에 남아 있었고, 사용자가 Tab 키로 탐색하는 동안 우연히 거래를 트리거할 수 있게 했습니다. 모달 닫기 버튼도 포커스를 트리거 요소로 다시 돌리지 않아, 사용자들이 페이지 상단에서 탐색을 다시 시작해야 하는 혼란을 초래했습니다.
우리는 axe DevTools와 Lighthouse와 같은 자동 접근성 스캐너를 사용할 것을 고려했습니다. 이 도구는 누락된 alt 속성과 불충분한 색 대비 비율을 효율적으로 식별했습니다. 그러나 이들은 라이브 지역 발표의 타이밍 문제와 모달의 React Portal 구현과 관련된 포커스 관리 문제를 완전히 간과했습니다. 정적 분석으로는 스크린 리더가 실제로 콘텐츠를 올바른 순간에 발표하는지 또는 포커스 트랩이 실제 보조 기술과 함께 작동하는지를 확인할 수 없습니다.
두 번째 접근 방법은 구조화된 테스트 케이스 없이 Windows에서 NVDA, macOS에서 VoiceOver와 함께 순수 수동 테스트를 수행하는 것이었습니다. 이 방법은 특정 포커스 가두기 문제를 포착했지만 일관성이 없고 시간이 많이 걸렸습니다. 다른 테스터들은 스크린 리더 숙련도 수준에 따라 상충되는 결과를 보고했습니다. 이 방법은 개발자가 문제를 수정할 수 있는 재생 가능한 단계를 설정하는 데 실패했으며, 경험담은 각 테스트 세션 사이에서 다르게 나타났습니다.
우리는 구조화된 테스트 계획을 타겟 보조 기술 검증과 결합한 혼합 방법론을 구현했습니다. 저는 NVDA와 Firefox, VoiceOver와 Safari를 기본 조합으로 사용하여 "스크린 리더 호환성"에 대한 구체적인 테스트 케이스를 작성했습니다. 각 테스트 케이스에는 라이브 지역의 정중 수준을 검증하는 특정 단계, 모달을 통과하는 정확한 Tab 탐색 순서를 문서화하는 단계가 포함되어 있었고, 스크린 리더 음성 뷰어를 사용하여 발표 행동을 기록했습니다. 이 접근법은 철저함과 재생 가능성을 균형 있게 조율했습니다.
우리는 구조화된 혼합 접근 방식을 선택했습니다. 이 방법은 개발자에게 특정 ARIA 속성 잘못 구성에 대한 구체적인 재생 가능한 결함 보고서를 제공했습니다. 이 방법론은 즉흥 테스트의 불일치성을 해소하면서 자동 스캐너가 놓친 문제를 포착했습니다. 구조화된 형식은 접근성 테스트에 익숙하지 않은 주니어 QA 엔지니어에게 지식을 전달하는 데도 도움이 되었습니다.
이 접근 방식은 개발 팀이 모든 가격 업데이트에 대해 aria-live="assertive"를 구현하여 지속적인 방해를 유발했다는 사실을 발견했습니다. 우리는 중요한 알림을 "assertive"로, 표준 업데이트를 "polite"로 변경할 것을 권장했습니다. 모달의 경우, 우리는 react-focus-lock 라이브러리를 사용하여 포커스 가두기를 구현하고 포커스가 트리거 요소로 돌아가도록 보장했습니다. 수정 후 검증 결과, 테스트한 스크린 리더 사용자 100%가 알림을 놓치거나 탐색 컨텍스트를 잃지 않고 거래 작업을 성공적으로 완료할 수 있었습니다.
모달 다이얼로그가 닫힐 때 포커스 관리가 제대로 작동하는지 어떻게 확인합니까?
많은 후보자는 모달이 시각적으로 사라지는지만 확인하라고 제안합니다. 올바른 접근 방식은 WCAG 2.1 성공 기준 2.4.3 (포커스 순서)를 이해하는 것입니다. 모달이 Escape 키나 닫기 버튼에 의해 닫힐 때 포커스가 DOM의 맨 위가 아닌 모달을 원래 열었던 요소로 돌아가는지를 확인해야 합니다. 모달을 열고, 닫은 다음 Tab 키를 한 번 눌러 포커스가 트리거 후의 논리적인 다음 요소로 이동하는지 확인합니다. 또한 모달이 보이는 동안 Tab 탐색은 (포커스 가두기) 모달 요소 내에서만 순환되어야 하며, 배경 상호작용을 방지해야 합니다.
정중한 및 단정한 라이브 지역의 차이는 무엇이며, 스크린 리더와 함께 그 행동을 어떻게 테스트합니까?
후보자들은 종종 이러한 ARIA 속성을 혼동하거나 기능이 동일하다고 제안합니다. aria-live="polite"는 스크린 리더가 현재 발화를 마칠 때까지 발표 대기를 하며, 자동 저장 확인과 같은 비판적이지 않은 업데이트에 적합합니다. aria-live="assertive"는 즉시 사용자를 방해하며, 트랜잭션 실패와 같은 치명적인 오류에 예약되어 있습니다. 테스트하려면 브라우저 도구 대신 실제 스크린 리더(NVDA, JAWS 또는 VoiceOver)를 사용하여 두 지역 유형이 스크린 리더가 다른 콘텐츠를 말할 때 업데이트되는 시나리오를 생성합니다. 많은 테스트자는 aria-atomic 및 aria-relevant 속성이 라이브 지역의 일부가 변경될 때 발표 행동을 추가로 제어한다는 점을 간과합니다.
React Router와 같은 프레임워크에서 전체 페이지를 새로 고치지 않고 라우팅 변경에 대한 접근성 테스트를 어떻게 처리합니까?
대부분의 주니어 테스터는 시각적 URL 변경을 확인하지만, 스크린 리더는 페이지 제목 업데이트와 포커스 이동을 통해 내비게이션을 발표하는 데 의존한다는 것을 간과합니다. SPA는 전통적인 페이지 로드 이벤트를 발생시키지 않기 때문에 보조 기술은 사용자가 새로운 뷰로 이동했다는 사실을 알지 못할 수 있습니다. 해결책은 경로 변경 시 programmatically 문서 제목(document.title)을 업데이트하고 JavaScript를 통해 H1 헤딩이나 주 랜드마크로 포커스를 이동시키는 것입니다. 테스트하려면 스크린 리더를 활성화하고 새 페이지 제목이나 헤딩 콘텐츠를 발표하는지 확인하여 경로를 탐색합니다. 후보자들은 SPA에서 스크린 리더와 함께 브라우저의 뒤로 버튼 동작 테스트를 간과하는 경우가 많으며, 포커스 기록을 유지하여 사용자가 내비게이션 스택에서 잃어버리지 않도록 해야 합니다.