WCAG 성공 기준 · Level AAA

WCAG 3.1.4: 약어

WCAG 3.1.4는 콘텐츠에서 사용되는 약어의 완전한 형태나 의미를 식별할 수 있는 메커니즘이 제공되어야 한다고 요구합니다. 이 기준은 약어, 두문자어, 머리글자어에 익숙하지 않은 사용자들이 그 전체 의미에 접근할 수 있도록 보장하여, 인지 장애가 있는 사람들, 비원어민, 스크린 리더 사용자들의 이해를 지원합니다.

이 규칙의 의미

WCAG 성공 기준 3.1.4 — Abbreviations (수준 AAA)는 웹 콘텐츠에 약어, 두문자어, 머리글자어가 나타날 때마다, 사용자가 그 전체 형태나 의미를 알 수 있는 메커니즘이 존재해야 한다고 요구한다. WCAG에서 말하는 약어는 단어, 구, 이름의 축약형을 의미하며 — 전통적인 약어(예: "approximately"의 "approx."), 두문자어(예: "National Aeronautics and Space Administration"의 "NASA"), 머리글자어(예: "HyperText Markup Language"의 "HTML")를 모두 포함한다.

이 기준은 단일한 필수 기법을 규정하지 않는다. 대신, 사용자가 낯선 축약형을 마주했을 때 그것이 무엇을 의미하는지 파악할 수 있도록 어떤 메커니즘이든 존재할 것을 요구한다. 허용되는 메커니즘에는 첫 사용 시 텍스트에서 약어를 풀어 쓰는 것(예: "HyperText Markup Language (HTML)"), HTML <abbr> 요소에 전체 표현을 제공하는 title 속성을 사용하는 것, 페이지에서 연결된 용어집을 제공하는 것, 또는 주변 문맥에 전체 형태를 포함해 의미가 모호하지 않도록 하는 것이 포함된다.

통과는 콘텐츠 내의 모든 약어가 다음 메커니즘 중 최소 하나를 갖고 있을 때 발생한다. 첫 사용 시 약어와 나란히 또는 바로 앞에 전체 형태가 텍스트에 나타나 있거나, 정보가 담긴 title 속성을 가진 <abbr> 요소가 약어를 감싸고 있거나, 페이지에서 접근 가능한 용어집 또는 정의 목록이 그 용어를 정의하고 있거나, 주변 문맥이 의미를 전혀 모호함 없이 완전히 명확하게 만드는 경우이다. 실패는 약어가 이러한 지원 없이 나타날 때 발생한다 — 사용자는 "MoNE"이나 "SCR" 같은 축약형을 아무런 의미 설명, 툴팁, 사전 확장, 연결된 용어집 없이 보게 된다.

WCAG에는 좁은 예외가 포함되어 있다. 약어가 언어 자체의 일부로 간주될 정도 — 즉, 독립적인 단어처럼 널리 이해되는 경우(원래는 두문자어였던 "laser"나 "radar" 등) — 확장이 요구되지 않는다. 마찬가지로, 콘텐츠 자체의 정의된 용어로 정의되고, 명확하게 접근 가능한 용어집과 함께 그 문맥에서 일관되게 사용되는 약어는 준수한 것으로 간주된다. 핵심 검사는 항상, 그 약어에 익숙하지 않은 사용자가 콘텐츠 내에서 제공되는 메커니즘을 통해 그 의미를 찾을 수 있는지 여부이다.

왜 중요한가

약어는 웹 콘텐츠 전반에 널리 퍼져 있다 — 정부 포털, 의료 시스템, 전자상거래 플랫폼, 교육 웹사이트는 모두 축약형에 크게 의존한다. 이러한 축약형은 도메인 전문가에게는 익숙하지만, 여러 사용자 집단에게는 상당한 장벽이 된다.

난독증, 지적 장애, 주의력 결핍과 같은 인지 및 학습 장애가 있는 사람들은 낯선 약어를 해독하는 데 어려움을 겪을 수 있으며, 의미를 찾기 위해 페이지를 떠나 검색을 하거나 아예 포기하게 될 수 있다. 기억 장애가 있는 사용자에게는 이전에 접했던 약어조차 세션마다 안정적으로 기억되지 않을 수 있으므로, 페이지 내 메커니즘이 지속적인 중요한 지원을 제공한다.

