WCAG 3.3.4: منع الأخطاء (قانونية، مالية، بيانات)

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

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

يفرض هذا المعيار توفير واحد على الأقل من وسائل الحماية الثلاث التالية لأي عملية إرسال من هذا النوع:

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

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

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

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

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

لماذا هو مهم

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

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

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

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

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

سيناريو واقعي: مستخدمة كفيفة في إسطنبول تحجز رحلة داخلية باستخدام قارئ شاشة. تختار تاريخًا لكنها تتجاوز حقل عدد الركاب عن طريق الخطأ، تاركة القيمة الافتراضية راكبين اثنين بدلًا من واحد. إذا قام موقع الحجز بخصم المبلغ من بطاقتها بمجرد تفعيل "تأكيد"، فستكون قد اشترت تذكرتين وقد تواجه غرامات على أجور غير قابلة للاسترداد. شاشة مراجعة تقرأ بصوت عالٍ "1 راكب: Ayşe Yılmaz، أنقرة إلى إسطنبول، 14 March، Economy — الإجمالي: ₺850" كانت ستتيح لها اكتشاف الخطأ فورًا.

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

يتطلب WCAG 3.3.4 اختبارًا يدويًا. لا توجد قاعدة axe-core آلية تطابق هذا المعيار مباشرة لأن وسائل الحماية التي يفرضها — قابلية التراجع، والتحقق مع فرصة التصحيح، وخطوات التأكيد — هي مسائل تتعلق بتدفق التطبيق ومنطق الأعمال، وليست مسائل بنية ترميز أو سمات DOM. يمكن للأدوات الآلية تحليل HTML وARIA، لكنها لا تستطيع تحديد ما إذا كان زر "Pay Now" يُطلق خصمًا لا يمكن التراجع عنه، أو ما إذا كانت سياسة إلغاء موجودة، أو ما إذا كانت البيانات المعروضة في شاشة المراجعة تعكس بدقة ما تم إدخاله.

• لماذا لا يمكن للأتمتة اكتشاف ذلك: يرى الماسح الآلي عنصر <button> بنص "Submit" وترميز صالح. ليس لديه طريقة لمعرفة ما إذا كان تفعيل هذا الزر يبدأ معاملة مالية ملزمة، أو ما إذا كان سيتبع ذلك مربع حوار تأكيد، أو ما إذا كان يمكن التراجع عن المعاملة بعد ذلك. هذه قرارات معمارية وتجريبية (UX) تقع فوق مستوى عقد DOM الفردية، وتتطلب مختبرًا بشريًا يفهم رحلة المستخدم كاملة.
• إشارات جزئية للبحث عنها أثناء الفحص الآلي: بينما لا يشير axe-core مباشرة إلى انتهاكات 3.3.4، يستخدم المدققون أحيانًا axe لتحديد مشكلات ذات صلة تزيد من المخاطر — مثل غياب سمات autocomplete في حقول الدفع (ذات صلة بـ 1.3.5)، أو غياب رسائل الخطأ (ذات صلة بـ 3.3.1 و3.3.3)، أو غياب التسميات على عناصر التحكم في النماذج (ذات صلة بـ 1.3.1 و4.1.2). تجعل هذه الإخفاقات المرتبطة منع الأخطاء أكثر صعوبة.
• منهجية التدقيق اليدوي الموصى بها: ينبغي للمختبرين رسم خريطة لكل رحلة مستخدم تتضمن إرسالًا قانونيًا أو ماليًا أو تعديل/حذف بيانات، ثم تقييم كل رحلة مقابل المعايير الثلاثة: هل هناك طريقة للتراجع؟ هل يوجد تحقق ضمني مع فرصة للتصحيح؟ هل توجد خطوة مراجعة وتأكيد؟ الإخفاق في استيفاء الشروط الثلاثة جميعًا في أي رحلة من هذا النوع يُعد إخفاقًا في 3.3.4.

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

