WCAG 2.4.6: العناوين والتسميات

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

تنص WCAG 2.4.6 على ما يلي: "تصف العناوين والتسميات الموضوع أو الغرض." في جوهره، يقتضي هذا المعيار أن أي عنوان (<h1> حتى <h6>) أو تسمية (<label>، aria-label، aria-labelledby) تظهر في الصفحة يجب أن تكون وصفية بما يكفي لتوضيح موضوع المحتوى الذي تقدمه أو غرض عنصر التحكم الذي تحدده.

هذا المعيار لا يفرض وجود عناوين أو تسميات من الأساس — فذلك الالتزام مغطى بمعايير نجاح أخرى مثل 1.3.1 (المعلومات والعلاقات) و2.4.2 (عنوان الصفحة). ما تنظمه 2.4.6 هو جودة العناوين والتسميات الموجودة بالفعل: عندما تكون موجودة، يجب أن تكون ذات معنى. العنوان الذي يقرأ "Section 1" أو التسمية التي تكتب "Field" لا تخبر المستخدمين بأي شيء مفيد عن المحتوى الذي يليها أو عن حقل الإدخال الذي تصفه. قارن ذلك مع "عنوان الشحن الخاص بك" أو "ملخص الميزانية الشهرية"، والتي توجه المستخدمين فورًا.

تشمل التسميات في هذا السياق ليس فقط عنصر HTML <label> المرتبط بعناصر النماذج، بل أيضًا أي آلية ترميز برمجية للتسمية: aria-label، aria-labelledby، خاصية title عندما تُستخدم كاسم متاح، وعنصر legend لمجموعات الحقول (fieldset). أي من هذه الآليات التي تُعرض لتقنيات المساعدة يجب أن يصف بوضوح غرض عنصر التحكم المرتبط بها.

يحدث الإخفاق عندما يكون العنوان أو التسمية عامًا أو غامضًا أو غير مفيد لدرجة أن المستخدم لا يستطيع تحديد ما الذي تتعلق به هذه الفقرة أو عنصر التحكم دون قراءة السياق المحيط. على سبيل المثال، نموذج يحتوي على ثلاثة حقول إدخال جميعها تحمل التسمية "Enter here" يفشل في تلبية هذا المعيار، وكذلك صفحة تستخدم عناوين مكررة مثل "More Info" لكل قسم فرعي. وبالمثل، فإن العنوان الموجود تقنيًا في الـ DOM ولكنه يضلل المستخدم تمامًا — مثل تسمية قسم نموذج الاتصال بعنوان "News and Updates" — يعد أيضًا إخفاقًا.

هناك استثناء رسمي مهم واحد: تنطبق WCAG 2.4.6 فقط عندما تُستخدم العناوين والتسميات بالفعل. إذا كانت الصفحة لا تحتوي بشكل مشروع على عناوين (على سبيل المثال، مستند قصير جدًا بموضوع واحد) أو كان هناك عنصر نموذج بدون تسمية مرئية أو برمجية (وهو ما ستلتقطه 1.3.1 بدلًا من ذلك)، فإن 2.4.6 نفسها لا تنطبق. نطاق هذا المعيار يتعلق حصريًا بالوصفية، لا بالوجود.

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

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

يستخدم مستخدمو قارئات الشاشة — وهم أساسًا الأشخاص المكفوفون أو ذوو ضعف البصر الشديد — العناوين للتنقل بين أجزاء الصفحة بالقفز من عنوان إلى آخر باستخدام مفاتيح الاختصار (حرف H في NVDA/JAWS، وRotor في VoiceOver). إذا كانت العناوين غامضة أو مضللة، تنهار هذه الاستراتيجية في التنقل بالكامل. فالمستخدم الكفيف الذي يصل إلى بوابة خدمات حكومية تستخدم "Section A" و"Section B" و"Section C" كعناوين، سيضطر إلى قراءة كل كلمة في كل قسم بالتسلسل للعثور على ما يحتاجه، مما يلغي ميزة الكفاءة التي يفترض أن توفرها العناوين. ووفقًا لمنظمة الصحة العالمية، يعاني حوالي 2.2 مليار شخص حول العالم من شكل من أشكال ضعف البصر، ما يجعل هذه فئة سكانية عالمية كبيرة.

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

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

فكر في سيناريو واقعي: شخص يستخدم قارئ شاشة يزور صفحة الدفع في موقع تجارة إلكترونية. تحتوي الصفحة على ثلاثة أقسام للعناوين — عنوان الفواتير، وعنوان الشحن، وعنوان مستلم الهدية — لكن كل قسم يستخدم نفس العنوان العام "Address" وكل مجموعة من الحقول تستخدم نفس التسميات: "Street"، "City"، "Postal Code". بدون عناوين وتسميات فريدة ووصفية، لا يستطيع مستخدم قارئ الشاشة تحديد أي مجموعة من الحقول يقوم بملئها، مما يزيد بشكل كبير من خطر أخطاء الطلب واحتمال التخلي عن عملية الشراء بالكامل.

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

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

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

