WCAG 3.3.6: منع الأخطاء (الكل)

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

المعيار WCAG 3.3.6 — منع الأخطاء (الكل) هو معيار نجاح من المستوى AAA ضمن مبدأ "قابلية الفهم". وهو يوسّع متطلبات 3.3.4 (منع الأخطاء: القانونية، المالية، البيانات) ليشمل جميع الصفحات التي تتطلب من المستخدم إرسال معلومات، بغض النظر عما إذا كان هذا الإرسال يتضمن التزامات قانونية أو معاملات مالية أو بيانات تعريف شخصية.

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

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

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

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

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

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

لماذا يهم

منع الأخطاء ليس مجرد تحسين في سهولة الاستخدام — بل هو متطلب أساسي من متطلبات الإتاحة للمستخدمين الذين يواجهون مخاطر أعلى لوقوع أخطاء في الإدخال بسبب الإعاقة أو العوائق الظرفية.

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

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

مستخدمو قارئات الشاشة: المستخدمون المكفوفون الذين يتنقلون باستخدام JAWS أو NVDA أو VoiceOver قد لا يمتلكون نفس النظرة البصرية الشاملة للنموذج المكتمل التي يتمتع بها المستخدمون المبصرون قبل الإرسال. تمنحهم شاشة تأكيد أو ملخص يُقرأ بصوت عالٍ بواسطة قارئ الشاشة فرصة أخيرة للتحقق من بياناتهم قبل إرسالها بشكل لا رجعة فيه.

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

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

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

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

يتطلب المعيار WCAG 3.3.6 اختبارًا يدويًا لأنه لا توجد أداة آلية يمكنها تحديد ما إذا كان تدفق إرسال نموذج معين يفي بمتطلبات القابلية للعكس أو التحقق من الأخطاء أو التأكيد في هذا المعيار. يمكن لأدوات الفحص الآلي لإتاحة الوصول مثل axe-core التحقق من وجود سمات ARIA الفردية، والعناوين، ورسائل الخطأ، لكنها لا تستطيع تقييم منطق تدفق الإرسال ككل، أو وجود خطوة تأكيد، أو ما إذا كانت آلية التراجع تعمل فعليًا. هذا المعيار يتعلق أساسًا بتصميم التفاعل وتدفق تجربة المستخدم — وليس بالترميز الثابت.

• لا توجد قاعدة axe-core مخصصة لـ 3.3.6. تختبر axe-core ومحركات مشابهة عناصر DOM الفردية مقابل متطلبات سمات أو أدوار محددة. يتطلب تحديد ما إذا كان النموذج متعدد الصفحات يتضمن خطوة مراجعة قبل الإرسال النهائي فهم تدفق التنقل في التطبيق وسلوك جانب الخادم — وهي معلومات لا يمكن لأدوات التحليل الثابت الوصول إليها. يجب على المختبر البشري أن يمر عبر رحلة الإرسال كاملة لتقييم الامتثال.
• قواعد ذات صلة تدعم جودة النماذج بشكل عام (وإن لم تكن مخصصة لـ 3.3.6): قواعد مثل label (كل حقل إدخال له عنوان مرتبط)، وaria-required-attr (وجود سمات ARIA المطلوبة)، وform-field-multiple-labels (عدم وجود عناوين متعارضة لحقل واحد) تساهم في أساس النماذج المتاحة. ضمان اجتياز هذه القواعد شرط مسبق لمنع الأخطاء بشكل فعّال، لكن اجتيازها لا يضمن الامتثال لـ 3.3.6.
• لماذا تعجز الأتمتة: قد يؤكد فحص آلي لصفحة الدفع أن جميع حقول الإدخال لها عناوين وأن رسائل الخطأ مرتبطة برمجيًا بالحقول. لكنه لا يستطيع تحديد ما إذا كان النقر على "إرسال" ينقل المستخدم إلى شاشة مراجعة، أو ما إذا كان هناك خيار "إلغاء"، أو ما إذا كان النظام يرسل بريدًا إلكترونيًا تأكيديًا يحتوي على رابط إلغاء. هذه أسئلة تتعلق بالسلوك والعملية لا يمكن الإجابة عنها إلا من خلال التقييم البشري.

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

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

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

نموذج اتصال بدون تحقق أو مراجعة — غير صحيح

<!-- Fails 3.3.6: submits immediately with no validation, no review, no undo -->
<form action='/submit-contact' method='post'>
  <label for='name'>Name</label>
  <input type='text' id='name' name='name'>

  <label for='email'>Email</label>
  <input type='text' id='email' name='email'>

  <label for='message'>Message</label>
  <textarea id='message' name='message'></textarea>

  <button type='submit'>Send</button>
</form>

نموذج اتصال مع تحقق وخطوة تأكيد — صحيح

