WCAG 4.1.2: 이름, 역할, 값

WCAG 4.1.2는 모든 사용자 인터페이스 구성 요소가 프로그래밍 방식으로 결정 가능한 이름과 역할을 가져야 하며, 상태, 속성, 값이 보조 기술에 의해 읽고 설정될 수 있어야 한다고 요구합니다. 이는 스크린 리더와 기타 도구가 페이지의 모든 요소를 정확하게 식별하고, 설명하며, 상호작용할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 4.1.2 — Name, Role, Value는 견고성(Robust) 원칙 아래의 레벨 A 성공 기준입니다. 이 기준은 폼 요소, 버튼, 링크, 커스텀 위젯, 프레임, 인터랙티브 컨트롤을 포함한 모든 사용자 인터페이스 구성 요소에 대해 다음 세 가지가 모두 충족되어야 함을 요구합니다.

Name(이름): 각 구성 요소는 보조 기술이 음성으로 읽거나 점자 디스플레이를 통해 노출할 수 있는 접근 가능한 이름을 가져야 합니다. 이름은 요소 콘텐츠(예: <button> 안의 텍스트), label 요소, aria-label 속성, aria-labelledby 참조, 또는 title 속성에서 올 수 있습니다.
Role(역할): 각 구성 요소는 보조 기술에 자신의 목적을 전달하는 역할을 가져야 합니다. 기본 HTML 요소는 암묵적인 역할을 갖습니다(<button>은 button 역할, <input type='checkbox'>는 checkbox 역할). <div>나 <span> 같은 일반 요소로 만든 커스텀 위젯은 ARIA role 속성을 사용해 역할을 명시적으로 선언해야 합니다.
Value(값: 상태와 속성): 체크박스가 선택되었는지, 디스클로저 위젯이 펼쳐졌는지, 필드가 필수인지 등 사용자에게 의미 있는 현재 상태나 값은 모두 프로그래밍 방식으로 노출되어야 합니다. 그래야 보조 기술이 이를 보고할 수 있고, 적용 가능한 경우 사용자가 이를 변경할 수 있습니다.

구성 요소는 접근 가능한 이름이 비어 있지 않고, 역할이 유효하며 의미상 적절하고, 모든 관련 상태(예: aria-checked, aria-expanded, aria-required 등)가 올바르게 적용되어 시각적 UI와 동기화되어 있을 때 이 기준을 통과합니다. 세 요소 중 하나라도 없거나, 잘못되었거나, 동기화되지 않은 경우 구성 요소는 실패합니다. 예를 들어, 색상만 바뀌고 aria-pressed 상태는 전혀 업데이트되지 않는 커스텀 토글 버튼이 이에 해당합니다.

공식 WCAG 예외는 의도적으로 접근성 API에 노출하지 않는 구성 요소를 다룹니다. 예를 들어, 순수 장식 요소나 aria-hidden='true'로 숨긴 콘텐츠가 이에 해당합니다. 그러나 활성 또는 포커스 가능한 콘텐츠를 aria-hidden으로 숨기는 것(예: <body> 요소에 적용하는 것)은 그 자체로 위반입니다. 페이지의 모든 콘텐츠를 접근성 트리에서 제거하기 때문입니다.

왜 중요한가

세계보건기구(WHO)에 따르면 전 세계적으로 약 2.2 billion 명이 어떤 형태로든 시각 장애를 가지고 있습니다. JAWS, NVDA, VoiceOver 같은 스크린 리더에 의존하는 시각장애 및 저시력 사용자에게 각 인터랙티브 구성 요소의 접근 가능한 이름과 역할은 그 컨트롤이 무엇을 하는지, 어떻게 사용하는지를 이해하는 주요한 — 그리고 종종 유일한 — 수단입니다. 버튼에 접근 가능한 이름이 없으면 스크린 리더 사용자는 그 목적에 대한 설명 없이 단지 "button"이라는 안내만 듣게 됩니다. 커스텀 드롭다운에 역할이 없으면, 사용자는 그것을 정적인 텍스트와 구분할 수 없습니다.

