WCAG 2.1.1: لوحة المفاتيح

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

تنص WCAG 2.1.1 (لوحة المفاتيح) على أن كل جزء من الوظائف في صفحة ويب أو تطبيق يجب أن يكون قابلاً للتشغيل باستخدام واجهة لوحة المفاتيح. هذا يعني أنه إذا كان بإمكان المستخدم النقر على زر، أو سحب عنصر، أو التحويم لإظهار قائمة، أو التفاعل مع أي عنصر آخر باستخدام الفأرة، فيجب أن يكون قادرًا على تنفيذ نفس الإجراء تمامًا باستخدام إدخالات لوحة المفاتيح فقط — عادةً مفاتيح Tab وShift+Tab وEnter وSpace ومفاتيح الأسهم.

ينطبق هذا المعيار على جميع العناصر التفاعلية: الروابط، الأزرار، عناصر النماذج، الودجات المخصصة، مربعات الحوار النمطية (modal dialogs)، القوائم المنسدلة، الأكورديونات، السلايدر (carousels)، منتقيات التاريخ، واجهات السحب والإفلات، التفاعلات المبنية على canvas، وأي مكوّن آخر يستجيب لإدخال المستخدم. إذا كان المحتوى يتطلب من المستخدم تنفيذ مسار رسم (حيث يكون المسار نفسه هو الإدخال، وليس مجرد نقطة النهاية)، فهذا هو الاستثناء الرسمي الوحيد المعترف به في WCAG. خارج هذا الاستثناء الضيق، يجب أن تكون كل وظيفة أخرى قابلة للوصول عبر لوحة المفاتيح.

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

من المهم التمييز بين WCAG 2.1.1 وWCAG 2.1.2 (عدم وجود فخ لوحة مفاتيح). يضمن المعيار 2.1.1 أن مستخدمي لوحة المفاتيح يمكنهم الوصول إلى كل شيء واستخدامه؛ بينما يضمن المعيار 2.1.2 أن مستخدمي لوحة المفاتيح لن يكونوا أبدًا محاصرين داخل مكوّن. يجب استيفاء كلاهما لتحقيق الامتثال الكامل لمستوى A.

لماذا يهم ذلك

إتاحة الوصول عبر لوحة المفاتيح ليست مسألة هامشية. يُقدَّر أن 1 من كل 4 بالغين في الولايات المتحدة يعيش مع شكل من أشكال الإعاقة، وأن الإعاقات الحركية — بما في ذلك حالات مثل مرض باركنسون، والتصلب المتعدد، وإصابات الحبل الشوكي، وإصابات الإجهاد المتكرر (RSI)، واختلافات الأطراف، والارتعاش — غالبًا ما تمنع المستخدمين من تشغيل فأرة قياسية أو شاشة لمس. يعتمد هؤلاء المستخدمون بالكامل على لوحات المفاتيح، أو مفاتيح التبديل، أو أجهزة sip-and-puff، أو مؤشرات الرأس، أو تقنيات مساعدة أخرى تحاكي في النهاية إدخال لوحة المفاتيح على مستوى نظام التشغيل.

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

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

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

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

• scrollable-region-focusable: تتحقق هذه القاعدة مما إذا كان أي عنصر يحتوي على محتوى يتجاوز حدوده (أي أنه قابل للتمرير) يمكن الوصول إليه عبر لوحة المفاتيح. عندما تحتوي الحاوية على خصائص CSS مثل overflow: auto أو overflow: scroll، يمكن لمستخدمي الفأرة المبصرين تمريرها بعجلة الفأرة أو لوحة التتبع. أما مستخدمو لوحة المفاتيح، فيجب أن يكونوا قادرين على الانتقال بمفتاح Tab إلى الحاوية أو استخدام مفاتيح الأسهم لتمريرها. تشير القاعدة إلى المناطق القابلة للتمرير التي لا تحتوي على سمة tabindex ولا على عنصر تابع قابل للتركيز بشكل طبيعي، مما يعني أن مستخدم لوحة المفاتيح فقط لن يكون لديه أي طريقة للوصول إلى المحتوى المتجاوز. يكون الكشف الآلي موثوقًا هنا لأن axe يمكنه فحص الأنماط المحسوبة وشجرة DOM لتحديد العناصر ذات التجاوز القابل للتمرير التي تفتقر إلى إمكانية التركيز بلوحة المفاتيح.
• server-side-image-map: تشير هذه القاعدة إلى استخدام خرائط الصور على جانب الخادم — عناصر HTML <img> التي تحتوي على السمة ismap. ترسل خرائط الصور على جانب الخادم إحداثيات البكسل الخام لنقرة الفأرة إلى الخادم لتحديد الرابط الذي تم تفعيله. وبما أن الإجراء يعتمد بالكامل على إحداثيات البكسل المستمدة من جهاز مؤشّر، فلا توجد آلية مكافئة بلوحة المفاتيح. على عكس خرائط الصور على جانب العميل (التي تستخدم عناصر <map> و<area> ويمكن جعلها قابلة للوصول بلوحة المفاتيح)، فإن خرائط الصور على جانب الخادم غير متوافقة جوهريًا مع التنقل باستخدام لوحة المفاتيح فقط. يشير axe إلى أي عنصر <img ismap> على أنه فشل في إتاحة الوصول عبر لوحة المفاتيح. يجب أن تؤكد عملية التحقق اليدوي ما إذا كانت خريطة الصورة هي الطريقة الوحيدة للوصول إلى التنقل أو الوظيفة الأساسية.

