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

별표만으론 부족하다

이번 648편은 필수 입력 항목 정보를 보조 기술이 확인할 수 있는 형태로 제공하라는 규칙입니다.

VViewCheck Insight
·2026.07.22 4분 50
별표만으론 부족하다
KRDS BP-082 — 필수 입력 항목 정보는 보조 기술이 확인할 수 있는 형태로 제공하고 있다.

0. 들어가며 — 스크린 리더가 필수임을 알 수 있나

이번 648편은 필수 입력 항목 정보를 보조 기술이 확인할 수 있는 형태로 제공하라는 규칙입니다.

BP-075에서 — 필수/선택을 시각적으로 구분했죠(별표 등). 그런데 — 그 별표가 스크린 리더 사용자에게도 ’필수’로 전달 될까요? BP-082는 보조 기술(스크린 리더)이 필수 항목을 인지하게 하라고 규정합니다. BP-075의 접근성 짝이죠.

1. 원문 — 필수 항목 보조기술 인지

BP-082 (기본 패턴 > 입력 폼) “필수 입력 항목 정보는 보조 기술이 확인할 수 있는 형태로 제공하고 있다.”

필수 입력 항목 정보를 보조 기술이 확인할 수 있는 형태로 제공하라는 뜻입니다.

정리: 필수 항목을 보조 기술(스크린 리더)이 인지하게 제공하라. 이게 BP-082입니다.

2. 왜 보조기술 인지인가

BP-075에서 필수/선택을 명확히 구분했습니다(별표 *, ‘(필수)’ 등). 그런데 이게 시각적으로만 표현되면, 스크린 리더 사용자는 필수임을 모를 수 있죠. BP-082는 보조 기술이 인지할 형태를 요구합니다.

시각 표시만 있을 때의 문제:

별표를 못 인지 필수를 빨간 별표(*)로만 표시하면, 스크린 리더는 그 별표를 ’별표’로 읽거나(혼란), 무시 하거나, CSS로 넣은 별표면 아예 못 읽습니다. 스크린 리더 사용자는 이 항목이 필수인지 모르죠.

필수 누락 필수임을 모르면, 스크린 리더 사용자는 그 항목을 건너뛰고 제출하다 오류를 만납니다. 시각 사용자 는 별표로 아는데 스크린 리더 사용자만 불리하죠.

그래서 BP-082는 — 보조 기술이 확인할 형태로 제공하라고 합니다:

required 속성 필수 입력 필드에 HTML required 속성을요. 스크린 리더가 ’필수’로 인지하고 사용자에게 알립니다. 브라우저 기본 검증도 작동하죠.

aria-required="true" 또는 aria-required="true"로 필수임을 명시합니다. 스크린 리더가 ’○○, 필수, 입력란’처럼 읽죠. (커스텀 위젯 등 required가 안 먹는 경우에 특히요.)

레이블에 ‘필수’ 텍스트 시각적 별표와 함께 레이블에 ‘필수’ 텍스트(또는 별표의 sr-only 대체 텍스트)를 넣어, 스크린 리더가 ’필수’를 읽게요. CSS 별표만으론 부족하니, 텍스트로 보강하죠.

범례 연결 — ‘* 필수 항목’ 범례를 — 두되, 별표 자체도 스크린 리더에 의미가 전달되게 합니다(aria-required와 병행).

BP-075·082의 짝. BP-075는 필수/선택의 시각적 명확 구분, BP-082는 그 필수 정보를 보조 기술도 인지 하게요. 둘이 함께 모든 사용자(시각·스크린 리더)가 필수를 알게 하죠. 시각 표시(별표)만 하고 aria를 빼면, 반쪽 접근성입니다.

WCAG 연계. 이름·역할·값(WCAG 4.1.2) + 레이블·지시(3.3.2)와 연결됩니다. 필수 여부는 — 필드의 중요한 ’상태’이므로, 프로그램적으로(required/aria-required) 전달돼야 보조 기술이 인지하죠.

