WCAG 4.1.2: الاسم، الدور، القيمة

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

ماذا تعني هذه القاعدة

WCAG 4.1.2 — الاسم، الدور، القيمة هي معيار نجاح من المستوى A ضمن مبدأ المتانة (Robust). يتطلب هذا المعيار أنه لكل مكوّن من مكوّنات واجهة المستخدم — بما في ذلك عناصر النماذج، الأزرار، الروابط، الودجات المخصصة، الإطارات، وعناصر التحكم التفاعلية — يجب أن تتحقق الأمور الثلاثة التالية:

الاسم: يجب أن يكون لكل مكوّن اسم متاح يمكن لتقنيات المساعدة قراءته بصوت عالٍ أو عرضه عبر شاشة برايل. يمكن أن يأتي الاسم من محتوى العنصر (مثل النص داخل عنصر <button>)، أو من عنصر label، أو من خاصية aria-label، أو مرجع aria-labelledby، أو خاصية title.
الدور: يجب أن يكون لكل مكوّن دور يوضّح غرضه لتقنيات المساعدة. عناصر HTML الأصلية تحمل أدوارًا ضمنية (عنصر <button> له الدور button، وعنصر <input type='checkbox'> له الدور checkbox). الودجات المخصصة المبنية من عناصر عامة مثل <div> أو <span> يجب أن تصرّح عن دورها صراحة باستخدام خاصية ARIA role.
القيمة (الحالات والخصائص): أي حالة أو قيمة حالية ذات معنى للمستخدم — مثل ما إذا كان مربع الاختيار محددًا، أو ما إذا كان ودجت الكشف (disclosure) موسّعًا، أو ما إذا كان الحقل مطلوبًا — يجب أن تُكشف برمجيًا بحيث يمكن لتقنيات المساعدة الإبلاغ عنها، وبحيث يتمكن المستخدمون من تغييرها عند الاقتضاء.

يُعتبَر المكوّن مستوفيًا لهذا المعيار عندما يكون اسمه المتاح غير فارغ، ويكون دوره صالحًا وملائمًا دلاليًا، وتكون جميع الحالات ذات الصلة (مثل aria-checked، aria-expanded، أو aria-required) مطبّقة بشكل صحيح ومزامَنة مع واجهة المستخدم المرئية. ويُعتبَر المكوّن غير مستوفٍ عندما يكون أي من هذه العناصر الثلاثة غائبًا أو غير صحيح أو غير متزامن — على سبيل المثال، زر تبديل مخصص يغيّر لونه بصريًا لكنه لا يحدّث حالة aria-pressed الخاصة به أبدًا.

يغطي الاستثناء الرسمي في WCAG المكوّنات التي لا يتم كشفها عمدًا لواجهات برمجة تطبيقات إمكانية الوصول — مثل العناصر الزخرفية البحتة أو المحتوى المخفي باستخدام aria-hidden='true'. ومع ذلك، فإن إخفاء المحتوى النشط أو القابل للتركيز باستخدام aria-hidden (على سبيل المثال، تطبيقه على عنصر <body>) يُعد في حد ذاته انتهاكًا، لأنه يزيل كل محتوى الصفحة من شجرة إمكانية الوصول.

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

وفقًا لمنظمة الصحة العالمية، يعاني حوالي 2.2 مليار شخص حول العالم من شكل من أشكال ضعف البصر. بالنسبة للمستخدمين المكفوفين أو ضعاف البصر الذين يعتمدون على برامج قراءة الشاشة مثل JAWS أو NVDA أو VoiceOver، فإن الاسم والدور المتاحين لكل مكوّن تفاعلي هما الوسيلة الأساسية — وغالبًا الوحيدة — لفهم ما يفعله عنصر التحكم وكيفية استخدامه. إذا لم يكن للزر اسم متاح، فلن يسمع مستخدم قارئ الشاشة سوى كلمة "button" دون أي إشارة إلى غرضه. وإذا لم يكن لقائمة منسدلة مخصصة دور، فلن يتمكن المستخدم من تمييزها عن النص الثابت.

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

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

فكّر في سيناريو واقعي ملموس: منصة تجارة إلكترونية تركية تعرض زر "إضافة إلى السلة" مبنيًا كعنصر <div> مع معالج نقر وأيقونة عربة تسوق. يبدو بصريًا كزر. لكن لأنه يفتقر إلى role='button'، واسم متاح، وtabindex='0'، فإن مستخدم قارئ الشاشة الذي يتنقل عبر لوحة المفاتيح لا يصادف أي شيء — العنصر غير مرئي تمامًا لتقنيته المساعدة. لا يمكنه إضافة المنتجات إلى سلته، مما يستبعده فعليًا من تجربة التسوق بأكملها.

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

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

