امتثال الصوت لمعيار WCAG 2.2 في WordPress: دليل 2026

يجب أن يستوفي الصوت في WordPress أربعة معايير نجاح على الأقل في WCAG 2.2 تشمل 1.4.2 التحكم في الصوت، و2.1.1 لوحة المفاتيح، و2.5.8 حجم الهدف (جديد في 2.2)، و4.1.2 الاسم والدور والقيمة. قانون إمكانية الوصول الأوروبي المطبَّق منذ 28 يونيو 2025 يجعل هذا إلزامياً قانونياً لأي موقع يخدم عملاء في الاتحاد الأوروبي. مشغّل الصوت الافتراضي في WordPress ومعظم الإضافات الصوتية تُخفق في عدد من هذه المتطلبات دون تعديل.

هذا الدليل هو قائمة التحقق العملية التي نستخدمها في Mementor عند مراجعة مواقع WordPress للتحقق من امتثالها لـ WCAG 2.2. نتناول جانبَي الصوت: الصوت كمحتوى له قواعد إمكانية وصول خاصة به، والصوت كأداة إمكانية وصول للمحتوى النصي.

لماذا يهم الامتثال الصوتي في 2026

ثلاثة عوامل تضافرت عام 2025 لتجعل هذا الموضوع ملحّاً. بدأ تطبيق قانون إمكانية الوصول الأوروبي في 28 يونيو 2025. كشف تقرير WebAIM Million لعام 2025 أن 96.3% من الصفحات الرئيسية تحتوي على أخطاء WCAG قابلة للاكتشاف. واستمرت قضايا ADA في الولايات المتحدة في التصاعد، إذ كانت مواقع WordPress حاضرة بكثرة في أكثر من 4000 قضية إمكانية وصول رُفعت خلال العام.

النمط الذي نراه في مراجعاتنا متكرر باستمرار. أصحاب المواقع يفترضون أن القالب يتولى إمكانية الوصول. القالب يرث ما تشحنه الإضافة الصوتية. والإضافة الصوتية تشحن أزراراً صغيرة جداً، وشرائط تحكم تحاصر مستخدمي لوحة المفاتيح، ونسب تباين تفشل عند أول فحص يدوي.

قائمة التحقق الكاملة لـ WCAG 2.2 الخاصة بالصوت

ثمانية معايير نجاح تؤثر مباشرة على الصوت في موقع WordPress. الجدول أدناه يوضح كل معيار من حيث معناه العملي، وما يُصيب مشغّل WordPress الافتراضي صواباً أو خطأً، وكيف يتعامل معه مشغّل TTSWP. المعايير المُشار إليها بـ NEW وصلت مع WCAG 2.2 في أكتوبر 2023.

صفحة متطلبات إمكانية وصول المستخدم للوسائط الصادرة عن W3C هي المرجع الرسمي لهذه المعايير. نركّز على المعايير الثمانية أعلاه لأنها تنطبق على مشغّلات الصوت نفسها. الترجمة النصية (1.2.2) والوصف الصوتي (1.2.3) وثيقان الصلة أيضاً لكنهما يخصّان الفيديو لا التعليق الصوتي الخالص.

استثناء البديل الإعلامي للنص

هذه القاعدة يغفل عنها 95% من المقالات المتعلقة بالامتثال. يُعرِّف WCAG البديل الإعلامي للنص بأنه وسائط لا تقدم معلومات تتجاوز ما هو موجود بالفعل في النص. حين يقرأ التعليق الصوتي التحويلي مقالاً موجوداً، يصبح الصوت بديلاً إعلامياً لنص الصفحة. نص الصفحة نفسه هو النص المكتوب البديل.

هذا يعني أن النسخة الصوتية لمقال ما لا تحتاج إلى ملف نص منفصل. WebAIM يشرح هذا بوضوح. الشرط الوحيد أن يكون الصوت مُعنوَناً بوضوح كبديل إعلامي حتى يدرك المستخدمون أنهم لن يفوّتوا أي معلومة بتخطّيه. عنوان مثل «استمع إلى هذا المقال» أو مشغّل مُعنوَن «النسخة الصوتية من هذا المنشور» يفي بهذا الشرط.

