WCAG 3.1.6: 발음

WCAG 3.1.6은 발음을 알지 못하면 의미가 모호해지는 단어의 특정 발음을 식별할 수 있는 메커니즘이 제공되어야 한다고 요구합니다. 이 기준은 음성 합성 기술에 의존하는 사용자나 익숙하지 않은 언어를 접하는 사용자가 모호한 콘텐츠의 올바른 의미에 접근할 수 있도록 보장합니다.

이 규칙의 의미

WCAG 3.1.6 발음(Pronunciation)은 이해 가능성(Understandable) 원칙 아래의 AAA 수준 성공 기준입니다. 이 기준은 다음과 같이 규정합니다. "단어의 의미가, 맥락 속에서, 발음을 알지 못하면 모호해지는 경우, 해당 단어의 특정 발음을 식별할 수 있는 메커니즘이 제공되어야 한다."

핵심 요구 사항은, 어떤 단어의 의미가 전적으로 그 단어가 어떻게 발음되는지에 달려 있고 — 그 발음을 주변 맥락만으로는 알 수 없을 때 — 작성자는 사용자가 올바른 발음을 알 수 있는 방법을 제공해야 한다는 점입니다. 이는 단순히 정의를 제공하는 것과는 다릅니다. 이 성공 기준은 의미상의 모호성을 해소하는 음성학적 발음에 명시적으로 초점을 맞춥니다.

이 기준은 동일한 문자 배열이 여러 방식으로 읽힐 수 있고, 각기 다른 의미를 낳는 상황을 대상으로 합니다. 영어의 고전적인 예로는 "read" (현재형, "reed"와 운율)와 "read" (과거형, "red"와 운율), 또는 "wind" (바람, "sinned"와 운율)와 "wind" (감다, "find"와 운율)가 있습니다. 일본어, 중국어, 아랍어처럼 문자 체계가 더 복잡하거나 성조 구별이 있는 언어에서는 이 문제가 훨씬 더 자주, 그리고 더 중대한 결과를 낳습니다.

터키어는 많은 다른 언어에 비해 대체로 음운 규칙이 규칙적인 편이지만, 특히 화면 낭독기를 사용하는 사용자에게는, 합성 음성 엔진이 익숙하지 않은 용어나 외래어의 강세를 잘못 두거나 잘못 발음할 수 있기 때문에, 전문적·기술적·격식 있는 맥락에서 발음이 불분명할 수 있는 단어와 차용어가 여전히 존재합니다.

충족으로 인정되는 경우: 어떤 단어가 발음을 알지 못하면 모호한 경우, 다음 메커니즘 중 최소 하나가 제공되면 해당 페이지는 이 기준을 충족합니다.

단어 바로 옆에 위치한 인라인 음성 안내(예: 동아시아 문자에 대해 HTML <ruby> 요소와 관련 <rt>, <rp> 태그를 사용하거나, IPA 또는 다른 공인 표기 체계를 사용한 괄호 속 발음 표기).
해당 모호한 단어의 발음을 명시적으로 다루는 용어집 항목 또는 발음 안내로 연결되는 링크.
단어와 연결된 오디오 발음 클립.
독자가 해석할 수 있는 방식으로 발음을 설명하는, 단어 바로 앞이나 뒤의 인라인 텍스트(예: "여기서 'bass'는 물고기를 뜻하며 — 'mass'와 같이 발음합니다.").

실패로 인정되는 경우: 어떤 단어의 의미가 실제로는 발음을 듣지 않고는 모호한데, 그 모호성을 발음 정보로 해소할 수 있는 메커니즘이 전혀 없는 경우 페이지는 실패합니다. 발음을 명확히 하지 않는 텍스트 정의만 제공하는 것은, 그 단어가 어떻게 들리는지 알지 못하면 정의만으로 의미를 파악할 수 없는 경우에는 충분하지 않습니다. 문장, 제목, 이미지 등 주변 맥락이 이미 발음을 명확히 해 주는 경우에는, 추가 메커니즘 없이도 이 기준이 충족된다는 점에 유의해야 합니다.

