إمكانية الوصول عبر لوحة المفاتيح: كيفية جعل موقعك الإلكتروني قابلاً للتنقل بالكامل باستخدام لوحة المفاتيح

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

من يعتمد على التنقل عبر لوحة المفاتيح — ولماذا هو أهم مما تظن

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

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

الحجة التجارية لا تقل إقناعًا. وفقًا للبيانات المتاحة، يمتلك الأشخاص ذوو الإعاقة في الولايات المتحدة ما يقرب من نصف تريليون دولار من الدخل المتاح للإنفاق. عندما لا يكون موقعك قابلًا للاستخدام عبر لوحة المفاتيح، فأنت فعليًا تصدّ نسبة كبيرة من هذا السوق. كما أن التعرض القانوني حقيقي: إتاحة الوصول عبر لوحة المفاتيح ضرورية للامتثال لـ WCAG، وهو المعيار المرجعي للامتثال لـ ADA وSection 508 وEuropean Accessibility Act وEN 301 549 عالميًا. فمصائد لوحة المفاتيح وحدها — حيث يعلق المستخدم داخل عنصر في الصفحة دون أي طريقة للخروج — تُذكر بوضوح كإخفاقات WCAG وقد ظهرت في دعاوى تتعلق بإتاحة الوصول.

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

إطار عمل WCAG: ما الذي تتطلبه القواعد فعليًا

تنظم إرشادات محتوى الويب القابل للوصول (WCAG) متطلبات لوحة المفاتيح أساسًا تحت المبدأ التوجيهي 2.1 — "اجعل كل الوظائف متاحة من لوحة المفاتيح". فهم ما هو مطلوب وما ليس مطلوبًا هو الخطوة الأولى نحو الامتثال. WCAG 2.2، التي أصبحت المعيار الرسمي لـ W3C في 5 أكتوبر 2023 وأضافت تسعة معايير نجاح جديدة إلى الإطار القائم، هي الآن المعيار الموصى به لـ ADA وSection 508 وEuropean Accessibility Act.

معايير النجاح الأساسية المتعلقة بلوحة المفاتيح التي تحتاج إلى معرفتها هي:

• SC 2.1.1 Keyboard (المستوى A): يجب أن تكون كل الوظائف قابلة للتشغيل عبر واجهة لوحة مفاتيح دون الحاجة إلى توقيت محدد لضغطات المفاتيح الفردية، باستثناء الحالات التي تتطلب فيها الوظيفة الأساسية إدخالًا يعتمد على المسار (مثل الرسم الحر باليد). هذا هو الحد الأدنى — يجب أن يكون كل عنصر تفاعلي قابلًا للوصول والتشغيل عبر لوحة المفاتيح.
• SC 2.1.2 No Keyboard Trap (المستوى A): إذا أمكن نقل تركيز لوحة المفاتيح إلى مكوّن باستخدام لوحة المفاتيح، فيجب أيضًا أن يكون من الممكن نقل التركيز بعيدًا باستخدام لوحة المفاتيح فقط. إذا كان الخروج يتطلب طريقة غير قياسية، فيجب إبلاغ المستخدمين بها. مصائد لوحة المفاتيح تشكل عائقًا مطلقًا لمستخدمي لوحة المفاتيح.
• SC 2.4.3 Focus Order (المستوى A): إذا كان يمكن التنقل في صفحة ويب بشكل تسلسلي، فيجب أن يحافظ ترتيب التركيز على المعنى وقابلية التشغيل. ترتيب Tab المنطقي والمتوقع غير قابل للتفاوض.
• SC 2.4.7 Focus Visible (المستوى AA): يجب أن يكون لأي واجهة مستخدم قابلة للتشغيل عبر لوحة المفاتيح وضع يظهر فيه مؤشر تركيز لوحة المفاتيح. يجب أن يكون المستخدمون قادرين دائمًا على رؤية مكانهم في الصفحة.
• SC 2.4.11 Focus Not Obscured (الحد الأدنى) (المستوى AA — جديد في WCAG 2.2): عندما يحصل عنصر قابل للتركيز عبر لوحة المفاتيح على التركيز، يجب ألا يكون مخفيًا بالكامل بواسطة محتوى أنشأه المؤلف مثل رؤوس ثابتة (sticky headers) أو لافتات ملفات تعريف الارتباط.
• SC 2.4.12 Focus Not Obscured (محسّن) (المستوى AAA): نسخة أكثر صرامة تتطلب ألا يكون أي جزء من المكوّن الذي عليه التركيز مخفيًا بواسطة محتوى أنشأه المؤلف.
• SC 2.5.8 Target Size (الحد الأدنى) (المستوى AA — جديد في WCAG 2.2): يجب أن تكون الأهداف التفاعلية بحجم لا يقل عن 24x24 بكسل CSS، لتقليل الأخطاء لدى المستخدمين ذوي التحكم الحركي المحدود.
• SC 2.5.7 Dragging Movements (المستوى AA — جديد في WCAG 2.2): يجب أن يكون لأي وظيفة تتطلب السحب بديل باستخدام مؤشر واحد — مما يفيد بالتبعية مستخدمي لوحة المفاتيح الذين لا يمكنهم تنفيذ عمليات السحب.

