WCAG 3.3.1: تحديد الخطأ

ماذا يعني هذا المعيار

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

ينطبق هذا المعيار على أي حالة يتم فيها جمع إدخال من المستخدمين ويحدث التحقق تلقائيًا. يشمل ذلك عناصر النماذج في HTML مثل <input> و<select> و<textarea>، بالإضافة إلى الودجات التفاعلية المخصصة المبنية باستخدام ARIA. ويغطي التحقق من جانب العميل الذي يتم تشغيله بواسطة JavaScript، والتحقق الأصلي للمتصفح باستخدام سمات مثل required وpattern وminlength وtype، وكذلك نتائج التحقق من جانب الخادم التي يتم عرضها بعد إعادة تحميل الصفحة أو حقنها ديناميكيًا في الـ DOM.

يتطلب الاجتياز أن: (1) يكون كل حقل يحتوي على خطأ مرتبطًا برمجيًا برسالة خطأ — عادةً عبر aria-describedby أو aria-errormessage — حتى تتمكن تقنيات المساعدة من الإعلان عنها؛ (2) تكون رسالة الخطأ نصًا واضحًا مرئيًا في واجهة المستخدم (غير مخفي عن المستخدمين المبصرين)؛ و(3) يصف النص بوضوح ما حدث من خطأ، وليس مجرد الإشارة إلى أن شيئًا ما حدث خطأ. على سبيل المثال، "عنوان البريد الإلكتروني مطلوب" هو وصف خطأ صالح، بينما الاكتفاء بعرض إطار أحمر أو أيقونة تعجب بدون بديل نصي يعد فشلًا.

يحدث الفشل عندما: يتم الإشارة إلى الأخطاء فقط من خلال تغييرات اللون (إطار أحمر بدون نص)، أو يتم الإعلان عن الأخطاء فقط عبر role="alert" دون تحديد أي حقل تأثر، أو يكون نص رسالة الخطأ فارغًا أو عامًا (مثل "إدخال غير صالح")، أو تكون رسائل الخطأ موجودة في الـ DOM ولكنها غير مرتبطة برمجيًا بالحقل المقابل بحيث لا تستطيع برامج قراءة الشاشة ربطها به.

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

لماذا هو مهم

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

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

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

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

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

قواعد axe-core ذات الصلة

يتطلب WCAG 3.3.1 إجراء اختبار يدوي للتحقق الكامل. وذلك لأن الأدوات الآلية يمكنها اكتشاف وجود أو غياب الأنماط الهيكلية (مثل aria-describedby أو aria-errormessage)، لكنها لا تستطيع تقييم ما إذا كان المحتوى النصي لرسالة الخطأ ذا معنى ودقة وكفاية لمساعدة المستخدم على فهم الخطأ وتصحيحه. ترى الأداة الآلية أن عنصرًا يحمل role="alert" موجود؛ لكنها لا تستطيع الحكم على ما إذا كانت رسالة مثل "خطأ في السطر 4" تصف فشل التحقق بشكل كافٍ لمستخدم قارئ الشاشة.

• aria-required-attr: تتحقق قاعدة axe-core هذه من أن العناصر ذات أدوار ARIA معينة تحتوي على جميع سمات ARIA المطلوبة. وعلى الرغم من أنها ليست قاعدة مخصصة لتحديد الأخطاء فقط، إلا أنها ذات صلة لأن حقل نموذج في حالة خطأ يستخدم role="textbox" أو ما شابه بدون السمات المطلوبة قد يفشل في نقل حالة الحقل إلى تقنيات المساعدة، مما يقوض عملية توصيل الخطأ.
• aria-valid-attr-value: تشير هذه القاعدة إلى الحالات التي تشير فيها سمات ARIA إلى معرفات (IDs) غير موجودة في الـ DOM. على سبيل المثال، إذا استخدم حقل ما aria-describedby="email-error" ولكن لا يوجد عنصر يحمل id="email-error"، فإن الارتباط يكون مكسورًا ولن تُقرأ رسالة الخطأ بواسطة برامج قراءة الشاشة. هذا نمط فشل شائع بالنسبة للمعيار 3.3.1.
• متطلب التقييم اليدوي: يجب على المختبرين إثارة أخطاء التحقق يدويًا ثم استخدام قارئ شاشة للتأكد من أن: الحقل الذي يحتوي على الخطأ يتم تحديده بالاسم أو التسمية، يتم الإعلان عن وصف الخطأ، تكون الرسالة ذات معنى وقابلة للتنفيذ، ولا يتم توصيل الخطأ فقط بوسائل غير نصية. لا يمكن لعمليات الفحص الآلية محاكاة تسلسلات تفاعل المستخدم أو تقييم الجودة الدلالية للنص، مما يجعل الحكم البشري لا غنى عنه لهذا المعيار.

