자동화된 접근성 테스트가 문제의 절반을 놓치는 이유

자동화된 접근성 테스트에 관한 불편한 진실

자동화된 접근성 테스트는 웹 팀이 만들 수 있는 가장 좋은 습관 중 하나입니다. 누락된 폼 레이블, 낮은 대비의 텍스트, 잘못된 ARIA, 중복 ID, 빈 버튼, 그리고 프로덕션에 절대 도달해서는 안 되는 여러 결함을 잡아냅니다.

하지만 이 테스트는 자주 오해됩니다.

자동화된 접근성 보고서를 통과했다고 해서 페이지가 접근 가능하다는 뜻은 아닙니다. 그것은 도구가 감지할 수 있도록 알고 있는 문제의 일부를 찾지 못했다는 뜻입니다. 그 일부는 가치가 있지만 제한적입니다. 많은 접근성 실패는 의미, 순서, 의도, 맥락, 인간의 상호작용에 달려 있습니다. 소프트웨어는 마크업을 검사할 수 있습니다. 하지만 스크린 리더, 키보드, 확대, 음성 제어, 캡션, 인지 지원을 사용하는 사람에게 그 경험이 제대로 작동하는지를 신뢰성 있게 이해할 수는 없습니다.

그래서 자동화 테스트가 문제의 약 절반을 놓친다는 말은 냉소적인 표현이 아닙니다. 오히려 관대한 표현입니다. 어떤 이슈 범주는 매우 높은 수준으로 자동화할 수 있습니다. 다른 범주는 거의 자동화할 수 없습니다.

실용적인 답은 자동화 도구를 버리는 것이 아닙니다. 올바른 위치에 두는 것입니다. 더 이른 시점에, 더 자주, 그리고 더 넓은 테스트 워크플로의 일부로 사용해야 합니다.

자동화 테스트가 잘하는 것

자동화 도구는 결정론적인 실패를 찾는 데 탁월합니다. 규칙을 기계가 읽을 수 있는 조건으로 표현할 수 있다면, 스캐너는 보통 이를 빠르고 일관되게 확인할 수 있습니다.

일반적인 예는 다음과 같습니다:

• alt 속성이 누락된 이미지
• 연결된 레이블이 없는 폼 입력
• 접근 가능한 이름이 없는 버튼
• 대비 기준을 통과하지 못하는 텍스트
• 잘못된 ARIA 속성 또는 역할
• 의심스러운 방식으로 건너뛰는 heading 수준
• 누락되거나 중복된 landmark
• 접근 가능한 이름이 비어 있는 링크
• 기본 구조가 없는 표

이런 검사는 자동화할 가치가 있습니다. 사람은 반복적인 검사에 적합하지 않기 때문입니다. 도구가 밀리초 단위로 잡아낼 수 있다면, 누락된 레이블을 찾기 위해 모든 페이지를 사람이 수동으로 훑어볼 필요는 없습니다.

자동화 검사는 엔지니어링 워크플로에서 접근성을 더 쉽게 논의할 수 있게도 합니다. CI에서 실패한 테스트는 구체적입니다. pull request의 경고는 시의적절합니다. 템플릿 전반의 추세선은 팀이 개선할 대상을 제공합니다.

문제는 팀이 이런 검사를 기본 위생 상태의 증거가 아니라 접근성의 증거로 취급할 때 시작됩니다.

자동화가 무너지는 지점

접근성은 코드의 속성만이 아닙니다. 사용의 속성입니다.

도구는 이미지에 alt text가 있는지 알려줄 수 있습니다. 하지만 그 alt text가 유용한지까지는 대체로 알려줄 수 없습니다. 제품 이미지는 제품 페이지에서는 자세한 설명이 필요할 수 있고, 장식용 hero에서는 설명이 필요 없을 수 있으며, 도움말 문서에서는 완전히 다른 설명이 필요할 수 있습니다. 정답은 맥락에 달려 있습니다. 그래서 팀에는 linter 규칙뿐 아니라 이미지 alt text에 대한 실용적 접근 같은 편집 지침이 필요합니다.

같은 문제가 곳곳에서 나타납니다.