1. حصر النماذج عالية المخاطر: قبل بدء الاختبار، أنشئ قائمة بكل نموذج أو سير عمل تفاعلي على الموقع يتضمن معاملات مالية (الدفع، السداد، الفوترة)، أو التزامات قانونية (توقيع عقد، الاشتراك في خدمة، نماذج الموافقة)، أو تعديل/حذف بيانات (تعديل الملف الشخصي، حذف الملفات، حذف الحساب). هذه هي التدفقات الوحيدة التي تقع ضمن نطاق 3.3.4.
2. تشغيل فحص آلي للمشكلات ذات الصلة: استخدم axe DevTools أو Lighthouse لتحديد إخفاقات إمكانية الوصول على مستوى النماذج في كل صفحة ضمن النطاق. رغم أن هذه الأدوات لن تشير مباشرة إلى 3.3.4، فإن معالجة مشكلات مثل غياب التسميات، وغياب سمات الإكمال التلقائي، وغياب إعلانات الأخطاء يضع أساسًا لجودة النماذج قبل تقييم وسيلة منع الأخطاء.
3. اختبار وسيلة "التحقق": أرسل عمدًا كل نموذج ضمن النطاق مع أخطاء مقصودة — أرقام مقلوبة في رقم البطاقة، تاريخ غير صالح، حقل تأكيد بريد إلكتروني غير مطابق. راقب ما إذا كان النظام يوقف الإرسال، ويحدد الخطأ المحدد، ويصف كيفية إصلاحه (وفقًا لـ 3.3.3)، ويبقي المستخدم في النموذج لإجراء التصحيحات. إذا تم إرسال النموذج بصمت أو عُرضت رسالة خطأ عامة فقط دون تحديد الحقل الذي فشل، فإن هذه الوسيلة غير مستوفاة.
4. اختبار وسيلة "التأكيد": أكمل كل نموذج ضمن النطاق ببيانات صحيحة وامضِ عبر التدفق كاملًا. تحقق مما إذا كانت هناك خطوة مراجعة قبل الإرسال النهائي. تأكد من أن خطوة المراجعة تعرض كل البيانات المدخلة بصيغة قابلة للقراءة، وتتضمن آلية للعودة والتعديل، وتتطلب إجراءً نهائيًا متعمدًا لإتمام الإرسال. باستخدام NVDA مع Firefox وJAWS مع Chrome، تنقل في خطوة المراجعة باستخدام قارئ الشاشة للتأكد من الإعلان عن جميع القيم وأن عناصر التحكم في التعديل والتأكيد قابلة للوصول عبر لوحة المفاتيح.
5. اختبار وسيلة "قابلية التراجع": أكمل عملية إرسال ثم حاول التراجع عنها. في التجارة الإلكترونية، ابحث عن رابط إلغاء في رسالة التأكيد الإلكترونية أو في صفحة سجل الطلبات. في حالة حذف البيانات، ابحث عن آلية استعادة أو سلة مهملات. قيّم ما إذا كان إطار التراجع موضحًا بوضوح للمستخدم قبل الإرسال، وليس بعده فقط.
6. جولة باستخدام قارئ الشاشة (VoiceOver + Safari على macOS/iOS): تنقل عبر عملية الدفع أو الإرسال كاملة باستخدام لوحة المفاتيح وVoiceOver فقط. تأكد من أن شاشة المراجعة تقرأ جميع القيم المدخلة بترتيب منطقي، وأن روابط التعديل يُعلن عنها بسياق كافٍ (مثل "تعديل عنوان الشحن" وليس فقط "تعديل")، وأن الغرض من زر التأكيد النهائي غير ملتبس.
7. فحص عبء الإدراك: قيّم ما إذا كانت خطوة المراجعة معروضة بلغة بسيطة. قد تُعتبر شاشة ملخص تسرد أسماء حقول قاعدة البيانات الخام أو تستخدم مصطلحات قانونية دون شرح شاشة مراجعة من الناحية التقنية، لكنها تفشل عمليًا بالنسبة للمستخدمين ذوي الإعاقات الإدراكية.

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

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

<!-- Problematic: clicking "Complete Purchase" immediately charges the card -->
<form action='/checkout/complete' method='post'>
  <input type='hidden' name='cart_id' value='abc123'>
  <input type='hidden' name='payment_token' value='tok_xyz'>
  <button type='submit'>Complete Purchase</button>
</form>

دفع بخطوة واحدة مع إضافة خطوة مراجعة — صحيح

<!-- Step 1: form collects data, submits to review page (not final) -->
<form action='/checkout/review' method='post'>
  <!-- payment and shipping fields -->
  <button type='submit'>Review Order</button>
</form>

<!-- Step 2: review page summarises all entered data and offers edit links -->
<section aria-labelledby='review-heading'>
  <h2 id='review-heading'>Review Your Order</h2>
  <dl>
    <dt>Delivery address</dt>
    <dd>Atatürk Cad. No:5, Kadıköy, Istanbul</dd>
    <dd><a href='/checkout/edit-address'>Edit delivery address</a></dd>
    <dt>Total</dt>
    <dd>₺1,249.00</dd>
  </dl>
  <form action='/checkout/complete' method='post'>
    <input type='hidden' name='order_token' value='tok_abc'>
    <!-- Final button is clearly labelled as the binding action -->
    <button type='submit'>Place Order and Pay ₺1,249.00</button>
  </form>
</section>

