WCAG 3.1.6: Wymowa

Co oznacza ta zasada

WCAG 3.1.6 Pronunciation (Wymowa) jest kryterium sukcesu na poziomie AAA w ramach zasady Zrozumiałość. Stanowi ono: „Dostępny jest mechanizm umożliwiający identyfikację konkretnej wymowy słów, w przypadkach gdy znaczenie słów w kontekście jest niejednoznaczne bez znajomości ich wymowy.”

Podstawowy wymóg polega na tym, że gdy znaczenie słowa zależy całkowicie od tego, jak jest ono wymawiane — i gdy tej wymowy nie da się ustalić na podstawie otaczającego kontekstu — autorzy muszą zapewnić użytkownikom sposób na poznanie poprawnej wymowy. Różni się to od zwykłego podania definicji; kryterium dotyczy konkretnie fonetycznej wymowy, która usuwa niejednoznaczność semantyczną.

Kryterium dotyczy sytuacji, w których ten sam ciąg znaków można odczytać na kilka sposobów, z których każdy prowadzi do innego znaczenia. Klasyczne przykłady z języka angielskiego to słowo „read” (czas teraźniejszy, rymuje się z „reed”) w porównaniu z „read” (czas przeszły, rymuje się z „red”) lub „wind” (wiatr, rymuje się z „sinned”) w porównaniu z „wind” (nawijać, rymuje się z „find”). W językach z bardziej złożonymi systemami pisma lub rozróżnieniami tonalnymi — takich jak japoński, chiński czy arabski — problem ten jest jeszcze częstszy i poważniejszy.

Język turecki, choć w dużej mierze fonetycznie regularny w porównaniu z wieloma innymi językami, nadal zawiera słowa i zapożyczenia, których wymowa może być niejasna w wyspecjalizowanych, technicznych lub formalnych kontekstach, szczególnie dla użytkowników czytników ekranu, których syntezator mowy może niewłaściwie akcentować lub wymawiać nieznaną terminologię lub obce zapożyczenia.

Co uznaje się za spełnienie kryterium: Strona spełnia kryterium, jeśli wszędzie tam, gdzie słowo jest niejednoznaczne bez znajomości jego wymowy, dostępny jest co najmniej jeden z następujących mechanizmów:

• Wbudowany przewodnik fonetyczny bezpośrednio obok słowa (np. z użyciem elementu HTML <ruby> oraz powiązanych znaczników <rt> i <rp> dla pism wschodnioazjatyckich lub nawiasowego zapisu wymowy w IPA lub innym uznanym systemie notacji).
• Odnośnik do hasła w glosariuszu lub przewodnika wymowy, który wprost dotyczy danego niejednoznacznego słowa.
• Klips audio z wymową powiązany ze słowem.
• Tekst wbudowany bezpośrednio przed lub po słowie, opisujący jego wymowę w sposób zrozumiały dla czytelnika (np. „Słowo ‘bass’ odnosi się tutaj do ryby — wymawiane jak ‘mass’”).

Co uznaje się za niespełnienie kryterium: Strona nie spełnia kryterium, jeśli znaczenie słowa jest rzeczywiście niejednoznaczne bez usłyszenia go i nie istnieje żaden mechanizm pozwalający usunąć tę niejednoznaczność poprzez informację o wymowie. Samo podanie definicji tekstowej, która nie wyjaśnia wymowy, jest niewystarczające, jeśli znaczenia nie da się wywnioskować z samej definicji bez znajomości brzmienia słowa. Należy zauważyć, że jeśli kontekst — taki jak otaczające zdanie, nagłówek lub obraz — już jednoznacznie wyjaśnia wymowę, kryterium jest spełnione bez dodatkowego mechanizmu.

Oficjalne wyjątki: Specyfikacja WCAG wyraźnie ogranicza zakres tego kryterium do przypadków, w których niejednoznaczność istnieje bez znajomości wymowy. Jeśli otaczający tekst, elementy wizualne lub struktura semantyczna już jednoznacznie usuwają niejednoznaczność, nie jest wymagany żaden dodatkowy mechanizm wymowy. Kryterium nie wymaga fonetycznej adnotacji dla każdego słowa na każdej stronie — dotyczy tylko tych, których znaczenie rzeczywiście zależy od wymowy, której nie można wywnioskować z kontekstu.

