원문: Artem Sapegin, "The most useful accessibility testing tools and techniques"
접근성 기능 배포는 버그 없는 기능 배포만큼 프론트엔드 개발자에게 필수입니다. 이 글에서는 눈이 멀든 한 손에 샌드위치를 들고 있든, 다양한 신체 능력을 가진 사람들에게 접근성이 충분한지 확인하기 위해 자주 사용하는 도구들을 소개합니다. 코드를 작성할 때 즉시 피드백을 제공하는 도구부터 시작하여 직접 실행하거나 수동으로 테스트하는 방법을 안내하는 다양한 도구를 소개하려고 합니다. 이 글은 개발자뿐만 아니라 디자이너, 프로젝트 관리자 및 다른 팀원들에게도 유용합니다. 대부분 브라우저에서 직접 사용할 수 있으며 기술적인 지식이 필요하지 않습니다.
접근성 테스트 시작하기
접근성 테스트를 한 번도 해본 적이 없거나 접근성을 고려하지 않고 설계된 프로젝트를 진행하고 있다면, 다음 단계를 따라 프로젝트의 접근성을 평가하고 개선하기 시작하는 것을 권장합니다.
(리액트 프로젝트에 한하여) 리액트 ESLint 플러그인을 설치하고 보고된 모든 문제를 수정합니다.
Accessibility Insights 브라우저 확장 프로그램에서 FastPass를 실행하여 가장 흔한 두 가지 접근성 문제를 발견하고 수정합니다.
사이트 또는 앱에서 키보드 탭(Tab)을 눌러 키보드 탐색 및 포커스 상태를 테스트합니다.
이렇게 한다고 사이트 또는 앱이 완벽한 접근성을 갖출 수는 없지만 접근성을 향한 좋은 첫 걸음이 됩니다. 각 도구 및 기술에 대해서 더 자세히 이야기해 보겠습니다.
리액트 ESLint 플러그인
저는 무언가 잘못하고 있을 때 누군가 제게 묻지 않고 바로 알려주는 것이 좋습니다. 린터는 코드를 작성할 때 편집기 내에서 즉시 피드백을 제공하는 완벽한 도구입니다.
리액트 프로젝트에서는 eslint-plugin-jsx-a11y가 많은 접근성 문제를 확인해줍니다. 예를 들어 이미지에 대한 대체 텍스트 누락이나 잘못된 ARIA 속성 및 role 속성 등을 확인합니다.
안타깝게도 이 플러그인은 상당히 제한적입니다.
코드의 정적 분석은 몇 가지 문제만 찾을 수 있습니다.
일반 HTML 요소에만 적용되며 커스텀 컴포넌트는 확인할 수 없습니다.
하지만 보통 프로젝트에 ESLint를 이미 사용하고 있으므로 이 플러그인을 사용하는 비용은 아주 적습니다. 가끔 브라우저에서 사이트나 앱을 확인해 보기도 전에 문제를 찾아주기도 합니다.
Axe-core
Axe-core는 브라우저에서 렌더링된 HTML의 접근성을 확인하는 라이브러리입니다. 텍스트가 충분한 색상 대비를 가지고 있는지 확인하는 등 더 많은 문제를 찾을 수 있기 때문에 ESLint 같은 정적 코드 분석보다 훨씬 더 강력합니다.
여러 도구가 axe-core를 기반으로 만들어졌습니다.
리액트 Styleguidist에서는 react-axe를 직접 추가할 수 있습니다.
둘 다 완전한 페이지를 렌더링 할 때 필요한 문서 개요나 랜드마크 영역 같은 것은 확인하지 않습니다. 하지만 새로운 컴포넌트를 독립적으로 개발할 때 빠른 피드백을 받을 수 있습니다. 실제 사이트나 앱에서는 확인하기 어려운 각 컴포넌트 변형의 접근성을 확인할 수도 있습니다.
Cypress-axe
매 변경마다 사이트 또는 앱의 접근성을 테스트하지 않는다면 결국 다시 접근성 문제로 회귀합니다. 그렇기 때문에 접근성 테스트를 지속적인 통합(CI) 프로세스의 일부로 만드는 것이 필수입니다. 접근성을 테스트하지 않고 코드를 코드베이스에 병합해서는 안 됩니다.
Cypress-axe는 axe-core를 기반으로 만들어졌습니다. Cypress E2E 테스트 내에서 접근성 검사를 실행할 수 있어 좋습니다. 왜냐하면 우리는 지속적인 통합 중에 E2E 테스트를 이미 실행하고 있고, 모든 페이지를 렌더링하기 때문입니다. 여러 번 테스트를 실행하여 다른 상태의 페이지를 테스트할 수도 있습니다. 예를 들어 열린 모달 또는 확장된 콘텐츠 섹션과 함께 테스트할 수 있습니다.
이러한 테스트는 사이트 또는 앱을 깨뜨리지 않는 접근성 스모크 테스트가 될 수 있습니다. 하지만 cypress-axe는 이미 접근성 문제가 있는 페이지를 분석하기엔 불편합니다. 이럴 때는 Axe 또는 Accessibility Insights와 같은 브라우저 확장 프로그램이 더 편리합니다.
cypress-axe 설정 및 사용 방법에 대해 더 자세히 알아보세요.
Tip
개별 컴포넌트의 자동화된 접근성 테스트를 위해 jest-axe도 좋은 선택입니다.
Axe 브라우저 확장 프로그램
Chrome 및 Firefox용 Axe 브라우저 확장 프로그램은 axe-core 기반으로 만들어졌습니다. 하지만 실제 사이트 또는 앱에서 이 확장 프로그램을 실행하면 하나의 컴포넌트에서는 찾을 수 없던 문제들을 찾을 수 있습니다. 예를 들어 올바른 머리글 구조 또는 랜드마크 영역 같은 문제말이죠.
이 확장 프로그램은 접근성 감사를 수행하는 데 매우 유용하지만 사이트 또는 앱에 추가 사항이나 변경 사항이 있을 때마다 실행해야 합니다. 때때로 부정 오류가 발생하기도 합니다. 예를 들어 Axe가 배경색을 판단하지 못해 텍스트의 색상 대비가 충분하지 않다고 보고하는 경우가 있습니다.
Accessibility Insights 브라우저 확장 프로그램
Microsoft의 Accessibility Insights 브라우저 확장 프로그램도 axe-core 기반으로 만들어졌지만 몇 가지 특별한 기능이 있습니다.
Accessibility Insights는 Axe 확장 프로그램과 유사한 자동화된 검사가 있지만 페이지에 직접 모든 문제를 강조해주는 기능도 있습니다.
Accessibility Insights는 자동화할 수 없는 여러 수동 검사를 설명해주기도 합니다.
Accessibility Insights의 FastPass 기능은 가장 흔한 두 가지 접근성 문제를 찾아주며 이는 사이트 또는 앱의 접근성을 개선하는 좋은 첫 걸음입니다.
마지막으로 페이지에서 머리글, 랜드마크 영역 및 탭 구간(아래 "탭 키"를 참조하세요)을 강조할 수 있습니다.
대비 앱 및 Chrome 개발자 도구 대비 검사기
때로는 목업이나 다른 곳에서 색상 대비를 확인해야 합니다. 브라우저 확장 프로그램을 실행하기가 불편하거나 불가능한 경우가 생기죠.
브라우저에서 색상 대비를 확인하기 위해 Chrome 개발자 도구 대비 검사기는 좋은 선택입니다 (요소 검사 후 스타일 탭에서 색상 색조를 클릭하세요).
그 외의 모든 경우에는 색상 대비 앱에서 스포이드를 사용하여 두 가지 색상을 선택하여 확인합니다.
Bonus
검사 결과 링크를 공유하려는 경우 Lea Verou의 색상 대비 웹 앱도 또 다른 선택이 될 수 있습니다.
Spectrum 크롬 확장 프로그램
Spectrum 브라우저 확장 프로그램을 사용하면 다양한 유형의 색맹이 사이트 또는 앱을 어떻게 보는지 확인하고 서로 다른 요소 간에 충분한 대비가 있는지 확인할 수 있습니다.
2024년 5월 업데이트
Spectrum 확장 프로그램을 더 이상 사용할 수 없습니다. Colorblindly는 좋은 대체입니다.Bonus
크롬 개발자 도구는 이러한 시력 장애 중 일부를 시뮬레이션할 수 있습니다. Escape 키를 누르고 점 세 개 메뉴 버튼에서 렌더링 탭을 활성화한 다음 시력 장애 시뮬레이션 섹션으로 스크롤합니다.
탭 키
앱 전반적으로 탭을 하면, 즉 키보드의 탭 키를 눌러 페이지의 상호작용 요소 간을 탐색하면 다음을 확인할 수 있습니다.
모든 상호작용 요소는 포커스 가능하며 포커스 상태를 표시해야 합니다.
탭 순서는 논리적이어야 합니다. 일반적으로 페이지의 시각적 순서를 따릅니다.
포커스는 모달 내부에 갇혀 있어야 합니다. 즉, 모달을 닫기 전까지 모달 뒤의 페이지로 탭 이동할 수 없으며, 모달을 닫으면 모달을 연 요소로 포커스가 돌아와야 합니다.
처음으로 탭 키를 눌렀을 때 건너뛰기 탐색 링크가 나타나야 합니다.
탭 키와 함께 다른 키가 예상대로 동작하는지 확인하는 것이 중요합니다. 예를 들어 화살표 키를 사용하여 목록을 탐색할 수 있어야 하고, 일부 유효성 검사 코드가 텍스트 필드에서 화살표 및 백스페이스를 차단하지 않아야 합니다.
마우스, 트랙패드 또는 터치스크린을 건드리지 않고 사이트 또는 앱에서 모든 중요한 행동을 완료할 수 있어야 합니다. 언제든지 어떤 요소에 초점이 맞춰져 있는지 알아야 합니다.
Tip
저는 크롬 개발자 도구에서 실시간 표현식 document.activeElement를 사용하여 어떤 요소에 초점이 맞춰져 있는지 확인합니다 (콘솔 탭 툴바의 "실시간 표현식 만들기" 버튼). 포커스 상태가 보이지 않는 요소의 경우, 보이지 않는 요소가 포커스되는 경우를 찾는 데 도움이 됩니다.
Bonus
Marcy Sutton의 No Mouse Days npm 패키지는 사이트나 앱에서 키보드 지원을 개선하기 위해 마우스 커서를 비활성화합니다.
줌
사이트나 앱을 확대하면 확대·축소가 어떻게 처리되는지 확인할 수 있습니다. 브라우저에서 200%까지 확대하여 어떤 부분이 깨지는지 확인해 보세요. 저를 포함하여 많은 사람들이 텍스트가 너무 작을 때 확대를 합니다. 그러므로 확대할 때 레이아웃이 깨지지 않고, 텍스트가 잘리지 않으며, 요소가 서로 겹치지 않도록 해야 합니다.
Tip
미디어 쿼리 중단점을 포함하여 CSS의 모든 크기에 rem을 사용하면 일반적으로 확대·축소 문제를 피할 수 있습니다.
스크린 리더
스크린 리더를 사용하여 사이트 또는 앱을 테스트하면 다음을 확인할 수 있습니다.
모든 상호작용 요소는 포커스 가능하며 접근성 있는 레이블을 가져야 합니다.
탭 순서, 시맨틱 마크업, 텍스트 콘텐츠가 논리적이어야 합니다.
건너뛰기 탐색 링크는 주요 페이지 콘텐츠로 직접 이동하므로 모든 탐색 링크를 계속 들어야 하는 문제를 피할 수 있습니다.
스크린 리더로 테스트하는 것은 키보드로 테스트하는 것과 여러 면에서 유사합니다. 화면을 볼 수 없으므로 (테스트 할 때 화면을 끄거나 눈을 감는 것을 추천합니다) 마우스나 트랙패드를 사용하여 화면에 나타난 항목을 선택하지 못하고, 키보드로 탭 키로 선택해야 합니다. 가장 큰 차이점은 버튼과 같은 요소를 형태로 인식할 수 없거나 인풋과 레이블을 위치로 연결짓지 못한다는 점입니다. 이러한 관계를 시맨틱 마크업 또는 ARIA 속성을 사용하여 정의해야 합니다.
맥 OS에는 이미 VoiceOver가 있습니다. 윈도우에서는 기본 제공 나레이터, 무료인 NVDA 또는 유료인 JAWS가 있습니다. 크롬 확장 프로그램으로 설치할 수 있는 ChromeVox도 있습니다.
Tip
VoiceOver를 시작하려면 이 글을 읽어보고 다시 돌아오세요.Bonus
크롬 개발자 도구의 접근성 탭을 사용하여 보조 기술 도구가 특정 요소를 어떻게 보는지 확인하세요.
항상 더 해볼 수 있는 것이 남아있죠
몇 가지 더 테스트할 가치가 있는 것들이 있습니다.
브라우저 읽기 모드는 접근성 도구 그 자체입니다. 독자들이 주요 콘텐츠에 집중하도록 도와주거나 색상을 읽기 쉽게 만들어 줍니다. 페이지의 시맨틱 마크업을 빠르게 테스트하는 방법으로 사용할 수도 있습니다. 메인 페이지 제목, 전체 주요 콘텐츠, 모든 콘텐츠 이미지가 보여야 하지만 장식 이미지나 배너 같은 추가 요소는 표시되지 않아야 합니다.
모션 감소는 운영 체제 옵션으로, 사이트 및 앱에 사용자가 화면에서 불필요한 모션을 최소화하길 원한다는 것을 (prefers-reduced-motion 미디어 쿼리를 통해) 알려줍니다. 스크롤 시 표시 또는 캐러셀 같은 애니메이션을 비활성화할 수 있습니다.
다크 모드는 사이트나 앱의 옵션 또는 운영 체제의 옵션일 수 있으며, prefers-color-scheme 미디어 쿼리를 통해 알 수 있습니다. 사이트 또는 앱이 다크 모드에서 여전히 접근 가능한지 특히 색상을 확인해야 합니다.
키보드 및 터치스크린에 대한 호버 대안. 호버는 콘텐츠 또는 상호작용 요소를 표시하는 유일한 방법이 아니어야 합니다. 일반적인 예시로 긴 목록의 항목에 호버할 때 나타나는 메뉴입니다. 툴팁은 또 다른 예입니다. 키보드 사용자에게 컨테이너가 포커스될 때 이러한 요소를 표시하고 터치스크린에서 항상 보여야 합니다.
Tip
CSS any-hover 상호작용 미디어 기능 쿼리를 사용하여 디바이스에서 호버 지원을 테스트할 수 있지만 잘못된 가정을 하지 않도록 주의하세요.Tip
Cypress와 cypress-axe를 사용하여 다크모드에서의 접근성을 테스트할 수 있습니다.
참고 글
Web accessibility course by Google
Writing HTML with accessibility in mind by Manuel Matuzovic
Writing JavaScript with accessibility in mind by Manuel Matuzovic
Writing CSS with accessibility in mind by Manuel Matuzovic
Beyond automatic accessibility testing: 6 things I check on every website I build by Manuel Matuzovic
Assistive technologies I test with by Dave Rupert
Testing web accessibility by Adrián Bolonio
16 things to improve your website accessibility (checklist) by Bruce Lawson
Getting Started with VoiceOver & Accessibility by Sue Lockwood
결론
코드 테스트뿐만 아니라 작은 글꼴이 있는 사이트를 확대하거나 어두운 배경의 사이트에서 읽기 모드를 사용하는 등 실제 사이트에서 사용할 수 있는 다양한 도구와 기법을 다뤘습니다.
도구는 일부 문제만 감지할 수 있다는 것을 명심하며 자동화된 접근성 테스트와 수동 접근성 테스트 사이의 균형을 찾아야 합니다.
수동 접근성 테스트가 올바르게 수행되면 대부분의 문제를 찾을 수 있지만 시간이 많이 걸립니다. 또한 사이트 또는 앱에 새로운 기능이 생길 때마다 다시 수행해야 합니다.
자동화된 접근성 테스트는 실행 비용이 저렴하고 사이트나 앱이 하는 것을 방지합니다. 하지만 자동화된 테스트는 특정 유형의 문제만 발견할 수 있습니다.
여러분이 선호하는 접근성 테스트 도구와 기술을 저에게 공유해주세요!
Eldar Amantay, Wendy Fox, Anna Gerus, Anita Kiss, Manuel Matuzovic, Patrick Smith에게 감사함을 전합니다.