هذا الاستثناء لا ينطبق إذا أضاف الصوت تعليقاً أو موسيقى تحمل معنى أو أقساماً غير موجودة في النص. التعليق الصوتي الخالص لمحتوى الصفحة يؤهَّل للاستثناء. نعتمد على هذا بانتظام حين ننصح عملاء الناشرين الذين يقلقون من أن إضافة الصوت تُنشئ التزامات جديدة بتوفير نصوص مكتوبة.

الجديد في WCAG 2.2 بشأن الصوت

ثلاثة معايير جديدة من المستوى AA تؤثر مباشرة على مشغّلات الصوت.

2.5.8 حجم الهدف (الحد الأدنى)

كل عنصر تحكم تفاعلي يحتاج هدفاً لا يقل عن 24×24 بكسل CSS. هذا هو المعيار الذي يُخفق فيه أكثر إضافات الصوت في WordPress. في مراجعاتنا لمواقع WordPress التي تشغّل إضافات صوتية خارجية، تقصر أزرار التخطي للأمام والخلف باستمرار عن هذا الحد. المصممون البصريون أعطوا الأولوية للإيجاز قبل أن يُقدِّم WCAG 2.2 قاعدة 24 بكسل، وقلة من مطوّري الإضافات لحقوا بهذا التغيير. أحياناً يُقلّص النمط الافتراضي هذه الأهداف أكثر.

الحل عادة في الحشو لا في حجم الأيقونة. أيقونة SVG بحجم 16 بكسل داخل زر بحشو 4 بكسل من كل جانب تصل إلى حد 24 بكسل دون تغيير المظهر البصري.

2.4.11 عدم إخفاء التركيز

الأشرطة الصوتية الثابتة في أسفل الصفحة تغطي ما يكون مستخدم لوحة المفاتيح مُركِّزاً عليه. إذا كان رابط مُركَّز عليه يقع خلف الشريط، يفشل المعيار. الحل إما جعل الشريط قابلاً للإغلاق، أو ترك مسافة فوق عنصر التركيز، أو استخدام scroll-padding-bottom على المستند حتى تبقى العناصر المُركَّز عليها مرئية.

2.5.7 حركات السحب

أشرطة التمرير المخصصة وشرائط الصوت التي تعمل بالسحب فقط تُخفق في هذا المعيار. كل تفاعل بالسحب يحتاج بديلاً بنقرة واحدة. النقر لتحديد الموضع على شريط التقدم يفي بالشرط. كذلك التحكم بمفاتيح الأسهم على role="slider" المبني بالشكل الصحيح.

أبرز أخطاء الصوت الشائعة في WordPress من مراجعات حقيقية

الأنماط تتكرر عبر مواقع العملاء. نرى أربعة أخطاء بصورة منتظمة.

الكتلة الافتراضية <audio> في WordPress تعرض مشغّل المتصفح الأصلي. لعناصر التحكم الصوتية الأصلية في المتصفح تاريخ طويل من السلوك غير المتسق مع قارئات الشاشة، ويتباين التحكم بمفتاح السهم في موضع رأس التشغيل بين Chrome وFirefox وSafari. مستخدمو NVDA أو JAWS كثيراً ما يسمعون الطوابع الزمنية لكنهم لا يستطيعون التحريك الموثوق للموضع بلوحة المفاتيح. الحل لفّ الصوت في مشغّل مخصص يكشف role="slider" مع خصائص ARIA للقيمة المناسبة.

تشحن إضافات المشغّل بأزرار أصغر من حد 24 بكسل. المصمم البصري أعطى الأولوية للإيجاز قبل أن يُقدِّم WCAG 2.2 القاعدة. ثم تتجاوز القوالب أنماط الإضافة، أحياناً تُسوّئ الأمور وأحياناً تُحسّنها.