스위치 액세스, Dragon NaturallySpeaking 같은 음성 제어 도구, 키보드 내비게이션을 통해 소프트웨어를 조작하는 운동 장애 사용자도 이 기준에 의존합니다. 음성 제어 소프트웨어는 말로 한 명령("Submit 클릭")을 접근 가능한 이름에 매핑합니다. 버튼의 접근 가능한 이름이 눈에 보이는 레이블과 일치하지 않으면 음성 명령은 완전히 실패합니다.

인지적 접근성도 마찬가지로 중요합니다. 일관되고 예측 가능한 레이블링은 난독증, 기억력 장애, 주의력 관련 장애가 있는 사용자의 인지적 부담을 줄여 줍니다. 모달이 열리거나 폼 필드가 필수가 되는 것과 같은 상태 변화가 보조 기술에 의해 안내되지 않으면, 사용자는 방향 감각을 잃고 작업을 완료하지 못할 수 있습니다.

구체적인 실제 시나리오를 생각해 봅시다. 한 터키 전자상거래 플랫폼이 클릭 핸들러와 장바구니 아이콘이 있는 <div>로 "Add to Cart" 버튼을 구현해 두었습니다. 시각적으로는 버튼처럼 보입니다. 하지만 role='button', 접근 가능한 이름, tabindex='0'가 모두 없기 때문에, 키보드로 탐색하는 스크린 리더 사용자는 아무것도 만나지 못합니다. 이 요소는 그들의 보조 기술에는 완전히 보이지 않는 것입니다. 그들은 장바구니에 상품을 담을 수 없고, 사실상 전체 쇼핑 경험에서 배제됩니다.

접근성을 넘어, 적절히 이름이 지정되고 구조화된 구성 요소는 SEO도 개선합니다. 검색 엔진 크롤러는 페이지 구조와 인터랙티브 의도를 이해하기 위해 시맨틱 마크업에 의존하기 때문입니다. 또한 자동화된 테스트 프레임워크가 의미 있는 역할과 레이블을 가진 요소를 더 신뢰성 있게 찾고 상호작용할 수 있으므로 테스트 가능성도 향상됩니다.

테스트 방법

axe DevTools 또는 Lighthouse를 사용한 자동 스캔: axe DevTools 브라우저 확장(Chrome 또는 Firefox)을 설치하거나 Chrome DevTools의 Accessibility 탭에서 Lighthouse 감사를 실행합니다. 전체 페이지 스캔을 실행하고 결과를 WCAG 4.1.2 태그로 필터링합니다. 특히 button-name, frame-title, aria-required-attr, aria-roles, aria-input-field-name 위반을 찾아보십시오. 각 발견 항목에는 문제 요소, 실패 설명, 제안된 수정 사항이 포함됩니다. 결과를 내보내고 Critical 및 Serious 심각도 항목을 우선적으로 처리하십시오.
키보드 내비게이션 테스트: 마우스를 분리하고 Tab 키만 사용해 전체 페이지를 탐색합니다. 모든 포커스 가능한 요소가 시각적으로 포커스를 받는지, 브라우저의 기본 포커스 표시(또는 커스텀 표시)가 명확히 보이는지, Enter 또는 Space로 모든 컨트롤을 활성화할 수 있는지 확인합니다. 화면을 보지 않고도 문맥만으로 식별할 수 없는 요소에 도달한다면, 접근 가능한 이름 실패 가능성이 높습니다.
NVDA와 Firefox를 사용한 스크린 리더 테스트: NVDA(Windows, 무료)를 실행하고 Firefox를 열어 Tab 키로 인터랙티브 요소를 이동하고 NVDA Elements List(Insert+F7)를 사용해 모든 버튼, 링크, 폼 필드를 탐색합니다. 각 인터랙티브 요소에 대해 NVDA가 무엇을 안내하는지 들어 보십시오. 요소의 이름, 역할, 관련 상태(예: "Subscribe, button" 또는 "Email address, required, edit text")를 읽어야 합니다. 이름 없이 안내되거나 잘못된 역할로 안내되는 요소는 모두 플래그하십시오.
VoiceOver와 Safari(macOS/iOS)를 사용한 스크린 리더 테스트: VoiceOver(Command+F5 on macOS)를 활성화하고 Safari를 열어 VO+Right Arrow로 요소를 탐색합니다. VoiceOver Rotor(VO+U)를 사용해 모든 폼 컨트롤과 버튼 목록을 확인합니다. 이름이 설명적인지, 역할이 적절한지, 상호작용 시 상태가 동적으로 업데이트되는지(예: 커스텀 아코디언을 토글하면 VoiceOver가 "expanded" 또는 "collapsed"를 안내하는지) 검증합니다.
JAWS와 Chrome을 사용한 스크린 리더 테스트: JAWS를 실행하고 Chrome을 엽니다. Tab 키로 인터랙티브 요소를 탐색하고 JAWS Virtual Cursor(폼 필드 목록은 Insert+F3)를 사용해 레이블을 검토합니다. ARIA로 구축된 커스텀 위젯에 특히 주의를 기울여, 키보드 상호작용으로 트리거된 상태 변화가 JAWS 안내에 실시간으로 반영되는지 확인합니다.
커스텀 위젯 상태 검증: 아코디언, 탭 패널, 콤보박스, 모달 같은 커스텀 위젯에 대해 키보드만 사용해 완전히 상호작용해 봅니다. 각 단계에서 스크린 리더가 올바른 상태 업데이트를 안내하는지 확인합니다. 예를 들어, 디스클로저 위젯을 열면 "expanded" 안내가, 닫으면 "collapsed" 안내가 나와야 합니다. 시각적 상태는 바뀌는데 스크린 리더가 조용하다면, aria-expanded가 없거나 프로그래밍 방식으로 토글되지 않고 있는 것입니다.

