Cert
UNIT · 1.5

폼과 입력 요소 접근성

Form and Input Accessibility

한국어 해설 KO

Original Text EN

레이블 연결, 오류 메시지, 필수 입력 표시, fieldset/legend 사용법을 학습합니다.

Learn label association, error messages, required fields, and fieldset/legend usage.

학습 목표

label 요소와 입력 필드를 올바르게 연결할 수 있다

인라인 오류 메시지의 접근성 패턴을 설명할 수 있다

fieldset과 legend의 사용 목적을 이해한다

필수 필드 표시의 접근성 요구사항을 설명할 수 있다

Learning Objectives

Correctly associate label elements with input fields

Explain accessible patterns for inline error messages

Understand the purpose of fieldset and legend

Describe accessibility requirements for marking required fields

레이블 — 폼 접근성의 출발점

Labels — Where Form Accessibility Starts

모든 폼 입력 요소에는 연결된 레이블이 있어야 합니다. `<label for="id">`로 명시적으로 연결하거나, 입력 요소를 `<label>` 안에 감싸 암시적으로 연결합니다. 명시적 연결이 보조기술 호환성이 더 좋아 권장됩니다. 레이블 연결의 부수 효과로 레이블 클릭 시 입력에 포커스가 가는 큰 터치 영역도 생깁니다.

Every form input needs an associated label. Associate explicitly with `<label for="id">` or implicitly by wrapping the input inside `<label>`. Explicit association has better AT compatibility and is preferred. A bonus: clicking the label focuses the input, creating a larger touch target.

플레이스홀더만으로는 레이블을 대체할 수 없습니다 — 입력을 시작하면 사라져 참조할 수 없고, 기본 색은 대비 기준에도 미달하기 쉽습니다. 시각적으로 레이블을 숨겨야 하는 디자인이라면(검색창 등) sr-only 클래스나 aria-label을 사용하되, 보이는 텍스트가 있다면 접근 가능한 이름에 포함시켜야 합니다(2.5.3).

Placeholder text cannot substitute for a label — it disappears when typing begins and its default color often fails contrast. If the design must hide the label visually (e.g., a search box), use an sr-only class or aria-label — and any visible text must be contained in the accessible name (2.5.3).

placeholder는 레이블이 아니다 — label 연결과 오류 통지
<!-- ❌ placeholder만 있는 입력: 입력 시작하면 이름이 사라짐 -->
<input type="email" placeholder="이메일">

<!-- ✅ label 연결 + 오류를 aria-describedby·aria-invalid로 -->
<label for="email">이메일</label>
<input id="email" type="email" aria-invalid="true"
       aria-describedby="email-err" autocomplete="email">
<p id="email-err" role="alert">올바른 이메일 형식이 아닙니다.</p>

그룹화 — fieldset과 legend

Grouping — fieldset and legend

관련된 폼 요소는 `<fieldset>`으로 그룹화하고 `<legend>`로 그룹 제목을 제공합니다. 대표 사례: 라디오 버튼 그룹('배송 방법'), 체크박스 그룹, 주소 입력 그룹. 스크린리더는 그룹에 진입할 때 legend를 함께 낭독해, '표준 배송' 라디오가 무엇에 대한 선택지인지 맥락을 제공합니다.

Group related form elements with `<fieldset>` and title the group with `<legend>`. Classic cases: radio groups ('Shipping method'), checkbox groups, address field sets. Screen readers announce the legend when entering the group, giving context to what a 'Standard shipping' radio is a choice about.

legend 없이 라디오 버튼만 나열하면 각 선택지의 레이블('예', '아니오')만 들리고 질문이 무엇인지 알 수 없습니다 — 폼 접근성에서 가장 흔한 결함 중 하나입니다. 시각적 디자인상 fieldset을 쓰기 어려우면 role="group"과 aria-labelledby로 동등한 의미를 제공할 수 있습니다.

Radio buttons without a legend leave users hearing only option labels ('Yes', 'No') with no idea what the question is — one of the most common form defects. Where the visual design resists fieldset, role="group" with aria-labelledby provides equivalent semantics.

오류 처리 패턴

Error Handling Patterns

