إمكانية الوصول في واجهات المؤسسات: ضعها في نظام التصميم

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

ولم تعد اختيارية في أوروبا أيضاً. فالقانون الأوروبي لإمكانية الوصول (European Accessibility Act)، مع استثناء للمؤسسات متناهية الصغر، يسري على الخدمات البنكية الموجّهة إلى المستهلكين وعلى خدمات التجارة الإلكترونية المقدَّمة للمستهلكين بعد 28 يونيو 2025.¹ وفي الخدمات البنكية للمستهلكين، يطلب الملحق الأول أن تكون وسائل التعريف بالهوية، والتوقيعات الإلكترونية، والأمان، وخدمات الدفع «قابلة للإدراك، وقابلة للتشغيل، ومفهومة، ومتينة».¹

المفاهيم القليلة التي تهمّ

WCAG 2.2 AA هدفاً. يصف MDN معيار WCAG 2.2 بأنه «أحدث إصدار من الإرشادات».² والمستوى AA هدف جيد للفريق لأنه ملموس بما يكفي لاختباره. وفي النماذج البنكية، يهمّ معيار واحد أكثر من غيره: يطلب المعيار 3.3.4 (AA) أن تكون عمليات إرسال البيانات المالية «قابلة للتراجع عنها، أو للتحقق منها، أو لتأكيدها»، مثلاً بخطوة يراجع فيها المستخدم بياناته ويصحّحها قبل أن يصبح الإرسال نهائياً.³ خطوة تأكيد التحويل جزء من إمكانية الوصول، لا من تجربة المستخدم الجيدة فقط.

عناصر HTML الأصلية أولاً، و ARIA ثانياً. يقول دليل Angular إن العناصر الأصلية «تلتقط عدة أنماط تفاعل قياسية»، وإنه «ينبغي أن تعيد استخدام هذه العناصر الأصلية مباشرة متى أمكن».⁴ وحين تحتاج إلى عنصر واجهة لا توفّره HTML، يقولها MDN بوضوح: مع ARIA «أنت المسؤول عن محاكاة سلوك المتصفح المقابل في السكربت».⁵ الدور (role) وعدٌ عليك أن تفي به في الكود.

لوحة المفاتيح والتركيز. في نافذة الحوار المنبثقة (modal dialog): ينتقل التركيز إلى داخلها عند الفتح، ويبقى التنقل بمفتاح الجدولة (Tab) داخلها، ويغلقها مفتاح الهروب (Escape)، وعند الإغلاق «ينبغي أن يعود التركيز إلى حيث كان قبل أن ينتقل إلى نافذة الحوار».⁶⁷ وفي تطبيق الصفحة الواحدة (single-page app)، تغيير المسار هو ما ينساه الناس: يقترح دليل Angular تحديث التركيز عند NavigationEnd، وتجنّب سقوط التركيز على body.⁴

انقر للتكبير

النماذج والأخطاء. وفي النماذج الطويلة الخاضعة للتنظيم يستسلم المستخدمون. وتقولها قائمة فحص WCAG من WebAIM ببساطة: خطأ الإدخال «يُحدَّد بوضوح»، ورسالة الحالة المهمة «يجب أن تُعلَن لمستخدمي قارئات الشاشة» حتى حين لا يكون التركيز عليها.³ وفي التطبيق العملي: <label> حقيقي لكل حقل، وأخطاء بـ role="alert"، وفي النماذج الطويلة ملخّص يربط بكل حقل.

نظام التصميم (design system) يحمل العبء. منتقي تاريخ واحد يراعي إمكانية الوصول أفضل من خمسين إصلاحاً. المكتبة المشتركة هي المكان الذي تُحسم فيه إطارات التركيز (focus rings) والتباين وسلوك لوحة المفاتيح مرة واحدة. ويوفّر CDK في Angular اللبنات الأساسية (cdkTrapFocus و LiveAnnouncer)، ويحيل الدليل الآن إلى Angular Aria للأنماط غير المنسَّقة (headless patterns) مثل combobox والقوائم والتبويبات.⁴ وفي React، تقع هذه المهمة على مكتبة المكوّنات لديك، فاخترها لدعمها للوحة المفاتيح.

الاختبار: أدوات وبشر. الفحوص الآلية في CI تلتقط الأخطاء الرخيصة في كل طلب دمج (pull request). ويوضّح MDN حدودها: «لا يمكنك الاعتماد على الأدوات الآلية وحدها لتحديد مشكلات إمكانية الوصول في موقعك».⁸ ومراجعة بلوحة المفاتيح وقارئ الشاشة على التدفقات الرئيسية تجد الباقي.

ماذا تختار، ومتى

• بناء العناصر الصعبة أو اعتمادها جاهزة: اشترِ أو اعتمد حلاً جاهزاً (CDK، أو Angular Aria، أو مكتبة React ناضجة) لـ combobox ومنتقي التاريخ وشبكة البيانات (data grid)؛ وابنِ فقط ما يخصّ مجالك.
• role="alert" أو خدمة للمنطقة الحيّة (live region): role="alert" لخطأ بجانب حقل؛ و LiveAnnouncer لشيء حدث في مكان آخر («أُرسل التحويل»).
• آلي أو يدوي: كلاهما، دائماً. الآلي في كل طلب دمج، واليدوي على التدفقات التي يهتم بها القانون: تسجيل الدخول، والدفع، والتوقيع.

في Atlas Bank

