WCAG 2.2 مقابل WCAG 2.1: ما الجديد وما الذي تحتاج إلى تحديثه

أكثر من 96% من الصفحات الرئيسية لا تزال تفشل في تلبية متطلبات WCAG الأساسية، وفقًا لتحليل إمكانية الوصول لعام 2024 من WebAIM — وذلك مقارنةً بمعيار كان عمره بالفعل خمس سنوات. في 5 أكتوبر 2023، نشر W3C معيار WCAG 2.2 كمعيار ويب رسمي، رافعًا السقف بتسعة معايير نجاح جديدة وإلغاء معيار واحد أصبح متقادمًا. إذا كنت تدير موقعًا إلكترونيًا، أو تبني منتجات رقمية، أو تشرف على الامتثال، فهذا التحديث ليس شيئًا يمكنك تأجيله إلى ما لا نهاية. اللوائح في الاتحاد الأوروبي والمملكة المتحدة، وبشكل متزايد في الولايات الأميركية، بدأت بالفعل في اعتماد WCAG 2.2 كمرجع لها.

لمحة تاريخية سريعة: من WCAG 2.1 إلى WCAG 2.2

تطورت إرشادات محتوى الويب القابل للوصول (WCAG) بشكل مستمر منذ إطلاق WCAG 2.0 في ديسمبر 2008. وصلت WCAG 2.1 في يونيو 2018، مضيفةً 17 معيار نجاح جديدًا مع تركيز خاص على مستخدمي الأجهزة المحمولة والأشخاص ذوي ضعف البصر أو الإعاقات الإدراكية. وعلى مدى خمس سنوات، كانت بمثابة معيار الامتثال الفعلي لقوانين مثل ADA وSection 508 وتوجيه إمكانية الوصول إلى الويب في الاتحاد الأوروبي.

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

أحد أهم الأمور التي يجب فهمها من الناحية الهيكلية هو أن WCAG 2.2 متوافقة بالكامل مع الإصدارات السابقة من WCAG 2.1. الامتثال لـ WCAG 2.2 يعني تلقائيًا أنك تمتثل أيضًا لـ WCAG 2.1 وWCAG 2.0. إذا كانت منظمتك حاليًا متوافقة مع WCAG 2.1 AA، فكل ما عليك هو معالجة المعايير الجديدة التي تم تقديمها في 2.2 — لست بصدد البدء من الصفر. كما ينصح W3C بأنه رغم بقاء WCAG 2.0 و2.1 توصيات صالحة، ينبغي للمنظمات استخدام WCAG 2.2 لتعظيم قابلية تطبيق أعمالها في مجال إمكانية الوصول في المستقبل.

من المتوقع أيضًا على نطاق واسع أن تكون WCAG 2.2 آخر إصدار فرعي (dot-release) من عائلة WCAG 2.x. الإصدار الرئيسي التالي، WCAG 3.0، مختلف تمامًا — إعادة تفكير جذرية في كيفية هيكلة إرشادات إمكانية الوصول. وهذا يجعل WCAG 2.2 نقطة النهاية الحاسمة لسلسلة تمتد إلى عام 2008، وهو الإصدار الذي تحتاج إلى إتقانه الآن.

الأرقام: ما الذي تغير فعليًا

لنكن دقيقين بشأن نطاق التغيير. احتوت WCAG 2.1 على 78 معيار نجاح عبر ثلاثة مستويات من الامتثال (A وAA وAAA). تضيف WCAG 2.2 تسعة معايير نجاح جديدة مع إزالة معيار واحد — معيار النجاح 4.1.1 Parsing — ليبقى الإجمالي عند 86 معيارًا نشطًا. من بين هذه الإضافات التسعة، اثنان في المستوى A، وأربعة في المستوى AA، وثلاثة في المستوى AAA.

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

