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

تخيّل أن تقضي ساعات في إتقان تصميم موقعك الإلكتروني، لتكتشف في النهاية أن جزءًا كبيرًا من زوّارك لا يستطيع استخدامه إطلاقًا. هذه هي الحقيقة بالنسبة لما يقرب من 1.3 مليار شخص حول العالم — حوالي 16% من سكان العالم — ممّن يعيشون مع شكل من أشكال الإعاقة. وفقًا لتقرير WebAIM Million 2025، لا يزال 94.8% من المواقع تحتوي على الأقل على فشل واحد قابل للكشف في إمكانية الوصول، مع وجود أكثر من 51 خطأ مميز في إمكانية الوصول في متوسط الصفحة الرئيسية. الخبر الجيد: هناك إطار عمل مبدئي يقطع الضوضاء ويخبرك بالضبط كيف يجب أن يبدو محتوى الويب القابل للوصول. يُسمّى هذا الإطار POUR.

ما هو POUR ومن أين أتى؟

POUR هو اختصار لأربعة مبادئ أساسية تقوم عليها إرشادات إمكانية الوصول لمحتوى الويب (WCAG): قابل للإدراك (Perceivable)، قابل للتشغيل (Operable)، قابل للفهم (Understandable)، ومتين (Robust). تُنشر هذه الإرشادات وتُحدَّث من قبل اتحاد شبكة الويب العالمية (W3C) من خلال مبادرة إمكانية الوصول للويب (WAI)، وتُعد WCAG المعيار المعترف به دوليًا لإمكانية الوصول على الويب. الإصدار المستقر الحالي — WCAG 2.2 — ينظم جميع إرشاداته الـ 13 وعشرات معايير النجاح القابلة للاختبار ضمن هذه المبادئ الأربعة.

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

فهم POUR مهم بما يتجاوز الالتزام الأخلاقي. القوانين واللوائح حول العالم — مثل قانون الأمريكيين ذوي الإعاقة (ADA) في الولايات المتحدة، وقانون إمكانية الوصول الأوروبي (EAA) في الاتحاد الأوروبي، وقانون المساواة في المملكة المتحدة — تعتمد على WCAG كمعيار تقني لها. عندما تواجه شركة دعوى قضائية تتعلق بإمكانية الوصول، يمكن تتبع الشكوى في الغالب إلى فشل في واحد أو أكثر من مبادئ POUR. في عام 2025 وحده، تم رفع 5,114 دعوى قضائية تتعلق بإمكانية الوصول الرقمي بموجب ADA، وكانت شركات التجارة الإلكترونية القطاع الأكثر استهدافًا. معرفة POUR تعني، عمليًا، معرفة حجم تعرضك القانوني.

كل مبدأ يتفرع إلى إرشادات — أهداف عامة — وهذه الإرشادات تتفرع إلى معايير نجاح محددة وقابلة للاختبار تُصنَّف على مستوى A (الحد الأدنى)، ومستوى AA (قوي — وهو المعيار الأكثر شيوعًا)، ومستوى AAA (معزَّز). بقية هذا الدليل يستعرض كل مبدأ بعمق، مع أمثلة عملية وأنماط برمجية يمكنك تطبيقها فورًا.

المبدأ 1: قابل للإدراك — إذا لم يتمكنوا من اكتشافه، فهو غير موجود

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

الإرشادات الأربعة في WCAG تحت مبدأ قابل للإدراك هي: البدائل النصية، الوسائط الزمنية، المحتوى القابل للتكيّف، والمحتوى المميَّز. البدائل النصية (الإرشاد 1.1) تتطلب أن يكون لكل عنصر غير نصي — الصور، الأيقونات، المخططات، الإنفوغرافيك، الملفات الصوتية، الفيديو — مكافئ نصي يؤدي الغرض نفسه. صورة تُستخدم كرابط للصفحة الرئيسية يجب أن تحتوي على نص بديل مثل "العودة إلى الصفحة الرئيسية"، وليس "logo.png" أو سلسلة فارغة. الصور الزخرفية، من ناحية أخرى، يجب أن تستخدم alt='' حتى تتجاوزها قارئات الشاشة تمامًا، مما يمنع الضوضاء غير الضرورية.

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

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