스크린 리더 사용자 — 시각장애인이나 심한 저시력자를 포함 — 는 스크린 리더가 약어를 혼란스럽거나 의미 없는 방식으로 음성화할 수 있기 때문에 직접적인 영향을 받는다. 예를 들어, 스크린 리더는 "SCR"을 "Sustainable Corporate Responsibility"가 아니라 의미 없는 문자 나열처럼 발음할 수 있다. <abbr> 요소를 적절히 사용하고 title 속성을 제공하면, 일부 스크린 리더 설정에서는 머리글자어 대신 전체 표현을 읽어 주어 이해도를 크게 높일 수 있다. 세계보건기구에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 이들 중 상당수가 디지털 콘텐츠에 접근하기 위해 보조 기술에 의존한다.

비원어민도 또 다른 영향을 받는 집단이다. 영어 기술 문서를 읽는 터키어 사용자나, 터키 정부 포털을 탐색하는 영어 사용자 등은 언어에는 능숙하더라도 도메인 특화 또는 문화 특화 약어에는 전혀 익숙하지 않을 수 있다. 확장을 제공하는 것은 사용자 배경과 지식 수준의 다양성을 존중하는 일이다.

구체적인 상황을 생각해 보자. 병원의 온라인 포털을 방문한 환자가 자신의 진단 보고서를 읽다가 아무런 확장 없이 "KOAH"라는 표현을 접한다. 터키인 임상의는 이를 "Kronik Obstrüktif Akciğer Hastalığı"(Chronic Obstructive Pulmonary Disease)로 즉시 인식하지만, 의학 용어에 익숙하지 않은 환자나 보호자는 자신의 진단을 이해하지 못한 채 남게 된다. 첫 사용 시 인라인으로 확장을 제공하거나 <abbr title='Kronik Obstrüktif Akciğer Hastalığı'>KOAH</abbr> 요소를 통해 확장을 제공하면, 혼란스러운 용어가 이해 가능한 정보로 바뀌고, 정보에 기반한 의사결정을 지원하게 된다.

접근성을 넘어, 측정 가능한 사용성 및 SEO 이점도 있다. 검색 엔진은 약어의 전체 표현을 색인화하여, 전체 용어로 검색하는 사용자를 위한 콘텐츠 검색 가능성을 향상시킨다. 명확하고 모호하지 않은 언어는 지원 요청을 줄이고, 과업 완료율을 높이며, 다양한 문해력 수준의 사용자와의 신뢰를 구축한다.

관련 Axe-core 규칙

WCAG 3.1.4는 어떤 자동화 도구도 페이지 문맥 내에서 특정 약어가 충분히 설명되었는지 신뢰성 있게 판단할 수 없기 때문에 수동 테스트를 요구한다. 자동 스캐너는 <abbr> 요소의 존재는 감지할 수 있지만, 페이지의 모든 약어에 접근 가능한 확장이 제공되었는지는 판단할 수 없다. 아래는 관련된 axe-core 문맥의 요약이다.

  • 수동 테스트 필요(전용 axe-core 규칙 없음): Axe-core에는 WCAG 3.1.4를 위한 자동 규칙이 포함되어 있지 않다. 이는 어떤 텍스트 문자열이 약어에 해당하는지, 페이지 어딘가에서 충분히 확장되었는지, 연결된 용어집이 접근 가능한지 등을 판단하려면 사람의 판단과 문맥 읽기가 필요하기 때문이다. 자동 도구는 깊은 자연어 이해 없이는 "IT"(Information Technology), "it"(대명사), "It"(고유명사)를 구분할 수 없다. 테스터는 페이지 콘텐츠를 수동으로 읽고, 모든 약어, 두문자어, 머리글자어를 식별한 뒤, 각각이 접근 가능한 확장 메커니즘을 갖추었는지 확인해야 한다.
  • 관련 검사 — <abbr>에 title 없음: 독립적인 axe-core 규칙으로 3.1.4에 매핑되지는 않지만, 일부 접근성 린팅 도구와 브라우저 확장 기능은 title 속성이 없는 <abbr> 요소를 모범 사례 경고로 표시한다. <abbr>를 확장 메커니즘으로 사용하는 경우, title 속성이 반드시 존재해야 하며 전체 표현을 포함해야 한다. 비어 있거나 없는 title은 요소의 목적을 무력화하며, 이 기준 하에서는 실패에 해당한다.