스캐너는 모든 버튼에 접근 가능한 이름이 있는지 확인할 수 있습니다. 하지만 그 이름이 의미가 있는지 항상 알 수는 없습니다. Submit이라는 이름의 버튼이 다섯 개 있는 페이지는 기본 규칙을 통과할 수 있지만, 스크린 리더 사용자에게는 여전히 고통스러울 수 있습니다. 모달은 올바른 ARIA 속성을 가지고 있어도 focus를 잘못 가둘 수 있습니다. 커스텀 dropdown은 정적 마크업에서는 준수하는 것처럼 보여도 누군가 키보드로 사용하려는 순간 실패할 수 있습니다.

자동화는 다음과 같은 질문에 취약합니다:

• focus 순서가 시각적 순서 및 논리적 순서와 일치하는가?
• 모든 작업을 키보드만으로 완료할 수 있는가?
• 오류 메시지가 구체적이고 시의적절하며 필드와 연결되어 있는가?
• 텍스트 크기를 조정하거나 확대해도 페이지가 계속 작동하는가?
• 보조 기술에 대한 읽기 순서가 합리적인가?
• 지침이 색상이나 위치에 의존하지 않아도 이해 가능한가?
• 캡션, transcript, 레이블이 실제로 콘텐츠를 전달하는가?
• 컴포넌트가 상태 전반에서 예측 가능하게 동작하는가?

이것들은 edge case가 아닙니다. 접근성의 핵심입니다.

높은 점수가 주는 거짓 안도감

접근성 점수는 복잡한 주제를 숫자로 압축하기 때문에 매력적입니다. 대시보드는 98이라고 말합니다. 보고서는 초록색 체크를 보여줍니다. 릴리스가 더 안전하게 느껴집니다.

하지만 그 점수는 도구가 측정하는 것만 측정합니다.

이는 성능 테스트와 비슷합니다. Lighthouse 보고서는 중요한 문제를 드러낼 수 있지만, 중급 사양의 휴대폰에서 실제 사용자가 느린 checkout을 힘겹게 통과하는 모습을 보는 것과 같지는 않습니다. 팀이 이미 성능 감사를 사용하고 있다면 같은 사고방식이 적용됩니다. 보고서를 주의 깊게 읽고, 실제 사용자에게 영향을 주는 발견 사항을 우선순위로 두어야 합니다. 우리는 이 구분에 대해 당황하지 않고 Lighthouse 보고서를 읽는 방법에서 다룬 바 있습니다.

접근성 보고서에도 같은 절제가 필요합니다. 깨끗한 자동화 스캔은 출발점입니다. 인증서가 아닙니다.

팀이 정적 페이지에 대해서만 스캔을 실행할 때 위험은 특히 커집니다. 현대 인터페이스는 상태를 가집니다. 메뉴가 열리고, drawer가 슬라이드되고, toast가 나타나며, validation 메시지가 업데이트되고, tab이 패널을 전환하며, filter가 콘텐츠를 다시 쓰고, 인증은 모든 것을 바꿉니다. 심각한 접근성 결함의 상당수는 이런 상호작용 안에 있습니다.

스캐너가 초기 DOM만 본다면, 제품을 놓치고 있는 것입니다.

가장 자주 놓치는 범주

1. 키보드와 focus 동작

키보드 접근은 자동화가 불충분한 이유를 가장 분명하게 보여주는 사례 중 하나입니다.

도구는 어떤 요소가 focus 가능한지 감지할 수 있습니다. 양수 tabindex 값이나 명백한 focus trap을 잡아낼 수도 있습니다. 하지만 tab 순서가 일관되게 느껴지는지, 동작 후 focus가 올바른 위치로 이동하는지, 닫힌 컴포넌트가 focus를 트리거로 되돌리는지를 신뢰성 있게 판단할 수는 없습니다.

사람이 실제 워크플로를 따라 Tab, Shift+Tab, Enter, Space, Escape, 화살표 키를 눌러봐야 합니다.