المحتوى المميَّز (الإرشاد 1.4) يحكم التباين، وتكبير النص، والتحكم في الصوت. يتطلب WCAG 2.2 على مستوى AA نسبة تباين لا تقل عن 4.5:1 للنص العادي و3:1 للنص الكبير. النص منخفض التباين هو أكثر فشل شيوعًا في إمكانية الوصول على الويب: في تحليل WebAIM Million في فبراير 2026، وُجد النص منخفض التباين في 83.9% من الصفحات الرئيسية، بمتوسط 34 حالة مميزة لكل صفحة. يجب أيضًا أن يظل النص قابلاً للقراءة عند تكبيره حتى 200% دون فقدان المحتوى أو الوظيفة، وألا يفقد أي محتوى معلوماته عند عرضه بعرض 320 بكسل CSS (معيار إعادة التدفق، 1.4.10).

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

إليك مقارنة سريعة بين وسم صورة غير قابل للوصول وآخر قابل للوصول:

<!-- Inaccessible: no alt attribute -->
<img src='product-chart.png'>

<!-- Accessible: descriptive alt text -->
<img src='product-chart.png' alt='Bar chart showing a 40% increase in Q3 revenue compared to Q2'>

<!-- Decorative image: tell assistive tech to skip it -->
<img src='divider-wave.png' alt='' role='presentation'>

المبدأ 2: قابل للتشغيل — يجب أن تعمل كل وظيفة مع كل طريقة إدخال

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

الإرشاد 2.1 يتطلب أن تكون كل الوظائف متاحة من لوحة المفاتيح. هذا يعني أن كل عنصر تفاعلي — الروابط، الأزرار، عناصر النماذج، الودجات المخصصة، أشرطة التمرير، منتقيات التاريخ، مربعات الحوار المنبثقة — يجب أن يكون قابلاً للوصول عبر مفتاح Tab وقابلاً للتشغيل عبر أوامر لوحة المفاتيح. والأهم من ذلك، يجب ألا تكون هناك "مصائد لوحة مفاتيح": إذا انتقل التركيز إلى مكوّن مثل مربع حوار، يجب أن يكون المستخدم قادرًا على نقل التركيز للخارج باستخدام لوحة المفاتيح فقط (عادة عبر مفتاح Escape). المستخدم المحاصر ليس أمامه خيار سوى إغلاق المتصفح.

لا يقل أهمية عن ذلك وضوح التركيز (الإرشاد 2.4، معيار النجاح 2.4.7). يحتاج مستخدمو لوحة المفاتيح المبصرون إلى رؤية مكان التركيز في كل الأوقات. إزالة مخطط التركيز الافتراضي للمتصفح — ممارسة أصبحت شائعة لأسباب جمالية — هي واحدة من أكثر القرارات ضررًا في إمكانية الوصول يمكن أن يتخذها المطوّر. عندما يكون التركيز غير مرئي، يكون مستخدم لوحة المفاتيح كمن يتنقل في الظلام. إذا تجاوزت أنماط التركيز الافتراضية للمتصفح، يجب أن توفّر بديلًا مرئيًا بنسبة تباين لا تقل عن 3:1 مع الخلفية المحيطة.

<!-- Inaccessible: focus outline suppressed globally -->
* { outline: none; }

<!-- Accessible: custom visible focus style -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
  border-radius: 2px;
}

الإرشاد 2.2 يتناول التوقيت. بعض المستخدمين يحتاجون إلى وقت أطول بكثير لقراءة المحتوى، أو إكمال النماذج، أو الاستجابة لتحذيرات انتهاء الجلسة. لأي حد زمني يفرضه محتواك، يجب أن يكون المستخدمون قادرين على إيقافه، أو تمديده (إلى ما لا يقل عن 10 أضعاف القيمة الافتراضية)، أو أن يتم تحذيرهم قبل انتهائه ومنحهم ما لا يقل عن 20 ثانية للاستجابة بإجراء بسيط. العروض المتحركة التلقائية (carousels)، والاختبارات المحددة بزمن، ونوافذ انتهاء الجلسة المنبثقة هي أمثلة شائعة على الإخفاق هنا.

