WCAG 1.3.1: المعلومات والعلاقات

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

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

ينطبق هذا المعيار على ثلاث فئات من المعاني التي تنقلها محتويات الويب عادةً من خلال العرض:

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

تجتاز الصفحة المعيار 1.3.1 عندما تكون كل معلومة بنيوية أو علائقية متاحة للمستخدم المبصر مُشفَّرة إما في HTML دلالي صحيح أو مكشوفة من خلال دور أو خاصية أو حالة ARIA صحيحة يمكن لتقنيات المساعدة تفسيرها. وتفشل الصفحة عندما تكون البنية البصرية موجودة فقط في CSS أو الصور، أو عندما تتعارض وسمات ARIA مع بنية DOM المعروضة أو تكون غائبة عنها.

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

لماذا يهم

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

مستخدمو قارئات الشاشة — وهم عادةً من الأشخاص المكفوفين أو ضعاف البصر — يتنقلون في الصفحات عن طريق استعلام شجرة الإتاحة (accessibility tree)، والتي تُبنى من HTML الدلالي وARIA. عندما يستخدم المطوّر عنصر <div> مُنسَّقًا ليبدو كعنوان بدلًا من استخدام عنصر <h2> فعلي، فإن مستخدم قارئ الشاشة الذي يقفز بين العناوين باستخدام مفتاح H سيتجاوز هذا العنوان تمامًا. وقد لا يعثر أبدًا على القسم الذي يقدمه. ووفقًا لمنظمة الصحة العالمية، يعيش حوالي 2.2 مليار شخص حول العالم مع شكل من أشكال ضعف البصر، ويعتمد عشرات الملايين منهم على قارئات الشاشة يوميًا.

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

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

فكّر في سيناريو ملموس: بوابة مرضى في مستشفى تعرض جدولًا بالمواعيد القادمة. يستخدم الجدول المحاذاة البصرية ولون الخلفية لربط التواريخ بالأطباء، لكن عناصر <th> تفتقر إلى خاصية scope وخلايا البيانات لا تشير إلى الرؤوس. يسمع المستخدم الكفيف الذي يستخدم قارئ شاشة قيم خلايا معزولة — "9:00 AM"، "Dr. Ayşe Kaya"، "Cardiology" — دون أي طريقة لمعرفة أي قيمة تنتمي إلى أي عمود. قد يسيء قراءة وقت موعده أو يحضر إلى القسم الخطأ. كان الاستخدام الصحيح لـscope='col' على الرؤوس وسمات headers على الخلايا سيجعل هذه العلاقات مسموعة.

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

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

تتطابق قواعد axe-core التالية مباشرة مع انتهاكات المعيار WCAG 1.3.1. تستهدف كل قاعدة جانبًا محددًا من البنية أو العلاقة البرمجية:

• aria-required-children — تتحقق من أن العناصر ذات أدوار ARIA معينة تحتوي على أدوار الأبناء المطلوبة. على سبيل المثال، يجب أن يحتوي عنصر role='list' على أبناء ذوي role='listitem'. بدون بنية الأبناء الصحيحة، تنكسر العلاقة بين الحاوية وعناصرها بالنسبة لتقنيات المساعدة.
• aria-required-parent — عكس القاعدة السابقة: تتحقق من أن العناصر ذات الأدوار التي تتطلب سياق أب محدد لديها بالفعل هذا الأب. يتم الإبلاغ عن عنصر role='listitem' غير الموجود داخل role='list' أو <ul>/<ol> لأن سياق العلاقة مفقود.
• aria-roles — تتحقق من أن جميع قيم سمة role هي أدوار ARIA صالحة. فالدور غير الصالح أو المكتوب بشكل خاطئ (مثل role='heading' بدلًا من استخدام عنصر عنوان فعلي، أو دور مختلق بالكامل) يعني أن تقنية المساعدة لا تتلقى أي معلومات مفيدة وقد تتجاهل العنصر تمامًا.
• definition-list — تتحقق من أن عناصر <dl> تحتوي فقط على الأبناء المسموح بهم: <dt>، <dd>، <div>، <script>، و<template>. إدخال عناصر أخرى مثل <p> مباشرة داخل <dl> يبطل بنية علاقة المصطلح-التعريف.
• dlitem — تتحقق من أن عناصر <dt> و<dd> تُستخدم فقط داخل عناصر <dl>. استخدام هذه العناصر خارج سياق الأب المطلوب يدمر المعنى الدلالي لزوج المصطلح-التعريف.
• heading-order — تشير إلى مستويات العناوين التي يتم تخطيها في مخطط المستند (مثل القفز من <h2> إلى <h4>). ورغم أن ذلك ليس دائمًا فشلًا صارمًا، فإن تخطي المستويات يضلل تقنيات المساعدة بشأن البنية الهرمية للصفحة ويُربك المستخدمين الذين يتنقلون عبر العناوين.
• label — تتحقق من أن كل عنصر إدخال في نموذج لديه تسمية مرتبطة برمجيًا، إما عبر <label for='...'> أو aria-label أو aria-labelledby أو عنصر <label> يحيط به. عنصر إدخال بدون تسمية متاحة يحرم المستخدمين المكفوفين ومستخدمي التحكم الصوتي من المعلومات التي يحتاجونها لفهم ما يجب إدخاله.
• list — تضمن أن عناصر <ul> و<ol> تحتوي فقط على عناصر <li> كأبناء مباشرين (إضافة إلى <script> و<template>). العناصر الأبناء غير الصالحة تكسر بنية القائمة التي تستخدمها قارئات الشاشة للإعلان عن عدد العناصر ومواقعها.
• listitem — تتحقق من أن عناصر <li> تُستخدم فقط داخل حاويات <ul> أو <ol> أو role='list'. عناصر القائمة اليتيمة تفقد معناها الدلالي بالكامل.
• scope-attr-valid — تتحقق من أن سمة scope على عناصر <th> تحتوي فقط على القيم المسموح بها: col أو row أو colgroup أو rowgroup. القيمة غير الصالحة أو الغائبة لـscope في جدول بيانات معقد تعني أن قارئات الشاشة لا يمكنها الإعلان بشكل موثوق عن الرأس الذي ينطبق على خلية بيانات معينة.
• td-headers-attr — تتحقق من أنه عندما تستخدم خلايا البيانات سمة headers، فإن كل معرّف (ID) مشار إليه موجود بالفعل في الجدول نفسه وينتمي إلى خلية رأس. المراجع المكسورة أو المفقودة تقطع العلاقة البرمجية بين البيانات ورأسها الوصفي، تاركة مستخدمي قارئات الشاشة بدون سياق.

لاحظ أن الأدوات الآلية مثل axe-core لا يمكنها اكتشاف كل انتهاك للمعيار 1.3.1. على سبيل المثال، قد يستخدم مطوّر عنصر <div> منسقًا بصريًا مع role='list' وعناصر أبناء ذات role='listitem' مُهيكلة بشكل صحيح — سيتجاوز axe هذا — لكن قد يكتشف مختبر بشري أن المسافة البادئة البصرية توحي بقائمة فرعية متداخلة غير ممثلة في بنية ARIA. كلما كانت البنية الهرمية البصرية معقدة، يصبح الفحص اليدوي واختبار قارئات الشاشة مكملين أساسيين للفحص الآلي.

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