من الضروري فهم أن الأدوات الآلية مثل axe-core لا يمكنها سوى التقاط جزء من حالات فشل إتاحة الوصول عبر لوحة المفاتيح. يتطلب العديد من الانتهاكات اختبارًا يدويًا لأنها تتضمن مستمعي أحداث JavaScript مخصصة، أو إدارة ديناميكية للتركيز، أو أنماط تفاعل معقدة لا يمكن للتحليل الساكن تقييمها بالكامل. على سبيل المثال، قد يتلقى زر مُنفَّذ كعنصر <div> مع مستمع حدث click التركيز عبر tabindex='0' لكنه يفشل في الاستجابة لضغط مفاتيح Enter أو Space — وهو فشل لا يمكن لـ axe اكتشافه دائمًا دون تنفيذ التفاعل.

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

1. فحص آلي باستخدام axe DevTools أو Lighthouse: ثبّت إضافة المتصفح axe DevTools لمتصفحي Chrome أو Firefox. انتقل إلى الصفحة قيد الاختبار وشغّل فحصًا لكامل الصفحة. رشّح النتائج للقواعد الموسومة بـ wcag2a وkeyboard. ابحث تحديدًا عن انتهاكات scrollable-region-focusable وserver-side-image-map. في Lighthouse (أدوات تطوير Chrome)، شغّل تدقيق Accessibility وراجع فئة "Keyboard". لاحظ أن هذه الأدوات ستُظهر الإخفاقات الهيكلية الواضحة لكنها لن تلتقط جميع مشكلات الودجات المخصصة.
2. اختبار تنقل يدوي بلوحة المفاتيح: افصل الفأرة أو ضعها جانبًا تمامًا. بدءًا من شريط عنوان المتصفح، اضغط على Tab بشكل متكرر للتحرك للأمام عبر جميع العناصر القابلة للتركيز في الصفحة. اضغط على Shift+Tab للتحرك للخلف. لكل عنصر تفاعلي — الروابط، الأزرار، حقول الإدخال، القوائم المنسدلة المخصصة، النوافذ النمطية، السلايدر — تحقق من أن: (أ) يتلقى مؤشر تركيز مرئي؛ (ب) الضغط على Enter أو Space يفعّله كما هو متوقع؛ (ج) أي مربع حوار أو لوحة ناتجة يمكن أيضًا التنقل فيها وإغلاقها بلوحة المفاتيح. استخدم مفاتيح الأسهم داخل الودجات التي تطبق أنماطًا مركّبة (القوائم، قوائم الألسنة، مجموعات أزرار الاختيار، صناديق القوائم).
3. اختبار قارئ الشاشة + لوحة المفاتيح باستخدام NVDA وFirefox: شغّل NVDA (مجاني، Windows) وافتح Firefox. استخدم وضع التصفح (Browse Mode) في NVDA (مفاتيح الأسهم) لقراءة الصفحة وتحديد جميع العناصر التفاعلية. انتقل إلى وضع التركيز (Focus Mode) (Insert+Space أو تلقائيًا في حقول النماذج) للتفاعل مع عناصر التحكم. تحقق من أن الودجات المخصصة تعلن عن دورها وحالتها واسمها، وأن كل الوظائف يمكن إكمالها دون استخدام الفأرة. اختبر أي حاويات قابلة للتمرير بمحاولة الانتقال إليها بمفتاح Tab واستخدام مفاتيح الأسهم للتمرير.
4. اختبار قارئ الشاشة باستخدام VoiceOver وSafari (macOS/iOS): فعّل VoiceOver (Command+F5 على macOS). استخدم VO+السهم الأيمن للتنقل خطيًا عبر الصفحة. استخدم Tab للتحرك بين العناصر التفاعلية. تأكد من أن المناطق القابلة للتمرير يمكن الوصول إليها وأنه لا توجد وظيفة تتطلب إيماءة سحب أو تفاعل بالمؤشر دون بديل متاح عبر لوحة المفاتيح.
5. اختبار JAWS وChrome: مع تشغيل JAWS، افتح Chrome وانتقل إلى الصفحة. استخدم المؤشر الافتراضي لـ JAWS (JAWS Virtual Cursor) لتصفح المحتوى ومفتاح Tab للتحرك بين العناصر التفاعلية. اختبر بشكل خاص أي ودجات JavaScript مخصصة — الأكورديونات، السلايدر، مربعات الحوار النمطية، صناديق الاختيار المخصصة — عن طريق الانتقال إليها بمفتاح Tab ومحاولة تشغيلها بالكامل عبر لوحة المفاتيح. سجّل أي عنصر يتلقى التركيز لكن لا يمكن تفعيله، أو أي وظيفة لا يمكن الوصول إليها إلا عبر تحويم الفأرة.
6. اختبار خاص بالمناطق القابلة للتمرير: حدد جميع الحاويات في الصفحة التي تحتوي على أشرطة تمرير مرئية أو التي تحتوي على محتوى أكثر من مساحتها المرئية. حاول الانتقال بمفتاح Tab إلى كل حاوية. إذا لم ينقل Tab التركيز داخل الحاوية ولا توجد عناصر تابعة قابلة للتركيز، فمن المحتمل أن تكون الحاوية فشلًا في إتاحة الوصول عبر لوحة المفاتيح. حاول الضغط على مفاتيح الأسهم بينما تكون الحاوية أو عنصر قريب منها في حالة تركيز لمعرفة ما إذا كان التمرير ممكنًا.

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

