WCAG 3.3.2: التسميات أو التعليمات

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

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

المعيار واسع النطاق عن قصد. فهو يغطي أي آلية يقدّم من خلالها المستخدم بياناته: عناصر <input> بجميع أنواعها (text, email, password, number, date, checkbox, radio, file upload)، وعناصر <textarea> للنص متعدد الأسطر، وقوائم <select> المنسدلة. كما ينطبق أيضاً على عناصر التحكم التفاعلية المخصصة المبنية باستخدام أدوار ARIA مثل role='combobox' أو role='listbox'.

يمكن توفير التسمية بعدة طرق تفي بهذا المعيار. الأكثر قوة هو عنصر <label> المرتبط برمجياً، الموجود بصرياً والمرتبط بعنصر التحكم من خلال زوج متطابق من for/id. بدلاً من ذلك، يمكن ربط نص تسمية مرئي باستخدام aria-labelledby الذي يشير إلى عنصر موجود، أو يمكن ربط تعليمات إضافية باستخدام aria-describedby. الشرط الأساسي هو أن التسمية أو التعليمات يجب أن تكون مقدَّمة — أي أن تكون موجودة في شكل يمكن للمستخدم إدراكه. لا يكفي نص الـ placeholder وحده للوفاء بهذا المعيار لأنه يختفي بمجرد أن يبدأ المستخدم في الكتابة، كما أنه لا يُنقل بشكل موثوق من قِبل جميع تقنيات المساعدة كتسمية دائمة.

يتطلب الاجتياز أن يكون لكل إدخال تسمية مرئية (أو على الأقل قابلة للتحديد برمجياً)، موجودة قبل أن يشرع المستخدم في ملء الحقل، وأن تكون وصفية بما يكفي لتوضيح نوع البيانات المتوقعة. يحدث الإخفاق عندما لا يكون للحقل أي تسمية على الإطلاق، أو عندما تكون التسمية الوحيدة هي خاصية placeholder، أو عندما تكون التسمية موجودة بصرياً ولكن غير مرتبطة برمجياً، أو عندما تكون التعليمات المتعلقة بالتنسيق المطلوب (مثل "أدخل التاريخ بصيغة DD/MM/YYYY") غائبة تماماً.

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

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

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

بالنسبة إلى المستخدمين المكفوفين وضعاف البصر الذين يعتمدون على قارئات الشاشة، يتم الإعلان عن الحقل غير المسمى ببساطة على أنه "edit text" أو "blank" دون سياق. ليس لدى المستخدم أي طريقة لمعرفة ما إذا كان عليه إدخال اسمه أو عنوان بريده الإلكتروني أو رقم بطاقته الائتمانية. وفقاً لمنظمة الصحة العالمية، يعاني حوالي 2.2 مليار شخص حول العالم من شكل من أشكال ضعف البصر، ويستخدم الملايين منهم قارئات الشاشة كوسيلتهم الأساسية للتفاعل مع الويب.

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

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

فكّر في سيناريو واقعي ملموس: مستخدم ضعيف البصر يتقدم للحصول على إعانة حكومية عبر بوابة مؤسسة عامة تركية. يستخدم النموذج نصوص placeholder بدلاً من التسميات. عند تكبير المستخدم للشاشة إلى 200% لقراءة المحتوى، تختفي نصوص الـ placeholder قبل أن يتمكن من قراءتها. يملأ المستخدم الحقول بالتخمين ويُرسل نموذجاً يحتوي على أخطاء، ليتلقى رسالة خطأ عامة دون أي إشارة إلى الحقول غير الصحيحة. يؤدي هذا السيناريو إلى استبعاد من خدمة عامة حيوية — وهو أمر يمكن منعه بالكامل.

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

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