1. فحص آلي باستخدام axe DevTools أو Lighthouse: ثبّت إضافة المتصفح axe DevTools (Chrome أو Firefox). افتح الصفحة قيد الاختبار، وافتح أدوات المطوّرين، وانتقل إلى تبويب axe، ثم نفّذ فحصًا كاملًا للصفحة. رشّح النتائج باستخدام الوسم wcag131 أو راجع جميع المشكلات الموسومة تحت "Info and Relationships". ابحث تحديدًا عن انتهاكات قواعد axe الإحدى عشرة المذكورة أعلاه. في Lighthouse (لوحة Audits في Chrome DevTools)، نفّذ تدقيقًا لإمكانية الوصول وتحقق من فئة "Accessibility" بحثًا عن الإخفاقات المتعلقة بترتيب العناوين والتسميات والقوائم. دوّن جميع العناصر المُشار إليها ومحددات DOM الخاصة بها للمعالجة.
2. مراجعة يدوية لبنية العناوين: استخدم إضافة المتصفح HeadingsMap أو لوحة "Headings" في axe DevTools لعرض مخطط العناوين الكامل للصفحة. تحقق من أن المخطط منطقي وهرمي — يجب أن يقرأ مثل جدول محتويات منظم جيدًا. تأكد من عدم تخطي مستويات العناوين وأن نص العناوين ذو معنى وليس مجرد تنسيق بصري مطبق على عناصر ليست عناوين.
3. التحقق من تسميات النماذج: تنقّل باستخدام مفتاح Tab عبر كل عنصر تفاعلي في النماذج على الصفحة. لكل عنصر input وselect وtextarea، تأكد من وجود تسمية مرئية وأنها مرتبطة برمجيًا (افحص العنصر في DevTools وابحث عن زوج for/id مطابق، أو aria-label/aria-labelledby). استخدم شجرة الإتاحة في Chrome DevTools (لوحة Elements → تبويب Accessibility) لتأكيد الاسم المتاح المحسوب لكل عنصر تحكم.
4. اختبار قارئ الشاشة باستخدام NVDA + Firefox: شغّل NVDA وافتح الصفحة في Firefox. اضغط H للتنقل بين العناوين وتحقق من أن مستويات العناوين المُعلنة تطابق البنية الهرمية البصرية. اضغط F للانتقال بين حقول النماذج وتأكد من الإعلان عن تسمية كل حقل. اضغط T للتنقل بين الجداول وتحرك بين الخلايا باستخدام الأسهم، واستمع إلى إعلانات الرؤوس. اضغط L للتنقل بين القوائم وتأكد من الإعلان عن عدد العناصر.
5. اختبار قارئ الشاشة باستخدام VoiceOver + Safari (macOS/iOS): فعّل VoiceOver (Cmd+F5 على macOS). افتح Rotor (Ctrl+Option+U) وتفقد العناوين والروابط وعناصر التحكم في النماذج والجداول. تأكد من أن جميع العناصر البنيوية تظهر في Rotor وأن الأسماء المُعلنة لها ذات معنى ودقة.
6. اختبار قارئ الشاشة باستخدام JAWS + Chrome: افتح JAWS والصفحة في Chrome. استخدم قائمة العناوين في JAWS (Insert+F6) لمراجعة شجرة العناوين. استخدم Insert+F5 لحقول النماذج للتحقق من ارتباط التسميات. تنقّل في الجداول باستخدام مفاتيح الأسهم وتأكد من أن JAWS يعلن عن رؤوس الأعمدة والصفوف لكل خلية بيانات.
7. التحقق من علاقة رؤوس الجداول: حدد جميع جداول البيانات في الصفحة. في الجداول البسيطة، تحقق من أن عناصر <th> تحتوي على سمات scope المناسبة. في الجداول المعقدة ذات الرؤوس متعددة المستويات، تحقق من أن خلايا البيانات تستخدم سمة headers مع الإشارة إلى قيم id الصحيحة. تتبّع بصريًا كل خلية إلى رؤوس الصفوف والأعمدة المنطقية الخاصة بها، ثم تأكد من تمثيل المسار نفسه في الشيفرة.

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

عناوين بصرية مُنفَّذة كعناصر div منسقة — غير صحيح

<!-- Heading conveyed only through CSS font-size and font-weight -->
<div class='section-title'>Our Services</div>
<div class='subsection-title'>Web Development</div>
<p>We build fast, accessible websites.</p>

عناوين بصرية مُنفَّذة كعناصر div منسقة — صحيح

<!-- Semantic heading elements expose hierarchy to assistive technologies -->
<h2>Our Services</h2>
<h3>Web Development</h3>
<p>We build fast, accessible websites.</p>

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

<!-- The placeholder is not a substitute for a label; it disappears on input -->
<p>Email Address *</p>
<input type='email' placeholder='Enter your email' />

حقل نموذج بدون تسمية مرتبطة — صحيح

<!-- The for attribute ties the label to the input by matching id -->
<label for='email'>Email Address <span aria-hidden='true'>*</span><span class='sr-only'>(required)</span></label>
<input type='email' id='email' aria-required='true' />

جدول بيانات بدون سمات scope — غير صحيح

<!-- Headers have no scope; screen readers cannot associate columns with data -->
<table>
  <tr>
    <th>Tarih</th>
    <th>Doktor</th>
    <th>Klinik</th>
  </tr>
  <tr>
    <td>15 Temmuz 2025</td>
    <td>Dr. Ayşe Kaya</td>
    <td>Kardiyoloji</td>
  </tr>
</table>

جدول بيانات بدون سمات scope — صحيح

<!-- scope='col' tells screen readers each th describes its entire column -->
<table>
  <caption>Yaklaşan Randevular</caption>
  <thead>
    <tr>
      <th scope='col'>Tarih</th>
      <th scope='col'>Doktor</th>
      <th scope='col'>Klinik</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>15 Temmuz 2025</td>
      <td>Dr. Ayşe Kaya</td>
      <td>Kardiyoloji</td>
    </tr>
  </tbody>
</table>

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

<!-- li elements without a parent ul or ol have no semantic meaning -->
<div class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</div>

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

<!-- Wrapping ul gives screen readers item count and navigation context -->
<ul class='features'>
  <li>Fast performance</li>
  <li>WCAG compliant</li>
  <li>Mobile friendly</li>
