WCAG 3.2.4: 일관된 식별

WCAG 3.2.4는 웹사이트 전반에서 동일한 기능을 수행하는 구성 요소가 나타날 때마다 동일한 레이블, 이름 또는 대체 텍스트를 사용하여 일관되게 식별할 것을 요구합니다. 이는 일관된 패턴에 의존해 디지털 인터페이스를 탐색하고 이해하는 사용자들이 혼란을 겪지 않도록 하기 위한 것입니다.

이 규칙의 의미

WCAG 성공 기준 3.2.4 — 일관된 식별(Consistent Identification) — 은 하나의 웹 페이지 집합 내에서 동일한 기능을 가진 구성 요소는 일관되게 식별되어야 한다고 규정한다. 이는 어떤 대화형 요소나 이미지가 동일한 기능을 수행할 때, 사이트 전반에서 나타날 때마다 동일한 접근 가능한 이름 또는 레이블을 가져야 한다는 뜻이다.

이 문맥에서 "식별(identified)"이라는 용어는 구성 요소가 보조 기술과 사용자에게 어떻게 제시되는지를 의미한다. 여기에는 눈에 보이는 레이블 텍스트, aria-label 또는 aria-labelledby 속성, 이미지의 alt 텍스트, title 속성, 그리고 브라우저의 접근성 트리가 계산한 접근 가능한 이름이 포함된다. 예를 들어 검색 버튼이 사이트의 모든 페이지에 나타난다면, 항상 "Search"라고 불러야 한다. 홈페이지에서는 "Search", 상품 목록 페이지에서는 "Find", 결제 페이지에서는 "Go"라고 부르는 식으로 달라져서는 안 된다.

이 기준은 WCAG가 동일한 목적을 공유하고 동일한 작성자가 만든 페이지 모음으로 정의하는 웹 페이지 집합에 적용된다. 이는 전체 웹사이트, 웹 애플리케이션, 여러 개의 URL에 걸친 다단계 양식을 모두 포함한다. 단지 시각적으로만 비슷하고 기능은 다른 구성 요소는 같은 이름을 공유할 필요가 없다. 이 요구 사항은 오직 기능이 동일한 경우에만 적용된다.

충족으로 인정되는 경우: 햄버거 메뉴를 여는 내비게이션 아이콘이 모든 페이지에서 일관되게 "Open navigation menu"(또는 동등한 표현)로 레이블링되어 있다. 쇼핑 카트 아이콘은 항상 "Shopping cart"라는 alt 텍스트 또는 접근 가능한 이름을 가진다. 로그아웃 버튼은 항상 "Log out"으로 레이블링된다. 동일한 기능에 대해 문구가 달라지는 것은 실패에 해당한다.

실패로 인정되는 경우: 회원가입 양식에서는 "Submit"으로 레이블링된 제출 버튼이, 문의 양식에서는 동일하게 사용자가 입력한 데이터를 전송하는 기능을 수행하면서 "Send"로 레이블링되어 있는 경우. 돋보기 아이콘 버튼이 대부분의 페이지에서는 "Search"로 레이블링되어 있지만, 번역된 하위 페이지 중 한 곳에서만 일관된 언어 전략 없이 "Ara"로 레이블링되어 있는 경우.

공식 예외: WCAG는 동일한 접근 가능한 이름을 가지지만 서로 다른 기능을 수행하는 두 구성 요소가 존재하는 것은 허용된다고 명시한다. 이 경우에는 기능의 차이 자체가 두 요소를 구분해 준다. 이 기준은 기능은 동일하지만 이름이 일관되지 않을 때만 위반으로 간주된다.

왜 중요한가

일관되지 않은 식별은 비시각적 또는 패턴 기반 탐색 전략에 의존하는 사용자에게 과도한 부담을 준다. 가장 심각한 영향을 받는 집단은 스크린 리더 사용자, 인지 장애가 있는 사용자, 그리고 음성 제어 소프트웨어에 의존하는 운동 장애 사용자들이다.