Dlaczego to ma znaczenie

Niejednoznaczność wymowy tworzy istotne bariery dla kilku odrębnych grup użytkowników, a jej wpływ jest szczególnie dotkliwy dla osób, które nie mogą polegać na wizualnych lub dźwiękowych wskazówkach spoza podstawowego tekstu.

Osoby niewidome i słabowidzące korzystające z czytników ekranu są grupą najbardziej bezpośrednio dotkniętą. Czytniki ekranu przekształcają tekst w mowę syntetyczną, a gdy słowo ma wiele poprawnych wymów o różnych znaczeniach, silnik TTS musi dokonać wyboru — i często wybiera błędnie. Użytkownik słuchający artykułu finansowego o „compound interest” może usłyszeć „compound” wymawiane identycznie jak jego forma rzeczownikowa (ogrodzony teren), co powoduje chwilowe lub dłuższe zamieszanie. Dla użytkowników, którzy nie mogą szybko rzucić okiem na otaczający kontekst wizualny, rozwiązanie tego zamieszania wymaga ponownego odsłuchania fragmentów lub szukania wyjaśnień gdzie indziej. Według Światowej Organizacji Zdrowia około 2,2 miliarda ludzi na świecie ma jakąś formę upośledzenia wzroku, z których znacząca część korzysta z technologii czytania z ekranu jako podstawowego sposobu dostępu do treści cyfrowych.

Osoby z niepełnosprawnościami poznawczymi i trudnościami w uczeniu się, w tym z dysleksją lub zaburzeniami przetwarzania języka, często korzystają z narzędzi text-to-speech, nawet jeśli mają funkcjonalny wzrok. Dla tych użytkowników usłyszenie nieprawidłowej wymowy homografu może zakłócić zrozumienie w sposób, z którego trudno się „odbić”, szczególnie gdy tekst jest techniczny lub nieznany.

Osoby Głuche i słabosłyszące, które używają języków migowych jako języka pierwszego, mogą mieć do czynienia z tekstem pisanym w drugim lub trzecim języku. Dla nich zobaczenie fonetycznej reprezentacji słowa — nawet jeśli go nie słyszą — może łączyć formę pisaną ze znanym pojęciem bardziej niezawodnie niż sama definicja tekstowa.

Osoby niebędące rodzimymi użytkownikami języka i uczące się języka odnoszą ogromne korzyści z wskazówek dotyczących wymowy. Osoba ucząca się tureckiego, napotykająca wyspecjalizowany termin medyczny lub prawniczy albo obcy termin techniczny zapisany w tureckiej transkrypcji, może nie wiedzieć, czy akcent pada na pierwszą, czy na drugą sylabę, co może zmieniać znaczenie lub po prostu utrudniać zrozumienie.

Konkretny scenariusz z życia: Rozważmy turecki portal zdrowotny opisujący procedurę z użyciem słowa „ileum” (odcinek jelita cienkiego) obok treści, która odnosi się także do ilium (kość miednicy). W języku angielskim słowa te w wielu dialektach brzmią identycznie. Na stronie odczytywanej przez czytnik ekranu pacjent przygotowujący się do operacji, który jest niewidomy lub słabowidzący, nie miałby żadnego sposobu, by odróżnić te dwa terminy wyłącznie na podstawie dźwięku, jeśli nie zostanie podana wymowa lub kontekst fonetyczny. Nie jest to hipotetyczny przypadek brzegowy — dokumentacja medyczna to obszar wysokiego ryzyka, w którym takie niejednoznaczności mogą powodować realne szkody.