WCAG 2.2 متوافقة بالكامل مع الإصدارات السابقة WCAG 2.1 — فهي تضيف معايير ولا تزيل أيًا منها (باستثناء 4.1.1 Parsing التي أصبحت الآن قديمة). إذا كان موقعك يفي بالفعل بـ WCAG 2.1 AA، فكل ما عليك هو تنفيذ ستة معايير جديدة من المستوى AA. وبالنسبة لإتاحة الوصول عبر لوحة المفاتيح تحديدًا، الإضافة الكبيرة الجديدة هي ضمان ألا تُحجب العناصر التي عليها التركيز بالكامل بواسطة عناصر ثابتة في الصفحة — وهي مشكلة شائعة في العالم الواقعي لم تعالجها WCAG 2.1 صراحة.

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

أكثر إخفاقات إتاحة الوصول عبر لوحة المفاتيح شيوعًا (وما الذي يسببها)

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

تتجمع الأسباب الجذرية حول عدد قليل من الأنماط المتكررة التي تستحق الفحص بالتفصيل.

1. معالجات أحداث خاصة بالماوس فقط. استخدام onmouseover أو onmouseout أو onclick على عناصر <div> دون معالجات أحداث مكافئة للوحة المفاتيح هو أحد أكثر الإخفاقات شيوعًا. فـ <div> مع معالج نقر ليس زرًا — ليس له دور ضمني في لوحة المفاتيح، ولن يحصل على التركيز عبر Tab، ولن يستجيب لمفاتيح Enter أو Space. إسناد role='button' عبر ARIA يساعد قارئات الشاشة لكنه لا يزال يتطلب منك إضافة tabindex='0' وonkeydown وonkeyup يدويًا. الحل الصحيح في الغالب هو استخدام عنصر <button> حقيقي.

2. قمع مخططات التركيز (focus outlines). من أكثر المشكلات انتشارًا قاعدة CSS outline: none أو outline: 0 المطبقة عالميًا أو على العناصر التي عليها التركيز. غالبًا ما يزيل المصممون حلقة التركيز الافتراضية للمتصفح لأنها تبدو غير جذابة في بعض السمات. والنتيجة أن مستخدمي لوحة المفاتيح لا يعرفون أين هم في الصفحة. هذا انتهاك مباشر لـ WCAG SC 2.4.7 وأحد أسهل المشكلات في الإنشاء — وفي الإصلاح.

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

4. ترتيب Tab غير منطقي. يتم تحديد ترتيب التنقل الافتراضي عبر لوحة المفاتيح بواسطة ترتيب المصدر في DOM. عندما يستخدم المطورون CSS Grid أو Flexbox أو تموضع CSS لإعادة ترتيب العرض المرئي بشكل مستقل عن ترتيب DOM، يقفز تركيز Tab حول الشاشة بطرق منفصلة تمامًا عن التخطيط المرئي. القيم الإيجابية لـ tabindex (مثل tabindex='2') المستخدمة لفرض ترتيب معين تجعل هذه المشكلة أسوأ بكثير في معظم الحالات الواقعية.