이는 커스텀 컨트롤에서 특히 중요합니다. Native HTML 요소는 수년간 다듬어진 접근성 동작을 기본으로 제공합니다. 버튼, select, checkbox, 메뉴, dialog를 div로 다시 만들면, 이제 그 동작의 책임은 팀에 있습니다. 인터랙티브 컴포넌트를 검토하고 있다면 접근 가능한 웹 버튼을 위한 짧은 체크리스트에서 시작하고, 같은 규율을 모든 커스텀 컨트롤로 확장하세요.

2. 의미 있는 이름과 설명

자동화 도구는 부재를 감지할 수 있습니다. 품질을 감지하는 데는 훨씬 약합니다.

Read more라는 이름의 링크는 기술적으로 접근 가능한 이름을 가질 수 있습니다. OK라는 레이블의 버튼도 유효할 수 있습니다. 폼 힌트가 존재할 수도 있습니다. 하지만 맥락 안에서 의미가 있을까요? 대개 그렇지 않습니다.

접근 가능한 이름은 사용자에게 어떤 일이 일어날지, 또는 요소가 무엇을 나타내는지 알려줘야 합니다. 여기에는 판단이 필요합니다. 또한 코드만이 아니라 인터페이스로 테스트해야 합니다.

3. 오류 처리

폼에는 스캐너가 부분적으로만 잡아내는 접근성 실패가 가득합니다.

도구는 레이블이 없는 필드를 표시할 수 있습니다. 하지만 validation 메시지가 너무 늦게 나타나는지, 너무 빨리 사라지는지, 스크린 리더에 발표되지 않는지, 또는 Password must be at least 12 characters라고 말해야 할 때 Invalid input이라고 말하는지는 잡아내지 못할 수 있습니다.

좋은 오류 처리는 인터랙션 디자인입니다. 수동 테스트가 필요하며, 이상적으로는 사용자 테스트도 필요합니다.

4. 시각적 적응

WCAG에는 텍스트 크기 조정, reflow, 대비, 간격, 단일 감각 단서에 의존하지 않는 것과 관련된 요구사항이 포함됩니다. 이 중 일부는 자동으로 확인할 수 있지만, 실제 질문은 조건이 바뀌었을 때 인터페이스가 계속 사용할 수 있는지입니다.

200% zoom을 시도해 보세요. 브라우저 텍스트 크기 조정을 시도해 보세요. high contrast 또는 forced colors mode를 시도해 보세요. 좁은 viewport 폭을 시도해 보세요. reduced motion을 시도해 보세요. 기본 설정에서는 세련되어 보이는 많은 사이트가 사용자가 자신의 선호를 적용하는 순간 빠르게 무너집니다.

5. 콘텐츠 명확성

어떤 자동화된 접근성 도구도 콘텐츠가 이해 가능한지 완전히 평가할 수는 없습니다.

누락된 heading이나 모호한 링크 텍스트는 표시할 수 있습니다. 하지만 페이지가 절차를 명확히 설명하는지, 레이블이 사용자 기대와 일치하는지, 조밀한 문구가 피할 수 있는 인지 부담을 만드는지는 알 수 없습니다.

접근성은 보조 기술 호환성만의 문제가 아닙니다. 스트레스를 받는 사람, 익숙하지 않은 언어를 사용하는 사람, 주의 제약을 겪는 사람, 복잡한 작업을 탐색하는 사람의 마찰을 줄이는 일이기도 합니다.

더 나은 테스트 워크플로

균형 잡힌 접근성 워크플로에는 여러 층이 있습니다.

자동화 검사를 지속적으로 실행하기

개발, pull request, 컴포넌트 preview, CI에서 자동화 테스트를 사용하세요. 이 테스트는 지루하고 빠르며 타협할 수 없어야 합니다. 새로 생긴 누락 레이블과 잘못된 ARIA를 발견하기 위해 분기별 감사가 필요해서는 안 됩니다.

이런 실패를 linting 실패처럼 다루세요. 목표는 영웅적인 대응이 아니라 regression을 막는 것입니다.

수동 키보드 테스트 추가하기

의미 있는 모든 사용자 흐름에 대해 마우스 없이 테스트하세요. 여기에는 탐색, 검색, 계정 생성, checkout, filtering, modal, menu, form submission이 포함됩니다.

최소한 다음을 확인하세요:

