WCAG 2.4.6: 제목과 레이블

WCAG 2.4.6은 제목과 레이블이 있을 경우, 그것들이 도입하거나 식별하는 콘텐츠의 주제나 목적을 설명적이고 정확하게 전달해야 한다고 요구합니다. 이 기준은 특히 보조 기술을 사용하는 사용자를 포함한 모든 사용자가 콘텐츠를 효율적으로 탐색하고, 페이지 섹션과 양식 필드의 구조와 목적을 이해하는 데 도움이 됩니다.

이 규칙의 의미

WCAG 2.4.6은 다음과 같이 규정한다. "머리글과 레이블은 주제나 목적을 설명해야 한다." 핵심적으로 이 기준은 페이지에 나타나는 모든 머리글(<h1>부터 <h6>까지)이나 레이블(<label>, aria-label, aria-labelledby)이, 소개하는 콘텐츠의 주제나 식별하는 컨트롤의 목적을 전달할 수 있을 만큼 충분히 설명적이어야 한다고 요구한다.

이 기준은 머리글이나 레이블이 반드시 존재해야 한다고 요구하는 것은 아니다. 그런 의무는 1.3.1(정보와 관계)이나 2.4.2(페이지 제목) 같은 다른 성공 기준에서 다룬다. 2.4.6이 규율하는 것은 이미 존재하는 머리글과 레이블의 품질이다. 즉, 머리글과 레이블이 있을 때에는 의미가 있어야 한다. "Section 1"이라고만 적힌 머리글이나 "Field"라고만 적힌 레이블은, 그 뒤에 오는 콘텐츠나 설명하는 입력값에 대해 사용자에게 유용한 정보를 전혀 제공하지 못한다. 반대로 "Your Shipping Address"나 "Monthly Budget Summary"와 같은 표현은 사용자가 즉시 방향을 잡을 수 있게 해 준다.

이 문맥에서 레이블에는 폼 컨트롤과 연결된 HTML <label> 요소뿐 아니라, 모든 프로그래밍 방식의 레이블링 메커니즘이 포함된다. 예를 들어 aria-label, aria-labelledby, 접근 가능한 이름으로 사용되는 title 속성, 그리고 fieldset에 대한 legend 요소 등이 있다. 이들 중 보조 기술에 노출되는 것은 모두, 연결된 컨트롤의 목적을 명확하게 설명해야 한다.

머리글이나 레이블이 너무 일반적이거나 모호하거나 정보가 부족해서, 사용자가 주변 문맥을 읽지 않고서는 해당 구역이나 컨트롤이 무엇에 관한 것인지 알 수 없는 경우 실패가 발생한다. 예를 들어, 세 개의 입력 필드가 모두 "Enter here"라는 레이블을 사용하는 폼은 이 기준을 충족하지 못하며, 모든 하위 섹션에 "More Info"와 같은 반복적인 머리글을 사용하는 페이지도 마찬가지다. 또한, DOM에는 머리글이 존재하지만 사용자에게 완전히 오해를 불러일으키는 경우 — 예를 들어 문의 양식 섹션에 "News and Updates"라는 머리글을 붙이는 경우 — 역시 실패에 해당한다.

여기에는 중요한 공식 예외가 하나 있다. WCAG 2.4.6은 머리글과 레이블이 사용될 때만 적용된다. 페이지에 정당하게 머리글이 전혀 없는 경우(예: 단일 주제를 다루는 매우 짧은 문서)나, 눈에 보이거나 프로그래밍 방식의 레이블이 전혀 없는 폼 컨트롤(이는 대신 1.3.1에서 문제로 잡힌다)이 있는 경우에는, 2.4.6 자체는 적용되지 않는다. 이 기준의 범위는 존재 여부가 아니라, 오로지 설명성에 관한 것이다.

왜 중요한가

설명적인 머리글과 레이블은 매우 폭넓은 사용자에게 이득을 주지만, 그 영향은 특히 구조에 의존해 탐색하는 장애인에게 가장 크다.

스크린 리더 사용자 — 주로 시각장애인이나 심각한 저시력 사용자 — 는 단축키(H: NVDA/JAWS, VoiceOver의 Rotor)를 사용해 머리글에서 머리글로 점프하며 페이지를 탐색하는 것이 일반적이다. 머리글이 모호하거나 오해를 부르는 경우, 이러한 탐색 전략은 완전히 무너진다. 예를 들어, "Section A", "Section B", "Section C"를 머리글로 사용하는 정부 서비스 포털에 접속한 시각장애인은, 필요한 정보를 찾기 위해 각 섹션의 모든 단어를 순차적으로 읽어야 하며, 이는 머리글이 제공해야 할 효율성 이점을 없애 버린다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있어, 이는 상당한 규모의 인구에 영향을 미친다.