القواعد التالية في axe-core مرتبطة مباشرة بـ WCAG 4.1.2. تستهدف كل منها فئة محددة من إخفاقات الاسم أو الدور أو القيمة:

aria-allowed-attr: تتحقق من أن خصائص ARIA المطبقة على عنصر ما مسموح بها لدور ذلك العنصر. على سبيل المثال، تطبيق aria-checked على عنصر له role='link' غير صالح ويتم الإبلاغ عنه، لأن دور link لا يدعم aria-checked.
aria-command-name: تضمن أن العناصر ذات أدوار أوامر ARIA (link، button، menuitem) لها اسم متاح غير فارغ. زر يعتمد على أيقونة فقط بدون نص تسمية وبدون aria-label سيتم الإبلاغ عنه هنا.
aria-hidden-body: تشير إلى الحالة المحددة التي يتم فيها تطبيق aria-hidden='true' على عنصر <body>، مما يزيل الصفحة بأكملها من شجرة إمكانية الوصول ويجعل كل المحتوى غير مرئي لبرامج قراءة الشاشة.
aria-input-field-name: تتحقق من أن العناصر ذات أدوار إدخال ARIA (textbox، searchbox، spinbutton، slider، combobox) لها اسم متاح. حقل بحث مخصص مبني مع role='textbox' ولكن بدون تسمية سيتم الإبلاغ عنه.
aria-meter-name: تتحقق من أن العناصر ذات role='meter' لها اسم متاح، حتى يفهم مستخدمو قارئ الشاشة الكمية التي يقيسها المقياس (على سبيل المثال، استخدام التخزين أو مستوى البطارية).
aria-progressbar-name: تضمن أن العناصر ذات role='progressbar' تحمل اسمًا متاحًا، حتى يعرف المستخدمون أي عملية أو إجراء قيد التقدم بدلًا من سماع "progress bar" فقط.
aria-required-attr: تتحقق من أن العناصر التي تستخدم دور ARIA معيّن تتضمن جميع الخصائص المطلوبة في مواصفة ARIA لذلك الدور. على سبيل المثال، role='slider' يتطلب aria-valuenow وaria-valuemin وaria-valuemax؛ إهمال أي منها يتم الإبلاغ عنه.
aria-roles: تتحقق من أن جميع القيم المعطاة لخاصية role هي أدوار ARIA صالحة وغير مجردة. الأخطاء الإملائية، الأدوار المخترعة، أو الأدوار المجردة (مثل role='widget') المستخدمة مباشرة على العناصر يتم الإبلاغ عنها جميعًا.
aria-tooltip-name: تتحقق من أن العناصر ذات role='tooltip' لها اسم متاح. عنصر تلميح أداة (tooltip) فارغ لا يقدّم أي قيمة لمستخدمي قارئ الشاشة ويمثّل فشلًا في التسمية.
button-name: تتحقق من أن عناصر <button> والعناصر ذات role='button' لها اسم متاح غير فارغ. هذا يلتقط أزرار الأيقونات التي لا تحتوي على aria-label والأزرار الفارغة المستخدمة كمحفزات زخرفية.
frame-title: تتطلب أن يكون لعناصر <iframe> و<frame> خاصية title غير فارغة تصف محتوى الإطار. بدون ذلك، لا يمكن لمستخدمي قارئ الشاشة تحديد غرض المحتوى المضمَّن وقد لا يعرفون ما إذا كان ينبغي عليهم الدخول إلى الإطار أو تخطيه.
input-button-name: تتحقق من أن عناصر <input> من النوع submit وreset وbutton وimage لها اسم متاح — إما عبر خاصية value أو، في حالة مدخلات الصور، خاصية alt.

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

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

