اختبار إمكانية الوصول في النماذج

أي معايير WCAG 2.2 تنطبق على النماذج

لا يوجد معيار نجاح (Success criterion) واحد اسمه «النماذج». المتطلبات موزّعة على المبادئ الأربعة، لذا فمراجعة النموذج هي في الحقيقة مرور على مجموعة معروفة من المعايير. ما يلي هو المجموعة الأساسية، والمستويات كما نُشرت في WCAG 2.2.

• 1.3.1 Info and Relationships (A) — يجب أن تكون التسميات والمجموعات وحالة الإلزام متاحة برمجياً، لا بصرياً فقط.
• 1.3.5 Identify Input Purpose (AA) — الحقول التي تجمع معلومات عن المستخدم تُعلن غرضها (في HTML عبر السمة autocomplete).
• 1.4.1 Use of Color (A) — لا يُشار إلى الحقول الإلزامية والأخطاء باللون وحده.
• 2.5.3 Label in Name (A) — الاسم القابل للوصول (Accessible name) للعنصر يحتوي نص تسميته المرئية.
• 3.2.2 On Input (A) — تغيير قيمة حقل لا يسبب تغييراً غير متوقع في السياق، مثل إرسال النموذج.
• 3.3.1 Error Identification (A) — عند اكتشاف خطأ إدخال يُحدَّد الحقل ويوصف الخطأ نصاً.
• 3.3.2 Labels or Instructions (A) — تُقدَّم تسميات أو تعليمات حين يتطلب المحتوى إدخالاً من المستخدم.
• 3.3.3 Error Suggestion (AA) — حين يكون التصحيح معروفاً يُقترح، ما لم يُعرّض ذلك الأمن أو الغرض للخطر.
• 3.3.4 Error Prevention (Legal, Financial, Data) (AA) — الإرسال ذو الأثر القانوني أو المالي أو على البيانات قابل للتراجع أو مُتحقَّق منه أو مؤكَّد.
• 3.3.7 Redundant Entry (A) — المعلومات المُدخلة سابقاً في العملية نفسها تُملأ تلقائياً أو تُتاح للاختيار.
• 3.3.8 Accessible Authentication (Minimum) (AA) — لا تتطلب أي خطوة دخول اختبار وظيفة إدراكية ما لم يوجد بديل أو آلية مسموح بها.
• 4.1.2 Name, Role, Value (A) و4.1.3 Status Messages (AA) — العناصر المخصّصة تُعلن الاسم والدور والحالة، ورسائل الحالة والخطأ تصل إلى التقنيات المساعدة دون نقل التركيز.

التسميات والتعليمات والحقول الإلزامية

يحتاج كل حقل إدخال إلى اسم قابل للوصول يطابق ما يقرؤه المستخدم المبصر بجواره. الطريقة المتينة في HTML هي عنصر <label> مربوط بالحقل عبر for/id أو محيط به. النص النائب داخل الحقل الفارغ ليس تسمية: يختفي عند الكتابة، وكثيراً ما يفشل في التباين، ودعمه كاسم قابل للوصول غير متسق. السمتان aria-label وaria-labelledby صحيحتان حين لا يوجد عنصر تسمية مرئي، لكن تحقّق حينها من معيار Label in Name — فزر يظهر عليه «إرسال» واسمه البرمجي «Submit form» يُربك مستخدمي التحكم الصوتي الذين ينطقون ما يرونه.

التعليمات وتلميحات التنسيق («يوم/شهر/سنة»، «8 أحرف على الأقل ورقم واحد») مكانها قبل الحقل أو مرتبطة به، عادةً عبر aria-describedby، لتُقرأ عند وصول التركيز إلى الحقل. أما التعليمات التي لا تظهر إلا في تلميح عند مرور المؤشر فيفوّتها مستخدمو لوحة المفاتيح واللمس.

تحتاج الحقول الإلزامية إلى إشارة مرئية وأخرى برمجية معاً. النجمة الحمراء وحدها تعتمد على اللون وعلى معرفة المستخدم بالعُرف؛ فاشرحها مرة في أعلى النموذج («الحقول المعلَّمة بـ * إلزامية») أو اكتب «(إلزامي)» في التسمية، واضبط السمة required أو aria-required="true" ليعلنها قارئ الشاشة.