주의력 결핍 장애, 기억력 손상, 학습 장애 등을 포함한 인지 장애가 있는 사람들은 인지적 부담을 줄이기 위해 명확하고 예측 가능한 레이블과 머리글에 크게 의존한다. 예를 들어, 회사 이름과 담당자 이름을 모두 수집하는 페이지에서 폼 필드가 단지 "Name"으로만 레이블링되어 있다면, 인지 장애가 있는 사용자는 문맥만으로 이 모호함을 해소하지 못해 오류와 좌절을 겪을 수 있다.

스위치 액세스, 시선 추적 소프트웨어, Dragon NaturallySpeaking과 같은 음성 제어에 의존하는 운동 장애 사용자는, 레이블이 설명적일수록 이득을 본다. 이들은 레이블 이름을 말함으로써 특정 폼 필드를 활성화할 수 있기 때문이다. 여러 필드가 동일한 레이블 텍스트를 공유하면, 음성 제어 소프트웨어는 이들을 구분할 수 없고, 사용자는 신체적으로 부담이 되는 추가 단계를 거쳐야 한다.

현실적인 시나리오를 생각해 보자. 스크린 리더를 사용하는 사람이 전자상거래 결제 페이지를 방문한다. 페이지에는 청구지 주소, 배송지 주소, 선물 수령인 주소 등 세 개의 주소 섹션이 있지만, 각 섹션은 모두 동일한 일반 머리글 "Address"를 사용하고, 각 입력 세트는 "Street", "City", "Postal Code"라는 동일한 레이블을 사용한다. 고유하고 설명적인 머리글과 레이블이 없다면, 스크린 리더 사용자는 자신이 어느 필드 그룹을 작성하고 있는지 알 수 없으며, 주문 오류의 위험이 크게 증가하고, 결국 구매를 완전히 포기할 가능성도 높아진다.

접근성을 넘어, 설명적인 머리글은 상당한 SEO 가치도 제공한다. 검색 엔진은 페이지 콘텐츠를 이해하고 사용자 쿼리와 매칭하기 위한 강력한 신호로 머리글 구조를 사용한다. 의미 있는 머리글은 검색 엔진이 페이지를 더 정확하게 색인하도록 돕고, 검색 결과에서 머리글이 미리보기 텍스트로 노출되는 경우 클릭률을 향상시킬 수 있다. 이는 비즈니스 인센티브를 접근성 요구사항과 직접적으로 정렬시킨다.

테스트 방법

먼저 자동 스캔 실행: axe DevTools(브라우저 확장)나 Chrome DevTools의 Lighthouse를 사용해, 누락된 레이블, 건너뛴 머리글 레벨, 비어 있는 머리글 요소 등 자동 도구가 잡을 수 있는 구조적 머리글 및 레이블 문제를 식별한다. 이들은 직접적인 2.4.6 위반은 아니지만, 수동 검토 시 더 주의 깊게 살펴봐야 할 영역을 나타낸다. 보고서에서 표시되거나 식별된 모든 머리글과 레이블이 있는 컨트롤을 기록한다.
머리글 목록 추출: HeadingsMap(Firefox 및 Chrome용)이나 WAVE와 같은 브라우저 확장을 사용해, 페이지의 모든 머리글을 주변 콘텐츠 없이 평면 목록으로 생성한다. 이 목록을 마치 목차처럼 읽어 본다. 본문 텍스트를 읽지 않고도, 머리글만으로 이 페이지의 구조와 주요 주제를 사용자가 이해할 수 있는지 자문해 본다. 어떤 머리글이든, 문맥 없이 보았을 때 모호하거나 정보가 부족하다면 2.4.6 실패이다.
NVDA와 Firefox로 테스트: 페이지를 열고 H 키를 눌러 머리글 단위로 탐색한다. 각 머리글이 어떻게 읽히는지 듣고, 뒤따르는 콘텐츠를 설명하는지 평가한다. 그런 다음 F 키를 눌러 폼 필드를 순환하며, 각 입력에 대해 읽히는 레이블을 듣는다. 주제나 목적을 명확히 설명하지 않는 머리글이나 레이블을 모두 기록한다.
VoiceOver와 Safari(macOS/iOS)로 테스트: Web Rotor(VO+U)를 사용해 Headings 목록과 Form Controls 목록을 연다. 각 목록을 탐색하며, 페이지 문맥과 독립적으로 각 항목의 설명성을 평가한다. iOS에서는 Rotor에서 머리글 단위로 탐색하기 위해 세 손가락 스와이프를 사용한다.
JAWS와 Chrome으로 테스트: H 키를 눌러 머리글을 탐색하고, Forms Mode(F)를 사용해 폼 컨트롤 사이를 이동한다. JAWS의 List of Headings 대화상자(Insert+F6)를 사용해 모든 머리글을 평면 목록으로 확인하는데, 이는 스크린 리더 사용자가 페이지 구조를 훑어보는 방식을 재현한다.
폼 레이블을 문맥 없이 평가: 각 폼 컨트롤에 대해, 주변 문맥을 모두 가리거나 무시하고, 프로그래밍 방식 레이블(눈에 보이는 레이블 텍스트, aria-label, aria-labelledby 대상)만 읽는다. 레이블만으로 어떤 정보를 입력해야 하는지, 또는 컨트롤이 어떤 동작을 수행하는지 이해할 수 있는지 확인한다.
중복된 머리글 또는 레이블 텍스트 확인: 페이지에서 반복되는 머리글 텍스트(예: 여러 개의 "Read More" 머리글이나 여러 개의 "Learn More" 섹션)를 검색한다. 동일한 텍스트가 서로 다른 주제나 컨트롤을 가리키는 머리글이나 레이블에 사용된다면, 이는 2.4.6의 실패이다.

