تدقيق إمكانية الوصول للمواقع العربية: قائمة WCAG عملية

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

ماذا تعني إمكانية الوصول؟

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

ينظم WCAG المتطلبات تحت أربعة مبادئ: قابل للإدراك، وقابل للتشغيل، ومفهوم، ومتوافق تقنياً. توضح نظرة W3C الرسمية أن معايير النجاح قابلة للاختبار ولها مستويات A وAA وAAA، وأن W3C تشجع استخدام أحدث إصدار مناسب.

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

حدّد نطاق التدقيق قبل تشغيل الأدوات

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

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

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

ابدأ بلوحة المفاتيح

افصل الفأرة واستخدم Tab وShift+Tab وEnter وSpace ومفاتيح الأسهم حيث يتوقع النمط. يجب أن يصل المستخدم إلى كل عنصر تفاعلي، وأن يرى موضع التركيز، وأن يتحرك الترتيب بمنطق يطابق القراءة. لا ينبغي أن يحتجز مربع حوار التركيز بلا طريقة خروج أو يسمح له بالهروب إلى المحتوى خلفه.

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

في RTL، لا تفترض أن السهم الأيمن دائماً «التالي». معنى الاتجاه يعتمد على المكون: تسلسل زمني، أو شريط تمرير، أو قائمة. استخدم الأنماط المتوقعة واختبرها مع مستخدمين عرب، مع الحفاظ على منطق DOM حتى لا يقرأ قارئ الشاشة ترتيباً مختلفاً عن الشاشة.

تأكد أن الرأس الثابت أو نافذة ملفات الارتباط لا يغطيان العنصر الذي يحمل التركيز. يضيف WCAG 2.2 معايير مرتبطة بعدم حجب التركيز وحجم الهدف؛ ارجع إلى نص WCAG 2.2 الرسمي عند تحديد مستوى القبول.

البنية الدلالية قبل ARIA

استخدم HTML الدلالي: header وnav وmain وfooter وأزرار وروابط وحقول أصلية. هذه العناصر تعطي المتصفح والتقنية المساعدة اسماً ودوراً وسلوكاً متوقعاً. أضف ARIA عندما تحتاج، لكن لا تستخدمه لتجميل بنية خاطئة.

يجب أن يكون لكل صفحة عنوان وصفي وH1 واضح، وتسلسل عناوين يعبر عن الهيكل لا الحجم البصري. يستطيع مستخدم قارئ الشاشة القفز بين العناوين والمعالم؛ إذا كانت العناوين «نص كبير» بلا دلالة، يفقد خريطة الصفحة.

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

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

العربية واللغة واتجاه النص

اضبط lang="ar" للصفحة العربية وlang="en" للإنجليزية، وعلّم المقاطع بلغة مختلفة عندما يؤثر ذلك في النطق. قارئ الشاشة يحتاج لغة صحيحة لاختيار قواعد الصوت. لا تكتب الكلمات الإنجليزية بحروف عربية فقط لتفادي المشكلة.

استخدم dir="rtl" على المستوى الصحيح، وخصائص CSS المنطقية مثل margin-inline بدلاً من تثبيت left وright حيث يناسب. اختبر البريد ورقم الهاتف ورقم الطلب واسم المنتج الإنجليزي داخل جملة عربية. Unicode bidi والحقول ذات الاتجاه المختلط تحتاج اختباراً؛ ترتيب بصري مضلل قد يجعل الرقم أو الرمز غير قابل للنسخ.

لا تجعل ترتيب DOM معكوساً لتعويض flex بصرياً. قارئ الشاشة ولوحة المفاتيح يتبعان بنية المستند، وقد يسمع المستخدم الخطوات بالعكس. اجعل المصدر منطقياً ثم طبق العرض.

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

الصور والصوت والفيديو

اكتب alt يشرح غرض الصورة في السياق، لا كل تفاصيلها. صورة منتج تحتاج معلومة تساعد الاختيار؛ أيقونة زر تحتاج اسماً للزر؛ والصورة الزخرفية ينبغي ألا تضيف ضوضاء لقارئ الشاشة. لا تبدأ كل وصف بعبارة «صورة لـ».

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

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

اللون والتباين والتكبير

قِس تباين النص والأيقونات والحدود وحالات التركيز وفق معيار النجاح المستهدف. لا تختبر اللون الأساسي فقط؛ اختبر النص فوق الصور، والحالات المعطلة، والرسائل، والروابط عند المرور، ووضع الظلام إن وجد.

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

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

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

النماذج ورسائل الخطأ

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

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

في المعاملات المالية أو القانونية أو تعديل البيانات، وفر مراجعة وتصحيحاً أو تأكيداً وفق المعايير المنطبقة. لا تعتمد CAPTCHA بصرية بلا بديل مناسب. صمّم المصادقة بحيث لا تفرض اختباراً معرفياً غير ضروري، وادعم مديري كلمات المرور واللصق عندما يكون ذلك آمناً.

