웹 애플리케이션의 접근성은 이제 기업이 더 이상 외면할 수 없는 문제가 되었다. 포용성을 실천해야 한다는 도덕적 책임과 접근성 관련 법규가 주는 법적 부담이 맞물리면서, 접근성을 고려해 구축하고 테스트하는 방법을 이해하는 것은 모든 프론트엔드 개발자에게 필수적인 지식이 되었다.

Web Content Accessibility Guidelines (WCAG)는 장애 유무와 관계없이 누구나 웹사이트를 사용할 수 있도록 보장하기 위한 기준을 제시한다. 대부분의 법규는 AA 수준 준수를 요구하는데, 이는 해당 기준을 이해하고 충족 여부를 검증하려는 의식적인 노력이 없이는 달성하기 어렵다.

접근성은 개발 과정 전반에 걸쳐 다음과 같이 통합할 수 있다:

• 접근 방식: 기획하고 개발하는 방법
• 자동화: 자동화된 테스트에 검사 통합하기
• 수동 테스트: 애플리케이션 감사하기
• 엔지니어링을 넘어서: 코드 너머의 문제 다루기

접근 방식

접근성에 대해 생각하기

첫 번째 단계는 접근성에 대해 생각하기 시작하는 것이다. WCAG 문서를 읽으며 많은 웹 페이지가 겪는 일반적인 접근성 문제들을 이해하고, 접근성 이슈를 대변하는 사람이 되어 보자. 겉핥기식으로 살펴보기만 해도 지금까지 운 좋게 한 번도 고민해 본 적 없는 문제가 얼마나 많은지 금방 알게 될 것이다.

목표는 가능한 한 가장 이른 시점부터 접근성을 고려하도록 하는 것이다. 기획 및 개선 회의에서 접근성 관련 우려를 제기하고, 처음부터 접근성이 접근 방식에 반영되도록 하자. 모두를 위한 접근성을 악화시키고 접근성 부채를 늘리는 변경에는 반대 목소리를 내야 한다. 문제를 발견하기 위해 자동화된 테스트에만 의존하는 것만으로는 충분하지 않다.

솔루션 재사용하기

공개 라이브러리나 내부 라이브러리를 활용하면 바퀴를 재발명하지 않고도 일반적인 접근성 문제를 처음부터 해결해야 하는 수고를 덜 수 있다. MUI나 Chakra 같은 컴포넌트 프레임워크를 사용하면 접근성이 이미 고려된 공통 컴포넌트를 제공받을 수 있다. design system library를 통해 자체 내부 컴포넌트를 공유하는 것도 이러한 접근성 모범 사례를 확산시키는 데 도움이 되며, 접근성 문제를 한 번 해결해 여러 팀에서 함께 활용할 수 있게 해준다.

가능한 한 네이티브 브라우저 요소를 사용하자. 이러한 요소들은 광범위한 사용 사례에서 접근성을 보장하도록 구현되어 있다. 정말로 커스텀 <select>나 <input type="date" />를 직접 만들어야 할까?

직접 커스텀 컴포넌트를 만들어야 한다면, react-aria가 대부분의 일반적인 컴포넌트에 접근성과 동작을 부여하는 React 훅 세트를 제공한다.

Storybook

Storybook은 프론트엔드 컴포넌트를 독립적으로 개발하고, 문서화하며, 테스트하기에 훌륭한 도구다. 접근성 테스트에 유용한 도구도 몇 가지 제공한다.

accessibility addon을 사용하면 각 스토리가 axe로 스캔되고 발견된 이슈가 패널에 표시된다. 이를 통해 컴포넌트를 개발하는 동안 잠재적인 접근성 문제에 대해 빠르게 피드백을 받을 수 있다.

이 애드온은 다양한 색각 이상 유형을 가진 사용자에게 UI가 어떻게 보이는지 시뮬레이션할 수 있는 여러 색상 필터도 제공한다. 이를 활용하면 색각 이상이 있는 사용자에게도 UI가 여전히 사용 가능한지 쉽게 테스트할 수 있다.

자동화

접근성 린트 규칙 사용하기

정적 분석으로 일부 접근성 문제를 잡아낼 수 있다. eslint 설정을 eslint-plugin-jsx-a11y 같은 플러그인으로 확장하면 img 태그의 alt 속성 누락이나 잘못된 aria 속성 같은 문제를 감지할 수 있다.

JSX를 작성하는 동안 IDE에서 즉각적인 피드백을 받을 수 있다.

Testing Library로 단위 테스트 작성하기

