كيفية جعل النماذج الخاصة بك متاحة للجميع: التسميات، والأخطاء، والتحقق من الصحة

وفقًا لـ WebAIM، فإن 48.6% من الصفحات الرئيسية للمواقع تحتوي على حقول إدخال نماذج تفتقر إلى التسميات — مما يجعل الحقول غير المسمّاة واحدة من أكثر إخفاقات الوصول شيوعًا على الويب. فكّر في ما يعنيه ذلك عمليًا: مستخدم قارئ الشاشة يصل إلى نموذج الاتصال الخاص بك، يضغط على Tab للتنقل بين الحقول، ولا يسمع سوى "edit text" مرارًا وتكرارًا. يعلن قارئ الشاشة عن تسميات حقول النموذج — وبدونها، يسمع المستخدمون "edit text" دون سياق ولا يعرفون ما هي المعلومات التي يجب إدخالها. غالبًا ما تكون النماذج الجزء الأكثر أهمية للأعمال في الموقع — تدفقات الدفع، شاشات التسجيل، صفحات الاتصال، طلبات الدعم — ومع ذلك تظل من أكثر التجارب تعطلًا بشكل مستمر للأشخاص الذين يستخدمون تقنيات مساعدة.

لماذا تهم إمكانية الوصول في النماذج أكثر مما تعتقد

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

يصادف معظم المستخدمين ذوي الإعاقة أخطاء عند إرسال المعلومات ولا يحصلون على تعليمات واضحة حول كيفية إصلاحها — مما يترك أمامهم خيارين: التخلي عن المحاولة والبحث عن نموذج أكثر إتاحة، أو طلب مساعدة شخص آخر، وكلاهما ليس تجربة مثالية. من منظور الأعمال، تحسّن النماذج المتاحة تجربة المستخدم، وتقلل معدلات التخلي، وتلبي المتطلبات القانونية. من منظور الامتثال، يُعد المعياران WCAG 1.3.1 (المعلومات والعلاقات) و4.1.2 (الاسم، الدور، القيمة) متطلبات من المستوى A موجودة منذ إطلاق WCAG 2.0 في 2008. هذه ليست حالات حافة أو تقنيات متقدمة — بل هي التوقعات الأساسية للمعيار.

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

معايير نجاح WCAG التي تحكم النماذج

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

تشمل المعايير الأكثر صلة: 1.3.1 المعلومات والعلاقات (المستوى A)، الذي يتطلب أن تكون المعلومات والبنية والعلاقات المنقولة من خلال العرض قابلة للتحديد برمجيًا؛ 2.4.6 العناوين والتسميات (المستوى AA)، الذي ينص على أن العناوين والتسميات تصف الموضوع أو الغرض؛ 3.3.2 التسميات أو التعليمات (المستوى A)، الذي يتطلب توفير تسميات أو تعليمات عندما يتطلب المحتوى إدخال المستخدم؛ و4.1.2 الاسم، الدور، القيمة (المستوى A)، الذي يتطلب أنه بالنسبة لجميع مكونات واجهة المستخدم، يمكن تحديد الاسم والدور برمجيًا.

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

إتقان التسميات: أساس النماذج المتاحة

التسمية ليست مجرد تلميح بصري. إنها الاتصال البرمجي بين الوصف النصي وعنصر التحكم في النموذج، وهي الآلية الأساسية التي تحدد بها تقنيات المساعدة الغرض من الحقل. الطريقة الأكثر قوة لإنشاء هذا الاتصال هي باستخدام عنصر HTML <label> وخصيصة for الخاصة به، التي تشير إلى id حقل الإدخال المقابل.

<!-- خطأ: placeholder وحده ليس تسمية متاحة -->
<input type='email' placeholder='Email address'>

<!-- صحيح: تسمية صريحة مرتبطة عبر for/id -->
<label for='email'>Email address</label>
<input type='email' id='email' name='email'>

يجب أن تكون التسميات مرئية دائمًا — لا مجرد placeholders. تختفي placeholders عندما يكتب المستخدمون، تاركة الحقل بلا سياق. هذا تمييز بالغ الأهمية. لم يُصمَّم نص placeholder ليكون تسمية؛ فهو يختفي بمجرد أن يبدأ المستخدم في الكتابة، وغالبًا ما يكون تباين لونه غير كافٍ، ولا تعرضه العديد من برامج قراءة الشاشة بشكل موثوق كاسم متاح للحقل. الاعتماد على placeholders وحدها يخذل المستخدمين على نطاق واسع — ليس فقط أولئك الذين يستخدمون تقنيات مساعدة.

عندما يكون لديك مجموعات من الحقول ذات الصلة — مثل مجموعة من أزرار الاختيار (radio buttons) أو كتلة من مربعات الاختيار (checkboxes) — فإن النمط الصحيح هو <fieldset> و<legend>. قم بتجميع الخيارات ذات الصلة مثل مربعات الاختيار وأزرار الاختيار باستخدام fieldsets وlegends لجعل النماذج المعقدة أسهل في الفهم.

