목록으로
KRDS 체크리스트 분석

결과 수가 바뀐 걸 소리로

이번 669편은 전체 검색 결과 수 안내 텍스트에 live-region을 적용하고, 값이 변경되자마자 스크린 리더로 전달되도록 aria-live="polite"를 사용하라는 규칙입니다.

VViewCheck Insight
·2026.07.22 4분 50
결과 수가 바뀐 걸 소리로
KRDS BP-103 — 전체 검색 결과 수 안내 텍스트에 live-region을 적용하고 값이 변경되자마자 해당 정보가 스크린 리더로 전달될 수 있도록 aria-live=“polite”를 사용하고 있다.

0. 들어가며 — 필터를 걸었는데 결과가 몇 개인지 안 들리면

이번 669편은 전체 검색 결과 수 안내 텍스트에 live-region을 적용하고, 값이 변경되자마자 스크린 리더로 전달되도록 aria-live="polite"를 사용하라는 규칙입니다.

필터를 걸어 — 결과 수가 ’152건 → 23건’으로 바뀌어도, 스크린 리더 사용자는 그 변화를 못 들으면 모르죠. BP-103은 결과 수에 aria-live를 적용하라고 규정합니다. 동적 변화 접근성(BP-049 정신)의 필터 적용이죠. 이번 편을 풀어냅니다.

1. 원문 — 결과 수 aria-live=“polite”

BP-103 (기본 패턴 > 필터링·정렬) “전체 검색 결과 수 안내 텍스트에 live-region을 적용하고 값이 변경되자마자 해당 정보가 스크린 리더로 전달 될 수 있도록 aria-live="polite"를 사용하고 있다.”

결과 수 텍스트에 aria-live="polite"를 적용해 변경 시 스크린 리더로 전달하라는 뜻입니다.

정리: 결과 수 텍스트에 aria-live=“polite”를 적용하라. 이게 BP-103입니다.

2. 왜 결과 수 live-region인가

필터·정렬을 적용하면, 결과 수가 바뀝니다(‘전체 152건’ → ‘필터 결과 23건’). 시각 사용자는 이 숫자 변화를 즉시 봅니다. 그런데 스크린 리더 사용자는, 결과 수가 동적으로 바뀐 걸 자동으로 못 듣죠. BP-103은 aria-live로 이를 전달하라고 합니다.

결과 수 안내가 없을 때(스크린 리더)의 문제:

결과 변화 미인지 필터를 적용해 결과가 23건으로 줄어도, 스크린 리더 사용자는 그 숫자 변화를 자동으로 못 듣습니다. 결과 수 텍스트가 바뀌어도, 포커스가 다른 곳에 있으면 안 읽히죠. ‘내 필터가 적용됐나?’, ‘몇 개나 나왔지?’ 모릅니다.

빈 결과 미인지 필터가 너무 좁아 0건이어도, 안내가 없으면 결과가 없는 줄도 모르고 헤맵니다.

탐색 피드백 부재 필터를 바꿔도, 효과(결과 수 변화)를 못 들으니 탐색이 어렵죠.

그래서 BP-103은 — aria-live="polite"를 요구합니다:

결과 수에 live-region 결과 수 안내 텍스트(‘전체 23건’, ‘검색 결과 23건’)를 담는 영역에 aria-live= "polite"를 적용합니다. 이 영역의 내용(숫자)이 바뀌면, 스크린 리더가 자동으로 읽어주죠. ’검색 결과 23건’처럼요.

즉시 전달 값이 변경되자마자(필터·정렬 적용 즉시) 스크린 리더에 전달됩니다. 사용자가 필터의 효과를 바로 듣죠.

polite 모드 polite는 사용자가 하던 읽기를 끝낸 후 알리는, 끼어들지 않는 모드입니다(BP-049). 결과 수 변경 같은 일반 안내에 적합하죠(긴급 아님).

WCAG 4.1.3(상태 메시지). 이는 WCAG 2.1 SC 4.1.3(상태 메시지)의 적용입니다. 콘텐츠 변경 없이 상태(결과 수) 가 바뀌면, 포커스 이동 없이도 보조 기술에 전달하라는 거죠. aria-live가 그 표준 방법입니다.

동적 변화 접근성의 일관 패턴. 피드백 구획 aria-live(BP-049), 즉각 표시(BP-100), 일괄 적용(BP-101)에서 본 동적 변화 안내의 일관된 패턴입니다. 화면이 새로고침 없이 부분 변경될 때(결과 수), 그 변화를 스크린 리더에 알리죠.