• افحص الاسم القابل للوصول لكل حقل في لوحة إمكانية الوصول ضمن أدوات المطوّر في المتصفح — لا تستنتجه من الشيفرة.
• انقر التسمية المرئية: يجب أن ينتقل التركيز إلى الحقل (فحص سريع لارتباط التسمية فعلاً).

جرّبها: مولّد اختبارات التحقق جرّبها: فاحص إمكانية الوصول في HTML

تجميع الحقول المترابطة باستخدام fieldset وlegend

لمجموعة أزرار الاختيار أو مربعات التحديد مستويان من المعنى: السؤال وكل إجابة. إذا وُسمت الإجابات وحدها يسمع مستخدم قارئ الشاشة «نعم، زر اختيار، 1 من 2» دون أن يعرف ما السؤال. ضع المجموعة داخل <fieldset> مع <legend>، أو استخدم role="group" أو role="radiogroup" مع aria-labelledby في العناصر المخصّصة. وينطبق الأمر نفسه على تاريخ الميلاد المقسّم إلى يوم وشهر وسنة، وعلى كتل العناوين المتكررة.

<!-- Defect: the question is plain text, not associated with the radios -->
<p>هل لديك إقامة سارية؟</p>
<input type="radio" id="p-yes" name="permit"><label for="p-yes">نعم</label>
<input type="radio" id="p-no" name="permit"><label for="p-no">لا</label>

<!-- Fixed: the legend names the group; each option keeps its own label -->
<fieldset>
  <legend>هل لديك إقامة سارية؟ (إلزامي)</legend>
  <input type="radio" id="p-yes" name="permit" required><label for="p-yes">نعم</label>
  <input type="radio" id="p-no" name="permit"><label for="p-no">لا</label>
</fieldset>

تحديد الأخطاء واقتراح تصحيحها والإعلان عنها

عند فشل التحقق يجب أن تتحقق ثلاثة أمور: يُحدَّد الحقل الذي فيه الخطأ؛ ويوصف الخطأ نصاً (3.3.1)؛ وحين يكون التصحيح معروفاً يُقترح (3.3.3) — «أدخل التاريخ بصيغة يوم/شهر/سنة، مثل 05/03/2026» بدلاً من «إدخال غير صالح». الإطار الأحمر وحده يُخفق في 1.4.1؛ والأيقونة وحدها تحتاج بديلاً نصياً؛ ويجب ربط الرسالة بالحقل برمجياً (aria-describedby أو aria-errormessage مع aria-invalid="true") لتُقرأ حين يعود المستخدم إليه.

<label الجزء 1:1for="dob">الجزء 2:2Date of birth (required)</label>
<p id="dob-hint">الجزء 3:3DD/MM/YYYY</p>
<input الجزء 1:1id="dob" الجزء 4:4required
  الجزء 5:5autocomplete="bday"
  الجزء 6:6aria-invalid="true"
  الجزء 7:7aria-describedby="dob-hint dob-error">
<p id="dob-error">الجزء 8:8Enter the date as DD/MM/YYYY, for example 05/03/2026</p>

ويحتاج المستخدم أيضاً إلى أن يعرف أن خطأً قد وقع. نمطان عمليان شائعان: عند الإرسال، اعرض ملخّص أخطاء أعلى النموذج وانقل التركيز إليه واربط كل بند بحقله؛ أو انقل التركيز مباشرة إلى أول حقل خاطئ. وللرسائل التي تظهر دون نقل التركيز — «تم الحفظ»، «3 نتائج»، أو «اسم المستخدم محجوز» القادمة بشكل غير متزامن — استخدم منطقة حيّة (Live region) مثل role="status" أو aria-live="polite" للمعلومات، وrole="alert" للأخطاء العاجلة، لتستوفي 4.1.3 Status Messages. يجب أن تكون حاوية المنطقة الحيّة موجودة في الصفحة قبل إدراج النص، وإلا فإن كثيراً من قارئات الشاشة لا تعلنه.

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

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