<!-- Step 1: Form with client-side validation before submission -->
<form id='contact-form' novalidate>
  <div role='group' aria-labelledby='form-heading'>
    <h2 id='form-heading'>Contact Us</h2>

    <div class='field-group'>
      <label for='name'>Full Name <span aria-hidden='true'>*</span></label>
      <input
        type='text'
        id='name'
        name='name'
        required
        aria-required='true'
        aria-describedby='name-error'
        autocomplete='name'
      >
      <span id='name-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='email'>Email Address <span aria-hidden='true'>*</span></label>
      <input
        type='email'
        id='email'
        name='email'
        required
        aria-required='true'
        aria-describedby='email-error'
        autocomplete='email'
      >
      <span id='email-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <div class='field-group'>
      <label for='message'>Message <span aria-hidden='true'>*</span></label>
      <textarea
        id='message'
        name='message'
        required
        aria-required='true'
        aria-describedby='message-error'
      ></textarea>
      <span id='message-error' class='error-msg' role='alert' aria-live='assertive'></span>
    </div>

    <!-- Review button triggers a confirmation summary before final submission -->
    <button type='button' onclick='showReviewScreen()'>Review &amp; Send</button>
  </div>
</form>

<!-- Step 2: Confirmation/review screen (shown after validation passes) -->
<section id='review-screen' hidden aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Message</h2>
  <p>Please review your details before sending. You can go back to make changes.</p>

  <dl>
    <dt>Full Name</dt>
    <dd id='review-name'></dd>
    <dt>Email</dt>
    <dd id='review-email'></dd>
    <dt>Message</dt>
    <dd id='review-message'></dd>
  </dl>

  <!-- Edit option satisfies the 'reversible/correctable before final commit' requirement -->
  <button type='button' onclick='goBackToForm()'>Edit My Details</button>
  <button type='button' onclick='submitFinalForm()'>Confirm and Send</button>
</section>

معالج متعدد الخطوات بدون خطوة ملخص — غير صحيح

<!-- Fails 3.3.6: final step submits directly without allowing user to review previous steps -->
<form action='/register' method='post'>
  <!-- Step 3 of 3 — no ability to review steps 1 and 2 -->
  <h2>Step 3: Payment</h2>
  <label for='card'>Card Number</label>
  <input type='text' id='card' name='card'>
  <button type='submit'>Complete Registration</button>
</form>

معالج متعدد الخطوات مع خطوة مراجعة نهائية — صحيح

<!-- Step 4 of 4: Summary review before final submission -->
<section aria-labelledby='summary-heading'>
  <h2 id='summary-heading'>Step 4 of 4: Review Your Registration</h2>
  <p>Please confirm the information below before completing your registration. Use the edit links to correct any errors.</p>

  <h3>Personal Details
    <a href='/register/step-1' aria-label='Edit personal details'>Edit</a>
  </h3>
  <dl>
    <dt>Full Name</dt><dd>Ayşe Kaya</dd>
    <dt>Date of Birth</dt><dd>15/04/1988</dd>
  </dl>

  <h3>Contact Information
    <a href='/register/step-2' aria-label='Edit contact information'>Edit</a>
  </h3>
  <dl>
    <dt>Email</dt><dd>[email protected]</dd>
    <dt>Phone</dt><dd>+90 532 000 0000</dd>
  </dl>

  <h3>Payment
    <a href='/register/step-3' aria-label='Edit payment details'>Edit</a>
  </h3>
  <dl>
    <dt>Card ending</dt><dd>**** 4242</dd>
  </dl>

  <!-- Final submit only after user has reviewed all data -->
  <form action='/register/complete' method='post'>
    <button type='submit'>Confirm and Complete Registration</button>
  </form>
</section>

نموذج بإرسال فوري ودون تراجع — غير صحيح

<!-- Fails 3.3.6: deletes comment immediately with no undo or confirmation -->
<form action='/comments/42/delete' method='post'>
  <button type='submit'>Delete Comment</button>
</form>

إجراء هدّام مع مربع حوار تأكيد — صحيح

<!-- Passes 3.3.6: user must confirm before destructive action is executed -->
<button
  type='button'
  aria-haspopup='dialog'
  onclick='openConfirmDialog(42)'
>
  Delete Comment
</button>

<dialog
  id='confirm-delete-dialog'
  aria-labelledby='dialog-title'
  aria-describedby='dialog-desc'
>
  <h2 id='dialog-title'>Delete this comment?</h2>
  <p id='dialog-desc'>
    This action cannot be undone. The comment will be permanently removed.
  </p>
  <form action='/comments/42/delete' method='post'>
    <button type='submit'>Yes, Delete</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

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

