WCAG 1.3.6: 목적 식별

이 규칙의 의미

\n

WCAG 1.3.6 — Identify Purpose는 원칙 1(지각 가능, Perceivable) 아래의 AAA 레벨 기준으로, 기존의 구조와 시맨틱 요구 사항을 더 세밀한 수준으로 확장한 것이다. 구체적으로, 각 사용자 인터페이스 구성 요소, 아이콘, 영역, 그리고 특정 입력 필드의 목적이 프로그래밍 방식으로 결정될 수 있어야 한다는 것을 요구한다. 이는 시맨틱 정보가 브라우저, 브라우저 확장 기능, 보조 기술이 읽고 이에 따라 동작할 수 있는 방식으로 노출되어야 함을 의미한다.

\n

이 기준은 1.3.1(정보와 관계, Info and Relationships)과 1.3.5(입력 목적 식별, Identify Input Purpose)를 직접적으로 기반으로 한다. 1.3.5가 이름, 이메일, 전화번호 등과 같은 일반적인 개인 정보 입력 필드에 초점을 맞추는 반면, 1.3.6은 요구 사항을 내비게이션 랜드마크, 아이콘, 버튼, 인터랙티브 위젯을 포함한 모든 사용자 인터페이스 영역과 구성 요소로 확장한다. 핵심 아이디어는 사용자 에이전트나 개인화 도구가 마크업에 내장된 기계가 읽을 수 있는 목적 데이터에 기반해 기본 표현을 교체할 수 있어야 한다는 것이다. 예를 들어 텍스트 레이블을 기호로 대체하거나, 복잡한 내비게이션을 단순화하거나, 가장 관련성이 높은 컨트롤을 강조 표시하는 식이다.

\n

실질적으로, 페이지가 1.3.6을 준수하려면 HTML5 랜드마크 요소(<header>, <nav>, <main>, <aside>, <footer>, <section> 등)를 사용하고, 랜드마크 요소를 사용하지 않는 경우 적절한 ARIA 랜드마크 역할을 적용하며, 아이콘 및 기타 비텍스트 UI 구성 요소의 목적을 접근 가능한 이름이나 역할을 통해 노출하고, 해당되는 경우 W3C Personalization Semantics 명세(이전 COGA Semantics 제안)에서 정의한 것과 같은 표준화된 목적 토큰을 사용해야 한다. 예를 들어 aui- 속성 어휘를 통해 사용할 수 있다.

\n

페이지는 영역이 시맨틱 역할 없이 일반적인 <div> 또는 <span> 컨테이너로 구현되어 있거나, 아이콘이 의미를 담고 있지만 접근 가능한 이름이나 지원 시맨틱이 없거나, 인터랙티브 구성 요소가 눈에 보이는 외형 외에는 기능에 대한 프로그래밍 가능한 단서를 제공하지 않을 때 실패한다. 공식적인 예외도 있다. 이 요구 사항은 예상되는 의미를 식별하는 것을 지원하는 기술을 사용해 구현된 콘텐츠에만 적용된다. 특정 기술 스택에서 특정 구성 요소 유형에 대해 이를 지원하는 기술이나 명세가 존재하지 않는다면, 이 기준을 그 구성 요소에 합리적으로 적용할 수 없다.

\n\n

왜 중요한가

\n

WCAG 1.3.6의 주요 수혜자는 난독증, 주의력 결핍 장애, 자폐 스펙트럼 상태, 기억력 손상, 지적 장애 등을 포함한 인지 및 학습 장애가 있는 사람들이다. 세계보건기구(WHO)에 따르면 전 세계 인구 약 6명 중 1명, 즉 10억 명이 넘는 사람이 어떤 형태로든 중대한 장애를 가지고 있으며, 인지 장애는 가장 크고 가장 충분히 지원받지 못하는 집단 중 하나를 이룬다. 이들 사용자 중 상당수는 복잡한 내비게이션 구조, 빽빽한 텍스트 메뉴, 시맨틱 기준점이 없는 아이콘 전용 컨트롤을 사용하는 데 어려움을 겪는다.

\n