수정 방법

일반적인 섹션 머리글 — 잘못된 예

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

일반적인 섹션 머리글 — 올바른 예

<!-- 이제 각 머리글이 섹션의 실제 주제를 설명하므로,
     스크린 리더 사용자가 필요한 부분으로 바로 이동할 수 있다 -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

모호한 폼 레이블 — 잘못된 예

<!-- 동일한 레이블을 사용하는 두 개의 주소 블록이 있는 체크아웃 폼 -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

모호한 폼 레이블 — 올바른 예

<!-- legend가 이제 두 fieldset을 구분해 주며;
     legend가 프로그래밍 방식으로 구분 문맥을 제공하므로 레이블은 짧게 유지할 수 있다 -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

아이콘 버튼에 비설명적인 ARIA 레이블 — 잘못된 예

<!-- aria-label이 레이블을 제공하지만 버튼의 목적을 설명하지는 않는다 -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

아이콘 버튼에 비설명적인 ARIA 레이블 — 올바른 예

<!-- aria-label이 이제 버튼을 활성화했을 때 무엇을 하는지 명확히 전달한다 -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

반복되는 "Read More" 머리글 또는 링크 — 잘못된 예

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

반복되는 "Read More" 머리글 또는 링크 — 올바른 예

<!-- 각 article은 주제를 식별하는 고유하고 설명적인 머리글을 가진다 -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

자주 발생하는 실수

