웹 애플리케이션 접근성 준수 - by. UXKM

  • A11Y
  • A11y Creation Tech
  • 웹 접근성 제작 기법
  • 웹 애플리케이션 접근성 준수
요약 설명

관련 지침 : 콘텐츠에 포함된 웹 애플리케이션은 접근성이 있어야 한다.
웹 애플리케이션이 포함된 콘텐츠는 모든 사용자가 기능을 동등하게 사용할 수 있도록 접근성이 보장되어야 하며, 이는 보조 기술 사용자에게도 동일한 기능을 제공할 수 있도록 구성해야 합니다.

관련 WCAG 2.2 성공 기준

웹 애플리케이션은 다음에 설명한 모든 요구사항을 적용하여 제작해야 합니다.

  • 접근성 프로그래밍 인터페이스 사용 지원

    웹 애플리케이션은 운영체제 또는 플랫폼이 제공하는 접근성 프로그래밍 인터페이스를 사용하여 제작해야 합니다. 그렇지 않으면 보조 기술이 웹 애플리케이션의 접근성 기능을 지원하지 못하는 경우가 발생할 수 있습니다.

  • 접근성 프로그래밍 인터페이스 대체수단 제공

    웹 애플리케이션을 구현하는 과정에서 운영체제(플랫폼 포함)가 제공하는 접근성 프로그래밍 인터페이스가 정의되지 않은 새로운 기능을 구현할 경우, 그 기능의 명칭, 역할, 상태 및 값에 관한 정보를 운영체제(또는 플랫폼)의 접근성 프로그래밍 인터페이스로 전달하도록 구현함으로써 보조 기술이 그 정보를 이용할 수 있게 해야 합니다.

  • 보조 기술 지원

    국내의 보조 기술로 접근이 불가능한 웹 애플리케이션은 가능한 한 사용하지 않는 것이 좋으며, 반드시 사용해야 하는 경우, 해당 웹 애플리케이션에 대한 대체 수단을 제공해야 합니다.

WCAG 2.2 - 2.1.1 키보드 (레벨 A) WCAG 2.2 - 2.4.3 포커스 순서 (레벨 A) WCAG 2.2 - 2.5.1 포인터 제스처 (레벨 A) WCAG 2.2 - 2.5.2 포인터 취소 (레벨 A) WCAG 2.2 - 2.5.3 레이블과 이름 (레벨 A) WCAG 2.2 - 2.5.4 동작 기반 작동 (레벨 A) WCAG 2.2 - 4.1.2 이름, 역할, 값 (레벨 A) MDN 웹 접근성 개요

기대효과

  • 웹 애플리케이션이 접근성을 제공할 경우, 보조 기술이 웹 애플리케이션과 상호작용할 수 있으므로, 보조 기술 사용자가 웹 애플리케이션을 활용할 수 있습니다.
  • 웹 애플리케이션에 적용하려는 기능이 플랫폼 접근성 프로그래밍 인터페이스를 지원하지 못하더라도, 필수적인 접근성 정보를 플랫폼 접근성 프로그래밍 인터페이스를 통해 보조 기술로 제공할 수 있게 되므로, 새롭고 접근 가능한 기술 개발이 가능합니다.

필요성

  • 비장애인뿐만 아니라 보조 기술 사용자(스크린 리더, 키보드 사용자 등)도 웹 애플리케이션을 완전히 사용할 수 있도록 해야 합니다.
  • SPA(Single Page Application) 등 동적 콘텐츠는 접근성 요소(ARIA, 포커스 이동 등)를 통해 구조화가 필요합니다.

대상

  • 사용자 유형
  • 이유
  • 시각장애인

    보이지 않는 UI에 대한 명확한 안내 필요

  • 지체장애인

    키보드만으로 조작 가능한 환경 필요

  • 인지장애인

    논리적 흐름, 오류 피드백 필요

  • 고령자

    명확하고 간단한 UI, 고대비 필요

체크리스트

  • 동적 콘텐츠가 갱신될 때 aria-live로 알림을 제공하는가?
  • 모든 컨트롤이 키보드로 조작 가능한가?
  • 버튼, 입력 등의 인터랙션 요소에 aria-label이 적절히 부여되어 있는가?
  • role, name, state, value가 명확히 전달되는가?
  • 포커스 순서가 논리적이며 시각적으로 확인 가능한가?

테스트 방법

  • 키보드만 사용해 기능을 조작해 보며 (Tab, Enter, Space, Esc, Arrow 등) 기능이 제대로 작동하는지 확인합니다.
  • 스크린 리더로 콘텐츠를 탐색하며 각 요소의 이름, 역할, 상태가 제대로 전달되는지 확인합니다.
  • 자동화 도구(WAVE, Axe, Lighthouse 등)를 사용하여 접근성 점검을 진행합니다.
  • ARIA 속성이 올바르게 동작하는지 개발자 도구로 확인합니다.

QA 지표

  • 키보드 탐색 가능 비율
  • ARIA 속성 적용 정확도
  • 스크린 리더 정보 전달 정확도
  • 동적 콘텐츠 변경 시 알림 제공 여부

개발방법

html 예시

Vue 예시

React 예시

점검 기준

  • 사용자는 보조 기술을 통해 애플리케이션의 모든 기능을 사용할 수 있어야 합니다.
  • 인터랙션 가능한 요소는 role, name, state, value가 적절히 제공되어야 합니다.

점검 방법

  • 키보드 탐색이 가능한가?
  • 포커스가 논리적으로 이동하는가?
  • 자동화 도구에서 접근성 오류가 발생하지 않는가?

준수/미준수 사례

미준수 사례

문제점 :
role 속성이 누락되어 이 버튼이 실제로 어떤 역할을 하는지 명확하지 않습니다.
aria-label이 없어 버튼의 기능(예: "제출하기")을 알 수 없습니다.

준수 사례

설명 :
"type="submit" 속성으로 버튼의 역할이 명확히 정의됩니다.
aria-label="Submit form" 속성으로 버튼의 기능을 명확하게 전달합니다.
role="button" 속성을 통해 이 요소가 버튼임을 명시합니다.
aria-pressed="false" 속성으로 버튼이 눌려지지 않은 상태임을 나타내어 동적 상태를 표현합니다.

관련 영상

출처 : AOA11Y (Academy Of Accessibility)


접근성 테스트 도구 활용 점검방법

결론

접근성은 시작은 있지만 끝이 없는 작업입니다.
오류 항목을 정기적으로 점검하여 접근성 개선을 한다면 점차 검사를 할 항목이 줄어들게 될 것입니다. 모두가 차별 없이 서비스를 이용할 수 있도록 접근성 유지를 위한 모두의 노력이 필요합니다. 무엇보다 접근성 작업은 서비스를 제공한다면 선택이 아닌 필수로 지켜야하는 항목임을 잊지 말아야 합니다.

접근성 작업 시 점검 필수사항

  • 접근성 가이드(WCAG, KWCAG, WAI-ARIA) 내용 숙지
  • 접근성 체크리스트 작성
  • 접근성 자동 및 수동 검사(스크린리더) 진행
  • 접근성 검사 툴(Lighthouse Accessibility 등) 활용 오류 항목 개선 및 내용 정리
  • 접근성 사용자 테스트
  • 접근성 정기적인 모니터링