aria-live 알림이 안 읽힌다면? 메시지와 영역을 함께 만든 경우

메시지와 영역을 동시에 만들면 알림을 놓칠 수 있다

화면에 상태 메시지는 나타나는데 스크린리더가 읽지 않는다면, aria-live 속성의 유무와 함께 영역이 먼저 존재했는지를 봐야 한다. 라이브 영역은 보통 그 안에서 일어난 내용 변화를 알린다. 문구를 채운 요소를 처음 삽입하는 동작과, 이미 등록된 영역의 문구를 바꾸는 동작은 같지 않다.

MDN의 라이브 영역 안내는 빈 영역을 먼저 마련하고 보조 기술이 인식할 시간을 준 뒤 내용을 갱신하도록 설명한다. 초기 HTML에 영역을 넣는 방법이 가장 안정적이다. JavaScript로 영역부터 만들어야 한다면 내용 갱신은 이후 이벤트 루프 작업으로 미룬다.

다만 모든 역할이 똑같이 동작하지는 않는다. role="alert"에는 초기 내용도 알리는 특수 처리가 있다. 이 예외를 일반적인 aria-live="polite" 영역에 그대로 기대하면 구현을 잘못 판단하게 된다.

빈 컨테이너를 두고, 이후 동작에서 텍스트를 바꾼다

다음은 알림 발생 순서를 보여주는 작은 예제다. 버튼과 빈 라이브 영역을 초기 HTML에 두고, 사용자가 버튼을 누르면 기존 영역의 텍스트만 갱신한다. 저장 API를 호출하는 예제는 아니며, 알림 자체를 확인하는 데 초점을 둔다.

<button id="notify" type="button">알림 시험</button>
<p id="status" aria-live="polite" aria-atomic="true"></p>

<script>
  const status = document.getElementById("status");
  document.getElementById("notify").addEventListener("click", () => {
    status.textContent = "알림 시험이 완료됐다.";
  });
</script>

aria-live 속성 설명처럼 알림을 위해 해당 영역으로 포커스를 옮길 필요는 없다. 실제 앱에서는 저장 성공 응답이나 검색 결과 수신처럼 결과가 확정된 시점에 그 문구를 넣는다. 버튼을 눌렀다는 사실만으로 ‘저장 완료’를 알리면 작업 결과와 안내가 어긋난다.

예제의 핵심은 새 요소를 매번 만드는 것이 아니라 기존 영역의 내용을 바꾼다는 점이다. 같은 문구를 다시 대입했을 때의 재알림까지 보장하는 코드는 아니다. 반복 알림이 필요한 UI라면 그 흐름도 따로 시험해야 한다.

assertive로 바꾸기 전에 알림의 내용과 시점을 본다

일반적인 완료 안내에는 polite가 맞는다. 현재 읽는 문장이나 사용자 입력을 마칠 여유를 두고 알리기 때문이다. assertive는 즉각적인 주의가 필요한 긴급 알림에 쓴다. 음성이 안 들린다는 이유로 모든 상태 안내를 긴급하게 만들면 사용자가 듣던 내용을 끊을 수 있다.

aria-atomic="true"는 변경된 부분만이 아니라 영역 전체를 읽도록 하는 속성이다. 예를 들어 ‘검색 결과 3개’에서 숫자만 바뀌었을 때 전체 문구가 필요하다면 이 설정을 검토할 수 있다. 알림 우선순위와 읽을 범위는 다른 선택이다.

스크린리더 구현 안내는 aria-busy="true"인 영역의 변경을 busy 해제 전까지 알림 대기열에 넣지 않도록 설명한다. 여러 조각으로 갱신하는 UI라면 작업이 끝난 뒤 busy 상태가 해제되는지도 확인해야 한다.

Chrome은 알림 기록을 더했지만, 최종 확인은 듣는 과정이다

Chrome DevTools의 2026년 10월 업데이트에는 라이브 알림과 ariaNotify 호출을 기록하고 디버깅하는 기능이 추가됐다. 알림 문구를 만드는 앱 코드를 살필 때 브라우저 쪽에서 발생한 알림을 추적할 수 있는 변화다.

이 기록은 스크린리더가 실제로 어떤 말을 했는지 녹음한 결과와는 다르다. 보조 기술은 우선순위와 자체 설정에 따라 알림을 처리한다. 따라서 브라우저 기록을 확인한 뒤에도 지원 대상 브라우저와 스크린리더 조합에서 같은 동작을 수행해야 한다.

시험에서는 메시지가 들리는지뿐 아니라 앞서 읽던 내용을 끊는지, 숫자만 읽어 의미가 사라지지는 않는지, 연속 동작에서도 필요한 결과를 전달하는지 들어본다. 영역 생성 순서부터 수정하고, 문구의 범위와 우선순위를 맞춘 다음 실제 발화를 확인하는 순서가 문제를 좁히는 데 도움이 된다.