WCAG 3.3.2: 레이블 또는 지침

WCAG 3.3.2는 콘텐츠가 사용자 입력을 필요로 할 때, 모든 사용자 — 능력과 상관없이 — 양식 데이터를 제출하기 전에 자신에게 무엇이 요구되는지 이해할 수 있도록 레이블이나 지침을 제공할 것을 요구합니다. 양식 필드에 레이블을 제공하지 않는 것은 웹에서 가장 흔하면서도 영향력이 큰 접근성 장벽 중 하나입니다.

이 규칙의 의미

WCAG 성공 기준 3.3.2 — 레이블 또는 지침(Level A)은 다음과 같이 규정한다. “콘텐츠가 사용자 입력을 요구하는 경우 레이블 또는 지침이 제공되어야 한다.” 실질적으로는, 사용자가 정보를 입력하거나 선택하도록 요구하는 모든 폼 필드, 입력 컨트롤, 텍스트 영역, select 요소에는 사용자가 해당 필드와 상호작용하기 전에 필드의 목적을 명확히 알 수 있도록 하는, 눈에 보이는 의미 있는 레이블 또는 지침이 있어야 한다는 뜻이다.

이 기준은 의도적으로 범위가 넓다. 사용자가 데이터를 제공하는 모든 메커니즘을 포함한다. 모든 타입의 <input> 요소(텍스트, 이메일, 비밀번호, 숫자, 날짜, 체크박스, 라디오, 파일 업로드), 여러 줄 텍스트를 위한 <textarea> 요소, 그리고 <select> 드롭다운이 여기에 해당한다. 또한 role='combobox'나 role='listbox'와 같은 ARIA 역할로 만든 커스텀 인터랙티브 컨트롤에도 적용된다.

레이블은 이 기준을 충족하는 여러 방식으로 제공될 수 있다. 가장 견고한 방법은 시각적으로 표시되며 일치하는 for/id 쌍을 통해 컨트롤과 연결된, 프로그래밍 방식으로 연계된 <label> 요소를 사용하는 것이다. 또는, 기존 요소를 가리키는 aria-labelledby를 사용해 눈에 보이는 레이블 텍스트를 연결할 수 있고, aria-describedby로 추가 지침을 연결할 수도 있다. 핵심 요구 사항은 레이블이나 지침이 제공되어야 한다는 점이다. 즉, 사용자가 지각할 수 있는 형태로 존재해야 한다. 플레이스홀더 텍스트만으로는 이 기준을 충족하지 못하는데, 사용자가 입력을 시작하는 즉시 사라지고, 모든 보조 기술이 이를 지속적인 레이블로 신뢰성 있게 전달하지도 않기 때문이다.

준수로 인정되려면 각 입력에는 눈에 보이는(또는 최소한 프로그래밍 방식으로 판별 가능한) 레이블이 있어야 하며, 사용자가 필드를 채우기로 하기 전에 존재해야 하고, 어떤 데이터가 필요한지 전달할 만큼 충분히 설명적이어야 한다. 위반은 필드에 레이블이 전혀 없거나, 유일한 레이블이 placeholder 속성인 경우, 레이블이 시각적으로는 존재하지만 프로그래밍 방식으로 연계되어 있지 않은 경우, 또는(예: “DD/MM/YYYY 형식으로 날짜를 입력하세요”)와 같은 요구 형식에 대한 지침이 전혀 없는 경우에 발생한다.

WCAG는 좁은 예외를 하나 언급한다. 폼에 단일하고 명백한 필드만 있는 경우 — 예를 들어, 바로 옆에 명확히 레이블이 붙은 제출 버튼이 있는 사이트 전체 검색창 — 맥락 자체가 충분한 지침을 제공할 수 있다. 그러나 이 예외는 매우 제한적이며, 다중 필드 폼에서 레이블을 생략하기 위한 일반적인 근거로 사용되어서는 안 된다.

왜 중요한가

