WCAG 3.1.6: Aussprache

WCAG 3.1.6 verlangt, dass ein Mechanismus verfügbar ist, um die spezifische Aussprache von Wörtern zu identifizieren, deren Bedeutung ohne Kenntnis der Aussprache mehrdeutig ist. Dieses Kriterium stellt sicher, dass Nutzer, die auf Text-zu-Sprache-Technologie angewiesen sind oder auf eine ihnen unbekannte Sprache stoßen, auf die korrekte Bedeutung mehrdeutiger Inhalte zugreifen können.

Was diese Regel bedeutet

WCAG 3.1.6 Aussprache ist ein Erfolgskriterium der Stufe AAA unter dem Prinzip Verständlich. Es lautet: „Ein Mechanismus ist verfügbar, um die spezifische Aussprache von Wörtern zu identifizieren, wenn die Bedeutung der Wörter im Kontext ohne Kenntnis der Aussprache mehrdeutig ist.“

Die Kernanforderung ist, dass Autorinnen und Autoren dann, wenn die Bedeutung eines Wortes vollständig davon abhängt, wie es ausgesprochen wird – und diese Aussprache nicht aus dem umgebenden Kontext abgeleitet werden kann – eine Möglichkeit bereitstellen müssen, mit der Nutzerinnen und Nutzer die korrekte Aussprache herausfinden können. Dies unterscheidet sich davon, einfach nur eine Definition bereitzustellen; das Kriterium bezieht sich ausdrücklich auf die phonetische Aussprache, die eine semantische Mehrdeutigkeit auflöst.

Das Kriterium zielt auf Situationen ab, in denen dieselbe Zeichenfolge auf mehrere Arten gelesen werden kann, wobei jede Aussprache zu einer anderen Bedeutung führt. Klassische Beispiele aus dem Englischen sind das Wort „read“ (Präsens, reimt sich auf „reed“) gegenüber „read“ (Präteritum, reimt sich auf „red“) oder „wind“ (bewegte Luft, reimt sich auf „sinned“) gegenüber „wind“ (aufwickeln, reimt sich auf „find“). In Sprachen mit komplexeren Schriftsystemen oder Tonunterschieden – wie Japanisch, Chinesisch oder Arabisch – ist das Problem noch verbreiteter und folgenreicher.

Türkisch ist zwar im Vergleich zu vielen anderen Sprachen weitgehend phonetisch regelmäßig, dennoch gibt es Wörter und Lehnwörter, deren Aussprache in spezialisierten, technischen oder formellen Kontexten unklar sein kann, insbesondere für Screenreader-Nutzerinnen und -Nutzer, deren synthetische Sprachausgabe unbekannte Fachbegriffe oder fremdsprachige Lehnwörter möglicherweise falsch betont oder falsch ausspricht.

Was als erfüllt gilt: Eine Seite besteht, wenn überall dort, wo ein Wort ohne Kenntnis seiner Aussprache mehrdeutig ist, mindestens einer der folgenden Mechanismen vorhanden ist:

Ein inline platzierter phonetischer Hinweis unmittelbar neben dem Wort (z. B. mit dem HTML-Element <ruby> und den zugehörigen Tags <rt> und <rp> für ostasiatische Schriften oder ein in Klammern gesetzter Aussprachehinweis in IPA oder einem anderen anerkannten Notationssystem).
Ein Link zu einem Glossareintrag oder Ausspracheleitfaden, der das mehrdeutige Wort ausdrücklich abdeckt.
Ein mit dem Wort verknüpfter Audio-Ausschnitt mit der Aussprache.
Inline-Text unmittelbar vor oder nach dem Wort, der seine Aussprache so beschreibt, dass die Leserschaft sie interpretieren kann (z. B. „Das Wort ‚bass‘ bezieht sich hier auf den Fisch – ausgesprochen wie ‚mass‘“).

