التحقق من نماذج HTML وإتاحة رسائل الخطأ
تطوير المواقع

التحقق من نماذج HTML وإتاحة رسائل الخطأ

تعلم استخدام required وpattern وminlength مع رسائل خطأ مفهومة وتجربة نموذج يمكن الوصول إليها.

التحقق المدمج في المتصفح

توفر HTML خصائص تساعد في رفض بعض الإدخالات غير المطابقة قبل إرسال النموذج. مثال:

<form action="/signup" method="post">
  <label for="username">اسم المستخدم</label>
  <input id="username" name="username" required minlength="3" maxlength="24">
  <label for="email">البريد الإلكتروني</label>
  <input id="email" name="email" type="email" required autocomplete="email">
  <button type="submit">إنشاء الحساب</button>
</form>

المسار توضيحي ويحتاج إلى نقطة معالجة فعلية. لا تعتبر نجاح التحقق في المتصفح دليلًا على أن البيانات صحيحة أو آمنة.

رسائل خطأ مفيدة

اشرح المشكلة بلغة مباشرة، واذكر طريقة إصلاحها؛ مثل «أدخل بريدًا إلكترونيًا بصيغة صحيحة». لا تعتمد على اللون وحده، ولا تمسح البيانات التي أدخلها المستخدم عند حدوث خطأ.

ربط الإرشادات بالحقول

<label for="password">كلمة المرور</label>
<p id="password-help">استخدم 12 حرفًا على الأقل.</p>
<input id="password" name="password" type="password" minlength="12" aria-describedby="password-help" required>

تربط aria-describedby الحقل بإرشادات مساعدة. عند استخدام JavaScript لإظهار أخطاء مخصصة، اجعلها قابلة للإدراك لقارئات الشاشة، وانقل التركيز إلى ملخص الأخطاء عند الحاجة دون إرباك المستخدم.

تحقق على الخادم دائمًا

يمكن تجاوز قيود HTML بإرسال طلب مباشر أو تعطيل JavaScript. أعد التحقق من جميع البيانات على الخادم، وتعامل مع القيم غير المتوقعة بأمان، ولا تعرض رسائل تكشف تفاصيل داخلية.

مراجع موثوقة

تابع سلسلة HTML

تابع الدروس السابقة: ما هي HTML؟، بنية مستند HTML، العناوين والفقرات والروابط، القوائم والصور، وأساسيات النماذج.

عرض أخطاء يمكن فهمها وإصلاحها

التحقق الفعال لا يكتفي بمنع الإرسال؛ يجب أن يشرح للمستخدم ما الخطأ وكيف يصححه. استخدم تعليمات قريبة من الحقل، ولا تعتمد على اللون وحده لتمييز الخطأ، وحافظ على البيانات التي أدخلها المستخدم.

<label for="email">البريد الإلكتروني</label>
<input id="email" name="email" type="email" required aria-describedby="email-help">
<p id="email-help">مثال: name@example.com</p>

سيناريوهات اختبار مهمة

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

رسائل الخطأ يجب أن تساعد على التصحيح

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

<label for="password">كلمة المرور</label>
<input id="password" name="password" type="password"
       minlength="12" autocomplete="new-password"
       aria-describedby="password-help" required>
<p id="password-help">استخدم 12 محرفًا على الأقل.</p>

تجنب قواعد ترفض تنسيقات صحيحة بلا حاجة، خصوصًا للأسماء وأرقام الهاتف. استخدم التحقق الأصلي في HTML حيث يناسب، ثم تحقق من كل قيمة على الخادم؛ يمكن تجاوز قيود العميل.

اختبار تدفق الأخطاء

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

أنماط تحقق تجعل نماذج HTML أوضح للمستخدم

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

الخاصيةالاستخدامما ينبغي مراعاته
requiredحقل لا يمكن تركه فارغًاوضّح سبب الإلزام ولا تفرضه على بيانات غير ضرورية
minlengthحد أدنى لطول النصاشرح الحد المتوقع للمستخدم
patternصيغة محددة مثل رمز داخلياكتب مثالًا مفهومًا ولا تفرض تنسيقًا بلا حاجة
min/maxنطاق تاريخ أو قيمة رقميةتأكد من المنطقة الزمنية والوحدة عند الحاجة

اربط الخطأ بالحقل

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

التحقق من جانب الخادم ضرورة

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

سيناريوهات اختبار عملية

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

راجع دليل MDN للتحقق من النماذج وإرشادات WAI للإشعارات والأخطاء قبل إضافة تحقق مخصص.

تصميم رسائل الخطأ واستعادة النموذج بعد الفشل

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

احتفظ بالمدخلات الصحيحة

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

اجعل الرسائل قابلة للوصول

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

اختبر التحقق على العميل والخادم

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

راجع إرشادات WAI لرسائل النماذج ودليل التحقق المدمج في HTML.

تصميم رسائل أخطاء يمكن فهمها وإصلاحها

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

اربط التعليمات بالحقل

استخدم تسمية مرئية عبر label، واجعل التعليمات الإضافية متاحة عبر aria-describedby عند الحاجة. إذا أصبح الحقل غير صالح بعد التحقق، يمكن استخدام aria-invalid="true" مع نص الخطأ المرتبط به، لكن لا تضف هذه الحالة قبل وجود خطأ فعلي. تأكد من أن قارئ الشاشة يستطيع اكتشاف التغيير، خصوصًا إذا كانت الرسالة تظهر ديناميكيًا بعد إرسال النموذج.

اجعل إدارة التركيز متوقعة

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

وازن بين التحقق المبكر والخصوصية

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

راجع إرشادات WAI للإشعارات في النماذج ومرجع MDN حول ARIA. ثم اختبر النموذج باستخدام لوحة المفاتيح وقارئ شاشة، وليس عبر الفأرة وحدها.

حالات اختبار إضافية للنماذج القابلة للوصول

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

اختبر التحديثات الديناميكية

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

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

الخلاصة

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

الكاتب: عماد الدين لمراني