WCAG 1.3.3: الخصائص الحسية

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

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

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

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

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

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

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

لماذا يهم

تخلق التعليمات المعتمدة على الحواس فقط حواجز صعبة أمام مجموعة واسعة من المستخدمين. انظر إلى كل فئة متأثرة:

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

المستخدمون المصابون بعمى الألوان — ويؤثر على حوالي 1 من كل 12 رجلاً و1 من كل 200 امرأة — لا يمكنهم تمييز بعض أزواج الألوان. فتعليمات مثل "الحقول المظللة باللون الأحمر إلزامية" تكون غير مرئية كإشارة مميزة لشخص مصاب بعمى الألوان الأحمر-الأخضر. وبينما يتناول 1.4.1 هذا الأمر بالنسبة لعنصر واجهة المستخدم نفسه، يضمن 1.3.3 أن النص الإرشادي أيضاً يوفر بديلاً.

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

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

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

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

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

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

• مطلوب مراجعة يدوية — لا توجد قاعدة axe-core مخصصة لـ 1.3.3. قد تكشف قواعد axe-core مثل color-contrast وlabel عن مشكلات ذات صلة (على سبيل المثال، زر بدون اسم قابل للوصول)، لكنها تعالج معايير مختلفة. بالنسبة لـ 1.3.3، يجب على المختبِر البشري قراءة كل جملة إرشادية في الصفحة، وتحديد أي إشارات حسية (الشكل، اللون، الحجم، الموقع، الاتجاه، الصوت)، والتحقق من أن كل إشارة يصاحبها على الأقل معرّف واحد غير حسي. لن تضع الأدوات الآلية علامة على جملة مثل "انقر على الزر الأخضر أدناه" كخرق لأن تحليل نية اللغة الطبيعية يتجاوز قدرات الأتمتة القائمة على القواعد حالياً.
• لماذا تفشل الأتمتة هنا: ضع في الاعتبار أن "انقر على الزر الكبير" تحتوي على كلمة "زر"، والتي قد تفسرها أداة آلية على أنها تشير إلى دور قابل للوصول. لكن التعليمات لا تزال تعتمد فقط على الحجم ("الكبير") لتمييز هذا الزر عن غيره. لا يمكن للأدوات الآلية تحديد ما إذا كان "الكبير" هو السمة المميزة الوحيدة أو ما إذا كان هناك زر واحد فقط في الصفحة (مما يجعل "الكبير" زائداً لكنه غير ضار). الحكم البشري ضروري لتقييم هذه الفروق الدقيقة في السياق.
• قواعد axe المكمّلة التي يجب تشغيلها إلى جانب المراجعة اليدوية: سيساعد تشغيل فحوصات color-contrast وlabel وbutton-name وaria-label في ضمان أن عناصر واجهة المستخدم المشار إليها في التعليمات لديها بالفعل أسماء برمجية — وهو شرط أساسي لكتابة تعليمات غير حسية. فإذا لم يكن للزر اسم قابل للوصول، فلن تتمكن أي تعليمات من الإشارة إليه بشكل ذي معنى دون اللجوء إلى إشارات حسية.

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