Was als nicht erfüllt gilt: Eine Seite fällt durch, wenn die Bedeutung eines Wortes ohne gesprochene Wiedergabe tatsächlich mehrdeutig ist und kein Mechanismus existiert, um diese Mehrdeutigkeit durch Ausspracheinformationen aufzulösen. Es reicht nicht aus, lediglich eine Textdefinition bereitzustellen, die die Aussprache nicht klärt, wenn die Bedeutung nicht allein aus der Definition abgeleitet werden kann, ohne zu wissen, wie das Wort klingt. Beachten Sie, dass das Kriterium erfüllt ist, wenn der Kontext – etwa der umgebende Satz, die Überschrift oder ein Bild – die Aussprache bereits eindeutig macht, ohne dass ein zusätzlicher Mechanismus erforderlich ist.

Offizielle Ausnahmen: Die WCAG-Spezifikation beschränkt dieses Kriterium ausdrücklich auf Fälle, in denen Mehrdeutigkeit ohne Kenntnis der Aussprache besteht. Wenn der umgebende Text, visuelle Elemente oder die semantische Struktur die Mehrdeutigkeit bereits eindeutig auflösen, ist kein zusätzlicher Aussprachemechanismus erforderlich. Das Kriterium verlangt keine phonetische Annotation für jedes Wort auf jeder Seite – nur für solche, deren Bedeutung tatsächlich von einer Aussprache abhängt, die nicht aus dem Kontext erschlossen werden kann.

Warum es wichtig ist

Mehrdeutigkeit bei der Aussprache schafft erhebliche Barrieren für mehrere unterschiedliche Nutzergruppen, und die Auswirkungen sind besonders gravierend für diejenigen, die sich außerhalb des Primärtexts nicht auf visuelle oder auditive Hinweise verlassen können.

Blinde und sehbehinderte Nutzerinnen und Nutzer, die Screenreader verwenden, sind die am unmittelbarsten betroffene Gruppe. Screenreader wandeln Text in synthetische Sprache um, und wenn ein Wort mehrere gültige Aussprachen mit unterschiedlichen Bedeutungen hat, muss die Sprachausgabe eine Auswahl treffen – und wählt häufig falsch. Eine Person, die einen Finanzartikel über „compound interest“ hört, könnte „compound“ identisch mit der Substantivform (ein umzäuntes Gelände) ausgesprochen bekommen, was zu momentaner oder anhaltender Verwirrung führt. Für Menschen, die nicht schnell auf den umgebenden visuellen Kontext blicken können, erfordert die Auflösung dieser Verwirrung das erneute Anhören von Passagen oder das Einholen von Klarstellungen an anderer Stelle. Laut Weltgesundheitsorganisation haben weltweit etwa 2,2 Milliarden Menschen eine Form von Sehbeeinträchtigung, von denen ein erheblicher Anteil Screenreader-Technologie als primäres Mittel zum Zugang zu digitalen Inhalten nutzt.

Nutzerinnen und Nutzer mit kognitiven und Lernbehinderungen, einschließlich Personen mit Dyslexie oder Sprachverarbeitungsstörungen, greifen häufig auf Vorlese-Tools zurück, selbst wenn sie funktionales Sehvermögen haben. Für diese Nutzerinnen und Nutzer kann eine falsche Aussprache eines Homographen das Verständnis so stören, dass es schwer wiederherzustellen ist, insbesondere wenn der Text technisch oder ungewohnt ist.

Gehörlose und schwerhörige Nutzerinnen und Nutzer, die Gebärdensprachen als ihre primäre Sprache verwenden, können mit geschriebenem Text in einer zweiten oder dritten Sprache konfrontiert sein. Für sie kann die Sichtbarkeit einer phonetischen Darstellung eines Wortes – auch wenn sie es nicht hören können – die schriftliche Form zuverlässiger mit einem bekannten Konzept verknüpfen als eine reine Textdefinition.

Nichtmuttersprachlerinnen und -sprecher sowie Sprachlernende profitieren enorm von Aussprachehilfen. Eine Person, die Türkisch lernt und auf einen spezialisierten medizinischen oder juristischen Begriff oder einen fremdsprachigen Fachbegriff in türkischer Transkription stößt, weiß möglicherweise nicht, ob die Betonung auf der ersten oder zweiten Silbe liegt, was die Bedeutung verändern oder das Verständnis erschweren kann.