كيفية الاختبار

1. فحص آلي باستخدام axe DevTools أو Lighthouse: قم بتشغيل فحص axe DevTools على الصفحة التي تحتوي على النموذج قبل وبعد إثارة أخطاء التحقق. ابحث تحديدًا عن الانتهاكات المتعلقة بمراجع aria-describedby أو aria-errormessage المكسورة، وغياب مناطق role="alert" أو aria-live المستخدمة لحقن الأخطاء ديناميكيًا، وحقول النماذج التي تفتقر إلى تسميات (مما يمنع أيضًا الربط الصحيح للأخطاء). في Lighthouse، تحقق من تدقيق إمكانية الوصول بحثًا عن الانتهاكات المتعلقة بالنماذج. لاحظ أن تقريرًا آليًا نظيفًا لا يؤكد الامتثال للمعيار 3.3.1 — بل يستبعد فقط بعض الإخفاقات الهيكلية.
2. اختبار التنقل اليدوي بلوحة المفاتيح: باستخدام لوحة المفاتيح فقط (Tab وShift+Tab وEnter وSpace)، حاول إرسال النموذج بقيم خاطئة أو مفقودة عمدًا. تحقق من أن: التركيز ينتقل إلى أو بالقرب من أول حقل يحتوي على خطأ، وأن كل رسالة خطأ مرئية في نافذة العرض، وأن رسائل الخطأ تحدد الحقل المحدد بالاسم وتصف المشكلة بنص واضح.
3. اختبار قارئ الشاشة باستخدام NVDA + Firefox: افتح النموذج في Firefox مع تفعيل NVDA. أرسل النموذج مع وجود أخطاء. استمع بعناية: هل يعلن NVDA عن الحقل الذي يحتوي على خطأ؟ هل يتم قراءة وصف الخطأ بصوت عالٍ؟ انتقل باستخدام Tab إلى الحقل الذي يحتوي على الخطأ — هل يقرأ NVDA رسالة الخطأ المرتبطة كجزء من الوصف المتاح للحقل؟ إذا كنت تستخدم مناطق aria-live، فتحقق من أن الإعلان ليس متأخرًا أو محجوبًا.
4. اختبار قارئ الشاشة باستخدام VoiceOver + Safari (macOS/iOS): كرر نفس العملية باستخدام VoiceOver على Safari. استخدم VO+السهم الأيمن لقراءة النموذج بعد الإرسال. تأكد من أن كل حقل يحتوي على خطأ يتضمن نص الخطأ في اسمه أو وصفه المتاح. على iOS، اختبر باستخدام التنقل باللمس وإيماءات السحب.
5. اختبار قارئ الشاشة باستخدام JAWS + Chrome: مع تشغيل JAWS في Chrome، أرسل النموذج مع وجود أخطاء. استخدم المؤشر الافتراضي لـ JAWS للتنقل إلى كل حقل نموذج يحتوي على خطأ. تأكد من أن نص رسالة الخطأ مضمَّن في قراءة JAWS للحقل. تحقق أيضًا من سلوك وضع النماذج في JAWS، حيث إن وضع النماذج قد يمنع بعض إعلانات مناطق live.
6. تدقيق الألوان والإشارات غير النصية: افحص كل حالة خطأ بصريًا. قم بإزالة أو تعطيل CSS مؤقتًا (باستخدام أدوات المطور في المتصفح أو bookmarklet) وتأكد من أن تحديد الخطأ لا يزال موجودًا كنص في الـ DOM. هذا يتحقق من أن توصيل الخطأ لا يعتمد فقط على اللون أو الأيقونات.
7. فحص الحقن الديناميكي: بالنسبة لتطبيقات الصفحة الواحدة أو النماذج ذات التحقق في الوقت الفعلي، استخدم أدوات المطور في المتصفح لفحص الـ DOM بعد إثارة خطأ. تأكد من أن عنصر رسالة الخطأ موجود في الـ DOM، ويحتوي على نص غير فارغ، ويتم الإشارة إليه بواسطة حقل الإدخال المقابل عبر aria-describedby أو aria-errormessage.

كيفية الإصلاح

السيناريو 1: خطأ يُشار إليه فقط باللون — غير صحيح

