WCAG 1.3.5: تحديد غرض حقل الإدخال

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

المعيار WCAG 1.3.5 — Identify Input Purpose هو معيار من مستوى AA تم تقديمه في WCAG 2.1 واستمر في WCAG 2.2. يقتضي هذا المعيار أن يكون لأي عنصر <input> أو <select> أو <textarea> يجمع معلومات عن المستخدم غرضٌ يتم توصيله برمجياً، بحيث تتمكن المتصفحات وتقنيات المساعدة من تحديد هذا الغرض والتصرف بناءً عليه تلقائياً.

الآلية المستخدمة للوفاء بهذا المعيار هي خاصية autocomplete مع استخدام قيمة الرمز token الصحيحة من القائمة الرسمية المحددة في مواصفة HTML. عندما يجمع الحقل اسم المستخدم أو عنوان بريده الإلكتروني أو رقم هاتفه أو عنوانه البريدي أو رقم بطاقته الائتمانية أو بيانات شخصية مشابهة، يجب أن تحمل خاصية autocomplete قيمة تصف بدقة غرض هذا الحقل — على سبيل المثال، autocomplete="given-name" لحقل الاسم الأول، أو autocomplete="email" لحقل البريد الإلكتروني.

ينطبق هذا المعيار تحديداً على الحقول التي تجمع معلومات عن المستخدم نفسه. ولا ينطبق على الحقول التي يُدخل فيها المستخدم بيانات عن شخص آخر (على سبيل المثال، نموذج حجز سفر يطلب اسم الراكب عندما يقوم المستخدم بالحجز نيابة عن شخص آخر)، كما لا ينطبق على الحقول التي قد يخلق فيها الإكمال التلقائي مخاطرة أمنية — مثل كلمات المرور ذات الاستخدام الواحد أو اختبارات CAPTCHA، والتي يمكنها بشكل مشروع استخدام autocomplete="off" أو autocomplete="one-time-code".

يتطلب النجاح أن: (1) يحمل كل حقل إدخال داخل النطاق خاصية autocomplete؛ و(2) تكون قيمة هذه الخاصية رمزاً صالحاً ومعترفاً به من مواصفة الإكمال التلقائي في HTML — لا سلسلة عشوائية، ولا قيمة فارغة عندما تكون قيمة ذات معنى مطلوبة، ولا رمزاً مكتوباً بشكل خاطئ. يحدث الفشل عندما لا يحتوي حقل إدخال داخل النطاق على خاصية autocomplete، أو عندما تكون قيمتها autocomplete="off" دون مبرر، أو عندما تحتوي على رمز غير صالح مثل autocomplete="firstname" (الرمز الصحيح هو given-name) أو autocomplete="phone" (الرمز الصحيح هو tel).

تُحافِظ WHATWG HTML Living Standard على القائمة الكاملة للرموز الصالحة لـ autocomplete، وتشمل قيماً للأسماء (given-name, family-name, additional-name)، والعناوين (street-address, address-line1, postal-code, country-name)، ومعلومات الاتصال (email, tel, tel-national)، وبيانات الاعتماد (username, current-password, new-password)، وتفاصيل الدفع (cc-name, cc-number, cc-exp, cc-csc)، وغيرها. يمكن أيضاً أن تُسبق الرموز بمعرّفات أقسام (مثل section-billing) وبكلمات الشحن أو الفوترة للتعامل مع مجموعات عناوين متعددة في صفحة واحدة.

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

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

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

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

فكّر في سيناريو واقعي: مستخدم مصاب بالشلل الدماغي يقوم بإكمال طلب للحصول على مزايا حكومية. يحتوي النموذج على اثني عشر حقلاً تغطي الاسم والعنوان والرقم الوطني وتفاصيل الاتصال. من دون قيم autocomplete الصحيحة، يجب كتابة كل حقل يدوياً. رمز واحد مكتوب بشكل خاطئ — مثل autocomplete="surname" بدلاً من autocomplete="family-name" — يكفي لمنع المتصفح من التعرف على الحقل، مما يترك المستخدم ليكتب اسم عائلته حرفاً بحرف. باستخدام الرموز الصحيحة، يمكن ملء النموذج بالكامل تلقائياً في ثوانٍ، مما يقلل الجهد ومعدلات الخطأ معاً.

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

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