الأشرطة الصوتية الثابتة تخفي المحتوى المُركَّز عليه. رأينا هذا يفشل في كل موقع يستخدم مشغّلاً ثابتاً في الذيل دون اختبار التنقل بلوحة المفاتيح.

تباين الموجات الصوتية أقل باستمرار من 4.5:1. المصممون يُفضّلون الموجة الرمادية الناعمة على خلفية بيضاء. قارئات الشاشة لا تكترث بذلك، لكن مستخدمي ضعيفي البصر يكترثون، ويفشل المعيار 1.4.3.

بناء مشغّل صوت متوافق: قائمة التحقق التقنية

1. لفّ المشغّل في role="region" مع aria-label يصفه.
2. استخدم <button> حقيقياً للتشغيل والإيقاف المؤقت والتخطي وكتم الصوت. لا تستخدم <div> مع معالج نقر أبداً.
3. عيِّن aria-pressed على زر التشغيل للكشف عن حالة التبديل.
4. امنح كل عنصر تحكم هدفاً لا يقل عن 24×24 بكسل CSS باستخدام الحشو.
5. اجعل شريط التمرير والصوت role="slider" مع aria-valuemin وaria-valuemax وaria-valuenow، وتأكد من استجابته لمفاتيح الأسهم.
6. وفّر النقر لتحديد الموضع على شريط التمرير كبديل للسحب.
7. اختبر التباين على كل عنصر نصي وأيقونة ذات معنى بحد أدنى 4.5:1.
8. تأكد أن حلقات التركيز مرئية ولا تُقطع بقواعد الفائض.
9. إذا كان المشغّل ثابتاً، اترك مساحة فوق عنصر التركيز أو اجعله قابلاً للإغلاق.
10. عنوِن مشغّلات تحويل النص إلى كلام بـ «النسخة الصوتية من هذا المقال» حتى ينطبق استثناء البديل الإعلامي بوضوح.

زر تشغيل أساسي يستوفي متطلبات إمكانية الوصول يبدو هكذا.

<div role="region" aria-label="Article audio player">
  <button type="button"
          aria-pressed="false"
          aria-label="Play article narration"
          style="min-width:24px;min-height:24px;padding:8px">
    <svg aria-hidden="true" width="16" height="16">...</svg>
  </button>
  <input type="range"
         aria-label="Playback position"
         min="0" max="100" value="0">
</div>

هذا هو الهيكل الأساسي. نسِّق الزر، واخفِ مظهر النطاق الأصلي إن أردت مساراً مخصصاً، لكن حافظ على الدلالات الأساسية.

كيف يُحسِّن تحويل النص إلى كلام الامتثال الكلي لـ WCAG

الصوت ليس مجرد محتوى يحتاج إمكانية وصول. هو بحد ذاته أداة إمكانية وصول. تُقدِّر منظمة الصحة العالمية أن 1.3 مليار شخص، أي نحو 16% من سكان العالم، يعيشون مع إعاقة ملحوظة. كثيرون منهم يستفيدون من الوصول المتعدد الوسائط للمحتوى النصي: الأشخاص الذين يعانون من عسر القراءة، واضطراب نقص الانتباه، وضعف البصر، والإعاقات المعرفية المختلفة يقرؤون بصورة أريح حين يرافق الصوتُ النصَّ.

إضافة تحويل النص إلى كلام هي من الاستثمارات القليلة في إمكانية الوصول التي تفيد المستخدمين قبل أن تستوفي متطلبات المراجعة. إضافة تحويل النص إلى كلام في WordPress لا تأخذ أكثر من 15 دقيقة مع إضافة TTSWP - تحويل النص إلى كلام. يشحن المشغّل بإعدادات افتراضية متوافقة مع WCAG 2.1 AA، وأهداف لا تقل عن 24 بكسل، ودعم لوحة مفاتيح، وأدوار ARIA صحيحة.