الإرشاد 2.3 يحظر المحتوى الذي يومض أكثر من ثلاث مرات في الثانية، لأن مثل هذا المحتوى يمكن أن يسبب نوبات صرع حساسة للضوء. الإرشاد 2.4 يغطي قابلية التنقل — ضمان أن يتمكن المستخدمون من العثور على المحتوى ومعرفة مكانهم. المتطلبات العملية تشمل طريقة لتجاوز كتل التنقل المتكررة (رابط "تخطي إلى المحتوى الرئيسي" هو أبسط تطبيق)، وعناوين صفحات وصفية، وترتيب تركيز منطقي، ونصوص روابط ذات معنى ("قراءة تقرير الربع الثالث" وليس "انقر هنا")، ومؤشرات تركيز مرئية. أضاف WCAG 2.2 أيضًا الإرشاد 2.5، الذي يغطي طرائق الإدخال: يجب أن تكون كل وظيفة تستخدم إيماءات متعددة النقاط أو قائمة على المسار (مثل القرص للتكبير، أو السحب) قابلة للتشغيل أيضًا بمؤشر واحد، ويجب أن تفي أهداف اللمس بمتطلبات الحجم الأدنى.

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

المبدأ 3: قابل للفهم — الوضوح ليس اختياريًا

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

الإرشاد 3.1 يغطي قابلية القراءة. المتطلب الأساسي هو تحديد لغة الصفحة في الشيفرة — عبر خاصية lang في عنصر <html>. هذا السمة الواحدة تتيح لقارئات الشاشة التبديل إلى محركات النطق المناسبة. تم العثور على إعلانات لغة مفقودة في 15.8% من الصفحات الرئيسية في بيانات WebAIM لعام 2025، ما يعني أن قارئ الشاشة قد ينطق صفحة إنجليزية بلكنة فرنسية (أو العكس) إذا كانت إعدادات اللغة الافتراضية للمستخدم مختلفة. عندما تنتقل الصفحة بين اللغات في منتصف المحتوى — وهو أمر شائع في المواقع متعددة اللغات — يجب تطبيق خاصية lang على العنصر المعني.

<!-- Page language declaration -->
<html lang='en'>

<!-- Inline language switch -->
<p>The phrase <span lang='fr'>joie de vivre</span> means joy of living.</p>

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

الإرشاد 3.3 يتناول مساعدة الإدخال — وهو أحد أكثر مجالات إمكانية الوصول تأثيرًا من الناحية العملية. عندما يرتكب المستخدمون أخطاء أثناء ملء النماذج، يحتاجون إلى معرفة ثلاثة أشياء: أن خطأ ما حدث، وأي حقل سبّبه، وكيفية إصلاحه. مجرد تلوين الحقل الخاطئ باللون الأحمر لا يكفي — يجب أن تكون رسالة الخطأ نصية، ومرتبطة برمجيًا بالحقل المعني، ومحددة بما يكفي لتكون قابلة للتنفيذ. "هذا الحقل مطلوب" أفضل قليلًا من لا شيء. "يرجى إدخال عنوان بريدك الإلكتروني بالصيغة [email protected]" مفيد حقًا. أضاف WCAG 2.2 أيضًا معيار النجاح 3.3.7 (الإدخال المكرر) و3.3.8 (المصادقة القابلة للوصول)، حيث يحظر الأخير اختبارات الوظائف الإدراكية — مثل الألغاز أو تحديات الذاكرة — كآلية المصادقة الوحيدة، إدراكًا أن مثل هذه الحواجز تؤثر بشكل غير متناسب على المستخدمين ذوي الإعاقات الإدراكية.

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

المبدأ 4: متين — مبني ليصمد عبر التقنيات

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

الإرشاد 4.1 هو الإرشاد الوحيد تحت مبدأ المتانة في WCAG 2.2، وأهم معيار نجاح متبقٍ فيه هو 4.1.2: الاسم، والدور، والقيمة. لكل مكوّن من مكوّنات واجهة المستخدم — النماذج، الروابط، الأزرار، الودجات المخصصة — يجب أن يكون الاسم (ما يُسمّى به)، والدور (نوع العنصر)، والقيمة أو الحالة (ما إذا كان مربع الاختيار محددًا، أو ما إذا كان الأكورديون موسَّعًا) قابلة للتحديد برمجيًا. هذه هي المعلومات التي تقرؤها التقنيات المساعدة من شجرة إمكانية الوصول لتخبر المستخدمين بما يتفاعلون معه.

