كيفية إصلاح أكثر 6 حالات فشل شيوعًا في WCAG على أي موقع ويب

افتح أيًا من أفضل مليون موقع ويب الآن، وهناك احتمال 96 من 100 أن تجد مخالفة لـ WCAG يمكن لأداة فحص آلية اكتشافها في ثوانٍ. عبر مليون صفحة رئيسية، تم اكتشاف 56,114,377 خطأ مميزًا في إمكانية الوصول — بمتوسط 56.1 خطأ لكل صفحة. ما يجعل هذا لافتًا بشكل خاص هو أن 96% من جميع الأخطاء المكتشفة تقع في ست فئات فقط، وهذه الأنواع الستة الأكثر شيوعًا من الأخطاء ظلت كما هي خلال السنوات السبع الماضية. هذا يعني أن إصلاح عدد قليل من المشكلات المفهومة جيدًا سيحسن إمكانية الوصول عبر الويب بأكمله بشكل جذري — ويبدأ ذلك من موقعك.

لماذا تستمر نفس الإخفاقات الستة في الظهور

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

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

المخاطر القانونية حقيقية ومتزايدة. وفقًا لـ Seyfarth Shaw، تم رفع 8,800 دعوى فيدرالية بموجب ADA Title III في 2024، مع استهداف حوالي 2,452 منها لإمكانية الوصول على الويب تحديدًا. تواجه مواقع التجارة الإلكترونية مخاطر غير متناسبة — 77% من دعاوى إمكانية الوصول على الويب تستهدف البيع بالتجزئة عبر الإنترنت. الامتثال لم يعد ميزة إضافية لطيفة. إنه مسألة استمرارية الأعمال.

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

الإخفاق #1 — نص منخفض التباين (WCAG 1.4.3)

النص منخفض التباين — النص الذي لا يحتوي على تمايز لوني كافٍ عن خلفيته — يظهر في 83.6% من الصفحات الرئيسية التي تمت دراستها. هذا هو الإخفاق الأكثر شيوعًا في WCAG، ويؤثر على أكثر من أربعة من كل خمسة مواقع. معيار WCAG 1.4.3 (الحد الأدنى للتباين) واضح بشكل صارم: يجب أن يحقق النص العادي نسبة تباين لا تقل عن 4.5:1 مقابل خلفيته، ويجب أن يصل النص الكبير (18pt أو 14pt عريض) إلى 3:1 على الأقل.

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

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

/* فشل — نسبة تقريبًا 2.3:1 */
.secondary-label {
  color: #aaaaaa;
  background-color: #ffffff;
}

/* اجتياز — نسبة تقريبًا 7:1 */
.secondary-label {
  color: #595959;
  background-color: #ffffff;
}

بالنسبة لنص العنصر النائب، تذكر أن WCAG يعامله كنص حقيقي — وليس تلميحًا زخرفيًا — لذا يجب أن يفي أيضًا بحد 4.5:1. تجنب الاعتماد فقط على نص العنصر النائب لنقل التعليمات؛ أقرنه دائمًا بعنصر <label> مرئي. إذا كنت تستخدم صورًا للنص، فلا يمكنك إصلاح التباين باستخدام CSS — تحتاج إلى إعادة إنشاء تلك الصور، وهو سبب آخر لتفضيل نص HTML حي على النص المدمج في الرسومات.

الإخفاق #2 — غياب نص بديل للصور (WCAG 1.1.1)

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

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

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

<!-- صورة ذات معنى: صف ما تنقله -->
<img src='team-photo.jpg' alt='The Accsible engineering team at their 2024 offsite in Lisbon' />

<!-- صورة زخرفية: alt فارغ، لا حاجة لدور -->
<img src='wave-divider.svg' alt='' />

<!-- صورة مرتبطة: صف الوجهة، لا الصورة -->
<a href='/pricing'>
  <img src='pricing-icon.svg' alt='View pricing plans' />
</a>

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

الإخفاق #3 — غياب تسميات حقول النماذج (WCAG 1.3.1, 3.3.2)

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

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

النمط الصحيح هو استخدام عنصر <label> مرتبط بحقل الإدخال عبر خاصيتي for وid المتطابقتين. إذا لم يكن التسمية المرئية ممكنة لأسباب تصميمية، استخدم aria-label أو aria-labelledby — لكن لا تلجأ إلى ARIA عندما يمكنك ببساطة استخدام <label>.

<!-- صحيح: ربط صريح بين التسمية والحقل -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email' autocomplete='email' />

<!-- خطأ: عنصر نائب فقط -->
<input type='email' placeholder='Email address' />

<!-- مقبول عندما يجب إخفاء التسمية بصريًا -->
<label for='search' class='visually-hidden'>Search the site</label>
<input type='search' id='search' name='q' />

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

الإخفاق #4 — روابط وأزرار فارغة (WCAG 2.4.4, 4.1.2)

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

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

<!-- رابط فارغ — فشل -->
<a href='/dashboard'><svg>...</svg></a>

<!-- تم الإصلاح باستخدام aria-label -->
<a href='/dashboard' aria-label='Go to dashboard'><svg aria-hidden='true'>...</svg></a>