**별표(*)의 올바른 처리.** CSS ::before로 넣은 별표는 스크린 리더가 못 읽을 수 있습니다. 그래서 별표는 시각 표시로 두되, 필수 정보는 required/aria-required + 레이블 텍스트로 별도로 보장합니다. 시각과 의미를 둘 다요.

이 규칙은 입력 폼의 ’필수 정보 접근성’을 담당합니다 — 필수 항목을 보조 기술이 인지하게 제공해(082), 스크린 리더 사용자도 무엇이 필수인지 알고 빠뜨리지 않게 하죠. 시각 구분(BP-075)의 접근성 완성입니다.

정리하면 — 필수를 시각(별표)으로만 표시하면 스크린 리더 사용자가 인지 못 하므로, required/aria-required + 레이블 ‘필수’ 텍스트로 보조 기술이 확인할 수 있는 형태로 제공해야 합니다.

3. 점검 / 개선

무엇을 점검하나

required/aria-required — 필수 필드에 required 또는 aria-required="true"가 있는가.

레이블 텍스트 — 시각 별표 외에 ‘필수’ 텍스트(또는 sr-only)가 있는가.

스크린 리더 인지 — 스크린 리더가 ’필수’를 읽는가(CSS 별표만 아님).

개선 방향

필수 필드에 required/aria-required="true". 레이블에 ‘필수’ 텍스트.

CSS 별표만 의존 금지. 시각(BP-075) + 보조기술(082) 양쪽 보장.

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

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

웹접근성 의무 대상이며 필수 항목이 있는 폼이 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 필수 필드에 required 또는 aria-required="true"가 있나요?

□ 시각 별표 외에 ‘필수’ 텍스트(또는 sr-only)가 있나요?

□ 스크린 리더가 ’필수’를 읽나요(CSS 별표만 아님)?

❓ FAQ

**Q1. 별표(*)만으로 필수를 표시하면 왜 안 되나요? CSS로 넣은 별표는 스크린 리더가 못 읽거나 ’별표’로만 읽어 필수 임을 모릅니다. required/aria-required + 텍스트로 보장해야 하죠. Q2. required와 aria-required 차이는요? required는 HTML 표준 속성(브라우저 검증도 작동), aria-required는 ARIA 속성입니다. 커스텀 위젯 등 required가 안 먹으면 aria-required="true"를 쓰죠. Q3. BP-075(필수/선택 구분)와 같나요?** BP-075는 시각적 구분, BP-082는 보조 기술 인지입니다. 둘이 함께여야 시각· 스크린 리더 사용자 모두 필수를 알죠. 시각만 하면 반쪽이에요.

6. 마무리

BP-082의 메시지:

별표만으론 부족하다 — 필수 항목을 보조 기술이 확인할 수 있는 형태로 제공하라.

필수를 시각(별표)으로만 표시하면 스크린 리더 사용자가 인지 못 합니다. required/aria-required + 텍스트로 보조 기술도 인지하게 하는 게 핵심이죠. 다음 편은 반복 입력 자동화 — 입력 폼 그룹의 마지막입니다.

다음 편 예고 ▶ 「649. (BP-083) 단계가 있는 입력폼에서 반복 입력 정보를 자동 입력하거나 동일하게 입력할 수 있는 수단을 제공하고 있다.」

ViewCheck는 필수 항목이 보조 기술이 확인할 수 있는 형태로 제공되는지를 진단합니다.

📚 참고 출처

KRDS 기본 패턴 — 입력 폼 가이드 — https://www.krds.go.kr/html/site/pattern/pattern_08.html

WCAG 2.1 SC 4.1.2 Name, Role, Value / 3.3.2 Labels or Instructions — https://www.w3.org/WAI/WCAG21/Understanding/

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

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

#KRDS#공공웹#기본패턴#필수항목#보조기술#스크린리더#접근성#ARIA

관련 글