5. قوائم منسدلة تعتمد على hover فقط. قوائم التنقل التي تُفتح فقط عند تحريك الماوس فوقها، دون مشغّل عبر لوحة المفاتيح، تترك مستخدمي لوحة المفاتيح عالقين. هذا نمط شائع للغاية في القوائم المنسدلة المعتمدة على CSS فقط، حيث تظهر القوائم الفرعية عند :hover لكنها لا تُتاح أبدًا للتنقل المعتمد على التركيز.

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

بناء إتاحة الوصول عبر لوحة المفاتيح بشكل صحيح: تنفيذ عملي

مع وضع أنماط الإخفاق في الاعتبار، إليك ما يبدو عليه التنفيذ الصحيح عبر أهم مناطق الموقع النموذجي.

استخدم HTML دلاليًا (Semantic) أولًا

العناصر الأصلية في HTML قابلة للاستخدام عبر لوحة المفاتيح افتراضيًا. الروابط (<a href>) والأزرار (<button>) وحقول النماذج والقوائم المنسدلة (selects) ومناطق النص (textareas) كلها تشارك في ترتيب Tab، وتستجيب لضغطات المفاتيح القياسية، وتُبلغ تقنيات المساعدة بدورها — دون سطر واحد إضافي من JavaScript. عنصر <button> يمتلك تلقائيًا الدور الصحيح، وهو قابل للاستخدام عبر لوحة المفاتيح، ويستجيب لمفاتيح Enter وSpace، ولديه إدارة تركيز مدمجة بشكل صحيح. إضافة role='button' إلى <div> يمنحه الدور الصحيح لكنه لا يزال يتطلب منك تنفيذ دعم لوحة المفاتيح وإدارة التركيز يدويًا. فضّل دائمًا HTML الدلالي.

<!-- Avoid: non-semantic div pretending to be a button -->
<div onclick='doSomething()' class='btn'>Submit</div>

<!-- Correct: native button element -->
<button type='button' onclick='doSomething()'>Submit</button>

أصلح مؤشرات التركيز لديك

بدلًا من إزالة مخطط التركيز الافتراضي للمتصفح، استبدله بمؤشر تركيز مخصص ومصمم. يتطلب WCAG 2.2 SC 2.4.11 أن تكون مساحة مؤشر التركيز على الأقل بحجم محيط بسماكة 2 بكسل CSS حول المكوّن غير المركّز، مع نسبة تباين لا تقل عن 3:1 بين حالتي التركيز وعدم التركيز. استخدم شبه الصنف :focus-visible بدلًا من :focus لإظهار مؤشرات التركيز لمستخدمي لوحة المفاتيح فقط، دون التأثير على جمالية التفاعل بالماوس.

/* Remove default only to replace with better indicator */
*:focus {
  outline: none;
}

*:focus-visible {
  outline: 3px solid #005fcc;
  outline-offset: 3px;
  border-radius: 2px;
}

يمنحك هذا النهج تحكمًا بصريًا كاملًا مع الحفاظ على الامتثال لـ WCAG. تأكد من أن لون التركيز يمتلك تباينًا كافيًا مع كل من الخلفية والمكوّن نفسه، خاصة في المواقع ذات السمات الداكنة أو فوق الصور.

إدارة التركيز في التفاعلات الديناميكية

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

// Opening a modal: move focus inside
function openModal(modalEl, triggerEl) {
  modalEl.removeAttribute('hidden');
  const firstFocusable = modalEl.querySelector(
    'button, [href], input, select, textarea, [tabindex]:not([tabindex="-1"])'
  );
  if (firstFocusable) firstFocusable.focus();
}

// Closing a modal: return focus to trigger
function closeModal(modalEl, triggerEl) {
  modalEl.setAttribute('hidden', '');
  triggerEl.focus();
}