<!-- زر فارغ — فشل -->
<button><svg>...</svg></button>

<!-- تم الإصلاح بنص مخفي بصريًا -->
<button>
  <svg aria-hidden='true'>...</svg>
  <span class='visually-hidden'>Close menu</span>
</button>

لاحظ aria-hidden='true' على عنصر SVG في كل مثال من الأمثلة المصححة. عندما توفر بديلًا نصيًا عبر aria-label أو نص مخفي بصريًا، تريد إخفاء SVG من شجرة إمكانية الوصول — وإلا قد تعلن قارئات الشاشة كلًا من التسمية وعنوان أو وصف SVG نفسه، مما يخلق إعلانًا مزدوجًا مربكًا. نص الرابط الغامض — عبارات مثل "click here" أو "read more" أو "learn more" — هو إخفاق ذو صلة. تم العثور على مشكلات أخرى في الروابط التشعبية مثل نص الرابط الغامض في ما يقرب من 14% من الصفحات الرئيسية، بزيادة عن العام السابق. الروابط ذات النص المناسب مهمة حتى يعرف المستخدمون إلى أين سيأخذهم الرابط. يجب أن يكون اسم كل رابط قابل للوصول منطقيًا خارج السياق لأن مستخدمي قارئات الشاشة يتنقلون كثيرًا عن طريق إظهار قائمة بجميع الروابط في الصفحة.

الإخفاق #5 — غياب لغة المستند (WCAG 3.1.1)

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

الحل هو خاصية HTML واحدة — حرفيًا سطر واحد من الشيفرة — ولا يوجد عذر لغيابها. أضف خاصية lang إلى عنصر <html> مع وسم اللغة المناسب وفق BCP 47. إذا كانت أقسام من صفحتك بلغة مختلفة عن لغة الصفحة ككل، أضف خاصية lang إلى تلك العناصر المحددة أيضًا.

<!-- مفقود: لا توجد خاصية lang -->
<html>

<!-- صحيح: صفحة باللغة الإنجليزية -->
<html lang='en'>

<!-- صحيح: صفحة باللغة الفرنسية -->
<html lang='fr'>

<!-- تبديل لغة ضمني داخل الصفحة -->
<p>The French phrase <span lang='fr'>joie de vivre</span> means a cheerful enjoyment of life.</p>

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

الإخفاق #6 — تنقل غير قابل للوصول بلوحة المفاتيح وإدارة تركيز غير سليمة (WCAG 2.1.1, 2.4.7)

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

أكثر إخفاقات لوحة المفاتيح شيوعًا هي: المكونات التفاعلية المخصصة المبنية من وسوم <div> أو <span> التي لا تحصل على التركيز أبدًا؛ قواعد CSS التي تزيل حلقة التركيز الافتراضية للمتصفح باستخدام outline: none أو outline: 0 من دون استبدالها بشيء مرئي بنفس القدر؛ مربعات الحوار النمطية التي لا تحبس التركيز (بحيث يمكن لمستخدمي لوحة المفاتيح التبويب خلف الطبقة المعتمة)؛ والشرائح الدوارة أو الأكورديونات التي لا يمكن تشغيلها من دون فأرة.

<!-- زر مخصص غير قابل للوصول بلوحة المفاتيح — فشل -->
<div class='btn' onclick='doSomething()'>Submit</div>

<!-- صحيح: استخدم زرًا حقيقيًا -->
<button type='button' onclick='doSomething()'>Submit</button>

<!-- إزالة أنماط التركيز — فشل WCAG 2.4.7 -->
* {
  outline: none; /* لا تفعل هذا أبدًا على مستوى عام */
}

<!-- أفضل: نمّط التركيز بشكل مرئي مع الحفاظ على الجماليات -->
:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 2px;
}

الـ :focus-visible pseudo-class هو أفضل صديق لك هنا. فهو يُظهر أنماط التركيز عندما يتنقل المستخدم بلوحة المفاتيح، لكنه يخفيها عند النقر بالفأرة — مما يمنحك جماليات نظيفة من دون التضحية بإمكانية الوصول. بالنسبة لمربعات الحوار والأدراج، استخدم أداة حبس تركيز تقيد التنقل عبر التبويب داخل مربع الحوار أثناء فتحه، وتعيد التركيز إلى العنصر الذي أطلقه عند إغلاقه. تظهر النوافذ المنبثقة غالبًا من دون إدارة تركيز مناسبة، ومن دون تسميات، أو من دون دعم للتنقل بلوحة المفاتيح. هذا يسبب اضطرابات كبيرة، خاصة في مسارات المستخدم الحرجة مثل التسجيل وتسجيل الدخول وعمليات الدفع.

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

<!-- ضع هذا كأول عنصر داخل <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- ثم في CSS الخاص بك -->
.skip-link {
  position: absolute;
  left: -9999px;
}
.skip-link:focus {
  left: 0;
  top: 0;
  z-index: 9999;
}

ملاحظة حول ARIA: استخدمها بحذر