حذف بيانات لا يمكن التراجع عنه دون تأكيد — غير صحيح

<!-- Problematic: delete button directly posts with no confirmation dialog -->
<form action='/account/delete-profile' method='post'>
  <button type='submit'>Delete My Account</button>
</form>

حذف بيانات لا يمكن التراجع عنه مع مربع حوار تأكيد — صحيح

<!-- Trigger button opens a confirmation dialog, not the destructive action -->
<button type='button' aria-haspopup='dialog' aria-controls='confirm-delete-dialog'>
  Delete My Account
</button>

<dialog id='confirm-delete-dialog' aria-labelledby='dialog-title' aria-describedby='dialog-desc'>
  <h2 id='dialog-title'>Permanently Delete Account?</h2>
  <p id='dialog-desc'>
    This will permanently remove all your data. This action cannot be undone.
    Your subscription will be cancelled immediately.
  </p>
  <form action='/account/delete-profile' method='post'>
    <button type='submit'>Yes, permanently delete my account</button>
    <button type='button' onclick='this.closest("dialog").close()'>Cancel</button>
  </form>
</dialog>

نموذج مالي دون تحقق ضمني — غير صحيح

<!-- Problematic: no validation, wrong IBAN accepted silently -->
<form action='/transfer/submit' method='post'>
  <label for='iban'>Recipient IBAN</label>
  <input type='text' id='iban' name='iban'>
  <label for='amount'>Amount (TRY)</label>
  <input type='number' id='amount' name='amount'>
  <button type='submit'>Transfer</button>
</form>

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

<!-- Inline validation with aria-describedby for error association -->
<form action='/transfer/review' method='post' novalidate>
  <div>
    <label for='iban'>Recipient IBAN</label>
    <input
      type='text'
      id='iban'
      name='iban'
      aria-describedby='iban-hint iban-error'
      aria-required='true'
      autocomplete='off'
      pattern='[A-Z]{2}[0-9]{2}[A-Z0-9]{1,30}'
    >
    <p id='iban-hint'>Enter a valid TR IBAN starting with TR followed by 24 digits.</p>
    <p id='iban-error' role='alert' aria-live='assertive' hidden>
      Invalid IBAN format. Please check the number and try again.
    </p>
  </div>
  <!-- Submits to review page, not direct execution -->
  <button type='submit'>Review Transfer</button>
</form>

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

• استخدام تلميح (tooltip) كآلية "مراجعة": عرض القيم المدخلة في تلميح يظهر عند التحويم قبل زر الإرسال لا يُعد خطوة مراجعة، لأن التلميحات ليست متاحة للمستخدمين الذين يعتمدون على لوحة المفاتيح فقط أو قارئات الشاشة وتختفي قبل أن يتمكن المستخدم من التصرف بناءً عليها.
• وضع تسمية "متابعة" على الزر النهائي بدلًا من وصف الإجراء: لا يوضح زر يحمل نص "متابعة" في صفحة المراجعة أن النقر عليه سيُتم معاملة مالية. يجب أن يصف الزر بوضوح الإجراء الملزم، مثل "إتمام الطلب والدفع ₺850" أو "توقيع العقد".
• توفير سياسة الإلغاء فقط في شروط الخدمة: إخفاء آلية التراجع في مستند قانوني مرتبط لا يقرأه معظم المستخدمين لا يفي بمتطلب قابلية التراجع. يجب توضيح إمكانية الإلغاء والإطار الزمني المتاح لذلك ضمن تدفق المعاملة نفسه.
• استخدام window.confirm() كآلية التأكيد الوحيدة: مربعات حوار التأكيد الأصلية في المتصفح مدعومة بشكل ضعيف من بعض تقنيات المساعدة، ولا يمكن تنسيقها لتحسين القراءة، ويتم حظرها في بعض إعدادات المتصفح. لا ينبغي استخدامها كوسيلة الحماية الوحيدة لعمليات الإرسال عالية المخاطر.
• إعادة تعيين النموذج عند فشل التحقق دون الحفاظ على القيم الصحيحة: عندما يفشل النموذج في التحقق، فإن مسح جميع الحقول يجبر المستخدمين — خاصة ذوي الإعاقات الحركية — على إعادة إدخال كل البيانات. يجب مسح أو تمييز الحقل غير الصحيح فقط؛ ويجب الحفاظ على جميع الإدخالات الصحيحة.
• وضع رابط "تعديل" في صفحة المراجعة دون ربط برمجي: يجب أن يكون لرابط "تعديل" بجوار كل مجموعة بيانات اسم متاح وصفي (مثل aria-label='Edit billing address'). تكرار "Edit" وحدها عدة مرات يكون غامضًا لمستخدمي قارئات الشاشة الذين يتنقلون عبر الروابط.
• عدم الإعلان عن خطوة المراجعة لقارئات الشاشة: إذا تم تحميل صفحة المراجعة دون نقل التركيز إلى العنوان أو منطقة الملخص، فقد لا يدرك مستخدمو قارئات الشاشة أنهم في صفحة مراجعة على الإطلاق وقد يفعّلون زر الإرسال دون قراءة الملخص.
• اعتبار المعيار منطبقًا على صفحات الدفع فقط: يشمل النطاق أي التزام قانوني (الاشتراك في خدمة، نماذج الموافقة، قبول العقود) وأي تعديل لبيانات المستخدم (حذف الملفات، تحديث السجلات الطبية، تغيير إعدادات الحساب). غالبًا ما يتجاهل المطورون اللوحات الإدارية وصفحات الإعدادات.
• تقديم إمكانية التراجع فقط عبر الهاتف أو البريد الإلكتروني: إذا كان الإلغاء يتطلب الاتصال بخط دعم، فقد لا يتمكن المستخدمون ذوو إعاقات النطق أو السمع من الوصول إلى آلية التراجع. يجب أن يكون مسار التراجع نفسه متاحًا — ويفضل أن يكون تدفق إلغاء داخل التطبيق.
• تجاهل المعيار في عروض الويب على الأجهزة المحمولة: تنفذ بعض الفرق خطوة مراجعة على سطح المكتب لكنها تستخدم تدفقًا مكثفًا من خطوة واحدة على الهاتف المحمول لتقليل مساحة الشاشة. ينطبق المعيار بالتساوي على جميع أحجام العروض ولا يجوز إهماله في تطبيقات الويب المتجاوبة أو على الأجهزة المحمولة.

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