• autocomplete-valid — هذه هي قاعدة axe-core الأساسية الخاصة بـ WCAG 1.3.5. تقوم هذه القاعدة بفحص كل عنصر <input> و<select> و<textarea> يحتوي على خاصية autocomplete، وتتحقق مما إذا كانت قيمة الخاصية رمزاً صالحاً ومعترفاً به من مواصفة الإكمال التلقائي في HTML. تُعلِم القاعدة عن العناصر التي يكون فيها الرمز مكتوباً بشكل خاطئ (مثل given name مع مسافة بدلاً من شرطة)، أو حيث تم استخدام قيمة ملكية غير قياسية (مثل autocomplete="first-name")، أو حيث يكون ترتيب الرموز في قيمة متعددة الرموز غير صحيح (مثل وضع اسم الحقل قبل بادئة القسم المطلوبة). لا تقوم القاعدة بالتنبيه على الحقول التي تفتقر تماماً إلى خاصية autocomplete — فهذه الحالة تتطلب مراجعة يدوية — لأن axe-core لا يمكنه تحديد ما إذا كان حقل معين ضمن نطاق المعيار برمجياً (أي ما إذا كان يجمع معلومات عن المستخدم).
• لماذا يلزم أيضاً إجراء اختبار يدوي — لا يمكن للأدوات الآلية مثل axe-core سوى التحقق من أن قيمة autocomplete الموجودة صحيحة من الناحية التركيبية؛ ولا يمكنها تحديد ما إذا كان الرمز المختار يصف غرض الحقل بدقة. على سبيل المثال، حقل هاتف الفوترة مع autocomplete="email" سيمر في القاعدة الآلية (لأن email رمز صالح) لكنه سيفشل في المعيار لأن الرمز لا يتطابق مع الغرض الفعلي للحقل. وبالمثل، لا يمكن للأدوات الآلية تحديد الحقول التي تفتقر إلى خاصية autocomplete لكنها يجب أن تحتوي عليها، لأن تحديد ما إذا كان الحقل يجمع معلومات شخصية عن المستخدم يتطلب حكماً بشرياً يعتمد على السياق. لذلك، تُعد المراجعة اليدوية لكل حقل نموذج يجمع بيانات خاصة بالمستخدم ضرورية للامتثال الكامل للمعيار 1.3.5.

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

1. تشغيل فحص آلي باستخدام axe DevTools أو Lighthouse. افتح الصفحة التي تحتوي على النموذج في Chrome أو Firefox. في axe DevTools، انقر على "Analyze" وفلتر النتائج حسب معرّف القاعدة autocomplete-valid. في Lighthouse، شغّل تدقيق الإتاحة وابحث عن الانتهاكات التي تشير إلى autocomplete. دوّن كل عنصر تم الإبلاغ عنه وسجّل قيم الرموز غير الصالحة المذكورة. عالج كل عنصر مُعلَم وأعد الفحص للتأكد من إصلاحه.
2. تحديد جميع حقول الإدخال داخل النطاق يدوياً. راجع النموذج وسجّل كل حقل يجمع معلومات عن المستخدم الحالي — حقول الاسم، وحقول العنوان، والبريد الإلكتروني، والهاتف، وتفاصيل الدفع، وبيانات الاعتماد. لكل حقل، تحقق من وجود خاصية autocomplete وأن رمزها يتطابق مع الغرض الفعلي للحقل وفقاً لقائمة رموز الإكمال التلقائي في HTML. الحقول التي تجمع معلومات عن أشخاص آخرين خارج النطاق ويمكن استثناؤها.
3. اختبار سلوك الإكمال التلقائي في المتصفح. في Chrome أو Firefox، تأكد من أن المتصفح يحتوي على ملف تعريف محفوظ (Settings > Autofill). انتقل إلى صفحة النموذج وانقر في أول حقل لمعلومات شخصية. تحقق من أن المتصفح يعرض اقتراح إكمال تلقائي وأن اختيار هذا الاقتراح يملأ الحقول الصحيحة بالقيم الصحيحة. كرر ذلك لحقول العنوان وحقول الدفع وحقول بيانات الاعتماد. إذا فشل الإكمال التلقائي في اقتراح قيم أو ملأ الحقول الخاطئة، فمن المرجح أن رموز autocomplete غير صحيحة.
4. الاختبار باستخدام قارئ شاشة مع متصفح. باستخدام NVDA وFirefox، انتقل إلى كل حقل نموذج باستخدام مفتاح Tab. يجب أن يعلن NVDA عن تسمية الحقل وغرضه؛ بعض تركيبات قارئ الشاشة والمتصفح ستعلن أيضاً عن غرض الإكمال التلقائي. باستخدام VoiceOver على macOS (Safari)، انتقل بين الحقول باستخدام Tab واستمع إلى VoiceOver وهو يعلن عن توفر الإكمال التلقائي. مع JAWS وChrome، انتقل بالمثل بين الحقول باستخدام Tab وتأكد من أن JAWS يعلن عن سياق الحقل المتوقع. على الرغم من أن قرّاء الشاشة لا يعلنون دائماً صراحة عن رموز autocomplete، فإن التأكد من أن الإكمال التلقائي يعمل بشكل صحيح مع التنقل عبر لوحة المفاتيح يؤكد أن الغرض البرمجي مكشوف.
5. فحص خصائص autocomplete في أدوات تطوير المتصفح. انقر بزر الماوس الأيمن على كل حقل نموذج واختر "Inspect". في لوحة Elements، تأكد من وجود خاصية autocomplete وأن قيمتها تطابق تماماً رمزاً صالحاً. أولِ اهتماماً خاصاً للقيم متعددة الرموز — على سبيل المثال، autocomplete="shipping street-address" — وتأكد من أن ترتيب الرموز يتبع المواصفة (اسم القسم، ثم "shipping" أو "billing"، ثم اسم الحقل).

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