فحص آلي باستخدام axe DevTools أو Lighthouse: ثبّت إضافة المتصفح axe DevTools (Chrome أو Firefox) أو نفّذ تدقيق Lighthouse في أدوات مطوري Chrome ضمن تبويب Accessibility. فعّل فحص الصفحة بالكامل وفلتر النتائج حسب الوسم WCAG 4.1.2. ابحث تحديدًا عن انتهاكات button-name وframe-title وaria-required-attr وaria-roles وaria-input-field-name. كل نتيجة ستتضمن العنصر المخالف، ووصفًا للإخفاق، واقتراحًا للإصلاح. صدّر النتائج وأعطِ الأولوية أولًا للعناصر ذات الخطورة الحرجة (Critical) والخطيرة (Serious).
اختبار التنقل عبر لوحة المفاتيح: افصل الفأرة وتنقّل في الصفحة بالكامل باستخدام مفتاح Tab. تأكد من أن كل عنصر قابل للتركيز يحصل على مؤشر تركيز مرئي، وأن مؤشر التركيز الأصلي للمتصفح (أو مؤشر مخصص) واضح، وأنك تستطيع تفعيل جميع عناصر التحكم باستخدام Enter أو Space. أي عنصر تصل إليه ولا يمكنك التعرف عليه من السياق وحده — دون النظر إلى الشاشة — يشير على الأرجح إلى فشل في الاسم المتاح.
اختبار قارئ الشاشة باستخدام NVDA وFirefox: افتح NVDA (Windows، مجاني)، ثم افتح Firefox، وتنقّل في الصفحة باستخدام Tab للانتقال بين العناصر التفاعلية وقائمة عناصر NVDA (Insert+F7) لاستعراض جميع الأزرار والروابط وحقول النماذج. لكل عنصر تفاعلي، استمع لما يعلنه NVDA. يجب أن يقرأ اسم العنصر، ودوره، وأي حالة ذات صلة (مثل "Subscribe, button" أو "Email address, required, edit text"). سجّل أي عنصر يُعلَن بدون اسم أو بدور غير صحيح.
اختبار قارئ الشاشة باستخدام VoiceOver وSafari (macOS/iOS): فعّل VoiceOver (Command+F5 على macOS)، وافتح Safari، واستخدم VO+السهم الأيمن للتنقل بين العناصر. استخدم Rotor الخاص بـ VoiceOver (VO+U) لسرد جميع عناصر التحكم في النماذج والأزرار. تحقق من أن الأسماء وصفية، والأدوار ملائمة، وأن الحالات يتم تحديثها ديناميكيًا عند التفاعل (على سبيل المثال، يجب أن يؤدي تبديل أكورديون مخصص إلى إعلان "expanded" أو "collapsed").
اختبار قارئ الشاشة باستخدام JAWS وChrome: شغّل JAWS وافتح Chrome. استخدم مفتاح Tab للتنقل بين العناصر التفاعلية والمؤشر الافتراضي لـ JAWS (Insert+F3 للحصول على قائمة حقول النماذج) لمراجعة التسميات. أولِ اهتمامًا خاصًا للودجات المخصصة المبنية باستخدام ARIA — تأكد من أن تغيّرات الحالة الناتجة عن التفاعل عبر لوحة المفاتيح تنعكس في ما يعلنه JAWS في الوقت الفعلي.
التحقق من حالة الودجات المخصصة: لأي ودجت مخصص (أكورديون، لوحة تبويبات، combobox، نافذة منبثقة)، تفاعل معه بالكامل باستخدام لوحة المفاتيح فقط. في كل خطوة، تحقق من أن قارئ الشاشة يعلن عن تحديث الحالة الصحيح — على سبيل المثال، فتح ودجت الكشف يجب أن يؤدي إلى إعلان "expanded"، وإغلاقه يجب أن يؤدي إلى إعلان "collapsed". إذا تغيّرت الحالة بصريًا لكن قارئ الشاشة بقي صامتًا، فإن aria-expanded إما مفقودة أو لا يتم تبديلها برمجيًا.

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

زر يعتمد على أيقونة فقط بدون اسم متاح — غير صحيح

<!-- Icon button with no accessible name: screen readers announce only "button" -->
<button>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

زر يعتمد على أيقونة فقط بدون اسم متاح — صحيح

<!-- aria-label provides the accessible name when no visible text is present -->
<button aria-label='Search'>
  <svg aria-hidden='true' focusable='false'>
    <use href='#icon-search'></use>
  </svg>
</button>

ودجت تبديل مخصص بدون دور أو حالة — غير صحيح

<!-- A div used as a toggle: no role, no state, not keyboard accessible -->
<div class='toggle' onclick='toggleDarkMode()'>
  Dark Mode
</div>

ودجت تبديل مخصص بدون دور أو حالة — صحيح

<!-- role='switch' communicates purpose; aria-checked reflects current state;
     tabindex='0' makes it keyboard reachable; keydown handler enables Space/Enter -->
<div
  role='switch'
  aria-checked='false'
  tabindex='0'
  onclick='toggleDarkMode(this)'
  onkeydown='if(event.key==="Enter"||event.key===" "){toggleDarkMode(this);event.preventDefault();}'
>
  Dark Mode
</div>

<script>
function toggleDarkMode(el) {
  const isOn = el.getAttribute('aria-checked') === 'true';
  el.setAttribute('aria-checked', String(!isOn));
  document.body.classList.toggle('dark-mode', !isOn);
}
</script>

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

<!-- iframe with no title: screen reader users cannot determine what is inside -->
<iframe src='https://maps.example.com/embed?q=istanbul'></iframe>

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

<!-- title describes the frame's content so users can decide whether to enter it -->
<iframe
  src='https://maps.example.com/embed?q=istanbul'
  title='Interactive map showing our Istanbul office location'
></iframe>