جرّبها: مولّد الاختبارات السلبية جرّبها: مولّد حمولات خطأ وهمية

منع الأخطاء وتجنّب الإدخال المكرر

ينطبق 3.3.4 Error Prevention (Legal, Financial, Data) على الصفحات التي تُنشئ التزامات قانونية أو معاملات مالية، أو تعدّل بيانات يتحكم بها المستخدم أو تحذفها، أو ترسل إجابات اختبار. ويجب أن يتحقق خيار واحد على الأقل من ثلاثة: أن يكون الإرسال قابلاً للتراجع؛ أو أن تُفحص البيانات ويُتاح للمستخدم تصحيحها؛ أو أن تتوفر آلية لمراجعة المعلومات وتأكيدها وتصحيحها قبل الإتمام. عملياً يتحقق المختبِر من وجود خطوة مراجعة قبل الدفع، أو نافذة تراجع أو إلغاء، أو حوار تأكيد قبل حذف الحساب — ومن أن شاشة المراجعة نفسها ميسّرة (عناوين، وقيم مقروءة، ورابط «تعديل» لكل قسم باسم واضح).

أما 3.3.7 Redundant Entry (A) فمعيار جديد في WCAG 2.2. إذا طلبت عملية متعددة الخطوات معلومات أدخلها المستخدم سابقاً — عنوان الشحن في خطوة الفوترة، أو رقم الهوية الوطنية في خطوة التأكيد — فيجب ملؤها تلقائياً أو عرضها للاختيار (مثل مربع «مطابق لعنوان الشحن»). وتوجد استثناءات حين تكون إعادة الإدخال جوهرية، أو مطلوبة للأمان (مثل تأكيد كلمة مرور جديدة)، أو حين لا تعود المعلومات السابقة صالحة.

غرض الإدخال والإكمال التلقائي والمصادقة الميسّرة

يطلب 1.3.5 Identify Input Purpose أن تُعلن الحقول التي تجمع معلومات عن المستخدم غرضها برمجياً حين يكون الغرض مدرجاً في قسم «Input Purposes for User Interface Components» في WCAG. في HTML يعني ذلك السمة autocomplete بالقيمة الصحيحة: name وgiven-name وfamily-name وemail وtel وstreet-address وpostal-code وbday وusername وcurrent-password وnew-password وcc-number وغيرها. وأبعد من المطابقة، تتيح القيم الصحيحة للمتصفحات ومديري كلمات المرور ملء النموذج، ما يساعد مباشرة ذوي الإعاقات الحركية والإدراكية. تحقق من القيمة في كل حقل؛ ووجود autocomplete="off" على حقل بيانات شخصية ملاحظة تستحق الرفع.

وينص 3.3.8 Accessible Authentication (Minimum) على ألا تتطلب أي خطوة في عملية المصادقة اختبار وظيفة إدراكية (Cognitive function test) — تذكّر كلمة مرور، أو حل لغز، أو نسخ رمز يدوياً — ما لم تقدّم الخطوة طريقة بديلة لا تعتمد عليه، أو آلية مساعدة (ومن أمثلة WCAG نفسها دعم مديري كلمات المرور والنسخ واللصق)، أو كان الاختبار تعرّفاً على أشياء أو على محتوى شخصي قدّمه المستخدم. وتَعُدّ وثيقة Understanding نسخَ رمز التحقق لمرة واحدة يدوياً اختبارَ وظيفة إدراكية، لذا يجب على الأقل أن يستطيع المستخدم لصق الرمز.

