상태 메시지 - by. UXKM

  • A11Y
  • A11y Creation Tech
  • 모바일 접근성 제작 기법
  • 상태 메시지
요약 설명

관련 지침(보조기술과의 호환성) : 조회 결과·장바구니 수량 변경·로딩·폼 오류 등 중요한 상태 변화가 초점 이동 없이도 보조 기술 사용자에게 전달되는가?
시각적 토스트만 띄우면 스크린 리더 사용자는 변화를 인지하지 못할 수 있습니다. 의미 있는 상태 변화는 접근성 이벤트나 라이브 영역으로 알려야 합니다.

모바일 앱 접근성 체크리스트(MACAG) — 견고성
WCAG 2.2 — Status Messages

필요성

폼 전송 실패, 네트워크 오류, 비동기 로딩 완료 등은 사용자의 다음 행동을 결정합니다. 포커스를 옮기지 않고도 음성으로 즉시 알려 주어야 동등한 경험이 됩니다.

대상

  • 스크린 리더 사용자

    화면 중앙 토스트를 시각적으로 보지 못하는 사용자.

  • 저시력 사용자

    짧게 사라지는 배너를 놓칠 수 있는 사용자.

  • 스위치·키보드 사용자

    포커스가 입력란에 고정된 채 비동기 결과만 바뀌는 흐름을 쓰는 사용자.

  • 전체 사용자

    멀티태스킹 중 알림 센터만 보고 상태를 확인하려는 사용자.

체크리스트

  • 성공·실패

    저장 성공, 결제 실패 등이 음성으로도 요약되는가?

  • 진행률

    장시간 작업에 진행 상태가 업데이트될 때마다 적절히 알리는가?

  • 중복·과다

    같은 메시지가 초당 여러 번 반복되지 않는가?

  • 우선순위

    긴급(차단 오류)과 일반(완료 토스트)을 polite/assertive 등으로 구분하는가?

구현 시 참고

Android

  • AccessibilityEvent, announceForAccessibility, 적절한 liveRegion 속성을 사용합니다.
  • Snackbar와 함께 라이브 영역이 연결되어 있는지 확인합니다.

iOS

  • UIAccessibility.post(notification:argument:) 등으로 레이아웃 변경·알림을 전달합니다.
  • SwiftUI에서는 변경된 상태에 맞는 접근성 속성 업데이트를 검토합니다.

공통

과도한 연속 알림은 사용자를 피로하게 하므로, 중요도에 따라 polite/assertive를 구분합니다.

점검 방법

  • 스크린 리더를 켠 채 네트워크 끊김·복구, 폼 오류, 장바구니 변경을 재현하고 알림 순서를 기록합니다.
  • 포커스를 입력 필드에 둔 상태에서만 완료되는 작업(자동 저장 등)이 있는지 확인합니다.

개발방법

아래 코드는 상태 메시지 검사항목을 충족하기 위해, 보조기술 호환성을 높이는 방식으로 구성한 예시입니다. 폼 제출 결과, 저장 완료, 오류 같은 변화가 포커스 이동 없이도 전달되도록 상태 공지 방식을 일관되게 적용해 주세요.

네이티브

iOS (Swift)

Android

하이브리드

html

Vue

React

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

결론

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

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

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