الحمل الأدنى في وقت التشغيل نحو 35 إلى 40 كيلوبايت مضغوطاً (151 كيلوبايت غير مُصغَّر) يغطي منطق مشغّل JavaScript وCSS المشترك. أجرينا اختبار GTmetrix على مقال منشور بالمشغّل النشط وحصلنا على تقدير A مع أداء 93%، وهيكل 99%، وأكبر رسم محتوى عند 1.3 ثانية، وإجمالي وقت الحجب عند 46 ميلي ثانية، وانزياح تخطيط تراكمي صفري. الحزمة تُحمَّل بتكاسل فقط على الصفحات التي تحتوي على المشغّل، لذا الصفحات الثابتة دون صوت لا تحمل أي عبء إضافي.

توثيق إمكانية الوصول متاح في صفحة الثقة لدينا. يعتمد التعليق الصوتي على محرك ElevenLabs التوليدي، الذي يُحسِّن النبر بما يكفي لجعل المستمعين يُكملون المقالات بدلاً من التخلي عنها حين يجدونها آلية الصوت.

قانون إمكانية الوصول الأوروبي على أرض الواقع

بات قانون إمكانية الوصول الأوروبي قابلاً للتطبيق منذ 28 يونيو 2025. الخدمات الرقمية الجديدة المطروحة في السوق الأوروبية بعد ذلك التاريخ يجب أن تمتثل الآن. الخدمات القائمة لديها حتى 28 يونيو 2030 لاستيفاء جميع المتطلبات. يسري التوجيه على أي شركة تخدم عملاء في الاتحاد الأوروبي بصرف النظر عن مقرها.

المعيار التقني الذي يستند إليه القانون هو EN 301 549. النسخة المنسجمة الحالية (V3.2.1، أغسطس 2021) مبنية على WCAG 2.1 المستوى AA. المسودة V4.1.0 الصادرة في نوفمبر 2025 تُحدِّث البنود 9 و10 و11 لتتوافق مع WCAG 2.2، مع توقع الانسجام النهائي خلال 2026. حتى تُدرَج هذه التحديثات في الجريدة الرسمية للاتحاد الأوروبي، يبقى WCAG 2.1 AA هو الحد الأدنى الملزم قانونياً، لكننا نوصي باستهداف 2.2 الآن لأن الانتقال أشهر لا سنوات.

تتفاوت العقوبات بحسب الدولة العضو. ألمانيا وفرنسا لديهما البنية التحتية الأكثر نشاطاً في التنفيذ، مع سلطات وطنية لإمكانية الوصول مخوَّلة بالتحقيق في الشكاوى وإصدار الغرامات. رأينا عملاء من النرويج وألمانيا يتلقون شكاوى رسمية من المستخدمين النهائيين في غضون أشهر من تاريخ التطبيق، عادة بشأن مكوّنات الصوت والنماذج. الشكاوى تسبق الغرامات، لذا نافذة إصلاح مدتها ثلاثون يوماً عادة ما تكون قابلة للتحقيق إذا كان الفريق مستعداً.

كيف تختبر الامتثال

الأدوات الآلية ترصد نحو 30 إلى 40 بالمئة من المشكلات. الاختبار اليدوي ضروري للباقي، لا سيما تفاعل لوحة المفاتيح والتباين ذو المعنى في الحالات الديناميكية.

• NVDA على Windows مع Chrome وFirefox. مجاني.
• JAWS على Windows لتوقعات عملاء المؤسسات.
• VoiceOver على macOS وiOS. مدمج في النظام.
• TalkBack على Android. مدمج في النظام.
• axe DevTools امتداد المتصفح للفحص الآلي.
• Lighthouse في Chrome DevTools للفحص السريع.
• الجولة باستخدام لوحة المفاتيح فقط. افصل الفأرة وشغِّل كل عنصر تحكم في المشغّل.

الجولة باستخدام لوحة المفاتيح فقط هي الاختبار الأعلى تأثيراً. إذا عمل المشغّل دون فأرة، فمعظم WCAG 2.2 يكون مستوفىً بالفعل.

أسئلة شائعة

هل يشترط WCAG 2.2 ترجمات نصية للبودكاست الصوتي؟