• حقول اسم المستخدم وكلمة المرور تقبل اللصق ويمكن لمديري كلمات المرور ملؤها (لا توجد شيفرة تمنع اللصق أو الملء التلقائي).
• يمكن لصق رمز التحقق لمرة واحدة (OTP) كاملاً. مدخلات «خانة لكل رقم» تفشل في هذا غالباً: اللصق يملأ الخانة الأولى فقط — اختبر ذلك صراحة. القيمة autocomplete="one-time-code" في HTML تساعد المتصفح على اقتراح الرمز، لكنها ليست ضمن قائمة أغراض الإدخال في WCAG، فعاملها كممارسة جيدة لا كمتطلب لـ 1.3.5.
• اختبار CAPTCHA: اختبار CAPTCHA النصي أو اللغزي اختبار وظيفة إدراكية ويحتاج إلى بديل؛ أما CAPTCHA القائم على التعرّف على الأشياء فمستثنى في المستوى AA (لا في AAA، أي 3.3.9 Accessible Authentication (Enhanced)). وأي صورة CAPTCHA تحتاج مع ذلك إلى بديل نصي يحدد غرضها وفق 1.1.1، إضافة إلى صيغة بديلة بحاسة مختلفة.
• الخيارات بلا كلمة مرور (رابط عبر البريد، مفاتيح المرور Passkeys/WebAuthn) بدائل تتجنب اختبار الوظيفة الإدراكية — تحقق من أنها قابلة للوصول والتشغيل بلوحة المفاتيح وقارئ الشاشة.

جرّبها: مولّد مستخدمين وهميين

إجراء اختبار عملي

• جولة البنية (أدوات المطوّر): لكل حقل اقرأ الاسم القابل للوصول المحسوب والدور والوصف وحالتي الإلزام والخطأ في شجرة إمكانية الوصول (Accessibility tree). وتحقق من قيم autocomplete.
• جولة لوحة المفاتيح: أكمل النموذج باستخدام Tab وShift+Tab والأسهم وSpace وEnter فقط — ترتيب التركيز يتبع الترتيب المرئي، والتركيز ظاهر دائماً، وقوائم الاختيار ومنتقيات التاريخ المخصّصة قابلة للتشغيل (راجع دليل اختبار لوحة المفاتيح).
• جولة قارئ الشاشة: أكمل النموذج بـ NVDA أو JAWS على Windows، أو VoiceOver على macOS/iOS، أو TalkBack على Android — كل حقل ومجموعة وتلميح وخطأ يُعلن بشكل مفهوم (راجع دليل اختبار قارئ الشاشة).
• جولة الأخطاء: أرسل فارغاً، وأرسل كل صيغة خاطئة، وأطلق أخطاء الخادم، وأطلق انتهاء المهلة. راقب انتقال التركيز والإعلانات.
• الجولة البصرية: كبّر إلى 200% وتحقق من إعادة التدفق عند عرض 320 CSS px؛ تبقى التسميات والأخطاء بجوار حقولها؛ ولا تعتمد الأخطاء على اللون؛ وحدود الحقول ومؤشرات التركيز تستوفي تباين العناصر غير النصية.

جرّبها: مولّد اختبارات التحقق جرّبها: مولّد أسماء وهمية

قائمة فحص: حالات اختبار النماذج الميسّرة

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

