WCAG 3.3.9: المصادقة المتاحة (محسّنة)

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

تُعد WCAG 3.3.9 — المصادقة المتاحة (المعززة) النظير على مستوى AAA للمعيار WCAG 3.3.8 (المصادقة المتاحة — الحد الأدنى، مستوى AA). معًا، يشكلان زوجًا من المعايير التي تم تقديمها في WCAG 2.2 بهدف ضمان ألا تصبح عملية إثبات الهوية لموقع ويب أو تطبيق عائقًا في حد ذاتها أمام إمكانية الوصول.

على مستوى AAA، تشدد 3.3.9 المتطلبات بشكل كبير. ينص المعيار على ما يلي: لا يجوز اشتراط اختبار وظيفة معرفية لأي خطوة في عملية المصادقة ما لم توفر تلك الخطوة واحدًا على الأقل مما يلي: طريقة مصادقة بديلة لا تعتمد على اختبار وظيفة معرفية؛ أو توفر آلية لمساعدة المستخدم في إكمال اختبار الوظيفة المعرفية؛ أو أن يكون اختبار الوظيفة المعرفية قائمًا على التعرف على الأشياء. وبشكل حاسم، وعلى عكس نسخة مستوى AA (3.3.8)، فإن معيار مستوى AAA يلغي الاستثناء الذي كان يسمح بالتعرف على محتوى غير قائم على الأشياء (مثل صور عناصر غير مادية اختارها المستخدم سابقًا). في هذا المستوى، يُسمح فقط بالتعرف الحقيقي على الأشياء — أي التعرف على أشياء شائعة من العالم الحقيقي مثل صور قطة أو دراجة أو منزل — كاختبار وظيفة معرفية، وفقط إذا لم تتحقق الشروط الأخرى.

يُعرَّف اختبار الوظيفة المعرفية بأنه أي مهمة تتطلب من المستخدم تذكر معلومات أو معالجتها أو نسخها. يشمل ذلك: تذكر اسم مستخدم أو كلمة مرور، حل لغز رياضي، إكمال CAPTCHA يتطلب فك نص مشوه، الإجابة عن سؤال أمان يتعلق بالتاريخ الشخصي (مثل: "ما اسم أول حيوان أليف لك؟")، أو نسخ تسلسل من الأحرف. تمثل كل هذه المهام مهام ذاكرة أو نسخ لا يستطيع العديد من المستخدمين أداؤها بشكل موثوق.

ما الذي يُعد اجتيازًا: تجتاز خطوة المصادقة المعيار 3.3.9 إذا كانت لا تتطلب أي اختبار وظيفة معرفية، أو إذا استوفت أحد هذه الشروط: (1) تقديم مسار مصادقة منفصل تمامًا وغير معرفي (مثل رابط سحري يُرسل عبر البريد الإلكتروني، WebAuthn/passkey، تسجيل الدخول البيومتري)؛ (2) وجود آلية تساعد في إكمال الاختبار (مثل عدم حظر مدير كلمات المرور في المتصفح، أو السماح بالنسخ واللصق)؛ أو (3) أن يكون الاختبار المعرفي الوحيد المتضمن هو التعرف على شيء شائع من العالم الحقيقي من مجموعة من الصور.

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

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

لماذا يهم هذا الأمر

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

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

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

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

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

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

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

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

يُصنف المعيار WCAG 3.3.9 على أنه يتطلب اختبارًا يدويًا فقط. اعتبارًا من axe-core 4.10، لا توجد قاعدة آلية تقيم هذا المعيار بالكامل. يتطلب فهم سبب عجز الأدوات الآلية عن اكتشاف هذه الانتهاكات فهم ما يقيسه المعيار فعليًا.

