WCAG 3.3.7: إدخال متكرر

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

المعيار WCAG 3.3.7 Redundant Entry هو معيار نجاح من المستوى A تم تقديمه في WCAG 2.2. وينص على ما يلي: "المعلومات التي سبق أن أدخلها المستخدم أو قُدمت له والتي يُطلب إدخالها مرة أخرى في نفس العملية، يجب إما أن تُملأ تلقائيًا أو أن تكون متاحة ليختارها المستخدم." بعبارة مبسطة، إذا كان المستخدم قد كتب بالفعل عنوان بريده الإلكتروني أو عنوان الشحن أو تاريخ الميلاد أو أي معلومة أخرى خلال الجلسة، فيجب ألا تجبره الواجهة على كتابتها مرة أخرى ضمن نفس العملية أو التدفق.

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

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

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

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

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

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

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

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

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

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

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

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

• يتطلب اختبارًا يدويًا (WCAG 2.2 جديد): تقوم axe-core وغيرها من ماسحات إمكانية الوصول الآلية بتحليل DOM لحالة صفحة واحدة في كل مرة. لا يمكنها تتبع القيم التي أدخلها المستخدم عبر تحميلات صفحات متعددة أو خطوات نموذج متعددة، ولا يمكنها مقارنة تسميات الحقول عبر الخطوات لتحديد التكرار الدلالي، ولا يمكنها تقييم ما إذا كانت آلية التعبئة المسبقة تعمل بشكل صحيح. يجب على المختبرين المرور يدويًا عبر العمليات متعددة الخطوات، وتسجيل البيانات التي يدخلونها في كل خطوة، والتحقق في كل خطوة لاحقة مما إذا كانت البيانات المقدمة سابقًا إما تُملأ تلقائيًا أو يمكن اختيارها. أي أداة تدّعي اكتشاف انتهاكات 3.3.7 تلقائيًا ستنتج معدلًا مرتفعًا للغاية من النتائج السلبية الكاذبة ولا ينبغي الاعتماد عليها كطريقة الاختبار الوحيدة.

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

1. فحص آلي كنقطة بداية: شغّل axe DevTools أو Lighthouse أو أداة Accsible على كل خطوة فردية من العملية متعددة الخطوات. رغم أن هذه الأدوات لن تشير مباشرة إلى انتهاكات 3.3.7، فإنها ستظهر مشكلات ذات صلة مثل خصائص autocomplete المفقودة، وحقول النماذج غير المسمّاة، وإخفاقات معايير 3.3.x الأخرى التي غالبًا ما تتزامن معها. وثّق كل حقل نموذج تجده في كل خطوة.
2. رسم خريطة لمتطلبات البيانات عبر الخطوات: قبل الاختبار اليدوي، أنشئ جدولًا أو ملفًا بسيطًا يسرد كل خطوة في العملية وكل حقل بيانات تجمعه. ثم حدد أي تسمية حقل أو نوع بيانات يظهر في أكثر من خطوة واحدة. هذا التمرين في رسم الخريطة يكشف عن المرشحين المحتملين للانتهاكات قبل حتى أن تفتح المتصفح.
3. مرور يدوي — على سطح المكتب: باستخدام فأرة ولوحة مفاتيح قياسيتين، أكمل العملية متعددة الخطوات بالكامل (مثل الدفع، التسجيل، تقديم مطالبة). أدخل قيمًا واقعية في كل حقل. عندما تصل إلى خطوة تظهر في خريطتك كحقل مكرر، تحقق مما إذا كان الحقل مملوءًا مسبقًا بإدخالك السابق، أو ما إذا كان هناك خيار قابل للاختيار يعرض إدخالك السابق. إذا لم يكن أي من ذلك متوفرًا، فسجّل إخفاقًا. كرر هذا الاختبار باستخدام قارئ شاشة (NVDA مع Firefox، JAWS مع Chrome، VoiceOver مع Safari) للتأكد من الإعلان عن القيم المملوءة مسبقًا بشكل صحيح وأن عناصر التحكم لاختيار القيم المدخلة سابقًا يمكن الوصول إليها عبر لوحة المفاتيح.
4. مرور يدوي — على الأجهزة المحمولة: أكمل نفس التدفق على iOS (VoiceOver + Safari) وAndroid (TalkBack + Chrome). انتبه إلى ما إذا كانت ميزات الإكمال التلقائي أو التعبئة التلقائية الأصلية يتم تعطيلها من قبل التطبيق، مما قد يخلق حواجز إدخال متكرر عن غير قصد حتى لو كان المطور يقصد أن يساعد الإكمال التلقائي.
5. اختبار الاستثناءات: حدد أي حقول تطلب عمدًا إدخالًا مكررًا (مثل تأكيد كلمة المرور، إعادة إدخال البريد الإلكتروني). تحقق من أن هذه الحقول تستوفي شروط فحوصات الأمان أو التحقق الأساسية بموجب استثناء WCAG وليست مجرد حقول متكررة يجب إزالتها أو تعبئتها مسبقًا.
6. الاختبار مع تعطيل الإكمال التلقائي: بعض المستخدمين يعطلون الإكمال التلقائي في المتصفح لأسباب تتعلق بالخصوصية. اختبر ما إذا كانت آلية التعبئة المسبقة الخاصة بالتطبيق (على جانب الخادم أو المعتمدة على JavaScript) لا تزال تعمل بشكل صحيح عند إيقاف تشغيل الإكمال التلقائي في المتصفح، لضمان استيفاء المعيار بشكل مستقل عن سلوك المتصفح.

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

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