شريط تقدم مخصص يفتقر إلى خصائص ARIA المطلوبة — غير صحيح

<!-- role='progressbar' without aria-valuenow, aria-valuemin, aria-valuemax:
     screen readers cannot determine the current progress -->
<div role='progressbar' style='width:60%'></div>

شريط تقدم مخصص يفتقر إلى خصائص ARIA المطلوبة — صحيح

<!-- All required attributes present; aria-label provides the accessible name -->
<div
  role='progressbar'
  aria-valuenow='60'
  aria-valuemin='0'
  aria-valuemax='100'
  aria-label='File upload progress'
>
  60%
</div>

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

استخدام role='button' على عنصر <div> بدون إضافة tabindex='0' — يصبح العنصر مُعلنًا كزر بواسطة برامج قراءة الشاشة لكنه يظل غير قابل للوصول عبر التنقل بمفتاح Tab، مما يجعله غير قابل للاستخدام لمستخدمي لوحة المفاتيح فقط.
تطبيق aria-label على عنصر غير تفاعلي — إضافة aria-label إلى عنصر <div> أو <span> بدون دور ليس لها أي تأثير؛ يتم تجاهل التسمية في معظم المتصفحات لأن العنصر لا يملك دورًا لتسمّيه.
ترك aria-expanded ثابتة بعد تنفيذ ودجت كشف — تعيين aria-expanded='false' في HTML وعدم تبديلها أبدًا باستخدام JavaScript يعني أن الخاصية تكون دائمًا خاطئة بعد أول نقرة، وتعلن الحالة المعاكسة لمستخدمي قارئ الشاشة.
استخدام aria-hidden='true' على حاوية تحتوي على عناصر قابلة للتركيز — هذا يخفي الحاوية من شجرة إمكانية الوصول لكن لا يخفيها عن تركيز لوحة المفاتيح، لذا يمكن لمستخدمي قارئ الشاشة الانتقال بمفتاح Tab إلى عناصر لا يمكنهم سماعها، مما يسبب ارتباكًا شديدًا.
توفير placeholder كالتسمية الوحيدة لعنصر <input> — نص placeholder يختفي عند الإدخال، ولا يتم الإعلان عنه بشكل موثوق كتسمية من جميع برامج قراءة الشاشة، ويفشل في تلبية متطلب الاسم المتاح لحقول النماذج.
استخدام دور ARIA غير صالح أو مجرد مثل role='widget' أو role='structure' — هذه أدوار أساسية في مواصفة ARIA وليست مخصصة للاستخدام المباشر؛ فهي لا توفر معلومات دلالية ذات معنى وقد يتم تجاهلها أو تسبب أخطاء في تقنيات المساعدة.
الإشارة إلى معرّف عنصر غير موجود في aria-labelledby — إذا لم يكن المعرّف المشار إليه بواسطة aria-labelledby موجودًا في DOM، تفشل عملية احتساب الاسم المتاح ويُترَك العنصر بدون اسم.
استخدام value بدلًا من aria-label لعنصر <input type='image'> — أزرار إدخال الصور تتطلب خاصية alt لاسمها المتاح؛ يتم تجاهل خاصية value في احتساب الاسم لمدخلات الصور.
إهمال خاصية title في عناصر <iframe> التي تحمّل محتوى من طرف ثالث — غالبًا ما يفترض المطورون أن التضمينات المعروفة (الخرائط، ودجات الدفع، مشغلات الفيديو) تشرح نفسها بنفسها، لكن يجب إخبار مستخدمي قارئ الشاشة بغرض الإطار قبل أن يقرروا ما إذا كانوا سيدخلونه أم لا.
نسيان تحديث الأسماء المتاحة ديناميكيًا عند تغيّر المحتوى — إذا تغيّرت تسمية زر بصريًا من "Play" إلى "Pause" لكن بقيت خاصية aria-label "Play"، يحصل مستخدمو قارئ الشاشة على معلومات غير صحيحة حول الحالة الحالية والإجراء.

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

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

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

تُعد WCAG 4.1.2 ذات أهمية خاصة للمنظمات التركية لأن العديد من المواقع التركية الحديثة تعتمد على مكوّنات تفاعلية مخصصة — مثل دوّارات المنتجات (carousels)، وأسئلة وأجوبة على شكل أكورديون، وتدفّقات الدفع خطوة بخطوة، ولوحات معلومات مصرفية — وغالبًا ما تُنفَّذ بدون أدوار ARIA صحيحة أو أسماء أو إدارة حالات مناسبة. زر دفع مخصص لا يملك اسمًا متاحًا، أو منزلق حاسبة قرض يفتقر إلى aria-valuenow، لا يمثل تجربة مستخدم سيئة فحسب: بل يشكّل، بموجب التعميم، إخفاقًا في الامتثال القانوني.

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

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