Ein konkretes Szenario aus der Praxis: Betrachten Sie ein türkisches Gesundheitsportal, das ein Verfahren beschreibt, bei dem das Wort „ileum“ (ein Abschnitt des Dünndarms) verwendet wird, zusammen mit Inhalten, die auch auf das „ilium“ (ein Beckenknochen) Bezug nehmen. Im Englischen klingen diese Wörter in vielen Dialekten identisch. Auf einer Seite, die von einem Screenreader vorgelesen wird, hätte eine Patientin oder ein Patient, die oder der sich auf eine Operation vorbereitet und blind oder sehbehindert ist, keine Möglichkeit, die beiden Begriffe allein anhand der Audioausgabe zu unterscheiden, sofern keine Aussprache- oder phonetischen Kontextinformationen bereitgestellt werden. Dies ist kein hypothetischer Randfall – medizinische Dokumentation ist ein Hochrisikobereich, in dem solche Mehrdeutigkeiten realen Schaden verursachen können.

Es gibt auch SEO- und Usability-Vorteile. Aussprachehilfen fördern die Verwendung präziser, gut definierter Terminologie. Glossare mit phonetischen Annotationen verbessern Kennzahlen wie Verweildauer und verringern Frustration. Reich strukturierte Inhalte, die Terminologie erklären, ziehen tendenziell mehr eingehende Links an und signalisieren Suchmaschinen fachliche Autorität.

Wie man testet

Zuerst einen automatisierten Scan ausführen (als Basis): Verwenden Sie axe DevTools oder Lighthouse, um ein allgemeines Accessibility-Audit der Seite durchzuführen. Auch wenn keines der Tools eine eigene Regel für WCAG 3.1.6 hat, kann der Scan verwandte Sprachprobleme aufdecken, etwa ein fehlendes oder falsches lang-Attribut am <html>-Element (WCAG 3.1.1) oder fehlende Sprachkennzeichnung für Passagen in einer anderen Sprache (WCAG 3.1.2). Diese Probleme können Ausspracheprobleme verstärken, indem sie dazu führen, dass der Screenreader die falsche Sprachengine verwendet. Vergewissern Sie sich, dass <html lang='tr'> (oder der passende Sprachcode) vorhanden und korrekt ist.
Inhaltsprüfung auf Homographen und mehrdeutige Begriffe durchführen: Lesen Sie mit Fachkenntnis des Themas und der Sprache der Seite den gesamten Textinhalt durch. Erstellen Sie eine Liste aller Wörter, die mehrere Aussprachen mit unterschiedlichen Bedeutungen haben. Achten Sie besonders auf: Lehnwörter aus dem Englischen, Französischen, Arabischen oder anderen Sprachen, die möglicherweise nicht den üblichen türkischen Lautregeln folgen; Fachjargon in Medizin, Recht oder Technik; Eigennamen mit nicht offensichtlicher Aussprache; und alle Wörter, die in der redaktionellen Prüfung ausdrücklich als potenziell verwirrend markiert wurden.
Test mit NVDA + Firefox: Öffnen Sie die Seite in Firefox mit laufendem NVDA. Verwenden Sie den kontinuierlichen Lesemodus von NVDA (Einfügen + Pfeil nach unten), um sich die gesamte Seite oder die relevanten Abschnitte vorlesen zu lassen. Notieren Sie jedes Wort, dessen Aussprache durch den Synthesizer missverständlich sein könnte. Prüfen Sie, ob ein Aussprachemechanismus (phonetische Annotation, Audiobutton, Glossarlink) vorhanden ist und ob NVDA ihn klar ankündigt.
Test mit JAWS + Chrome: Wiederholen Sie den oben beschriebenen Hörtest in Chrome mit JAWS. JAWS und NVDA verwenden unterschiedliche Sprachausgaben und können dasselbe Wort unterschiedlich aussprechen, daher sind beide Tests wertvoll. Nutzen Sie die Ausführlichkeits-Einstellungen von JAWS, um sicherzustellen, dass alle Inline-Annotationen und Inhalte von <ruby>-Elementen vorgelesen werden.
Test mit VoiceOver + Safari (macOS/iOS): Aktivieren Sie VoiceOver und navigieren Sie mit Safari durch die Seite. Verwenden Sie VO + A, um die Seite kontinuierlich vorlesen zu lassen. Apples Sprachausgabe hat ihre eigene Aussprachelogik; prüfen Sie, ob <ruby>-Annotationen oder aria-label-Überschreibungen korrekt ausgegeben werden.
Überprüfen, ob der Aussprachemechanismus zugänglich ist: Stellen Sie für jeden Aussprachemechanismus auf der Seite sicher, dass er allein per Tastatur erreichbar ist, von Screenreadern angekündigt wird und dass die bereitgestellten Ausspracheinformationen die Mehrdeutigkeit tatsächlich auflösen (z. B. ist eine IPA-Transkription nur dann nützlich, wenn die Zielgruppe IPA lesen kann; eine laienverständliche phonetische Schreibweise wie „ausgesprochen: EYE-lee-um“ kann universell hilfreicher sein).
Audio-Ausspracheclips prüfen: Wenn Audioclips verwendet werden, stellen Sie sicher, dass sie zugängliche Steuerelemente haben (Abspielknopf mit Beschriftung, Lautstärkeregelung) und dass Transkripte oder Textalternativen für gehörlose Nutzerinnen und Nutzer verfügbar sind, die von Audio nicht profitieren können.

