ariaNotify(), 스크린리더 알림의 양날의 검
화면이 바뀌었다는 사실을 스크린리더 사용자에게 어떻게 알릴까. 그동안 답은 사실상 aria-live 영역 하나뿐이었고, 그마저도 브라우저·보조기술마다 제멋대로 동작해 개발자를 괴롭혔다. 2026년 6월, 새 ariaNotify() API가 "문자열 하나만 넘기면 스크린리더가 읽어준다"는 깔끔한 대안으로 등장했다. 그런데 CSS-Tricks의 Mat Marquis는 이 편리함이야말로 함정일 수 있다고 경고한다.
"ARIA leaves no room for interpretation; what we say goes, full stop."CSS-Tricks
무슨 일인가
ariaNotify()는 요소나 document에서 호출해 알릴 문자열과 우선순위(normal·high)를 넘기면 스크린리더가 그대로 읽는다. 기존 aria-live는 영역이 DOM에 미리 존재해야 하고 display:none에서 토글하면 안 읽히는 등 타이밍 문제가 많았는데, 이 API는 그런 숨은 마크업 트릭 없이 직접 알림을 띄운다. 파이어폭스 150이 먼저 지원을 붙였다. 문제는 호출이 너무 쉬워서, 옛 alert()처럼 아무 데서나 남발하기 쉽다는 점이다.
여러 시각
같은 "알림" 문제를 세 글이 다른 높이에서 본다.
- CSS-Tricks (Mat Marquis) — ariaNotify()는 진짜 문제를 풀지만, 쉬운 만큼 과도한 알림으로 숙련된 스크린리더 사용자를 방해할 위험이 크다며 절제를 강조한다.
- web.dev (Hiding and updating content) — 전통적 aria-live의 polite·assertive와 aria-atomic·relevant·busy를 정리하되, 영역이 로드 시점에 존재해야 하고 스크린리더마다 동작이 달라 테스트가 필수라고 짚는다.
- web.dev (Introduction to ARIA) — "ARIA의 첫 번째 규칙은 ARIA를 쓰지 않는 것"이라는 원칙으로, 네이티브 HTML로 되는 일에 굳이 ARIA를 덧씌우지 말라고 상기시킨다.
왜 중요한가
세 글을 겹치면 결론이 모인다. 새 API의 가치는 기술이 아니라 절제에서 나온다. ariaNotify()는 aria-live의 고질적 타이밍 문제를 없애지만, 그만큼 "읽어줄 수 있다"가 "읽어줘야 한다"로 오해되기 쉽다. 스크린리더 사용자에게 불필요한 알림은 시각 사용자에게 모달 팝업을 연달아 띄우는 것과 같다. 접근성은 더 많이 말하는 게 아니라, 꼭 필요한 것만 정확한 순간에 말하는 일이다.
실무 적용
- 알림이 정말 필요한지 먼저 묻고, 포커스 이동이나 네이티브 HTML로 이미 전달되는 맥락은 ariaNotify()로 중복 안내하지 마라.
- 새 API는 점진적 향상으로 깔되, 미지원 브라우저를 위해 검증된 aria-live 폴백을 함께 설계하라.
- high 우선순위는 작업을 가로막아야 할 만큼 급한 경우로만 한정하고, 대부분의 알림은 normal로 큐에 쌓아라.
Kenny의 관점
프론트엔드·AX 관점에서 ariaNotify()는 "권한이 생기면 책임도 커진다"는 접근성의 오랜 교훈을 다시 꺼낸다. 그동안 aria-live가 까다로웠던 건 역설적으로 남용을 막는 마찰이기도 했다. 마찰이 사라진 지금, 무엇을 알릴지 결정하는 판단이 곧 품질이 된다. 나는 알림을 늘리는 코드를 리뷰할 때 "이 소리를 끄고 싶은 사용자는 어떻게 하지"를 함께 묻는 것을 기본 규칙으로 삼는다.
출처
이 글은 아래 원문을 바탕으로 Kenny가 한국어로 요약·정리한 큐레이션입니다.
원문 보기 — CSS-Tricks ↗