구체적인 상황을 생각해 보자. 심한 난독증이 있는 사용자가 표준 내비게이션 레이블을 일상에서 사용하는 의사소통 보드의 그림 기반 아이콘과 같은 개인 심볼 세트로 대체해 주는 브라우저 확장 기능에 의존한다고 하자. 이러한 대체가 작동하려면, 확장 기능은 특정 <div>가 실제로 내비게이션 랜드마크인지, 별 모양 아이콘이 “즐겨찾기에 추가”를 의미하는지, 원형 화살표가 “새로 고침”을 의미하는지 등을 파악할 수 있어야 한다. 목적을 프로그래밍 방식으로 결정할 수 없다면, 확장 기능은 연결 고리를 찾지 못하고 대체는 조용히 실패하여, 사용자가 해석할 수 없는 인터페이스만 남게 된다.

\n

스위치 액세스나 음성 제어 도구에 의존하는 운동 장애 사용자도 큰 혜택을 본다. 목적을 인식하는 도구는 기능이 기계가 읽을 수 있는 컨트롤에 대해서만 단축키 오버레이나 음성 명령 매핑을 생성할 수 있기 때문이다. 스크린 리더를 통해 상호작용하는 시각장애 사용자는 명확하게 레이블이 지정된 랜드마크 영역 덕분에 <main> 콘텐츠로 바로 이동하거나 반복되는 내비게이션을 건너뛸 수 있다. 브라우저 확대나 사용자 정의 스타일시트를 사용하는 저시력 사용자는 랜드마크 구조 덕분에 브라우저가 콘텐츠를 예측 가능하게 리플로우할 수 있어 이점을 얻는다.

\n

접근성을 넘어, 1.3.6이 요구하는 시맨틱을 구현하면 측정 가능한 SEO 이점도 얻을 수 있다. 검색 엔진 크롤러는 랜드마크와 스키마 마크업을 사용해 페이지 구조를 이해하고, 콘텐츠 계층을 인덱싱하며, 리치 결과를 생성한다. 의미 있는 랜드마크 영역을 가진 잘 구조화된 페이지는 추천 스니펫을 얻고 높은 관련성 점수를 받을 가능성이 더 크다. 또한 직접적인 사용성 배당도 있다. 명확한 시맨틱 구조를 가진 페이지는 개발 팀이 유지보수, 테스트, 확장하기가 더 쉬워 장기적인 기술 부채를 줄여 준다.

\n\n

관련 Axe-core 규칙

\n

WCAG 1.3.6은 자동화된 검사 외에 수동 테스트를 요구한다. 자동화 도구는 시맨틱 마크업의 존재 여부는 확인할 수 있지만, 그 마크업이 사람 테스트자처럼 모든 구성 요소의 목적을 정확하고 완전하게 전달하는지 여부는 판단할 수 없다. 다음 axe-core 규칙은 이 기준과 밀접하게 관련되어 있으며, 이 기준의 일부 측면에 대한 자동화된 대리 지표 역할을 한다.

\n

\n
• region — 페이지의 모든 콘텐츠가 랜드마크 영역 안에 포함되어 있는지 확인한다. 인식 가능한 랜드마크 요소나 ARIA 랜드마크 역할 밖에 있는 콘텐츠를 표시한다. 이 규칙은 목적 식별의 정확성을 테스트하지는 않지만, 1.3.6이 요구하는 구조적 기반이 존재하는지 확인한다. 이 규칙에서 실패한다는 것은 중요한 콘텐츠가 랜드마크 기반 내비게이션에서 보이지 않는다는 의미다.
\n
• landmark-one-main — 페이지에 정확히 하나의 <main> 요소 또는 role='main'을 가진 요소가 있는지 확인한다. 메인 콘텐츠 영역은 목적이 식별 가능해야 하는 가장 중요한 영역 중 하나이므로, 이는 1.3.6의 기초가 된다. 여러 개의 <main> 랜드마크가 있거나 아예 없으면 개인화 도구가 기본 콘텐츠를 분리해 낼 수 없다.
\n
• landmark-complementary-is-top-level — <aside> 요소나 role='complementary' 영역이 그 목적을 잘못 표현하는 방식으로 메인 콘텐츠 영역 안에 중첩되어 있지 않은지 확인한다. 잘못된 중첩은 영역 간 관계에 대해 보조 기술을 오도한다.
\n
• aria-allowed-role 및 aria-valid-attr-value — 잘못되었거나 부적절한 ARIA 역할 할당을 표시한다. 1.3.6은 정확한 역할 시맨틱에 의존하므로, 잘못된 역할(예: 버튼 그룹에 role='navigation' 사용)을 사용하면 목적 식별을 적극적으로 저해하며, 이러한 규칙이 이러한 불일치를 드러낸다.
\n
• button-name 및 link-name — 인터랙티브 컨트롤에 접근 가능한 이름이 있는지 확인한다. 아이콘 전용 버튼과 접근 가능한 이름이 없는 링크는 1.3.6의 주요 실패 유형이다. 이름이 없는 컨트롤은 목적을 결정할 수 없기 때문이다. 이 규칙은 aria-label, aria-labelledby 또는 눈에 보이는 텍스트가 없는 경우를 표시한다.
\n