تلجأ العديد من الفرق إلى خصائص ARIA (Accessible Rich Internet Applications) كحل سريع لفجوات إمكانية الوصول. تشير البيانات إلى أن هذا يأتي بنتائج عكسية في كثير من الأحيان أكثر مما يساعد. حوالي 79% من الصفحات الرئيسية التي تم تقييمها استخدمت ARIA، بزيادة عن العام السابق. الصفحات الرئيسية التي تحتوي على ARIA كان لديها أكثر من ضعف عدد الأخطاء مقارنة بالصفحات من دون ARIA. ARIA نفسها ليست المشكلة — بل غالبًا سوء الاستخدام أو ARIA غير الصحيحة. العديد من المطورين حسني النية يعتقدون أنهم يجعلون المحتوى أكثر قابلية للوصول بإضافة ARIA، بينما في الواقع غالبًا ما يجعلونه أقل قابلية للوصول.

المبدأ الإرشادي بسيط: استخدم HTML الدلالي أولًا. عنصر <button> أفضل من <div role='button'>. عنصر <nav> أفضل من <div role='navigation'>. تأتي عناصر HTML الأصلية بسلوك مدمج للوحة المفاتيح، وإدارة تركيز، وأدوار ARIA ضمنية تتطلب منك تكرارها يدويًا في العلامات المخصصة — وهذا التكرار اليدوي هو المكان الذي تتسلل فيه الأخطاء. احتفظ بـ ARIA للحالات التي لا يمكن لـ HTML التعبير فيها حقًا عن الدلالة التي تحتاجها، مثل المناطق الحية، أو الواجهات المركبة المعقدة، أو تغييرات الحالة الديناميكية.

دمج إمكانية الوصول في سير عملك

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

ادمج الفحص الآلي في خط أنابيب CI/CD لديك حتى تُلتقط الانتهاكات قبل أن تصل إلى بيئة الإنتاج. يمكن تضمين أدوات مثل axe-core في اختبارات الوحدات وأطقم الاختبارات الشاملة. أقرن ذلك بجولات دورية يدوية بلوحة المفاتيح واختبارات قارئات الشاشة — VoiceOver على macOS وiOS، وNVDA على Windows — لأن الاختبارات الآلية يمكنها اكتشاف الأخطاء الشائعة في إمكانية الوصول، لكن الاختبارات اليدوية تساعد في سد الفجوات. بالنسبة للفرق التي تحتاج إلى نقطة انطلاق أسرع، يمكن لأداة تراكب إمكانية الوصول مثل Accsible إظهار فئة كبيرة من المشكلات ومعالجتها على مستوى طبقة العرض بينما يتم التخطيط ونشر إصلاحات على مستوى الشيفرة على المدى الطويل.

أخيرًا، عالج نقطة النفوذ الأكبر في قاعدة الشيفرة لديك: القوالب. تستخدم معظم مواقع الويب قوالب — ترويسة وتذييل وتنقل وتخطيط صفحة تتكرر في كل صفحة. المشكلات في هذه القوالب تتضاعف عبر موقعك بالكامل. أصلحها أولًا لتحقيق أقصى تأثير. يمكن لقالب أساسي واحد مصحح أن يحوّل 10,000 إخفاق في WCAG إلى صفر بنشر واحد.

أهم النقاط

• ستة أنواع من المشكلات تهيمن على المشهد. النص منخفض التباين، النص البديل المفقود، حقول النماذج غير المسمّاة، الروابط والأزرار الفارغة، لغة المستند المفقودة، والتنقل المعطّل بلوحة المفاتيح تمثل الغالبية الساحقة من إخفاقات WCAG. إصلاح هذه الفئات الست يحقق نتائج كبيرة مقارنة بالجهد المبذول.
• معظم الإصلاحات هي تغييرات في CSS أو أسطر HTML واحدة. إضافة lang='en' إلى وسم <html>، واستبدال outline: none بأنماط :focus-visible، وربط التسميات بالحقول هي ساعات من العمل، لا أشهر — ومع ذلك تلغي إخفاقات تؤثر على كل مستخدم من ذوي الإعاقة يزور موقعك.
• القوالب هي موقع الإصلاح الأعلى نفوذًا. أخطاء إمكانية الوصول في المكونات المشتركة وقوالب الصفحات تتكرر عبر موقعك بالكامل. راجع الترويسة والتذييل والتنقل والنماذج أولًا — إصلاحها هناك يعني إصلاحها في كل مكان.
• ARIA أداة الملاذ الأخير، لا الاستجابة الأولى. المواقع التي تعتمد بشكل كبير على ARIA من دون أساس قوي من HTML الدلالي تميل إلى امتلاك عدد أكبر بكثير من أخطاء إمكانية الوصول، لا أقل. فضّل عناصر HTML الأصلية كلما أمكن.
• الفحص الآلي يلتقط أقل من نصف المشكلات الحقيقية. أكمل أدواتك بجولات يدوية بلوحة المفاتيح واختبارات قارئات الشاشة للعثور على الإخفاقات التي لن تُظهرها أي أداة فحص، بما في ذلك حبس التركيز، ومشكلات ترتيب التبويب المنطقي، والمحتوى الديناميكي الذي يفشل في الإعلان عن التغييرات.