스크린 리더 사용자는 탭으로 이동하거나 랜드마크 단위로 탐색하면서 요소 이름을 들으며 웹사이트의 정신적 모델을 구축한다. 이전 페이지에서 동일한 기능을 수행하던 버튼이 다음 페이지에서는 다른 이름을 갖게 되면, 사용자는 멈춰서 조사하고 다시 방향을 잡아야 한다. 이는 시간도 많이 들고 좌절감을 주는 경험이다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있다. 그 중 일부만이라도 일관되지 않게 레이블링된 사이트를 이용하게 되면 상당한 장벽에 부딪히게 된다.

인지 장애가 있는 사용자, 예를 들어 난독증, 주의력 결핍 장애, 기억력 장애가 있는 사용자는 인지 부하를 줄이기 위해 예측 가능한 명명 규칙에 크게 의존한다. 익숙한 아이콘이나 컨트롤이 다른 이름으로 나타나면 다시 학습해야 하고 불안을 유발한다. 일관된 레이블링은 사이트를 반복적으로 사용할 때 절차적 기억을 형성하는 데 필요한 노력을 줄여 준다.

음성 제어 사용자(Dragon NaturallySpeaking이나 Apple의 Voice Control 같은 도구 사용)는 컨트롤의 이름을 말해 그것을 활성화한다. 버튼의 접근 가능한 이름이 사이트에서의 이전 경험을 바탕으로 기대하는 것과 다르면, 그들의 음성 명령은 조용히 실패한다. 소프트웨어가 일치하는 항목을 찾지 못하기 때문이다. 이 순간 인터페이스는 사실상 사용 불가능해진다.

구체적인 실제 시나리오: 의류를 판매하는 터키의 한 전자상거래 플랫폼을 생각해 보자. 상품 그리드 페이지에서 각 상품에는 하트 아이콘이 있는 버튼이 있고, 그 접근 가능한 이름은 "Add to favourites"이다. 상품 상세 페이지에서는 같은 하트 아이콘의 접근 가능한 이름이 "Kaydet"(터키어로 "저장")이다. 그리드 페이지에서 하트 버튼을 이름으로 호출하는 방법을 학습한 스크린 리더 사용자는, 상세 페이지에서 동일한 컨트롤을 찾기 위해 샅샅이 탐색하지 않는 이상 찾을 수 없다. 결국 사이트를 완전히 떠날 수도 있다.

접근성을 넘어, 일관된 레이블링은 SEO에도 도움이 된다. 검색 엔진은 접근 가능한 이름과 링크 텍스트를 분석해 페이지 내용을 이해한다. 기능적으로 동일한 링크에 대해 일관되지 않은 레이블링(예: 모두 기사 상세 페이지로 이동하지만 "Read more", "Continue reading", "Learn more"처럼 제각각인 경우)은 키워드 신호를 희석시키고 크롤러가 사이트 구조를 이해하기 어렵게 만든다.

테스트 방법

자동 사전 스캔: 각 페이지에서 axe DevTools 또는 Lighthouse를 실행해 (image-alt, button-name, link-name 등) 접근 가능한 이름 누락과 같은 관련 위반 사항을 찾아낸다. 먼저 이를 해결해야 한다. 이름이 없으면 이름의 일관성을 평가할 수 없기 때문이다. 스캔 결과에서 반복되는 구성 요소에 대해 보고된 접근 가능한 이름을 기록해 둔다.
구성 요소 인벤토리 작성: 페이지 전반에 반복되는 모든 기능적 구성 요소 — 내비게이션 메뉴, 검색 입력, 제출 버튼, 아이콘 버튼, 브레드크럼 링크, 소셜 미디어 링크, 인쇄/공유 버튼, 페이지네이션 컨트롤 — 를 수동으로 나열한다. 브라우저의 접근성 패널(Chrome DevTools > Elements > Accessibility 또는 Firefox Accessibility Inspector)을 사용해 각 인스턴스의 접근 가능한 이름을 기록한다.
페이지 간 이름 비교: 인벤토리에 있는 각 구성 요소 유형에 대해, 모든 인스턴스가 동일한 접근 가능한 이름을 가지고 있는지 확인한다. 불일치는 모두 표시한다. 특히 헤더, 푸터, 사이드바에 나타나는 구성 요소에 주의를 기울이는데, 이들은 템플릿 간에 레이블이 일관되지 않을 가능성이 가장 크다.
NVDA + Firefox로 스크린 리더 테스트: 홈페이지로 이동한 뒤, NVDA의 요소 목록(Insert + F7)을 사용해 버튼 및 링크 목록을 연다. 반복되는 컨트롤의 이름을 기록한다. 그런 다음 대표적인 다른 페이지 세네 곳으로 이동해 같은 작업을 반복한다. 기능적으로 동일한 컨트롤에서 이름이 달라지는지 귀로 확인한다.
VoiceOver + Safari(macOS/iOS)로 스크린 리더 테스트: 각 페이지에서 Rotor(VO + U)를 사용해 버튼 또는 링크 목록을 연다. 반복되는 요소의 이름을 비교한다. iOS에서는 동등한 페이지에서 대화형 요소를 쓸어 넘기며 탐색하고, 이름의 차이가 있는지 기록한다.
JAWS + Chrome으로 스크린 리더 테스트: 여러 페이지에서 JAWS 가상 커서와 폼 필드 목록(Insert + F5), 링크 목록(Insert + F7)을 사용한다. 동일한 컨트롤이 사이트 전체에서 동일한 이름을 공유하는지 확인한다.
음성 제어 테스트: Windows Voice Access 또는 Dragon NaturallySpeaking을 사용해 한 페이지에서 반복되는 컨트롤의 이름(예: "Click Search")을 말한다. 다른 페이지로 이동해 같은 명령을 말한다. 실패한다면, 기능적 관점에서 이름이 일관되지 않은 것이다.