تنفيذ روابط تخطي التنقل (Skip Navigation)

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

<!-- Place as the first element in <body> -->
<a href='#main-content' class='skip-link'>Skip to main content</a>

<!-- Target anchor on the main content container -->
<main id='main-content' tabindex='-1'>
  <!-- page content -->
</main>

/* Show skip link only on keyboard focus */
.skip-link {
  position: absolute;
  top: -40px;
  left: 0;
  background: #000;
  color: #fff;
  padding: 8px 16px;
  z-index: 100;
  transition: top 0.2s;
}

.skip-link:focus {
  top: 0;
}

بناء قوائم تنقل قابلة للوصول

تتطلب قوائم التنقل ذات القوائم الفرعية المنسدلة عناية دقيقة. نمط التفاعل الصحيح عبر لوحة المفاتيح لقائمة التنقل هو: مفتاح Tab للتنقل بين العناصر ذات المستوى الأعلى؛ مفتاح Enter أو Space لفتح القائمة الفرعية؛ مفاتيح الأسهم للتنقل داخل القائمة الفرعية؛ ومفتاح Escape لإغلاق القائمة الفرعية وإعادة التركيز إلى المشغّل. استخدم سمات ARIA للتواصل حول الحالة. القوائم التي تُفتح فقط عند hover بالماوس دون مشغّل عبر لوحة المفاتيح غير قابلة للوصول ويجب إصلاحها.

<nav aria-label='Main navigation'>
  <ul role='menubar'>
    <li role='none'>
      <button
        aria-haspopup='true'
        aria-expanded='false'
        aria-controls='products-menu'>
        Products
      </button>
      <ul role='menu' id='products-menu' hidden>
        <li role='none'>
          <a role='menuitem' href='/software'>Software</a>
        </li>
        <li role='none'>
          <a role='menuitem' href='/hardware'>Hardware</a>
        </li>
      </ul>
    </li>
  </ul>
</nav>

استخدم aria-expanded='false' وaria-expanded='true' يتم تبديلهما عبر JavaScript للتواصل حول حالة الفتح/الإغلاق. استخدم aria-haspopup='true' للإشارة إلى أن تفعيل الزر يكشف عن قائمة فرعية. تأكد من أن مفتاح Escape يغلق القائمة الفرعية ويعيد التركيز إلى زر المشغّل.

التعامل مع tabindex بشكل صحيح

هناك ثلاث قيم ذات معنى لـ tabindex ولكل منها غرض مميز. tabindex='0' يضيف عنصرًا غير تفاعلي إلى ترتيب Tab الطبيعي — استخدم هذا عندما تحتاج حقًا إلى أن يحصل عنصر غير قابل للتركيز (مثل حاوية ويدجت مخصصة) على التركيز. tabindex='-1' يزيل عنصرًا من ترتيب Tab لكنه يسمح له بالحصول على التركيز برمجيًا عبر .focus() — وهو ضروري لأهداف النوافذ المنبثقة ووجهات روابط التخطي. القيم الإيجابية لـ tabindex (مثل tabindex='1' أو tabindex='5') تتجاوز الترتيب الطبيعي بطرق تكاد دائمًا أن تسبب مشكلات أكثر مما تحل؛ تجنبها تمامًا وأصلح ترتيب DOM بدلًا من ذلك.

ARIA: أداة قوية، وليست حلًا سحريًا

سمات Accessible Rich Internet Applications (ARIA) توسّع دلالات HTML لمساعدة تقنيات المساعدة على فهم المكوّنات المخصصة التي لا تغطيها عناصر HTML الأصلية — مثل علامات التبويب (tabs)، والأكورديونات، وعروض الشرائح (carousels)، وعناصر الشجرة (tree views)، وصناديق الاختيار المركبة (combo boxes). يمكن لسمات ARIA أن توفر سياقًا إضافيًا، لكنها يجب أن تكمل — لا أن تستبدل — HTML الدلالي. خطأ شائع وخطير هو اللجوء إلى ARIA قبل التفكير فيما إذا كان عنصر HTML أصلي يمكنه أداء المهمة بدلًا من ذلك.