• 모든 인터랙티브 요소에 도달할 수 있음
• focus가 항상 보임
• focus 순서가 논리적임
• 예상되는 키가 작동함
• Escape가 닫을 수 있는 overlay를 닫음
• 컴포넌트를 열고 닫은 뒤 focus가 관리됨
• keyboard trap이 없음

이 하나의 습관만으로도 자동화 스캔이 놓치는 큰 범주의 문제를 잡아낼 수 있습니다.

최소 하나의 스크린 리더로 테스트하기

유용한 것을 배우기 위해 스크린 리더 전문가가 될 필요는 없습니다. 다만 겸손함은 필요합니다. 스크린 리더 테스트에는 학습 곡선이 있고, 초보자는 문제를 잘못 진단할 수 있습니다.

그래도 VoiceOver, NVDA, JAWS로 기본 테스트를 해보면 스캐너가 잡지 못할 수 있는 깨진 이름, 혼란스러운 읽기 순서, 발표되지 않는 업데이트, landmark 문제를 발견할 수 있습니다.

이를 semantic HTML과 함께 사용하세요. native 요소를 더 많이 사용할수록 접근성은 덜 취약해집니다.

콘텐츠와 상태 검토하기

empty state, loading state, error state, disabled state, success message, permission failure를 확인하세요. 접근성 버그는 종종 happy path 밖에 숨어 있습니다.

실제 문구도 검토하세요. 레이블, heading, 지침, 오류 메시지는 인터페이스의 일부입니다.

위험이 큰 경우 장애가 있는 사용자를 포함하기

중요한 흐름에서는 수동 전문가 검토만으로 충분하지 않습니다. 장애가 있는 참여자와의 사용자 테스트는 팀이 예상하지 못한 문제를 찾아냅니다. 이는 공공 서비스, 의료, 금융, 교육, 그리고 배제가 심각한 결과를 낳는 모든 흐름에서 특히 중요합니다.

자동화 테스트는 확장됩니다. 인간 테스트는 이해합니다.

자동화 결과를 책임 있게 해석하는 방법

통과했는가?라고 묻지 마세요.

더 나은 질문을 하세요:

• 이 도구는 어떤 이슈 범주를 감지할 수 있는가?
• 어떤 템플릿과 상태를 스캔했는가?
• 상호작용 이후에 실행되었는가, 아니면 초기 로드에서만 실행되었는가?
• 위반 사항은 근본 원인별로 묶였는가, 아니면 반복적으로 집계되었는가?
• 어떤 실패가 사용자의 작업 완료를 막는가?
• 무엇이 여전히 수동 검토를 필요로 하는가?

이 프레이밍은 대화를 바꿉니다. 자동화 도구는 권위가 아니라 증거가 됩니다.

또한 팀이 바쁜 일만 하는 것을 피하게 해줍니다. 하나의 컴포넌트를 고치면 반복된 위반 수백 개가 사라질 수 있습니다. 반대로 보고된 이슈가 하나뿐인 페이지에도 심각한 keyboard trap이 있을 수 있습니다. 개수는 영향이 아닙니다.

실용적 기준: 명백한 것은 자동화하고, 경험은 수동으로 테스트하기

최고의 접근성 팀은 도구에 반대하지 않습니다. 환상에 반대합니다.

그들은 기계가 신뢰성 있게 감지할 수 있는 것을 자동화합니다. 동작과 의미에 달린 것은 수동으로 테스트합니다. WCAG 같은 표준을 공통 기준선으로 사용하되, 제품을 직접 사용하는 것의 대체물로 삼지는 않습니다.

현재 프로세스가 출시 전 자동화 스캔뿐이라면, 다음 순서로 개선하세요:

1. 개발 초기에 자동화 검사를 추가합니다.
2. 핵심 흐름을 키보드로 수동 테스트합니다.
3. 이름, 레이블, 오류, 지침을 검토합니다.
4. 일반적인 컴포넌트를 스크린 리더로 테스트합니다.
5. 고위험 여정에는 전문가 및 사용자 테스트를 도입합니다.

이것은 완벽한 프로세스가 아닙니다. 현실적인 프로세스입니다. 그리고 초록색 접근성 점수가 찾아낼 수 있는 것보다 훨씬 더 많은 것을 찾아낼 것입니다.