<!-- Step 1: Shipping Address -->
<form id='shipping-form'>
  <label for='ship-name'>Full Name</label>
  <input type='text' id='ship-name' name='shipping_name'>

  <label for='ship-street'>Street Address</label>
  <input type='text' id='ship-street' name='shipping_street'>

  <label for='ship-city'>City</label>
  <input type='text' id='ship-city' name='shipping_city'>
</form>

<!-- Step 2: Billing Address — user must type everything again -->
<form id='billing-form'>
  <label for='bill-name'>Full Name</label>
  <input type='text' id='bill-name' name='billing_name'>

  <label for='bill-street'>Street Address</label>
  <input type='text' id='bill-street' name='billing_street'>

  <label for='bill-city'>City</label>
  <input type='text' id='bill-city' name='billing_city'>
</form>

عملية دفع متعددة الخطوات — نفس العنوان مطلوب في شاشتين — صحيح

<!-- Step 2: Billing Address — pre-fill option provided -->
<form id='billing-form'>
  <!-- Checkbox allows user to confirm same address rather than re-type it -->
  <input type='checkbox' id='same-as-shipping' name='same_as_shipping'>
  <label for='same-as-shipping'>My billing address is the same as my shipping address</label>

  <div id='billing-fields'>
    <!-- Fields are pre-populated server-side with shipping values;
         JavaScript can also copy values when checkbox is unchecked -->
    <label for='bill-name'>Full Name</label>
    <input type='text' id='bill-name' name='billing_name' value='Jane Doe' autocomplete='billing name'>

    <label for='bill-street'>Street Address</label>
    <input type='text' id='bill-street' name='billing_street' value='123 Elm Street' autocomplete='billing street-address'>

    <label for='bill-city'>City</label>
    <input type='text' id='bill-city' name='billing_city' value='Ankara' autocomplete='billing address-level2'>
  </div>
</form>

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

<!-- Step 1 collected email. Step 3 asks again with no pre-fill. -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <input type='email' id='confirm-email' name='confirm_email'>
  <!-- No value pre-populated; user must type the same email entered on step 1 -->
</fieldset>

معالج تسجيل — البريد الإلكتروني مملوء مسبقًا من بيانات الجلسة — صحيح

<!-- Server renders the previously collected email into the value attribute -->
<fieldset>
  <legend>Confirm Your Details</legend>
  <label for='confirm-email'>Email Address</label>
  <!-- value is injected from server-side session; user can correct if needed -->
  <input type='email' id='confirm-email' name='confirm_email'
         value='[email protected]' autocomplete='email'>
</fieldset>