السيناريو 1: حاوية قابلة للتمرير — غير صحيح

<!-- Scrollable div with no tabindex: keyboard users cannot scroll this content -->
<div style='height: 200px; overflow-y: auto;'>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

السيناريو 1: حاوية قابلة للتمرير — صحيح

<!-- Adding tabindex='0' makes the container focusable so keyboard users
     can scroll it with arrow keys once it receives focus -->
<div
  tabindex='0'
  role='region'
  aria-label='Terms and Conditions'
  style='height: 200px; overflow-y: auto;'
>
  <p>Long list of terms and conditions text...</p>
  <p>More text that overflows the container...</p>
</div>

السيناريو 2: خريطة صورة على جانب الخادم — غير صحيح

<!-- ismap sends pixel coordinates to the server — no keyboard equivalent exists -->
<a href='/map-handler'>
  <img src='navigation-map.png' ismap alt='Site navigation map' />
</a>

السيناريو 2: خريطة صورة على جانب الخادم — صحيح

<!-- Replace with a client-side image map using <map> and <area> elements.
     Each <area> is focusable and activatable by keyboard. -->
<img
  src='navigation-map.png'
  alt='Site navigation map'
  usemap='#site-nav'
/>
<map name='site-nav'>
  <area shape='rect' coords='0,0,100,50' href='/home' alt='Home' />
  <area shape='rect' coords='100,0,200,50' href='/about' alt='About Us' />
  <area shape='rect' coords='200,0,300,50' href='/contact' alt='Contact' />
</map>

السيناريو 3: ودجت مخصص يستخدم أحداث الفأرة فقط — غير صحيح

<!-- div acting as a button with only onclick: keyboard users pressing Enter
     or Space will get no response -->
<div onclick='submitForm()'>Submit Order</div>

السيناريو 3: ودجت مخصص يستخدم أحداث الفأرة فقط — صحيح

<!-- Option A: Use a native <button> — it handles keyboard activation natively -->
<button type='submit' onclick='submitForm()'>Submit Order</button>

<!-- Option B: If a custom element is required, add tabindex, role, and
     a keydown listener for Enter (13) and Space (32) -->
<div
  role='button'
  tabindex='0'
  onclick='submitForm()'
  onkeydown='if(event.key==="Enter"||event.key===" "){submitForm();}'
>
  Submit Order
</div>

السيناريو 4: قائمة منسدلة تعتمد على التحويم فقط — غير صحيح

<!-- Menu only appears on CSS :hover — keyboard focus on the parent
     does not reveal the submenu -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <a href='/products'>Products</a>
      <ul class='dropdown'> <!-- only visible on :hover in CSS -->
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

السيناريو 4: قائمة منسدلة تعتمد على التحويم فقط — صحيح