• مراجعة يدوية لنص العناوين: سيشير axe-core إلى العناوين المفقودة أو التداخل غير الصحيح (عبر قواعد مثل heading-order)، لكنه لا يستطيع الإشارة إلى عنوان مثل "Click Here" أو "Untitled Section" كخرق لمعيار 2.4.6. يجب على المختبر البشري قراءة كل عنوان بمعزل عن غيره — كما سيصادفه مستخدم قارئ الشاشة عند التنقل عبر العناوين — وتقييم ما إذا كان يوضح موضوع المحتوى الذي يليه.
• مراجعة يدوية لنص تسميات النماذج: تتحقق قاعدة label في axe-core من أن كل حقل إدخال في النموذج لديه تسمية مرتبطة به، لكنها لا تقيم ما إذا كان نص هذه التسمية وصفيًا. عنصر label يحتوي فقط على حرف نائب (placeholder) أو رمز أيقونة أو كلمة عامة مثل "Input" سيتجاوز الفحوصات الآلية بينما يظل مخالفًا لمعيار 2.4.6. تتطلب المراجعة اليدوية قراءة كل تسمية والتأكد من أنها تصف بدقة غرض عنصر التحكم المرتبط بها.
• مراجعة يدوية لقيم aria-label وaria-labelledby: وبالمثل، تؤكد مجموعة قواعد aria-label-is-accessible في axe-core أن تسميات ARIA صحيحة نحويًا وأن العناصر المشار إليها موجودة، لكنها لا تقيم ما إذا كان نص التسمية ذا معنى دلالي أو وصفيًا لغرض عنصر التحكم.
• اكتشاف التسميات المكررة: بينما يمكن لبعض الأدوات الإشارة إلى نصوص التسميات المكررة عبر الصفحة، فإنها لا تستطيع تحديد ما إذا كان التكرار مقصودًا ومناسبًا (حقلان لهما نفس الغرض في صفوف مختلفة من جدول) أو إخفاقًا حقيقيًا في الوصفية حيث تشترك عدة عناصر تحكم مختلفة في تسمية غامضة. تتطلب هذه التفرقة مراجعة يدوية.

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

1. تشغيل فحص آلي أولًا: استخدم axe DevTools (امتداد المتصفح) أو Lighthouse في Chrome DevTools لتحديد أي مشكلات بنيوية في العناوين أو التسميات يمكن للأدوات الآلية اكتشافها، مثل التسميات المفقودة، أو تخطي مستويات العناوين، أو عناصر العناوين الفارغة. رغم أن هذه ليست خروقات مباشرة لمعيار 2.4.6، إلا أنها تشير إلى مناطق يجب التدقيق فيها بعناية أكبر أثناء المراجعة اليدوية. دوّن كل عنوان وعنصر متحكم مُسمى تم الإشارة إليه أو تحديده في التقرير.
2. استخراج قائمة العناوين: استخدم امتداد متصفح مثل HeadingsMap (متوفر لـ Firefox وChrome) أو أداة WAVE لإنشاء قائمة مسطحة بجميع العناوين في الصفحة، منزوعة من محتواها المحيط. اقرأ هذه القائمة كما لو كانت جدول محتويات. اسأل نفسك: هل يمكن للمستخدم فهم بنية ومواضيع هذه الصفحة الرئيسية من العناوين وحدها، دون قراءة نص الجسم؟ إذا كان أي عنوان غامضًا أو غير مفيد عند قراءته بمعزل، فهو إخفاق في معيار 2.4.6.
3. الاختبار باستخدام NVDA وFirefox: افتح الصفحة واضغط على H للتنقل بين العناوين واحدًا تلو الآخر. استمع إلى الإعلان عن كل عنوان وقيّم ما إذا كان يصف المحتوى الذي يليه. ثم اضغط على F للتنقل بين حقول النماذج والاستماع إلى التسمية المعلنة لكل حقل إدخال. سجّل أي عنوان أو تسمية لا يصف بوضوح موضوعه أو غرضه.
4. الاختبار باستخدام VoiceOver وSafari (على macOS/iOS): استخدم Web Rotor (الأمر VO+U) لفتح قائمة العناوين وقائمة عناصر التحكم في النماذج. تنقل عبر كل قائمة وقيّم وصفية كل عنصر بشكل مستقل عن سياق الصفحة. على iOS، استخدم السحب بثلاثة أصابع للتنقل حسب العناوين في Rotor.
5. الاختبار باستخدام JAWS وChrome: اضغط على H للتنقل بين العناوين واستخدم وضع النماذج (Forms Mode) (المفتاح F) للتحرك بين عناصر التحكم في النماذج. استخدم مربع حوار قائمة العناوين في JAWS (Insert+F6) لعرض جميع العناوين في قائمة مسطحة، مما يحاكي طريقة مسح مستخدم قارئ الشاشة لبنية الصفحة.
6. تقييم تسميات النماذج بمعزل: لكل عنصر تحكم في نموذج، قم بتغطية أو تجاهل كل السياق المحيط واقرأ فقط التسمية البرمجية (نص التسمية المرئي، أو aria-label، أو الهدف المشار إليه في aria-labelledby). تأكد من أن التسمية وحدها كافية لفهم نوع المعلومات التي يجب إدخالها أو الإجراء الذي ينفذه عنصر التحكم.
7. التحقق من تكرار نص العناوين أو التسميات: ابحث في الصفحة عن نصوص عناوين مكررة (مثل عناوين "Read More" متعددة أو أقسام "Learn More" متعددة). إذا استُخدم نفس النص لعناوين أو تسميات تشير إلى مواضيع أو عناصر تحكم مختلفة، فهذا إخفاق في معيار 2.4.6.

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