تتناول المعايير الجديدة بشكل أساسي أربعة مجالات مشكلة كانت عمليات تدقيق إمكانية الوصول في العالم الحقيقي تشير إليها مرارًا على أنها غير مغطاة بشكل كافٍ في المعيار الحالي: وضوح تركيز لوحة المفاتيح، تفاعلات اللمس والمؤشر، إمكانية الوصول الإدراكية، وحواجز المصادقة. هذه ليست مخاوف نظرية. إنها من نوع الحواجز التي تمنع الأشخاص ذوي الإعاقة بانتظام من إكمال مهام يومية مثل تسجيل الدخول، أو ملء نموذج، أو التنقل في صفحة ذات ترويسة ثابتة (sticky header).

شرح معايير النجاح التسعة الجديدة

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

المستوى A (الحد الأدنى — مطلوب للجميع)

• 2.4.11 عدم حجب التركيز (الحد الأدنى): عندما يحصل مكون واجهة المستخدم على تركيز لوحة المفاتيح، يجب ألا يكون مخفيًا بالكامل بواسطة محتوى أنشأه المؤلف. أكثر المسببات شيوعًا هنا هي الترويسات الثابتة، وأشرطة ملفات تعريف الارتباط العائمة، وأدوات الدردشة المباشرة التي تجلس فوق الصفحة. إذا ضغط المستخدم على Tab ووصل إلى زر مغطى بالكامل بشريط التنقل الثابت لديك، فهذا يعد انتهاكًا لهذا المعيار. لاحظ أن الحجب الجزئي مقبول في المستوى A — العنصر فقط لا يمكن أن يكون مخفيًا بنسبة 100%.
• 2.5.7 حركات السحب: أي وظيفة تتطلب حركة سحب — مثل تحميل الملفات بالسحب والإفلات، أو عناصر القوائم القابلة للترتيب، أو عناصر التحكم المنزلقة — يجب أن تكون قابلة للتشغيل أيضًا بإجراء مؤشر واحد (مثل النقر أو اللمس) دون سحب. هذا أمر بالغ الأهمية للمستخدمين ذوي الإعاقات الحركية الذين لا يمكنهم تنفيذ حركات سحب مضبوطة بشكل موثوق. ينطبق هذا المتطلب على المحتوى الذي أنشأه المؤلف؛ سلوكيات المتصفح الأصلية مستثناة.

المستوى AA (مطلوب للامتثال القياسي)

• 2.4.12 عدم حجب التركيز (محسّن): نسخة أكثر صرامة من 2.4.11. في المستوى AA، لا يجوز إخفاء أي جزء من مؤشر التركيز بواسطة محتوى أنشأه المؤلف عندما يحصل عنصر على تركيز لوحة المفاتيح. هذا يغلق الثغرة الموجودة في نسخة المستوى A ويتطلب أن تكون العناصر ذات التركيز مرئية بالكامل — وليس جزئيًا فقط.
• 2.5.8 حجم الهدف (الحد الأدنى): يجب أن تكون المنطقة القابلة للنقر أو اللمس للعناصر التفاعلية لا تقل عن 24×24 بكسل CSS، مع استثناءات محددة للروابط النصية المضمنة، والعناصر التي يتحكم فيها وكيل المستخدم، والحالات التي يوجد فيها هدف مكافئ بحجم 24×24 قريبًا. هذا تغيير مهم عن WCAG 2.1، حيث كان حجم الهدف 44×44 بكسل موصى به فقط في المستوى AAA. الآن أصبح الحد الأدنى قابلًا للتنفيذ في المستوى AA. لاحظ أنه رغم أن 24×24 بكسل هو الحد الأدنى، فإن معيار المستوى AAA (2.5.5) لا يزال يوصي بـ 44×44 بكسل، وما زال هذا هو المعيار الذهبي لتصميم ملائم للمس.
• 3.2.6 المساعدة المتسقة: إذا كان الموقع يوفر أي آليات مساعدة — تفاصيل اتصال بشري، أدوات مساعدة ذاتية، دردشة آلية، أو نموذج اتصال — وتظهر هذه الآليات في صفحات متعددة، فيجب أن تظهر في نفس الموضع النسبي عبر تلك الصفحات. يجب أن يكون المستخدمون الذين يحتاجون إلى المساعدة، وخاصة ذوو الإعاقات الإدراكية، قادرين دائمًا على العثور عليها في نفس المكان دون بحث.
• 3.3.7 الإدخال المتكرر (Redundant Entry): المعلومات التي أدخلها المستخدم بالفعل في خطوة سابقة من نفس العملية يجب إما أن تُملأ تلقائيًا له أو تكون متاحة للاختيار، حتى لا يضطر إلى كتابتها مرة أخرى. فكر في تدفقات الدفع متعددة الخطوات التي تطلب عنوان الفوترة ثم تطلب مرة أخرى عنوان الشحن — يجب أن يُعرض على المستخدمين خيار نسخ ما أدخلوه بالفعل. يُسمح بالاستثناءات عندما يكون إعادة إدخال المعلومات ضروريًا للأمان (مثل تأكيد كلمة المرور) أو عندما لم تعد البيانات المدخلة سابقًا صالحة.
• 3.3.8 المصادقة القابلة للوصول (الحد الأدنى): لا يجوز أن تُطلب اختبارات الوظائف الإدراكية — مثل حل لغز، أو حفظ كلمة مرور، أو نسخ أحرف من CAPTCHA مصورة — كوسيلة وحيدة للمصادقة. يجب أن تكون هناك طريقة بديلة متاحة، أو آلية تساعد المستخدم (مثل السماح باستخدام مدير كلمات المرور، أو السماح بالنسخ واللصق في حقل كلمة المرور). هذا المعيار لا يحظر CAPTCHAs تمامًا، لكنه يتطلب ألا تكون أبدًا الخيار الوحيد للمستخدمين الذين لا يمكنهم إكمالها.