테스트 방법

  1. 자동 스캔 기준선: 페이지에 대해 axe DevTools 또는 Lighthouse를 실행한다. 두 도구 모두 3.1.4 전용 규칙은 없지만, axe DevTools는 title 속성이 없는 <abbr> 요소에 대한 모범 사례 알림을 표시할 수 있다. 이를 출발점으로 삼되, <abbr> 마크업 자체가 전혀 없는 약어는 포착하지 못한다는 점을 이해해야 한다.
  2. 수동 콘텐츠 감사: 제목, 본문 텍스트, 표, 폼 레이블, 버튼 레이블, 내비게이션 항목, 푸터 텍스트를 포함해 전체 페이지 콘텐츠를 읽는다. 약어, 두문자어, 머리글자어일 수 있는 모든 단어 또는 문자 시퀀스를 표시한다. 각각에 대해 다음을 확인한다. (a) 같은 페이지에서 이전에 확장되었는지, (b) 비어 있지 않은 title을 가진 <abbr> 요소로 감싸져 있는지, (c) 해당 용어를 정의하는 용어집으로 연결되는 링크가 있는지, (d) 주변 문맥이 그 의미를 모호함 없이 명확하게 만드는지.
  3. NVDA + Firefox로 스크린 리더 검증: NVDA를 활성화한 상태에서 Firefox에서 페이지를 연다. 화살표 키를 사용해 콘텐츠를 탐색한다. NVDA가 title을 가진 <abbr> 요소를 만나면, title 텍스트를 읽어야 한다. 확장이 노출되는지 확인한다. <abbr> 요소의 title 속성에 대한 NVDA의 동작은 버전과 설정에 따라 달라질 수 있으므로, 먼저 NVDA 기본 설정으로 테스트한다.
  4. VoiceOver + Safari(macOS/iOS)로 스크린 리더 검증: VoiceOver를 활성화하고 페이지를 탐색한다. macOS의 VoiceOver는 <abbr> 요소의 title 속성을 읽는다. VO+A를 사용해 페이지를 선형으로 읽고, 약어가 확장을 함께 읽는지 확인한다. iOS에서는 콘텐츠를 스와이프하며 동일한 동작을 확인한다.
  5. JAWS + Chrome으로 스크린 리더 검증: JAWS를 활성화한 상태에서 화살표 키로 페이지를 탐색한다. JAWS는 <abbr title='...'>를 title을 읽어 주는 방식으로 처리한다. 마크업된 각 약어에 대해 확장이 올바르게 음성으로 읽히는지 테스트한다.
  6. 키보드 및 시각적 툴팁 확장 확인: 구현이 <abbr> hover 상태에 연결된 CSS 툴팁 패턴이나 JavaScript 기반 툴팁에 의존하는 경우, 키보드로 요소에 탭(또는 프로그래밍 방식으로 포커스)하여 툴팁이 나타나는지 확인한다. WCAG는 메커니즘이 접근 가능할 것을 요구하며, 마우스로만 접근 가능해서는 안 된다 — hover에서만 나타나는 툴팁은 키보드 사용자에게 실패이다.
  7. 용어집 링크 검증: 페이지가 연결된 용어집에 의존하는 경우, 링크를 따라가 원본 콘텐츠에서 사용된 모든 약어에 대해 명확한 정의가 있는지 확인한다. 용어집 링크가 눈에 잘 띄고, 키보드로 접근 가능해야 한다.

수정 방법

첫 사용 시 표시되지 않은 약어 — 잘못된 예

<p>The WHO reported that NCDs account for 74% of all deaths globally each year.</p>

첫 사용 시 표시되지 않은 약어 — 올바른 예

<!-- Expand on first use inline, then use abbr for subsequent references -->
<p>The World Health Organization (WHO) reported that non-communicable diseases
(<abbr title='non-communicable diseases'>NCDs</abbr>) account for 74% of all
deaths globally each year.</p>

title 속성이 없는 abbr 요소 — 잘못된 예

<!-- abbr element present but title is missing — provides no expansion -->
<p>Submit your <abbr>VAT</abbr> registration number to proceed.</p>

title 속성이 없는 abbr 요소 — 올바른 예