공식적인 예외: WCAG 명세는 이 성공 기준의 범위를, 발음을 알지 못하면 모호성이 존재하는 경우로 명시적으로 한정합니다. 주변 텍스트, 시각 자료, 의미 구조가 이미 모호성을 명확하게 해소하는 경우에는 추가 발음 메커니즘이 필요하지 않습니다. 이 기준은 모든 페이지의 모든 단어에 음성학적 주석을 요구하는 것이 아니라 — 의미가 발음에 실제로 의존하고, 그 발음을 맥락에서 추론할 수 없는 단어에만 적용됩니다.

왜 중요한가

발음의 모호성은 여러 상이한 사용자 집단에 의미 있는 장벽을 만들며, 특히 기본 텍스트 외의 시각적·청각적 단서에 의존할 수 없는 사용자에게 그 영향이 두드러집니다.

화면 낭독기에 의존하는 시각장애 및 저시력 사용자가 가장 직접적인 영향을 받는 집단입니다. 화면 낭독기는 텍스트를 합성 음성으로 변환하는데, 하나의 단어에 서로 다른 의미를 가진 복수의 유효한 발음이 존재할 경우, TTS 엔진은 둘 중 하나를 선택해야 하며 — 자주 잘못 선택합니다. 예를 들어, "compound interest"(복리)에 대한 금융 기사를 듣는 사용자가 "compound"를 울타리로 둘러싸인 구역을 뜻하는 명사형과 동일하게 발음되는 것으로 들을 수 있어, 순간적 또는 지속적인 혼란을 겪을 수 있습니다. 주변 시각적 맥락을 빠르게 훑어볼 수 없는 사용자에게는, 이러한 혼란을 해소하기 위해 구절을 다시 듣거나 다른 곳에서 추가 설명을 찾아야 합니다. 세계보건기구(WHO)에 따르면 전 세계적으로 약 22억 명이 어떤 형태로든 시각 장애를 가지고 있으며, 이들 중 상당수는 디지털 콘텐츠에 접근하기 위한 주된 수단으로 화면 낭독 기술을 사용합니다.

인지 및 학습 장애가 있는 사용자는 난독증이나 언어 처리 장애가 있는 사람을 포함하며, 기능적 시력을 가지고 있더라도 텍스트-음성 변환 도구에 자주 의존합니다. 이러한 사용자에게 동철이의 발음이 잘못 들리면, 특히 해당 구절이 기술적이거나 낯선 경우, 회복하기 어려운 방식으로 이해를 방해할 수 있습니다.

수어를 주 언어로 사용하는 농인 및 난청 사용자는 2차 또는 3차 언어로서의 문어를 접할 수 있습니다. 이들에게는, 비록 소리를 들을 수 없더라도, 단어의 음성 표기를 보는 것이 텍스트 정의만으로는 어려운 개념 연결을 더 안정적으로 가능하게 해 줍니다.

비원어민 및 언어 학습자도 발음 안내로부터 큰 도움을 받습니다. 터키어 학습자가 전문 의학·법률 용어 또는 터키어 표기로 옮겨진 외국 기술 용어를 접할 때, 강세가 첫 음절에 오는지 두 번째 음절에 오는지 알지 못할 수 있으며, 이는 의미를 바꾸거나 최소한 이해를 방해할 수 있습니다.

구체적인 실제 시나리오: "ileum"(소장의 한 구간)이라는 단어를 포함한 시술 설명과 함께 ilium(골반뼈)을 언급하는 콘텐츠가 있는 터키어 의료 포털을 생각해 보십시오. 영어에서는 많은 방언에서 이 두 단어가 동일하게 들립니다. 화면 낭독기로 페이지를 읽을 때, 수술을 앞둔 시각장애 또는 저시력 환자는 발음이나 음성학적 맥락이 제공되지 않는 한, 오디오만으로 두 용어를 구분할 수 없습니다. 이는 가상의 극단적 사례가 아니라 — 이러한 모호성이 실제 피해를 초래할 수 있는, 위험도가 높은 의료 문서 영역에서 실제로 발생하는 문제입니다.

SEO 및 사용성 측면의 이점도 존재합니다. 발음 안내는 정확하고 잘 정의된 용어 사용을 장려합니다. 음성 표기가 포함된 용어집은 페이지 체류 시간을 늘리고 사용자 좌절을 줄입니다. 용어를 설명하는 구조화된 풍부한 콘텐츠는 더 많은 인바운드 링크를 유도하고, 검색 엔진에 주제 전문성을 신호합니다.