تُرسّخ التعميم الرئاسي 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 June 2025، إطارًا وطنيًا شاملًا لإمكانية الوصول يشير إلى WCAG 2.2 كمعيار تقني. يفرض التعميم أن تلبي الخدمات الرقمية مستوى توافق لا يقل عن WCAG 2.2 المستوى AA، والذي يشمل WCAG 3.3.4 منع الأخطاء (قانونية، مالية، بيانات).

تشمل الكيانات التي يغطيها التعميم صراحةً مجموعة واسعة من القطاعات. يُطلب من المؤسسات والهيئات العامة جعل جميع الخدمات الرقمية الموجهة للمواطنين متاحة، بما في ذلك الطلبات عبر الإنترنت، وبوابات الحكومة الإلكترونية، وخدمات الهوية الرقمية — وكلها غالبًا ما تتضمن التزامات قانونية وتعديل بيانات. يجب على البنوك والمؤسسات المالية الخاضعة لتنظيم BDDK (هيئة التنظيم والرقابة المصرفية) الامتثال، مما يجعل 3.3.4 ذا صلة مباشرة بكل معاملة مصرفية عبر الإنترنت، وتحويل أموال، وطلب قرض تقدمه. يجب على المستشفيات والمؤسسات الصحية التي تشغّل بوابات المرضى الرقمية، وأنظمة حجز المواعيد، والسجلات الصحية الإلكترونية ضمان أن أي إدخال أو تعديل بيانات في تلك الأنظمة يفي بمعايير منع الأخطاء. يجب على مزودي خدمات الاتصالات الذين لديهم 200,000 مشترك أو أكثر — بما في ذلك Turkcell وVodafone TR وTürk Telekom — التأكد من تغطية إدارة الاشتراكات، وتغيير الخطط، وتدفقات الدفع. كما تقع منصات التجارة الإلكترونية، ووكالات السفر، وشركات النقل الخاصة، والمدارس الخاصة المرخصة من وزارة التربية الوطنية (MoNE) ضمن النطاق، مما يغطي جزءًا كبيرًا من خدمات الويب المعاملاتية عالية الحجم في السوق التركية.

لا يُعد الامتثال لـ 3.3.4 مجرد خانة فنية ضمن هذا الإطار. يجب على المؤسسات التي تسعى للحصول على Erişilebilirlik Logosu (شعار إمكانية الوصول) الصادر عن وزارة الأسرة والخدمات الاجتماعية إثبات توافق كامل مع WCAG 2.2 AA. يعمل الشعار كإشارة ثقة عامة ويُتوقع بشكل متزايد من قبل المستهلكين والجهات المتعاقدة. يمكن أن يؤدي عدم تنفيذ وسائل منع الأخطاء في التدفقات المالية أو القانونية إلى رفض منح الشعار وإلى اتخاذ إجراءات إدارية محتملة بموجب أحكام إنفاذ التعميم.

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