• يتطلب اختبارًا يدويًا — اكتشاف اختبارات الوظيفة المعرفية: يمكن لأدوات الفحص الآلي اكتشاف وجود عناصر HTML معينة (مثل <input type='password'> أو iframe يضم أداة CAPTCHA من طرف ثالث)، لكنها لا تستطيع تحديد ما إذا كان تدفق المصادقة الكامل يتطلب اختبار وظيفة معرفية دون بديل متاح. يتعلق المعيار برحلة المستخدم بأكملها عبر خطوات وصفحات متعددة محتملة، وليس بخصائص أي عنصر منفرد. لا يمكن لأداة الفحص تقييم ما إذا كان اللصق محظورًا برمجيًا عبر JavaScript، أو ما إذا كانت المهلة الزمنية لحقل إدخال رمز معقولة، أو ما إذا كان مسار المصادقة البديل يتجنب بالفعل الاختبارات المعرفية. هذه أسئلة سلوكية ومعمارية تتطلب من مقيم بشري المرور فعليًا بعملية المصادقة.
• يتطلب اختبارًا يدويًا — التحقق من المسار البديل: حتى لو اكتشفت أداة الفحص أداة CAPTCHA، لا يمكنها التحقق مما إذا كانت هناك طريقة مصادقة بديلة متاحة على نفس الصفحة أو في نفس التدفق. لا يمكنها تقييم ما إذا كان خيار "استخدم مفتاح مرور بدلًا من ذلك" مكافئًا حقًا أو ما إذا كان مخفيًا في صفحة إعدادات ثانوية تتطلب هي نفسها اجتياز CAPTCHA غير متاحة أولًا. يتطلب تقييم تكافؤ المسارات البديلة حكمًا بشريًا حول مدى اكتمال هذه البدائل ووضوحها.
• يتطلب اختبارًا يدويًا — سلوك لصق الحافظة: يكون JavaScript الذي يعترض أحداث paste ويلغيها (event.preventDefault() في مستمع لصق) غير مرئي لتحليل HTML الساكن. ترى أداة الفحص عنصر <input> صالحًا؛ لكنها لا تستطيع معرفة أن اللصق فيه قد تم تعطيله. لا يكشف هذا الفشل إلا الاختبار اليدوي — أي محاولة لصق كلمة مرور أو رمز فعليًا.
• يتطلب اختبارًا يدويًا — توافق عناصر المصادقة مع تقنيات المساعدة: قد تُعرض مجموعات تطوير برمجيات المصادقة من طرف ثالث (أزرار تسجيل الدخول الاجتماعي، مزودو CAPTCHA، مطالبات القياسات الحيوية) داخل iframes أو Shadow DOM لا تستطيع أدوات الفحص الآلي اختراقها بالكامل. يعد الاختبار اليدوي باستخدام قارئات الشاشة مثل NVDA وJAWS وVoiceOver ضروريًا للتأكد من أن جميع العناصر التفاعلية داخل تدفق المصادقة قابلة للتشغيل ومفهومة.

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