1. تشغيل فحص آلي أولاً (axe DevTools أو Lighthouse): افتح الصفحة في Chrome، فعّل إضافة axe DevTools، وشغّل فحصاً لكامل الصفحة. رغم عدم وجود قاعدة تطابق مباشرة 1.3.3، راجع أي مشكلات تم الإبلاغ عنها ضمن فئات "color" و"label" و"name". توفر هذه النتائج خط أساس — فإذا كانت عناصر واجهة المستخدم تفتقر إلى أسماء قابلة للوصول، فمن شبه المؤكد أن النص الإرشادي الذي يشير إليها يعتمد على إشارات حسية. صدّر النتائج وسجّل جميع العناصر التفاعلية التي لا تحتوي على تسميات برمجية.
2. تحديد كل النصوص الإرشادية يدوياً: اقرأ كل جملة في الصفحة توجّه المستخدم لاتخاذ إجراء أو تحديد موقع معلومات. يشمل ذلك نصوص المساعدة، وتلميحات النماذج، وتلميحات الأدوات، وطبقات الشرح، ورسائل الخطأ، وتدفقات الإعداد الأولي. أنشئ قائمة بكل تعليمات وميّز أي إشارات حسية: كلمات اللون (أحمر، أزرق، أخضر)، كلمات الشكل (دائري، مربع، مثلث)، كلمات الحجم (كبير، صغير، ضخم)، كلمات الموضع (يسار، يمين، أعلى، أسفل، فوق، تحت، زاوية)، كلمات الاتجاه (أفقي، عمودي)، وإشارات الصوت (رنين، صفير، صوت تنبيه).
3. تقييم كل إشارة حسية بحثاً عن معرّفات إضافية غير حسية: لكل إشارة حسية تم العثور عليها، حدد ما إذا كان هناك معرّف غير حسي موجود أيضاً. يشمل المعرّف غير الحسي تسمية نصية تطابق التسمية المرئية للعنصر أو اسمه القابل للوصول، أو عنواناً، أو خطوة مرقمة، أو دوراً برمجياً فريداً، أو تسمية ARIA. إذا كانت الطريقة الوحيدة لتحديد العنصر المشار إليه هي الإدراك الحسي، فإن التعليمات تفشل 1.3.3.
4. الاختبار باستخدام قارئ الشاشة (NVDA + Firefox): تنقّل في الصفحة باستخدام لوحة المفاتيح فقط وNVDA. انتقل بين جميع العناصر التفاعلية باستخدام Tab واستمع إلى كيفية إعلان NVDA لكل عنصر. ثم اقرأ النصوص الإرشادية في الصفحة واسأل: هل يمكن لمستخدم يسمع هذه الإعلانات فقط أن يتبع التعليمات؟ إذا قالت التعليمات "انقر على الأيقونة على اليمين" لكن NVDA يعلن العنصر كـ "Settings، زر"، فإن المرجع الموضعي يصبح ثانوياً لكن التسمية تجعل التعليمات قابلة للتنفيذ. إذا أعلن NVDA العنصر كـ "زر" بدون اسم، فإن التعليمات التي تعتمد على الموقع البصري تفشل تماماً.
5. الاختبار باستخدام VoiceOver + Safari (macOS/iOS): فعّل VoiceOver وتنقّل في الصفحة. استخدم الـ rotor للتصفح حسب الأزرار والروابط وعناصر النماذج. تحقق من أن كل عنصر مشار إليه في تعليمات يمكن الوصول إليه والتعرف عليه من خلال اسمه المعلن فقط، دون الاعتماد على موقعه في التخطيط البصري.
6. الاختبار باستخدام JAWS + Chrome: افتح الصفحة في Chrome مع تفعيل JAWS. استخدم وضع Forms Mode للتنقل بين الحقول والاستماع إلى إعلانات الحقول. قارن ذلك مع أي تعليمات على مستوى النموذج تستخدم اللون أو الموضع للإشارة إلى الحقول المطلوبة.
7. الاختبار في أوضاع التباين العالي والوضع الداكن: غيّر نظام التشغيل إلى وضع التباين العالي وأعد تحميل الصفحة. قد تصبح التعليمات المشفرة بالألوان التي تشير إلى ألوان محددة غامضة أو غير مرئية عندما يتغير عرض الألوان. يساعد هذا في كشف الاعتماد الخفي على اللون كإشارة حسية وحيدة.
8. الاختبار في عرض محمول مكبّر أو معاد التدفق: غيّر حجم نافذة المتصفح إلى عرض 320px أو استخدم جهازاً محمولاً. يجب أن تظل التعليمات التي تستخدم لغة موضعية مثل "الشريط الجانبي الأيسر" أو "التنقل العلوي" ذات معنى عندما يعاد تدفق التخطيط إلى عمود واحد.

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

تعليمات حقول النموذج المعتمدة على اللون فقط — غير صحيحة

<p>Fields shown in red are required.</p>
<label for='email'>Email Address</label>
<input type='email' id='email' style='border-color: red;' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

تعليمات حقول النموذج المعتمدة على اللون فقط — صحيحة

<!-- The instruction now uses a text marker AND color, not color alone.
     The asterisk and the word "required" provide non-sensory identification. -->
<p>Fields marked with an asterisk (*) are required.</p>
<label for='email'>Email Address <span aria-hidden='true'>*</span></label>
<input type='email' id='email' aria-required='true' />
<label for='phone'>Phone Number</label>
<input type='tel' id='phone' />

مرجع موضعي للزر — غير صحيح

<p>To save your work, click the button on the right side of the toolbar.</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

مرجع موضعي للزر — صحيح

<!-- The instruction now references the button by its visible text label "Save",
     which matches the button's accessible name. Position is still mentioned
     but is no longer the sole identifier. -->
<p>To save your work, click the <strong>Save</strong> button (located on the right side of the toolbar).</p>
<div class='toolbar'>
  <button type='button'>Undo</button>
  <button type='button'>Redo</button>
  <button type='button'>Save</button>
</div>

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

<p>Tap the circular icon to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