폼 레이블은 매우 다양한 사용자에게 가장 큰 영향을 미치는 접근성 기능이다. 레이블이 없으면 많은 사람이 거래를 완료하거나, 서비스에 등록하거나, 기관에 연락하는 것이 사실상 불가능해지는 장벽이 생긴다.

스크린 리더에 의존하는 시각장애 및 저시력 사용자에게 레이블이 없는 필드는 맥락 없이 단순히 “edit text” 또는 “blank”로만 읽힌다. 사용자는 여기에 이름을 입력해야 하는지, 이메일 주소를 입력해야 하는지, 신용카드 번호를 입력해야 하는지 알 수 없다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 그중 수백만 명이 웹과 상호작용하는 주요 수단으로 스크린 리더를 사용한다.

인지 및 학습 장애 — 난독증, ADHD, 기억 관련 장애 등을 포함 — 가 있는 사용자에게는 플레이스홀더 텍스트가 특히 해롭다. 플레이스홀더는 포커스나 입력 시 사라지기 때문에, 폼 작성 중간에 잠시 멈춘 사용자는 이미 입력을 시작한 필드에 무엇을 입력해야 했는지 다시 참조할 수 없다. 이들은 지침을 다시 읽기 위해 필드를 지워야 하고, 이는 혼란과 좌절을 초래한다. 지속적으로 보이는 레이블은 이러한 인지적 부담을 완전히 제거한다.

키보드, 스위치 장치, 음성 제어로 탐색하는 운동장애 사용자에게 레이블은 추가적인 기능을 한다. Dragon NaturallySpeaking과 같은 음성 제어 소프트웨어를 통해 필드를 활성화할 때 사용하는 음성 명령어가 되기 때문이다. 눈에 보이는 레이블 텍스트가 프로그래밍 방식의 접근 가능한 이름과 일치하지 않으면 음성 명령은 아무런 표시 없이 실패한다.

구체적인 실제 상황을 생각해 보자. 저시력 사용자가 터키의 한 공공기관 포털에서 정부 지원금을 신청하고 있다. 이 폼은 레이블 대신 플레이스홀더 텍스트를 사용한다. 사용자가 화면을 읽기 위해 200%로 확대하자, 플레이스홀더는 읽기도 전에 사라진다. 사용자는 추측으로 필드를 채우고 폼을 제출하지만, 어떤 필드가 잘못되었는지 알려주지 않는 일반적인 오류 메시지만 받는다. 이 상황은 중요한 공공 서비스에서의 배제를 초래하며, 전적으로 예방 가능하다.

접근성을 넘어, 레이블이 있는 폼은 검색 엔진 크롤러가 폼의 목적을 더 잘 이해할 수 있게 해 SEO를 개선하고, 특히 작은 터치 타깃이 연관 입력의 활성 영역을 확장하는 탭 가능한 레이블 영역의 이점을 누리는 모바일 사용자 등 모든 사용자의 사용성을 향상시킨다.

테스트 방법