1. تحديد جميع نقاط الدخول للمصادقة: قبل الاختبار، حدد كل موضع في التطبيق يتعين فيه على المستخدم المصادقة أو التحقق من الهوية. يشمل ذلك تسجيل الدخول الأولي، وإنشاء الحساب، وإعادة تعيين كلمة المرور، ومطالبات المصادقة الثنائية، وإعادة المصادقة بعد انتهاء الجلسة، وشاشات تأكيد الدفع، وحواجز التحقق من العمر. يجب تقييم كل من هذه التدفقات بشكل مستقل.
2. تشغيل فحص آلي أساسي: استخدم axe DevTools (امتداد المتصفح) أو Lighthouse في أدوات مطوري Chrome على كل صفحة مصادقة. رغم أن هذه الأدوات لن تشير مباشرة إلى انتهاكات 3.3.9، فإنها ستظهر مشكلات ذات صلة — مثل فقدان التسميات على حقول النماذج، أو محتوى iframe غير متاح، أو إدارة تركيز غير صحيحة — والتي تفاقم عوائق المصادقة. دوّن أي مشكلات تم الإبلاغ عنها كخلفية للتقييم اليدوي. في axe DevTools، انظر إلى علامة التبويب "Needs Review" للعناصر التي تتطلب حكمًا يدويًا.
3. مراجعة وجود اختبارات الوظيفة المعرفية: لكل خطوة مصادقة، اسأل: هل تتطلب هذه الخطوة من المستخدم (أ) تذكر شيء ما، أو (ب) نسخ شيء ما، أو (ج) حل لغز؟ إذا كانت الإجابة نعم، فتحقق من وجود واحد على الأقل مما يلي وبنفس الدرجة من الوضوح: مسار بديل غير معرفي؛ آلية (مثل السماح بلصق الحافظة أو حقل متوافق مع الإكمال التلقائي) تساعد في الإكمال؛ أو أن المهمة المعرفية الوحيدة هي التعرف على شيء شائع من العالم الحقيقي.
4. اختبار سلوك لصق الحافظة: في كل حقل لإدخال كلمة المرور والرموز، انسخ سلسلة نصية إلى الحافظة وحاول لصقها باستخدام Ctrl+V (في Windows/Linux) أو Cmd+V (في macOS). إذا تم حظر اللصق، فهذا فشل. اختبر أيضًا ما إذا كان الإكمال التلقائي لمدير كلمات المرور في المتصفح قد تم تعطيله (تحقق من وجود autocomplete='off' أو JavaScript الذي يمسح قيم الإكمال التلقائي عند التركيز).
5. الاختبار باستخدام NVDA + Firefox: تنقل عبر تدفق المصادقة بالكامل باستخدام لوحة المفاتيح فقط وقارئ الشاشة NVDA. تحقق من أن جميع حقول النماذج يُعلن عنها بتسميات ذات معنى، وأن جميع عناصر التحكم التفاعلية (الأزرار، الروابط، تحديات CAPTCHA) يمكن الوصول إليها وتشغيلها، وأن أي رسائل خطأ مرتبطة برمجيًا بالحقل ذي الصلة وتُعلن فورًا دون الحاجة إلى تنقل إضافي.
6. الاختبار باستخدام VoiceOver + Safari (macOS/iOS): كرر تدفق المصادقة بالكامل. على iOS، تحقق أيضًا من أن المصادقة البيومترية (Face ID / Touch ID) تُعرض كبديل حيث تُستخدم المصادقة الأصلية، وأن التدفق القائم على الويب قابل للتشغيل بالكامل باستخدام Switch Control إذا لم تكن القياسات الحيوية متاحة.
7. الاختبار باستخدام JAWS + Chrome: كرر التدفق، مع إيلاء اهتمام خاص لكيفية الإعلان عن عناصر الطرف الثالث (تسجيل الدخول عبر OAuth، iframes الخاصة بـ CAPTCHA). يتعامل JAWS مع أنماط ARIA معينة بشكل مختلف عن NVDA؛ يجب اختبار كليهما.
8. تقييم المسارات البديلة من حيث التكافؤ الحقيقي: إذا كانت هناك طريقة مصادقة بديلة (مثل "تسجيل الدخول باستخدام رابط سحري")، فأكمل التدفق بالكامل باستخدام هذه الطريقة فقط. تأكد من أنها تصل إلى نفس حالة المصادقة دون طلب أي اختبار معرفي. إذا كان المسار البديل نفسه يحتوي على CAPTCHA أو اختبار ذاكرة، فهو ليس بديلًا صالحًا بموجب 3.3.9.
9. توثيق النتائج بالأدلة: لكل فشل، التقط تسجيل شاشة أو لقطة شاشة مشروحة توضح بالضبط أي خطوة فشلت ولماذا. هذا التوثيق ضروري لتسليم أعمال المعالجة إلى فرق التطوير ولأغراض تتبع التدقيق.

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

CAPTCHA بدون بديل — غير صحيح

<!-- Fails 3.3.9: The only authentication path requires solving a visual CAPTCHA.
     No alternative is provided, and there is no object-recognition option. -->
<form method='post' action='/login'>
  <label for='username'>Username</label>
  <input type='text' id='username' name='username' autocomplete='username'>

  <label for='password'>Password</label>
  <input type='password' id='password' name='password' autocomplete='off'>

  <!-- Third-party CAPTCHA widget with no accessible alternative path -->
  <div class='g-recaptcha' data-sitekey='YOUR_SITE_KEY'></div>

  <button type='submit'>Log In</button>
</form>

استبدال CAPTCHA بمفتاح مرور ورابط سحري — صحيح

<!-- Passes 3.3.9: CAPTCHA removed entirely. Primary path uses a passkey
     (WebAuthn — no cognitive test). A magic link fallback is offered
     for devices without passkey support. Password entry allows paste
     and browser autofill. -->