حقول الاسم — غير صحيح

<!-- Invalid: uses non-standard token 'firstname' instead of 'given-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='firstname'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='surname'>

حقول الاسم — صحيح

<!-- Valid: uses the exact WHATWG-specified tokens 'given-name' and 'family-name' -->
<label for='fname'>First Name</label>
<input type='text' id='fname' name='first_name' autocomplete='given-name'>

<label for='lname'>Last Name</label>
<input type='text' id='lname' name='last_name' autocomplete='family-name'>

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

<!-- Invalid: missing autocomplete attributes entirely on address fields -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' placeholder='Street Address'>
  <input type='text' name='bill_city' placeholder='City'>
  <input type='text' name='bill_postal' placeholder='Postal Code'>
</fieldset>

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

<!-- Valid: autocomplete tokens include 'billing' prefix and correct field names -->
<fieldset>
  <legend>Billing Address</legend>
  <input type='text' name='bill_street' autocomplete='billing street-address' placeholder='Street Address'>
  <input type='text' name='bill_city' autocomplete='billing address-level2' placeholder='City'>
  <input type='text' name='bill_postal' autocomplete='billing postal-code' placeholder='Postal Code'>
</fieldset>

حقل الهاتف — غير صحيح

<!-- Invalid: uses 'phone' which is not a recognized autocomplete token -->
<label for='tel'>Phone Number</label>
<input type='text' id='tel' name='telephone' autocomplete='phone'>

حقل الهاتف — صحيح

<!-- Valid: 'tel' is the correct autocomplete token for a full phone number -->
<label for='tel'>Phone Number</label>
<input type='tel' id='tel' name='telephone' autocomplete='tel'>

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

<!-- Invalid: autocomplete='off' prevents password managers and autofill from working -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='off'>

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

بيانات اعتماد تسجيل الدخول — صحيح

<!-- Valid: 'username' and 'current-password' allow password managers to function correctly -->
<label for='user'>Username</label>
<input type='text' id='user' name='username' autocomplete='username'>

<label for='pass'>Password</label>
<input type='password' id='pass' name='password' autocomplete='current-password'>

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