Testing library는 개발자가 리팩터링에 강하고 쉽게 깨지지 않는 테스트를 작성하도록 돕는다. XPath와 유사한 선택자로 요소를 찾는 대신 사용자가 하는 방식과 동일하게 페이지에서 요소를 찾는 쿼리는 디자인 변경이나 리팩터링으로 인해 깨질 가능성이 적다. 예를 들어, Password라는 레이블을 가진 input 요소를 조회해 비밀번호 필드를 찾는 방법은 페이지 디자인이 완전히 바뀌어도 계속 동작하지만, .password-input 클래스 이름을 가진 요소를 조회하는 방식은 그렇지 않다.

이러한 접근 방식은 더 접근성 높은 컴포넌트를 만들도록 유도한다는 장점도 있다. 레이블과 aria 속성은 시맨틱 태그를 기반으로 요소를 조회하는 견고한 테스트를 작성하기 쉽게 해 주는 동시에, 스크린 리더를 사용하는 사용자가 동일한 요소를 찾기도 쉽게 만든다. Testing Library의 기본 셀렉터로 쿼리를 작성하는 데 어려움을 겪고 있다면, 아마도 UI가 접근성 표준을 따르고 있지 않기 때문일 가능성이 높다.

Testing Library는 React, Angular, Svelte 및 plain DOM을 포함한 다양한 프레임워크와 통합을 제공한다.

단위 테스트 및 통합 테스트에서 axe 활용하기

axe는 웹 페이지의 접근성을 자동으로 테스트하는 강력한 도구다. 페이지를 스캔해 접근성 문제를 찾을 수 있으며, 이미 자동화된 테스트 파이프라인에서 사용하고 있을 법한 다양한 테스트 도구와 통합된다.

axe를 Playwright나 Puppeteer 같은 자동화된 브라우저 테스트 도구와 함께 사용할 수 있다. 애플리케이션의 각 페이지를 테스트함으로써 접근성 문제를 사용자에게 배포되기 전에 잡아낼 수 있다. 기존 프로젝트에 이를 추가하는 경우 스냅샷 테스트를 활용해 현재 접근성 문제의 기준선을 정의하고, 새로운 기능을 추가하면서 상황이 더 나빠지지 않도록 할 수도 있다.

jest-axe를 사용하면 JSDOM 환경에서 axe를 이용해 접근성 문제를 감지하는 단위 테스트를 추가할 수 있다. 이는 전체 통합 테스트 결과를 기다리지 않고 더 일찍 피드백을 받는 데 유용할 수 있다.

수동 테스트

axe 같은 자동화된 테스트 도구는 평균적으로 접근성 문제의 약 60% 정도만 잡아낼 수 있다. 예를 들어 자동화 도구는 <img /> 요소에 alt 속성이 존재하는지는 감지할 수 있지만, 해당 텍스트가 실제로 이미지를 의미 있게 설명하는지는 판단할 수 없다. 따라서 접근성 접근 방식에는 수동 테스트도 포함되어야 한다.

VPAT 같은 문서를 활용해 수동 테스트를 진행하고, 이를 외부 사용자와 공유해 애플리케이션이 접근성 표준을 준수함을 입증할 수 있다. 접근성을 수동으로 평가하고 검토하는 작업을 정기적으로 수행하면 문제를 발견하고 시간에 따른 접근성 변화를 추적하는 데 도움이 되며, 사용자가 접근성을 우선순위에 두고 있음을 안심하게 할 수 있다.

장애를 가진 실제 사용자가 웹사이트를 테스트하도록 하는 것이 시스템의 접근성이 실제로 어느 정도인지 파악하는 가장 좋은 방법이다. 스크린 리더를 사용하거나 마우스 없이 웹사이트를 사용해 보면서 실제로 얼마나 사용하기 쉬운지 가늠해 보자.

엔지니어링을 넘어서

엔지니어링 모범 사례만으로는 모든 접근성 문제를 해결할 수 없다. 조직 전체가 역할을 해야 한다.

디자이너는 초기 UX 및 UI 디자인 단계부터 접근성을 고려해야 한다. Figma 같은 도구는 accessibility integrations를 제공해 접근성을 염두에 두고 디자인 목업을 만들 수 있도록 돕는다.

웹 콘텐츠를 제작하는 모든 사람은 접근성과 그 중요성을 인지해야 한다. CMS에서 이미지에 alt 텍스트를 입력하도록 요구할 수는 있지만, 모두가 이 필드의 중요성과 스크린 리더 사용자를 위해 어떻게 유용한 설명을 작성해야 하는지 이해하고 있을까? 제작되는 모든 영상 콘텐츠에 자막이 포함되어 있을까?

Employee Resource Groups (ERGs)나 부서 간 워킹 그룹 같은 방식을 활용하면 조직 전반에 걸쳐 접근성의 중요성을 체계화하고 확산시킬 수 있다. 사무실 환경부터 내부 시스템, 외부 웹 애플리케이션에 이르기까지 모든 영역에서 접근성을 고려해야 하며, 이러한 요구사항을 우선시하는 문화를 만들려면 이를 앞장서 추진하는 사람들이 필요하다.