해결 방법

레이블이 일관되지 않은 검색 버튼 — 잘못된 예

<!-- Homepage -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Product listing page -->
<button type='submit' aria-label='Find products'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Blog page -->
<button type='submit' aria-label='Go'>
  <svg aria-hidden='true'>...</svg>
</button>

레이블이 일관된 검색 버튼 — 올바른 예

<!-- Homepage, product listing page, and blog page all use the same label -->
<!-- Consistent aria-label across all pages ensures assistive technologies
     always announce the same name for this functionally identical button -->
<button type='submit' aria-label='Search'>
  <svg aria-hidden='true'>...</svg>
</button>

동일한 동작에 사용되는 아이콘 이미지의 alt 텍스트가 다른 경우 — 잘못된 예

<!-- Order history page -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print order' />
</a>

<!-- Invoice page -->
<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print this document' />
</a>

<!-- Receipt page -->
<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Yazdir' />
</a>

동일한 동작에 사용되는 아이콘 이미지의 alt 텍스트가 일관된 경우 — 올바른 예

<!-- All print links across the site share the same alt text.
     The destination URL differentiates which document is printed;
     the control's accessible name remains consistent. -->
<a href='/print/order/123'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/invoice/456'>
  <img src='/icons/print.svg' alt='Print' />
</a>

<a href='/print/receipt/789'>
  <img src='/icons/print.svg' alt='Print' />
</a>

내비게이션 닫기 버튼 이름이 일관되지 않은 경우 — 잘못된 예

<!-- Mobile menu on homepage -->
<button aria-label='Close menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

<!-- Mobile menu on product page (different developer implemented it) -->
<button aria-label='Dismiss navigation' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

내비게이션 닫기 버튼 이름이 일관된 경우 — 올바른 예

<!-- A shared component/template ensures the label is identical everywhere.
     Using a single reusable component or design token for the label
     eliminates the risk of developer-introduced inconsistencies. -->
<button aria-label='Close navigation menu' aria-expanded='true' aria-controls='nav-menu'>
  <svg aria-hidden='true'>...</svg>
</button>

이름이 제각각인 소셜 공유 링크 — 잘못된 예

<!-- Article page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

<!-- Video page -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Tweet this'>
  <svg aria-hidden='true'>...</svg>
</a>

이름이 일관된 소셜 공유 링크 — 올바른 예

<!-- Both pages use the same accessible name for the functionally
     identical sharing action. The URL parameter carries the context;
     the control name stays uniform. -->
<a href='https://twitter.com/intent/tweet?url=...' aria-label='Share on Twitter'>
  <svg aria-hidden='true'>...</svg>
</a>

자주 발생하는 실수