• label — تتحقق هذه القاعدة من أن كل عنصر <input> (باستثناء تلك ذات type='hidden' وtype='image' وtype='button' وtype='submit' وtype='reset') وكل <textarea> وكل <select> لديه اسم متاح. تشير القاعدة إلى العناصر التي تفتقر إلى <label> مرتبط، أو خاصية aria-label، أو مرجع aria-labelledby، أو خاصية title. هذا هو المؤشر الآلي الأساسي على انتهاكات 3.3.2 في عناصر النماذج القياسية.
• select-name — تستهدف هذه القاعدة تحديداً عناصر القوائم المنسدلة <select> وتتحقق من أن لديها اسماً متاحاً غير فارغ. يفترض المطورون أحياناً أن خيارات القائمة المنسدلة تجعل غرضها بديهياً، لكن بدون تسمية، يسمع مستخدمو قارئات الشاشة فقط قيمة الخيار المحدد حالياً — والتي قد تكون قيمة افتراضية عامة مثل "Select one" — دون أي إشارة إلى الفئة التي يختارون منها. تشير Axe إلى عناصر <select> التي تفتقر إلى أي من آليات التسمية القياسية.
• textarea-label — تتحقق هذه القاعدة من عناصر <textarea> بحثاً عن اسم متاح. تُستخدم مناطق النص متعددة الأسطر كثيراً للتعليقات أو الرسائل أو الإدخال التفصيلي، ومع ذلك غالباً ما تُترك بدون تسمية تحت الافتراض الخاطئ بأن السياق المحيط كافٍ. تشير Axe إلى أي <textarea> لا يمكن ربطه برمجياً بتسمية عبر <label for> أو aria-label أو aria-labelledby أو title.

من المهم فهم حدود الاختبار الآلي لهذا المعيار. يمكن لـ axe-core اكتشاف غياب التسمية البرمجية، لكنه لا يستطيع تحديد ما إذا كانت التسمية الموجودة ذات معنى أو دقيقة بالفعل. حقل يحمل التسمية "Field 1" أو تسمية تحتوي فقط على "*" سوف يجتاز الفحوصات الآلية بينما يفشل تماماً في خدمة المستخدمين. المراجعة اليدوية مطلوبة دائماً للتأكد من أن التسميات تصف الإدخال المتوقع بوضوح، وأن تعليمات التنسيق موجودة عند الحاجة (مثل صيغ التاريخ ومتطلبات كلمة المرور)، وأن الحقول المطلوبة محددة — ويفضل أن يكون ذلك بصرياً وبرمجياً معاً.

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

1. فحص آلي باستخدام axe DevTools أو Lighthouse: افتح الصفحة التي تحتوي على النموذج في Chrome أو Firefox. شغّل إضافة المتصفح axe DevTools وفلتر النتائج حسب قواعد label وselect-name وtextarea-label. دوّن كل عنصر تم الإشارة إليه. شغّل Google Lighthouse (تدقيق إمكانية الوصول) كفحص ثانوي. صدّر أو التقط صوراً لكل الانتهاكات. تذكّر أن تقريراً آلياً نظيفاً لا يضمن الامتثال — تابع الخطوات اليدوية.
2. فحص بصري: دون استخدام أي تقنية مساعدة، راجع كل حقل في النموذج على الصفحة. تأكد من أن لكل حقل تسمية مرئية ثابتة — وليس مجرد placeholder — موضوعة بوضوح بالقرب من الحقل (عادةً أعلاه أو إلى اليسار). تأكد من أن متطلبات التنسيق (مثل "يجب أن تتكون كلمة المرور من 8 أحرف على الأقل") تظهر قبل أو في وقت الإدخال، وليس فقط بعد إرسال فاشل. تأكد من أن الحقول المطلوبة محددة بأكثر من اللون وحده.
3. اختبار التنقل بلوحة المفاتيح: انتقل بين كل حقل في النموذج باستخدام مفتاح Tab. تأكد من أنه عند حصول كل حقل على التركيز، يكون غرضه واضحاً فوراً من التسمية المرئية. لا ينبغي أن يكون أي حقل قابلاً للوصول بلوحة المفاتيح دون أن تكون تسمية ثابتة مجاورة مرئية في تلك اللحظة.
4. اختبار قارئ الشاشة باستخدام NVDA وFirefox: افتح النموذج مع تشغيل NVDA. اضغط Tab للانتقال بين كل عنصر تفاعلي. يجب أن يعلن NVDA عن التسمية والدور (مثل "edit", "combo box") وأي حالة (مثل "required"). إذا أعلن NVDA عن الدور والحالة فقط دون تسمية، يفشل الحقل. استخدم وضع النماذج في NVDA (يُفعّل تلقائياً على العناصر التفاعلية) لمحاكاة تنقل المستخدم الواقعي.
5. اختبار قارئ الشاشة باستخدام VoiceOver وSafari (macOS/iOS): فعّل VoiceOver (Command + F5 على Mac). استخدم Tab أو السحب للتنقل إلى كل حقل في النموذج. يجب أن يعلن VoiceOver عن التسمية قبل الدور. على iOS، انقر على كل حقل وتأكد من أن التسمية تُقرأ بصوت عالٍ قبل ظهور لوحة المفاتيح. عادةً ما تُقرأ الحقول التي تحتوي فقط على placeholder كنص placeholder عند التركيز الأول لكنها تصبح صامتة بمجرد إدخال نص.
6. اختبار قارئ الشاشة باستخدام JAWS وChrome: افتح JAWS وتنقل في النموذج باستخدام Tab. استخدم وضع النماذج في JAWS. تأكد من أن الاسم المُعلن لكل حقل يتطابق تماماً مع تسميته المرئية. استخدم Insert + F1 (مساعدة الحقل) في JAWS للتحقق من أي أوصاف إضافية عبر aria-describedby.
7. اختبار التحكم الصوتي باستخدام Dragon NaturallySpeaking: فعّل Dragon وحاول التفاعل مع كل حقل من خلال نطق تسميته المرئية. إذا لم تتطابق التسمية المنطوقة مع الاسم المتاح برمجياً، لن يستجيب الحقل لأمر الصوت، مما يشير إلى عدم تطابق يفشل في كل من 3.3.2 والمعايير ذات الصلة.

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

