접근성 테스트의 기초 익히기

학습 목표

이 유닛을 완료하면 다음을 수행할 수 있습니다.

접근성 테스트의 중요성을 이해합니다.
접근성 테스트 자동화의 장단점을 요약할 수 있습니다.
접근성 테스트 자동화에 사용할 수 있는 도구를 찾을 수 있습니다.
나만의 자동화된 접근성 테스트를 작성하기 위한 전략을 설명할 수 있습니다.

접근성 테스트가 필요한 이유

접근성 테스트는 웹 사이트나 앱과 같은 디지털 제품을 장애인을 포함한 모두가 사용할 수 있게 만들기 위한 것입니다. 이를 위해서는 사용자의 접근성을 제한하는 장벽을 사전에 제거해야 합니다. 이상적으로는 접근성 버그가 처음부터 발생하지 않는 것이 좋지만 현실적으로 개발 중에는 버그가 발생할 수밖에 없습니다. 언제나 개발을 할 때는 사용자가 이러한 버그를 경험하지 않도록 하겠다는 목표를 지녀야 합니다.

접근성 테스트는 디자인 단계에서 시작해 개발 단계는 물론 배포 이후까지 포함하는 개발 라이프사이클 전반에서 수행하는 것이 바람직합니다. 이러한 사전 조치를 통해 모든 단계에서 접근성을 고려하고 반영할 수 있습니다.

접근성 테스트를 통해 다음을 달성할 수 있습니다.

모두가 동등하게 누릴 수 있는 포용적 디지털 경험을 창출합니다.
규제 및 법률의 요구 사항을 충족합니다.
더 많은 사용자에게 도달합니다.
전반적 사용자 경험을 향상합니다.

이번 모듈에서는 포괄적인 접근성 테스트를 수행하기 위해 모두 필요한 자동 테스트와 수동 테스트를 살펴보겠습니다. 먼저 자동 접근성 테스트부터 살펴봅시다.

접근성 테스트 자동화의 장단점

앞에서 말씀드렸듯이 자동화된 접근성 테스트를 활용하면 디지털 제품의 접근성 기준 충족 여부를 빠르게 평가할 수 있습니다. 예를 들어, 자동화된 테스트 소프트웨어는 웹 사이트를 스캔하여 대체 텍스트 누락, 불충분한 색상 대비, 제목 누락과 같은 다양한 접근성 장벽을 찾아낼 수 있습니다. 테스트 절차를 자동화하면 효율성과 일관성이 높아지며 확장성도 향상됩니다.

자동화된 접근성 테스트를 수행하는 개발자.

자동화된 테스트는 장점도 많지만 사람의 이해와 맥락이 필요한 미묘한 접근성 장벽은 물론 중대한 접근성 문제까지 놓칠 수 있다는 점을 유념해야 합니다. 예를 들어 자동화된 테스트는 제목으로 사용된 텍스트 이미지를 문제로 인식하지 못할 수 있습니다. 또한 접근성 장벽이 사용자에 미치는 현실적 영향을 평가할 수 없습니다. 접근성을 가장 포괄적으로 평가하기 위해서는 반드시 수동 접근성 테스트를 자동 테스트와 함께 실시해야 합니다.

자체 접근성 테스트를 자동화할 때는 사전 제작된 테스트 유틸리티와 고객 테스트 사례를 통합하여 사용자 인터페이스에서 악화된 접근성을 찾습니다. IOS 및 Android용 모바일 테스트 프레임워크에는 기본 접근성 검사가 포함됩니다. 기본 코드를 사용하여 기능을 개발하는 경우 테스트를 추가하여 테스트 프레임워크에서 지원하는 기본 검사를 수행합니다. 모바일 테스트에 관한 상세 내용은 이번 유닛 마지막에 있는 리소스를 통해 확인하세요.

접근성 테스트 도구 사용

접근성 테스트를 할 때는 여러 가지 자동화 및 반자동화 도구를 사용할 수 있습니다. 대부분의 도구는 테스트 대상 컨텐츠를 웹 컨텐츠 접근성 지침(WCAG)에 견주어 접근성 장벽을 식별해냅니다. 몇 가지 유용한 도구는 다음과 같습니다.