أكثر طريقة موثوقة للوفاء بالمعيار 4.1.2 هي استخدام عناصر HTML الأصلية، التي تحمل دلالات مدمجة تُعرَض تلقائيًا في شجرة إمكانية الوصول. عنصر <button> هو زر بشكل أصيل — يحصل على الدور الصحيح، وهو قابل للتركيز افتراضيًا، ويُفعَّل عبر مفتاحي Enter وSpace. عنصر <div> مُنسَّق ليبدو كزر لا يمتلك أيًا من هذه الخصائص ما لم تضف يدويًا role='button' وtabindex='0' ومعالجات أحداث JavaScript لكل من أحداث لوحة المفاتيح والمؤشر. الدلالات الأصلية مجانية؛ أما التنفيذات المخصصة فتتطلب صيانة مستمرة.

<!-- Inaccessible custom button -->
<div class='btn' onclick='submitForm()'>Submit</div>

<!-- Accessible: native element -->
<button type='submit'>Submit</button>

<!-- When a custom component is unavoidable -->
<div
  role='button'
  tabindex='0'
  aria-pressed='false'
  onkeydown='handleKey(event)'
  onclick='toggleState()'
>
  Toggle
</div>

يتطلب معيار النجاح 4.1.3 (رسائل الحالة، مستوى AA) أن تُعلَن رسائل الحالة المهمة — مثل تأكيدات إرسال النماذج، ومؤشرات التحميل، وإشعارات الأخطاء، وتحديثات سلة التسوق — لمستخدمي التقنيات المساعدة دون الحاجة إلى نقل تركيز لوحة المفاتيح إليها. الآلية القياسية هي مناطق ARIA الحية: aria-live='polite' للتحديثات غير العاجلة ("تم حفظ تغييراتك") وaria-live='assertive' للمقاطعات العاجلة ("انتهت الجلسة"). بدون هذا، قد يقوم مستخدم قارئ الشاشة بإكمال عملية الدفع، ويرسل نموذجًا، ولا يسمع شيئًا — لا تأكيدًا ولا خطأ — ولا يعرف ما إذا كانت طلبه قد تم أم لا.

<!-- Polite live region for non-urgent status -->
<div aria-live='polite' aria-atomic='true' class='sr-only'>
  <!-- Dynamically injected: 'Your profile has been updated.' -->
</div>

<!-- Assertive live region for urgent alerts -->
<div role='alert' aria-live='assertive'>
  <!-- Dynamically injected: 'Error: Payment failed. Please try again.' -->
</div>

لاحظ أن WCAG 2.2 أزال معيار النجاح القديم 4.1.1 (Parsing)، الذي كان يتطلب سابقًا التحقق الصارم من صحة HTML. المتصفحات الحديثة والتقنيات المساعدة تتعامل مع HTML غير الصحيح بشكل أكثر سلاسة بكثير مما كانت عليه سابقًا، مما جعل هذا المعيار متجاوزًا. تركّز الاهتمام الآن بالكامل على الدلالات ذات المعنى والاستخدام الصحيح لـ ARIA.

كيف تعمل المبادئ الأربعة معًا

POUR ليس قائمة تحقق من مربعات معزولة لتعليمها — بل هو إطار متكامل. الفشل في مبدأ واحد يكاد دائمًا أن يتسلسل إلى إخفاقات في مبادئ أخرى. قائمة منسدلة مخصصة مبنية بعناصر <div> وCSS فقط ستفشل عادة في المبادئ الأربعة في الوقت نفسه: لا يمكن إدراكها بواسطة قارئ الشاشة (لا دور دلالي)، لا يمكن تشغيلها بلوحة المفاتيح (لا إدارة للتركيز)، لا يمكن فهمها من قبل مستخدم قارئ الشاشة (لا إعلانات عن الحالة)، ولن تكون متينة مع تطور واجهات برمجة تطبيقات التقنيات المساعدة (لا اسم أو قيمة برمجية).

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

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

POUR في الممارسة: تطبيق الإطار على موقعك

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