القاعدة الأولى لـ ARIA هي: لا تستخدم ARIA إذا كان عنصر أو سمة HTML أصلية يمكن أن تؤدي نفس المهمة. القاعدة الثانية: عدم استخدام ARIA أفضل من استخدامها بشكل سيئ. فوسم ARIA غير الصحيح — على سبيل المثال، تطبيق role='menu' دون التسلسل الهرمي الصحيح لأبناء role='menuitem'، أو استخدام aria-hidden='true' على عنصر يحصل على التركيز — يمكن أن يضر بإتاحة الوصول بدلًا من أن يساعدها.

عندما تكون ARIA مطلوبة حقًا، فإن السمات الأكثر فائدة للتفاعلات عبر لوحة المفاتيح هي: aria-expanded للتواصل حول حالة الفتح/الإغلاق في العناصر القابلة للطي؛ aria-controls لربط المشغّل بالمحتوى الذي يتحكم فيه؛ aria-haspopup للإشارة إلى أن زرًا يفتح قائمة أو مربع حوار؛ aria-modal='true' على عناصر الحوار للإشارة إلى أن محتوى الخلفية غير نشط؛ ومناطق aria-live (polite لرسائل الحالة، assertive للتنبيهات العاجلة) للإعلان عن تغييرات المحتوى الديناميكية لمستخدمي قارئات الشاشة دون نقل التركيز.

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

اختبار إتاحة الوصول عبر لوحة المفاتيح

أكثر اختبار فعّال يمكنك إجراؤه الآن لا يتطلب أي أدوات: افصل الماوس وتصفّح موقعك باستخدام لوحة المفاتيح فقط. اضغط Tab للتنقل للأمام عبر العناصر التفاعلية، وShift+Tab للتنقل للخلف، وEnter لتفعيل الروابط والأزرار، وSpace لتبديل مربعات الاختيار وتفعيل الأزرار، وEscape لإغلاق النوافذ المنبثقة والقوائم، ومفاتيح الأسهم للتنقل داخل المكوّنات. اسأل نفسك: هل يمكنك الوصول إلى كل عنصر تفاعلي؟ هل يمكنك رؤية مكانك في كل الأوقات؟ هل يمكنك إكمال كل رحلة مستخدم حرجة دون أن تعلق؟

يمكن للأدوات الآلية اكتشاف مجموعة ذات مغزى من مشكلات إتاحة الوصول عبر لوحة المفاتيح — خصوصًا التسميات المفقودة، والأزرار الفارغة، وبعض مشكلات إدارة التركيز. أدوات مثل axe DevTools وWAVE وLighthouse تشكل تمريرة أولى قيّمة. ومع ذلك، تكتشف الأدوات الآلية حوالي 40% فقط من مشكلات WCAG. رؤية التركيز، وترتيب التركيز المنطقي، والإدارة الصحيحة لحالة ARIA كلها تتطلب تقييمًا يدويًا بشريًا. للحصول على تقييم أكثر شمولًا، اجمع بين الفحص الآلي والاختبار اليدوي باستخدام لوحة المفاتيح فقط عبر متصفحات متعددة، وضمّن اختبار قارئات الشاشة باستخدام NVDA (Windows) أو JAWS (Windows) أو VoiceOver (macOS/iOS).

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

بالنسبة للفرق التي تبني مكتبات مكوّنات، يعد WAI-ARIA Authoring Practices Guide (APG) الذي ينشره W3C المرجع الحاسم لأنماط التفاعل عبر لوحة المفاتيح لعشرات أنواع الويدجت — من الأكورديونات وعروض الشرائح إلى منتقيات التواريخ وعناصر الشجرة. يحدد كل نمط بالضبط أي المفاتيح يجب دعمها وما ينبغي أن يكون عليه السلوك المتوقع.

الرؤوس الثابتة، التذييلات الثابتة، وحجب التركيز