عناوين أقسام عامة — غير صحيح

<section>
  <h2>Section 1</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Section 2</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

عناوين أقسام عامة — صحيح

<!-- Each heading now describes the actual topic of its section,
     enabling screen reader users to jump directly to what they need -->
<section>
  <h2>Enterprise Logistics Software Solutions</h2>
  <p>We offer a range of enterprise software solutions tailored for logistics companies.</p>
</section>
<section>
  <h2>Flexible User-Based Pricing</h2>
  <p>Our pricing is flexible and based on the number of active users.</p>
</section>

تسميات نماذج غامضة — غير صحيح

<!-- A checkout form with two address blocks, both using identical labels -->
<fieldset>
  <legend>Address</legend>
  <label for='street1'>Street</label>
  <input type='text' id='street1'>
  <label for='city1'>City</label>
  <input type='text' id='city1'>
</fieldset>
<fieldset>
  <legend>Address</legend>
  <label for='street2'>Street</label>
  <input type='text' id='street2'>
  <label for='city2'>City</label>
  <input type='text' id='city2'>
</fieldset>

تسميات نماذج غامضة — صحيح

<!-- Legends now distinguish the two fieldsets; labels remain short because
     the legend provides the distinguishing context programmatically -->
<fieldset>
  <legend>Billing Address</legend>
  <label for='billing-street'>Street</label>
  <input type='text' id='billing-street'>
  <label for='billing-city'>City</label>
  <input type='text' id='billing-city'>
</fieldset>
<fieldset>
  <legend>Shipping Address</legend>
  <label for='shipping-street'>Street</label>
  <input type='text' id='shipping-street'>
  <label for='shipping-city'>City</label>
  <input type='text' id='shipping-city'>
</fieldset>

تسمية ARIA غير وصفية على زر أيقونة — غير صحيح

<!-- aria-label provides a label but it does not describe the button's purpose -->
<button aria-label='button'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

تسمية ARIA غير وصفية على زر أيقونة — صحيح

<!-- aria-label now clearly communicates what activating the button will do -->
<button aria-label='Search products'>
  <svg aria-hidden='true' focusable='false'><!-- search icon --></svg>
</button>

عناوين أو روابط "Read More" مكررة — غير صحيح

<article>
  <h3>Latest News</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>Latest News</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

عناوين أو روابط "Read More" مكررة — صحيح

<!-- Each article has a unique, descriptive heading that identifies its topic -->
<article>
  <h3>Istanbul Metro Expands to Three New Districts</h3>
  <p>Istanbul metro expands to three new districts...</p>
</article>
<article>
  <h3>New Regulations Affect E-Commerce Platforms</h3>
  <p>New regulations affect e-commerce platforms...</p>
</article>

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

