WCAG 3.3.3: اقتراح الخطأ

ماذا تعني هذه القاعدة

المعيار WCAG 3.3.3 اقتراح الخطأ هو معيار من مستوى AA ضمن مبدأ "قابل للفهم". وهو يبني مباشرة على المعيار 3.3.1 (تحديد الخطأ)، الذي ي要求 تحديد الأخطاء نصيًا. يذهب اقتراح الخطأ خطوة أبعد: عندما يتم اكتشاف خطأ في الإدخال تلقائيًا، يجب على الواجهة أيضًا اقتراح كيفية تصحيحه للمستخدم، بشرط ألا يعرّض هذا الاقتراح أمان المحتوى أو غرضه للخطر.

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

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

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

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

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

لماذا يهم

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

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

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

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

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

سيناريو واقعي: تخيل مواطنًا تركيًا يتقدم بطلب للحصول على إعانة اجتماعية عبر بوابة حكومية إلكترونية. يتطلب الطلب رقم الهوية التركية (TC Kimlik Numarası)، وهو صيغة محددة من 11 رقمًا. إذا أدخل المستخدم 10 أرقام وتلقى فقط الرسالة "TC Kimlik Numarası hatalı" (رقم الهوية التركية غير صحيح)، فقد لا يعرف مستخدم ذو إعاقة إدراكية أو مستخدم مسن أو مستخدم قارئ شاشة ما إذا كان الرقم قصيرًا جدًا، أو يحتوي على حرف غير صالح، أو به مشكلة في التنسيق. إضافة "TC Kimlik Numarası 11 haneli olmalıdır, örneğin: 12345678901" (يجب أن يتكون رقم الهوية التركية من 11 رقمًا، مثل: 12345678901) تحل الغموض فورًا وتمكّن المستخدم من تصحيح الخطأ بنفسه.

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

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

يتطلب المعيار WCAG 3.3.3 اختبارًا يدويًا لأن الأدوات الآلية لا يمكنها تقييم جودة أو اكتمال نص رسالة الخطأ. يمكن لأداة الفحص الآلي اكتشاف وجود رسالة خطأ وأنها مرتبطة برمجيًا بحقل نموذج، لكنها لا تستطيع تحديد ما إذا كانت الرسالة تقدم بالفعل اقتراحًا تصحيحيًا مفيدًا. يتطلب ذلك حكمًا بشريًا لتقييم ما إذا كان النص محددًا وقابلًا للتنفيذ وكافيًا لتوجيه المستخدم نحو إدخال صالح.

• مراجعة يدوية — جودة محتوى رسالة الخطأ: يجب على المختبرين تشغيل كل شرط من شروط التحقق يدويًا (إرسال حقل مطلوب فارغ، إدخال بيانات بصيغة خاطئة، تجاوز حدود الأحرف، إلخ) وتقييم كل رسالة خطأ ناتجة. يسأل المختبر: هل تخبر هذه الرسالة المستخدم ليس فقط بأن خطأ قد حدث، بل تحديدًا ما الذي يجب عليه فعله لتصحيحه؟ إذا كانت الرسالة عامة ("غير صالح"، "خطأ"، "يرجى التحقق من هذا الحقل")، فإنها تفشل في استيفاء المعيار 3.3.3 بغض النظر عما إذا كانت مكشوفة برمجيًا أم لا.
• مراجعة يدوية — الارتباط البرمجي: يجب على المختبرين التحقق من أن نص اقتراح الخطأ مرتبط برمجيًا بحقل الإدخال ذي الصلة باستخدام aria-describedby أو مناطق aria-live أو الارتباط المضمّن، بحيث تعلن قارئات الشاشة عنه دون الحاجة إلى تنقل إضافي. يتداخل هذا جزئيًا مع قواعد axe مثل label وaria-input-field-name، لكن نص الاقتراح نفسه لا يتم التحقق منه بواسطة هذه القواعد.
• مراجعة يدوية — صحة استثناء الأمان: يجب على المختبرين التحقق من أن أي نموذج لا يتضمن اقتراحات تصحيحية لأسباب أمنية (مثل نماذج تسجيل الدخول) يستوفي بالفعل شروط استثناء الأمان، وأن هذا الاستثناء لا يُستخدم لتجنب المتطلبات في الحقول غير الحساسة.
• آلي جزئيًا — قاعدة label: بينما تتحقق قاعدة label في axe-core من أن حقول النموذج لها أسماء يمكن الوصول إليها، فإنها لا تتحقق مما إذا كانت رسائل الخطأ تقدم اقتراحات تصحيحية. يمكنها إظهار التسميات المفقودة التي ستفاقم مشكلة اقتراح الخطأ، وإصلاح مشكلات التسميات هو شرط مسبق لتنفيذ فعال لاقتراح الخطأ.

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

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

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