axe DevTools 또는 Lighthouse를 사용한 자동 스캔: Chrome 또는 Firefox에서 폼이 포함된 페이지를 연다. axe DevTools 브라우저 확장을 실행하고 label, select-name, textarea-label 규칙으로 결과를 필터링한다. 표시된 모든 요소를 기록한다. 보조 확인을 위해 Google Lighthouse(접근성 감사)를 실행한다. 모든 위반 사항을 내보내거나 스크린샷으로 저장한다. 자동 보고서가 깨끗하다고 해서 준수가 보장되는 것은 아니므로, 반드시 수동 단계로 진행해야 한다.
시각적 검사: 어떤 보조 기술도 사용하지 않고 페이지의 모든 폼 필드를 검토한다. 각 필드에 플레이스홀더가 아닌, 눈에 보이는 정적인 레이블이 있고, 필드 근처(일반적으로 위나 왼쪽)에 명확히 위치하는지 확인한다. 형식 요구 사항(예: “비밀번호는 최소 8자여야 합니다”)이 실패한 제출 이후가 아니라 입력 전 또는 입력 시점에 표시되는지 확인한다. 필수 필드가 색상만으로 식별되지 않는지도 확인한다.
키보드 탐색 테스트: 모든 폼 필드를 Tab 키로 이동하며 확인한다. 각 필드에 포커스가 갈 때마다, 눈에 보이는 레이블만으로 그 목적이 즉시 명확해야 한다. 키보드로 도달할 수 있지만 그 순간 인접한 지속적인 레이블이 보이지 않는 필드는 없어야 한다.
NVDA와 Firefox를 사용한 스크린 리더 테스트: NVDA를 실행한 상태에서 폼을 연다. Tab 키를 눌러 각 인터랙티브 컨트롤로 이동한다. NVDA는 레이블, 역할(예: “edit”, “combo box”), 상태(예: “required”)를 함께 읽어야 한다. NVDA가 레이블 없이 역할과 상태만 읽는다면 해당 필드는 실패이다. NVDA의 폼 모드(인터랙티브 요소에서 자동으로 활성화)를 사용해 실제 사용자 탐색을 시뮬레이션한다.
VoiceOver와 Safari(macOS/iOS)를 사용한 스크린 리더 테스트: VoiceOver를 활성화한다(Command + F5 on Mac). Tab 또는 스와이프를 사용해 각 폼 필드로 이동한다. VoiceOver는 역할보다 먼저 레이블을 읽어야 한다. iOS에서는 각 필드를 탭했을 때 키보드가 나타나기 전에 레이블이 소리로 읽히는지 확인한다. 플레이스홀더만 있는 필드는 처음 포커스 시 플레이스홀더가 읽히지만, 텍스트를 입력하면 보통 아무것도 읽히지 않게 된다.
JAWS와 Chrome을 사용한 스크린 리더 테스트: JAWS를 실행하고 Tab 키로 폼을 탐색한다. JAWS의 Forms Mode를 사용한다. 각 필드의 읽히는 이름이 눈에 보이는 레이블과 정확히 일치하는지 확인한다. Insert + F1(필드 도움말)을 사용해 aria-describedby를 통한 추가 설명이 있는지 확인한다.
Dragon NaturallySpeaking을 사용한 음성 제어 테스트: Dragon을 활성화하고, 각 필드의 눈에 보이는 레이블을 말해 해당 필드와 상호작용을 시도한다. 말한 레이블이 프로그래밍 방식의 접근 가능한 이름과 일치하지 않으면 필드는 음성 명령에 반응하지 않으며, 이는 3.3.2 및 관련 기준 위반을 의미하는 불일치이다.

수정 방법

텍스트 입력에 레이블이 없는 경우 — 잘못된 예

<!-- 레이블이 제공되지 않았고, 플레이스홀더만 힌트로 사용됨 -->
<input type='text' name='email' placeholder='Email address' />

텍스트 입력에 레이블이 없는 경우 — 올바른 예

<!-- 눈에 보이는 <label>이 일치하는 for/id 속성으로 연계됨.
     플레이스홀더는 보조 힌트로 사용할 수 있지만,
     레이블이 기본이자 지속적인 식별자 역할을 함. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

레이블이 없는 select 드롭다운 — 잘못된 예

<!-- 레이블이 없어 스크린 리더는 선택된 옵션 값만 읽게 됨 -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

레이블이 없는 select 드롭다운 — 올바른 예

<!-- 프로그래밍 방식으로 연계된 레이블이
     사용자가 드롭다운을 열기 전에 필드의 목적을 명확히 함. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

레이블이 없는 textarea — 잘못된 예

<!-- textarea에 레이블이 없으며, 주변 단락 텍스트는
     프로그래밍 방식으로 연계되지 않아 스크린 리더가
     이 필드의 레이블로 읽지 않는다. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