테스트 방법

먼저 자동 스캔 실행(기본선 확보): axe DevTools 또는 Lighthouse를 사용해 페이지의 일반적인 접근성 감사를 수행합니다. 두 도구 모두 WCAG 3.1.6 전용 규칙은 없지만, <html> 요소의 lang 속성 누락 또는 오류(WCAG 3.1.1), 다른 언어로 된 구절에 대한 언어 식별 누락(WCAG 3.1.2) 등 관련 언어 문제를 드러낼 수 있습니다. 이러한 문제는 화면 낭독기가 아예 잘못된 언어 엔진을 적용하게 만들어 발음 문제를 악화시킬 수 있습니다. <html lang='tr'>(또는 적절한 언어 코드)가 존재하고 올바른지 확인하십시오.
동철이 및 모호한 용어에 대한 콘텐츠 감사 수행: 페이지 주제와 언어에 대한 도메인 전문성을 바탕으로 모든 텍스트 콘텐츠를 읽습니다. 서로 다른 의미를 가진 복수의 발음을 가진 단어 목록을 작성합니다. 특히 다음에 주의를 기울이십시오. 표준 터키어 음운 규칙을 따르지 않을 수 있는 영어, 프랑스어, 아랍어 등의 차용어; 의학, 법률, 공학 분야의 기술 용어; 발음이 명확하지 않은 고유명사; 편집 검토에서 잠재적으로 혼란을 줄 수 있다고 명시된 단어.
NVDA + Firefox로 테스트: Firefox에서 NVDA를 실행한 상태로 페이지를 엽니다. NVDA의 연속 읽기 모드(Insert + 아래쪽 화살표)를 사용해 전체 페이지 또는 관련 구역을 듣습니다. 합성기가 오해의 소지가 있는 방식으로 발음하는 단어를 기록합니다. 발음 메커니즘(음성 표기, 오디오 버튼, 용어집 링크)이 제공되는지, 그리고 NVDA가 이를 명확히 읽어 주는지 확인합니다.
JAWS + Chrome으로 테스트: Chrome에서 JAWS를 사용해 위와 동일한 청취 테스트를 반복합니다. JAWS와 NVDA는 서로 다른 음성 합성기를 사용하며, 동일한 단어를 다르게 발음할 수 있으므로 두 테스트 모두 중요합니다. JAWS의 상세도(verbosity) 설정을 조정해 모든 인라인 주석과 <ruby> 요소의 콘텐츠가 읽히는지 확인합니다.
VoiceOver + Safari(macOS/iOS)로 테스트: VoiceOver를 활성화하고 Safari로 페이지를 탐색합니다. VO + A를 사용해 페이지를 연속으로 읽습니다. Apple의 음성 합성기는 자체 발음 로직을 가지고 있으므로, <ruby> 주석이나 aria-label 재정의가 올바르게 노출되는지 확인합니다.
발음 메커니즘의 접근성 검증: 페이지에 존재하는 각 발음 메커니즘에 대해, 키보드만으로 접근 가능한지, 화면 낭독기가 이를 알리는지, 그리고 제공된 발음 정보가 실제로 모호성을 해소하는지 확인합니다(예: IPA 표기는 대상 사용자가 IPA를 읽을 수 있을 때만 유용합니다. "pronounced: EYE-lee-um"과 같은 평이한 음성 표기가 더 보편적으로 도움이 될 수 있습니다).
오디오 발음 클립 확인: 오디오 클립을 사용하는 경우, 재생 버튼 라벨, 볼륨 조절 등 접근 가능한 컨트롤이 있는지, 그리고 오디오의 발음 내용을 들을 수 없는 농인 사용자를 위해 대체 텍스트나 전사가 제공되는지 확인합니다.

수정 방법

본문 텍스트의 동철이 — 잘못된 예

<!-- The word "bass" is used in a music context, but its pronunciation
     is ambiguous (rhymes with "face" not "mass" in this context).
     No mechanism is provided to clarify. -->