<!-- title attribute supplies the full expansion for assistive technologies -->
<p>Submit your <abbr title='Value Added Tax'>VAT</abbr> registration number to proceed.</p>

hover 전용 약어 툴팁 — 잘못된 예

<!-- CSS tooltip only appears on mouse hover; keyboard users and touch users cannot access it -->
<span class='tooltip-trigger'>KVKK
  <span class='tooltip-text'>Kişisel Verilerin Korunması Kanunu</span>
</span>

hover 전용 약어 툴팁 — 올바른 예

<!-- Using abbr with title ensures the expansion is available to all users,
     including keyboard and screen reader users, without relying on hover -->
<abbr title='Kişisel Verilerin Korunması Kanunu'>KVKK</abbr>

확장 없이 표 헤더에 있는 약어 — 잘못된 예

<table>
  <thead>
    <tr>
      <th>SKU</th>
      <th>MoQ</th>
      <th>ETA</th>
    </tr>
  </thead>
</table>

확장 없이 표 헤더에 있는 약어 — 올바른 예

<!-- abbr with title inside th provides context for all users, including screen reader users -->
<table>
  <thead>
    <tr>
      <th><abbr title='Stock Keeping Unit'>SKU</abbr></th>
      <th><abbr title='Minimum Order Quantity'>MoQ</abbr></th>
      <th><abbr title='Estimated Time of Arrival'>ETA</abbr></th>
    </tr>
  </thead>
</table>

자주 발생하는 실수

  • <title> 속성 없이 <abbr> 사용: 텍스트를 <abbr> 태그로 감싸는 것만으로는 의미론적 가치나 확장을 제공하지 못한다 — 이 기준에서 접근성 목적을 달성하려면 title 속성이 필수이다.
  • 첫 사용 이후에만 약어를 확장하는 경우: 약어가 읽기 순서에서 확장보다 먼저 나타나는 경우(예: 본문 단락에서 확장되기 전에 제목에 등장하는 경우), 제목을 먼저 접하는 사용자는 그 시점에서 약어를 이해할 수 있는 메커니즘이 없다. 항상 첫 사용 시점 또는 그 이전에 확장해야 한다.
  • 마우스 hover 툴팁에만 의존하는 경우: :hover에서만 나타나는 CSS 또는 JavaScript 툴팁은 키보드 전용 사용자, 터치스크린 사용자, 대부분의 스크린 리더 설정에서 접근할 수 없다. <abbr title> 패턴이 더 바람직하며, 툴팁을 사용할 경우 :focus에서도 트리거되어야 한다.
  • 연결된 용어집을 제공하지만 링크를 찾기 어렵게 만드는 경우: 확장 메커니즘이 용어집인 경우, 링크는 명확하게 레이블링되고, 눈에 잘 띄는 위치에 있으며, 키보드로 접근 가능해야 한다. 용어집 링크를 작은 글씨로 푸터에 숨기거나 접힌 섹션 뒤에 두는 것은 사용 가능한 메커니즘 요구사항을 충족하지 못할 수 있다.
  • 약어 확장을 일관되지 않게 제공 — 일부만 마크업하는 경우: 한 섹션에서는 두문자어에 <abbr title>를 사용하면서, 같은 페이지의 다른 곳에서는 그대로 두면, 검색이나 랜드마크를 통해 해당 섹션으로 바로 이동한 사용자는 설명되지 않은 축약형을 마주하게 된다.
  • 모든 약어가 보편적으로 이해된다고 가정하는 경우: 금융 분야의 "EBITDA", 소프트웨어 개발의 "API", 터키 정부 문맥의 "BKT"처럼 실무자에게는 자명한 도메인 특화 약어도, 그 분야 밖의 사용자 — 보조 기술 사용자나 처음 페이지를 방문한 사람 — 에게는 완전히 불투명할 수 있다.
  • 확장을 이미지의 alt 텍스트에만 두고 텍스트에는 두지 않는 경우: 이미지의 alt 텍스트에는 확장이 있지만, 눈에 보이는 텍스트에는 약어만 있는 경우, 브라우저 리더 모드 사용자 등 모든 사용자에게 메커니즘이 접근 가능하지 않을 수 있다. 확장은 문서의 프로그래밍 가능한 텍스트 내에서도 제공되어야 한다.
  • 잘못되었거나 축약된 title 값을 사용하는 경우: <abbr> 요소의 title 속성에는 또 다른 약어나 부분적인 설명이 아니라 전체 확장이 포함되어야 한다. title='HyperText Markup Language' 대신 title='HTML lang'라고 쓰는 것은 이 기준을 충족하지 못한다.
  • 동적 콘텐츠의 약어를 고려하지 않는 경우: AJAX, 무한 스크롤, 단일 페이지 애플리케이션 라우팅을 통해 로드되는 콘텐츠는 페이지 초기 로드 이후 새로운 약어를 도입할 수 있다. DOM에 주입되는 모든 동적 콘텐츠도 이 기준을 준수해야 하며, 동적으로 렌더링되는 섹션의 약어 역시 정적 콘텐츠와 동일한 확장 메커니즘을 가져야 한다.
  • 일상어가 된 두문자어를 항상 예외로 취급하는 경우: "laser", "radar"처럼 단어로 기능하는 약어에 대한 예외는 매우 좁다. "URL"이나 "PDF" 같은 용어는 기술에 익숙한 문맥에서는 매우 널리 알려져 있지만, 고령 사용자, 인지 장애가 있는 사용자, 다른 문화적 배경을 가진 사용자에게는 여전히 불투명할 수 있다. 애매할 때는 확장을 제공하는 것이 좋으며, 이미 용어를 알고 있는 사용자에게 해가 되지 않는다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 WCAG 2.2와 정렬된 의무적 디지털 접근성 의무를 수립한다. 이 대통령령은 광범위한 주체 유형을 포괄한다. 모든 수준의 공공 기관 및 정부 기관, 전자상거래 플랫폼, 은행 및 금융 기관, 병원 및 의료 제공자, 200,000명 이상의 가입자를 보유한 통신 회사, 허가받은 여행사, 민간 운송 회사, 그리고 국립교육부(MoNE)의 인가를 받은 사립 학교가 이에 해당한다.