لا. الترجمات النصية (1.2.2) تنطبق على الفيديو المسجَّل مسبقاً مع الصوت المتزامن. بالنسبة للمحتوى الصوتي فقط كالبودكاست، المعيار المعني هو 1.2.1 الذي يشترط بديلاً نصياً كنص مكتوب أو ملخص تفصيلي. الترجمات النصية والنصوص المكتوبة تخدمان غرضين مختلفين. البودكاست يحتاج النص المكتوب. الفيديو التعليمي يحتاج كليهما مع وصف صوتي للمعلومات البصرية فقط.

هل التشغيل التلقائي للصوت مخالف للقانون بموجب قانون إمكانية الوصول الأوروبي؟

ليس مخالفاً مباشرة، لكنه مقيَّد. المعيار 1.4.2 التحكم في الصوت الذي يستند إليه القانون عبر EN 301 549 يشترط أن أي صوت يعمل تلقائياً لأكثر من ثلاث ثوانٍ يجب أن يوفر إيقافاً مؤقتاً أو كاملاً أو تحكماً مستقلاً في الصوت. التشغيل التلقائي دون ذلك التحكم يُخفق في المستوى A ويُنشئ حالة عدم امتثال. معظم هيئات التنفيذ تعتبر هذا انتهاكاً صريحاً لا حالة حدية.

هل أحتاج نصاً مكتوباً إذا كان لديّ نسخة صوتية من مقالتي؟

في الغالب لا. حين يكون الصوت تعليقاً مباشراً لنص المقال دون إضافة معلومات جديدة، يصبح نص المقال نفسه هو النص المكتوب وفق تعريف WCAG لـ «البديل الإعلامي للنص». عنوِن المشغّل بوضوح كنسخة صوتية من المقال وينطبق الاستثناء. إذا تضمّن الصوت تعليقاً أو موسيقى ذات معنى أو أجزاء غير موجودة في النص، فأنت تحتاج نصاً مكتوباً منفصلاً.

ما الحد الأدنى لحجم الزر في مشغّلات الصوت وفق WCAG 2.2؟

يجب أن تكون الأهداف التفاعلية 24×24 بكسل CSS على الأقل بموجب معيار النجاح 2.5.8 حجم الهدف (الحد الأدنى) عند المستوى AA. الهدف يشمل الحشو، لذا أيقونة بحجم 16 بكسل مع حشو 4 بكسل من كل جانب تستوفي الشرط. توجد استثناءات للروابط المضمَّنة في النص والعناصر التي يتحكم فيها وكيل المستخدم، لكن أزرار المشغّل المستقلة لا استثناء لها ويجب أن تصل إلى الحد المطلوب.

هل ينطبق WCAG 2.2 على المواقع المستضافة على WordPress.com؟

نعم. ينطبق WCAG على أي محتوى ويب بصرف النظر عن منصة الاستضافة. مواقع WordPress.com تحمل نفس المسؤولية القانونية بموجب قانون إمكانية الوصول الأوروبي وADA والقوانين الوطنية المعادلة تماماً كـ WordPress ذاتي الاستضافة. نموذج الاستضافة لا يُغيِّر الالتزام. ما يتغير هو مقدار التحكم الذي يملكه صاحب الموقع على ترميز المشغّل. خطط Business وCommerce في WordPress.com تسمح بإضافات مخصصة، أما الخطط الأقل فلا.

من أين تبدأ

اختر منشوراً واحداً على موقعك، وأجرِ جولة بلوحة المفاتيح فقط على مشغّل الصوت، وتحقق من كل زر وفق قاعدة 24 بكسل. هذه المراجعة الواحدة تكشف ما إذا كان إعدادك الحالي قريباً من متوافق مع WCAG 2.2 أم بعيداً. من هناك، الخيار بين إصلاح المشغّل القائم أو استبداله بمشغّل يشحن متوافقاً بشكل افتراضي. توثيق إمكانية الوصول لدينا يغطي الإعداد الذي نوصي به للمواقع الخاضعة لضغط قانون إمكانية الوصول الأوروبي.