\n

수동 테스트가 필요한 이유는 자동화 도구가 선택된 목적 토큰이나 시맨틱 역할이 애플리케이션 맥락에서 구성 요소의 실제 기능을 정확하게 나타내는지 평가할 수 없기 때문이다. 버튼에 접근 가능한 이름과 유효한 ARIA 역할이 있더라도, 이름이 오해의 소지가 있거나 역할이 실제 컨트롤 동작을 반영하지 않으면 여전히 1.3.6을 충족하지 못한다.

\n\n

테스트 방법

\n

\n
1. axe DevTools 또는 Lighthouse로 자동 스캔을 실행한다. Chrome에서 페이지를 열고 axe DevTools 확장 기능을 활성화한 뒤 전체 페이지 스캔을 실행한다. 결과를 위에 나열된 규칙(region, landmark-one-main, button-name, link-name)으로 필터링한다. 위반 사항과 그 영향 등급을 기록한다. Lighthouse에서는 접근성(A11y) 감사(Audit)를 실행하고 랜드마크 및 ARIA 섹션을 검토한다. 모든 실패를 기준선으로 문서화하되, 이것이 1.3.6 준수의 일부만을 나타낸다는 점을 이해해야 한다.
\n
2. 브라우저 개발자 도구를 사용해 랜드마크 구조를 수동으로 검사한다. DevTools를 열고 접근성 트리 패널(Chrome) 또는 Accessibility Inspector(Firefox)로 이동하여 페이지가 일관된 랜드마크 계층을 노출하는지 확인한다. 최상위에 하나의 <header>, 하나의 <main>, 최소 하나의 <nav>(여러 개가 있는 경우 구분되는 레이블 포함), 그리고 하나의 <footer>가 있어야 한다. 의미 있는 콘텐츠 영역이 일반적인 <div> 또는 <span>으로만 감싸져 있지 않은지 확인한다.
\n
3. NVDA와 Firefox로 테스트한다. NVDA를 실행하고 Firefox에서 페이지를 연 뒤, D 키를 눌러 랜드마크를 순환한다. 각 랜드마크가 의미 있는 역할로 안내되는지, 동일 유형의 랜드마크가 여러 개 있을 경우 고유한 레이블이 있는지 확인한다. Tab 키로 아이콘 전용 버튼을 각각 탐색하고, NVDA가 비어 있는 문자열, 파일 이름, “button”과 같은 일반 레이블이 아니라 설명적인 접근 가능한 이름을 읽어 주는지 확인한다.
\n
4. VoiceOver와 Safari(macOS/iOS)로 테스트한다. VoiceOver를 활성화(Cmd+F5, macOS)하고, 로터(Rotor, Vo+U)를 사용해 Landmarks 목록을 열어 예상되는 모든 영역이 나타나는지 확인한다. 인터랙티브 컨트롤을 Tab으로 이동하며 의미 있는 설명이 읽히는지 확인한다. iOS에서는 세 손가락 스와이프로 제목과 랜드마크 단위로 이동하며 각 영역의 목적이 올바르게 안내되는지 확인한다.
\n
5. JAWS와 Chrome으로 테스트한다. JAWS를 실행한 상태에서 Chrome에서 페이지를 연다. R 키로 영역을 탐색하며 각 영역의 역할과 레이블이 정확한지 확인한다. JAWS 가상 커서를 사용해 아이콘 버튼을 읽어 내려가며 그 목적이 전달되는지 확인한다. JAWS 링크 목록(Insert+F7)을 사용해 모든 링크 이름이 의미 있는지 점검한다.
\n
6. 개인화 시맨틱(구현된 경우)을 테스트한다. 페이지에서 W3C Personalization Semantics 어휘(예: data-purpose 또는 aui- 속성)를 사용하는 경우, Personalization Semantics 테스트 도구나 호환되는 브라우저 확장 기능을 사용해 목적 토큰이 올바르게 적용되었는지, 그리고 명세를 지원하는 사용자 에이전트에서 기계가 읽을 수 있는지 확인한다.
\n
7. 구성 요소별 목적 감사(Component-by-component purpose audit)를 수행한다. 페이지의 모든 인터랙티브 구성 요소와 아이콘에 대해 “시각적 맥락 없이 이 구성 요소의 목적을 알 수 있는가?”라고 자문해 보라. 모든 CSS와 이미지를 제거해도 DOM과 ARIA 속성만으로 구성 요소의 목적이 명확하다면 통과다. 목적이 시각적으로만 전달된다면 실패다.
\n