Istnieją także korzyści SEO i użyteczności. Przewodniki wymowy zachęcają do używania precyzyjnej, dobrze zdefiniowanej terminologii. Glosariusze z adnotacjami fonetycznymi poprawiają wskaźniki czasu spędzanego na stronie i zmniejszają frustrację użytkowników. Bogate, ustrukturyzowane treści wyjaśniające terminologię mają tendencję do przyciągania większej liczby linków przychodzących i sygnalizują wyszukiwarkom eksperckość tematyczną.

Powiązane reguły Axe-core

WCAG 3.1.6 wymaga wyłącznie testów manualnych. Nie istnieją zautomatyzowane reguły axe-core, które bezpośrednio odwzorowują to kryterium. Poniższe wyjaśnienie precyzuje, dlaczego automatyzacja nie może wiarygodnie wykrywać naruszeń i na co testerzy muszą zwracać uwagę ręcznie.

• Nie istnieje zautomatyzowana reguła dla niejednoznaczności wymowy. Zautomatyzowane silniki testów dostępności, takie jak axe-core, działają poprzez skanowanie DOM w poszukiwaniu wzorców strukturalnych, brakujących atrybutów, nieprawidłowych ról i innych warunków opartych na regułach. Ustalenie, czy konkretne słowo jest niejednoznaczne bez znajomości jego wymowy, wymaga semantycznego i językowego zrozumienia treści — oceny zależnej od słownictwa, języka, kontekstu dziedzinowego i tła czytelnika. Żaden obecny silnik analizy statycznej nie jest w stanie wiarygodnie określić, że słowo „read” w danym zdaniu jest niejednoznaczne pod względem wymowy bez ludzkiej interpretacji otaczającego znaczenia. Dlatego WCAG samo przyznaje, że to kryterium jest trudne do przetestowania programowo i umieszcza je na poziomie AAA.
• Co muszą sprawdzać testerzy manualni: Testerzy muszą przeczytać treść strony, mając wiedzę dziedzinową o używanym(-ych) języku(-ach), i zaznaczyć każde słowo, dla którego (a) istnieją dwie lub więcej poprawnych wymów, (b) każda wymowa odpowiada innemu znaczeniu oraz (c) otaczający kontekst nie rozstrzyga jednoznacznie, które znaczenie jest zamierzone. Dla każdego takiego słowa tester musi następnie sprawdzić, czy istnieje mechanizm wymowy — przewodnik fonetyczny, klip audio, odnośnik do glosariusza lub wyjaśnienie kontekstowe — oraz czy jest on dostępny.
• Wyrywkowe testy z czytnikiem ekranu: Testerzy korzystający z czytników ekranu (NVDA, JAWS, VoiceOver, TalkBack) powinni odsłuchać treść i zanotować wszelkie przypadki, w których syntezator głosu wymawia słowo w sposób sprzeczny z zamierzonym znaczeniem w kontekście. Jest to silny sygnał, że potrzebny jest mechanizm wymowy.

Jak testować

