입력칸에 접근가능한 이름을

KRDS CP-405 — 스크린 리더 사용자가 텍스트 입력 필드의 용도를 확인할 수 있도록 , title, aria-label, aria-labelledby 중 1가지 방식을 이용하여 레이블을 제공하고 있다.

0. 들어가며 — 스크린 리더에 ’편집창’이라고만 들리면

이번 525편은 각 텍스트 입력 필드에 <label>, title, aria-label, aria-labelledby 중 1가지로 레이블을 제공 하라는 규칙입니다. 이로써 텍스트 입력 7개 규칙이 마무리됩니다.

CP-400에서 ’모든 입력 필드에 (보이는) 레이블을 두라’고 했죠. 이번 CP-405는 그 레이블을 스크린 리더가 확인할 수 있게 프로그래밍적으로 연결하라는 규칙입니다. 셀렉트 CP-303·날짜 입력 CP-391·텍스트 영역 CP-398과 평행한 규칙이죠. 이번 편을 풀어냅니다.

1. 원문 — 4가지 중 하나로 SR 레이블

CP-405 (컴포넌트 > 텍스트 입력 필드) “스크린 리더 사용자가 텍스트 입력 필드의 용도를 확인할 수 있도록 , title, aria-label, aria-labelledby 중 1가지 방식을 이용하여 레이블을 제공하고 있다.”

각 텍스트 입력 필드에 4가지 방법 중 하나로 접근가능한 이름을 부여해, 스크린 리더가 용도를 알리게 하라는 뜻입니다.

정리: 각 입력 필드에 4가지 중 하나로 접근가능한 레이블을 제공하라. 이게 CP-405입니다.

2. 왜 SR 레이블이 필요한가

텍스트 입력 필드(<input type="text">)는 스크린 리더에서 ’편집창’으로 인식됩니다. 하지만 그 입력 필드가 무엇을 입력하는 것인지(이름·이메일·전화번호)는 프로그래밍적으로 연결된 레이블이 있어야 스크린 리더가 알리죠. 화면에 ’이메일’이라는 텍스트가 옆에 보여도 그게 입력 필드와 프로그래밍적으로 연결돼 있지 않으면, 스크린 리더는 그 둘을 별개로 인식합니다. 그래서 스크린 리더 사용자는 입력 필드에 초점이 가면 ’편집창’이라고만 듣고, 무엇을 적는지 모릅니다.

이는 접근가능한 이름(accessible name) 의 문제입니다(WCAG 4.1.2 Name, Role, Value). 모든 폼 컨트롤은 — 프로그래밍적으로 결정되는 이름이 있어야, 보조기술이 용도를 전달하죠. CP-400(보이는 레이블 존재)과 CP-405(그 레이블의 프로그래밍적 연결)는 짝입니다.

4가지 레이블 제공 방법. CP-405는 다음 중 하나로 이름을 주라고 합니다:

① <label> (권장) — <label for="email">이메일</label> + <input id="email" type="text">. 가장 표준적 이죠. CP-400의 보이는 레이블을 for/id로 연결하면 — 시각·접근성 둘 다 충족합니다. 레이블 클릭 시 필드 포커스도 가고요. 입력 필드엔 이 방식이 최선입니다.

② aria-labelledby — 화면의 기존 텍스트 요소 id를 가리켜 이름으로 씀.

③ aria-label — 보이는 텍스트 없이 속성으로 직접 이름 부여(aria-label="이메일"). 보이는 레이블을 안 둘 때(예: 검색창에 레이블 생략하고 아이콘만 — 단, CP-400이 보이는 레이블 권장이라 제한적).

④ title — title 속성. 폴백 수단(권장도 낮음).

우선순위는 — 입력 필드엔 <label> 연결이 최선입니다(CP-400의 보이는 레이블 + 접근성 동시 충족).

용도가 분명해야. 원문이 ’입력 필드의 용도를 확인’이라 한 것처럼 — 레이블은 무엇을 적는지(이름·이메일·전화 번호)를 정확히 전해야 하죠.

도움말·자동완성도 연결. 레이블(이름)에 더해 — 형식 안내·도움말을 aria-describedby로 연결하면, 스크린 리더가 레이블 + 부가 안내를 함께 읽죠(‘이메일, example 형식, 편집창’). 그리고 — autocomplete 속성(CP-402)으로 입력 목적 식별(WCAG 1.3.5)을 더하면 자동 완성·맞춤 지원도 됩니다. 레이블(405)·도움말(describedby)·자동완성(402)이 함께 입력 필드 접근성을 완성하죠.

