نماذج HTML للمبتدئين: input وlabel وbutton والتحقق الأساسي
تعلم إنشاء نموذج HTML واضح وسهل الوصول، مع label وinput وأنواع الحقول والأزرار وخصائص التحقق المدمجة وأفضل الممارسات.
ما هو نموذج HTML؟
تسمح النماذج للمستخدم بإدخال معلومات وإرسالها، مثل نموذج التواصل أو البحث أو التسجيل. توفر HTML عناصر لوصف الحقول، لكن إرسال البيانات ومعالجتها فعليًا يحتاج إلى وجهة مناسبة على الخادم أو إلى خدمة متخصصة؛ وجود زر إرسال وحده لا ينشئ نظامًا خلفيًا.
نموذج بسيط وواضح
<form action="/contact" method="post">
<div>
<label for="name">الاسم</label>
<input id="name" name="name" type="text" autocomplete="name" required>
</div>
<div>
<label for="email">البريد الإلكتروني</label>
<input id="email" name="email" type="email" autocomplete="email" required>
</div>
<div>
<label for="message">رسالتك</label>
<textarea id="message" name="message" rows="5" required></textarea>
</div>
<button type="submit">إرسال الرسالة</button>
</form>المسار /contact مثال توضيحي؛ استبدله بعنوان نقطة المعالجة الحقيقية في مشروعك. لا تضع بيانات سرية في حقول النموذج على أساس أن HTML ستحميها.
لماذا نربط label بالحقل؟
تربط قيمة for في label معرّف الحقل id. هذا يجعل اسم الحقل واضحًا لقارئات الشاشة، كما يسمح للمستخدم بالنقر على التسمية للتركيز على الحقل. لا تعتمد على placeholder بديلًا عن التسمية؛ قد يختفي النص أثناء الكتابة ولا يؤدي الدور نفسه.
اختيار نوع الحقل المناسب
type="text"للنص العام.type="email"للبريد الإلكتروني، مع تحقق مبدئي من صيغة الإدخال.type="tel"لأرقام الهاتف، مع مراعاة اختلاف تنسيقاتها.type="password"لكلمة المرور؛ لا يعني ذلك أن البيانات تُرسل بأمان دون HTTPS ومعالجة خادمية سليمة.textareaللنصوص متعددة الأسطر.
التحقق الأساسي من البيانات
يمكن لخصائص مثل required وminlength وmaxlength وmin وmax وpattern إضافة قواعد تحقق من جهة المتصفح. مثال:
<label for="username">اسم المستخدم</label>
<input
id="username"
name="username"
type="text"
minlength="3"
maxlength="24"
required
>هذا التحقق يحسن تجربة المستخدم لكنه ليس بديلًا عن التحقق على الخادم؛ يمكن تجاوز قيود المتصفح. لا تثق في البيانات القادمة من العميل دون فحصها مجددًا.
ممارسات الوصول والأمان
- أضف تسمية مرئية لكل حقل وبيّن الحقول المطلوبة بوضوح.
- تأكد من أن النموذج قابل للاستخدام بلوحة المفاتيح وأن مؤشر التركيز ظاهر.
- اعرض رسائل خطأ مفهومة وحدد الحقل الذي يحتاج إلى تصحيح.
- استخدم HTTPS عند نقل البيانات، ولا ترسل كلمات المرور أو المعلومات الحساسة إلى سجلات أو روابط URL.
- استخدم
method="post"عندما تكون البيانات مخصصة للإرسال في جسم الطلب؛ لا تجعل ذلك بديلًا عن تصميم أمني سليم.
أخطاء شائعة
- إضافة حقل بلا
name، مما قد يمنع تضمينه في بيانات الإرسال المعتادة. - استخدام placeholder دون label.
- الاعتقاد أن
requiredيمنع كل الإدخالات غير الصحيحة أو الخبيثة. - إغفال توضيح ما سيحدث بعد إرسال النموذج.
تمرين عملي
أنشئ نموذج تواصل يحتوي الاسم والبريد والرسالة. جرّب إرساله فارغًا، وأدخل بريدًا غير صحيح، ثم اختبر التنقل بين الحقول باستخدام لوحة المفاتيح. تذكر أن المسار في المثال يحتاج إلى خادم حتى تتم معالجة الرسالة.
مصادر موثوقة
تحسين النموذج قبل نشره
اربط كل حقل بتسمية واضحة، واستخدم name حتى يدخل الحقل ضمن بيانات الإرسال، وحدد autocomplete للبيانات الشائعة مثل الاسم والبريد. إذا احتجت إلى مجموعة اختيارات مترابطة، فاجمعها داخل fieldset مع legend يشرح الغرض منها.
<label for="email">البريد الإلكتروني</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<button type="submit">إرسال</button>اختبار عملي
- جرّب النموذج بلوحة المفاتيح فقط وتأكد من ظهور التركيز.
- اختبر الحقول الفارغة والقيم غير الصالحة ورسالة النجاح.
- تأكد من أن وجهة
actionموجودة وتعالج البيانات بأمان.
تحسين تجربة الإرسال والاستجابة
قبل ربط النموذج بالخادم، حدد بوضوح ما البيانات المطلوبة ولماذا. لا تطلب معلومات لا تحتاج إليها، واستخدم autocomplete لتسهيل ملء الحقول الشائعة. بعد الإرسال يجب أن يحصل المستخدم على نتيجة مفهومة: تأكيد النجاح أو رسالة توضح المشكلة والخطوة التالية. لا تضع رسالة نجاح ثابتة في HTML إذا لم يتم إرسال البيانات فعلًا.
<label for="topic">موضوع الرسالة</label>
<select id="topic" name="topic" required>
<option value="">اختر موضوعًا</option>
<option value="support">الدعم الفني</option>
<option value="feedback">اقتراح أو ملاحظة</option>
</select>القيمة الفارغة للخيار الأول تجبر المستخدم على اختيار موضوع حقيقي عند وجود required. لا تستخدم ذلك لإجبار المستخدم على اختيارات غير ضرورية؛ اجعل كل حقل يخدم هدفًا واضحًا.
قائمة اختبار قبل النشر
- لكل حقل تسمية ظاهرة واسم إرسال مناسب.
- ترتيب الانتقال بالزر Tab يتبع ترتيب القراءة المنطقي.
- تظهر أخطاء الإدخال بجوار الحقل وتشرح طريقة التصحيح.
- وجهة النموذج متاحة وتستخدم اتصالًا آمنًا.
- يتم التحقق من المدخلات على الخادم مع التعامل الآمن مع البيانات.
بناء نموذج HTML قابل للاستخدام من البداية إلى النهاية
النموذج الجيد يبدأ من المهمة التي يريد المستخدم إنجازها، لا من قائمة الحقول المتاحة. اسأل عن أقل بيانات لازمة لإتمام المهمة، ثم رتّب الحقول بحسب تسلسلها الطبيعي. كل حقل إضافي يزيد الجهد واحتمال الخطأ، لذلك لا تجمع معلومات لا تحتاجها بوضوح.
مثال هيكلي مبسط
<form action="/contact" method="post">
<label for="name">الاسم</label>
<input id="name" name="name" autocomplete="name" required>
<label for="email">البريد الإلكتروني</label>
<input id="email" name="email" type="email" autocomplete="email" required>
<button type="submit">إرسال الرسالة</button>
</form>هذا المثال يوضح البنية فقط؛ يجب أن يكون المسار /contact موجودًا وأن يعالج الخادم الطلب بصورة آمنة. السمة name هي المفتاح الذي يرسل المتصفح قيمته، بينما تربط label النص بالحقل. وتساعد قيمة autocomplete المتصفح على اقتراح بيانات مناسبة دون إجبار المستخدم على كتابتها كل مرة.
اختيار method وbutton type
يستخدم GET عادةً لطلبات القراءة التي يمكن تمثيلها في عنوان URL، بينما يستخدم POST لإرسال بيانات تغيّر حالة أو تتضمن معلومات لا ينبغي وضعها في العنوان. هذا ليس بديلًا عن HTTPS أو ضوابط الأمان. كذلك، حدّد نوع الزر بوضوح: قد يؤدي زر بلا type داخل النموذج وظيفة الإرسال افتراضيًا، بينما يمنع type="button" الإرسال غير المقصود عند استخدامه لفتح واجهة أو تنفيذ إجراء آخر.
تقليل أخطاء الإدخال
- ضع مثالًا بجانب الحقول ذات التنسيق غير المألوف، مثل رقم مرجعي أو تاريخ.
- استخدم النوع الملائم مثل email أو tel عندما يحسن تجربة الإدخال، مع عدم افتراض أن التحقق المبدئي يثبت صحة البيانات.
- احتفظ بالقيم التي أدخلها المستخدم عند ظهور خطأ، باستثناء الحالات التي تتطلب حماية خاصة.
- اعرض حالة نجاح واضحة بعد الإرسال، ولا تترك المستخدم يتساءل هل تم استلام الطلب.
- اجعل كل حقل قابلًا للوصول بلوحة المفاتيح، وراقب التباين وحجم أهداف اللمس.
الخصوصية ومعالجة البيانات
وضّح لماذا تطلب البيانات وكيف ستستخدمها، ولا تجمع معلومات شخصية لمجرد احتمال الاحتياج إليها لاحقًا. يجب أن يتحقق الخادم من الصلاحيات والقيم، وأن يتعامل مع الرسائل المرسلة بمعدلات مناسبة لمنع الإغراق الآلي. إذا كان النموذج يرسل بيانات حساسة، فلا تعرضها في عناوين URL أو سجلات عامة، وطبّق سياسة احتفاظ مناسبة.
قائمة اختبار قبل النشر
- جرّب إرسال نموذج صحيح وآخر ناقصًا، وتأكد من وضوح النتيجة في الحالتين.
- استخدم لوحة المفاتيح وحدها وتحقق من ترتيب التركيز.
- اختبر على شاشة صغيرة ومع تكبير النص.
- تأكد أن الخادم لا يقبل حقولًا أو قيمًا غير مسموحة حتى لو تجاوز المستخدم التحقق في المتصفح.
- راجع الرسائل باللغة التي يستخدمها جمهور الصفحة.
يمكنك مراجعة دليل MDN للنماذج ودليل WAI للنماذج سهلة الوصول عند تنفيذ نموذج حقيقي.
تحسين ترتيب الحقول وتدفق النموذج
رتّب الحقول وفق ما يحتاجه المستخدم لإنجاز المهمة، واجمع المعلومات المرتبطة ببعضها في مجموعات واضحة. إذا كان النموذج طويلًا، ففكر في تقسيمه إلى خطوات مفهومة مع إظهار التقدم، لكن لا تضف خطوات متعددة إذا كان يمكن إكمال المهمة بسهولة في صفحة واحدة.
اختيار الحقول المطلوبة
اجعل الحقول الإلزامية واضحة قبل الإرسال، ولا تضع علامة الإلزام بعد أن يكتشف المستخدم الخطأ. تجنب طلب رقم هاتف أو عنوان كامل إذا لم تكن تحتاجهما. كلما قل عدد الحقول غير الضرورية، قلت احتمالات الخطأ وزاد وضوح الغرض من جمع البيانات.
التسميات والتعليمات
اربط label بكل حقل باستخدام for وid، وضع التعليمات بجانب الحقل الذي تحتاجه. لا تعتمد على placeholder ليشرح الحقل؛ فهو يختفي عند الكتابة وقد يصعب قراءته بسبب التباين. إذا كان تنسيق القيمة محددًا، قدم مثالًا، مثل شكل رقم مرجعي أو طريقة كتابة التاريخ.
النجاح والفشل
بعد الإرسال، أخبر المستخدم هل تمت العملية بنجاح وما الخطوة التالية. عند الفشل، احتفظ بالقيم غير الحساسة واشرح ما يحتاج إلى تصحيح. إذا كان النموذج يرسل طلبًا إلى خدمة خارجية، تعامل مع انقطاع الشبكة أو انتهاء المهلة برسالة مفهومة وخيار إعادة المحاولة دون تكرار عملية غير آمنة.
اختبر النموذج على الهاتف ولوحة المفاتيح وقارئ الشاشة، وراجع دليل WAI للنماذج قبل النشر.
من إدخال البيانات إلى إرسال النموذج: ما الذي ينبغي اختباره؟
يتكون النموذج الجيد من عناصر إدخال مفهومة، وطريقة إرسال صحيحة، وحالات نجاح وفشل يمكن للمستخدم إدراكها. ابدأ بتحديد الهدف من كل حقل، واحذف الحقول التي لا تحتاج إليها، لأن طلب بيانات زائدة يزيد الاحتكاك ويضعف الخصوصية. اربط كل حقل بتسمية صريحة، واستخدم نصًا مساعدًا عندما تكون صيغة الإدخال غير بديهية، مثل رقم مرجعي أو تاريخ بمتطلبات محددة.
اختر method وaction بعناية
استخدم طريقة الإرسال التي تناسب العملية، ولا تضع بيانات حساسة في عنوان URL. لا يعني استخدام POST أن التطبيق آمن تلقائيًا؛ يجب أن يكون الاتصال مشفرًا وأن يتحقق الخادم من الصلاحيات والمدخلات. تأكد من أن الزر المقصود يرسل النموذج، وأن أزرار الإلغاء أو التنقل داخل النموذج لا ترسله بالخطأ؛ يمكن تحديد type="button" للأزرار التي لا ينبغي أن ترسل.
غطِّ الحالات التي لا تظهر في العرض المثالي
اختبر إرسال الحقول الفارغة، والقيم غير الصالحة، والنقر المزدوج، وفشل الشبكة، واستجابة الخادم المتأخرة. ينبغي تعطيل الإرسال المتكرر أثناء المعالجة عند الحاجة، مع إعادة إتاحة الإجراء بعد الفشل. لا تعرض رسالة نجاح قبل تأكيد الخادم، ولا تمسح النموذج إذا لم يتم حفظ البيانات. إذا كانت العملية قد تُكرر آثارًا مالية أو إجرائية، فطبّق حماية مناسبة من الطلبات المكررة في الخادم أيضًا.
حافظ على قابلية الوصول
تحقق من إمكانية الوصول إلى كل حقل باستخدام Tab، ومن وضوح مؤشر التركيز، ومن أن ترتيب التنقل منطقي. يجب أن تكون رسائل الخطأ مقروءة ومتصلة بالحقول، وألا تعتمد على اللون وحده. جرّب النموذج على شاشة صغيرة ومع تكبير النص، وتأكد من أن الأزرار لا تتداخل وأن التسميات تظل ظاهرة.
للتفاصيل راجع دليل MDN للنماذج ودروس WAI للنماذج القابلة للوصول. اختبر سلوك الواجهة والخادم معًا؛ فكل منهما يعالج جزءًا مختلفًا من مسؤولية التحقق.
تقليل البيانات وحماية المستخدم أثناء إرسال النماذج
اجمع فقط البيانات اللازمة لإنجاز الغرض المعلن. كل حقل إضافي يزيد الوقت المطلوب من المستخدم ويزيد مسؤولية تخزين البيانات وحمايتها. وضّح سبب طلب المعلومات الحساسة عندما تكون ضرورية، ولا تطلبها في نموذج عام إذا كان بالإمكان إتمام المهمة دونها. استخدم اتصالًا مشفرًا، وتأكد من أن الخادم يتحقق من الصلاحيات والقيم بدل الاعتماد على الحقول المخفية أو قواعد المتصفح.
خطط لحالات الفشل والاستعادة
إذا فشل الإرسال، احتفظ بالقيم غير الحساسة حتى يستطيع المستخدم المحاولة مجددًا، لكن تجنب حفظ أسرار في تخزين المتصفح دون ضرورة. اعرض حالة واضحة أثناء المعالجة، ولا تسمح بتكرار عملية قد تسبب أثرًا مزدوجًا. إذا كان النموذج طويلًا، ففكر في تقسيمه إلى خطوات مفهومة مع إظهار التقدم وإمكانية الرجوع دون فقدان البيانات.
بعد النشر، راقب معدلات فشل الإرسال ورسائل الخادم مع احترام الخصوصية. لا تسجل محتوى الحقول الحساسة في السجلات التشخيصية، واجعل معالجة الأخطاء مفيدة للمستخدم دون كشف تفاصيل النظام الداخلية.
الخلاصة
الخلاصة: قلّل الحقول إلى ما يحتاجه المستخدم، واربط كل حقل بتسمية وتعليمات واضحة، ثم اختبر الإرسال والنجاح والفشل على أجهزة مختلفة. تحقق الخادم ضروري حتى لو استخدمت قواعد HTML.