대통령령은 주로 WCAG 2.2 수준 AA 준수를 의무화한다. WCAG 3.1.4 — Abbreviations는 수준 AAA 기준이므로, 현재의 대통령령 2025/10 문구에 따라 직접적인 법적 요구사항은 아니다. 그러나 수준 AAA 준수는 단순한 이상적 목표에 그치지 않으며, 터키 디지털 환경에서 상당한 실질적·평판적 의미를 가진다.

다양한 인구를 대상으로 하는 공공 부문 기관, 병원, 교육 기관의 경우 — 이들 중 상당수는 관료적 또는 의학적 약어에 익숙하지 않을 수 있다 — 3.1.4를 구현하는 것은 진정한 서비스 품질의 문제이다. 터키 행정 및 법률 언어는 공무원에게는 너무나 자연스럽지만 일반 대중, 특히 고령자, 농촌 지역 사용자, 포털 첫 방문자에게는 혼란스러운 머리글자어("SGK"는 Sosyal Güvenlik Kurumu, "KDV"는 Katma Değer Vergisi, "ÖTV"는 Özel Tüketim Vergisi 등)로 가득하다.

대통령령의 적용을 받는 은행, 통신사, 전자상거래 플랫폼은 금융 상품 설명, 계약 요약, 요금표, 서비스 약관에 사용되는 약어를 확장함으로써 접근성 수준과 브랜드 신뢰를 강화할 수 있다. 특히 금융 문서는 약어가 빽빽하게 들어 있어, 정보에 기반한 결정을 내려야 하는 소비자에게 중요한 정보를 가리는 역할을 할 수 있다.

시장 선도 의지를 보여 주거나, 국제 파트너의 조달 요구사항을 충족하거나, 공중 보건 또는 교육 분야의 특수 계약에서 기대되는 수준을 맞추기 위해 WCAG 2.2 AAA 공식 준수 선언을 추구하는 조직은 3.1.4를 표준 관행으로 구현해야 한다. Accsible의 오버레이 SDK는 팀이 약어 확장 패턴을 구현하고 감사하는 데 도움을 주며, 콘텐츠 작성 워크플로 중에 가이던스를 노출하도록 구성할 수 있어, 대규모로 동적으로 업데이트되는 콘텐츠 전반에 걸쳐 준수를 유지하도록 지원한다.