플레이스홀더는 레이블이 아님(CP-400 재강조). 플레이스홀더는 — 접근가능한 이름이 아닙니다. 입력 시 사라지고 스크린 리더 읽기가 불일관하죠. 반드시 <label> 등으로 별도 이름을 줍니다.

모든 폼 컨트롤의 일관 원칙. 셀렉트(CP-303)·날짜 입력(CP-391)·텍스트 영역(CP-398)과 동일한 4방식 패턴입니다. 라디오·체크박스의 ’레이블 제공’과도 통하죠. 모든 폼 컨트롤이 접근가능한 이름을 갖는 게 폼 접근성의 기본입니다.

이 규칙은 텍스트 입력 필드의 ’식별 가능성’을 담당합니다 — 보이는 레이블(400)을 스크린 리더에 연결해(405), 스크린 리더 사용자가 무엇을 적는 입력칸인지 알게 하죠. 텍스트 입력 7개 규칙이 이로써 마무리됩니다.

정리하면 — 입력 필드에 연결된 레이블이 없으면 스크린 리더가 ’편집창’으로만 읽어 용도를 못 알리므로, <label> (권장)·aria-labelledby·aria-label·title 중 하나로 각 입력 필드에 접근가능한 이름을 제공해야 합니다.

3. 점검 / 개선

무엇을 점검하나

레이블 존재 — 각 입력 필드에 4가지 중 하나로 접근가능한 이름이 있는가.

연결 정확 — <label for>/id 매칭, aria-labelledby가 올바른 id를 가리키는가.

플레이스홀더 의존 배제 — 플레이스홀더만으로 레이블을 대체하지 않았는가(CP-400).

개선 방향

CP-400의 보이는 레이블을 <label for>/id로 입력 필드에 연결(권장).

도움말은 aria-describedby, 자동완성은 autocomplete(CP-402). 플레이스홀더는 보조로만.

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

역할	책임
퍼블리셔/개발	label/aria 연결 구현
콘텐츠/UX	입력 필드 레이블 텍스트 작성

기관 유형	CP-405 적용
중앙행정기관(대표·운영) / 공공기관 / 지자체	✅ 필수 (텍스트 입력 사용 시)

웹접근성 의무 대상이며 텍스트 입력을 쓰는 사이트에 해당됩니다.

5. 30초 자가진단 + FAQ

✅ 30초 자가진단

□ 각 입력 필드에 4가지 중 하나로 접근가능한 이름이 있나요?

□ <label for>/id 매칭, aria-labelledby가 올바른 id를 가리키나요?

□ 플레이스홀더만으로 레이블을 대체하지 않았나요?

❓ FAQ

Q1. CP-400과 뭐가 다른가요? CP-400은 ‘보이는 레이블이 있는가’(+플레이스홀더 금지), CP-405는 ‘그 레이블이 스크린 리더에 연결됐는가’입니다. 보통 <label for>로 둘 다 충족하죠. Q2. 검색창처럼 레이블을 안 보이게 하려면? aria-label로 이름을 줍니다. 단, 가능하면 보이는 레이블이 권장 (CP-400)이죠. Q3. 다른 폼 컨트롤과 같나요? 네. 셀렉트·날짜·텍스트 영역·라디오·체크박스 모두 같은 ’레이블 제공’ 원칙입니다. 폼 접근성의 기본이죠.

6. 마무리

CP-405의 메시지:

입력칸에 접근가능한 이름을 — label/aria-label/aria-labelledby/title 중 하나로 레이블을 제공하라.

입력 필드에 연결된 레이블이 없으면 스크린 리더가 ’편집창’으로만 읽어 용도를 못 알립니다. <label for> 연결로 시각·접근성을 한 번에 충족하는 게 핵심이죠. 이로써 텍스트 입력 7개 규칙이 마무리됩니다. 다음 편부터는 파일 업로드 (File upload)입니다.

다음 편 예고 ▶ 「526. (CP-406) 파일 업로드 — 사용자가 파일을 첨부·업로드하는 데 사용하고 있다.」

ViewCheck는 각 입력 필드에 접근가능한 레이블이 제공되는지를 진단합니다.

📚 참고 출처

KRDS 컴포넌트 — 텍스트 입력 필드(Text input) 가이드 — https://www.krds.go.kr/html/site/component/component_40.html

WCAG 2.1 SC 4.1.2 Name, Role, Value — https://www.w3.org/WAI/WCAG21/Understanding/name-role-value.html

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

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