في ملف القواعد في Atlas Bank هذا السطر: «إعادة التنسيق لا تغيّر التدفق أبداً. التسميات، وأسماء الأزرار، ورسائل role=alert هي ما تقرؤه اختبارات الـ URL؛ أبقِها، وستنجح الاختبارات دون تغيير.» إمكانية الوصول والاختبارات تتقاسمان العقد نفسه.

وتتضمّن رموز التصميم (design tokens) في apps/atlas/src/styles/tokens دوراً باسم --color-focus، بقيمة للوضع الفاتح وأخرى للداكن، ويضع apps/atlas/src/styles/base/_document.scss إطار تركيز افتراضياً على كل :focus-visible. ويُفشل npm run check:tokens أي مكوّن خارج الركن القديم يستخدم لوناً خاماً بدل رمز تصميم.

ويُظهر Atlas النقص أيضاً. ففي الفرع الرئيسي (main)، تعرض شاشة NgModule المجمّدة في libs/legacy/transfers/src/lib/transfer.component.html خطأها في <div class="alert alert-danger"> عادي، بلا role. أما نموذج المستفيدين في AngularJS وشاشة التحويل الجديدة في الوحدة 5 فيستخدمان role="alert". الأركان القديمة تخفي ديوناً قديمة.

ويفحص Atlas قوالبه أصلاً في CI بحثاً عن مشكلات إمكانية الوصول (قواعد إمكانية الوصول في angular-eslint، والركن القديم يعطّل label-has-associated-control). ما لا يملكه بعد: فحص على الصفحة المعروضة، مثل axe في الاختبارات الشاملة (end-to-end)، وفحص تباين على رموز التصميم. كلاهما إضافة صغيرة؛ فـ check:tokens يفحص اليوم أين توجد الألوان، لا هل تتباين بما يكفي.

ما تركته جانباً، ولماذا

• روابط التخطي (skip links)، والنص البديل، وتباين الألوان بوصفها بنوداً منفصلة: فهي تندرج ضمن «عناصر HTML الأصلية أولاً» و«نظام التصميم يحمل العبء».
• طبقات إمكانية الوصول (accessibility overlays). سطر واحد: سكربت الطبقة لا يصلح المكوّنات التي تحتها، فهو ليس طريقاً مختصراً.

مع بداية الأسبوع

• افتح نافذة الحوار في نظام التصميم لديك، ونفّذ خطوات لوحة المفاتيح الأربع المذكورة أعلاه. ثم افعل الشيء نفسه مع أقدم شاشة لديك.
• ابحث عن رسائل الخطأ في النماذج التي لا تحمل role="alert" ولا منطقة حيّة.
• إن كنت تبني لبنك أو متجر في الاتحاد الأوروبي، فاسأل من المسؤول عن معلومات إمكانية الوصول التي يجب أن توفّرها الخدمة. وإن لم يكن هناك أحد، فهذا أول قرار.

لوكيل البرمجة الخاص بك

قواعد هذا المقال، مكتوبة لوكيل. الصقها في ملف AGENTS.md لديك، أو احفظها مهارةً (skill)، أو وجّه وكيلك إلى الملف.

# Accessibility rules for enterprise apps

Source: https://tt-tech.io/blog/enterprise-frontend-accessibility-design-system
For Angular and React frontends. Add to AGENTS.md or save as a skill. Your project's own rules win where they differ.

## Rules

1. Target WCAG 2.2 level AA.
2. Use native HTML elements first (`<label>`, `<dialog>`, native form controls). Use ARIA only for a widget HTML does not have.
3. When you add an ARIA role, implement in script the keyboard and behaviour the browser would give the native element. A role is a promise you keep in code.
4. Every modal dialog: focus moves inside on open, Tab stays inside (`cdkTrapFocus` in Angular), Escape closes, and on close focus returns to where it was before.
5. On a route change in a single-page app, move focus (in Angular, on `NavigationEnd`). Never let focus fall back to `body`.
6. In forms, give every field a real `<label>`, show field errors with `role="alert"`, and on long forms add an error summary that links to each field.
7. Announce something that happened elsewhere on the page ("Transfer sent") through a live region, `LiveAnnouncer` in Angular.
8. Submissions of financial data need a step where the user reviews and corrects before the submission is final (WCAG 3.3.4).
9. Fix accessibility in the shared design-system component, not in each screen. Focus rings, contrast and keyboard behaviour are decided there once.
10. For combobox, date picker and data grid, adopt a tested building block (Angular CDK, Angular Aria, or a mature React library chosen for its keyboard support). Build only what is specific to the domain.
11. Never add an accessibility overlay script as a fix. It does not fix the components underneath.
12. Run automated accessibility checks in CI, and never report a flow as accessible from automated checks alone. Login, payment and signature also need a manual keyboard and screen reader pass.

## Before you say done

- Run the project's accessibility lint (for example angular-eslint's template accessibility rules) and fix every new error.
- Search the diff for form error messages without `role="alert"` or a live region, and for `role=` attributes. For each role, name the code that implements its keyboard behaviour.
- For every new or changed dialog, list in the pull request where the code handles focus in, Tab, Escape and focus return.
- List the manual keyboard and screen reader checks still needed.

المصادر

1. EUR-Lex, Directive (EU) 2019/882 on the accessibility requirements for products and services, 2019
2. MDN, Understanding the Web Content Accessibility Guidelines (WCAG)
3. WebAIM, WebAIM's WCAG 2 Checklist
4. Angular, Accessibility in Angular
5. MDN, ARIA
6. MDN, ARIA: dialog role
7. MDN, <dialog> HTML dialog element
8. MDN, Accessibility tooling and assistive technology