<fieldset>
  <legend>Preferred contact method</legend>

  <input type='radio' id='contact-email' name='contact' value='email'>
  <label for='contact-email'>Email</label>

  <input type='radio' id='contact-phone' name='contact' value='phone'>
  <label for='contact-phone'>Phone</label>
</fieldset>

في الحالات التي تكون فيها التسمية المرئية زائدة بصريًا — على سبيل المثال، حقل بحث منفرد بجوار زر Search مُسمّى بوضوح — يمكنك استخدام aria-label أو aria-labelledby لتوفير اسم متاح دون عرض نص مرئي. ومع ذلك، استخدم هذا بحذر. يمكن للأشخاص الذين يستخدمون برامج قراءة الشاشة تحديد عناصر التحكم في النماذج وفهمها بسهولة أكبر لأنها مرتبطة بتسميات، وfieldsets، وعناصر بنيوية أخرى — كما أن التسميات المرئية تفيد الجميع، بما في ذلك المستخدمين المبصرين ذوي الإعاقات الإدراكية، والمستخدمين الذين يقومون بالتكبير إلى 400%، وأي شخص فقد مكانه مؤقتًا في نموذج طويل.

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

كتابة رسائل خطأ تقدم مساعدة فعلية

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

رسائل الخطأ الغامضة مثل "Invalid input" أو "Error" لا تخبر المستخدمين بما حدث خطأ أو كيفية تصحيحه. يجب أن تحدد كل رسالة خطأ المشكلة المحددة وتقترح حلاً ملموسًا.

لضمان التوافق مع برامج قراءة الشاشة، يجب دمج رسائل الخطأ في DOM باستخدام سمات ARIA مثل aria-invalid="true" وaria-describedby، التي تربط رسائل الخطأ مباشرة بالحقول المقابلة لها. إليك شكل حالة خطأ مُعلَّمة بشكل صحيح:

<label for='email'>Email address</label>
<input
  type='email'
  id='email'
  name='email'
  aria-invalid='true'
  aria-describedby='email-error'
>
<span id='email-error' role='alert'>
  Please enter a valid email address, for example: [email protected]
</span>

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

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

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

توقيت التحقق وإدارة التركيز

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

اجمع بين التغذية الراجعة في الوقت الفعلي للحقول الحرجة، والتحقق عند فقدان التركيز (on-blur) للمدخلات ذات التنسيق المحدد، والتحقق عند الإرسال لمراجعة شاملة للأخطاء. عمليًا، يعني هذا: تحقق من التنسيقات المعقدة مثل كلمات المرور أو عناوين البريد الإلكتروني عندما يغادر المستخدم الحقل (on blur)؛ تجنب المقاطعة بالتحقق الفوري الذي يعمل مع كل ضغطة مفتاح؛ وعند إرسال النموذج، قم بتمرير كامل وبلّغ بوضوح عن جميع الأخطاء دفعة واحدة.

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

<!-- ملخص الأخطاء موضوع في أعلى النموذج، يتم تركيزه برمجيًا -->
<div id='error-summary' role='alert' tabindex='-1'>
  <h2>2 errors found. Please correct the following:</h2>
  <ul>
    <li><a href='#email'>Email address: Please enter a valid email</a></li>
    <li><a href='#phone'>Phone number: Please use the format (555) 555-5555</a></li>
  </ul>
</div>

تأكد من أن المستخدمين يمكنهم التنقل في النماذج دون استخدام الفأرة، مع ترتيب Tab منطقي ومؤشرات تركيز مرئية. حلقة التركيز الافتراضية في المتصفح هي خط أساس قانوني ووظيفي — لكن العديد من فرق التصميم تقوم بإخفائها باستخدام outline: none في CSS دون توفير بديل. هذا يجعل النموذج غير قابل للاستخدام فعليًا لمستخدمي لوحة المفاتيح فقط. مؤشر تركيز واضح وعالي التباين مطلوب بموجب WCAG 2.4.7 (المستوى AA) والمعيار الأكثر صرامة 2.4.11 في WCAG 2.2. إذا تعارضت إرشادات علامتك التجارية مع حلقة التركيز الافتراضية، فاستبدلها — لا تزلها.

تقديم التعليمات والتلميحات قبل حدوث الأخطاء

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

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

<label for='phone'>Phone number</label>
<input
  type='tel'
  id='phone'
  name='phone'
  aria-describedby='phone-hint'
>
<span id='phone-hint'>Format: (555) 555-5555</span>

كلما أمكن، قدّم أمثلة لتوضيح التوقعات — على سبيل المثال، إذا كان حقل التاريخ يتطلب التنسيق MM/DD/YYYY، فضمّن مثالًا مثل "Enter date as 12/25/2024." بالنسبة لحقول كلمات المرور، اذكر المتطلبات مسبقًا بدلًا من كشفها واحدة تلو الأخرى عندما ينتهك المستخدم كل قاعدة. إذا أمكن، يجب ألا تكون النماذج خاضعة لحد زمني حتى يتمكن المستخدمون من إكمال النموذج وفق وتيرتهم — وإذا كان لا بد من وجود حد زمني، فيجب أن يكون لدى المستخدم خيار إيقافه أو تمديده.