المستوى AAA (محسّن — موصى به لكنه غير إلزامي لمعظم الجهات)

• 2.4.13 مظهر التركيز: عندما يكون مؤشر تركيز لوحة المفاتيح مرئيًا، يجب أن يستوفي متطلبات دنيا محددة للحجم والتباين: يجب أن تكون منطقة التركيز على الأقل بحجم محيط بسماكة 2 بكسل CSS حول العنصر، ويجب أن يكون هناك نسبة تباين لا تقل عن 3:1 بين حالات التركيز وغير التركيز. كان من المخطط في الأصل أن يكون هذا المعيار في المستوى AA لكنه نُقل إلى AAA بسبب تعقيده. هذا يعني أنه من أجل امتثال المستوى AA فقط، لا يزال لا يوجد حد أدنى محدد معياريًا لحجم مؤشر التركيز — فقط يجب أن يكون مرئيًا.
• 2.5.9 حركات السحب (محسّنة): انتظر — لا يوجد 2.5.9 في هذا الإصدار. تم تضمين تحسين السحب في المستوى AAA ضمن 3.3.9 أدناه.
• 3.3.9 المصادقة القابلة للوصول (محسّنة): نسخة أكثر صرامة من 3.3.8. في المستوى AAA، تُحظر أيضًا اختبارات التعرف على الأشياء والمحتوى الشخصي (مثل "انقر على جميع إشارات المرور" أو "اختر الصور من حسابك")، وليس فقط الاستثناءات المحددة في المستوى AA. يبقى استثناءان فقط بدلًا من أربعة.

ما الذي أُزيل: 4.1.1 Parsing

تزيل WCAG 2.2 معيار نجاح واحدًا كان موجودًا منذ WCAG 2.0: 4.1.1 Parsing. كان هذا المعيار يتطلب في الأصل أن يكون HTML مُشكّلًا بشكل جيد، مع وسوم بداية ونهاية كاملة، وتداخل صحيح، وعدم وجود سمات مكررة. كان الهدف هو ضمان أن المتصفحات وتقنيات المساعدة يمكنها تحليل العلامات بشكل موثوق وعرض المحتوى بشكل صحيح للمستخدمين.