Wie man behebt

Homograph im Fließtext – falsch

<!-- 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>

Homograph im Fließtext – korrekt

<!-- 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>

Ostasiatische oder ruby-annotierte Schrift – falsch

<!-- 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>

Ostasiatische oder ruby-annotierte Schrift – korrekt

<!-- 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>

Fachbegriff mit mehrdeutiger Aussprache – falsch

<!-- "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>

Fachbegriff mit mehrdeutiger Aussprache – korrekt

<!-- 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>

Lehnwort mit nicht standardmäßiger Aussprache im Türkischen – falsch

<!-- 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>

Lehnwort mit nicht standardmäßiger Aussprache im Türkischen – korrekt

<!-- 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>

Häufige Fehler

Nur eine Textdefinition ohne Aussprache bereitzustellen: Das Hinzufügen eines Tooltips oder einer Glossardefinition, die die Bedeutung eines Wortes erklärt, erfüllt WCAG 3.1.6 nicht, wenn die Definition selbst die Aussprache nicht klärt. Wenn man beispielsweise „bass“ als „einen tieffrequenten Klang oder ein Musikinstrument“ definiert, bleibt die Aussprache weiterhin mehrdeutig; der Mechanismus muss ausdrücklich darauf eingehen, wie das Wort ausgesprochen wird.
Verwendung von <ruby> ohne <rp>-Fallback-Tags: In Browsern, die Ruby-Annotationen nicht nativ unterstützen, führt das Weglassen von <rp> (Ruby-Klammern) dazu, dass die phonetische Annotation vollständig verschwindet. Fügen Sie immer <rp>(</rp> und <rp>)</rp> um jedes <rt>-Element herum ein, damit Nutzerinnen und Nutzer auf nicht unterstützten Plattformen den Aussprachetext weiterhin inline sehen.
Bereitstellung von Audioclips ohne zugängliche Steuerelemente oder Textalternativen: Ein Audio-Aussprachebutton ohne Beschriftung (z. B. <button><img src='speaker.png'></button> ohne alt oder aria-label) ist für genau die Nutzerinnen und Nutzer unzugänglich, die ihn am dringendsten benötigen. Jedes Audiosteuerungselement muss eine beschreibende Beschriftung haben, und der Ausspracheinhalt des Audios muss für gehörlose Nutzerinnen und Nutzer auch in Textform verfügbar sein.
Die Annahme, dass die TTS-Engine es schon richtig machen wird: Viele Teams verzichten auf Aussprachemechanismen, weil ihre internen Tests (visuell oder akustisch durch sehende/hörende Testerinnen und Tester) die Mehrdeutigkeit nicht aufdecken. Sich auf die Heuristiken einer Sprachausgabe zu verlassen, um die korrekte Aussprache eines Homographen zu wählen, ist keine gültige Accessibility-Strategie; diese Heuristiken versagen regelmäßig, insbesondere bei domänenspezifischen oder mehrsprachigen Inhalten.
Platzierung der Aussprachehilfe zu weit vom Wort entfernt: Ein Link zu einem seitenweiten Ausspracheglossar am Seitenende oder in einem Hilfebereich erfüllt das Kriterium nicht, wenn Nutzerinnen und Nutzer den Inhalt verlassen müssen, um ihn zu finden, und dabei ihre Leseposition verlieren. Der Mechanismus muss klar mit dem spezifischen mehrdeutigen Wort verknüpft sein, entweder inline oder über einen nahe gelegenen, eindeutig beschrifteten Link.
Verwendung von IPA-Notation ohne Berücksichtigung der Zielgruppe: Transkriptionen im Internationalen Phonetischen Alphabet sind präzise, werden aber von den meisten allgemeinen Zielgruppen nicht gelesen. Wenn Ihre Nutzerinnen und Nutzer keine Sprachprofis sind, sind laienverständliche phonetische Umschriften („ausgesprochen: KAY-oss“ für „chaos“) praktischer. Eine unzugängliche Form für die Aussprachehilfe zu wählen, untergräbt den gesamten Zweck ihrer Bereitstellung.
Versäumnis, Aussprache-Spans mit geeigneten Sprachattributen zu markieren: Wenn eine phonetische Umschrift in einer Sprache oder einem Notationssystem bereitgestellt wird, das sich von der Hauptsprache der Seite unterscheidet, und das korrekte lang-Attribut am umschließenden Element weggelassen wird. Dies führt dazu, dass Screenreader falsche Lautregeln auf genau den Text anwenden, der die Aussprache erklären soll, und verschärft das Problem.
Das Kriterium nur auf Fließtext anzuwenden und Überschriften, Navigation und UI-Beschriftungen zu ignorieren: Mehrdeutige Homographen können in Überschriften, Button-Beschriftungen, Linktexten, Formularfeld-Beschriftungen und Fehlermeldungen auftreten. Diese Elemente werden von Screenreader-Nutzerinnen und -Nutzern häufig isoliert nach Landmarke oder Elementtyp vorgelesen, wodurch kontextuelle Auflösung noch weniger zuverlässig ist als im Fließtext.
WCAG 3.1.3 (Ungewöhnliche Wörter) mit 3.1.6 (Aussprache) zu verwechseln: WCAG 3.1.3 verlangt Mechanismen für Wörter, die in einer ungewöhnlichen oder spezialisierten Weise verwendet werden. WCAG 3.1.6 zielt auf ein anderes Problem: Wörter, deren Bedeutung selbst davon abhängt, wie sie ausgesprochen werden. Ein Wort kann eine Korrektur nach 3.1.6 erfordern, auch wenn es nicht ungewöhnlich ist – „read“ und „wind“ sind gängige Wörter. Gehen Sie nicht davon aus, dass die Erfüllung des einen Kriteriums automatisch das andere erfüllt.
Kein Test mit mehreren Screenreadern und TTS-Engines: Unterschiedliche Sprachausgaben (NVDA mit eSpeak, JAWS mit Eloquence oder Vocalizer, die integrierten Stimmen von Apple) haben unterschiedliche Ausspracheheuristiken und gehen mit Homographen unterschiedlich um. Ein Wort, das eine bestimmte Engine zufällig korrekt ausspricht, kann von einer anderen falsch ausgesprochen werden. Inhaltsverantwortliche sollten mit mindestens zwei Screenreader-/Browser-Kombinationen testen, um Aussprachefehler zu identifizieren, die reale Nutzerinnen und Nutzer betreffen.