"Step 1", "Step 2", "Section A"와 같은 위치나 순서를 나타내는 머리글만 사용하고 설명 텍스트를 추가하지 않는 것: 이런 머리글은 사용자가 순서상 어디에 있는지만 알려 줄 뿐, 섹션이 무엇에 관한 것인지는 알려 주지 않는다. 항상 "Step 2: Verify Your Email Address"와 같이 순서 표시와 설명적인 명사구를 함께 사용해야 한다.
목록 페이지의 모든 카드나 article 컴포넌트에 동일한 머리글 텍스트를 사용하는 것(예: 모든 상품 카드의 <h3>가 "Product"라고만 되어 있는 경우): 각 카드의 머리글은 해당 상품, 블로그 글, 항목을 고유하게 식별해야 한다.
폼 입력의 접근 가능한 레이블로 플레이스홀더 텍스트를 사용하는 것(<label> 요소나 aria-label 대신 placeholder 속성에 의존하는 경우): 플레이스홀더는 입력 시 사라지며, 모든 스크린 리더가 접근 가능한 이름으로 안정적으로 읽어 주는 것도 아니다. 플레이스홀더가 있더라도 별도의 설명적인 레이블이 필요하다.
요소 유형만을 반복하는 aria-label을 작성하는 것(예: 텍스트 필드에 aria-label='input', 버튼에 aria-label='button'을 사용하는 경우): 레이블은 요소의 종류가 아니라, 컨트롤이 수행하는 동작이나 수집하는 값을 설명해야 한다.
툴팁 텍스트나 title 속성을 폼 컨트롤의 유일한 레이블로 사용하고 이것이 2.4.6을 충족한다고 가정하는 것: title 기반 레이블은 키보드만 사용하는 사용자에게 종종 접근할 수 없고, 스크린 리더가 일관되게 읽어 주지도 않는다. 대신 눈에 보이는 <label> 요소나 aria-label에 의존해야 한다.
여러 검색 범위가 있는 페이지에서 검색 입력을 단지 "Search"라고만 레이블링하는 것(예: 사이트 전체 검색과 데이터 테이블 내 검색이 모두 있는 경우): 두 컨트롤이 서로 다른 검색을 수행한다면, 각 레이블은 "Search all products", "Search within order history"처럼 범위를 명시해야 한다.
모달 대화 상자의 머리글에 페이지의 메인 머리글과 동일한 텍스트를 사용하는 것: 모달 머리글은 "Confirm Your Cancellation"처럼 대화 상자의 구체적인 작업이나 콘텐츠를 설명해야 하며, 모달 내에서 탐색하는 스크린 리더 사용자에게 혼란을 주는 페이지 제목을 그대로 가져와서는 안 된다.
라디오 버튼이나 체크박스 그룹에 설명적인 <legend>를 생략하고 개별 옵션 레이블만 제공하는 것: <legend>는 각 개별 레이블을 의미 있게 만드는 필수 문맥을 제공한다. "Yes"와 "No"는 "Do you agree to the terms and conditions?"와 같은 legend 없이 단독 옵션 레이블로는 정보가 부족하다.
시각적 디자인을 이유로 DOM에서 머리글 텍스트를 잘라내는 것(예: 전체 텍스트는 인접한 시각 요소에 있고, 머리글에는 아이콘이나 한 단어만 넣는 경우): 스크린 리더 사용자는 주변 시각 레이아웃을 보지 못한 채 머리글만 듣기 때문에, 프로그래밍 방식 머리글은 완전히 설명적이어야 한다.
레이블이 시각 사용자에게 보인다는 이유만으로 모든 사용자에게 충분히 설명적이라고 가정하는 것: 위치 관계에 의존하는 레이블(예: 의미가 주변 셀과의 관계에 달려 있는 커스텀 그리드의 열 머리글)은 시각적으로는 명확할 수 있지만, 같은 정보를 프로그래밍 방식으로 전달하지 못할 수 있다. 접근 가능한 이름만으로도 충분한지 항상 확인해야 한다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보(Official Gazette) 제32933호에 게재되었으며, 터키에서 운영되는 광범위한 공공 및 민간 기관에 대해 의무적인 디지털 접근성 의무를 설정한다. 이 대통령령은 적합성의 기술 표준으로 WCAG 2.1 AA 레벨을 명시적으로 참조하며, WCAG 2.2의 AA 레벨 요구사항 — WCAG 2.1 AA 레벨과 하위 호환 — 은 공식적인 접근성 로고(Erişilebilirlik Logosu)를 취득하려는 기관에 대해 강력히 권장되며 사실상 요구된다. 이 로고는 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급한다.

WCAG 2.4.6은 AA 레벨 기준으로, 이는 해당 기관들이 완전한 적합성을 달성하기 위해 반드시 다루어야 하는 범위에 정확히 포함된다는 의미다. 대통령령이 적용되는 기관 유형에는 공공 기관 및 정부 부처, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 서비스 제공자, 가입자 200,000명 이상인 통신 사업자, 여행사, 민간 운송 회사, 그리고 교육부(Millî Eğitim Bakanlığı)의 인가를 받은 사립 학교 등이 포함된다.

이들 기관의 경우, 설명적인 머리글과 레이블을 제공하지 않는 것은 구체적인 규제 리스크를 수반한다. 모호한 섹션 머리글을 가진 정부 포털은 장애가 있는 시민이 공공 서비스에 접근하는 것을 방해하며, 이는 평등한 접근을 보장한다는 대통령령의 명시적 목표와 직접적으로 충돌한다. 결제 흐름에서 모호한 폼 레이블을 사용하는 전자상거래 사이트는 시각 또는 인지 장애가 있는 사용자가 구매를 완료하지 못하게 만들 수 있으며, 이는 대통령령이 제거하고자 하는 경제 활동 참여 장벽에 해당한다.

Erişilebilirlik Logosu를 취득하려는 기관은 접근성 감사를 통해 적합성을 입증해야 하며, 2.4.6은 감사자가 수동으로 평가하는 기준 중 하나이다. 이 기준은 사람의 판단을 필요로 하며 — 자동 도구는 설명성을 평가할 수 없다 —, 조직은 모든 머리글과 폼 레이블에 대한 구조화된 수동 검토를 접근성 감사 프로세스의 표준 일부로 포함해야 한다. 이를 일회성 감사 작업이 아니라, 콘텐츠가 시간이 지나며 변경될 때도 지속적인 준수를 유지하기 위한 가장 효과적인 전략으로, 콘텐츠 관리 워크플로와 디자인 시스템에 내재화하는 것이 바람직하다.