تُعد خصيصة autocomplete آلية أخرى كثيرًا ما تُهمل في إمكانية الوصول. تعيين قيم مثل autocomplete="email"، autocomplete="given-name"، أو autocomplete="street-address" يمكّن المتصفحات ومديري كلمات المرور من تعبئة الحقول تلقائيًا بشكل صحيح، مما يقلل بشكل كبير العبء على المستخدمين ذوي الإعاقات الحركية، أو الإعاقات الإدراكية، أو أي شخص يجد الكتابة المتكررة صعبة. يتطلب معيار WCAG 1.3.5 (تحديد غرض الإدخال، المستوى AA) ذلك للحقول التي تجمع معلومات شخصية.

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

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

بالنسبة لاختبار لوحة المفاتيح، افصل الفأرة وحاول إكمال النموذج. يجب أن تتمكن من الوصول إلى كل حقل، وتفعيل كل زر، وتلقي كل رسالة خطأ باستخدام Tab وShift+Tab ومفاتيح الأسهم وEnter/Space فقط. إذا علقت في مكان ما، فهذا فشل. بالنسبة لاختبار قارئ الشاشة، استخدم NVDA مع Firefox على Windows أو VoiceOver مع Safari على macOS. تتصرف برامج قراءة الشاشة بشكل مختلف قليلًا عن بعضها — اختصارات مختلفة، إعلانات دلالية مختلفة، ودعم ميزات مختلف؛ على سبيل المثال، يعمل NVDA بشكل أفضل مع Firefox، بينما يعمل VoiceOver بشكل أفضل مع Safari. سيؤدي الاختبار باستخدام مجموعتين على الأقل إلى اكتشاف أوسع نطاق من المشكلات.

تُعد أدوات مثل WAVE وAxe رائعة لفحص النماذج بحثًا عن التسميات المفقودة، وسمات ARIA غير الصحيحة، وضعف تباين الألوان. يمكن دمج هذه الأدوات الآلية مباشرة في خط أنابيب CI/CD الخاص بك لاكتشاف التراجعات قبل أن تصل إلى الإنتاج. نظرًا لأن إرشادات إمكانية الوصول دقيقة، يمكن للأدوات الآلية اكتشاف حوالي 30% فقط من مشكلات WCAG — ولهذا يجب أن تُستكمل الطبقة الآلية بمراجعة يدوية، ويفضل أن يكون ذلك مع اختبار فعلي مع مستخدمين يعتمدون على تقنيات مساعدة.

عند مراجعة الشيفرة يدويًا، اطرح الأسئلة التالية لكل حقل نموذج: هل لديه تسمية مرئية؟ هل هذه التسمية مرتبطة برمجيًا عبر for/id أو ARIA؟ هل أي نص تلميح مرتبط باستخدام aria-describedby؟ هل تضبط كل حالة خطأ خصيصة aria-invalid="true" وتشير إلى رسالة الخطأ عبر aria-describedby؟ هل خصيصة required موجودة في الحقول المطلوبة؟ هل يمكنك الوصول إلى كل عنصر تفاعلي وتشغيله باستخدام لوحة المفاتيح فقط؟

أهم النقاط

• كل حقل إدخال يحتاج إلى تسمية برمجية. استخدم <label for='...'> لجميع حقول النماذج — لا تعتمد أبدًا على نص placeholder وحده. كل حقل نموذج يحتاج إلى تسمية برمجية، دون استثناء — نص placeholder ليس تسمية.
• يجب أن تسمّي رسائل الخطأ المشكلة وتقترح حلاً. يجب أن تحدد رسائل الخطأ المشكلة وتقترح كيفية إصلاحها، ويجب ربطها بالحقول الخاصة بها باستخدام aria-describedby.
• لا تعتمد أبدًا على اللون وحده. لا تعتمد على اللون وحده لأي إشارة حالة — استخدم النص، والأيقونات، ومؤشرات غير لونية أخرى إلى جانب إشارات اللون.
• إدارة التركيز بعد الإرسال. يجب تحديد الخطأ بوضوح، وتوفير وصول سريع إلى العنصر الإشكالي، ويجب أن يكون المستخدم قادرًا على إصلاح الخطأ بسهولة وإعادة إرسال النموذج. نقل التركيز إلى ملخص الأخطاء بعد فشل الإرسال هو المعيار الذهبي.
• اختبر باستخدام أدوات حقيقية، لا افتراضات. الحفاظ على إتاحة النماذج ليس مهمة تُنفّذ مرة واحدة وتنتهي — بل يتطلب اختبارًا منتظمًا وتحديثات لضمان بقائها متوافقة وسهلة الاستخدام. اجمع بين الفحص الآلي والتنقل بلوحة المفاتيح فقط واختبار قارئ الشاشة في كل تحديث مهم للنموذج.