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

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컴포넌트,웹표준

관련 글
다음 호는 언제?
이번 846편은 간행물 자료의 발행 주기 정보를 본문의 부제목이나 별도 안내 영역에 제공하라는 규칙입니다. 그리고 이 편이 — 846 규칙 완전 분해 시리즈의 마지막 한 편입니다.
방대한 자료를 효율적으로
이번 845편은 목록에 필터링, 정렬 방식, 상세 검색(기간, 자료 유형 등) 기능을 제공하여 정보를 효과적으로 조회하라는 규칙입니다. [정책 자료 탐색] 서브섹션의 시작이죠.
적힌 대로 가야 한다
이번 844편은 모든 링크는 실행하였을 때, 링크 레이블에 명시된 적절한 화면으로 이동하라는 규칙입니다.