أحد أكثر المتطلبات الجديدة صلة بالواقع العملي في WCAG 2.2 هو معيار النجاح 2.4.11: Focus Not Obscured. يعالج مشكلة شائعة لدرجة أنها تكاد تعرّف الويب الحديث: أشرطة التنقل الثابتة، ولافتات موافقة ملفات تعريف الارتباط، وويدجت الدردشة، والتذييلات الثابتة التي تجلس فوق محتوى الصفحة. عندما ينتقل مستخدم لوحة المفاتيح باستخدام Tab إلى عنصر تم تمريره خلف إحدى هذه الطبقات الثابتة، يصبح العنصر الذي عليه التركيز غير مرئي — فلا يمكن للمستخدم رؤية ما يتفاعل معه.

يتطلب الإصلاح تنسيقًا بين CSS وJavaScript. عندما يحصل عنصر على التركيز، يجب على المتصفح تمريره إلى منطقة مرئية. لكن رأسًا ثابتًا بـ position: fixed وارتفاع، لنقل، 80px يعني أن أعلى 80px من نافذة العرض مشغولة بشكل دائم. يمكن أن يعوّض CSS scroll padding عن هذا:

html {
  /* Height of your sticky header + a small buffer */
  scroll-padding-top: 96px;
}

هذا يخبر المتصفح بضبط تثبيت التمرير بمقدار القيمة المحددة، بحيث عندما يقوم بالتمرير التلقائي لعنصر عليه التركيز إلى مجال الرؤية، يأخذ في الحسبان الرأس الثابت. قد تحتاج أيضًا إلى scroll-padding-bottom مكافئ إذا كان لديك تذييل ثابت. بالنسبة للافتات ملفات تعريف الارتباط أو التراكبات التي تظهر وتختفي، تأكد من أنها تحمل قيم z-index لا تغطي العنصر الذي عليه التركيز، أو اضبط padding التمرير ديناميكيًا عندما تكون اللافتة مرئية.

أهم النقاط المستخلصة

• HTML الدلالي هو أفضل خطوة أولى لك. العناصر الأصلية مثل <button> و<a> وعناصر النماذج قابلة للاستخدام عبر لوحة المفاتيح افتراضيًا. كل ويدجت مخصص مبني من divs يكلّفك إتاحة وصول يجب عليك بعد ذلك إعادة بنائها يدويًا باستخدام ARIA وJavaScript.
• لا تقم أبدًا بقمع مؤشرات التركيز دون استبدالها. قاعدة outline: none العامة هي من أكثر الأشياء ضررًا التي يمكنك وضعها في ملف الأنماط. استخدم :focus-visible لتوفير حلقة تركيز ذات نمط واضح وتباين عالٍ تلبي متطلبات الحجم والتباين الدنيا في WCAG 2.2.
• أدِر التركيز برمجيًا لكل تفاعل ديناميكي. النوافذ المنبثقة، والأدراج، وإشعارات toast، وتغييرات المحتوى الديناميكية كلها تتطلب إدارة تركيز صريحة — نقل التركيز إلى الداخل، وإعادته عند الإغلاق. بدون ذلك، يفقد مستخدمو لوحة المفاتيح مكانهم في كل مرة يتغير فيها واجهة المستخدم.
• أضف رابط تخطي التنقل في أعلى كل صفحة. يستغرق الأمر أقل من 20 سطرًا من الشيفرة ويحسّن بشكل كبير تجربة مستخدمي لوحة المفاتيح الذين سيضطرون خلاف ذلك إلى الضغط على Tab عبر كامل رأس الصفحة والتنقل في كل مرة تُحمّل فيها الصفحة.
• اختبر باستخدام لوحة المفاتيح قبل الإطلاق. تلتقط الأدوات الآلية جزءًا فقط من مشكلات إتاحة الوصول عبر لوحة المفاتيح. جولة تستغرق عشر دقائق باستخدام لوحة المفاتيح فقط عبر أهم رحلات المستخدم لديك ستكشف عن عوائق حقيقية لن يجدها أي ماسح — ويمكن لأي مطور في الفريق القيام بها دون تدريب متخصص.