<p>
  The bass guitar part in the recording was improvised live during
  the studio session.
</p>

본문 텍스트의 동철이 — 올바른 예

<!-- A parenthetical phonetic guide immediately resolves the ambiguity.
     Alternatively, a link to a glossary entry with an audio clip
     would also satisfy the criterion. -->
<p>
  The bass <span lang='en-x-phonetics'>(pronounced: "base", rhymes with "face")</span>
  guitar part in the recording was improvised live during the studio session.
</p>

동아시아 문자 또는 ruby 주석 스크립트 — 잘못된 예

<!-- Japanese kanji without furigana: the reading of this compound
     is not clear to all readers and screen readers may mispronounce it. -->
<p>本日の<span>音楽</span>イベントへようこそ。</p>

동아시아 문자 또는 ruby 주석 스크립트 — 올바른 예

<!-- The <ruby> element with <rt> provides the phonetic reading.
     <rp> provides fallback parentheses for browsers that do not
     support ruby annotations, ensuring backward compatibility. -->
<p>本日の
  <ruby>
    音楽
    <rp>(</rp>
    <rt>おんがく</rt>
    <rp>)</rp>
  </ruby>
イベントへようこそ。</p>

발음이 모호한 기술 용어 — 잘못된 예

<!-- "Ileum" and "ilium" sound identical when mispronounced by a TTS engine.
     No disambiguation mechanism is present in this medical content. -->
<p>
  The surgical procedure involves resection of the terminal ileum
  to treat the affected region.
</p>

발음이 모호한 기술 용어 — 올바른 예

<!-- A glossary link provides access to a page with an audio pronunciation
     clip and IPA notation, satisfying the criterion. The link text is
     descriptive so screen reader users understand where it leads. -->
<p>
  The surgical procedure involves resection of the terminal
  <a href='/glossary/ileum' aria-label='ileum — view pronunciation and definition'>ileum</a>
  to treat the affected region.
</p>

<!-- The linked glossary entry should contain: -->
<article id='glossary-ileum'>
  <h2>Ileum</h2>
  <p><strong>Pronunciation:</strong> ILL-ee-um (/ˈɪliəm/)</p>
  <audio controls aria-label='Audio pronunciation of ileum'>
    <source src='/audio/ileum.mp3' type='audio/mpeg'>
    Your browser does not support the audio element.
  </audio>
  <p><strong>Definition:</strong> The final section of the small intestine,
  connecting to the large intestine. Not to be confused with the ilium
  (a bone of the pelvis, pronounced identically).</p>
</article>

터키어에서 비표준 발음을 가진 차용어 — 잘못된 예

<!-- The English loanword "cache" is used in a Turkish tech article.
     Turkish TTS engines may pronounce this as "kah-sheh" or "kash"
     rather than the intended "kash". No guidance is provided. -->
<p>Tarayıcı cache dosyalarını temizlemek performansı artırabilir.</p>

터키어에서 비표준 발음을 가진 차용어 — 올바른 예

<!-- A phonetic clarification in parentheses uses familiar Turkish
     phonetic conventions to guide the reader. -->
<p>
  Tarayıcı cache
  <span class='pronunciation-guide' aria-label='telaffuz: keş'>
    (telaffuz: keş)
  </span>
  dosyalarını temizlemek performansı artırabilir.
</p>

자주 발생하는 실수

