Harbour Lights 2026
\n![\"image\"](\"crowd.jpg\")
\n Tickets
\n \n \n \n \n \n Festival FAQ\n\n لسمير مقولة: «الروبوت يجد الأخطاء الإملائية، والإنسان يجد الثغرات في الحبكة». أدوات إمكانية الوصول الآلية سريعة ورخيصة ولا تتعب، وتجد نسبة كبيرة من المشكلات في الصفحة المعتادة خلال ثوانٍ. لكنها عاجزة تمامًا عن معرفة إن كان النص البديل صادقًا، أو إن كان ترتيب التركيز منطقيًا، أو إن كانت نافذة الحوار قابلة للاستخدام. يوضّح هذا الدرس كيف تحصل منها على أقصى فائدة، وأين تتوقّف.
\naxe-core، الذي تصونه شركة Deque، مكتبة JavaScript مفتوحة المصدر لقواعد إمكانية الوصول. تعمل داخل الصفحة، وتفحص الـ DOM والأنماط المحسوبة، وتبلّغ عن المخالفات مع معيار WCAG المعنيّ والعنصر المخالف واقتراح للإصلاح. وهي حريصة على نحو غير معتاد على تجنّب الإنذارات الكاذبة: حين لا تكون متأكدة، تبلّغ عن العنصر على أنه “needs review” (يحتاج إلى مراجعة) لا على أنه مخالفة.
\nستقابلها في عدة أماكن:
\n@axe-core/playwright للاختبارات الشاملة (end-to-end)، وأغلفة مثل vitest-axe لاختبارات الـ components.وإضافة WAVE من WebAIM وAccessibility Insights من Microsoft بدائل أو رفاق جيدون؛ وتضيف Accessibility Insights أيضًا فحوصًا يدوية موجَّهة.
\nالقواعد الآلية جيدة في الحقائق الموضوعية البنيوية:
\n| تلتقطه الأتمتة بشكل موثوق | \nيحتاج إلى إنسان | \n
|---|---|
| غياب خاصية alt | \nهل النص البديل دقيق ومفيد | \n
| حقول وأزرار وروابط بلا اسم | \nهل للاسم معنى، وهل يطابق التسمية المرئية | \n
| تباين نصي أقل من 4.5:1 أو 3:1 | \nالتباين فوق الصور والتدرّجات اللونية | \n
غياب lang، وتكرار الـ ids، وقيم ARIA غير الصالحة | \nهل اللغة صحيحة لكل جزء | \n
aria-hidden على عناصر قابلة للتركيز | \nترتيب التركيز، ومصائد لوحة المفاتيح، والتركيز بعد إغلاق نافذة حوار | \n
| بعض مشكلات العناوين والـ landmarks | \nهل العناوين تصف المحتوى | \n
| \n | هل تُعلَن التحديثات الحيّة، وهل التعليمات واضحة | \n
كم يمثّل ذلك إجمالًا؟ الدراسات تختلف لأنها تحسب بطرق مختلفة. حين زرعت دائرة الخدمات الرقمية الحكومية في المملكة المتحدة (GDS) عام 2017 ما مجموعه 142 عائقًا معروفًا في صفحة اختبار، وجدت أفضل أداة 40% منها، ووجد بعضها أقل من ذلك بكثير. أما Deque، التي تحصي المشكلات في آلاف عمليات التدقيق الحقيقية، فتقول إن الاختبارات الآلية التقطت نحو 57% من المشكلات من حيث العدد، ويعود ذلك أساسًا إلى أن بضع مشكلات قابلة للأتمتة، وخاصةً التباين، تتكرّر كثيرًا. الخلاصة المنصفة: الأتمتة تجد المشكلات الأكثر تكرارًا، لكنها لا تغطّي إلا أقلية مما تطلبه WCAG.
\n\nالفحص في الـ CI يحوّل إمكانية الوصول إلى اختبار تراجع (regression test): بمجرد أن تصبح الصفحة نظيفة، يُفشل أي label مفقود جديد الـ build. مع Playwright و@axe-core/playwright:
import { test, expect } from '@playwright/test';\nimport AxeBuilder from '@axe-core/playwright';\n\nconst WCAG_AA = ['wcag2a', 'wcag2aa', 'wcag21a', 'wcag21aa', 'wcag22aa'];\n\ntest('event page has no detectable WCAG A/AA violations', async ({ page }) => {\n await page.goto('/events/friday');\n const results = await new AxeBuilder({ page }).withTags(WCAG_AA).analyze();\n expect(results.violations).toEqual([]);\n});\n\ntest('booking dialog has no detectable violations when open', async ({ page }) => {\n await page.goto('/events/friday');\n await page.getByRole('button', { name: 'Book now Friday pass' }).click();\n await expect(page.getByRole('dialog', { name: 'Book Friday pass' })).toBeVisible();\n\n const results = await new AxeBuilder({ page })\n .include('#booking')\n .withTags(WCAG_AA)\n .analyze();\n expect(results.violations).toEqual([]);\n});الاختبار الثاني لا يقلّ أهمية عن الأول. لا يرى axe إلا ما هو معروض لحظة الفحص، فنوافذ الحوار المغلقة والقوائم المطويّة وحالات الخطأ والسمة الداكنة تبقى غير مختبَرة ما لم يضع اختبارك الصفحة في تلك الحالات أولًا.
\nلاحظ أن الاختبار يجد العناصر أيضًا عبر getByRole واسم متاح. تحديد العناصر بالدور والاسم هو الأسلوب الذي يوصي به Playwright أصلًا، ويمنحك فحصًا صغيرًا لإمكانية الوصول مجانًا: إن فقدت نافذة الحوار اسمها، يتوقّف الـ locator عن المطابقة.
في مشاريع React، ينبّه eslint-plugin-jsx-a11y إلى المشكلات وأنت تكتب: عنصر img بلا alt، أو div عليه onClick بلا دور أو معالج مفاتيح، أو خاصية aria-* غير موجودة. يلتقط أقل مما يلتقطه axe لأنه لا يرى إلا الكود المصدري لا الصفحة المعروضة، لكنه يلتقطه بعد دقائق من الخطأ بدلًا من أيام.
هكذا يبدو الإعداد متعدّد الطبقات: الـ linter في المحرّر، وaxe في اختبارات الـ components والاختبارات الشاملة، وإنسان بلوحة مفاتيح وقارئ شاشة قبل كل إصدار. والدرس التالي هو ذلك الإنسان.
\n","toc":[{"id":"sec-1","text":"axe وعائلته","level":2},{"id":"sec-2","text":"ما تلتقطه الأتمتة، وما لا تستطيعه","level":2},{"id":"sec-3","text":"axe في اختبارات Playwright","level":2},{"id":"sec-4","text":"الـ Linting يلتقط المشكلات أبكر","level":2}],"takeaways":["axe-core هو محرّك القواعد مفتوح المصدر الذي يقف خلف axe DevTools وتدقيق إمكانية الوصول في Lighthouse وكثير من تكاملات الاختبار.","تلتقط الأدوات الآلية بشكل موثوق غياب alt والـ labels والأسماء، وإخفاقات التباين، وقيم ARIA غير الصالحة، وغياب لغة الصفحة.","لا تستطيع هذه الأدوات الحكم على المعنى، فجودة alt وترتيب التركيز وسلوك لوحة المفاتيح والإعلانات الحيّة وعدم تطابق التسمية مع الاسم تحتاج إلى إنسان.","شغّل axe في الـ CI على الصفحات والحالات الأساسية، مثل نافذة حوار مفتوحة، لتُفشل التراجعاتُ الـ build، واعتبر الفحص النظيف الحدّ الأدنى لا خطّ النهاية."],"further":[{"title":"Playwright: Accessibility testing","url":"https://playwright.dev/docs/accessibility-testing"},{"title":"W3C WAI: Selecting Web Accessibility Evaluation Tools","url":"https://www.w3.org/WAI/test-evaluate/tools/selecting/"},{"title":"web.dev Learn Accessibility: Automated testing","url":"https://web.dev/learn/accessibility/test-automated"}],"quiz":[{"q":"تحصل الصفحة الرئيسية في Ticketly على 100 في تدقيق إمكانية الوصول في Lighthouse. ماذا تستنتج؟
","options":[{"text":"الصفحة تحقّق WCAG 2.2 AA","why":"يشغّل Lighthouse جزءًا من قواعد axe. والدرجة الكاملة تعني أن أيًّا من تلك الفحوص الآلية لم يفشل، لا أن الصفحة متوافقة."},{"text":"لم يجد أيٌّ من الفحوص الآلية التي يشغّلها Lighthouse مشكلة؛ وما زالت مشكلات لوحة المفاتيح وقارئ الشاشة والمحتوى غير مختبَرة","why":"صحيح. إنها علامة جيدة وحماية مفيدة من التراجعات، لكن معظم WCAG يحتاج إلى حكم بشري."},{"text":"لن يواجه مستخدمو قارئ الشاشة أي صعوبة معها","why":"لا تستطيع الأدوات الآلية أن تعرف إن كانت الأسماء ذات معنى، أو إن كان التركيز ينتقل بشكل منطقي، أو إن كانت التحديثات تُعلَن. وحده الاختبار بقارئ شاشة يُظهر ذلك."}],"answer":1},{"q":"أيّ هذه المشكلات سيرصدها axe افتراضيًا؟
","options":[{"text":"صورة عليهاalt="image"","why":"خاصية alt موجودة، فلا يوجد ما ترصده القاعدة. أما إن كان النص ذا معنى فهذا يحتاج إلى إنسان."},{"text":"نافذة منبثقة تترك التركيز خلفها حين تُفتح","why":"إدارة التركيز تعتمد على التفاعل والقصد؛ ولا يستطيع فحص ثابت أن يعرف أين يجب أن يذهب التركيز."},{"text":"رسالة حالة في فقرة عادية لا تُعلنها قارئات الشاشة أبدًا","why":"لا يستطيع axe أن يعرف أيّ نص يتغيّر ديناميكيًا أو يجب أن يُعلَن. وهذا يُكتشف بالاختبار بقارئ شاشة."},{"text":"حقل نصي بلا label وبلا اسم متاح","why":"صحيح. غياب labels النماذج هو بالضبط نوع الإخفاقات الموضوعية البنيوية التي ترصدها القواعد الآلية بشكل موثوق."}],"answer":3},{"q":"لماذا قد ينجح اختبار Playwright هذا مع أن نافذة الحجز في Ticketly فيها إخفاقات تباين؟
\nawait page.goto('/events/friday');\nconst results = await new AxeBuilder({ page }).analyze();\nexpect(results.violations).toEqual([]);Tickets
\n \n \n \n \n \n Festival FAQ\nهذا الجزء من Ticketly ينجح في فحص axe بلا أي مخالفة. ومع ذلك يصطدم مستخدم قارئ الشاشة بأربعة إخفاقات حقيقية في WCAG. اختر الأسطر التي سينبّه إليها مراجع بشري. (.section-title منسّق ليبدو تمامًا مثل عناوين الأقسام الأخرى، وaddToBasket() تكتب “Ticket added” داخل #basket-status.)
السطر 3: alt="image" موجودة، فيرضى axe، لكنها لا تخبر مستخدم قارئ الشاشة بشيء (“image, image”). صِف الصورة، أو إن كانت زخرفية فاستخدم alt="".
السطر 4: تبدو الفقرة عنوانَ قسم لكنها ليست كذلك، فهي غائبة عن التنقّل بين العناوين (1.3.1 Info and Relationships). استخدم <h2>Tickets</h2>.
السطر 8: يتغيّر #basket-status بعد كل نقرة، لكنه ليس live region، فلا تُعلن قارئات الشاشة شيئًا (4.1.3 Status Messages). أضِف role="status".
السطر 9: النص المرئي “Reserve seats” لكن الاسم المتاح “Book”، فمستخدم التحكّم الصوتي الذي يقول “click Reserve seats” لا يحصل على شيء (2.5.3 Label in Name). احذف الـ aria-label. لدى axe قاعدة لهذا، لكنها تجريبية ومعطّلة افتراضيًا.
بقية الأسطر سليمة: حقل الإدخال له label، وللأزرار والرابط أسماء واضحة.
\n","checkLabels":{}},"words":676,"readMinutes":4}