إزالة هذا المعيار ليست مثيرة للجدل — فهي تعكس تحولًا حقيقيًا في المشهد التقني. منذ 2008، أصبحت المتصفحات جيدة للغاية في التعامل بسلاسة مع HTML غير المُشكّل جيدًا، باتباع خوارزمية تصحيح أخطاء موحدة ومعيارية. تعتمد تقنيات المساعدة مثل قارئات الشاشة الآن على نموذج كائن المستند (DOM) الخاص بالمتصفح، وليس على كود HTML الخام. خلص W3C إلى أن هذا المعيار لم يعد يوفر أي فائدة ذات مغزى لإمكانية الوصول في البيئة الحديثة. لا تزال مشكلات إمكانية الوصول التي كان يتم اكتشافها بواسطة 4.1.1 مغطاة بمعايير أكثر تحديدًا مثل 1.3.1 (المعلومات والعلاقات) و4.1.2 (الاسم، الدور، القيمة).

الآثار العملية لفريقك: إذا كانت أدوات الاختبار الآلي لديك تشير إلى إخفاقات في 4.1.1 Parsing، فإن هذه لم تعد مشكلات WCAG 2.2. قد ترى انخفاضًا في الإخفاقات المبلغ عنها لمجرد الترقية في الإصدار، وليس لأن شيئًا ما قد تم إصلاحه. ومع ذلك، يظل كتابة HTML صالح ومهيكل جيدًا ممارسة موصى بها بقوة — لكنه لم يعد مطلب امتثال مستقلًا بحد ذاته.

الآثار التنظيمية والقانونية

فهم المعايير الجديدة شيء، وفهم ما تعنيه لمخاطرك القانونية شيء آخر. الجواب المختصر هو: WCAG 2.2 في طريقها لتصبح "قانون الأرض" في عدة ولايات قضائية، والجدول الزمني يتحرك أسرع مما تدركه العديد من المنظمات.

في المملكة المتحدة، يُطلب من الهيئات العامة بالفعل تلبية WCAG 2.2 المستوى AA بموجب لوائح إمكانية الوصول لهيئات القطاع العام. في الاتحاد الأوروبي، المعيار EN 301 549 — المعيار التقني الذي يدعم قانون إمكانية الوصول الأوروبي — في طور اعتماد WCAG 2.2 كأساس له. لدى EAA نفسها موعد تنفيذ في يونيو 2025 لمعظم منظمات القطاع الخاص التي تقدم منتجات وخدمات في الاتحاد الأوروبي. كما أعربت عدة ولايات أميركية، بما في ذلك Colorado، عن نيتها تحديث قوانين إمكانية الوصول الخاصة بها من WCAG 2.1 إلى WCAG 2.2.

في الولايات المتحدة، يشير ADA Title II حاليًا إلى WCAG 2.1 AA كمعيار تقني لمواقع الويب الخاصة بحكومات الولايات والحكومات المحلية. ومع ذلك، استشهدت المحاكم الأميركية بشكل متزايد بـ WCAG 2.2 في دعاوى إمكانية الوصول، والاتجاه واضح. الانتظار حتى صدور تفويض اتحادي رسمي قبل اتخاذ إجراء هو استراتيجية امتثال تنطوي على مخاطر قانونية متزايدة، خاصة بالنسبة لمؤسسات التجارة الإلكترونية والخدمات المالية والرعاية الصحية التي تُعد أهدافًا ذات قيمة عالية لدعاوى إمكانية الوصول.

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

كيفية تدقيق موقعك وتحديثه

إذا كنت متوافقًا بالفعل مع WCAG 2.1 AA، فإن مسار الترقية إلى WCAG 2.2 قابل للإدارة. إليك إطارًا عمليًا للتعامل معه.

ابدأ بتدقيق مستهدف للمعايير الستة الجديدة في المستوى AA. هذه هي المعايير التي تحمل وزنًا قانونيًا لمعظم المنظمات. ركّز بشكل خاص على 2.4.11 و2.4.12 (حجب التركيز)، و2.5.8 (حجم الهدف)، و3.2.6 (المساعدة المتسقة)، و3.3.7 (الإدخال المتكرر)، و3.3.8 (المصادقة القابلة للوصول). يمكن لمهندس إمكانية وصول ماهر عادةً تدقيق هذه المعايير يدويًا في بضع ساعات لموقع متوسط التعقيد.