도구	개념	기능
Axe	웹 사이트 및 기타 HTML 기반 사용자 인터페이스에 대한 오픈 소스 테스트 도구로서 포괄적인 접근성 테스트 제공	코딩 시 접근성 오류를 포착해 기존 테스트 환경에 통합하여 접근성 테스트를 자동화할 수 있게 해줌
WAVE	장애인 사용자에게 영향을 미치는 일반적 접근성 장벽(낮은 대비 및 대체 텍스트 누락 등)을 식별하는 데 도움이 되는 무료 평가 도구 모음	아이콘과 기호를 사용하여 다양한 접근성 문제를 표시하여 사람이 웹 컨텐츠를 쉽게 평가할 수 있게 지원
Google Lighthouse	WCAG 위반을 비롯한 접근성 문제를 검토하는 오픈 소스 자동화 도구	접근성을 검토하여 페이지의 접근성 수준에 따라 100점을 만점으로 점수 부여
Linters	개발 라이프사이클의 시작부터 통합하여 접근성 문제와 위반 사항을 방지할 수 있는 자동화된 도구(GitHub: infofarmer / eslint-plugin-jsx-a11y 및 GitHub: reactjs / react-a11y와 유사)	HTML, CSS, JavaScript와 같은 소스 코드를 분석해 키보드 탐색 문제, 부적절한 제목 및 랜드마크 사용과 같은 접근성 장벽을 식별
sa11y	Salesforce가 만든 오픈 소스 JavaScript 라이브러리로서 자동화된 접근성 테스트 작성에 도움을 줌	기계가 인지할 수 있는 정적 DOM 접근성 문제를 탐지할 수 있게 지원

이러한 도구를 사용하더라도 모든 문제를 파악할 수 있는 것은 아닙니다. 설령 코드가 모든 테스트를 통과하더라도 접근성이 완벽하다고 말할 수는 없습니다. 그러나 이러한 테스트는 주요 접근성 문제를 충분히 찾아낼 수 있으며 그로 인해 코드의 접근성이 떨어지는 것을 막을 수 있습니다. 자동화된 테스트 뿐만 아니라 수동 테스트까지 함께 실시하여 접근성을 포괄적으로 평가하는 것이 바람직합니다. 수동 테스트는 나중에 자세히 알아보겠습니다.

나만의 접근성 테스트 작성하기

구성 요소에 액세스하기 위해 많은 노력을 기울인 경우 구성 요소가 그러한 상태를 유지할 수 있도록 테스트를 작성하는 것이 좋습니다. 예상 키보드 기능 및 HTML 요소에 대한 올바른 ARIA 값 등의 다양한 접근성 문제에 대해 자동 테스트를 작성할 수 있습니다.

예시: Lightning 버튼 테스트

다음은 Lightning Web Components(LWC) Jest 테스트를 위한 모의 코드입니다. 이 테스트는 Lightning 버튼을 생성하고 해당 구성 요소 구조의 접근성을 검증합니다.

registerSa11yMatcher();
const element = createButton({
    label: 'Submit',
    variant: 'brand-outline',
    title: 'This is a submit button',
});
const button = shadowQuerySelector(element, 'button');


return Promise.resolve().then(async () => {
    await expect(button).toBeAccessible();
});

이 코드 예시에서는 먼저 sa11y를 등록하여 구성 요소의 접근성을 검사합니다. 그런 다음 레이블, 특정 변형, 제목을 사용하여 버튼을 만듭니다. 그런 다음 이 버튼을 찾아 변수에 할당합니다. 마지막으로 접근성 검사를 도입하기 위해 비동기 함수 호출을 사용하여 버튼의 접근성을 검사합니다.

Jest에서 무언가의 접근성을 검사할 때는 검사된 요소의 HTML 구조를 가져와서 WCAG 표준에 따라 검증합니다. 그 과정에서 렌더링되는 요소에 대한 ARIA 속성이 모두 올바른지 또한 확인해야 합니다.

지금까지 접근성 테스트의 기초 사항을 몇 가지 알아봤습니다. 이제 원칙을 활용할 준비가 되셨나요? 다음 자료에서 키보드 및 화면 리더기 테스트를 수행하는 법을 확인하세요.

예상 시간

주제

도움말 검색

Salesforce Platform 자원