<!-- Fail: red border added via class, no error text associated -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' class='input-error'>
<!-- CSS sets border: 2px solid red on .input-error -->
<!-- No error message text is rendered in the DOM -->

السيناريو 1: خطأ يُشار إليه فقط باللون — صحيح

<!-- Pass: error text is present, visible, and linked to the input -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  class='input-error'
  aria-describedby='email-error'
  aria-invalid='true'
>
<!-- aria-invalid signals the error state to assistive technologies -->
<!-- aria-describedby links the input to its error message by ID -->
<p id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</p>

السيناريو 2: ملخص خطأ عام بدون تحديد الحقول — غير صحيح

<!-- Fail: a summary alert exists but does not identify which fields failed -->
<div role='alert'>
  <p>There are errors in the form. Please correct them and try again.</p>
</div>
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' name='phone' class='is-invalid'>
<!-- No per-field error message; user cannot determine which field failed -->

السيناريو 2: ملخص خطأ عام بدون تحديد الحقول — صحيح

<!-- Pass: summary lists specific fields in error, and each field has inline error text -->
<div role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>2 errors found. Please fix the following:</h2>
  <ul>
    <li><a href='#phone'>Phone Number: must contain only digits and be 10 characters long</a></li>
    <li><a href='#dob'>Date of Birth: required field — please enter your date of birth</a></li>
  </ul>
</div>
<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-error'
  aria-invalid='true'
>
<!-- Inline error linked via aria-describedby -->
<p id='phone-error'>Phone Number must contain only digits and be 10 characters long.</p>

السيناريو 3: مرجع aria-describedby مكسور — غير صحيح

<!-- Fail: aria-describedby references an ID that does not exist in the DOM -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- The element with id='username-msg' was never rendered or was removed -->
<!-- Screen readers find no target and announce nothing for the description -->

السيناريو 3: مرجع aria-describedby مكسور — صحيح

<!-- Pass: the referenced element exists in the DOM with matching ID -->
<label for='username'>Username</label>
<input
  type='text'
  id='username'
  name='username'
  aria-describedby='username-msg'
  aria-invalid='true'
>
<!-- Element with matching id is present and contains descriptive text -->
<span id='username-msg'>
  Username must be between 4 and 20 characters and contain only letters and numbers.
</span>

السيناريو 4: خطأ تحقق في الوقت الفعلي يُحقن ديناميكيًا — غير صحيح

<!-- Fail: error injected into DOM but not associated with input; no live region -->
<label for='password'>Password</label>
<input type='password' id='password' name='password'>
<!-- After blur, JavaScript appends this element, but no aria-describedby on input -->
<div class='error-text'>Password is too short.</div>

السيناريو 4: خطأ تحقق في الوقت الفعلي يُحقن ديناميكيًا — صحيح

<!-- Pass: error container pre-exists in DOM (empty), input references it; aria-live announces changes -->
<label for='password'>Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-describedby='password-error'
  aria-invalid='false'
>
<!-- Empty span present at page load; JavaScript populates text and sets aria-invalid='true' on error -->
<span id='password-error' aria-live='polite'></span>
<!-- JavaScript on blur: -->
<!-- document.getElementById('password-error').textContent = 'Password must be at least 8 characters.'; -->
<!-- document.getElementById('password').setAttribute('aria-invalid', 'true'); -->

الأخطاء الشائعة