ابدأ بتدقيق العناصر الثابتة/ذات الموضع الثابت (sticky/fixed-position). تُنتهك معايير حجب التركيز (2.4.11 و2.4.12) بواسطة بعض أنماط واجهة المستخدم الأكثر شيوعًا على الويب — الترويسات الثابتة، أزرار الإجراءات العائمة، أشرطة موافقة ملفات تعريف الارتباط، وأدوات الدردشة. تجوّل في موقعك بالكامل باستخدام مفتاح Tab فقط ولاحظ ما إذا كان أي عنصر ذو تركيز يختفي تحت طبقة ثابتة. غالبًا ما يكون إصلاح CSS مباشرًا:

/* Prevent sticky header from covering focused elements */
:focus {
  scroll-margin-top: 80px; /* match your sticky header height */
}

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

راجع تدفقات المصادقة لديك بعناية. معيار 3.3.8 (المصادقة القابلة للوصول) له تأثير حقيقي. إذا كنت تستخدم CAPTCHA لا يمكن تجاوزها أو حلها عبر طريقة بديلة، فمن المرجح أنك غير ممتثل. قيّم ما إذا كانت تدفقات تسجيل الدخول والتسجيل والمصادقة الثنائية تسمح لمديري كلمات المرور بالملء التلقائي، وتسمح بالنسخ واللصق، وتوفر طريقة تحقق بديلة (مثل رابط سحري أو رمز لمرة واحدة)، أو تقدم أي تسهيلات أخرى للمستخدمين الذين لا يمكنهم إكمال تحدٍ إدراكي.

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

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

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

WCAG 2.2 وأدوات التراكب (Overlay Widgets): ما الذي يجب أن تعرفه

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

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

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

أهم النقاط المستخلصة

• WCAG 2.2 تضيف تسعة معايير نجاح جديدة وتزيل قاعدة واحدة متقادمة (4.1.1 Parsing). وهي متوافقة بالكامل مع 2.1، لذا فإن عمل الامتثال الحالي لديك لم يذهب سدى — كل ما عليك هو إضافة ما هو جديد.
• للامتثال في المستوى AA، ركّز على ستة معايير جديدة محددة: عدم حجب التركيز (2.4.11 و2.4.12)، الحد الأدنى لحجم الهدف (2.5.8)، المساعدة المتسقة (3.2.6)، الإدخال المتكرر (3.3.7)، والمصادقة القابلة للوصول (3.3.8). هذه هي المعايير ذات الصلة القانونية لمعظم المنظمات.
• اعتماد اللوائح يتسارع. يطبق القطاع العام في المملكة المتحدة بالفعل WCAG 2.2، والاتحاد الأوروبي في طور الانتقال إليه بموجب قانون إمكانية الوصول الأوروبي، والمحاكم الأميركية تستشهد به بشكل متزايد. لا تنتظر تفويضًا رسميًا في ولايتك القضائية قبل اتخاذ إجراء.
• الأدوات الآلية تلتقط حوالي 40% فقط من مشكلات WCAG 2.2 — الاختبار اليدوي، وجولات التنقل باستخدام لوحة المفاتيح فقط، والاختبار مع مستخدمين حقيقيين ضروري لتحقيق امتثال حقيقي، خاصة للمعايير الجديدة المتعلقة بالمصادقة وإمكانية الوصول الإدراكية.
• أكثر المكاسب السريعة شيوعًا هي إصلاح الترويسات الثابتة التي تحجب العناصر ذات التركيز، وتكبير أهداف اللمس الصغيرة، وتدقيق تدفقات تسجيل الدخول/المصادقة بحثًا عن الاعتماد على CAPTCHA. غالبًا ما تكون هذه التغييرات منخفضة الجهد وعالية الأثر — وهي نقطة انطلاق جيدة لمرحلة معالجة WCAG 2.2 لديك.