프론트엔드 웹 접근성(a11y) - toast

• 웹 접근성(a11y) - 기본
• 웹 접근성(a11y) - toast (현재 글)
• 웹 접근성(a11y) - rem

토스트는 짧은 시간에 나타났다가 사라지는 알림 컴포넌트이다. 일반적으로 토스트 메세지는 사용자와 상호작용이 필요하지 않거나 중요하지 않은 메세지를 표시한다. 지도 앱에서 검색 버튼을 누르면 결과가 나오기 전까지 표시되는 “위치 검색 중”과 같은 메세지를 예로 들 수도 있다.

모달은 다른 컴포넌트이다. 모달의 경우엔 닫기 버튼 등, 사용자와의 상호작용 비용이 더 크다.

토스트 메세지는 몇 가지 주의사항을 놓치면 장애를 겪고 있는 사용자 뿐만 아니라 모두에게 악영향을 주는 접근성 문제를 가질 수 있다.

토스트 메세지 지속시간

메세지를 읽고 이해하는데 필요한 시간은 단지 접근성 문제가 아니다. 언어를 학습 중인 사용자들뿐만 아니라, 읽는 속도가 느린 장애가 없는 사람들도 마찬가지이다. 알림이 표시되는 시간의 길이는 기본 값이 2초이고, 최대 길이는 3.5초인 환경(Android)에서 대게 문제가 될 수 있다.

토스트 메세지를 유지하는 적절한 시간은 5초를 기본으로 하고 다섯 단어당 1초를 더한다. 이는 평균적으로 분당 300단어를 읽는다고 생각하면 의미 있는 수치이다. 즉, 우리가 유지해야 할 최소 길이는 6초인 것이다.

토스트 메세지 AA 레벨 접근성 지침

대부분 토스트 메세지에 적용되는 WCAG2.0 및 2.1에서의 레벨 AA 표준 접근성 지침이 있다.

일괄된 식별, 위치

특정 아이콘에 대체 텍스트가 있는지 또는 메세지에 헤더 역할을 하는 단어가 있는지를 결정 후 사용자 학습을 위해 반복적으로 사용한다. 또 토스트 메세지가 어디에 표시될지 결정하고 일관되게 배치해야 한다.

키보드 접근성

사용자는 키보드를 사용하여 토스트 메세지를 탭으로 이동할 수 있어야 한다. 키보드로 모든 컴포넌트를 탭으로 이동할 수 있어야 하기 때문이다. 토스트 메세지의 위치가 항상 동알한 위치에 배치되었다면 포커스 순서도 정확해야 한다. tabindex 값을 0이 아닌 다른 양수로 지정하여 포커스 순서를 강제로 지정하지 않도록한다. 이것은 필연적으로 더 많은 접근성 문제를 야기한다.

스크린 리더기

WCAG2.1의 새로운 기능으로

HTML을 사용하여 구현된 컨텐츠에서 상태 메세지는 역할이나 속성을 개발자가 작성하여 포커스를 직접 받지 않고 보조 기술을 통해 사용자에게 전달할 수 있다. role alert이나 aria-live와 같은 aria 옵션을 사용하여 토스트 메세지가 표시되자마자 스크린리더기에서 확인할 수 있다.

aria-live

aria-live는 개발자가 페이지 일부를 실시간으로 표시할 수 있도록 돕는다. 업데이트가 페이지의 해당 부분을 탐색하는 것이 아니라 페이지 위치와 상관없이 즉시 사용자에게 전달되어야 한다는 의미이다. 엘리먼트에 aria-live 속성이 있는 경우 해당 엘리먼트와 하위 엘리먼트가 포함된 페이지 영역을 라이브 영역이라고 한다.

예를 들어, 라이브 영역은 사용자의 상호작용으로 인해 나타나는 메세지일 수 있다. 메세지가 시력이 있는 사용자의 주의를 끌 정도로 중요한 경우, aria-live 속성을 설정하여 스크린 리더기에 의존적인 사용자의 주의도 끌 수도 있어야 한다. 이제 아래 div 태그를 비교해 보자.

<!-- 🚨 접근성 문제 야기 -->
<div class="status">메세지가 전송 되었습니다.</div>

<!-- ✅ 문제 개선 -->
<div class="status" aria-live="polite">메세지가 전송 되었습니다.</div>

aria-live에는 polite, assertive, off 세 가지 옵션이 존재한다.

• aria-live=“polite” 현재 진행 중인 작업을 완료했을 때 사용자에게 변경 사항을 알리기 위한 기능이고, aria-live 옵션 중에 가장 많이 사용된다.
• aria-live=“assertive” 스크린 리더기에서 수행 중인 작업을 중단하고 사용자에게 이 변경 사항을 알릴 때 사용한다. 서버 오류와 같은 상태 메세지 또는 입력 필드에 대한 업데이트와 같은 중요하고 긴급한 변경사항에만 사용한다.
• aria-live=“off” aria-live의 동작을 일시적으로 중단하는 옵션이다.

aria-live와 함께 동작하는 ARIA 옵션인 aria-hidden, aria-atomic, aria-busy등을 사용하여 라이브 영역이 변경될 때 사용자에게 전달해야 하는 내용을 디테일하게 가져갈 수 있다. 예를 들어 하위 요소의 가려진(hidden) 스타일을 활성화에서 비활성화로 변화하면 스크린 리더기에서 알림을 줄 수 있다.

aria-live는 초기 페이지 로드에 설정되어 있어야 한다. 엄격하게 지켜져야 할 규칙은 아니지만 라이브 영역에 문제가 생겼을 때 문제가 될 수 있다.

간단한 규칙

위에서 언급된 지침 외에도 토스트 메세지를 만들기 위해 고려해야 하는 몇가지 룰이 있다.

페이지 로드 시 예기치 않은 이벤트로 인해 토스트 메세지를 발생시키는 것은 스크린 리더기 사용자에게 혼란을 야기한다.

포커스를 이동시키기전에 토스트 메세지가 완전히 전달되었는지 확인해야 한다. 특히 토스트 메세지가 여러개인 경우 중요하다. 위에서 언급 했던 aria-live와 같은 접근 ARIA 옵션을 이용하여 메세지를 명시적이고 개발자의 의도한대로 처리할 수 있을 것이다.

ALL UPPER CASE를 과도하게 사용하지 않아야 한다. ALL UPPER CASE의 경우 난독증이 있는 사람뿐만 아니라 장애가 없는 사람도 읽기 어려울 수 있다. 또한 스크린 리더기에서는 대문자를 단어가 아닌 약어라고 생각하여 오동작을 일으킬 수 있고, 단어를 읽는 것이 아닌 각 알파벳을 읽기 때문에 스크린 리더기의 읽는 속도가 현저히 느려진다. 약어를 사용해야 하는 경우엔 <abbr />을 사용하여 단어를 설명하도록 한다.

<abbr /> 의 경우 포커스를 줄 수 없고, 시각 장애인은 대부분 약어를 이해하기 때문에 사용을 권장하지 않고, aria-label 사용을 권장하는 입장도 존재 한다.

마지막

토스트 메세지는 일시적인 상태를 알리기에 좋은 방법이다. 그러나 작은 시각적 요소이지만 접근성 고려 사항이 많다. 50개의 WCAG 2.0 AA 레벨 지침 중 12개가 토스트 메세지에 적용되며, 타이밍 고려 사항도 있다. 개발자와 디자이너가 작업 중인 스타일 가이드에 이러한 생각을 녹이는 것은 서비스 내에 토스트 메세지가 올바른 접근성을 가지도록 하는 훌륭한 단계이다.