• استخدام autocomplete="firstname" أو autocomplete="first-name" بدلاً من الرمز الصحيح given-name". هذه القيم غير القياسية لا يتعرف عليها المتصفح أو تقنيات المساعدة حتى وإن بدت منطقية. استخدم دائماً الرموز الدقيقة من مواصفة الإكمال التلقائي في HTML.
• استخدام autocomplete="phone" بدلاً من autocomplete="tel". كلمة "phone" ليست رمزاً صالحاً. تستخدم المواصفة tel لرقم الهاتف الكامل، وtel-national وtel-area-code وtel-local لأجزاء فرعية من رقم الهاتف.
• تعيين autocomplete="off" على حقول بيانات الاعتماد كإجراء أمني خاطئ. تعترف المتصفحات الحديثة ومواصفة WCAG معاً بأن منع الإكمال التلقائي في نماذج تسجيل الدخول يخلق حواجز حقيقية للمستخدمين ذوي الإعاقات ولا يحسن الأمان بشكل ملموس. استخدم autocomplete="username" وautocomplete="current-password" بدلاً من ذلك.
• إهمال خاصية autocomplete تماماً في حقول البيانات الشخصية، بافتراض أن المتصفح سيستنتج الغرض من اسم الحقل أو تسميته. تستخدم المتصفحات خوارزميات لتخمين غرض الحقل، لكنها غير موثوقة وغير متسقة بين المتصفحات. الرموز الصريحة مطلوبة لتجربة مضمونة وميسّرة.
• استخدام autocomplete="address" بدلاً من الرموز الفرعية المحددة للعناوين. لا يوجد رمز address في المواصفة. يجب استخدام street-address وaddress-line1 وaddress-line2 وaddress-level1 (الولاية/المقاطعة) وaddress-level2 (المدينة) وpostal-code كلٌ على حدة.
• وضع كلمات الشحن أو الفوترة في ترتيب خاطئ ضمن القيم متعددة الرموز. الترتيب الصحيح هو: بادئة قسم اختيارية (مثل section-billing)، ثم كلمة الشحن/الفوترة الاختيارية، ثم رمز اسم الحقل. كتابة autocomplete="street-address billing" غير صالح؛ الشكل الصحيح هو autocomplete="billing street-address".
• تطبيق autocomplete على الحقول المرئية فقط وتجاهل الحقول المخفية أو التي تظهر ديناميكياً. يجب أن تحمل الحقول التي تكون مخفية في البداية ثم تظهر من خلال تفاعل المستخدم (مثل أسطر العنوان الإضافية أو الحقول الاختيارية) رموز autocomplete الصحيحة أيضاً عندما تصبح نشطة.
• استخدام JavaScript لإزالة خاصية autocomplete أو استبدالها ديناميكياً بعد تحميل الصفحة. تقوم بعض مكتبات النماذج أو أطر واجهات المستخدم بإعادة تعيين خصائص الإدخال عند تركيب المكونات أو إعادة عرضها، مما يؤدي عن غير قصد إلى إزالة رموز autocomplete. تحقق دائماً من أن الخاصية تبقى موجودة في DOM الحي بعد تنفيذ كل JavaScript.
• الافتراض بأن type="email" أو type="tel" في حقل الإدخال كافٍ لتوصيل الغرض من دون autocomplete. على الرغم من أن خاصية type توفر بعض المعلومات، فإن خاصية autocomplete إشارة صريحة منفصلة مطلوبة بموجب WCAG 1.3.5 وتُستخدم بطريقة مختلفة من قِبل المتصفحات وتقنيات المساعدة.
• استخدام رمز autocomplete نفسه على حقلين مختلفين يجمعان بيانات مختلفة. على سبيل المثال، وضع autocomplete="email" على كل من حقل البريد الإلكتروني للعمل وحقل البريد الإلكتروني الشخصي يربك المتصفحات وقد يؤدي إلى إكمال تلقائي غير صحيح. استخدم بادئات الأقسام (مثل section-work email مقابل section-personal email) لتمييز الحقول.

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

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

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

بالنسبة للمعيار WCAG 1.3.5 تحديداً، يعني هذا أن أي نموذج دفع في التجارة الإلكترونية التركية، أو نموذج فتح حساب بنكي، أو نموذج تسجيل مريض في مستشفى، أو نموذج اشتراك في خدمات الاتصالات يجمع معلومات عن المستخدم مثل الاسم أو العنوان أو رقم الهاتف أو تفاصيل الدفع يجب أن يتضمن قيم خصائص autocomplete صالحة على كل حقل إدخال ذي صلة. إن عدم القيام بذلك يشكل حالة عدم امتثال لمستوى AA ويمكن أن يمنع المنظمة من الحصول على شعار الإتاحة (Erişilebilirlik Logosu) أو الاحتفاظ به، وهو العلامة الرسمية التي تصدرها وزارة الأسرة والخدمات الاجتماعية والتي تشهد بأن الخدمات الرقمية للمنظمة تلبي معايير الإتاحة.

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

يجب على المنظمات تدقيق جميع النماذج عبر ممتلكاتها الرقمية — بما في ذلك واجهات الويب على الأجهزة المحمولة والتصاميم المتجاوبة — ووضع سياسة تطوير تشترط استخدام رموز autocomplete الصحيحة كجزء قياسي من أي تنفيذ لنموذج. يجب فرض ذلك من خلال الاختبارات الآلية في خطوط CI/CD باستخدام أدوات مثل axe-core، بحيث يتم اكتشاف التراجعات قبل وصولها إلى بيئة الإنتاج.