• التسميات والتعليمات — لكل حقل تسمية مرئية واسم قابل للوصول مطابق لها (1.3.1 و3.3.2 و2.5.3)؛ والنص النائب (Placeholder) ليس التسمية الوحيدة أبداً؛ وتلميحات الصيغة مرتبطة بالحقل (aria-describedby) وتُقرأ عند التركيز؛ والحقول الإلزامية معلَّمة بنص مرئي أو برمز مشروح مع required أو aria-required (1.3.1 و1.4.1).
• التجميع — لمجموعات أزرار الاختيار ومربعات التحديد وللحقول المقسّمة (التاريخ والهاتف) عنصر fieldset مع legend، أو role=group مع اسم.
• الأخطاء — عند الإرسال فارغاً تسمّي كل رسالة الحقل وتظهر نصاً (3.3.1)؛ وعند الصيغة الخاطئة تقترح الرسالة الصيغة الصحيحة بمثال (3.3.3)؛ والخطأ مرتبط بالحقل وaria-invalid مضبوطة على الحقول غير الصالحة؛ والأخطاء تُعلَن، إما بنقل التركيز إلى الملخص أو إلى أول خطأ وإما بمنطقة حية (4.1.3)؛ ولا تُعرض الأخطاء باللون وحده (1.4.1)؛ وتغيير قيمة حقل لا يرسل النموذج ولا ينقل الصفحة على نحو غير متوقع (3.2.2).
• منع الأخطاء والإدخال المتكرر — في الإرسالات القانونية والمالية والتي تغيّر البيانات توجد مراجعة أو تراجع أو فحص وتصحيح (3.3.4)؛ والبيانات المُدخلة في خطوات سابقة تُملأ مسبقاً أو يمكن اختيارها (3.3.7)؛ ويمكن تمديد مهلة الجلسة دون فقدان البيانات (2.2.1).
• الغرض والمصادقة — قيم autocomplete صحيحة في حقول البيانات الشخصية (1.3.5)؛ واللصق ومديرو كلمات المرور يعملون في حقول اسم المستخدم وكلمة المرور ورمز OTP (3.3.8)؛ ولصق رمز OTP كاملاً في المربعات المقسّمة يملؤها كلها؛ ولاختبار CAPTCHA بديل وله بديل نصي (3.3.8 و1.1.1).
• التشغيل — يمكن إكمال النموذج كله بلوحة المفاتيح وحدها مع تركيز مرئي، ويمكن إكماله بقارئ الشاشة؛ وعند تكبير 200% وعرض 320 CSS px لا تضيع التسميات ولا الأخطاء؛ والنماذج العربية تعلن ⁦lang="ar" dir="rtl"⁩، وحقول البيانات ذات الاتجاه من اليسار إلى اليمين تستخدم ⁦dir="ltr"⁩ أو ⁦dir="auto"⁩.

FORM A11Y CHECKLIST — <form name / URL / build>

Labels & instructions
[ ] Every field has a visible label and a matching accessible name (1.3.1, 3.3.2, 2.5.3)
[ ] Placeholder is never the only label
[ ] Format hints are associated with the field (aria-describedby) and read on focus
[ ] Required fields: visible text or explained marker + required/aria-required (1.3.1, 1.4.1)

Grouping
[ ] Radio/checkbox groups and split fields (date, phone) have fieldset+legend or role=group with a name

Errors
[ ] Empty submit: each error names the field and is in text (3.3.1)
[ ] Wrong format: message suggests the correct format with an example (3.3.3)
[ ] Error is associated with the field; aria-invalid set on invalid fields
[ ] Errors are announced: focus moves to summary/first error, or live region used (4.1.3)
[ ] Errors are not shown by colour alone (1.4.1)
[ ] Changing a field does not submit or navigate unexpectedly (3.2.2)

Prevention & redundant entry
[ ] Legal/financial/data-changing submit: review, undo or check-and-correct exists (3.3.4)
[ ] Data from earlier steps is pre-filled or selectable (3.3.7)
[ ] Session timeout can be extended without data loss (2.2.1)

Purpose & authentication
[ ] autocomplete tokens correct on personal-data fields (1.3.5)
[ ] Paste and password managers work on username/password/OTP fields (3.3.8)
[ ] Pasting a full OTP into split boxes fills all boxes
[ ] CAPTCHA has an alternative and a text alternative (3.3.8, 1.1.1)

Operation
[ ] Whole form completable by keyboard only; focus visible
[ ] Whole form completable with a screen reader
[ ] 200% zoom and 320 CSS px width: no lost labels or errors
[ ] RTL forms: lang="ar" dir="rtl"; LTR data fields use dir="ltr"/"auto"

جرّبها: مولّد قوائم تحقق QA بالذكاء الاصطناعي

عيوب نموذجية مكتوبة كعناوين تقارير أخطاء

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

• «التسجيل: حقل البريد الإلكتروني بلا اسم قابل للوصول — قارئ الشاشة يعلن ‹حقل تحرير› فقط (1.3.1، 4.1.2)»
• «الدفع: أخطاء البطاقة تظهر كإطار أحمر فقط دون رسالة نصية (1.4.1، 3.3.1)»
• «الدفع: ملخّص الأخطاء يظهر بعد الإرسال لكن التركيز يبقى على الزر ولا يُعلن شيء (4.1.3)»
• «تسجيل الدخول: اللصق ممنوع في حقل كلمة المرور ومديرو كلمات المرور لا يستطيعون ملأه (3.3.8)»
• «شاشة OTP: لصق رمز من 6 أرقام يملأ الخانة الأولى فقط من ست خانات (3.3.8)»
• «طلب التأشيرة، الخطوة 3: يجب كتابة رقم الجواز مرة أخرى رغم إدخاله في الخطوة 1 (3.3.7)»