1. Najpierw uruchom skan automatyczny (dla punktu odniesienia): Użyj axe DevTools lub Lighthouse, aby przeprowadzić ogólny audyt dostępności strony. Choć żadne z tych narzędzi nie ma dedykowanej reguły dla WCAG 3.1.6, skan może ujawnić powiązane problemy językowe, takie jak brakujący lub nieprawidłowy atrybut lang w elemencie <html> (WCAG 3.1.1) lub brak identyfikacji języka dla fragmentów w innym języku (WCAG 3.1.2). Problemy te mogą potęgować kłopoty z wymową, powodując, że czytnik ekranu zastosuje całkowicie niewłaściwy silnik językowy. Sprawdź, czy <html lang='tr'> (lub odpowiedni kod języka) jest obecny i poprawny.
2. Przeprowadź audyt treści pod kątem homografów i niejednoznacznych terminów: Dysponując wiedzą dziedzinową w zakresie tematyki strony i języka, przeczytaj całą treść. Sporządź listę słów, które mają wiele wymów o odrębnych znaczeniach. Zwróć szczególną uwagę na: zapożyczenia z angielskiego, francuskiego, arabskiego lub innych języków, które mogą nie podlegać standardowym regułom fonetycznym tureckiego; żargon techniczny w medycynie, prawie lub inżynierii; nazwy własne o nieoczywistej wymowie; oraz każde słowo wyraźnie oznaczone w redakcji jako potencjalnie mylące.
3. Test z NVDA + Firefox: Otwórz stronę w Firefoxie z uruchomionym NVDA. Użyj trybu ciągłego czytania NVDA (Insert + Strzałka w dół), aby odsłuchać całą stronę lub odpowiednie sekcje. Zanotuj każde słowo, które syntezator wymawia w sposób mogący prowadzić do nieporozumień. Sprawdź, czy dostępny jest jakikolwiek mechanizm wymowy (adnotacja fonetyczna, przycisk audio, odnośnik do glosariusza) i czy NVDA wyraźnie go ogłasza.
4. Test z JAWS + Chrome: Powtórz powyższy test odsłuchowy w Chrome z JAWS. JAWS i NVDA używają różnych syntezatorów mowy i mogą różnie wymawiać to samo słowo, więc oba testy są wartościowe. Użyj ustawień gadatliwości JAWS, aby upewnić się, że wszystkie adnotacje w tekście i treść elementów <ruby> są odczytywane na głos.
5. Test z VoiceOver + Safari (macOS/iOS): Włącz VoiceOver i nawiguj po stronie za pomocą Safari. Użyj VO + A, aby odczytać stronę ciągle. Syntezator mowy Apple ma własną logikę wymowy; sprawdź, czy adnotacje <ruby> lub nadpisania aria-label są poprawnie prezentowane.
6. Zweryfikuj dostępność mechanizmu wymowy: Dla każdego mechanizmu wymowy obecnego na stronie potwierdź, że jest on dostępny wyłącznie z klawiatury, że jest ogłaszany przez czytniki ekranu oraz że dostarczona informacja o wymowie rzeczywiście usuwa niejednoznaczność (np. transkrypcja IPA jest użyteczna tylko wtedy, gdy grupa docelowa potrafi czytać IPA; prosty zapis fonetyczny w języku potocznym, taki jak „pronounced: EYE-lee-um”, może być bardziej uniwersalnie pomocny).
7. Sprawdź klipy audio z wymową: Jeśli używane są klipy audio, upewnij się, że mają dostępne kontrolki (przycisk odtwarzania z etykietą, regulacja głośności) oraz że dostępne są transkrypcje lub alternatywy tekstowe dla osób Głuchych, które nie skorzystają z audio.

Jak naprawiać

Homograf w treści — niepoprawnie

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

Homograf w treści — poprawnie

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

Pismo wschodnioazjatyckie lub skrypt z adnotacją ruby — niepoprawnie

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

Pismo wschodnioazjatyckie lub skrypt z adnotacją ruby — poprawnie

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

Termin techniczny o niejednoznacznej wymowie — niepoprawnie

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

Termin techniczny o niejednoznacznej wymowie — poprawnie

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

Zapożyczenie o niestandardowej wymowie w tureckim — niepoprawnie

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

Zapożyczenie o niestandardowej wymowie w tureckim — poprawnie

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

Typowe błędy