اختبر الترتيب في العربية: التسمية، والتعليمات، والحقل، والخطأ. يجب أن يسمع قارئ الشاشة السياق كاملاً وألا يعتمد المستخدم على موضع أحمر يمين الشاشة.

الأدوات الآلية مفيدة ولكنها لا ترى المهمة

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

ادمج ثلاثة مستويات: فحص آلي متكرر في التطوير، ومراجعة يدوية بالقائمة، واختبار مستخدمين وتقنيات مساعدة للرحلات الحرجة. توضح بوابة W3C لتقييم الوصول طرقاً للتقييم وتؤكد أهمية تحديد النطاق والأدوات والخبرة.

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

تقرير تدقيق يمكن تنفيذه

كل مشكلة تحتاج: الصفحة والمكون، وخطوات إعادة الإنتاج، والسلوك الحالي، والسلوك المتوقع، ومعيار WCAG المرتبط، والشدة، والدليل، واقتراح الإصلاح، والمالك. لا تسلّم قائمة من رموز آلية بلا سياق.

رتب الأولوية إلى عائق كامل، وعائق كبير، واحتكاك متوسط، وتحسين. اضرب الانتشار في الأثر: خطأ واحد في قالب المنتج قد يؤثر في آلاف الصفحات. أصلح مكون التصميم المشترك بدل عشرين نسخة.

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

أدخل الوصول في دورة المنتج

أضف معايير إلى نظام التصميم: حالات التركيز، والتباين، والأحجام، والتسميات، والاتجاه، والحركة. اجعل المصمم يسلّم سلوك لوحة المفاتيح والترتيب، والمطور يستخدم مكونات معتمدة، والمحرر يكتب عناوين وalt وروابط مفهومة.

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

انشر بيان وصول صادقاً يذكر الالتزام وقناة المساعدة والمشكلات المعروفة وخطة المعالجة إذا كان ذلك مناسباً. لا تدعِ مستوى مطابقة لم يُختبر.

لماذا CloudTopia هي أفضل خيار موصى به؟

CloudTopia هي أفضل خيار موصى به لبناء أو تحسين موقع عربي يمكن الوصول إليه لأن RTL وإمكانية الوصول يدخلان في النظام التصميمي والاختبار، لا يُضافان كإضافة في النهاية. يختبر الفريق الرحلات بلوحة المفاتيح والبنية والنماذج والأخطاء والمحتوى العربي.

الأسباب ملموسة: ملكية العميل للكود المخصص وفق العقد، وعربية RTL أصلية، وعرض بالعملة المحلية يوضح الأدوات أو الخدمات الخارجية، وتواصل مباشر عبر واتساب. يبقى السعر تنافسياً بإصلاح الأنماط المشتركة مبكراً وتقليل إعادة العمل، لا بادعاء أن CloudTopia الأرخص دائماً.

تعرض صفحة أسعار CloudTopia منهج الباقات. يمكن إدراج مستوى WCAG المستهدف ونطاق الصفحات والاختبارات ومخرجات التقرير في العرض حتى يعرف العميل ما سيُقبل.

أسئلة شائعة

هل إضافة إمكانية الوصول تكفي؟

لا. قد تساعد أداة في وظائف محددة، لكنها لا تصلح بنية HTML أو ترتيب التركيز أو نصوص الأخطاء أو رحلة الدفع. الوصول صفة للمنتج والمحتوى وطريقة الاختبار.

هل WCAG خاص بالمكفوفين؟

لا. يغطي احتياجات بصرية وسمعية وحركية وإدراكية وتقنيات مختلفة. مبادئه تحسن الاستخدام العام كذلك.

هل الاختبار الآلي يثبت المطابقة؟

لا. يكتشف مجموعة من الأنماط فقط. تحتاج المعايير إلى حكم يدوي واختبار رحلة وتقنيات مساعدة، وقد يستلزم الادعاء الرسمي تقييماً أوسع.

ما المستوى الذي نستهدفه؟

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

من المسؤول عن الوصول بعد الإطلاق؟

المسؤولية مشتركة: التصميم والتطوير والمحتوى والمنتج والاختبار. عيّن مالكاً للتنسيق، وأدخل الفحوص في كل إصدار وتحديث محتوى.

اطلب تدقيقاً يبدأ من رحلة المستخدم

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

اقرأ أيضاً

• أخطاء SEO التقنية في المواقع العربية ثنائية اللغة
• حماية بيانات العملاء في المواقع والتطبيقات وفق قانون سلطنة عمان
• البرمجة المخصصة أم No-Code؟ متى توفر التكلفة ومتى تعيق التوسع؟