جرّبها: مولّد عناوين الأخطاء بالذكاء الاصطناعي

النماذج العربية والنماذج من اليمين إلى اليسار

تضيف النماذج العربية فحوصاً خاصة فوق القائمة السابقة. تحتاج الصفحة أو النموذج إلى lang="ar" وdir="rtl" ليغيّر قارئ الشاشة صوته ويقرأ بالترتيب الصحيح؛ ويجب أن تتبع التسميات والتلميحات وملخّصات الأخطاء ترتيب القراءة من اليمين إلى اليسار (RTL)، وأن يطابقه ترتيب التركيز. أما الحقول التي تحمل بيانات من اليسار إلى اليمين — البريد الإلكتروني، وعناوين URL، وأرقام IBAN، وكثير من صيغ الهاتف — فتحتاج عادةً إلى dir="ltr" (أو dir="auto") على الحقل نفسه كي لا يُعاد ترتيب المحارف أثناء الكتابة، ويجب ألا تتشوّه هذه القيم حين تقتبسها رسائل الخطأ.

ويجب أن يقبل التحقق ما يكتبه الناس فعلاً بالعربية: الأرقام العربية المشرقية (٠١٢٣) في الهاتف ورقم الهوية إن كان النظام يحوّلها، والأسماء بالحرف العربي، والتواريخ الهجرية حيث يقبلها العمل. رسالة مثل «أدخل اسماً صالحاً» تظهر عند إدخال اسم عربي صحيح عيب وظيفي وعيب إمكانية وصول معاً. ويغطي دليل اختبار الواجهات من اليمين إلى اليسار النص ثنائي الاتجاه وعكس الواجهة والإدخال مختلط الاتجاه بالتفصيل.

جرّبها: مولّد أسماء وهمية

الأسئلة الشائعة

المراجع

• Web Content Accessibility Guidelines (WCAG) 2.2W3C · 2024توصية W3C التي تحدد معايير النجاح القابلة للاختبار لإتاحة محتوى الويب، مرتّبةً تحت أربعة مبادئ وثلاثة مستويات مطابقة (A وAA وAAA).
• Understanding WCAG 2.2W3C Web Accessibility Initiative (WAI)الشرح التوضيحي لكل إرشاد ومعيار نجاح في WCAG 2.2: الغرض، ومن يستفيد، والأمثلة والتقنيات (غير إلزامي).
• How to Meet WCAG (Quick Reference)W3C Web Accessibility Initiative (WAI)قائمة قابلة للتصفية بكل معايير نجاح WCAG 2.2 مع التقنيات الكافية وحالات الإخفاق الشائعة.
• Accessible Rich Internet Applications (WAI-ARIA) 1.2W3C · 2023توصية W3C التي تعرّف أدوار ARIA وحالاتها وخصائصها — أي كيف تُعلن عناصر الواجهة المخصّصة معناها للتقنيات المساعدة.
• ARIA Authoring Practices Guide (APG)W3C Web Accessibility Initiative (WAI)أنماط للعناصر الشائعة (التبويبات والقوائم ونوافذ الحوار والقوائم المنسدلة) مع تفاعل لوحة المفاتيح المتوقع واستخدام ARIA — المرجع الذي تُقارَن به المكونات المخصصة.
• Accessibility — MDNMDN Web Docs (Mozilla)أدلة عملية لبناء صفحات ويب ميسّرة وفحصها: HTML الدلالي وARIA ودعم لوحة المفاتيح والاختبار.
• Evaluating Web Accessibility OverviewW3C Web Accessibility Initiative (WAI)مدخل W3C إلى تقييم إمكانية الوصول: لماذا يبدأ التقييم مبكراً ويستمر طوال التطوير، وكيف تتكامل الفحوص اليدوية والأدوات ومشاركة المستخدمين.