• Podawanie wyłącznie definicji tekstowej bez wymowy: Dodanie podpowiedzi (tooltip) lub definicji w glosariuszu, która wyjaśnia znaczenie słowa, nie spełnia WCAG 3.1.6, jeśli sama definicja nie wyjaśnia wymowy. Na przykład zdefiniowanie „bass” jako „dźwięk o niskiej częstotliwości lub instrument muzyczny” nadal pozostawia wymowę niejednoznaczną; mechanizm musi konkretnie wskazywać, jak wymawia się słowo.
• Używanie <ruby> bez znaczników zapasowych <rp>: W przeglądarkach, które nie obsługują natywnie adnotacji ruby, pominięcie <rp> (nawiasów ruby) powoduje całkowite zniknięcie adnotacji fonetycznej. Zawsze dołączaj <rp>(</rp> i <rp>)</rp> wokół każdego elementu <rt>, aby użytkownicy na platformach bez obsługi ruby nadal widzieli tekst wymowy w treści.
• Udostępnianie klipów audio bez dostępnych kontrolek lub alternatyw tekstowych: Przycisk odtwarzania wymowy audio bez etykiety (np. <button><img src='speaker.png'></button> bez alt lub aria-label) jest niedostępny dla użytkowników, którzy najbardziej go potrzebują. Każda kontrolka audio musi mieć opisową etykietę, a treść wymowy w audio musi być również dostępna w formie tekstowej dla osób Głuchych.
• Zakładanie, że silnik TTS zrobi to dobrze: Wiele zespołów rezygnuje z mechanizmów wymowy, ponieważ ich wewnętrzne testy (prowadzone wizualnie lub słuchowo przez osoby widzące/słyszące) nie ujawniają niejednoznaczności. Poleganie na heurystykach silnika text-to-speech przy wyborze poprawnej wymowy homografu nie jest prawidłową strategią dostępności; heurystyki te często zawodzą, zwłaszcza w przypadku treści specjalistycznych lub wielojęzycznych.
• Umieszczanie wskazówek wymowy zbyt daleko od słowa: Odnośnik do ogólnoserwisowego glosariusza wymowy na dole strony lub w sekcji pomocy nie spełnia kryterium, jeśli użytkownicy muszą opuścić treść, aby go znaleźć, tracąc swoje miejsce w czytaniu. Mechanizm musi być wyraźnie powiązany z konkretnym niejednoznacznym słowem, albo w treści, albo poprzez bliski, wyraźnie opisany odnośnik.
• Używanie notacji IPA bez uwzględnienia odbiorców: Transkrypcje w Międzynarodowym Alfabecie Fonetycznym są precyzyjne, ale większość ogólnych odbiorców nie potrafi ich czytać. Jeśli Twoi użytkownicy nie są specjalistami językowymi, praktyczniej jest stosować zapisy fonetyczne w języku potocznym („pronounced: KAY-oss” dla „chaos”). Wybranie niedostępnego formatu przewodnika wymowy podważa cały cel jego udostępnienia.
• Brak oznaczenia fragmentów wymowy odpowiednimi atrybutami języka: Gdy podajesz zapis fonetyczny w języku lub systemie notacji innym niż główny język strony, pominięcie poprawnego atrybutu lang w elemencie zawierającym powoduje, że czytniki ekranu stosują niewłaściwe reguły fonetyczne do tekstu, który ma pomagać w wymowie, co potęguje problem.
• Stosowanie kryterium wyłącznie do treści głównej i ignorowanie nagłówków, nawigacji oraz etykiet interfejsu: Niejasne homografy mogą pojawiać się w nagłówkach, etykietach przycisków, tekście odnośników, etykietach pól formularzy i komunikatach o błędach. Te elementy są często odczytywane w oderwaniu przez użytkowników czytników ekranu nawigujących po znacznikach lub typach elementów, co czyni kontekstową dezambiguację jeszcze mniej niezawodną niż w treści głównej.
• Mylenie WCAG 3.1.3 (Nietypowe słowa) z 3.1.6 (Wymowa): WCAG 3.1.3 wymaga mechanizmów dla słów użytych w nietypowy lub specjalistyczny sposób. WCAG 3.1.6 dotyczy odrębnego problemu: słów, których samo znaczenie zależy od sposobu wymowy. Słowo może wymagać poprawki zgodnie z 3.1.6, nawet jeśli nie jest nietypowe — „read” i „wind” to powszechne słowa. Nie zakładaj, że spełnienie jednego kryterium oznacza spełnienie drugiego.
• Brak testów z użyciem wielu czytników ekranu i silników TTS: Różne syntezatory (eSpeak w NVDA, Eloquence lub Vocalizer w JAWS, wbudowane głosy Apple) mają różne heurystyki wymowy i różnie traktują homografy. Słowo, które dany silnik akurat wymawia poprawnie, może być błędnie wymawiane przez inny. Autorzy treści powinni testować co najmniej dwa zestawy czytnik/przeglądarka, aby zidentyfikować błędy wymowy wpływające na realnych użytkowników.