رسالة خطأ عامة — غير صحيح

<!-- Error message provides no suggestion on how to fix the problem -->
<label for='email'>Email Address</label>
<input type='email' id='email' name='email' aria-invalid='true' />
<span class='error'>Invalid email address.</span>

رسالة خطأ عامة — صحيح

<!-- aria-describedby links the suggestion text to the input;
     the suggestion explains exactly what format is expected -->
<label for='email'>Email Address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
/>
<span id='email-error' class='error' role='alert'>
  Please enter a valid email address in the format [email protected].
</span>

التحقق من كلمة المرور بدون إرشاد حول الصيغة — غير صحيح

<!-- User is told the password is wrong but not why or how to fix it -->
<label for='password'>Create Password</label>
<input type='password' id='password' name='password' aria-invalid='true' />
<p class='error'>Password is not valid.</p>

التحقق من كلمة المرور بدون إرشاد حول الصيغة — صحيح

<!-- The suggestion lists exactly what the password must contain,
     enabling the user to self-correct without guessing -->
<label for='password'>Create Password</label>
<input
  type='password'
  id='password'
  name='password'
  aria-invalid='true'
  aria-describedby='password-error'
/>
<span id='password-error' class='error' role='alert'>
  Password must be at least 8 characters and include at least one
  uppercase letter, one number, and one special character (e.g. !, @, #).
</span>

حقل تاريخ مع خطأ غامض في الصيغة — غير صحيح

<!-- No indication of which date format is expected -->
<label for='dob'>Date of Birth</label>
<input type='text' id='dob' name='dob' aria-invalid='true' />
<span class='error'>Date is incorrect.</span>

حقل تاريخ مع خطأ غامض في الصيغة — صحيح

<!-- The suggestion states the required format and provides
     a concrete example, removing all ambiguity -->
<label for='dob'>Date of Birth</label>
<input
  type='text'
  id='dob'
  name='dob'
  aria-invalid='true'
  aria-describedby='dob-error'
  placeholder='DD/MM/YYYY'
/>
<span id='dob-error' class='error' role='alert'>
  Please enter your date of birth in DD/MM/YYYY format, for example
  15/03/1985.
</span>

نموذج متعدد الحقول مع ملخص أخطاء على جانب الخادم — غير صحيح

<!-- Error summary exists but links do not associate suggestions
     with individual fields, and messages are vague -->
<div class='error-summary'>
  <p>Please correct the following errors:</p>
  <ul>
    <li>Name error</li>
    <li>Phone error</li>
  </ul>
</div>

نموذج متعدد الحقول مع ملخص أخطاء على جانب الخادم — صحيح

<!-- Error summary includes linked, specific suggestions;
     each list item links to the relevant field;
     inline errors also appear adjacent to each field -->
<div class='error-summary' role='alert' aria-labelledby='error-heading'>
  <h2 id='error-heading'>There are 2 errors on this form</h2>
  <ul>
    <li>
      <a href='#full-name'>
        Full Name: Please enter your first and last name.
      </a>
    </li>
    <li>
      <a href='#phone'>
        Phone Number: Enter 10 digits without spaces, e.g. 05321234567.
      </a>
    </li>
  </ul>
</div>

<label for='full-name'>Full Name</label>
<input
  type='text'
  id='full-name'
  name='full-name'
  aria-invalid='true'
  aria-describedby='full-name-error'
/>
<span id='full-name-error' class='error'>
  Please enter your first and last name.
</span>

<label for='phone'>Phone Number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-invalid='true'
  aria-describedby='phone-error'
/>
<span id='phone-error' class='error'>
  Enter 10 digits without spaces or dashes, for example 05321234567.
</span>

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

• استخدام placeholder كبديل لاقتراحات الخطأ: يختفي نص العنصر النائب بمجرد أن يبدأ المستخدم في الكتابة ولا يتم الإعلان عنه بشكل موثوق بواسطة قارئات الشاشة كخطأ. لا تعتمد أبدًا على نص العنصر النائب وحده للتواصل حول الصيغة المطلوبة بعد حدوث خطأ.
• عرض رسائل الخطأ فقط في إشعار عائم (toast) يختفي بعد بضع ثوانٍ: الإشعارات العابرة ليست قابلة للإدراك لجميع المستخدمين — قد يفوت مستخدمو قارئات الشاشة الإعلان، وتختفي الرسالة قبل أن يتمكن القارئ البطيء من معالجتها. يجب أن تستمر اقتراحات الخطأ في الظهور حتى يتم تصحيح الخطأ.
• استخدام aria-invalid='true' بدون aria-describedby يشير إلى نص الاقتراح: تعيين aria-invalid يشير إلى أن الحقل يحتوي على خطأ، لكن بدون ربط aria-describedby بعنصر الاقتراح، لن تقرأ قارئات الشاشة نص الاقتراح عند تركيز الحقل.
• تقديم الاقتراح فقط في التصميم البصري (مثل تلميح أداة عند التمرير) وليس في DOM: تلميحات الأدوات التي تظهر عند التمرير فقط غير متاحة لمستخدمي لوحة المفاتيح ومستخدمي قارئات الشاشة. يجب أن يكون نص الاقتراح موجودًا في DOM ومرتبطًا برمجيًا بالحقل.
• استخدام اللون أو الأيقونات وحدها للإشارة إلى الحقل الذي يحتوي على خطأ: لا يُعد الإطار الأحمر أو أيقونة التحذير اقتراح خطأ. يجب أن يكون الاقتراح وصفًا نصيًا يشرح الإجراء التصحيحي، وليس مؤشرًا بصريًا.
• كتابة اقتراحات تحدد المشكلة دون الحل: "كلمة المرور الخاصة بك قصيرة جدًا" تحدد الخطأ لكنها لا تقترح إصلاحًا. "يجب أن تتكون كلمة المرور الخاصة بك من 8 أحرف على الأقل" تقدم الإرشاد التصحيحي اللازم. كلا الجزأين مطلوبان للامتثال للمعيار 3.3.3.
• تطبيق استثناء الأمان بشكل مفرط الاتساع: ينطبق استثناء الأمان بشكل ضيق على الحالات التي يؤدي فيها تقديم اقتراح إلى تعريض الأمان للخطر بالفعل — وعادة ما يقتصر على حقول المصادقة. لا ينطبق على حقول النماذج القياسية مثل الأسماء أو العناوين أو أرقام الهواتف، حيث لا مبرر للأخطاء العامة.
• وضع اقتراح الخطأ بعد زر الإرسال أو بعيدًا عن الحقل: يجب أن تكون اقتراحات الخطأ قريبة بصريًا وبرمجيًا من الحقل الذي تصفه. وضع جميع الأخطاء في أسفل نموذج طويل، دون تضمين اقتراحات مضمنة عند كل حقل، يجبر المستخدمين على تبديل السياق وتذكر أي اقتراح ينطبق على أي حقل.
• الفشل في نقل التركيز إلى ملخص الأخطاء بعد إرسال فاشل على جانب الخادم: عندما يُعاد تحميل الصفحة بعد إرسال فاشل، يعود التركيز عادةً إلى أعلى الصفحة. بدون إدارة تركيز برمجية إلى ملخص الأخطاء أو إلى أول حقل يحتوي على خطأ، يجب على مستخدمي قارئات الشاشة التنقل في الصفحة بأكملها لاكتشاف ما حدث.
• استخدام لغة غامضة مثل "يرجى التحقق من إدخالك" أو "حدث خطأ ما": لا تقدم هذه الرسائل أي معلومات حول ما الخطأ أو كيفية إصلاحه. يجب أن يكون كل اقتراح خطأ محددًا بالحقل وقاعدة التحقق المحددة التي تم انتهاكها.

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

تقدمت بيئة إمكانية الوصول في تركيا بشكل كبير مع التعميم الرئاسي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025. يضع هذا التعميم متطلبات إلزامية لإمكانية الوصول على الويب والهواتف المحمولة متوافقة مع WCAG 2.2، مع اشتراط مستوى AA للجهات التي تسعى للحصول على Erişilebilirlik Logosu (شعار إمكانية الوصول) الصادر عن وزارة الأسرة والخدمات الاجتماعية (Aile ve Sosyal Hizmetler Bakanlığı).

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

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

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

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

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

كما تقع وكالات السفر، وشركات النقل الخاصة، والمدارس الخاصة المرخصة من وزارة التربية الوطنية (MoNE) ضمن النطاق. يجب أن تستوفي نماذج الحجز، وطلبات التسجيل، وواجهات الدفع التي تديرها هذه الجهات معايير مستوى AA بما في ذلك المعيار 3.3.3.

من منظور الامتثال العملي، ينبغي على المنظمات التي تسعى للحصول على Erişilebilirlik Logosu أن تتعامل مع المعيار WCAG 3.3.3 كنقطة تدقيق رئيسية أثناء أي تقييم لإمكانية الوصول. يتطلب الأمر اختبارًا يدويًا لجميع تدفقات التحقق من صحة النماذج — بما في ذلك حالات الأخطاء على جانب العميل والخادم — ويجب الاحتفاظ بتوثيق مبررات استثناء الأمان لأي حقول يتم فيها حجب الاقتراحات التصحيحية عمدًا. سيؤدي الفشل في استيفاء متطلبات مستوى AA، بما في ذلك معيار اقتراح الخطأ، إلى منع منح الشعار وقد يعرّض الجهات المشمولة لعواقب إدارية بموجب التعميم.