수정 방법

접근 가능한 이름이 없는 아이콘 전용 버튼 — 잘못된 예

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

접근 가능한 이름이 없는 아이콘 전용 버튼 — 올바른 예

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

역할과 상태가 없는 커스텀 토글 위젯 — 잘못된 예

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

역할과 상태가 없는 커스텀 토글 위젯 — 올바른 예

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

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

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

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

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

필수 ARIA 속성이 없는 커스텀 진행률 표시줄 — 잘못된 예

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

필수 ARIA 속성이 없는 커스텀 진행률 표시줄 — 올바른 예

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

자주 발생하는 실수

<div>에 role='button'을 사용하면서 tabindex='0'를 추가하지 않는 경우 — 스크린 리더에는 버튼으로 안내되지만 키보드 Tab 내비게이션으로는 도달할 수 없어 키보드 전용 사용자에게는 사용할 수 없습니다.
비인터랙티브 요소에 aria-label을 적용하는 경우 — 역할이 없는 <div>나 <span>에 aria-label을 추가해도 효과가 없습니다. 요소에 이름을 붙일 역할이 없기 때문에 대부분의 브라우저는 이 레이블을 무시합니다.
디스클로저 위젯을 구현한 후에도 aria-expanded를 정적으로 두는 경우 — HTML에서 aria-expanded='false'로 설정해 두고 JavaScript로 전혀 토글하지 않으면, 첫 클릭 이후 이 속성은 항상 잘못된 상태가 되어 스크린 리더 사용자에게 반대 상태를 안내하게 됩니다.
포커스 가능한 요소를 포함한 컨테이너에 aria-hidden='true'를 사용하는 경우 — 이 컨테이너는 접근성 트리에서는 숨겨지지만 키보드 포커스에서는 숨겨지지 않습니다. 그 결과 스크린 리더 사용자는 들을 수 없는 요소에 Tab으로 들어가게 되어 극심한 혼란을 겪습니다.
<input>의 유일한 레이블로 placeholder를 제공하는 경우 — placeholder 텍스트는 입력 시 사라지고, 모든 스크린 리더가 이를 레이블로 안정적으로 안내하지 않으며, 폼 필드의 접근 가능한 이름 요구 사항을 충족하지 못합니다.
role='widget'이나 role='structure' 같은 잘못된 또는 추상 ARIA 역할을 사용하는 경우 — 이는 ARIA 명세의 기본 역할로 직접 사용하도록 의도된 것이 아닙니다. 의미 있는 시맨틱 정보를 제공하지 못하며, 보조 기술에서 무시되거나 오류를 유발할 수 있습니다.
aria-labelledby에서 존재하지 않는 요소 ID를 참조하는 경우 — aria-labelledby가 가리키는 ID가 DOM에 존재하지 않으면 접근 가능한 이름 계산이 실패하고, 해당 요소는 이름 없이 남게 됩니다.
<input type='image'>에 aria-label 대신 value를 사용하는 경우 — 이미지 입력 버튼은 접근 가능한 이름을 위해 alt 속성이 필요합니다. 이미지 입력에서 이름 계산 시 value 속성은 무시됩니다.
서드파티 콘텐츠를 로드하는 <iframe> 요소에 title 속성을 생략하는 경우 — 개발자는 잘 알려진 임베드(지도, 결제 위젯, 비디오 플레이어)가 스스로 설명적이라고 가정하는 경우가 많지만, 스크린 리더 사용자는 프레임에 들어갈지 결정하기 전에 프레임의 목적을 안내받아야 합니다.
콘텐츠가 변경될 때 접근 가능한 이름을 동적으로 업데이트하는 것을 잊는 경우 — 버튼의 레이블이 시각적으로 "Play"에서 "Pause"로 바뀌었는데 aria-label은 여전히 "Play"로 남아 있으면, 스크린 리더 사용자는 현재 상태와 동작에 대해 잘못된 정보를 받게 됩니다.

