معايير نجاح WCAG · Level AAA
WCAG 1.2.9: صوتي فقط (مباشر)
تتطلب WCAG 1.2.9 أن يكون كل المحتوى الصوتي المباشر فقط — مثل البث الإذاعي المباشر أو التدفقات الصوتية فقط — مصحوبًا ببديل نصي مكافئ في الوقت الفعلي، مثل تغذية تسميات توضيحية مباشرة أو نص تفريغ يتم تحديثه بشكل متزامن. يضمن ذلك أن المستخدمين الصم أو ضعاف السمع يمكنهم الوصول إلى المحتوى الصوتي المباشر دون الاعتماد على المسار الصوتي نفسه.
ماذا يعني هذا المعيار
يقع معيار النجاح 1.2.9 من WCAG، الصوت فقط (مباشر)، تحت الإرشاد 1.2 (الوسائط الزمنية) في المستوى AAA. وينص على ما يلي: "يتم توفير بديل للوسائط الزمنية يقدم معلومات مكافئة للمحتوى الصوتي المباشر فقط." عملياً، يعني هذا أنه كلما قام موقعك الإلكتروني أو تطبيقك ببث أو تقديم محتوى صوتي مباشِر — ولا يصاحبه أي مكوّن مرئي — يجب تزويد المستخدمين بنص مكافئ في الوقت الفعلي ينقل نفس المعلومات بأمانة.
العرض الصوتي المباشر فقط هو أي بث صوتي يُذاع في الوقت الفعلي دون مسار فيديو متزامن. تشمل الأمثلة الشائعة برامج الراديو المباشرة المضمّنة في صفحة ويب، والتعليق الصوتي المباشر أثناء حدث رياضي، والمؤتمرات الصحفية المباشرة التي تُبث بصيغة صوتية، ومكالمات الأرباح المباشرة أو الإحاطات للمستثمرين، والبودكاست الصوتي المباشر أو بث برامج الحوار حيث لا يصاحب الصوت أي تغذية فيديو.
يجب أن يكون البديل النصي المطلوب بموجب هذا المعيار مكافئاً — أي أنه يجب أن يلتقط ليس فقط الكلمات المنطوقة، بل أيضاً المعلومات الصوتية غير الكلامية ذات الصلة مثل ضوضاء الجمهور، أو الإنذارات، أو المؤثرات الصوتية، أو الموسيقى التي تحمل قيمة معلوماتية. لا يفي النص الجزئي أو المتأخر بهذا المعيار؛ إذ يجب تحديث البديل بشكل متزامن (أو شبه متزامن) مع البث المباشر حتى يتمكن المستخدمون الصم وضعاف السمع من متابعة المحتوى في الوقت الفعلي.
تشمل التقنيات المقبولة للوفاء بهذا المعيار توفير كاتب اختزال بشري مباشر ينتج نصاً في الوقت الفعلي (CART — Communication Access Realtime Translation)، أو تضمين ترجمات حية متزامنة يتم إنشاؤها بواسطة خدمة ترجمة نصية مؤهلة، أو عرض تغذية نصية مباشرة تعمل بالتوازي مع البث الصوتي. قد تفي الترجمات التلقائية التي تنتجها برمجيات التعرف على الكلام بالمعيار أيضاً بشرط أن تكون الدقة عالية بما يكفي وأن يتم عرض المخرجات في الوقت شبه الفعلي.
ما يُعد اجتيازاً: توفّر الصفحة بديلاً نصياً مرئياً ومتزامناً — مرتبطاً بوضوح أو معروضاً بجوار مشغّل الصوت — يقدم معلومات مكافئة للبث الصوتي المباشر أثناء حدوثه. يجب أن يكون البديل قابلاً للإدراك من قبل المستخدمين الذين لا يمكنهم سماع الصوت.
ما يُعد إخفاقاً: عدم تقديم أي بديل نصي على الإطلاق؛ أو تقديم بديل نصي متأخر بشكل كبير (مثل نص تفريغي يُنشر بعد الحدث)؛ أو بديل نصي يغطي جزءاً فقط من الصوت (مثل كلام المقدّم فقط دون أسئلة الجمهور)؛ أو وجود بديل نصي لكنه غير متاح لمستخدمي تقنيات المساعدة (مثل عرضه داخل عنصر canvas غير قابل للتركيز أو داخل أداة Flash مغلقة).
الاستثناءات الرسمية: لا يضع WCAG استثناءات محددة للمعيار 1.2.9 بخلاف المبدأ العام الذي ينص على أن المتطلب ينطبق فقط على المحتوى الصوتي المباشر فقط. يغطي المعيار 1.2.1 المحتوى الصوتي المسجّل مسبقاً فقط. لا يوجد استثناء للمقاطع الصوتية القصيرة أو الإعلانات الموجزة — إذا كان المحتوى مباشراً وصوتياً فقط، فإن المعيار ينطبق.
لماذا يهم
يعاني ما يقرب من 466 مليون شخص حول العالم من فقدان سمع معيق، وفقاً لمنظمة الصحة العالمية، ومن المتوقع أن يرتفع هذا العدد إلى أكثر من 900 مليون بحلول عام 2050. بالنسبة لهؤلاء المستخدمين، يكون المحتوى الصوتي المباشر فقط غير قابل للوصول تماماً دون بديل نصي. وعلى عكس المحتوى المسجّل مسبقاً — حيث يمكن إعداد نص تفريغي مسبقاً وإرفاقه لاحقاً — يمثل الصوت المباشر تحدياً فريداً لأن المعلومات حساسة زمنياً وعابرة. لا يمكن للمستخدم الأصم ببساطة إعادة تشغيل البث المباشر لاحقاً وتوقع نفس التجربة؛ فبحكم التعريف، يفقد المحتوى المباشر فوريته بمجرد انقضاء اللحظة.
فكّر في سيناريو واقعي ملموس: تستضيف شركة مدرجة في البورصة مكالمة أرباح مباشرة تُبث كصوت فقط على صفحة علاقات المستثمرين الخاصة بها. لا يستطيع المحللون والصحفيون والمستثمرون الأفراد من الصم أو ضعاف السمع المشاركة في المكالمة — أو حتى متابعتها بشكل سلبي — دون تغذية نصية في الوقت الفعلي. يتم توصيل الإفصاحات المالية المهمة، وتحديثات التوجيه، والردود على أسئلة المحللين في الوقت الفعلي، وأي تأخير في تلقي هذه المعلومات يضع هؤلاء المستخدمين في وضع غير متكافئ من حيث المعلومات. في القطاعات المنظمة، يمكن أن يثير هذا حتى أسئلة حول تكافؤ الوصول إلى المعلومات العامة.
إلى جانب الصمم، يفيد هذا المعيار شريحة أوسع من السكان. فالمستخدمون الذين لديهم اضطرابات في معالجة السمع قد يسمعون الصوت لكنهم يواجهون صعوبة في فك شفرة الكلام بسرعة كافية لمتابعة البث المباشر؛ إذ تتيح لهم تغذية نصية متزامنة القراءة وفقاً لسرعة استيعابهم بينما يُشغَّل الصوت. كما يستفيد المستخدمون في البيئات الحساسة للضوضاء — مثل المكاتب المفتوحة أو المكتبات أو وسائل النقل العام — الذين لا يمكنهم تشغيل الصوت بصوت عالٍ، من البديل النصي. كما يجد المستخدمون الذين تكون لغة البث بالنسبة لهم لغة ثانية أن البدائل النصية أسهل في المتابعة من الكلام المباشر السريع.
من منظور تحسين محركات البحث وقابلية اكتشاف المحتوى، يخلق النص التفريغي المباشر أو تغذية الترجمات النصية الحية نصاً قابلاً للفهرسة يمكن لمحركات البحث الزحف إليه. من المرجح أن تظهر الأحداث المباشرة التي تولّد نصاً في الوقت الفعلي في نتائج البحث ومجمّعات الأخبار، مما يوسّع نطاق الجمهور إلى ما بعد نافذة البث الأصلية.
بالنسبة للمنظمات العاملة في القطاعات المنظمة — الخدمات المالية، الرعاية الصحية، الحكومة — أصبح توفير وصول متكافئ إلى المعلومات الصوتية المباشرة توقعاً متزايداً بدلاً من كونه مجاملة. قد يؤدي عدم الوفاء بهذا المعيار إلى تعريض المنظمات للشكاوى، ومخاطر السمعة، وفي بعض الولايات القضائية، للمسؤولية القانونية.
قواعد Axe-core ذات الصلة
يتطلب المعيار 1.2.9 من WCAG اختباراً يدوياً؛ فلا يمكن لأي قاعدة آلية في axe-core اكتشاف ما إذا كان البث الصوتي المباشر فقط يحتوي على بديل نصي متزامن بشكل موثوق. تعود أسباب هذا القيد إلى طبيعة المعيار نفسها:
- لماذا لا يمكن للأتمتة اكتشاف هذا الانتهاك: تعمل الأدوات الآلية مثل axe-core على لقطات DOM ثابتة أو حالات صفحة في نقطة زمنية واحدة. يمكنها اكتشاف وجود عنصر
<audio>أو مشغّل وسائط، لكنها لا تستطيع تحديد ما إذا كان المحتوى المرتبط مباشراً أم مسجّلاً مسبقاً، أو ما إذا كانت منطقة نصية مرئية على الصفحة تُحدَّث فعلياً بشكل متزامن مع البث الصوتي، أو ما إذا كان المحتوى النصي مكافئاً دلالياً للصوت (يغطي كل الكلام والمعلومات الصوتية غير الكلامية)، أو ما إذا كانت أي خدمة ترجمة نصية خارجية مرتبطة نشطة ودقيقة بالفعل. تتطلب كل هذه الأحكام مراجعة بشرية للبث المباشر نفسه. - ما الذي يجب على المدقق اليدوي التحقق منه: يجب على المدقق الوصول إلى الصفحة أثناء نشاط البث الصوتي المباشر، وتحديد كيفية (أو ما إذا كان) تقديم البديل النصي، والتأكد من أن البديل النصي يُحدَّث في الوقت الفعلي مع تقدم الصوت، والتحقق من أن النص يغطي كل المحتوى الصوتي ذي المعنى بما في ذلك تحديد المتحدثين، والأصوات غير الكلامية، والانتقالات، والتأكد من أن البديل النصي متاح لتقنيات المساعدة — على سبيل المثال، أن منطقة حية تستخدم
aria-live='polite'أوaria-live='assertive'تعلن التحديثات لمستخدمي قارئات الشاشة بشكل مناسب. - إشارات الأتمتة الجزئية: بينما لا يمكن لـ axe-core الإشارة مباشرة إلى غياب بديل نصي مباشر، يجب على المدققين ملاحظة أن axe-core سيقوم بالإشارة إلى مشكلات ذات صلة تفاقم المشكلة — على سبيل المثال، إذا كانت هناك منطقة نص تفريغي موجودة لكنها مخفية باستخدام
display:none، أو إذا كان مشغّل الوسائط يفتقر إلى عناصر تحكم قابلة للوصول. تشكل هذه الإشارات نقاط انطلاق مفيدة أثناء المراجعة اليدوية.
كيفية الاختبار
- فحص آلي كنقطة أساس: شغّل axe DevTools أو Lighthouse على الصفحة التي تستضيف البث الصوتي المباشر. لاحظ أي مشكلات تم الإشارة إليها تتعلق بعناصر الوسائط، أو التسميات المفقودة، أو عناصر التحكم غير القابلة للوصول. رغم أن أياً من الأداتين لن يشير مباشرة إلى غياب بديل نصي مباشر، إلا أنهما قد يكشفان عن حواجز ذات صلة — مثل مشغّل صوت بدون اسم قابل للوصول أو حاوية نص تفريغي مخفية عن شجرة إمكانية الوصول. وثّق هذه النتائج وتعامل معها كجزء من التقييم العام لإمكانية الوصول.
- تحديد المحتوى الصوتي المباشر: أثناء نشاط البث المباشر، تأكد من أن البث الصوتي مباشر (وليس تسجيلاً) وأنه لا يحمل مسار فيديو. تحقق من مصدر الصفحة وطلبات الشبكة للحصول على دلائل — تستخدم البثوث المباشرة عادة HLS (
.m3u8) أو MPEG-DASH أو التوصيل المعتمد على WebSocket. تأكد من أن المحتوى صوتي فقط. - التحقق من وجود بديل نصي: ابحث عن منطقة نصية مرئية، أو تراكب ترجمات، أو تغذية نص تفريغي ذات تسمية واضحة على الصفحة أو مرتبطة مباشرة من الصفحة. يجب أن يكون البديل بارزاً — لا أن يكون مخفياً في قائمة إعدادات أو متاحاً فقط عند الطلب. إذا لم يكن هناك بديل نصي مرئي، يفشل المعيار فوراً.
- التحقق من التزامن: مع ظهور البديل النصي المباشر، استمع إلى البث الصوتي واقرأ التغذية النصية في الوقت نفسه. تأكد من أن النص يُحدَّث ضمن تأخير معقول (عادة لا يزيد عن بضع ثوانٍ لخدمات CART أو خدمات الترجمة النصية الاحترافية). لا يفي المعيار تغذية نصية تُحدَّث كل عدة دقائق أو فقط بعد انتهاء البث.
- التحقق من التكافؤ: تأكد من أن البديل النصي يلتقط كل المحتوى الصوتي ذي المعنى: الكلمات المنطوقة، وتحديد المتحدثين عندما تكون هناك عدة أصوات، والأصوات غير الكلامية ذات الصلة (مثل "[تصفيق]"، "[أصوات إنذار]"، "[موسيقى تُعزف]")، وأي إعلانات أو مقاطعات على الهواء.
- اختبار قارئ الشاشة — NVDA + Firefox: افتح الصفحة مع تفعيل NVDA. انتقل إلى منطقة النص المباشر. إذا كانت المنطقة تستخدم
aria-live، يجب أن يعلن NVDA عن إدراج النص الجديد تلقائياً. إذا كانت منطقة نصية قابلة للتمرير، تحقق من إمكانية وضع التركيز عليها وأن المحتوى قابل للقراءة. تحقق أيضاً من أن عناصر التحكم في مشغّل الصوت قابلة للتشغيل باستخدام لوحة المفاتيح. - اختبار قارئ الشاشة — VoiceOver + Safari (macOS/iOS): فعّل VoiceOver وانتقل إلى منطقة النص المباشر. تأكد من أن VoiceOver يقرأ النص الجديد عند ظهوره. على iOS، تحقق أيضاً من التجربة على الأجهزة المحمولة — إذ يتم الوصول إلى الأحداث المباشرة كثيراً عبر المتصفحات المحمولة.
- اختبار قارئ الشاشة — JAWS + Chrome: مع تفعيل JAWS، انتقل إلى الصفحة وتأكد من أن إعلانات المنطقة الحية تعمل. يتعامل JAWS مع
aria-live='polite'وaria-live='assertive'بشكل مختلف؛ تأكد من أن إعداد مستوى التفصيل مناسب لنوع المحتوى (قد يكون تدفق الترجمات السريع أكثر ملاءمة لـassertiveلتجنب تأخيرات الاصطفاف). - اختبار الأجهزة المحمولة والنطاق الترددي المنخفض: إذا كان الموقع يخدم جمهوراً يستخدم الأجهزة المحمولة، اختبر البديل النصي المباشر على جهاز Android متوسط الإمكانات عبر اتصال مقيّد السرعة. تأكد من أن التغذية النصية تظل متزامنة وقابلة للوصول حتى في ظل الظروف المقيدة.
كيفية الإصلاح
السيناريو 1: مشغّل صوت مباشر بدون بديل نصي — غير صحيح
<!-- Live radio stream embedded with no accompanying text alternative -->
<section>
<h2>Live Broadcast</h2>
<audio controls src='https://stream.example.com/live'>
Your browser does not support the audio element.
</audio>
</section>
السيناريو 1: مشغّل صوت مباشر مع نص تفريغي في منطقة ARIA حية — صحيح
<!-- Live radio stream with a synchronous ARIA live region for real-time captions -->
<section>
<h2>Live Broadcast</h2>
<audio controls src='https://stream.example.com/live'
aria-describedby='live-caption-feed'>
Your browser does not support the audio element.
</audio>
<!-- aria-live='assertive' ensures screen readers announce new text immediately -->
<!-- aria-atomic='false' allows incremental updates rather than re-reading the whole block -->
<div id='live-caption-feed'
role='region'
aria-label='Live captions'
aria-live='assertive'
aria-atomic='false'
tabindex='0'>
<!-- Caption text is injected here by the captioning service JavaScript -->
</div>
</section>
السيناريو 2: نشر النص التفريغي فقط بعد انتهاء الحدث — غير صحيح
<!-- Transcript link appears but only resolves after the broadcast -->
<div>
<audio controls src='https://stream.example.com/press-conference'></audio>
<p>A full transcript will be available after the press conference concludes.</p>
</div>
السيناريو 2: تغذية CART في الوقت الفعلي مرتبطة بجانب المشغّل — صحيح
<!-- Real-time CART captions are displayed inline during the live event -->
<div>
<audio controls src='https://stream.example.com/press-conference'
aria-describedby='cart-feed'></audio>
<!-- The CART feed is an iframe served by a professional captioning provider -->
<!-- The iframe must itself be accessible with an appropriate title -->
<iframe
id='cart-feed'
src='https://cart-provider.example.com/feed/press-conference-2025'
title='Real-time captions for live press conference'
width='100%'
height='200'>
</iframe>
<p>A full transcript will also be published after the event concludes.</p>
</div>
السيناريو 3: ترجمات تلقائية مخفية خلف مفتاح إعدادات — غير صحيح
<!-- Captions exist but are hidden by default and require multiple steps to enable -->
<div class='player-wrapper'>
<audio controls src='https://stream.example.com/webinar'></audio>
<button onclick='toggleSettings()'>Settings</button>
<div id='settings-panel' hidden>
<button onclick='enableCaptions()'>Enable Captions</button>
</div>
</div>
السيناريو 3: ترجمات مفعّلة افتراضياً مع مفتاح واضح — صحيح
<!-- Captions are ON by default; a prominent toggle lets users turn them off if preferred -->
<div class='player-wrapper'>
<audio controls src='https://stream.example.com/webinar'
aria-describedby='webinar-captions'></audio>
<!-- Default state is captions-on; aria-pressed reflects current state -->
<button id='caption-toggle'
aria-pressed='true'
onclick='toggleCaptions(this)'>
Live Captions: On
</button>
<div id='webinar-captions'
role='region'
aria-label='Live webinar captions'
aria-live='polite'
aria-atomic='false'
tabindex='0'>
<!-- Caption text injected here in real time -->
</div>
</div>
الأخطاء الشائعة
- نشر نص تفريغي بعد الحدث والادعاء بأنه يفي بالمعيار 1.2.9: لا يُعد النص التفريغي الذي يُنشر بعد ساعات أو أيام من البث المباشر بديلاً نصياً في الوقت الفعلي. يتطلب المعيار 1.2.9 من WCAG تحديداً أن يكون البديل متاحاً بالتزامن مع الصوت المباشر، وليس بأثر رجعي.
- استخدام
aria-live='polite'لتغذية ترجمات سريعة التحديث: تنتظر المناطق الحية من النوع "polite" حتى ينتهي المستخدم من التفاعل قبل الإعلان عن المحتوى الجديد. بالنسبة للترجمات التي تُحدَّث بسرعة، يؤدي ذلك إلى فقدان مستخدمي قارئات الشاشة للإعلانات. استخدمaria-live='assertive'لتدفقات الترجمات المباشرة التي يكون فيها كل تحديث حساساً للوقت. - حقن كامل سجل الترجمات في كل تحديث بدلاً من المحتوى الجديد فقط: عندما يتم تعيين
aria-atomic='true'واستبدال كتلة النص بالكامل في كل تحديث، تحاول قارئات الشاشة إعادة قراءة المنطقة بأكملها، مما يسبب تجربة مزعجة. استخدمaria-atomic='false'وأضف عقد نصية جديدة بحيث يُعلن فقط الجزء الجديد. - تضمين تغذية الترجمات في عنصر
<canvas>أو كرسوم تراكب على الفيديو: يكون نص الترجمات الذي يُعرض كبيكسلات على canvas أو مدمجاً داخل إطار الفيديو غير مرئي لتقنيات المساعدة. يجب تقديم البدائل النصية كعقد نصية فعلية في DOM. - وضع منطقة الترجمات الحية خارج الشاشة باستخدام
position:absolute; left:-9999px: رغم أن إخفاء المحتوى بصرياً بهذه الطريقة يبقيه في شجرة إمكانية الوصول، فإنه يحرم المستخدمين المبصرين من ذوي فقدان السمع من القدرة على قراءة الترجمات. يجب أن يكون البديل النصي متاحاً بصرياً لجميع المستخدمين، وليس لمستخدمي قارئات الشاشة فقط. - عدم تحديد المتحدثين في البثوث متعددة المتحدثين: لا يكون تدفق الترجمات الذي ينقل الكلام دون نسبته إلى متحدثين محددين (مثل "[الميسّر]:"، "[الرئيس التنفيذي]:"، "[أحد الحضور]:") مكافئاً بالكامل. يعد تحديد المتحدثين ضرورياً لتمكين المستخدمين من متابعة البنية الحوارية للحدث المباشر.
- إغفال المعلومات الصوتية غير الكلامية من البديل النصي: تحمل الأصوات ذات الصلة مثل التصفيق، أو الانقطاعات التقنية، أو الموسيقى الخلفية، أو الإنذارات، أو الضحك محتوى معلوماتياً ويجب وصفها في التغذية النصية (مثل "[تصفيق]"، "[مشكلات تقنية — انقطع الصوت]").
- توفير البديل النصي فقط عبر عنوان URL لطرف ثالث دون تضمينه في نفس الصفحة: اشتراط فتح علامة تبويب أو نافذة متصفح منفصلة للوصول إلى الترجمات بينما يُشغَّل الصوت على الصفحة الأصلية يخلق حاجزاً كبيراً في سهولة الاستخدام، خصوصاً لمستخدمي قارئات الشاشة ومستخدمي لوحة المفاتيح فقط الذين يجب عليهم تبديل السياقات.
- افتراض أن الترجمات التلقائية تلبي دائماً معيار التكافؤ: يمكن أن تكون معدلات الخطأ في الترجمات التي تولدها تقنيات الذكاء الاصطناعي عالية مع الكلام ذي اللكنة، أو المصطلحات التقنية، أو الأسماء العلم، أو الكلام السريع. قد يؤدي نشر ترجمات تلقائية غير مصححة لحدث مباشر عالي المخاطر (مثل إحاطة طبية أو إفصاح مالي) إلى عدم الوفاء بمعيار التكافؤ حتى لو كانت تغذية الترجمات موجودة تقنياً.
- عدم اختبار منطقة النص المباشر باستخدام قارئات الشاشة الفعلية أثناء البث المباشر: تختبر العديد من الفرق المشغّل وحاوية الترجمات بمعزل باستخدام نصوص ثابتة تجريبية، لكنها لا تختبر السلوك الديناميكي أثناء البث المباشر الفعلي. لن تظهر الأخطاء في JavaScript الذي يحقن تحديثات الترجمات — مثل مراقبي تغيّر DOM الذين يفشلون بصمت — إلا أثناء الاختبار المباشر.
العلاقة مع لوائح إمكانية الوصول في تركيا
يضع التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، التزامات ملزمة لإمكانية الوصول على الويب لمجموعة واسعة من المنظمات العاملة في تركيا. يفرض التعميم الالتزام بـ WCAG 2.2 على مستوى AA كمعيار أساسي. تشمل أنواع الكيانات المشمولة المؤسسات والهيئات العامة، ومنصات التجارة الإلكترونية، والبنوك والمؤسسات المالية، والمستشفيات ومقدمي الرعاية الصحية الخاصة، وشركات الاتصالات التي لديها 200,000 مشترك أو أكثر، ووكالات السفر المرخّصة، وشركات النقل الخاصة، والمدارس الخاصة المخوّلة من وزارة التربية الوطنية (MoNE).
يُعد المعيار 1.2.9 من WCAG معياراً من المستوى AAA، ما يعني أنه ليس من بين متطلبات الالتزام التي يفرضها التعميم على مستوى AA الأساسي. لا تكون المنظمات المشمولة بالتعميم الرئاسي 2025/10 ملزمة قانوناً بتنفيذ بدائل نصية للمحتوى الصوتي المباشر فقط ما لم تكن قد التزمت بشكل منفصل بالامتثال الكامل لـ WCAG 2.2 على مستوى AAA.
ومع ذلك، تجعل عدة اعتبارات عملية المعيار 1.2.9 ذا صلة كبيرة بالمنظمات التركية حتى بما يتجاوز الحد الأدنى القانوني الصارم. تقدم شركات الاتصالات، والمؤسسات المالية، وهيئات البث العامة كثيراً من المحتوى الصوتي المباشر — مكالمات المستثمرين، والإعلانات العامة، والبثوث المباشرة لخدمة العملاء — التي يعتمد عليها المستخدمون الصم وضعاف السمع في تركيا. إن إظهار الالتزام بمستوى AAA يشير إلى التزام رائد بإمكانية الوصول ويقلل بشكل كبير من خطر شكاوى التمييز بموجب إطار حقوق الأشخاص ذوي الإعاقة الأوسع في تركيا، بما في ذلك قانون الأشخاص ذوي الإعاقة رقم 5378 ولوائحه التنفيذية.
بالنسبة للمنظمات التي تسعى طوعاً إلى الامتثال لـ WCAG 2.2 على مستوى AAA — سواء لتمييز موقفها في مجال إمكانية الوصول، أو لخدمة أسواق دولية ذات متطلبات أكثر صرامة، أو للتماشي مع معايير المشتريات التي تتطلب مستوى AAA — فإن التنفيذ الصحيح للمعيار 1.2.9 أمر أساسي. توصي Accsible بأن تقوم المنظمات التركية في القطاعات المنظمة بتقييم محتواها الصوتي المباشر بشكل استباقي وتقييم جدوى دمج خدمات CART أو الترجمة النصية عالية الدقة في الوقت الفعلي، خصوصاً للأحداث المباشرة الموجهة للجمهور حيث يكون تكافؤ المعلومات توقعاً ملموساً لأصحاب المصلحة.
المصادر والمراجع
- W3C Understanding 1.2.9 Audio-only (Live)
- W3C Techniques for 1.2.9
- WebAIM: Captions, Transcripts, and Audio Descriptions
- W3C Technique G151: Providing a link to a text transcript of a prepared statement or script
- W3C Technique G157: Incorporating a live audio captioning service into the Web page
- MDN: ARIA live regions
- MDN: The HTML audio element