<!-- Use a button to toggle the dropdown and manage aria-expanded.
     CSS shows the submenu when the button has aria-expanded='true'.
     Keyboard users press Enter/Space on the button to open the menu. -->
<nav>
  <ul>
    <li class='has-dropdown'>
      <button
        aria-expanded='false'
        aria-controls='products-submenu'
        onclick='toggleMenu(this)'
      >
        Products
      </button>
      <ul id='products-submenu' hidden>
        <li><a href='/products/a'>Product A</a></li>
        <li><a href='/products/b'>Product B</a></li>
      </ul>
    </li>
  </ul>
</nav>

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

• استخدام onclick كمعالج الحدث الوحيد على عنصر غير أصيل (non-native) دون إضافة معالج onkeydown أو onkeyup مكافئ — نقرات الفأرة تشغّل onclick لكن التفعيل بلوحة المفاتيح على عنصر <div> أو <span> لا يفعل ذلك.
• إضافة tabindex='0' إلى عنصر تفاعلي مخصص مع نسيان إضافة role='button' (أو الدور المناسب)، مما يعني أن قارئات الشاشة لا تنقل غرض العنصر للمستخدم.
• بناء تنقل بقوائم منسدلة يعتمد حصريًا على شبه الصنف :hover في CSS دون وجود تبديل بلوحة المفاتيح مدعوم بـ JavaScript، مما يجعل القوائم الفرعية غير مرئية وغير قابلة للوصول لمستخدمي لوحة المفاتيح.
• تنفيذ واجهات السحب والإفلات — مثل قوائم الفرز، ولوحات kanban، ومناطق رفع الملفات — دون آلية بديلة قابلة للوصول بلوحة المفاتيح مثل أوامر نقل يتم تشغيلها بلوحة المفاتيح أو عنصر تحكم منفصل لإعادة الترتيب.
• إنشاء حاويات قابلة للتمرير (مثل صناديق شروط الخدمة، أو نوافذ الدردشة، أو جداول البيانات داخل أغلفة ذات ارتفاع ثابت) دون tabindex='0'، مما يمنع مستخدمي لوحة المفاتيح من التمرير لعرض كل المحتوى.
• استخدام <img ismap> لمكوّنات التنقل الموروثة من قواعد شيفرة قديمة دون استبدالها بخرائط صور على جانب العميل أو روابط تنقل قياسية.
• تطبيق tabindex='-1' على عناصر تفاعلية لإزالتها من ترتيب Tab الطبيعي دون توفير استراتيجية برمجية لإدارة التركيز، مما يؤدي إلى عناصر تحكم لا يمكن الوصول إليها نهائيًا بلوحة المفاتيح.
• تشغيل الوظائف حصريًا على أحداث mouseenter أو mouseleave أو mousemove (مثل التلميحات، والمعاينات، والقوائم السياقية) دون بدائل مكافئة لأحداث focus وblur أو أحداث لوحة المفاتيح.
• الافتراض بأن مربع الحوار النمطي يدير التركيز تلقائيًا — الفشل في نقل التركيز إلى مربع الحوار عند فتحه والفشل في إرجاع التركيز إلى العنصر الذي شغّله عند إغلاقه، مما يترك مستخدمي لوحة المفاتيح في حالة ارتباك داخل الصفحة.
• تعيين pointer-events: none في CSS على عنصر يجب أن يكون قابلاً للوصول بلوحة المفاتيح، وهو ما لا يؤثر مباشرة على سلوك لوحة المفاتيح، لكنه غالبًا ما يقترن بأنماط JavaScript التي تحجب أيضًا التفاعل بلوحة المفاتيح.

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

تضع التعميم الرئاسي 2025/10 في تركيا، المنشور في الجريدة الرسمية رقم 32933 بتاريخ 21 يونيو 2025، متطلبات إلزامية لإتاحة الوصول على الويب متوافقة مع WCAG 2.1 مستوى AA. تُعد WCAG 2.1.1 (لوحة المفاتيح) معيارًا من المستوى A، مما يضعها في أعلى فئة أولوية من متطلبات الامتثال. يُعتبر الامتثال لمستوى A الحد الأدنى المطلق — فإذا أخفق موقع ما في معايير مستوى A، يُعتبر غير متاح بغض النظر عن أي تحسينات أخرى تم إجراؤها.

بموجب التعميم، تختلف جداول الامتثال حسب نوع الكيان: يُطلب من المؤسسات العامة والهيئات الحكومية تحقيق الامتثال خلال عام واحد من تاريخ نشر التعميم، بينما لدى الكيانات في القطاع الخاص المشمولة باللائحة عامان للامتثال.

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

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

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