발음 없이 텍스트 정의만 제공하는 경우: 단어의 의미를 설명하는 툴팁이나 용어집 정의를 추가하는 것만으로는, 정의 자체가 발음을 명확히 하지 않는다면 WCAG 3.1.6을 충족하지 못합니다. 예를 들어, "bass"를 "저주파수의 소리 또는 악기"라고 정의해도 발음은 여전히 모호합니다. 메커니즘은 단어가 어떻게 발음되는지를 구체적으로 다루어야 합니다.
<ruby>를 사용할 때 <rp> 폴백 태그를 생략하는 경우: 루비 주석을 기본적으로 지원하지 않는 브라우저에서는 <rp>(루비 괄호)를 생략하면 음성 주석이 완전히 사라집니다. 루비 주석을 지원하지 않는 플랫폼에서도 사용자가 인라인으로 발음 텍스트를 볼 수 있도록, 각 <rt> 요소를 <rp>(</rp>와 <rp>)</rp>로 감싸야 합니다.
접근 가능한 컨트롤이나 텍스트 대체 없이 오디오 클립만 제공하는 경우: 라벨이 없는 오디오 발음 버튼(예: <button><img src='speaker.png'></button>에 alt나 aria-label이 없는 경우)은, 정작 이를 가장 필요로 하는 사용자에게 접근할 수 없습니다. 모든 오디오 컨트롤에는 설명적인 라벨이 있어야 하며, 오디오의 발음 내용은 농인 사용자를 위해 텍스트 형태로도 제공되어야 합니다.
TTS 엔진이 알아서 올바르게 발음할 것이라고 가정하는 경우: 많은 팀이 내부 테스트(시각·청각적으로 가능한 테스트 담당자에 의해 수행됨)에서 모호성이 드러나지 않는다는 이유로 발음 메커니즘을 생략합니다. 동철이의 올바른 발음을 선택하는 일을 TTS 엔진의 휴리스틱에 맡기는 것은 유효한 접근성 전략이 아닙니다. 이러한 휴리스틱은 특히 도메인 특화 콘텐츠나 다국어 콘텐츠에서 자주 실패합니다.
발음 안내를 단어에서 너무 멀리 배치하는 경우: 페이지 하단이나 도움말 섹션에 있는 사이트 전체 발음 용어집으로 연결하는 링크는, 사용자가 해당 내용을 찾기 위해 현재 읽고 있던 위치를 떠나야 한다면 이 기준을 충족하지 못합니다. 메커니즘은 모호한 특정 단어와 명확히 연관되어 있어야 하며, 인라인이거나, 가까운 위치에 있는 명확한 라벨의 링크여야 합니다.
대상 사용자를 고려하지 않고 IPA 표기만 사용하는 경우: 국제 음성 기호(IPA) 표기는 매우 정확하지만, 대부분의 일반 사용자에게는 읽기 어렵습니다. 사용자가 언어 전문가가 아니라면, "chaos"에 대해 "pronounced: KAY-oss"와 같은 평이한 음성 표기가 실질적으로 더 유용합니다. 접근하기 어려운 형식의 발음 안내를 선택하는 것은, 발음 안내를 제공하는 목적 자체를 훼손합니다.
발음 스팬에 적절한 언어 속성을 지정하지 않는 경우: 페이지의 기본 언어와 다른 언어나 표기 체계로 음성 표기를 제공하면서, 해당 요소에 올바른 lang 속성을 생략하는 경우가 있습니다. 이로 인해 화면 낭독기가 발음을 안내하기 위한 텍스트에 잘못된 음운 규칙을 적용하게 되어, 문제를 더욱 악화시킵니다.
본문 텍스트에만 이 기준을 적용하고, 제목·내비게이션·UI 라벨을 무시하는 경우: 모호한 동철이는 제목, 버튼 라벨, 링크 텍스트, 폼 필드 라벨, 오류 메시지에도 등장할 수 있습니다. 이러한 위치는 화면 낭독기 사용자가 랜드마크나 요소 유형별로 탐색할 때 종종 문맥과 분리된 채로 읽히므로, 본문 텍스트보다 맥락을 통한 모호성 해소가 더 어려울 수 있습니다.
WCAG 3.1.3(특수한 단어)와 3.1.6(발음)을 혼동하는 경우: WCAG 3.1.3은 특수하거나 비일상적인 방식으로 사용되는 단어에 대한 메커니즘을 요구합니다. WCAG 3.1.6은 발음에 따라 의미가 달라지는 단어라는 별도의 문제를 다룹니다. "read"와 "wind"처럼 흔한 단어도, 특수하지 않더라도 3.1.6에 따라 수정이 필요할 수 있습니다. 한 기준을 충족했다고 해서 다른 기준까지 자동으로 충족된다고 가정하지 마십시오.
여러 화면 낭독기와 TTS 엔진으로 테스트하지 않는 경우: NVDA의 eSpeak, JAWS의 Eloquence 또는 Vocalizer, Apple의 내장 음성 등 서로 다른 합성기는 서로 다른 발음 휴리스틱을 사용하며, 동철이를 다르게 처리합니다. 특정 엔진이 우연히 올바르게 발음하는 단어라도, 다른 엔진에서는 잘못 발음될 수 있습니다. 콘텐츠 작성자는 최소 두 가지 이상의 화면 낭독기/브라우저 조합으로 테스트하여 실제 사용자에게 영향을 미치는 발음 실패를 찾아야 합니다.