유효성 검사 오류의 접근성 패턴: 오류를 필드 근처에 인라인으로 표시하고 aria-describedby로 입력과 연결하며, aria-invalid="true"로 오류 상태를 명시합니다. 제출 시 여러 오류가 있으면 상단에 오류 요약(각 오류로 가는 링크 포함)을 제공하고 요약이나 첫 오류 필드로 포커스를 이동합니다.

The accessible validation pattern: show errors inline near the field, connect them with aria-describedby, and mark the state with aria-invalid="true". When submission produces multiple errors, provide an error summary at the top (with links to each error) and move focus to the summary or the first errored field.

오류 메시지는 무엇이 잘못됐고 어떻게 고치는지를 함께 설명해야 합니다(WCAG 3.3.1 오류 식별, 3.3.3 오류 제안). '유효하지 않은 입력'보다 '생년월일은 YYYY-MM-DD 형식으로 입력하세요'가 좋은 메시지입니다. 색상만으로 오류를 표시하지 말고(1.4.1), 오류 발생을 aria-live 영역으로 알리면 스크린리더 사용자가 즉시 인지합니다.

Error messages must say what went wrong and how to fix it (WCAG 3.3.1 Error Identification, 3.3.3 Error Suggestion). 'Enter your date of birth as YYYY-MM-DD' beats 'Invalid input.' Don't mark errors by color alone (1.4.1), and announcing errors via a live region lets screen reader users notice immediately.

오류 예방도 기준입니다: 법적·금융 거래에서는 제출 전 검토·수정 기회를 제공해야 하고(3.3.4), WCAG 2.2의 3.3.7(중복 입력)은 같은 정보를 다시 입력하게 하지 않도록 요구합니다. autocomplete 속성(1.3.5 입력 목적 식별)은 자동완성을 지원해 인지·운동 장애 사용자의 입력 부담을 줄입니다.

Prevention is also required: legal and financial transactions need review-and-correct opportunities before submission (3.3.4), and WCAG 2.2's 3.3.7 (Redundant Entry) forbids making users re-enter the same information. The autocomplete attribute (1.3.5 Identify Input Purpose) enables autofill, reducing input burden for users with cognitive and motor disabilities.

필수 필드와 도움말

Required Fields and Help Text

필수 입력은 시각적 표시(별표 등)와 프로그래밍적 표시(required 속성 또는 aria-required="true")를 모두 제공합니다. 한쪽만 있으면 시각 사용자 또는 스크린리더 사용자 중 한쪽이 놓칩니다. 별표(*)의 의미는 폼 상단에서 설명해주는 것이 좋습니다.

Mark required inputs both visually (asterisk) and programmatically (the required attribute or aria-required="true"). Either alone means one audience misses it — sighted users or screen reader users. Explain what the asterisk means at the top of the form.

형식 안내('비밀번호는 8자 이상')와 도움말은 필드와 aria-describedby로 연결해 스크린리더가 필드 진입 시 함께 낭독하게 합니다. 도움말을 시각적으로만 배치하면 스크린리더 사용자에게는 존재하지 않는 정보가 됩니다.

Connect format hints ('Password must be at least 8 characters') and help text to the field with aria-describedby so screen readers announce them on entry. Help text placed only visually simply doesn't exist for screen reader users.

단원 퀴즈

7문제 · 오답은 오답노트에 자동 저장됩니다

1

폼 입력 필드의 레이블로 플레이스홀더만 사용하면 안 되는 이유는?

2

라디오 버튼 그룹을 접근성 있게 그룹화하는 올바른 방법은?

3

오류 메시지를 입력 필드와 프로그래밍적으로 연결하는 ARIA 속성은?

4

WCAG 2.2의 3.3.7 '중복 입력(Redundant Entry)'이 요구하는 것은?

5

여러 유효성 오류가 발생한 폼 제출 후 권장되는 패턴은?

6

autocomplete 속성과 관련된 WCAG 성공 기준은?

7

제출 실패 시 오류 필드에 빨간 테두리만 표시되고, 스크린 리더 사용자는 무엇이 잘못됐는지 알 수 없습니다. 우선 수정 조합은?

로드맵으로
로그인하면 학습 메모를 작성할 수 있습니다.

댓글

댓글을 불러오는 중...

댓글을 작성하려면 로그인이 필요합니다.