حقل نصي بدون تسمية — غير صحيح

<!-- No label provided; placeholder is the only hint -->
<input type='text' name='email' placeholder='Email address' />

حقل نصي بدون تسمية — صحيح

<!-- Visible <label> associated via matching for/id attributes.
     Placeholder may still be used as supplementary hint,
     but the label is the primary, persistent identifier. -->
<label for='email'>Email address</label>
<input type='text' id='email' name='email' placeholder='[email protected]' />

قائمة select منسدلة بدون تسمية — غير صحيح

<!-- No label; screen readers will only announce the selected option value -->
<select name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

قائمة select منسدلة بدون تسمية — صحيح

<!-- Programmatically associated label makes the field's purpose clear
     before the user opens the dropdown. -->
<label for='city'>City</label>
<select id='city' name='city'>
  <option value=''>Select a city</option>
  <option value='istanbul'>Istanbul</option>
  <option value='ankara'>Ankara</option>
</select>

Textarea بدون تسمية — غير صحيح

<!-- The textarea has no label; surrounding paragraph text is not
     programmatically associated and will not be read by screen readers
     as the field's label. -->
<p>Please describe your issue:</p>
<textarea name='message' rows='5'></textarea>

Textarea بدون تسمية — صحيح

<!-- Using aria-labelledby to associate the existing visible heading
     with the textarea, or alternatively wrapping with a <label> element. -->
<label for='message'>Please describe your issue</label>
<textarea id='message' name='message' rows='5'></textarea>

غياب تعليمات التنسيق لحقل تاريخ — غير صحيح

<!-- Label present but no instruction about expected date format;
     users must guess whether to enter 01/06/2025 or 2025-06-01. -->
<label for='dob'>Date of birth</label>
<input type='text' id='dob' name='dob' />

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

<!-- Format instruction is visible and linked via aria-describedby
     so screen readers announce it when the field receives focus. -->
<label for='dob'>Date of birth</label>
<span id='dob-hint'>Enter as DD/MM/YYYY, e.g. 15/06/1990</span>
<input type='text' id='dob' name='dob' aria-describedby='dob-hint' />

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