• تنفيذ التحقق دون إظهاره لمستخدمي قارئات الشاشة: عرض رسائل الخطأ بصريًا عبر تغييرات في ألوان CSS أو الأيقونات دون ربطها بحقل الإدخال باستخدام aria-describedby أو حقنها في منطقة aria-live يعني أن المستخدمين المكفوفين لن يسمعوا الخطأ — فيبدو النموذج وكأنه أُرسل بنجاح بينما هو في الواقع لا يزال غير مكتمل.
• اعتبار الامتثال لـ 3.3.4 كافيًا للمستوى AAA: غالبًا ما تنفذ الفرق منع الأخطاء فقط في النماذج المالية أو القانونية (مستوفية 3.3.4) وتفترض أن جميع النماذج مغطاة. يتطلب المعيار 3.3.6 توفير نفس الحماية لكل نموذج في الموقع، بما في ذلك الاشتراك في النشرات البريدية، والتعليقات، وتحديثات الملف الشخصي.
• توفير شاشة تأكيد للقراءة فقط دون مسار للتعديل: صفحة مراجعة تعرض البيانات المرسلة لكنها تقدم زر "تأكيد" فقط — دون طريقة للعودة وتصحيح الأخطاء — لا تفي بالكامل بروح المعيار وتترك المستخدمين دون حل إذا اكتشفوا خطأ أثناء المراجعة.
• استخدام window.confirm() كآلية التأكيد الوحيدة: مربعات حوار التأكيد الأصلية في المتصفح ليست متاحة لجميع المستخدمين ولا يمكن تصميمها أو تنظيمها لزيادة الوضوح. كما أنها تتصرف بشكل غير متسق عبر تقنيات المساعدة. استخدم عنصر <dialog> مناسبًا مع سمات ARIA الملائمة بدلًا من ذلك.
• إعادة تعيين النموذج بالكامل عند فشل التحقق بدلًا من الحفاظ على الإدخالات الصحيحة: عندما يرسل المستخدم نموذجًا يحتوي على 10 حقول مع خطأ واحد فقط ويتم مسح جميع الحقول، يجب عليه إعادة إدخال كل البيانات. هذا مرهق بشكل خاص للمستخدمين ذوي الإعاقات الحركية أو الإرهاق الإدراكي. حافظ دائمًا على البيانات الصحيحة وركّز الانتباه فقط على الحقول الخاطئة.
• وضع ملخص رسائل الخطأ خارج إطار العرض أو ترتيب التركيز بلوحة المفاتيح: لا يفيد شريط ملخص الأخطاء الذي يُحقن أعلى الصفحة بعد فشل الإرسال المستخدمين الذين يتركز تركيزهم في منتصف النموذج. استخدم aria-live='assertive' على حاوية الملخص وانقل التركيز برمجيًا إليها عند فشل الإرسال.
• وضع عناوين غامضة على أزرار التأكيد مثل "موافق" أو "نعم": في شاشة المراجعة، يجب أن توضح الأزرار بجلاء ما سيحدث. "تأكيد وإرسال الرسالة" غير ملتبس؛ أما "موافق" فليس كذلك — خاصة لمستخدمي قارئات الشاشة الذين قد لا تتوفر لديهم السياقات البصرية المحيطة.
• افتراض أن التحقق على جانب الخادم وحده يفي بالمعيار: إذا غاب التحقق على جانب العميل، يتطلب كل إرسال رحلة كاملة إلى الخادم قبل أن يعرف المستخدم بوجود خطأ. قد يجد المستخدمون على اتصالات بطيئة أو الذين يفقدون الاتصال أثناء الإرسال أنفسهم في حالة غير واضحة دون ملاحظات خطأ واضحة.
• عدم اختبار آلية القابلية للعكس في ظروف واقعية: أحيانًا تنفذ الفرق خيار "إلغاء" في بريد إلكتروني تأكيدي لكنها لا تختبر ما إذا كان رابط الإلغاء متاحًا، أو ما إذا كان يعمل بعد انتهاء النافذة الزمنية، أو ما إذا كان الرابط قابلًا للاستخدام بواسطة قارئات الشاشة. آلية التراجع غير المتاحة لا تفي بالمعيار.
• الفشل في التعامل مع حالات الملء التلقائي في شاشات المراجعة: عندما يملأ المتصفح أو مدير كلمات المرور حقول النموذج تلقائيًا، قد لا تتطابق القيم المعروضة في شاشة المراجعة مع ما تم إرساله فعليًا إذا كان JavaScript الذي يملأ شاشة المراجعة يسحب القيم من DOM قبل اكتمال الملء التلقائي. اسحب القيم دائمًا مباشرة قبل عرض شاشة المراجعة، وليس عند تحميل الصفحة لأول مرة.

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

تُقرّ التعميم الرئاسي التركي 2025/10، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، التزامات إلزامية للإتاحة الرقمية لمجموعة واسعة من الكيانات العاملة في تركيا. يتطلب التعميم من الجهات المشمولة الامتثال لمعيار WCAG 2.2 عند مستوى AA كحد أدنى. تشمل الكيانات المشمولة صراحةً المؤسسات والهيئات العامة، ومنصات التجارة الإلكترونية، والبنوك والمؤسسات المالية، والمستشفيات ومقدمي الرعاية الصحية، وشركات الاتصالات التي لديها 200,000 مشترك أو أكثر، ووكالات السفر المرخصة، وشركات النقل الخاصة، والمدارس الخاصة المعتمدة من قبل وزارة التربية الوطنية (MoNE).

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

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