إتاحة الويب (WCAG) للمنتجات الحقيقية: دليل عملي
ما الذي تتطلبه WCAG 2.2 AA فعليًا، والعيوب التي تعطّل المنتجات، وكيف تبني الإتاحة دون إبطاء التسليم.
يفتح أحد عملائك صفحة الدفع على هاتفه، ويضغط على زر "ادفع الآن"، فلا يحدث شيء — لأنه يتصفح باستخدام قارئ شاشة، والزر مبني في الأصل كعنصر <div> منسّق بلا دور (role) ولا تسمية (label). يترك العميل سلته ويغادر. وأنت لا ترى السبب أبدًا، لأن أدوات التحليل لا تسجّل سوى جلسة أخرى انتهت بالانسحاب.
هذه هي التكلفة الحقيقية للبرمجيات غير المتاحة: إيرادات ضائعة، وتذاكر دعم، وفي عدد متزايد من الأسواق مسؤولية قانونية. إتاحة الويب (Accessibility) ليست ميزة خيرية تُضاف في النهاية، بل هي خاصية جودة في المنتج، تمامًا كالأداء والأمان. يشرح هذا المقال ما الذي تطلبه معايير WCAG فعليًا، وأين تتعثّر الفرق، وكيف تبني الإتاحة داخل منتجات حقيقية دون أن تُبطئ التسليم.
ما الذي تعنيه WCAG فعليًا
اختصار WCAG يشير إلى "إرشادات إتاحة محتوى الويب"، التي يشرف عليها اتحاد W3C. وهي المعيار المرجعي الذي يستند إليه تقريبًا كل قانون إتاحة وكل اشتراط في المناقصات الحكومية، من قانون الإتاحة الأوروبي إلى Section 508 الأمريكي وصولًا إلى معايير الحكومة الرقمية في السعودية. حين يقول أحدهم "نحتاج إلى الالتزام بمعايير a11y"، فإنه يقصد WCAG سواء عرف ذلك أم لا.
تنتظم هذه الإرشادات حول أربعة مبادئ تُختصر غالبًا بكلمة POUR:
- قابلية الإدراك (Perceivable) — أن يدرك المستخدم المحتوى. للصور بدائل نصية، وللفيديو ترجمة مكتوبة، والتباين اللوني عالٍ بما يكفي للقراءة.
- قابلية التشغيل (Operable) — أن يتمكن المستخدم من تشغيل الواجهة. كل شيء يعمل بلوحة المفاتيح، ولا وميض خطر، والأهداف كبيرة بما يكفي للنقر عليها.
- قابلية الفهم (Understandable) — أن تتصرّف الواجهة بشكل متوقّع، وأن تُشرح الأخطاء بلغة واضحة.
- المتانة (Robust) — أن تكون البنية البرمجية نظيفة بما يكفي لتفسرها التقنيات المساعدة بشكل موثوق، الآن ومستقبلًا.
لمعايير WCAG ثلاثة مستويات للمطابقة: A (الحد الأدنى)، وAA (الهدف العملي الذي يستهدفه الجميع تقريبًا)، وAAA (مستوى طموح نادرًا ما يُطلب عبر المنتج كاملًا). بالنسبة لأغلب المنتجات التجارية، فإن WCAG 2.2 المستوى AA هو المعيار الصحيح. وهو ما تتوقعه الجهات التنظيمية وما يضعه عملاء المؤسسات في عقودهم.
العيوب التي تُعطّل المنتجات فعلًا
في قواعد الأكواد الحقيقية، تتجمّع إخفاقات الإتاحة حول حفنة من الأخطاء المتكررة. أصلحها فتتخلّص من غالبية ما سيكشفه أي تدقيق.
بنية غير دلالية (Non-semantic)
المشكلة الأكثر شيوعًا هي بناء العناصر التفاعلية من حاويات عامة. فالعنصر <div onclick> غير مرئي للوحة المفاتيح ولا لقارئ الشاشة. استخدم العنصر الحقيقي — <button> و<a> و<input> — فتحصل على معالجة التركيز، والتفعيل بلوحة المفاتيح، والدور الصحيح مجانًا. ولا تلجأ إلى أدوار ARIA إلا حين لا يناسب أيُّ عنصر أصلي.
تسميات مفقودة أو خاطئة
حقول النماذج بلا <label> مرتبط، وأزرار الأيقونات بلا اسم متاح، والصور ذات نص alt الفارغ أو الزخرفي غير المُعلَن — كلها تترك المستخدم يخمّن. أيقونة العدسة المكبّرة تحتاج إلى aria-label="بحث"، أما الصورة الرئيسية التي لا تضيف معنى دلاليًا فينبغي أن تحمل alt="" ليتجاوزها قارئ الشاشة.
تباين منخفض
النص الرمادي الفاتح على خلفية بيضاء يبدو أنيقًا في التصميم المبدئي، لكنه غير مقروء لكثير من المستخدمين، بمن فيهم أيُّ شخص يقف تحت شمس الخليج. يتطلب المستوى AA نسبة تباين لا تقل عن 4.5:1 للنص العادي و3:1 للنص الكبير. وهذا أسهل العيوب اكتشافًا وأكثرها شحنًا في الإصدارات.
مصائد لوحة المفاتيح والتركيز غير المرئي
إذا تمكّن المستخدم من الدخول إلى نافذة منبثقة (modal) بمفتاح Tab دون أن يستطيع الخروج منها، أو إذا أُزيل مؤشر التركيز عبر outline: none لأسباب جمالية، تصبح الواجهة غير قابلة للاستخدام دون فأرة. أبقِ على حالة تركيز مرئية، واحرص على أن ينتقل التركيز بترتيب منطقي.
اللون كإشارة وحيدة
عبارة "الحقول المطلوبة باللون الأحمر" أو "الأخطاء مظللة بالأحمر" تُخفق مع أي شخص مصاب بعمى الألوان. اقرن اللون بأيقونة أو نص أو نمط حتى يبقى المعنى قائمًا من دونه.
الإتاحة للمنتجات العربية وثنائية اللغة
تتحمّل الفرق التي تبني للخليج ومصر مسؤولية إضافية تتجاهلها أغلب نصائح الإتاحة العامة: دعم الاتجاه من اليمين إلى اليسار (RTL) والواجهات ثنائية اللغة.
- اضبط اللغة والاتجاه على المستند:
<html lang="ar" dir="rtl">، وبدّلهما معًا عند تغيير المستخدم للغة. تستخدم قارئات الشاشة سمةlangلاختيار الصوت والنطق الصحيحين. - استخدم خصائص CSS المنطقية (
margin-inline-startوpadding-inline-end) بدلًا من قيم اليمين واليسار الثابتة، حتى تنعكس التخطيطات بشكل صحيح في الاتجاه RTL. - اختبر التجربة العربية الفعلية بقارئ شاشة، لا الإنجليزية فقط. فالمحتوى المختلط الاتجاه — اسم علامة تجارية إنجليزي داخل جملة عربية، أو سعر بأرقام لاتينية — هو حيث تختبئ العيوب.
تدعم أطر العمل مثل Next.js وFlutter الاتجاهية والتعريب جيدًا، لكن الإعدادات الافتراضية نادرًا ما تغطي الحالات الحدّية ثنائية اللغة بمفردها. لا بد من تفعيلها بشكل متعمّد.
كيف تبنيها دون أن تُبطئ التسليم
تفشل الإتاحة حين تُعامَل كبوابة جودة نهائية. فعند ذلك تكون البنية قد رسّخت المشكلات، ويعني إصلاحها إعادة عمل. أما الفرق الناجحة فتنقل العمل إلى مرحلة مبكرة وتُؤتمت الأجزاء المملّة.
- ابدأ في التصميم. حدّد نسب التباين وحالات التركيز والحد الأدنى لأحجام الأهداف داخل نظام التصميم. فإذا كانت مكتبة المكوّنات متاحة، ورثت كل شاشة هذه الإتاحة.
- افحص واختبر في الـ CI. تكشف أدوات مثل axe-core وLighthouse وpa11y نسبة كبيرة من المشكلات تلقائيًا في كل طلب دمج (pull request). لن تجد كل شيء، لكنها توقف التراجعات مجانًا.
- اختبر بلوحة المفاتيح وقارئ شاشة. لا تستطيع الأدوات الآلية الحكم على ما إذا كان المسار منطقيًا. اقضِ عشر دقائق في التنقل داخل ميزة بلوحة المفاتيح وحدها ومع VoiceOver أو NVDA أو TalkBack. تظهر أغلب العيوب الجادة فورًا.
- اكتب معايير قبول على مستوى المكوّن. عبارة "الزر يمكن الوصول إليه بلوحة المفاتيح ويُعلن عن تسميته" تنتمي إلى التذكرة، لا إلى تدقيق منفصل بعد ستة أشهر.
تكتشف الفحوص الآلية عادةً جزءًا فقط من الحواجز الواقعية؛ أما البقية فتتطلب حكمًا بشريًا. خصّص ميزانية للاثنين معًا. التصميم الشامل (inclusive design) أرخص ما يكون حين يكون مستمرًا، وأغلى ما يكون حين يتحوّل إلى هرولة في اللحظة الأخيرة قبل إطلاق أو موعد قانوني.
أهم النقاط
- WCAG 2.2 المستوى AA هو هدف المطابقة العملي للمنتجات التجارية، وهو المعيار الذي تتوقعه الجهات التنظيمية وعملاء المؤسسات.
- تأتي أغلب عيوب الإتاحة من قائمة قصيرة: بنية غير دلالية، وتسميات مفقودة، وتباين منخفض، ودعم معطّل للوحة المفاتيح، وإشارات تعتمد على اللون وحده.
- تحتاج المنتجات الخليجية والمصرية ثنائية اللغة إلى معالجة متعمّدة للاتجاه RTL ولسمتي
langوdir— فالإتاحة ودعم العربية مشكلة واحدة. - ابنِ الإتاحة داخل نظام التصميم وخط أنابيب الـ CI؛ تكشف الأدوات الآلية المشكلات السهلة، ويكشف الاختبار البشري الباقي.
- التصميم الشامل خاصية جودة لا ميزة — يردّ تكلفته في عملاء محتفَظ بهم، ودعم أقل تكلفة، ومخاطر قانونية أخفض.
الإتاحة المُتقنة غير مرئية: تعني ببساطة أن مزيدًا من الناس يستطيعون استخدام ما بنيته، على أجهزة أكثر، وفي ظروف أكثر. إن أردت منتجًا يحقق معايير WCAG دون التضحية بالسرعة أو الإتقان، يمكن لـ SummationWorks المساعدة — من تدقيق إتاحة موقع قائم إلى بنائها منذ أول سطر برمجي. تعرّف على خدماتنا، واطّلع على أعمالنا، أو تواصل معنا لنناقش منتجك.
عن الكاتب
SummationWorks
SummationWorks is a software development company building web apps, mobile apps, and AI tools for startups and growing businesses across the US, UK, and GCC.
المزيد عنّامقالات ذات صلة
engineeringبناء تطبيقات ويب سريعة في 2026
كيف نطلق تطبيقات ويب جاهزة للإنتاج تُحمّل فورًا وتتوسع — التقنيات، والمفاضلات، والعادات التي تقف خلف ذلك.
engineeringتحديد معدل الطلبات والحماية من الإساءة في الـ API: دليل عملي
كيف يحافظ rate limiting والحماية من الإساءة على استقرار الـ backend: استراتيجيات throttling ودفاعات متعددة الطبقات وحدود لا تعاقب المستخدمين الحقيقيين.
engineeringالنشر على App Store و Play Store: كيف تتجنّب الرفض
معظم حالات رفض التطبيقات يمكن تفاديها. دليل عملي لاجتياز مراجعة App Store و Play Store من أول محاولة، من الخصوصية إلى المدفوعات.