• استخدام placeholder كتسمية وحيدة: يختفي نص الـ placeholder عند الإدخال، ولا يُعلن عنه بشكل موثوق كتسمية من قِبل جميع قارئات الشاشة، ويفشل في خدمة المستخدمين ذوي الإعاقات الإدراكية الذين يحتاجون إلى نص مرجعي دائم. احرص دائماً على توفير عنصر <label> مرئي بالإضافة إلى أي placeholder.
• وضع تسمية بصرياً بالقرب من الحقل دون ربط برمجي: عنصر <p> أو <span> موضوع بصرياً فوق عنصر الإدخال يبدو كتسمية للمستخدمين المبصرين لكنه يُتجاهل من قِبل قارئات الشاشة. استخدم <label for='id'> أو aria-labelledby أو ضع عنصر الإدخال داخل عنصر <label>.
• استخدام aria-label بنص لا يطابق التسمية المرئية: عندما يختلف الاسم المتاح برمجياً عن النص المرئي، لا يستطيع مستخدمو التحكم الصوتي تفعيل الحقل من خلال نطق ما يقرؤونه على الشاشة، مما ينتهك المعيار 2.5.3 (Label in Name) ويخلق ارتباكاً لمستخدمي قارئات الشاشة.
• تسمية مجموعة من أزرار الاختيار مع إهمال legend للمجموعة: قد تكون أزرار الاختيار الفردية مُسمّاة بنص الخيار الخاص بها، لكن إذا لم يتم توفير السؤال العام (مثل "طريقة الدفع") عبر <fieldset> و<legend>، يسمع المستخدمون الذين يتنقلون بلوحة المفاتيح كل خيار بمعزل دون فهم ما يختارون بينه.
• تحديد الحقول المطلوبة باللون أو النجمة فقط دون تفسير: النجمة (*) بجوار التسمية لا تنقل أي معنى لمستخدمي قارئات الشاشة ما لم يتم شرح معناها (مثل ملاحظة في أعلى النموذج تنص على "الحقول المشار إليها بـ * مطلوبة") وأن تحمل الحقول المطلوبة أيضاً خاصية required أو aria-required='true'.
• إخفاء تعليمات التنسيق حتى بعد إرسال فاشل: عرض قواعد كلمة المرور أو متطلبات تنسيق التاريخ فقط في رسائل الخطأ بعد الإرسال يجبر المستخدمين على ارتكاب خطأ قبل أن يتمكنوا من معرفة ما هو متوقع. يجب أن تكون التعليمات موجودة قبل أو في وقت تفاعل المستخدم مع الحقل.
• إخفاء التسميات باستخدام display:none أو visibility:hidden: تزيل خصائص CSS هذه التسميات من شجرة إمكانية الوصول بالكامل. إذا كان لابد من إخفاء التسمية بصرياً (مثلاً لتصميم بسيط)، استخدم فئة CSS للإخفاء البصري تبقي العنصر في شجرة إمكانية الوصول مع نقله خارج الشاشة.
• استخدام خاصية title كتسمية وحيدة والافتراض بأنها كافية: رغم أن axe-core قد لا يشير إلى التسمية المعتمدة على title فقط، إلا أن خاصية title تظهر فقط كأداة تلميح عند التحويم وهي غير متاحة لمستخدمي لوحة المفاتيح فقط ومستخدمي الأجهزة المحمولة. يجب استخدامها كوصف إضافي، لا كتسمية أساسية.
• تطبيق aria-label واحدة على عنصر حاوية <div> وتوقع أن تُسمّي عناصر الإدخال الفرعية: لا تُورَّث تسميات ARIA على عناصر الحاوية إلى عناصر التحكم في النماذج الفرعية. يجب تسمية كل عنصر تفاعلي على حدة.
• عدم إعادة ربط التسميات بعد تحديثات المحتوى الديناميكية: عندما تُحقن حقول النماذج ديناميكياً عبر JavaScript (مثل إضافة صف عنوان)، غالباً ما تفتقر عناصر الإدخال المُضافة حديثاً إلى تسميات مرتبطة لأن المطور أضاف فقط نص التسمية المرئي كعنصر شقيق دون ربط صحيح عبر for/id.

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

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

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

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

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

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