حجز موعد — تفاصيل المريض مطلوبة مرة أخرى في خطوة الملخص — غير صحيح

<!-- Summary step re-asks for date of birth already entered in patient info step -->
<label for='dob-confirm'>Date of Birth</label>
<input type='date' id='dob-confirm' name='dob_confirm'>
<!-- Empty field requires user to re-enter DOB from memory or paper -->

حجز موعد — عرض تاريخ الميلاد كحقل تأكيد للقراءة فقط — صحيح

<!-- Previously entered DOB displayed in a read-only field for review;
     a hidden input carries the value for form submission -->
<label for='dob-confirm'>Date of Birth (from your patient record)</label>
<input type='date' id='dob-confirm' name='dob_confirm'
       value='1985-04-12' readonly aria-describedby='dob-hint'>
<span id='dob-hint'>This value was entered earlier. Contact support if it is incorrect.</span>

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

• بناء نماذج متعددة الخطوات كصفحات مستقلة دون حالة جلسة مشتركة، بحيث لا توجد آلية لنقل القيم المدخلة في الخطوات السابقة — وهو الخطأ المعماري الأكثر جوهرية الذي يؤدي إلى إخفاقات 3.3.7.
• توفير خانة اختيار "نفس عنوان الشحن" دون تعبئة حقول الفوترة فعليًا عند تحديدها، مما يجبر المستخدمين على كتابة تفاصيل العنوان يدويًا حتى بعد الإشارة إلى أنه يجب أن يتطابق.
• تعبئة الحقول مسبقًا عند تحميل الصفحة ثم مسحها عند حدوث خطأ في التحقق، بحيث يضطر المستخدم الذي يرتكب خطأ في خطوة لاحقة إلى إعادة إدخال كل البيانات التي قدمها سابقًا عند عودته لتصحيحها.
• تخزين بيانات الجلسة بشكل غير آمن واختيار تعطيلها بدلًا من إصلاح مشكلة الأمان، مما يؤدي إلى تجربة تعبئة مسبقة معطلة تشكل من الناحية التقنية إخفاقًا في 3.3.7.
• استخدام استثناء تأكيد كلمة المرور كمبرر لإجبار المستخدمين على إعادة إدخال عناوين البريد الإلكتروني، في حين أن تأكيد البريد الإلكتروني ليس فحصًا أمنيًا أساسيًا ولا يندرج تحت استثناء WCAG.
• عدم تمرير القيم المنقولة عبر حقول مخفية في النماذج المولدة على جانب الخادم، مما يؤدي إلى فقدان القيم المملوءة مسبقًا عندما ينتقل المستخدم ذهابًا وإيابًا عبر الخطوات باستخدام أزرار سجل المتصفح.
• الاعتماد فقط على التعبئة التلقائية في المتصفح للوفاء بهذا المعيار، دون تنفيذ تعبئة مسبقة على مستوى التطبيق — مما يترك المستخدمين الذين يعطلون التعبئة التلقائية لأسباب تتعلق بالخصوصية دون مسار متوافق عبر العملية.
• تعبئة حقل مسبقًا ولكن تعيينه كـ disabled بدلًا من readonly، مما يؤدي إلى استبعاد القيمة من إرسال النموذج في معظم المتصفحات، وكسر العملية وربما إجبار المستخدم على إعادة الإدخال.
• عدم اختبار التدفق الكامل من البداية إلى النهاية مع مستخدمين يستعملون برامج إدخال صوتي مثل Dragon NaturallySpeaking، حيث قد تتطلب الحقول المتكررة تكرار نفس أمر الإملاء الصوتي عدة مرات، وهو عبء كبير يسهل تجاهله في اختبارات المطورين.
• التعامل مع هذا المعيار على أنه ينطبق فقط على حقول العناوين، في حين أنه ينطبق بنفس القدر على أي بيانات مكررة بما في ذلك الأسماء، وأرقام الهواتف، وأرقام الهوية الوطنية، وأرقام الوثائق، والتواريخ، وأي معلومات أخرى يقدمها المستخدم وتُطلب أكثر من مرة في نفس العملية.

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

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

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

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

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