터키 접근성 규정과의 관계

터키의 대통령령 2025/10은 2025년 6월 21일 관보(Official Gazette) 제 32933호에 게재되었으며, WCAG 2.2와 정렬된 의무적인 디지털 접근성 요구 사항을 수립합니다. WCAG 4.1.2 — Name, Role, Value는 레벨 A 기준으로, 가장 기본적인 적합성 단계에 해당합니다. 이 대통령령에 따라 레벨 A 적합성은 선택 사항이 아니라, 모든 적용 대상 기관이 달성해야 하는 최소 기준입니다.

이 대통령령은 터키에서 운영되는 광범위한 유형의 기관에 적용됩니다. 공공 기관 — 부처, 지방자치단체, 국가 기관을 포함 — 은 대통령령 공포일로부터 1년 이내에 적합성을 달성해야 합니다. 민간 부문 기관 — 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 민간 의료 제공자, 200,000명 이상의 가입자를 보유한 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받은 사립학교 — 는 2년 이내에 적합성을 달성해야 합니다.

WCAG 4.1.2는 많은 현대 터키 웹사이트가 제품 캐러셀, 아코디언 FAQ, 단계별 결제 플로우, 뱅킹 대시보드 같은 커스텀 인터랙티브 구성 요소에 크게 의존한다는 점에서 특히 중요합니다. 이들은 종종 적절한 ARIA 역할, 이름, 상태 관리 없이 구현됩니다. 접근 가능한 이름이 없는 커스텀 결제 버튼이나 aria-valuenow가 없는 대출 계산기 슬라이더는 단순히 사용자 경험이 나쁜 수준을 넘어, 대통령령 하에서는 법적 컴플라이언스 실패에 해당합니다.

대통령령의 적용을 받는 은행과 전자상거래 플랫폼의 경우, 결제 폼, 인증 모달, 계정 대시보드 같은 거래 핵심 플로우에서 발생하는 WCAG 4.1.2 위반은 특히 위험도가 높습니다. 적절한 ARIA 마크업이 없는, 시각적으로 스타일링된 커스텀 콤보박스(예: 은행 지점을 선택하는 용도)는 스크린 리더 사용자가 거래를 완전히 완료하지 못하게 만들 수 있으며, 이는 기관을 규제 조치와 차별 소송 모두에 노출시킬 수 있습니다.

Accsible overlay SDK를 사용하는 기관은 많은 Name, Role, Value 위반에 대해 자동 감지 및 런타임 수정의 이점을 누릴 수 있습니다. 여기에는 누락된 접근 가능한 이름 주입, 알려진 위젯 패턴에서 잘못된 ARIA 역할 수정, 인터랙티브 구성 요소의 상태 속성 동기화 등이 포함됩니다. 그러나 기관은 자동 오버레이 지원을, 특히 복잡한 커스텀 위젯의 경우에는, 애플리케이션 로직에 처음부터 프로그래밍 방식 상태 관리를 내장해야 한다는 점을 감안할 때, 올바른 시맨틱 HTML 개발을 대체하는 것이 아니라 보완하는 수단으로 취급해야 합니다.