</ul>

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

• استخدام خصائص CSS مثل font-size وfont-weight وحدها لإنشاء المظهر البصري للعناوين على عناصر <div> أو <span>، دون إضافة role='heading' وaria-level أو تحويلها إلى عناصر عناوين فعلية <h1>–<h6> — لا يمكن لقارئات الشاشة اكتشاف هذه العناصر كعناوين قابلة للتنقل.
• استخدام نص placeholder كالتسمية الوحيدة لعناصر إدخال النماذج، مما يؤدي إلى اختفاء التسمية بمجرد أن يبدأ المستخدم في الكتابة، تاركًا الحقل بدون تسمية طوال فترة الإدخال — يجب دائمًا إقران عناصر الإدخال بعنصر <label> ثابت.
• تمييز الحقول المطلوبة بنجمة حمراء (*) يتم شرحها فقط في مفتاح بصري أعلى النموذج، دون إضافة aria-required='true' أو تضمين كلمة "مطلوب" في التسمية البرمجية بحيث يتلقى مستخدمو قارئات الشاشة المعلومات نفسها.
• تطبيق list-style: none عبر CSS على عنصر <ul> دون فهم أن بعض قارئات الشاشة (خصوصًا Safari + VoiceOver) قد تتوقف عندها عن الإعلان عن العنصر كقائمة — إذا كانت دلالات القائمة ذات معنى، أضف role='list' صراحة للحفاظ عليها.
• تخطي مستويات العناوين — على سبيل المثال، وضع عنصر <h4> مباشرة بعد <h2> لأن المصمم أراد نصًا أصغر — بدلًا من استخدام مستوى العنوان الصحيح والتحكم في المظهر البصري عبر CSS.
• بناء جداول بيانات معقدة بخلايا مدمجة (colspan/rowspan) دون إضافة سمة headers على خلايا البيانات، مما يترك مستخدمي قارئات الشاشة غير قادرين على تحديد أي رأس يحكم خلية مدمجة غامضة.
• استخدام عناصر <table> لأغراض التخطيط ثم إضافة role='presentation' بشكل غير متسق — بعض الخلايا لا تزال تحتوي على رؤوس يتم الإعلان عنها خارج سياقها، مما يربك المستخدمين الذين لا يمكنهم رؤية أن الجدول زخرفي بحت.
• تغليف زوج <dt>/<dd> داخل عنصر <p> أو <div> يكون ابنًا مباشرًا لعنصر <dl> دون فهم أن أغلفة <div> فقط هي المسموح بها داخل <dl> في HTML5، وأن خلط عناصر الكتلة الأخرى يدمر بنية قائمة التعاريف.
• إضافة aria-labelledby على عنصر إدخال يشير إلى معرّف (ID) غير موجود في DOM، أو يشير إلى معرّف عنصر غير نصي — يصبح الاسم المتاح المحسوب فارغًا ويُعتبر عنصر الإدخال فعليًا بدون تسمية بالنسبة لتقنيات المساعدة.
• الافتراض بأنه لمجرد أن الصفحة تبدو صحيحة بصريًا وتحصل على درجة Lighthouse أعلى من 90، فهي متوافقة مع المعيار 1.3.1 — لا يمكن للأدوات الآلية اكتشاف كل انتهاك بنيوي، مثل علاقات التداخل البصرية غير المنعكسة في تسلسل أدوار ARIA، مما يجعل التحقق اليدوي واختبار قارئات الشاشة أمرين إلزاميين.

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

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

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

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

لأغراض الامتثال العملي، يُعد المعيار 1.3.1 واحدًا من أكثر معايير المستوى A تأثيرًا لأنه يحكم بنية الصفحة الأساسية. فموقع تجارة إلكترونية تركي تستخدم صفحات فئات المنتجات فيه عناصر <div> منسقة كعناوين، وتفتقر حقول نموذج الدفع فيه إلى ارتباطات التسميات، أو يكون ملخص الطلب فيه جدولًا غير منظم بدون سمات scope، سيفشل المعيار 1.3.1 بشكل شامل. المعالجة ليست مجرد التزام قانوني — بل تحسن مباشرة تجربة ما يُقدّر بـ700,000 أو أكثر من الأشخاص المكفوفين وضعاف البصر في تركيا الذين يعتمدون على تقنيات المساعدة للتسوق، وإجراء المعاملات البنكية، والوصول إلى الرعاية الصحية، والتفاعل مع الخدمات الحكومية عبر الإنترنت.

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