• استخدام تغييرات فئة CSS فقط (مثل إضافة border-color: red) للإشارة إلى الأخطاء دون أي نص مقابل في الـ DOM. اللون وحده لا يمكن إدراكه من قبل المستخدمين المكفوفين أو المصابين بعمى الألوان، ويفشل في الامتثال لكل من 3.3.1 و1.4.1.
• كتابة aria-describedby على حقل الإدخال ولكن الإشارة إلى معرف يتم عرضه شرطيًا أو يُزال من الـ DOM عند إعادة تعيين التحقق. يعني المرجع المكسور أن قارئ الشاشة لا يجد محتوى مرتبطًا، ويصبح الخطأ غير مرئي فعليًا لمستخدمي تقنيات المساعدة.
• استخدام نص placeholder كرسالة الخطأ الوحيدة. يختفي نص placeholder عندما يبدأ المستخدم في الكتابة، وغالبًا ما يكون منخفض التباين، ولا يتم الإعلان عنه بشكل موثوق من قبل جميع برامج قراءة الشاشة كجزء من وصف الحقل أثناء حالات الخطأ.
• حقن رسائل الخطأ ديناميكيًا في الـ DOM دون التأكد من ارتباطها بحقلها الأصلي عبر aria-describedby. رسالة خطأ مجاورة بصريًا لا ترتبط تلقائيًا بحقل الإدخال — يجب أن يكون الربط البرمجي صريحًا.
• عرض ملخص خطأ على مستوى الصفحة دون ربط كل عنصر في الملخص بالحقل المحدد الذي يحتوي على خطأ. يحتاج مستخدمو برامج قراءة الشاشة أو التنقل بلوحة المفاتيح إلى القدرة على الانتقال مباشرة من وصف الخطأ إلى الحقل الذي يتطلب التصحيح.
• تعيين aria-invalid='true' على حقل دون توفير نص رسالة خطأ. تشير سمة aria-invalid إلى أن الحقل في حالة خطأ لكنها لا تصف الخطأ — يجب دمجها مع رسالة وصفية.
• تقديم رسائل خطأ عامة للغاية، مثل "إدخال غير صالح" أو "خطأ في الحقل". لا تشرح هذه الأوصاف ما الخطأ أو كيفية إصلاحه، مما يفشل متطلب الوصف في 3.3.1 ويجعل تصحيح الأخطاء صعبًا بلا داعٍ لجميع المستخدمين.
• إزالة مناطق aria-live أو role='alert' من حاويات الأخطاء عند إعادة تعيين النموذج، مما يؤدي إلى اختفاء الحاويات قبل أن تنهي برامج قراءة الشاشة إعلان محتواها. يمكن أن تُقطع إعلانات الأخطاء، مما يترك المستخدم غير مدرك لنتيجة التحقق.
• الاعتماد على فقاعات التحقق الأصلية للمتصفح (نوافذ التلميحات الافتراضية) دون تخصيص. واجهات التحقق الأصلية للمتصفح غير متسقة عبر المتصفحات وتركيبات تقنيات المساعدة، وغالبًا لا تلبي متطلبات WCAG للتحديد والوصف في سيناريوهات النماذج المعقدة.
• وضع رسائل الخطأ بصريًا بعيدًا عن الحقول المرتبطة بها — مثل وضعها فقط في مربع تنبيه في رأس الصفحة — دون توفير رسائل مضمنة بالقرب من كل حقل أيضًا. قد لا يرى المستخدمون ضعاف البصر الذين يكبرون الشاشة تنبيه الرأس أثناء تركيزهم على منطقة الإدخال، ويضطر مستخدمو لوحة المفاتيح إلى قطع مسافة كبيرة لقراءة الخطأ.

العلاقة مع لوائح إمكانية الوصول في تركيا

تضع التعميم الرئاسي 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، متطلبات إلزامية لإمكانية الوصول على الويب لمجموعة واسعة من الكيانات العاملة في تركيا. يعتمد التعميم WCAG 2.2 كمعيار تقني، مما يجعل جميع معايير النجاح من المستوى A — بما في ذلك WCAG 3.3.1 لتحديد الأخطاء — إلزامية قانونًا للمنظمات المشمولة.

جدول الامتثال الذي حدده التعميم هو سنة واحدة للمؤسسات العامة وسنتان للكيانات في القطاع الخاص من تاريخ النشر. وهذا يعني أن على المؤسسات العامة تحقيق توافق مع WCAG 2.2 من المستوى A بحلول يونيو 2026، وعلى الكيانات المشمولة في القطاع الخاص بحلول يونيو 2027.

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

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

يمكن أن يعرّض عدم الامتثال للتعميم الكيانات المشمولة للتدقيق التنظيمي، ومخاطر السمعة، واحتمال فرض عقوبات مع نضوج إطار إنفاذ إمكانية الوصول الرقمي في تركيا. وبعيدًا عن الامتثال القانوني، يُظهر الالتزام بالمعيار 3.3.1 التزامًا بتقديم خدمات شاملة — مما يضمن أن جميع المواطنين، بما في ذلك حوالي 8.5 مليون شخص من ذوي الإعاقة في تركيا (وفقًا لبيانات TÜİK)، يمكنهم الوصول إلى الخدمات الأساسية عبر الإنترنت دون عوائق. يجب على المنظمات التي تعمل ضمن إطار SDK الخاص بـ Accsible أن تعطي الأولوية لكل من الامتثال الهيكلي الآلي والاختبار اليدوي الشامل لضمان أن معالجة الأخطاء لديها تلبي بالكامل هذا المعيار الأساسي.