터키 접근성 규정과의 관계

2025년 6월 21일 관보 제32933호에 게재된 터키 대통령령 2025/10은 터키에서 운영되는 광범위한 주체에 대해 구속력 있는 웹 접근성 요구 사항을 수립합니다. 이 대통령령은 WCAG 2.2 기준 준수를 의무화하며, 적용 대상에 대해 주로 A 및 AA 수준 성공 기준을 강조합니다. 대통령령이 명시적으로 적용되는 주체에는 공공 기관 및 단체, 전자상거래 플랫폼, 은행 및 금융 서비스 제공자, 병원 및 의료 기관, 가입자 200,000명 이상인 통신사, 여행사, 민간 운송 회사, 그리고 교육부(MoNE)의 인가를 받아 운영되는 사립 학교가 포함됩니다.

WCAG 3.1.6 발음(Pronunciation)은 AAA 수준 기준이므로, 대통령령에서 법적으로 의무화된 요구 사항에는 포함되지 않습니다. 적용 대상 기관은 기본 준수 조치로서 발음 메커니즘을 구현할 법적 의무는 없습니다. 그러나 대통령령의 보다 넓은 목적 — 장애인을 포함한 모든 시민이 디지털 서비스를 실제로 사용할 수 있도록 보장하는 것 —은 기술적·편집적으로 가능한 범위에서 AAA 수준 기준을 자발적으로 채택하는 것으로 잘 달성될 수 있습니다.

법적 의무가 없더라도, 특정 적용 대상 범주에서는 WCAG 3.1.6을 구현해야 할 실질적인 이유가 특히 강합니다. 대통령령의 적용 대상인 병원이 운영하는 의료 포털은, 발음 모호성이 실제 환자 피해를 초래할 수 있는 용어를 다룹니다. 공공 기관이 게시하는 법률 또는 규제 텍스트에는, 화면 낭독기 사용자에게 장벽이 되는 발음이 명확하지 않은 전문 용어가 포함될 수 있습니다. 다양한 언어 배경을 가진 고객 — 비원어민 터키어 사용자 포함 —을 대상으로 하는 전자상거래 플랫폼은, 발음 안내가 고객 혼란과 이탈을 줄이는 데 도움이 된다는 점을 발견할 수 있습니다.

터키어는 철자와 발음의 대응 관계가 영어·프랑스어 같은 언어보다 더 일관된, 음운 규칙이 규칙적인 언어입니다. 이는 터키어 콘텐츠에 대한 WCAG 3.1.6 준수 작업의 범위를 줄여 주지만, 완전히 없애지는 않습니다. 특히 대통령령의 적용 대상 분야에서, 터키어 기술·상업·디지털 콘텐츠에 영어·프랑스어 차용어가 널리 사용된다는 점을 고려하면, 발음 모호성은 여전히 실제적인 문제입니다. 다른 언어에서 차용된 단어는 항상 터키어 음운 규칙을 따르지 않으며, 합성기의 설정에 따라 터키어 TTS 엔진이 서로 다르게 발음할 수 있습니다.

대통령령의 적용 대상이면서 최고 수준의 접근성을 지향하는 조직 — 또는 다국어 환경에서 사용자를 지원하거나, 보건·금융처럼 위험도가 높은 영역에서 운영하거나, 터키 디지털 시장에서 접근성 리더십을 보여 주고자 하는 조직 — 은, 최소 법적 준수를 넘어서는 포괄적 접근성 프로그램의 일부로 WCAG 3.1.6을 고려해야 합니다. 발음 메커니즘을 구현하는 것은 대부분의 콘텐츠 유형에서 비교적 비용이 낮은 개선이며, 대통령령의 취지와 국제 모범 사례 모두에 부합하는, 포용적 디자인에 대한 진정한 의지를 보여 줍니다.