많은 중소기업이 홈페이지나 서비스에 AI 챗봇을 붙이면서 '사람처럼 자연스러운 대화'에만 신경을 씁니다. 하지만 시각장애인이 스크린 리더로 접속하면 화면에 새 답변이 올라와도 이를 알 길이 없어, 챗봇이 멈춘 것처럼 느껴지는 경우가 많습니다. 결론부터 말하면 LLM 기반 채팅 UI도 일반 웹페이지와 똑같이 웹 접근성 가이드라인(WCAG, 장애가 있는 사용자도 웹 콘텐츠를 동등하게 이용할 수 있도록 정한 국제 기준)을 지켜야 하며, 핵심은 ARIA Live Region이라는 선언 방식입니다.
스크린 리더가 AI 답변을 놓치는 이유
LLM 챗봇 UI는 특별한 기술이 아니라 HTML, CSS, 자바스크립트 같은 일반 웹 표준으로 만들어집니다. 그래서 시각장애인을 포함한 모든 사용자가 접근할 수 있어야 한다는 웹 접근성 기준이 그대로 적용됩니다. 문제는 화면을 보지 않고 스크린 리더(화면 내용을 음성으로 읽어 주는 보조 기술)로 이용하는 사용자는 새로운 답변이 화면에 추가돼도 스스로 그 위치를 찾아가지 않는 한 알아챌 방법이 없다는 점입니다.
이를 해결하는 장치가 ARIA Live Region입니다. 특정 영역을 '살아 있는 영역'으로 선언해 두면, 그 안의 내용이 바뀔 때마다 스크린 리더가 자동으로 변경된 내용을 읽어 줍니다. 시각 사용자가 화면에 올라오는 답변을 눈으로 확인하듯, 스크린 리더 사용자는 이 선언 덕분에 귀로 같은 정보를 받을 수 있습니다.
챗봇 도입 시 점검해야 할 상호작용 영역
홈페이지에 챗봇을 넣을 때는 답변 알림뿐 아니라 입력, 처리 중 표시, 콘텐츠 읽기까지 채팅을 이루는 모든 상호작용을 접근성 관점에서 함께 살펴야 합니다. 특히 답변이 실시간으로 한 글자씩 나타나는 스트리밍 방식을 쓴다면, 완성되지 않은 문장을 조각조각 공지하는 대신 전체 답변이 끝난 뒤 한 번에 알려 주는 편이 훨씬 이해하기 쉽습니다.
| 상호작용 요소 | 놓치기 쉬운 지점 | 적용 방법 |
|---|---|---|
| 텍스트 입력·제출 | 입력창과 버튼의 키보드 접근 | 탭 이동과 레이블 연결 확인 |
| 응답 생성 중 표시 | 로딩 애니메이션만 시각적으로 표시 | 상태를 음성으로도 안내 |
| 응답 완료 알림 | 스트리밍 중 조각난 내용 공지 | 완성 후 전체 내용 한 번에 공지 |
| 답변 내용 읽기 | Live Region 위치가 매번 바뀜 | DOM 끝에 고정, 영역 재사용 |
Live Region 적용을 위한 실행 단계
- 채팅 화면의 접근성 현황 점검하기 스크린 리더(윈도우 내레이터, 보이스오버 등)를 직접 켜고 챗봇과 대화해 보며 답변이 들리는지 확인합니다.
- Live Region 영역 만들기 답변이 표시되는 영역에 aria-live 속성을 선언하고, 이 영역을 페이지 안에 하나만 두어 모든 메시지 공지에 재사용합니다.
- 공지 위치를 DOM 끝으로 고정하기 Live Region을 문서 구조 끝부분에 배치해 레이아웃이 바뀌어도 위치가 흔들리지 않도록 합니다.
- 스트리밍 알림 방식 조정하기 답변이 완성될 때까지 기다렸다가 전체 내용을 한 번에 공지하도록 로직을 수정합니다.
- 처리 중 상태를 비시각적으로도 전달하기 로딩 문구나 애니메이션 외에 음성 안내 문구를 함께 넣어 처리 중임을 알립니다.
흔히 빠지는 함정들
- 로딩 애니메이션만 넣고 끝내는 경우: 시각적 표시는 스크린 리더 사용자에게 전달되지 않으므로 별도 음성 안내가 필요합니다.
- Live Region을 메시지마다 새로 만드는 경우: 영역이 계속 바뀌면 스크린 리더가 변경을 인식하지 못할 수 있어 하나의 영역을 재사용해야 합니다.
- 웹에서만 접근성을 챙기고 네이티브 앱은 넘어가는 경우: Electron이나 Tauri로 감싼 앱도 같은 웹 기술을 쓰므로 동일한 원칙을 적용해야 합니다.
한 줄 정리 AI 챗봇의 완성도는 답변의 자연스러움뿐 아니라, 화면을 보지 않는 사용자도 그 답변을 놓치지 않게 만드는 데서 결정됩니다.