Bezug zu den Barrierefreiheitsvorschriften der Türkei

Die Präsidialverfügung 2025/10 der Türkei, veröffentlicht im Amtsblatt Nr. 32933 am 21. Juni 2025, legt verbindliche Anforderungen an die Web-Barrierefreiheit für eine breite Palette von Akteuren fest, die in der Türkei tätig sind. Die Verfügung schreibt die Einhaltung der WCAG-2.2-Standards vor, mit einem Schwerpunkt auf den Kriterien der Stufen A und AA für die erfassten Akteure. Zu den in der Verfügung ausdrücklich genannten Akteuren gehören öffentliche Institutionen und Behörden, E‑Commerce-Plattformen, Banken und Finanzdienstleister, Krankenhäuser und Gesundheitseinrichtungen, Telekommunikationsunternehmen mit 200.000 oder mehr Abonnentinnen und Abonnenten, Reisebüros, private Transportunternehmen und Privatschulen, die unter der Genehmigung des Bildungsministeriums (MoNE) tätig sind.

WCAG 3.1.6 Aussprache ist ein Kriterium der Stufe AAA und gehört daher nicht zu den rechtlich vorgeschriebenen Anforderungen der Verfügung. Erfasste Akteure sind durch die Verfügung nicht verpflichtet, Aussprachemechanismen als Basismaßnahme zur Compliance zu implementieren. Der weiter gefasste Zweck der Verfügung – sicherzustellen, dass digitale Dienste für alle Bürgerinnen und Bürger, einschließlich Menschen mit Behinderungen, tatsächlich nutzbar sind – wird jedoch durch die freiwillige Einführung von AAA-Kriterien überall dort, wo dies technisch und redaktionell machbar ist, gut unterstützt.