Związek z tureckimi regulacjami dotyczącymi dostępności

Prezydencki Okólnik Turcji 2025/10, opublikowany w Dzienniku Urzędowym nr 32933 w dniu 21 czerwca 2025 r., ustanawia wiążące wymagania dotyczące dostępności stron internetowych dla szerokiego zakresu podmiotów działających w Turcji. Okólnik nakazuje zgodność ze standardami WCAG 2.2, z głównym naciskiem na kryteria poziomu A i AA dla objętych podmiotów. Podmioty wyraźnie objęte okólnikiem obejmują instytucje i agencje publiczne, platformy e-commerce, banki i dostawców usług finansowych, szpitale i organizacje opieki zdrowotnej, przedsiębiorstwa telekomunikacyjne z 200 000 lub większą liczbą abonentów, biura podróży, prywatne firmy transportowe oraz szkoły prywatne działające na podstawie upoważnienia Ministerstwa Edukacji Narodowej (MoNE).

WCAG 3.1.6 Pronunciation jest kryterium poziomu AAA, a zatem nie należy do wymogów prawnie obowiązkowych na mocy okólnika. Podmioty objęte nie są zobowiązane okólnikiem do wdrażania mechanizmów wymowy jako podstawowego środka zgodności. Jednak szerszy cel okólnika — zapewnienie, że usługi cyfrowe są rzeczywiście użyteczne dla wszystkich obywateli, w tym osób z niepełnosprawnościami — jest dobrze realizowany poprzez dobrowolne przyjmowanie kryteriów poziomu AAA wszędzie tam, gdzie jest to technicznie i redakcyjnie wykonalne.

Dla niektórych kategorii podmiotów objętych okólnikiem praktyczne argumenty za wdrożeniem WCAG 3.1.6 są szczególnie silne, nawet przy braku obowiązku prawnego. Portale zdrowotne prowadzone przez szpitale objęte okólnikiem operują terminologią, w której niejednoznaczność wymowy może powodować realne szkody dla pacjentów. Teksty prawne lub regulacyjne publikowane przez instytucje publiczne mogą zawierać specjalistyczne słownictwo o nieoczywistej wymowie, które tworzy bariery dla użytkowników czytników ekranu. Platformy e-commerce obsługujące zróżnicowane językowo grupy odbiorców — w tym osoby niebędące rodzimymi użytkownikami języka tureckiego — mogą stwierdzić, że wskazówki wymowy zmniejszają liczbę nieporozumień i porzuceń koszyka.

Turecki jest językiem fonetycznie regularnym, co oznacza, że związek między pisownią a wymową jest bardziej spójny niż w językach takich jak angielski czy francuski. Zmniejsza to (ale nie eliminuje) zakres prac nad zgodnością z WCAG 3.1.6 dla treści w języku tureckim. Jednak rozpowszechnienie zapożyczeń z angielskiego i francuskiego w tureckich treściach technicznych, komercyjnych i cyfrowych — szczególnie w sektorach objętych okólnikiem — oznacza, że niejednoznaczność wymowy pozostaje realnym problemem. Słowa zapożyczone z innych języków nie zawsze podlegają tureckim konwencjom fonetycznym i mogą być różnie odczytywane przez tureckie silniki TTS w zależności od konfiguracji syntezatora.

Organizacje objęte okólnikiem, które aspirują do najlepszej w swojej klasie dostępności — lub które obsługują użytkowników w kontekstach wielojęzycznych, działają w obszarach wysokiego ryzyka, takich jak zdrowie lub finanse, albo chcą wykazać przywództwo w zakresie dostępności na tureckim rynku cyfrowym — powinny rozważyć WCAG 3.1.6 jako część kompleksowego programu dostępności wykraczającego poza minimalną zgodność prawną. Wdrażanie mechanizmów wymowy jest stosunkowo niskokosztowym ulepszeniem dla większości typów treści i sygnalizuje autentyczne zaangażowanie w projektowanie inkluzywne, które jest zgodne zarówno z duchem okólnika, jak i z międzynarodowymi najlepszymi praktykami.