• استخدام عناوين موضعية أو ترتيبية مثل "Step 1" و"Step 2" و"Section A" دون أي نص وصفي: هذه العناوين تخبر المستخدم فقط بمكانه في التسلسل، لا بما يدور حوله القسم. احرص دائمًا على الجمع بين مؤشرات التسلسل وعبارة اسمية وصفية، مثل "Step 2: Verify Your Email Address".
• إعطاء جميع البطاقات أو مكونات المقالات في صفحة سرد نفس نص العنوان (مثل أن تحتوي كل بطاقة منتج على <h3> مكتوب فيه فقط "Product"): يجب أن يحدد عنوان كل بطاقة ذلك المنتج أو التدوينة أو العنصر المحدد بشكل فريد.
• استخدام نص العنصر النائب (placeholder) كالتسمية المتاحة لحقل نموذج (الاعتماد على خاصية placeholder بدلًا من عنصر <label> أو aria-label): تختفي نصوص placeholder عند الإدخال ولا تُعلن بشكل موثوق من جميع قارئات الشاشة كأسماء متاحة. حتى عند وجود placeholder، يلزم وجود تسمية وصفية منفصلة.
• كتابة aria-label يعيد فقط ذكر نوع العنصر بدلًا من غرضه، مثل aria-label='input' على حقل نصي أو aria-label='button' على زر: يجب أن تصف التسمية ما يفعله عنصر التحكم أو نوع القيمة التي يجمعها، لا نوع العنصر نفسه.
• استخدام نص تلميح (tooltip) أو خاصية title كتسمية وحيدة لعنصر نموذج وافتراض أن هذا يفي بمعيار 2.4.6: التسميات المعتمدة على title غالبًا ما تكون غير متاحة لمستخدمي لوحة المفاتيح فقط ولا تُعلن باستمرار من قارئات الشاشة. اعتمد بدلًا من ذلك على عناصر <label> مرئية أو aria-label.
• تسمية حقول البحث فقط بـ "Search" في صفحة تحتوي على عدة نطاقات بحث (مثل بحث على مستوى الموقع وبحث داخل جدول بيانات): عندما تنفذ أداتان بحثين مختلفين، يجب أن يحدد كل منهما النطاق، مثل "Search all products" و"Search within order history".
• تطبيق نفس نص العنوان على عنوان مربع حوار (modal) كما في العنوان الرئيسي للصفحة: يجب أن تصف عناوين النوافذ المنبثقة المهمة المحددة أو محتوى مربع الحوار (مثل "Confirm Your Cancellation") بدلًا من وراثة عنوان الصفحة، لأن ذلك سيكون مربكًا لمستخدمي قارئات الشاشة الذين يتنقلون داخل مربع الحوار.
• إهمال <legend> وصفي لمجموعات أزرار الاختيار أو مربعات الاختيار مع توفير تسميات للخيارات الفردية فقط: يوفر عنصر <legend> سياقًا أساسيًا يجعل كل تسمية فردية ذات معنى. "Yes" و"No" كتسميات خيارات مستقلة غير مفيدة دون legend مثل "Do you agree to the terms and conditions?".
• اقتطاع نص العنوان في الـ DOM لأسباب تصميمية بصرية (مثل عنوان يحتوي فقط على أيقونة أو كلمة واحدة لأن النص الكامل موجود في عناصر بصرية مجاورة): يجب أن يكون العنوان البرمجي وصفيًا بالكامل لأن مستخدمي قارئات الشاشة يسمعونه دون رؤية التخطيط البصري المحيط.
• الافتراض بأن التسمية المرئية للمستخدمين المبصرين تكون بالتالي وصفية بما يكفي لجميع المستخدمين: التسمية التي تعتمد على الموضع المكاني (مثل رأس عمود في شبكة مخصصة حيث يعتمد معنى التسمية على رؤية علاقتها بالخلايا المحيطة) قد تكون واضحة بصريًا لكنها تفشل في نقل نفس المعلومات برمجيًا. تحقق دائمًا من أن الاسم المتاح وحده كافٍ.

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

تضع التعميم الرئاسي 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، التزامات إلزامية لإمكانية الوصول الرقمي لمجموعة واسعة من الكيانات العامة والخاصة العاملة في تركيا. يشير التعميم صراحة إلى WCAG 2.1 مستوى AA كمعيار تقني للامتثال، كما أن متطلبات مستوى AA بموجب WCAG 2.2 — المتوافق رجعيًا مع WCAG 2.1 على مستوى AA — مشجعة بشدة ومطلوبة للكيانات التي تسعى للحصول على شعار إمكانية الوصول (Erişilebilirlik Logosu) الرسمي الصادر عن وزارة الأسرة والخدمات الاجتماعية (Aile ve Sosyal Hizmetler Bakanlığı).

تُعد WCAG 2.4.6 معيارًا من مستوى AA، ما يعني أنها تقع تمامًا ضمن نطاق ما يجب على الكيانات المشمولة معالجته لتحقيق الامتثال الكامل. تشمل أنواع الكيانات المشمولة بالتعميم الرئاسي: المؤسسات العامة والهيئات الحكومية؛ منصات التجارة الإلكترونية؛ البنوك والمؤسسات المالية؛ المستشفيات ومقدمو الرعاية الصحية؛ مشغلو الاتصالات الذين لديهم 200,000 مشترك أو أكثر؛ وكالات السفر؛ شركات النقل الخاصة؛ والمدارس الخاصة المرخصة من قبل وزارة التربية الوطنية (Millî Eğitim Bakanlığı).

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

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