<form method='post' action='/login'>
  <label for='email'>Email address</label>
  <input type='email' id='email' name='email' autocomplete='email'>

  <!-- Passkey login: no password to remember, no CAPTCHA -->
  <button type='button' id='passkey-btn'>Sign in with Passkey</button>

  <!-- Password fallback: paste and autofill explicitly enabled -->
  <label for='password'>Password (optional)</label>
  <input type='password' id='password' name='password'
         autocomplete='current-password'>
  <!-- NOTE: Do NOT add autocomplete='off' or paste-blocking JS here -->

  <button type='submit'>Log In</button>
</form>

<!-- Non-cognitive alternative: magic link -->
<p><a href='/send-magic-link'>Send me a sign-in link instead</a></p>

<script>
  // WebAuthn passkey authentication — no cognitive function test
  document.getElementById('passkey-btn').addEventListener('click', async () => {
    const credential = await navigator.credentials.get({ publicKey: publicKeyOptions });
    // submit credential to server
  });
</script>

حظر لصق الحافظة في حقل OTP — غير صحيح

<!-- Fails 3.3.9: The one-time code field blocks paste via JavaScript,
     forcing users to manually transcribe a time-limited code.
     This is a transcription cognitive function test with no bypass. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='off'>

<script>
  document.getElementById('otp').addEventListener('paste', function(e) {
    e.preventDefault(); // Blocks paste — FAILS 3.3.9
  });
</script>

حقل OTP مع تمكين اللصق وتلميح الإكمال التلقائي — صحيح

<!-- Passes 3.3.9: Paste is allowed. The autocomplete='one-time-code' attribute
     enables browsers and password managers to automatically fill the OTP,
     eliminating the transcription requirement entirely. -->
<label for='otp'>Enter the 6-digit code from your authenticator app</label>
<input type='text' id='otp' name='otp' maxlength='6'
       inputmode='numeric' autocomplete='one-time-code'>

<!-- No paste-blocking JavaScript. autocomplete='one-time-code' allows
     the OS (iOS, Android, desktop browsers) to suggest the OTP
     automatically from SMS or authenticator apps. -->

أسئلة الأمان القائمة على المعرفة — غير صحيح

<!-- Fails 3.3.9: Requiring answers to knowledge-based security questions
     is a memory-recall cognitive function test. No alternative is offered. -->
<form method='post' action='/verify-identity'>
  <p>To verify your identity, please answer your security question:</p>
  <label for='sq-answer'>What was the name of your childhood pet?</label>
  <input type='text' id='sq-answer' name='sq-answer' autocomplete='off'>
  <button type='submit'>Verify</button>
</form>

التحقق من الهوية ببدائل غير معرفية — صحيح

<!-- Passes 3.3.9: Security questions replaced with email magic link
     and government ID upload options — neither requires memory recall.
     If security questions are retained for some users, a clearly labeled
     alternative path is provided upfront. -->
<form method='post' action='/verify-identity'>
  <p>We need to verify your identity. Choose one of the following methods:</p>

  <fieldset>
    <legend>Verification method</legend>

    <label>
      <input type='radio' name='verify-method' value='magic-link' checked>
      Send a verification link to my registered email
    </label>

    <label>
      <input type='radio' name='verify-method' value='id-upload'>
      Upload a photo of a government-issued ID
    </label>
  </fieldset>

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

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