Für bestimmte Kategorien erfasster Akteure ist die praktische Argumentation für die Umsetzung von WCAG 3.1.6 besonders stark, selbst ohne rechtliche Verpflichtung. Von Krankenhäusern betriebene Gesundheitsportale, die unter die Verfügung fallen, arbeiten mit Terminologie, bei der Mehrdeutigkeit in der Aussprache echten Schaden für Patientinnen und Patienten verursachen kann. Von öffentlichen Institutionen veröffentlichte juristische oder regulatorische Texte können Fachvokabular mit nicht offensichtlicher Aussprache enthalten, das für Screenreader-Nutzerinnen und -Nutzer Barrieren schafft. E‑Commerce-Plattformen, die vielfältige sprachliche Zielgruppen bedienen – einschließlich nicht muttersprachlicher Türkischsprecherinnen und -sprecher – können feststellen, dass Aussprachehilfen Verwirrung und Abbrüche bei Kundinnen und Kunden verringern.

Türkisch ist eine phonetisch regelmäßige Sprache, was bedeutet, dass die Entsprechung zwischen Schreibweise und Aussprache konsistenter ist als in Sprachen wie Englisch oder Französisch. Dies verringert (aber beseitigt nicht) den Umfang der Arbeiten zur Einhaltung von WCAG 3.1.6 für türkischsprachige Inhalte. Die Verbreitung englischer und französischer Lehnwörter in türkischen technischen, kommerziellen und digitalen Inhalten – insbesondere in den von der Verfügung erfassten Sektoren – bedeutet jedoch, dass Mehrdeutigkeit bei der Aussprache ein reales Problem bleibt. Aus anderen Sprachen entlehnte Wörter folgen nicht immer den türkischen Lautregeln und können von türkischen TTS-Engines je nach Konfiguration des Synthesizers unterschiedlich wiedergegeben werden.

Organisationen, die der Verfügung unterliegen und eine Barrierefreiheit auf höchstem Niveau anstreben – oder die Nutzerinnen und Nutzer in mehrsprachigen Kontexten bedienen, in Hochrisikobereichen wie Gesundheit oder Finanzen tätig sind oder Führungsanspruch in Sachen Barrierefreiheit im türkischen Digitalmarkt erheben möchten – sollten WCAG 3.1.6 als Teil eines umfassenden Barrierefreiheitsprogramms betrachten, das über die minimale rechtliche Compliance hinausgeht. Die Implementierung von Aussprachemechanismen ist für die meisten Inhaltstypen eine relativ kostengünstige Verbesserung und signalisiert ein echtes Engagement für inklusives Design, das sowohl mit dem Geist der Verfügung als auch mit internationalen Best Practices im Einklang steht.