레이블이 없는 textarea — 올바른 예

<!-- 기존에 보이는 제목을 aria-labelledby로 textarea와 연계하거나,
     또는 <label> 요소로 감싸는 방식 사용. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

날짜 필드에 형식 지침이 없는 경우 — 잘못된 예

<!-- 레이블은 있지만 예상 날짜 형식에 대한 지침이 없어
     사용자가 01/06/2025 또는 2025-06-01 중 무엇을 입력해야 할지 추측해야 함. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

날짜 필드에 형식 지침이 있는 경우 — 올바른 예

<!-- 형식 지침이 눈에 보이고 aria-describedby로 연계되어
     필드에 포커스가 갈 때 스크린 리더가 함께 읽어 줌. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

자주 발생하는 실수

placeholder를 유일한 레이블로 사용하는 경우: 플레이스홀더 텍스트는 입력 시 사라지고, 모든 스크린 리더가 이를 레이블로 신뢰성 있게 읽어 주지 않으며, 지속적인 참조 텍스트가 필요한 인지 장애 사용자에게는 특히 문제가 된다. 항상 플레이스홀더와 더불어 눈에 보이는 <label>을 제공해야 한다.
프로그래밍 방식 연계 없이 필드 근처에 레이블을 시각적으로만 배치하는 경우: 입력 위에 시각적으로 배치된 <p>나 <span>은 시력이 있는 사용자에게는 레이블처럼 보이지만, 스크린 리더는 이를 무시한다. <label for='id'>, aria-labelledby를 사용하거나, 입력을 <label> 요소 안에 감싸야 한다.
눈에 보이는 레이블과 일치하지 않는 텍스트로 aria-label을 사용하는 경우: 프로그래밍 방식의 접근 가능한 이름이 눈에 보이는 텍스트와 다르면, 음성 제어 사용자는 화면에서 읽은 내용을 말해도 필드를 활성화할 수 없으며, 이는 SC 2.5.3(Label in Name) 위반일 뿐 아니라 스크린 리더 사용자에게도 혼란을 준다.
라디오 버튼 그룹에 레이블을 붙이면서 그룹 legend를 생략하는 경우: 개별 라디오 버튼에는 각 옵션 텍스트로 레이블이 붙어 있을 수 있지만, “Payment method”와 같은 상위 질문이 <fieldset>과 <legend>로 제공되지 않으면, 키보드로 탐색하는 사용자는 각 옵션을 맥락 없이 듣게 되어 무엇을 선택하는지 이해하지 못한다.
필수 필드를 색상이나 별표만으로 식별하는 경우: 레이블 옆의 별표(*)는, 그 의미가 설명되지 않으면(예: 폼 상단에 “* 표시가 있는 필드는 필수입니다”라는 안내) 스크린 리더 사용자에게 아무 의미도 전달하지 못하며, 필수 필드에는 required 또는 aria-required='true' 속성도 함께 있어야 한다.
형식 지침을 실패한 제출 이후에만 제공하는 경우: 비밀번호 규칙이나 날짜 형식 요구 사항을 제출 후 오류 메시지에서만 보여 주면, 사용자는 무엇이 요구되는지 알기 위해 반드시 한 번은 실수해야 한다. 지침은 사용자가 필드와 상호작용하기 전 또는 그 시점에 제공되어야 한다.
display:none 또는 visibility:hidden으로 레이블을 숨기는 경우: 이러한 CSS 속성은 레이블을 접근성 트리에서 완전히 제거한다. 레이블을 시각적으로 숨겨야 하는 경우(예: 미니멀 디자인), 요소를 접근성 트리에 남겨 두면서 화면 밖으로 이동시키는 시각적 숨김 CSS 클래스를 사용해야 한다.
title 속성을 유일한 레이블로 사용하고 충분하다고 가정하는 경우: axe-core는 title만 있는 레이블을 위반으로 표시하지 않을 수 있지만, title 속성은 호버 시 툴팁으로만 나타나며 키보드 전용 사용자와 모바일 사용자에게는 접근할 수 없다. 이는 보조 설명으로만 사용해야 하며, 기본 레이블로 사용해서는 안 된다.
컨테이너 <div>에 단일 aria-label을 적용하고 자식 입력이 레이블을 상속한다고 기대하는 경우: 컨테이너 요소에 설정된 ARIA 레이블은 자식 폼 컨트롤에 상속되지 않는다. 각 인터랙티브 컨트롤은 개별적으로 레이블이 있어야 한다.
동적 콘텐츠 업데이트 후 레이블을 다시 연계하지 않는 경우: JavaScript로 폼 필드를 동적으로 삽입할 때(예: 주소 행 추가), 새로 삽입된 입력은 개발자가 눈에 보이는 레이블 텍스트만 형제 요소로 추가하고 적절한 for/id 바인딩을 하지 않아 연관 레이블이 없는 경우가 많다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보 제32933호에 게재되었으며, WCAG 2.2와 정렬된 의무적인 웹 접근성 요구 사항을 수립한다. WCAG 성공 기준 3.3.2 — 레이블 또는 지침은 Level A 요구 사항으로, 준수의 기준선에 해당하며 이 대통령령에서 가장 엄격하게 집행되는 조항 중 하나이다.