동일한 구성 요소에 대해 서로 다른 템플릿에서 다른 aria-label 값을 사용하는 경우: 공용 구성 요소 라이브러리 없이 서로 다른 개발자가 페이지 템플릿을 독립적으로 만들면, 닫기, 검색, 카트와 같은 아이콘 버튼에 임의의 레이블이 붙는 경우가 잦다. 반복되는 모든 대화형 요소에 대해 디자인 시스템 토큰이나 공용 구성 요소를 마련해, 접근 가능한 이름을 한 번만 정의하고 어디서나 재사용하도록 해야 한다.
다국어 페이지에서 접근 가능한 이름을 일관되지 않게 번역하는 경우: 사이트가 영어에서는 검색 버튼을 "Search"로 올바르게 레이블링하면서, 터키어 번역에서는 페이지 템플릿이 먼저 현지화된 순서에 따라 어떤 곳은 "Ara", 어떤 곳은 "Arama Yap"을 사용하는 식으로 일관성이 없을 수 있다. 구성 요소 레이블마다 단일 번역 키를 유지하고, 모든 로케일 파일에 이를 강제해야 한다.
기능은 동일한 컨트롤에 맥락별 접미사를 덧붙이는 경우: 핵심 기능(장바구니에 담기)은 동일한데 버튼을 "Add to cart — Blue T-Shirt", "Add to cart — Red Dress"처럼 레이블링하는 것은 자동으로 3.2.4 위반은 아니다. WCAG는 구분을 허용하기 때문이다. 하지만 어떤 곳에서는 접미사를 쓰고, 어떤 곳에서는 쓰지 않는 식으로 일관성이 없으면 혼란을 야기한다. 하나의 패턴을 선택해 일관되게 적용해야 한다.
가시 텍스트 레이블만 일관되면 된다고 보고, 서로 다른 aria-label 재정의를 사용하는 경우: 버튼에 보이는 텍스트는 "Search"로 동일하지만, 한 템플릿에서는 aria-label='Search the site'를 추가하고 다른 템플릿에서는 aria-label을 사용하지 않아(접근 가능한 이름이 가시 텍스트에서만 파생되도록) 스크린 리더가 서로 다른 이름을 읽게 되는 경우가 있다. 버튼이 동일해 보이더라도 전체 접근 가능한 이름 계산을 감사해야지, 눈에 보이는 레이블만 봐서는 안 된다.
CMS 편집자가 접근성 거버넌스 없이 버튼 텍스트를 자유롭게 바꾸도록 두는 경우: 버튼 레이블을 편집 가능한 필드로 노출하는 콘텐츠 관리 시스템에서는, 편집자가 개인적 선호에 따라 "Submit"을 "Send"나 "Gönder"로 바꾸는 일이 발생할 수 있다. 기능적 UI 구성 요소의 레이블 편집을 제한하거나, 제안된 레이블이 기존 표준에서 벗어날 때 경고하는 검증을 추가해야 한다.
서드파티 위젯이나 임베디드 구성 요소를 감사하지 않는 경우: 서드파티가 삽입한 채팅 위젯, 쿠키 동의 배너, 결제 iframe 등에는 호스트 사이트의 규칙과 다르게 레이블링된 버튼이 자주 포함된다. 가능한 경우 서드파티의 접근 가능한 이름을 검토하고 설정해, 사이트의 명명 규칙과 일치하도록 하거나, 그렇지 못할 경우 알려진 예외로 문서화해야 한다.
일부 인스턴스에서는 툴팁 텍스트(title 속성)를 유일한 접근 가능한 이름으로 사용하고, 다른 인스턴스에서는 aria-label을 사용하는 경우: title 속성은 모든 보조 기술에서 신뢰성 있게 읽히지 않으며, 약한 접근 가능한 이름 소스로 간주된다. 반복되는 구성 요소의 일부 인스턴스는 title을, 다른 인스턴스는 aria-label을 사용하면, 브라우저와 스크린 리더의 처리 차이로 인해 계산된 이름이 달라질 수 있다.
페이지 번호가 다르다는 이유로 페이지네이션 컨트롤이 예외라고 가정하는 경우: "Next page"와 "Previous page" 컨트롤은 레이블에 페이지 번호(예: "Go to page 3")가 포함되더라도 일관된 패턴을 적용해야 한다. 동일한 페이지네이션 컨트롤에 대해 어떤 페이지에서는 "Next", 다른 페이지에서는 "Next page" 또는 "İleri"를 사용하는 식으로 섞어 쓰면 3.2.4 위반이다.
모든 개별 페이지 템플릿에서 헤더와 푸터 구성 요소를 테스트하지 않는 경우: 사이트에는 보통 여러 페이지 템플릿(홈페이지, 카테고리 페이지, 기사 페이지, 체크아웃)이 있다. 헤더와 푸터 구성 요소는 템플릿마다 약간씩 다르게 렌더링될 수 있다. 한두 개 템플릿만 검사하는 테스터는 템플릿별 오버라이드로 인해 발생한 불일치를 놓치기 쉽다.
3.2.4를 3.2.3(일관된 내비게이션)과 혼동하는 경우: 팀은 내비게이션 순서가 일관되면(3.2.3) 이름도 일관될 것이라고 생각하는 경우가 있지만, 이는 별개의 요구 사항이다. 모든 페이지에서 같은 위치에 있는 내비게이션 바(3.2.3 준수)는, 링크가 페이지마다 다르게 레이블링되어 있다면 여전히 3.2.4를 위반할 수 있다. QA 프로세스에서 두 기준을 모두 명시적으로 다루어야 한다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 광범위한 공공 및 민간 디지털 서비스에 대해 구속력 있는 접근성 요구 사항을 수립한다. 이 대통령령은 국제적으로 인정된 접근성 표준 준수를 의무화하며 — 실질적으로 WCAG 2.2 레벨 AA와의 정렬을 의미 — 이를 가족·사회서비스부(Aile ve Sosyal Hizmetler Bakanlığı)가 발급하는 접근성 로고(Erişilebilirlik Logosu)와 연계한다.