\n\n

수정 방법

\n\n

랜드마크가 없는 일반 div 영역 — 잘못된 예

\n

<div class='site-header'>\n  <div class='logo'>Accsible</div>\n  <div class='main-nav'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </div>\n</div>\n<div class='main-content'>\n  <p>Welcome to our platform.</p>\n</div>\n<div class='sidebar'>\n  <p>Related articles</p>\n</div>\n<div class='site-footer'>\n  <p>© 2025 Accsible</p>\n</div>

\n\n

랜드마크가 없는 일반 div 영역 — 올바른 예

\n

<!-- 브라우저와 보조 기술이 각 영역의 목적을\n     프로그래밍 방식으로 식별할 수 있도록 네이티브 HTML5 랜드마크 요소를 사용 -->\n<header>\n  <a href='/' aria-label='Accsible home'>\n    <img src='logo.svg' alt='Accsible' />\n  </a>\n  <nav aria-label='Primary navigation'>\n    <a href='/home'>Home</a>\n    <a href='/pricing'>Pricing</a>\n  </nav>\n</header>\n<main>\n  <p>Welcome to our platform.</p>\n</main>\n<aside aria-label='Related articles'>\n  <p>Related articles</p>\n</aside>\n<footer>\n  <p>© 2025 Accsible</p>\n</footer>

\n\n

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

\n

<!-- 목적을 프로그래밍 방식으로 결정할 수 없는 아이콘 버튼 —\n     접근 가능한 이름이 전혀 없다 -->\n<button class='btn-icon'>\n  <svg viewBox='0 0 24 24' width='24' height='24'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

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

\n

<!-- aria-label이 버튼에 프로그래밍 방식으로 결정 가능한 목적을 부여한다.\n     레이블이 목적을 설명하므로 SVG는 보조 기술에서 숨긴다 -->\n<button class='btn-icon' aria-label='Add to favourites'>\n  <svg viewBox='0 0 24 24' width='24' height='24' aria-hidden='true' focusable='false'>\n    <path d='M12 2l3.09 6.26L22 9.27l-5 4.87 1.18 6.88L12 17.77l-6.18 3.25L7 14.14 2 9.27l6.91-1.01L12 2z'/>\n  </svg>\n</button>

\n\n

구분 레이블이 없는 다중 내비게이션 랜드마크 — 잘못된 예

\n

<!-- 동일한 역할을 가지지만 레이블이 없는 두 개의 nav 요소:\n     스크린 리더는 이들의 목적을 구분할 수 없다 -->\n<nav>\n  <a href='/home'>Home</a>\n  <a href='/about'>About</a>\n</nav>\n\n<nav>\n  <a href='/page1'>Chapter 1</a>\n\n
(Content truncated due to token limit — please retry this article.)