이 대통령령은 광범위한 유형의 기관을 포괄하며, 부문별로 준수 기한이 다르다. 공공기관 — 부처, 지방자치단체, 국가 기관, 공적 자금 지원 기관 등을 포함 — 은 대통령령 공포 후 1년 이내에 Level A 전면 준수를 달성해야 한다. 범위에 포함되는 민간 부문 기관은 2년 이내에 준수해야 한다. 명시적으로 포함된 민간 부문에는 전자상거래 플랫폼, 은행 및 금융기관, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 민간 학교가 포함된다.

이 모든 기관에 대해, 폼 필드에 레이블을 제공하지 않는 것은 단순한 사용성 부족이 아니라 직접적인 규정 위반이다. 폼은 모든 대상 디지털 서비스 전반에 걸쳐 광범위하게 사용된다. 시민은 정부 포털에서 신청서를 제출하고, 환자는 병원 웹사이트에서 진료를 예약하며, 고객은 전자상거래 플랫폼에서 구매를 완료하고, 학생은 학교 포털을 통해 등록한다. 이러한 여정 하나하나가 폼에 의존하며, 그 폼의 레이블 없는 필드 하나하나가 감사인이 문서화하고 보고할 수 있는 명백한 WCAG 3.3.2 위반이다.

대통령령의 적용을 받는 조직은 SC 3.3.2 준수를 모든 접근성 감사 또는 인증 프로세스의 전제 조건으로 취급해야 한다. 이는 Level A 기준이므로 면제하거나 연기할 수 없으며, Level A 항목을 제외한 부분적 준수 주장은 인정되지 않는다. 모든 대외 공개 폼에서 레이블이 있는 입력을 입증하지 못하는 기관은 규제상 지적, 비준수의 공적 보고, 그리고 포용적 디자인이 점점 더 디지털 신뢰와 연결되는 시장에서의 평판 손상을 감수해야 한다.

실무적인 관점에서 보면, 3.3.2 준수 달성은 조직이 취할 수 있는 가장 적은 노력으로 가장 큰 효과를 내는 조치 중 하나이다. 기존 폼 컨트롤에 레이블을 연계하는 것은 일반적으로 소규모 HTML 변경만 필요하며, 올바르게 구현하면 시각적 디자인에는 영향을 주지 않는다. Accsible의 오버레이 SDK를 사용하는 조직의 경우, 누락된 레이블의 자동 감지를 통해 정기 스캔 중 이러한 위반을 표면화할 수 있으며, 개발 팀이 규제 기한 전에 조치 가능한 수정 가이드를 확보하도록 도와준다.