결과 수 외에도. 결과 수 외에 로딩 상태(‘검색 중’), 적용 조건 변경 등도 aria-live로 알리면 좋습니다. 핵심은 필터·정렬의 동적 변화를 스크린 리더 사용자도 인지하게 하는 것이죠.

이 규칙은 필터링·정렬의 ’결과 변화 접근성’을 담당합니다 — 결과 수에 aria-live=“polite”를 적용해(103), 스크린 리더 사용자도 필터·정렬의 효과(결과 수 변화)를 인지하게 하죠. 초점 유지(BP-104)와 함께 동적 접근성을 완성합니다.

정리하면 — 필터·정렬로 결과 수가 바뀌어도 스크린 리더 사용자는 자동으로 못 들으므로, 결과 수 텍스트에 aria-live= "polite"를 적용해 변경 즉시 전달해야 합니다.

3. 점검 / 개선

무엇을 점검하나

aria-live 적용 — 결과 수 텍스트 영역에 aria-live="polite"가 있는가.

즉시 전달 — 필터·정렬 적용 시 결과 수 변경이 스크린 리더로 읽히는가.

polite 적절 — 긴급이 아니므로 assertive가 아닌 polite인가.

개선 방향

결과 수 안내 영역에 aria-live="polite". 변경 즉시 전달(WCAG 4.1.3).

로딩·빈 결과도 안내. 긴급 아니므로 polite. 초점 유지(BP-104).

4. 누가 담당하나 / 우리 사이트에 해당될까?

역할책임
퍼블리셔/개발aria-live 구현
QA/접근성결과 수 전달 스크린 리더 검증
기관 유형BP-103 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체✅ 필수 (웹접근성 의무)

웹접근성 의무 대상이며 필터·정렬 결과 수를 보이는 사이트가 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 결과 수 텍스트 영역에 aria-live="polite"가 있나요?

□ 필터·정렬 적용 시 결과 수 변경이 스크린 리더로 읽히나요?

□ 긴급이 아니므로 assertive가 아닌 polite인가요?

❓ FAQ

Q1. aria-live가 왜 필요한가요? 결과 수가 동적으로 바뀌어도(152→23건) 스크린 리더는 자동으로 못 읽습니다. aria- live="polite"를 적용하면 변경 시 ‘검색 결과 23건’을 읽어주죠(WCAG 4.1.3). Q2. polite와 assertive 중 뭘 쓰나요? 결과 수 변경은 긴급하지 않으니 끼어들지 않는 polite를 씁니다. assertive는 중요한 오류·경고용이죠. Q3. 결과 수만 알리면 되나요? 결과 수가 핵심이지만, 로딩 상태(’검색 중’)·빈 결과도 알리면 좋습니다. 필터·정렬의 동적 변화를 스크린 리더 사용자도 인지하게 하는 게 목표죠.

6. 마무리

BP-103의 메시지:

결과 수가 바뀐 걸 소리로 — 결과 수 텍스트에 aria-live=“polite”를 적용하라.

결과 수가 바뀌어도 스크린 리더 사용자는 자동으로 못 듣습니다. aria-live=“polite”로 변경 즉시 전달해 필터 효과를 인지 하게 하는 게 핵심이죠. 다음 편은 즉각 표시 시 초점 유지 — 필터링·정렬 그룹의 마지막입니다.

다음 편 예고 ▶ 「670. (BP-104) 필터링·정렬 결과를 즉각적으로 표시할 때, 키보드 초점은 값을 변경하거나 선택한 옵션 항목에 유지하고 있다.」

ViewCheck는 결과 수 텍스트에 aria-live=“polite”가 적용되는지를 진단합니다.

📚 참고 출처

KRDS 기본 패턴 — 필터링·정렬 가이드 — https://www.krds.go.kr/html/site/pattern/pattern_10.html

WCAG 2.1 SC 4.1.3 Status Messages — https://www.w3.org/WAI/WCAG21/Understanding/status-messages.html

KRDS #ViewCheck #공공웹사이트 #전자정부 #디지털정부 #웹접근성 #디자인시스템 #UIUX #UI컴포넌트 #웹표준

KRDS,ViewCheck,공공웹사이트,전자정부,디지털정부,웹접근성,디자인시스템,UIUX,UI컴포넌트,웹표준

#KRDS#공공웹#기본패턴#live-region#aria-live#검색결과수#스크린리더#접근성

관련 글