بالنسبة لمبدأ قابل للإدراك، ابدأ بفحص آلي باستخدام أداة مثل WAVE أو Axe لاكتشاف المشكلات السهلة: سمات alt المفقودة، إخفاقات التباين، تسميات النماذج المفقودة، ولغة الصفحة المفقودة. يمكن لهذه الفحوصات الآلية اكتشاف حوالي 30–40% من مشكلات WCAG. ثم راجع يدويًا البقية: شاهد صفحة تُقرأ بواسطة قارئ شاشة مثل NVDA أو VoiceOver، وشاهد ما يراه مستخدم مصاب بعمى الألوان باستخدام محاكي، وتحقق من أن كل جزء من المعنى المنقول بصريًا يُنقل أيضًا عبر النص أو البنية.

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

بالنسبة لمبدأ قابل للفهم، راجع إعلانات لغة الصفحة عبر كل قالب. راجع كل نموذج للتأكد من وجود تسميات واضحة ومرتبطة، واختبر كل حالة خطأ للتأكد من أن الرسائل محددة، نصية، ومرتبطة برمجيًا بحقل الإدخال المعني. أجرِ مراجعة للمحتوى باستخدام مقياس قابلية القراءة — استهدف مستوى قراءة Flesch-Kincaid المناسب لجمهورك، مع إعادة كتابة بلغة بسيطة للأقسام المعقدة. راجع أنماط التنقل عبر موقعك للتأكد من الاتساق.

بالنسبة لمبدأ متين، تحقّق من صحة HTML الخاص بك. استخدم أدوات المطور في المتصفح ومفتش شجرة إمكانية الوصول (المضمّن في أدوات تطوير Chrome وFirefox وSafari) للتحقق من أن كل عنصر تفاعلي لديه اسم قابل للوصول ذو معنى، والدور الصحيح، ومعلومات حالة دقيقة. راجع كل ودجت مخصص. شغّل موقعك مع عدة قارئات شاشة — JAWS وNVDA وVoiceOver لكل منها سلوكيات مختلفة قليلًا — وتحقق من أن التحديثات الديناميكية مثل أخطاء النماذج، وحالات التحميل، وإشعارات التوست يتم الإعلان عنها بشكل صحيح عبر المناطق الحية.

أهم النقاط

POUR هو العمود الفقري لـ WCAG. كل معيار نجاح في WCAG 2.2 يرتبط بأحد المبادئ الأربعة — قابل للإدراك، قابل للتشغيل، قابل للفهم، متين — وفهم هذه المبادئ يساعدك على التفكير في إمكانية الوصول بدلًا من مجرد مطاردة قائمة تحقق.
أكثر الإخفاقات شيوعًا يمكن الوقاية منها. النص منخفض التباين (الموجود في 83.9% من الصفحات)، النص البديل المفقود، حقول النماذج غير المسمّاة، وإعلانات لغة الصفحة المفقودة هي إخفاقات في POUR يمكن لأدوات الفحص الآلي اكتشافها ويمكن للمطورين إصلاحها بسرعة.
إمكانية الوصول عبر لوحة المفاتيح هي أساس قابلية التشغيل. يجب أن يكون كل عنصر تفاعلي قابلًا للوصول، والتشغيل، والخروج عبر لوحة المفاتيح وحدها — لتغطية المستخدمين ذوي الإعاقات الحركية، والمكفوفين، والإعاقات الظرفية.
HTML الدلالي هو أفضل استراتيجية للمتانة. العناصر الأصلية في HTML تعرض الأسماء والأدوار والحالات الصحيحة لشجرة إمكانية الوصول تلقائيًا. المكوّنات المخصصة المبنية على عناصر غير دلالية تتطلب عملًا إضافيًا كبيرًا وصيانة مستمرة لمضاهاة هذا الأساس.
إمكانية الوصول ممارسة مستمرة، وليست مرحلة من مراحل المشروع. دمج التفكير القائم على POUR في مراجعات التصميم، وقوائم مراجعة مراجعة الشيفرة، وتدفقات عمل المحتوى. الأدوات الآلية تلتقط جزءًا من المشكلات — أما الاختبار البشري المستمر وعمليات التصميم الشامل فهي ما يسد الفجوة.

مبادئ POUR موضّحة: قابلية الإدراك، قابلية التشغيل، قابلية الفهم، المتانة