WCAG 3.2.4 일관된 식별은 레벨 AA 기준으로, Erişilebilirlik Logosu를 취득하거나 유지하려는 조직에 필수적인 요구 사항이며 단순 권고 사항이 아니다. 디지털 서비스 전반에서 일관된 식별을 구현하지 못하면 완전한 AA 준수가 불가능해지고, 그 결과 로고 자격을 얻을 수 없다.

이 대통령령은 다음과 같은 유형의 기관을 명시적으로 포함하며, 이들 모두는 웹 및 모바일 인터페이스에서 WCAG 3.2.4를 준수해야 한다. 공공 기관 및 정부 부처, 은행 및 금융 서비스 제공자, 병원 및 헬스케어 플랫폼, 가입자 200,000명 이상인 통신 사업자, 전자상거래 플랫폼, 여행사 및 예약 서비스, 민간 운송 회사, 그리고 교육부(Milli Eğitim Bakanlığı) 인가를 받은 사립학교 등이 이에 해당한다.

이들 조직에 대한 실질적 함의는 크다. 은행의 인터넷 뱅킹 포털, 병원의 진료 예약 시스템, 대학의 학생 정보 시스템과 같은 대형 기관 웹사이트는 보통 수백 개의 페이지로 구성되며, 여러 개발 팀이 수년에 걸쳐 구축한다. 이러한 페이지 전반에서 반복되는 컨트롤(계정 관련 버튼, 검색 바, 내비게이션 아이콘)의 레이블이 일관되지 않은 것은 흔하면서도 쉽게 간과되는 실패 유형이다. 컴플라이언스 프로그램에는 단일 페이지 자동 스캔만이 아니라, 페이지 간 일관성 감사를 별도의 테스트 단계로 포함해야 한다.

Erişilebilirlik Logosu를 추구하는 터키 조직은 WCAG 3.2.4 점검을 디자인 시스템 거버넌스, 콘텐츠 관리 워크플로, QA 파이프라인에 통합해야 한다. 특히 모든 재사용 가능한 UI 구성 요소는 디자인 시스템 수준에서 접근 가능한 이름을 수정 불가능한 상수로 정의하고, 번역 키를 중앙에서 관리해, 해당 구성 요소가 나타나는 모든 페이지와 템플릿에서 터키어 및 기타 언어 변형이 일관되도록 해야 한다.