• إضافة autocomplete='off' إلى حقول كلمات المرور لمنع الإكمال التلقائي من المتصفح. هذا يعطل الآلية الأساسية التي تسمح للمستخدمين بتجنب حفظ كلمات المرور ويفشل مباشرة في 3.3.9. أزل autocomplete='off' واستخدم autocomplete='current-password' أو autocomplete='new-password' بدلًا من ذلك.
• إرفاق مستمع حدث JavaScript من نوع paste يستدعي event.preventDefault() على حقول إدخال المصادقة، اعتقادًا بأن هذا يحسن الأمان. في الواقع، هذا يحظر مديري كلمات المرور وتقنيات المساعدة ويشكل متطلبًا للنسخ بموجب 3.3.9.
• اعتبار البديل الصوتي لـ CAPTCHA كافياً لتجاوز CAPTCHAs المرئية. لا تزال CAPTCHAs الصوتية تشكل اختبار وظيفة معرفية (نسخ أحرف صوتية مشوهة) ولا تفي بالمعيار 3.3.9. يلزم وجود مسار بديل غير معرفي حقيقي.
• تقديم خيار مفتاح مرور أو تسجيل دخول اجتماعي ولكن وضعه خلف تحدي CAPTCHA أولًا. إذا كان على المستخدم اجتياز اختبار معرفي للوصول إلى البديل المتاح، فإن البديل ليس مكافئًا حقًا ويفشل التدفق في 3.3.9.
• استخدام ستة حقول <input> منفصلة ذات حرف واحد لإدخال OTP (نمط واجهة مستخدم شائع) دون دعم اللصق لملء الحقول. العديد من التطبيقات تلصق فقط في الحقل الأول وتتطلب إدخالًا يدويًا حرفًا بحرف للخمسة المتبقية، وهو عائق نسخ.
• الاعتماد على خيار "تذكرني" أو ملفات تعريف الارتباط للجلسات المستمرة كوسيلة التيسير الوحيدة للمستخدمين الذين لا يستطيعون المصادقة بشكل متكرر. رغم أن تقليل تكرار المصادقة يساعد، إلا أنه لا يصلح عملية مصادقة غير متاحة — إذ يجب على المستخدمين اجتياز الاختبار المعرفي مرة واحدة على الأقل، كما أن الجلسات تنتهي أو تُمسح.
• تنفيذ حقول OTP محدودة بزمن تُمسح عند انتهاء المهلة دون تحذير، مما يجبر المستخدمين على طلب رمز جديد ومحاولة النسخ مرة أخرى. هذا يزيد العبء المعرفي على المستخدمين ذوي السرعات الحركية أو المعرفية البطيئة.
• استخدام تحديات CAPTCHA القائمة على الصور التي تتطلب التعرف على محتوى غير قائم على الأشياء — مثل الأنماط المجردة أو الألوان أو تسلسلات من الصور الشخصية المختارة — والاعتقاد بأن هذا يفي بالمعيار 3.3.9. لا يسمح معيار AAA إلا بالتعرف على الأشياء (أشياء من العالم الحقيقي مثل السيارات والدراجات وإشارات المرور)؛ التعرف على الصور غير القائمة على الأشياء غير مستثنى في هذا المستوى.
• حظر الوصول إلى مدير بيانات اعتماد المتصفح عبر autocomplete='new-password' في حقول تسجيل الدخول (بدلًا من حقول التسجيل). تشير قيمة new-password إلى المتصفحات أن هذا حقل لإنشاء كلمة مرور جديدة، مما يمنع الإكمال التلقائي لبيانات الاعتماد المحفوظة أثناء تسجيل الدخول.
• الفشل في اختبار تدفقات المصادقة باستخدام تقنيات المساعدة الفعلية والاعتماد بدلًا من ذلك فقط على نتائج الفحص الآلي. نظرًا لأن 3.3.9 قابل للاختبار يدويًا فقط، فإن الفرق التي تتخطى اختبار قارئات الشاشة ولوحة المفاتيح اليدوي ستفوت بشكل منهجي حالات الفشل في هذا المعيار في كل دورة إصدار.

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

تضع التعميم الرئاسي رقم 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، التزامات شاملة لإمكانية الوصول على الويب والهواتف المحمولة لمجموعة واسعة من الكيانات العامة والخاصة العاملة في تركيا. يفرض التعميم الالتزام بـ WCAG 2.2، مما يجعله أول أداة قانونية تركية تشير صراحة إلى الإصدار 2.2 من المعيار.

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

لا يُعد المعيار WCAG 3.3.9، باعتباره معيارًا على مستوى AAA، التزامًا قانونيًا أدنى بموجب التعميم. يتوافق الحد الأدنى القانوني المطلوب مع الالتزام بمستويي A وAA من WCAG 2.2. ومع ذلك، فإن روح ونطاق التعميم يجعلان 3.3.9 ذا صلة كبيرة عمليًا لعدة أسباب.

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

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

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

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