تنقل بأيقونة معتمدة على الشكل فقط — صحيح

<!-- The button now has an accessible name via aria-label.
     The instruction references "Home" by name, not just by shape. -->
<p>Tap the <strong>Home</strong> button (the circular icon) to return to the home screen.</p>
<nav>
  <button type='button' class='icon-home' aria-label='Home'>
    <img src='home-circle.svg' alt='' />
  </button>
</nav>

إشارة تقدم صوتية فقط — غير صحيحة

<p>Listen for the beep to know when the upload is complete.</p>
<button type='button' id='upload-btn'>Upload File</button>
<audio id='complete-chime' src='chime.mp3'></audio>

إشارة تقدم صوتية فقط — صحيحة

<!-- A visible and screen-reader-accessible status message supplements the audio cue.
     Deaf users and users in silent environments now receive the same information. -->
<p>When the upload is complete, you will hear a chime and a <strong>"Upload Complete"</strong> message will appear below.</p>
<button type='button' id='upload-btn'>Upload File</button>
<div role='status' aria-live='polite' id='upload-status'></div>
<audio id='complete-chime' src='chime.mp3'></audio>
<!-- JavaScript sets #upload-status text to "Upload Complete" on success -->

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

• كتابة "الزر الأحمر" أو "الحقل الأخضر" كمعرّف وحيد في تعليمات النماذج أو نصوص المساعدة، دون تقديم التسمية المرئية للزر أو اسم الحقل — وهذا يفشل كلّاً من 1.3.3 و1.4.1.
• استخدام عبارات موضعية مثل "القائمة على اليسار" أو "اللوحة في الأعلى" في وثائق المساعدة أو تدفقات الإعداد الأولي دون تسمية القائمة أو اللوحة، مما يجعل التعليمات عديمة الفائدة بعد أن يؤدي إعادة التدفق المتجاوب إلى طي التخطيط في عمود واحد.
• وصف الأيقونات بالشكل فقط ("انقر على زر التشغيل المثلث") بدلاً من استخدام الاسم أو التسمية القابلة للوصول للأيقونة، والتي يمكن لمستخدم قارئ الشاشة تحديدها فعلياً عبر التنقل بلوحة المفاتيح.
• الإشارة إلى الحقول المطلوبة حصرياً من خلال لون الحدود أو لون الخلفية في التعليمات المضمنة ("يجب ملء الحقول البرتقالية") دون رمز أو لاحقة تسمية أو خاصية aria-required='true' لنقل نفس المعلومات برمجياً.
• وضع تغذية راجعة صوتية فقط للعمليات التفاعلية (تحميل الملفات، إرسال النماذج، انتهاء المؤقت) دون تحديث حالة نصي مرئي مقابل باستخدام role='status' أو aria-live='polite'.
• استخدام الحجم كإشارة تمييز وحيدة — التعليمات مثل "انقر على البطاقة الكبيرة للتوسيع" تفشل عندما يقوم المستخدم بالتكبير، أو عندما تُعرض البطاقات بأحجام متطابقة في عروض أصغر، أو عندما لا يملك مستخدم قارئ الشاشة أي مفهوم عن أحجام البطاقات النسبية في DOM.
• الاعتماد على إشارات الاتجاه مثل "اسحب أفقياً للتنقل" دون توفير طريقة تفاعل بديلة وتسمية غير معتمدة على الاتجاه للكاروسيل أو شريط التمرير الموصوف.
• نسيان أن رسائل الخطأ هي أيضاً تعليمات — فخطأ يقول "الحقول المظللة أدناه تحتوي على أخطاء" يعتمد على التمييز البصري والقرب الموضعي، وسيكون عديم الفائدة لمستخدم قارئ الشاشة ما لم يتم أيضاً تسمية كل حقل خاطئ صراحة في رسالة الخطأ.
• افتراض أن إضافة نص بديل للأيقونة يحل المشكلة — إذا كان النص الإرشادي لا يزال يقول فقط "انقر على الأيقونة الدائرية"، فإن وجود نص بديل على عنصر الصورة لا يجعل النص الإرشادي متوافقاً؛ يجب أن يتضمن النص نفسه معرّفاً غير حسي.
• إهمال التعليمات المحقونة ديناميكياً في التطبيقات أحادية الصفحة — غالباً ما تحتوي تلميحات الأدوات والنوافذ المنبثقة وخطوات المعالج التي يتم حقنها عبر JavaScript على إرشادات حسية فقط تفلت من مراجعة ضمان الجودة لأنها غير مرئية في تدقيق صفحة ثابتة.

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

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

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

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

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