مدخل إلى إمكان الوصول في تطبيقات Windows ── الاستعداد لأتمتة الواجهة ومتطلّبات الترتيبات التيسيرية

«معيَّن في منتصف المسار ضعيف البصر لا يستطيع استخدام تطبيق إدخال الطلبات الأساسيّ بقارئ شاشة. يستخدم متصفّح ويب وبريداً بلا مشكلة، لكنّ قراءة تطبيق أعمالنا وحدها لا تعمل بشكل صحيح. هل يمكن فعل شيء؟» ── استشارات من هذا النوع من أقسام تقنيّة المعلومات لدى العملاء تزداد.

خلفيّة واحدة هي الإطار القانونيّ. تعديل 2021 لقانون القضاء على التمييز ضدّ ذوي الإعاقة دخل حيّز التنفيذ في 1 أبريل 2024، وأصبح «تقديم الترتيبات التيسيرية» لذوي الإعاقة التزاماً على المنشآت أيضاً.¹ كذلك، علاقة موظّف–شركة كالافتتاحيّة (مجال التوظيف) إقليم قانون تعزيز توظيف ذوي الإعاقة، الذي ألزم أصحاب العمل بتقديم الترتيبات التيسيرية منذ أبريل 2016.² فكرة أنّ «إمكان الوصول موضوع مواقع وليس له علاقة بتطبيقات Windows الداخليّة» لم تعد تصمد، لا قانوناً ولا ممارسة.

من جهة أخرى، من أرضيّة التطوير، «لا نعلم ماذا نفعل» مكان صادق. إمكان الوصول لتطبيقات سطح مكتب Windows أقلّ معلوماتاً من الويب، ولا حلّ سحريّ بعد الواقعة. لا حاجة للتشاؤم أيضاً. إن فهمت الآليّة التي تقرأ بها قارئ شاشة تطبيقاً (UI Automation) واستوعبت أساسيّات الاسم ولوحة المفاتيح واللون، تتحسّن قابليّة استخدام تطبيق أعمال جوهريّاً. وكثير من ذلك تحسين يرفع إنتاجيّة كلّ مستخدم، مع إعاقة أو دونها.

موجَّه إلى مطوِّري تطبيقات أعمال يابانيّة وموظّفي تقنيّة المعلومات، يصل هذا المقال في تمريرة واحدة من فرز أدنى للإطار القانونيّ والمعايير، عبر آليّة UI Automation، والتنفيذ في WinForms/WPF، وتشغيل لوحة المفاتيح، واللون والتباين، وأدوات التحقّق، إلى طريقة واقعيّة لوضع الأولويّات.

flowchart TB
    accTitle: تدفّق هذا المقال
    accDescr: بنية هذا المقال، تصل بالترتيب من فرز الإطار القانونيّ والمعايير عبر آليّة UI Automation، والتنفيذ في WinForms وWPF، وتشغيل لوحة المفاتيح، واللون والتباين، وأدوات التحقّق، وكيفيّة وضع الأولويّات
    law["فرز الإطار القانونيّ والمعايير"] --> uia["آليّة UI Automation"]
    uia --> impl["التنفيذ في WinForms/WPF"]
    impl --> kb["تشغيل لوحة المفاتيح"]
    kb --> color["اللون والتباين"]
    color --> verify["أدوات التحقّق"]
    verify --> prio["كيفيّة وضع الأولويّات"]

الشكل 1: يصل هذا المقال الإطار القانونيّ عبر الآليّة والتنفيذ والتحقّق والأولويّات في تدفّق واحد.

1. الخلاصة أوّلاً

• تقديم الترتيبات التيسيرية التزام على المنشآت أيضاً منذ 1 أبريل 2024. عندما يبيّن شخص ذو إعاقة قصداً لإزالة حاجز، تُطلَب استجابة ضمن نطاق ليس عبئاً مفرطاً. مجال التوظيف تحت قانون تعزيز توظيف ذوي الإعاقة، وذلك التزام صاحب عمل منذ أبريل 2016.¹²
• الترتيبات التيسيرية عمليّة «الاستجابة لطلب فرديّ عبر حوار بنّاء»؛ جعل التطبيق أسهل استخداماً مسبقاً «تحسين بيئة» (التزام جهد). الدعم المسبق الكامل ليس الالتزام؛ ما يهمّ ألا ترفض الحوار أحاديّاً.¹
• المعايير التقنيّة لإمكان الوصول مركَّزة في WCAG ‏(JIS X 8341-3:2016). JIS X 8341-3:2016 معيار مقابل بالمحتوى نفسه لـ WCAG 2.0، وWCAG2ICT من W3C يعطي إرشاداً لتطبيقه على برمجيّات غير الويب. يمكن فحص تطبيق سطح مكتب بالتفكير نفسه.³⁴
• قارئ شاشة يقرأ تطبيقاً عبر UI Automation (UIA). الخصائص التي يحملها كلّ عنصر على شجرة UIA ── Name وControlType وما شابه ── وأنماط التحكّم مثل Invoke وValue وSelectionItem هي مادّة الإعلان والتشغيل.⁵
• زرّ Name فيه فارغ يُعلَن فقط «زرّاً». الإصلاح الأعلى أولويّة هو التسمية. WinForms يستخدم AccessibleName وربط Label بترتيب الجدولة؛ WPF يستخدم AutomationProperties.Name/LabeledBy.⁶⁷
• القدرة على بلوغ كلّ وظيفة من لوحة المفاتيح وحدها معيار نجاح WCAG ‏(2.1.1) وفي الوقت نفسه سرعة إدخال مشغِّل ماهر نفسها. وضع ترتيب الجدولة ومفاتيح الوصول وإشارة التركيز يصل مباشرةً إلى كفاءة كلّ مستخدم.⁸
• اتّخذ نسبة تباين نصّ 4.5:1 أو أكثر دليلاً، ولا تنقل معلومات باللون وحده. في سمة تباين (تباين عالٍ)، احترم ألوان النظام لا ألواناً مرمَّزة صلباً.⁸⁹
• اجمع التحقّق مع FastPass في Accessibility Insights for Windows وتحقّقاً عمليّاً بقارئ شاشة. لأنّهما يجلسان على أساس UIA نفسه، هذا العمل يؤتي أيضاً مع أصول اختبار الواجهة الآليّ مثل FlaUI.¹⁰
• لا تحتاج إلى إصلاح كلّ شاشة دفعةً. الترتيب الواقعيّ هو (1) من الشاشات التي يستخدمها ذلك المستخدم، (2) التطوير الجديد مطابق للمعيار، (3) انشر جانبيّاً بإصلاح عناصر تحكّم مشتركة.

بجملة واحدة: دعم إمكان الوصول هو «عرض الاسم والعمليّات الصحيحة على شجرة UIA، والإبقاء على أساسيّات لوحة المفاتيح واللون».

2. فرز الإطار القانونيّ والمعايير ── ما الذي «صار التزاماً» تغيّر

2.1. قانون القضاء على التمييز ضدّ ذوي الإعاقة ── من أبريل 2024، المنشآت أيضاً ملزمة بتقديم الترتيبات التيسيرية

قانون القضاء على التمييز ضدّ ذوي الإعاقة قانون يحظر «معاملة تمييزيّة غير عادلة» لذوي الإعاقة من أجهزة إداريّة ومنشآت، ويتطلّب «تقديم الترتيبات التيسيرية». في تعديل 2021 (ريوا 3)، تقديم الترتيبات التيسيرية من المنشآت، الذي كان التزام جهد، صار التزاماً، ودخل القانون المعدَّل حيّز التنفيذ في 1 أبريل 2024 (ريوا 6).¹

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

تمييزان عمليّان يهمّان هنا.

1. «وجود كلّ شيء في مكانه مسبقاً» ليس ما صار التزاماً. تدابير تحسين مسبقة موجَّهة إلى عدد غير محدَّد من ذوي الإعاقة ── الجانب الليّن كمراجعة دليل وتدريب، والجانب الصلب كجعل منشأة خالية من الحواجز ── تُدعى «تحسين البيئة»، وهذا التزام جهد.¹ وضع تطبيق أعمال في حالة قابلة للاستخدام بقارئ شاشة مسبقاً يمكن التفكير فيه جهداً لتحسين البيئة. كلّما مضى تحسين البيئة أبعد، خفّ عبء تقديم ترتيبات تيسيرية فرديّة.
2. مجال التوظيف ليس تحت قانون القضاء على التمييز ضدّ ذوي الإعاقة بل تحت قانون تعزيز توظيف ذوي الإعاقة. النشرة نفسها تنصّ أيضاً على أنّ التوظيف والعمل يتبعان أحكام قانون تعزيز توظيف ذوي الإعاقة.¹ وتحت ذلك القانون، بالتعديل الذي دخل حيّز التنفيذ في أبريل 2016 (هيسي 28)، حظر التمييز بسبب الإعاقة في التوظيف وتقديم الترتيبات التيسيرية ضمن نطاق ليس عبئاً مفرطاً أُلزِما على أصحاب العمل.² الاستشارة الافتتاحيّة «موظّف لا يستطيع استخدام تطبيق الأعمال» كانت، في الواقع، في مجال الالتزام قبل 2024 بمدّة.

flowchart TB
    accTitle: موضع الترتيبات التيسيرية وتحسين البيئة
    accDescr: علاقة منشأة عامّة وشخص ذي إعاقة تحت قانون القضاء على التمييز، وتقديم الترتيبات التيسيرية بالاستجابة لطلب فرديّ عبر حوار بنّاء التزام منذ أبريل 2024؛ مجال التوظيف التزام صاحب عمل منذ أبريل 2016 تحت قانون تعزيز التوظيف؛ جعل التطبيق أسهل استخداماً مسبقاً تحسين بيئة، التزام جهد
    scene{"أيّ مشهد؟"}
    scene -->|"منشأة + إعاقة"| kaisho["قانون التمييز"]
    scene -->|"توظيف / عمل"| koyou["قانون التوظيف"]
    kaisho --> moushide["طلب عبر حوار"]
    moushide --> hairyo["قدِّم ترتيباً"]
    hairyo -.-> hairyoN["التزام منذ 2024"]
    koyou --> koyougimu["قدِّم ترتيباً"]
    koyougimu -.-> koyouN["التزام منذ 2016"]
    kaisho -.-> kankyo["تطبيق أسهل مسبقاً"]
    kankyo -.-> kankyoN["تحسين بيئة"]
    kankyoN -.-> kankyoN2["التزام جهد"]
    kankyo -.-> moushide

الشكل 2: القانون الحاكم ينقسم حسب المشهد؛ الترتيبات التيسيرية التزام، والإصلاحات المسبقة تحسين بيئة، التزام جهد.

كيف تُعامَل حالة فرديّة في القانون يعتمد على الوضع. هذا المقال لا يدخل التفسير القانونيّ؛ يمضي من وجهة نظر ما يستطيع مهندس فعله عندما تُطلَب استجابة. للمصادر الأوّليّة، راجع موادّ مكتب مجلس الوزراء ووزارة الصحّة والعمل والرعاية.¹²

2.2. JIS X 8341-3 وWCAG ── «معايير الويب» تمتدّ إلى البرمجيّات أيضاً

على جانب المعايير التقنيّة، هي مركَّزة في JIS X 8341-3:2016. هذا المعيار معيار مقابل لـ ISO/IEC 40500:2012، وجسم المعيار المحتوى نفسه لـ WCAG 2.0 من W3C.³ إن أردت أن تعلم ملموسًا ممّ يتكون «دعم إمكان الوصول»، قراءة معايير نجاح WCAG (الآن ممتدّة في WCAG 2.1/2.2) أقصر طريق، وترجمة يابانيّة من WAIC منشورة أيضاً.⁸

سؤال «هل WCAG معيار لمحتوى ويب؟» عادل، لكنّ W3C نظّم، في Group Note يُدعى WCAG2ICT (Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies)، كيفيّة تطبيق معايير نجاح WCAG 2.0/2.1/2.2 على وثائق وبرمجيّات غير الويب.⁴ بعبارة أخرى، تفكير مثل «بدائل نصّ»، و«تباين»، و«تشغيل لوحة مفاتيح»، و«اللون ليس الوسيلة الوحيدة» يمكن تطبيقه على تطبيق سطح مكتب Windows في الإطار نفسه كالويب. الفصول 3 فصاعداً من هذا المقال تُسقط ذلك التفكير في تنفيذ WinForms/WPF ملموس.

flowchart TB
    accTitle: العلاقة بين JIS X 8341-3 وWCAG
    accDescr: JIS X 8341-3:2016 معيار مقابل بالمحتوى نفسه لـ WCAG 2.0، وWCAG2ICT يُظهر كيفيّة تطبيق معايير نجاح WCAG على برمجيّات غير الويب، لذا يمكن فحص تطبيق سطح مكتب Windows في الإطار نفسه
    wcag["WCAG 2.0（W3C）"] ---|"معيار مقابل بالمحتوى نفسه"| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["طبِّق على برمجيّات غير الويب"]
    soft --> app["تطبيق سطح مكتب Windows"]

الشكل 3: JIS X 8341-3:2016 معيار مقابل لـ WCAG 2.0، وWCAG2ICT يمدّ المعايير نفسها إلى تطبيقات سطح المكتب.

3. كيف تقرأ تقنيّة مساعدة تطبيقاً ── ثلاثيّ UI Automation

3.1. شجرة UIA، والخصائص، وأنماط التحكّم

لدى Windows أساس إمكان وصول يُدعى UI Automation (UIA) مبنيّاً فيه. UIA آليّة تتيح لتقنيّة مساعدة كقارئ شاشة الحصول على معلومات واجهة وتشغيل الواجهة بوسائل غير الإدخال القياسيّ، وتتوسّط بين جانب التطبيق (المزوِّد) وجانب التقنيّة المساعدة (العميل).⁵

عالم UIA يمكن فهمه كالثلاثيّ التالي.⁵

عندما تركّز قارئ شاشة زرّاً، الإعلان «زرّ تأكيد الطلب» هو، تقريباً، جمع Name + نوع التحكّم. عندما ينفّذ المستخدم عمليّة «تنفيذ»، تضغط التقنيّة المساعدة ذلك الزرّ عبر نمط Invoke. بعبارة أخرى، إن عُرض Name والأنماط بشكل صحيح يمكن قراءته وتشغيله؛ إن لم تُعرَض، فهو كأنه غير موجود حتّى إن كان مرئيّاً على الشاشة.

flowchart TB
    accTitle: ثلاثيّ UI Automation
    accDescr: التطبيق، بوصفه مزوِّداً، يعرض خصائص كلّ عنصر وأنماط التحكّم على شجرة UIA؛ قارئ الشاشة، بوصفه عميلاً، يعلن Name وControlType ويعمل عبر أنماط مثل Invoke
    app["التطبيق（مزوِّد）"] --> tree["شجرة UIA"]
    tree --> prop["خصائص（Name، ControlType، وما شابه）"]
    tree --> pat["أنماط（Invoke، Value، وما شابه）"]
    sr["قارئ شاشة（عميل）"] -->|"يعلن"| prop
    sr -->|"يشغِّل"| pat

الشكل 4: تستخدم قارئ الشاشة الخصائص والأنماط التي عرضها التطبيق على شجرة UIA للإعلان والتشغيل.

3.2. قارئ شاشة عميل UIA

قارئات الشاشة الرئيسة المستخدمة على Windows تشمل Narrator، المضمَّن في Windows؛ وNVDA،¹¹ الحرّ ومفتوح المصدر؛ وPC-Talker، منتجاً تجاريّاً واسع الاستخدام في اليابان. أسلوب الإعلان يختلف بينها، لكنّ المسار الأوّليّ لقراءة واجهة تطبيق سطح مكتب هو UIA في كلّ حالة. لذلك استجابة جانب التطبيق ليست «دعماً لقارئ شاشة معيّن» بل تتركّز على عرض المعلومات الصحيحة لـ UIA.

flowchart TB
    accTitle: المسار المشترك لقارئات الشاشة الرئيسة
    accDescr: إن عرض التطبيق المعلومات الصحيحة لـ UIA، يمكن لـ Narrator وNVDA وPC-Talker كلّها قراءة الواجهة بالمسار نفسه، لذا استجابة جانب التطبيق ليست موجَّهة لقارئ شاشة معيّن بل تتركّز على العرض لـ UIA
    app["التطبيق"] -->|"يعرض معلومات"| uia["UI Automation（UIA）"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["الاستجابة تتركّز على العرض لـ UIA"]

الشكل 5: قارئات الشاشة الرئيسة كلّها تتّخذ UIA مساراً، لذا تتركّز استجابة التطبيق على العرض لـ UIA.

3.3. بماذا يُعلَن «زرّ Name فيه فارغ»؟

مثال ملموس واحد. افترض أنّ شريط أدوات فيه زرّ حفظ يعرض أيقونة قرص مرن فقط. لمستخدم مبصر الأيقونة تنقل المعنى، لكن إن تُرك Name فارغاً، تعلن قارئ شاشة هذا الزرّ فقط «زرّاً». إن كان «فتح» و«طباعة» المجاوران كذلك، يسمع المستخدم فقط «زرّ، زرّ، زرّ» ولا وسيلة لمعرفة أيّها أيّ. دليل إصلاح إمكان الوصول من مايكروسوفت يسرد أيضاً زرّاً بلا Name، وصورة تُعلَن فقط «Image»، مشكلات ممثِّلة توقف عمل المستخدم.⁷

لحسن الحظّ، عناصر تحكّم WinForms وWPF القياسيّة لديها دعم UIA من البداية، وفي حالات كثيرة يُقرَّر Name تلقائيّاً من نصّ أو تسمية. ما ينكسر عادةً واحد من (1) أيقونة فقط، بلا مادّة لاسم، (2) لا ارتباط بتسمية، أو (3) رسم مخصّص لا يضع معلومات على شجرة UIA. الفصلان التاليان ينظران في كيفيّة إصلاحه لكلّ إطار عمل.

flowchart TB
    accTitle: ثلاث طرق نمطيّة ينكسر بها الإعلان
    accDescr: ينكسر الإعلان عندما لا توجد مادّة لاسم لأنّه أيقونة فقط، أو عندما لا يوجد ارتباط بتسمية، أو عندما رسم مخصّص لا يضع معلومات على شجرة UIA، وينتهي معلَناً فقط زرّاً
    c1["أيقونة فقط، بلا مادّة"] --> broken["Name يصبح فارغاً"]
    c2["لا ارتباط بتسمية"] --> broken
    c3["رسم مخصّص لا يُخرج معلومات"] --> broken
    broken --> result["يُعلَن فقط زرّاً"]

الشكل 6: انكسار الإعلان عادةً يعود إلى واحد من ثلاثة أنماط: مادّة اسم غير كافية، ارتباط غير كافٍ، أو رسم مخصّص.

4. التنفيذ في WinForms ── AccessibleName وترتيب الجدولة

4.1. عناصر تحكّم يصبح Text فيها Name تلقائيّاً، وعناصر لا يصبح

في WinForms، عنصر تحكّم يعرض نصّاً، كـ Button أو CheckBox، يستخدم قيمة خاصّيّة Text كـ UIA Name. بالمقابل، ComboBox وListBox وListView وPictureBox وProgressBar وTabControl وTextBox وTreeView وما شابه لا تجعل Text هو Name. هذه تحتاج اسماً بوسيلة أخرى.⁶

الطريقة الأكثر قابليّة للصيانة هي وضع Label وصفيّ في ترتيب الجدولة السابق مباشرةً لعنصر التحكّم المستهدف. إن ضبطت TabIndex لعنصر التحكّم المستهدف ليأتي فوراً بعد TabIndex لـ Label، يُستخدم نصّ ذلك Label تلقائيّاً كـ UIA Name. التسمية المرئيّة على الشاشة والإعلان يتطابقان، ولا تحتاج إلى إدارة الصياغة مرّتين.⁶¹²

إن لم تستطع وضع Label، اضبط AccessibleName صراحةً. يمكنك أيضاً ضبط AccessibleDescription إن احتيج شرح تكميليّ، وAccessibleRole إن اختلف الدور عن المظهر.¹³

flowchart TB
    accTitle: كيف يُقرَّر اسم عنصر تحكّم WinForms
    accDescr: لـ Button وما شابه، يصبح Text هو UIA Name كما هو؛ لعناصر مثل TextBox لا يُعاد استخدام Text، يُستخدم نصّ Label موضوع في ترتيب الجدولة السابق مباشرةً؛ إن لم تستطع وضع Label، اضبط AccessibleName صراحةً
    ctrl["عنصر تحكّم"] --> qtext{"نوع يصبح Text فيه Name؟"}
    qtext -->|"نعم"| usetext["Text يصبح Name كما هو"]
    qtext -->|"لا"| qlabel{"Label في ترتيب الجدولة السابق مباشرةً؟"}
    qlabel -->|"نعم"| uselabel["نصّ Label يُستخدم كـ Name"]
    qlabel -->|"لا"| explicit["اضبط AccessibleName صراحةً"]

الشكل 7: لـ Name في WinForms، اختر كيفيّة تقريره بترتيب Text، ثمّ Label في ترتيب الجدولة السابق مباشرةً، ثمّ AccessibleName.

// An icon-only toolbar button: state the name for announcement explicitly
saveToolStripButton.AccessibleName = "Save";

// An image-only button: name + a supplementary explanation
btnSearchCustomer.AccessibleName = "Search customer";
btnSearchCustomer.AccessibleDescription = "Search the customer master by customer code or name";

// Set it directly on an input field where you cannot place a Label in the immediately preceding tab order
txtOrderNo.AccessibleName = "Order number";

// A PictureBox reused as a chart display: match the role to the reality as well
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "Monthly order-count chart";

كتحذير، إن ضبطت AccessibleName مرّة في لوحة الخصائص في Visual Studio ثمّ مسحته، يمكن أن يبقى ضبط سلسلة فارغة في ملفّ المصمِّم ويتدخّل في حلّ الاسم الافتراضيّ. احذف السطر المقابل من ملفّ المصمِّم.⁶

flowchart TB
    accTitle: مشكلة بقاء AccessibleName سلسلة فارغة
    accDescr: إن ضبطت AccessibleName مرّة في لوحة الخصائص ثمّ مسحته، يبقى ضبط سلسلة فارغة في ملفّ المصمِّم ويتدخّل في حلّ الاسم الافتراضيّ، لذا تصلحه بحذف السطر المقابل من ملفّ المصمِّم
    set["اضبط AccessibleName"] --> erase["امسحه في لوحة الخصائص"]
    erase --> remain["يبقى ضبط سلسلة فارغة"]
    remain --> block["يتدخّل في حلّ الاسم الافتراضيّ"]
    block -.-> fix["احذف السطر المقابل من ملفّ المصمِّم"]

الشكل 8: مسحه في لوحة الخصائص ما زال يترك سلسلة فارغة، لذا تصلحه بحذف السطر المقابل من ملفّ المصمِّم.

4.2. تحسينات شائعة على شاشة إدخال طلبات

الأماكن التي نصلحها فعلاً كثيراً في تطبيقات أعمال ملخَّصة كقائمة تحقّق.

كلّ منها إصلاح أسطر قليلة، لكن لمستخدم قارئ شاشة هو المفرق بين «شاشة لا تستطيع استخدامها» و«شاشة تستطيع استخدامها».

5. التنفيذ في WPF ── AutomationProperties وAutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

في WPF، عنصر تحكّم Content فيه سلسلة، كـ Button، يستخدم ذلك المحتوى كـ UIA Name. زرّ أيقونة فقط (Image أو Path) بلا مادّة لـ Name، لذا تنصّ عليه بـ AutomationProperties.Name، أو إن وُجد نصّ عرض قريب تربطه بـ AutomationProperties.LabeledBy.⁷

لـ TextBox تحذير مهمّ. يُعاد استخدام Text لـ TextBlock كـ Name، لكنّ Text لـ TextBox يُعرَض على جانب خاصّيّة UIA Value ولا يصبح Name. لحقل إدخال، ربط TextBlock تسمية العرض بـ LabeledBy المرشّح الأوّل. الإعلان والعرض على الشاشة يتطابقان، وتتجنّب أيضاً إدارة الصياغة مرّتين.¹⁴

<!-- An input field: associate the display label with LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="Order number" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- An icon-only button: state the name, and a supplement if needed -->
<Button
    AutomationProperties.Name="Confirm order"
    AutomationProperties.HelpText="Confirm the order being entered and allocate inventory">
    <Path Data="{StaticResource CheckIconGeometry}" Width="16" Height="16" />
</Button>

flowchart TB
    accTitle: كيف يُقرَّر اسم عنصر تحكّم WPF
    accDescr: عنصر تحكّم Content فيه سلسلة يستخدم ذلك المحتوى كـ Name؛ وإلا ربط تسمية عرض قريبة بـ LabeledBy المرشّح الأوّل؛ إن غاب ذلك أيضاً، انصص AutomationProperties.Name؛ Text لـ TextBox يُعرَض على جانب Value، لا كـ Name
    ctrl["عنصر تحكّم"] --> qc{"هل Content سلسلة؟"}
    qc -->|"نعم"| auto["المحتوى يصبح Name"]
    qc -->|"لا"| ql{"تسمية عرض قريبة؟"}
    ql -->|"نعم"| lb["اربط بـ LabeledBy"]
    ql -->|"لا"| nm["اضبط Name صراحةً"]
    tbx["Text لـ TextBox"] -.-> val["يُعرَض كـ Value، لا Name"]

الشكل 9: لـ Name في WPF، قرِّر بترتيب سلسلة Content، ثمّ LabeledBy، ثمّ ضبط صريح؛ Text لـ TextBox لا يصبح Name.

معلومات تكميليّة لا تدخل في Name يمكن عرضها بـ AutomationProperties.HelpText.⁷ كذلك، AutomationId معرِّف يُستخدم لتحديد العناصر في اختبار الواجهة الآليّ، لذا تقرير اصطلاح تسمية وقت تصميم الشاشة يؤتي لاحقاً (مشمول بعمق في «الاختبار الآليّ لواجهة المستخدم في تطبيقات سطح مكتب Windows»).

5.2. عنصر تحكّم مخصّص يحتاج AutomationPeer

عنصر تحكّم مخصّص ترسمه بنفسك لا يستطيع، كما هو، عرض معلومات ذات معنى على شجرة UIA. في WPF تتجاوز OnCreateAutomationPeer على صنف مشتقّ من UIElement وتعيد صنفاً مشتقّاً من AutomationPeer لعرض الاسم والنوع والأنماط. إن كنت ترث عنصر تحكّم قائماً، وراثة الـ Peer المقابل (ButtonBaseAutomationPeer لـ ButtonBase) تتيح لك أخذ سلوك منفَّذ أصلاً.¹⁵

flowchart TB
    accTitle: كيف تُعرَض معلومات عبر AutomationPeer
    accDescr: عنصر تحكّم مخصّص يعرض اسماً ونوعاً وأنماطاً بتجاوز OnCreateAutomationPeer وإعادة صنف مشتقّ من AutomationPeer؛ إن كنت ترث عنصر تحكّم قائماً، ارث الـ Peer المقابل وخذ سلوكاً منفَّذاً أصلاً
    custom["عنصر تحكّم مخصّص"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["أعد صنفاً مشتقّاً من Peer"]
    peer --> pub["اعرض اسماً ونوعاً وأنماطاً"]
    inherit["ارث عنصر تحكّم قائماً"] -.-> basepeer["ارث الـ Peer المقابل"]
    basepeer -.-> reuse["خذ سلوكاً منفَّذاً أصلاً"]

الشكل 10: عنصر تحكّم مخصّص يعيد Peer من OnCreateAutomationPeer ويعرض معلومات لـ UIA.

// An example of a control that custom-draws line status as a coloured lamp
public class StatusLamp : Control
{
    public static readonly DependencyProperty IsOnlineProperty =
        DependencyProperty.Register(nameof(IsOnline), typeof(bool), typeof(StatusLamp),
            new FrameworkPropertyMetadata(false,
                FrameworkPropertyMetadataOptions.AffectsRender, OnIsOnlineChanged));

    public bool IsOnline
    {
        get => (bool)GetValue(IsOnlineProperty);
        set => SetValue(IsOnlineProperty, value);
    }

    internal static string NameFor(bool isOnline)
        => isOnline ? "Line status: online" : "Line status: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // Raise a UIA property-changed event the moment the value changes. Without this,
        // a screen reader keeps the old name and cannot notice the change of state
        if (UIElementAutomationPeer.FromElement((UIElement)d) is AutomationPeer peer)
        {
            peer.RaisePropertyChangedEvent(
                AutomationElementIdentifiers.NameProperty,
                NameFor((bool)e.OldValue), NameFor((bool)e.NewValue));
        }
    }

    protected override AutomationPeer OnCreateAutomationPeer()
        => new StatusLampAutomationPeer(this);
}

public class StatusLampAutomationPeer : FrameworkElementAutomationPeer
{
    public StatusLampAutomationPeer(StatusLamp owner) : base(owner) { }

    protected override AutomationControlType GetAutomationControlTypeCore()
        => AutomationControlType.Text; // Text-equivalent if it is a status display with no operation

    protected override string GetNameCore()
        => StatusLamp.NameFor(((StatusLamp)Owner).IsOnline);
}

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

sequenceDiagram
    accTitle: تدفّق إخبار قارئ شاشة بتغيّر حالة
    accDescr: في لحظة تغيّر قيمة عنصر التحكّم، يرفع AutomationPeer حدث تغيّر خاصّيّة Name؛ التقنيّة المساعدة لا تعيد الجلب وحدها، لذا بلا الحدث تبقى على الاسم القديم ولا تستطيع ملاحظة التغيّر
    participant c as عنصر التحكّم
    participant p as AutomationPeer
    participant s as قارئ الشاشة
    c->>p: قيمة IsOnline تتغيّر
    p->>s: ارفع حدث تغيّر خاصّيّة Name
    s->>s: أعلن الحالة الجديدة
    Note over s: بلا الحدث يبقى على الاسم القديم

الشكل 11: تغيّر قيمة يبلغ قارئ شاشة فقط عندما يخبره AutomationPeer بحدث تغيّر.

إن كان لعنصر التحكّم المخصّص عمليّة (يمكن ضغطه، يمكن تغيير قيمته، يمكن اختياره)، تتجاوز GetPattern وتوفّر واجهة نمط مثل IInvokeProvider أو IRangeValueProvider.¹⁵ النقطة أنّ إن بنيت الـ Peer أيضاً على جانب مكتبة عناصر التحكّم المشتركة، تصبح كلّ شاشة تستخدمه مدعومة تلقائيّاً. ذلك أساس «انشر جانبيّاً» في الفصل 9.

6. هل تستطيع بلوغ كلّ وظيفة من لوحة المفاتيح وحدها؟

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

جولة WinForms لإمكان الوصول تسرد أيضاً، كأساسيّات، وضع تسمية في ترتيب الجدولة السابق مباشرةً لحقل إدخال، ووضع مفاتيح وصول على عناصر التحكّم والقوائم التي يريد المستخدم الانتقال إليها.¹²

ما نريد تأكيده أنّ هذا ليس «تكلفة إضافيّة لدعم الإعاقة». في عمل روتينيّ كإدخال طلبات، ما إذا كنت تستطيع إكمال الإدخال دون رفع يديك عن موضع المنزل هو ما يقرّر إنتاجيّة المشغِّل كما هي. ترتيب جدولة مضطرب أو عمليّة تتطلّب فأرة عيب يحلق قليلاً من إنتاجيّة كلّ مستخدم كلّ يوم. دعم إمكان الوصول وكفاءة لوحة المفاتيح مجرّد اسمين للعمل نفسه (للأولويّات حسب بيئة الاستخدام، انظر أيضاً «تصميم UX لتطبيقات Windows»).

flowchart TB
    accTitle: الأثر المزدوج لترتيب لوحة المفاتيح
    accDescr: وضع ترتيب الجدولة ومفاتيح الوصول وإشارة التركيز ينتج أثرين دفعةً ── مستخدم تقنيّة مساعدة يستطيع بلوغ وظيفة، وسرعة إدخال كلّ مشغِّل ── ووظيفة قابلة للاستخدام بالفأرة فقط كوظيفة غير موجودة
    seibi["رتِّب لوحة المفاتيح"] --> a11y["مستخدمو تقنيّة مساعدة"]
    seibi --> speed["سرعة كلّ مشغِّل"]
    mouse["وظيفة فأرة فقط"] -.-> none["كغير موجودة"]

الشكل 12: ترتيب تشغيل لوحة المفاتيح يحقّق دعم التقنيّة المساعدة والكفاءة لكلّ مستخدم في الوقت نفسه؛ وظيفة فأرة فقط كأنها غير موجودة.

7. اللون والتباين ── 4.5:1 و«اللون ليس الوسيلة الوحيدة»

7.1. دليل نسبة التباين 4.5:1

معيار نجاح WCAG 1.4.3 (Contrast (Minimum)) يتطلّب نسبة تباين 4.5:1 على الأقلّ للنصّ وصور النصّ، و3:1 على الأقلّ للنصّ الكبير.⁸ تصميم حديث يضع نصّاً رماديّاً فاتحاً على خلفيّة بيضاء ليس نادراً في التقصير عن هذا المعيار. مستخدمو تطبيق أعمال يشملون أشخاصاً تغيّر بصرهم ورؤية ألوانهم مع العمر، وأشخاصاً يستخدمونه في بيئة سيّئة الإضاءة كمصنع. اعتد القياس بفاحص تباين عند مراجعة التصميم.

7.2. لا تنقل معلومات باللون وحده

معيار النجاح 1.4.1 (Use of Color) أنّ اللون يجب ألا يكون الوسيلة البصريّة الوحيدة لنقل معلومات.⁸ أمثلة نمطيّة في تطبيق أعمال كما يلي.

• إظهار صفّ خطأ بنصّ أحمر فقط ← وفِّر أيضاً أيقونة خطأ وعمود رسالة
• إظهار حقل مطلوب بلون التسمية فقط ← أضف «*» أو صياغة «مطلوب»
• إظهار حالة بلون المصباح فقط ← اجعله لوناً + شكلاً، أو صياغة («يعمل»، «متوقّف»)

نظراً لتنوّع رؤية الألوان، هذا أيضاً ليس «استجابة خاصّة» بل أساس تصميم عرض.

flowchart TB
    accTitle: استبدال معلومات منقولة باللون وحده
    accDescr: عرض يُظهر خطأ بنصّ أحمر فقط يُستبدَل بأيقونة خطأ زائد عمود رسالة؛ عرض يُظهر حقلاً مطلوباً بلون التسمية فقط يُستبدَل بإضافة صياغة مطلوب؛ عرض يُظهر حالة بلون المصباح فقط يُستبدَل بجمع شكل أو صياغة
    err["خطأ بنصّ أحمر فقط"] --> erra["وفِّر أيضاً أيقونة وصياغة"]
    req["مطلوب بلون التسمية فقط"] --> reqa["أضف صياغة مطلوب"]
    lamp["حالة بلون المصباح فقط"] --> lampa["اجمع لوناً مع شكل أو صياغة"]

الشكل 13: أمثلة نمطيّة للنقل باللون وحده تُستبدَل بجمع أيقونة وصياغة وشكل أو نصّ.

7.3. متابعة سمة تباين (تباين عالٍ)

لدى Windows سمات تباين (سابقاً تباين عالٍ) تبدّل إلى مخطّط ألوان بفصل قويّ للمقدّمة والخلفيّة؛ يستطيع المستخدم اختيار وتحرير سمات مضمَّنة مصمَّمة بحيث تكون نسبة التباين عموماً 7:1 أو أكثر.⁹ المبدأ على جانب التطبيق بسيط: لا تُرمِّز ألواناً صلباً؛ احترم ألوان النظام.

• WinForms: إن تركت ForeColor/BackColor عند الافتراضيّ، تُستخدم إعدادات ألوان المستخدم. حيث طبّقت لوناً من عندك، احكم بـ SystemInformation.HighContrast، بدِّل إلى مخطّط قائم على SystemColors، وتابع تغيّر إعدادات بحدث UserPreferenceChanged.¹²
• WPF/WinUI: إن رجعت إلى موارد فئة SystemColors، تتابع تبديل سمة. أماكن ملأتها بفرشاة من عندك تصبح سبب الانكسار.⁹

flowchart TB
    accTitle: متابعة سمة تباين
    accDescr: أماكن رُمِّز فيها لون صلباً تنكسر عند تبديل إلى سمة تباين، لذا بدِّل إلى مخطّط قائم على SystemColors وتابع بحدث تغيّر إعدادات؛ إن رجعت إلى ألوان نظام تستطيع متابعة ألوان المستخدم تلقائيّاً
    theme["بدِّل إلى سمة تباين"] --> qh{"كيف حُدِّد اللون؟"}
    qh -->|"مرمَّز صلباً"| broken["مخطّط الألوان ينكسر"]
    qh -->|"مرجع لون نظام"| ok["يتابع ألوان المستخدم تلقائيّاً"]
    broken -.-> fix["بدِّل إلى SystemColors"]
    fix -.-> ev["تابع بحدث تغيّر إعدادات"]

الشكل 14: فقط أماكن رُمِّز فيها لون صلباً تنكسر تحت سمة تباين؛ مرجع لون نظام يتابع تلقائيّاً.

كذلك، مستخدم ضعيف البصر كثيراً ما يستخدم تكبيراً عالياً لنظام التشغيل (تحجيم DPI)، لذا دعم الدقّة العالية أيضاً جزء من دعم إمكان الوصول. تطبيق ينكسر تخطيطه عند 125%–200% غير قابل للاستخدام عند تلك النقطة. انظر «دعم الدقّة العالية في WinForms» و«دعم الدقّة العالية في WPF» للتفاصيل.

8. التحقّق عمليّاً ── Accessibility Insights وتحقّق عمليّ بقارئ شاشة

8.1. Accessibility Insights for Windows

توفّر مايكروسوفت Accessibility Insights for Windows أداة تحقّق إمكان وصول لتطبيقات Windows، بثلاثة استخدامات رئيسة.¹⁰

• Live Inspect: مجرّد تحويم الفأرة فوق عنصر أو تركيزه بلوحة المفاتيح، ويمكنك تأكيد خصائص UIA (Name وControlType والأنماط وما شابه). أقصر وسيلة لرؤية «ما Name هذا الزرّ».
• FastPass: فحص خفيف يكشف مشكلات إمكان وصول عالية الأثر في أقلّ من خمس دقائق. مشكلات يمكن الحكم عليها آليّاً، كـ Name ناقص، يمكن جردها لكلّ شاشة جديدة.
• Troubleshooting: يساعد تشخيص وإصلاح مشكلة معيّنة. من مشكلة مكتشفة يمكنك السير مباشرةً إلى أدلّة الإصلاح لكلّ إطار عمل يستشهد بها هذا المقال أيضاً.

Inspect.exe وAccEvent، المضمَّنان في Windows SDK، يمكنهما أيضاً تأكيد شجرة UIA والخصائص، لكنّهما موضوعان كأدوات قديمة، والانتقال إلى Accessibility Insights موصى به الآن.¹⁰

flowchart TB
    accTitle: ثلاثة استخدامات لـ Accessibility Insights
    accDescr: يوفّر Accessibility Insights for Windows تأكيد خصائص UIA بـ Live Inspect، وفحصاً خفيفاً لمشكلات عالية الأثر بـ FastPass، ومساعدة تشخيص وإصلاح مشكلة بـ Troubleshooting؛ الانتقال من أدوات قديمة مثل Inspect.exe موصى به
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["أكِّد خصائص UIA"]
    fast --> fastf["اكشف مشكلات عالية الأثر"]
    ts --> tsf["ساعد التشخيص والإصلاح"]
    legacy["Inspect.exe وما شابه"] -.->|"انتقال موصى به"| ai

الشكل 15: لـ Accessibility Insights الاستخدامات الثلاثة تأكيد واكتشاف وتشخيص، وهو وجهة انتقال من أدوات قديمة.

8.2. تحقّق عمليّ بقارئ شاشة

ما يستطيع فحص أداة تلقائيّ كشفه هو فقط مشكلات يمكن الحكم عليها آليّاً. في النهاية، سر دائماً في عمليّة أعمال حقيقيّة بقارئ شاشة. يمكن بدء Narrator المضمَّن في Windows فوراً بـ Ctrl+مفتاح Windows+Enter، ويمكن إدخال NVDA مجّاناً.¹¹ حيلة التحقّق أن تجرب، دون النظر إلى الشاشة (أو والشاشة مطفأة)، معتمداً فقط على الإعلان، ما إذا كنت تستطيع إكمال مهمّة حقيقيّة مثل «أدخل طلباً واحداً وأكِّده». مشكلات مثل وجود اسم لكنّ ترتيب الإعلان غير متماسك، أو هروب التركيز خارج نافذة نمطيّة، تُوجَد فقط عمليّاً.

flowchart TB
    accTitle: جمع تحقّق أداة وتحقّق عمليّ
    accDescr: ما يستطيع فحصاً تلقائيّاً مثل FastPass كشفه هو فقط مشكلات يمكن الحكم عليها آليّاً؛ الباقي يُوجَد عمليّاً بالسير في عمليّة أعمال حقيقيّة بقارئ شاشة وإيجاد مشكلات ترتيب إعلان وتركيز
    tool["فحص أداة تلقائيّ"] --> kikai["مشكلات يمكن الحكم عليها آليّاً"]
    tool -.-> nokori["مشكلات لا تستطيع كشفها تبقى"]
    nokori --> sr["تحقّق عمليّ بقارئ شاشة"]
    sr --> task["سر في عمليّة أعمال"]
    task --> mieru["مشكلات ترتيب إعلان وتركيز"]

الشكل 16: اجرد مشكلات آليّة بفحص تلقائيّ، وأوجد الباقي بتحقّق عمليّ بقارئ شاشة.

8.3. بناؤه في تدفّق التطوير، والعائد المتبادل مع اختبار الواجهة الآليّ

لكي لا يصبح التحقّق معتمداً على شخص، نوصي ببناء قائمة التحقّق التالية في بنود مراجعة لشاشة جديدة.

وواحد آخر. اختبار الواجهة الآليّ بـ FlaUI وما شابه مبنيّ على UIA نفسه الذي تستخدمه قارئات الشاشة. Name والأنماط التي تضعها لإمكان الوصول تصبح أجزاء شيفرة اختبار، وAutomationId مصمَّم للاختبارات يجعل التنقيح في Live Inspect أسهل. بالمقابل، واجهة لا تظهر في شجرة UIA غير مرئيّة للاختبارات وللتقنيّة المساعدة. إمكان الوصول وقابليّة الاختبار وجهان للاستثمار نفسه («الاختبار الآليّ لواجهة المستخدم في تطبيقات سطح مكتب Windows»).

flowchart TB
    accTitle: العائد المتبادل لإمكان الوصول واختبار الواجهة الآليّ
    accDescr: قارئ شاشة واختبار واجهة آليّ مثل FlaUI مبنيّان على UIA نفسه، لذا يمكن استخدام Name والأنماط التي تضعها من كليهما، وواجهة لا تظهر في شجرة UIA غير مرئيّة من أيّ منهما
    uia["ترتيب شجرة UIA"] --> sr["قارئ شاشة يستطيع قراءتها"]
    uia --> test["يمكن استخدامها في اختبار واجهة آليّ"]
    sr -.-> both["وجهان للاستثمار نفسه"]
    test -.-> both
    hidden["واجهة لا تظهر في UIA"] -.-> invisible["غير مرئيّة من أيّ منهما"]

الشكل 17: لأنّهما يجلسان على أساس UIA نفسه، ترتيب شجرة UIA يؤتي لكلّ من التقنيّة المساعدة واختبار الواجهة الآليّ.

9. كيفيّة وضع الأولويّات ── لا تصلح كلّ شاشة دفعةً

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

1. أصلح من الشاشات التي يستخدمها ذلك المستخدم في العمل. الترتيبات التيسيرية عمليّة استجابة فرديّة لطلب من المعنيّ.¹ أوّلاً دَع الشخص يشغِّل العمل الفعليّ بقارئ شاشة، وحدِّدا معاً أين يعلق. في حالات كثيرة تضيق الشاشات المستخدمة في العمل اليوميّ إلى بضع إلى دزينة، والمشكلات القاتلة بينها (زرّ بلا اسم، زرّ تأكيد لا تستطيع ضغطه من لوحة المفاتيح) يمكن حلّها في إصلاح أيّام.
2. اجعل التطوير الجديد مطابقاً للمعيار. أضف قائمة تحقّق الفصل 8 إلى تعريف الإنجاز، وابنِ شاشات جديدة مدعومة من البداية. بخلاف إصلاح بعد الواقعة، زيادة تكلفة بنائه وقت التصميم طفيفة.
3. انشر جانبيّاً بإصلاح عناصر تحكّم مشتركة. إن نفّذت AccessibleName افتراضيّاً أو AutomationPeer على أجزاء داخليّة مشتركة كحوار بحث أو شبكة أو إدخال تاريخ، يسري دفعةً على كلّ شاشة تستخدمها. حركة أعلى بكثير في كفاءة التكلفة من لمس شاشات فرديّة واحدة فواحدة.

flowchart TB
    accTitle: الطبقات الثلاث لأولويّة الإصلاح
    accDescr: أصلح من الشاشات التي يستخدمها المستخدم في العمل، اجعل التطوير الجديد مطابقاً للمعيار بقائمة تحقّق، وانشر إلى كلّ شاشة بإصلاح عناصر تحكّم مشتركة
    s1["1. أصلح من الشاشات التي يستخدمها المستخدم"] --> s2["2. العمل الجديد مطابق للمعيار"] --> s3["3. انشر جانبيّاً بعناصر مشتركة"]
    s3 -.-> all["يسري دفعةً على كلّ شاشة تستخدمها"]

الشكل 18: لا تتقدّم بإصلاح كلّ شاشة دفعةً بل بالطبقات الثلاث شاشات قيد الاستخدام، وعمل جديد، وأجزاء مشتركة.

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

flowchart TB
    accTitle: تدفّق الحوار البنّاء وسجلّ
    accDescr: استجب لطلب من شخص ذي إعاقة عبر حوار بنّاء؛ نفِّذ إصلاحاً يمكن الاستجابة به؛ لإصلاح عبؤه أثقل ممّا ينبغي، انظر في وسيلة بديلة مع الشخص واتّفقا؛ سجّل ما طُلب وما استُجيب له وما جُعل وسيلة بديلة
    req["طلب"] --> talk["حوار بنّاء"]
    talk --> q{"هل العبء أثقل ممّا ينبغي؟"}
    q -->|"لا"| kaishu["استجب بإصلاح"]
    q -->|"نعم"| alt["انظر في وسيلة بديلة واتّفقا"]
    kaishu --> rec["سجّل التاريخ"]
    alt --> rec

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

10. الخلاصة

• بتعديل قانون القضاء على التمييز ضدّ ذوي الإعاقة الذي دخل حيّز التنفيذ في أبريل 2024، صار تقديم الترتيبات التيسيرية التزاماً على المنشآت أيضاً. مجال التوظيف التزام صاحب عمل منذ 2016 تحت قانون تعزيز توظيف ذوي الإعاقة. جعل التطبيق أسهل استخداماً مسبقاً «تحسين بيئة» (التزام جهد)، وكلّما مضى أبعد خفّت الاستجابات الفرديّة.
• المعايير التقنيّة مركَّزة في WCAG ‏(JIS X 8341-3:2016)، ويمكن تطبيق التفكير نفسه على تطبيق سطح مكتب عبر WCAG2ICT.
• قارئ شاشة يقرأ تطبيقاً عبر UI Automation. ثلاثيّ شجرة UIA والخصائص (Name/ControlType/AutomationId) وأنماط التحكّم هو الأساس.
• الأعلى أولويّة هو Name. WinForms يستخدم AccessibleName وربط Label بترتيب الجدولة؛ WPF يستخدم AutomationProperties.Name/LabeledBy؛ عنصر تحكّم مخصّص يستخدم AutomationPeer.
• القدرة على بلوغ كلّ وظيفة من لوحة المفاتيح وحدها معيار نجاح WCAG وفي الوقت نفسه إنتاجيّة كلّ مشغِّل. رتِّب ترتيب الجدولة ومفاتيح الوصول وإشارة التركيز.
• أساسيّات اللون الثلاث نسبة تباين 4.5:1، واللون ليس الوسيلة الوحيدة، واحترام ألوان النظام في سمة تباين.
• اجمع التحقّق مع FastPass+Live Inspect في Accessibility Insights وتحقّقاً عمليّاً بـ Narrator/NVDA، وابنِه في تدفّق التطوير كقائمة تحقّق لشاشة جديدة.
• لا تصلح كلّ شاشة دفعةً؛ تقدّم بترتيب الشاشات التي يستخدمها المستخدم ← دعم قياسيّ للعمل الجديد ← نشر جانبيّ لعناصر تحكّم مشتركة. الترتيبات التيسيرية عمليّة حوار، وسجلّ التاريخ يحمي المنظّمة.

كخطوة أولى نوصي باختيار واحدة من شاشاتك الرئيسة، تشغيل FastPass في Accessibility Insights for Windows، ثمّ السير في العمل بمفتاح Tab وحده. في ثلاثين دقيقة، يصير موضع تطبيقك الحاليّ ملموساً على نحو مفاجئ.

مقالات ذات صلة

• الاختبار الآليّ لواجهة المستخدم في تطبيقات سطح مكتب Windows ── آليّة UI Automation وبناء اختبارات لا تنكسر بسهولة باستخدام FlaUI
• طريقة التفكير في تصميم UX لتطبيقات Windows - جدول قرار لتحديد ما يُعطى الأولوية في ToC / ToB / المراقبة / الأجهزة الميدانية / الأدوات المقيمة
• دعم الدقّة العالية (High DPI) في WinForms ── أسباب النِّيَة والانكسار على شاشات 4K ومعالجتها الواقعيّة
• التعامل مع الدقّة العالية (DPI) في WPF ── أسباب الضبابيّة والتلطّخ رغم أنّه «يُفترَض أن يكون محصّناً ضدّ DPI» وطرق العلاج
• لماذا يبني كومورا سوفت المواقع الإلكترونية اعتماداً على نظام تصميم وكالة الرقمنة اليابانية؟ ── يمكن الجمع بين الرخص والجودة
• مزالق الخطوط والأحرف اليابانيّة ── معالجة JIS2004 وIVS والأحرف الخارجيّة في تطبيقات الأعمال

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع إصلاحات إمكان الوصول لتطبيقات أعمال WinForms/WPF (دعم قارئات الشاشة، وترتيب تشغيل لوحة المفاتيح، ودعم سمة التباين)، وتنفيذ AutomationPeer على عناصر تحكّم مشتركة، واستشارات تشخيص الحالة الراهنة ووضع الأولويّات بـ Accessibility Insights. يصحّ البدء من مرحلة «نريد أن نؤكّد ما إذا كان موظّف يستطيع استخدام تطبيقنا بقارئ شاشة».

• تطوير تطبيقات Windows
• الاستشارة التقنيّة ومراجعة التصميم
• تواصل معنا

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

هل دعم إمكان الوصول لتطبيق أعمال مطلوب قانوناً؟

تعديل 2021 لقانون القضاء على التمييز ضدّ ذوي الإعاقة دخل حيّز التنفيذ في 1 أبريل 2024، وأصبح تقديم الترتيبات التيسيرية لذوي الإعاقة التزاماً على المنشآت أيضاً. الترتيبات التيسيرية استجابة تزيل، عندما يطلب شخص ذو إعاقة، حاجزاً فرديّاً ضمن نطاق ليس عبئاً مفرطاً؛ جعل التطبيق أسهل استخداماً مسبقاً موضوع كالتزام جهد يُدعى «تحسين البيئة». التوظيف، كالعلاقة بين موظّف والشركة، ليس تحت ذلك القانون بل تحت قانون تعزيز توظيف ذوي الإعاقة، الذي ألزم أصحاب العمل بتقديم الترتيبات التيسيرية منذ التعديل الذي دخل حيّز التنفيذ في أبريل 2016. بعبارة أخرى، وضع «موظّف لا يستطيع استخدام تطبيق الأعمال» في مجال الالتزام منذ مدّة. مدى الذهاب في أيّ حالة يعتمد على الوضع الفرديّ، لذا تؤكّد المصادر الأوّليّة من مكتب مجلس الوزراء ووزارة الصحّة والعمل والرعاية وتقرّر عبر حوار مع المعنيّ.

كيف تقرأ قارئ شاشة تطبيق سطح مكتب Windows؟

قارئات شاشة مثل Narrator وNVDA تقرأ واجهة تطبيق عبر أساس إمكان وصول يُدعى UI Automation (UIA). جانب التطبيق يعرض عناصر الشاشة في بنية تُدعى شجرة UIA؛ لكلّ عنصر خصائص مثل Name (الغرض) وControlType (النوع)، وأنماط تحكّم مثل Invoke (ضغط) وValue (قيمة). تعلن قارئ الشاشة هذه المعلومات «زرّ تأكيد الطلب» وتعمل عبر الأنماط. عناصر تحكّم WinForms وWPF القياسيّة لديها هذه الآليّة من البداية، لذا عمل المطوِّر الرئيس ألا يترك Name فارغاً، وأن يجعل الواجهة قابلة للتشغيل من لوحة المفاتيح، وأن ينفّذ معلومات على عناصر مخصّصة.

على تطبيق WinForms قائم، بماذا نبدأ؟

أقصر طريق تشغيل FastPass في Accessibility Insights for Windows ضدّ الشاشة المستهدفة وجرد عناصر التحكّم التي Name فيها فارغ ومشكلات ترتيب الجدولة. الإصلاحات تبدأ بضبط AccessibleName على أزرار أيقونة فقط، وربط Label في ترتيب الجدولة السابق مباشرةً لحقل إدخال، وترتيب TabIndex بحيث يطابق الترتيب البصريّ. ثمّ ابدأ Narrator أو NVDA وسر في عمليّة أعمال حقيقيّة دون النظر إلى الشاشة، وأكِّد أين تعلق. لا تحتاج إلى إصلاح كلّ شاشة دفعةً؛ البدء من شاشات يستخدمها أحد فعلاً، وجعل الشاشات الجديدة مطابقة لمعيار بقائمة تحقّق، واقعيّ.

ماذا نفعل لدعم التباين العالي (سمة التباين)؟

الأساس ألا تُرمِّز الألوان صلباً وأن تحترم ألوان النظام. في WinForms، اترك ForeColor/BackColor عند الافتراضيّ أو استخدم SystemColors، احكم على الحالة بـ SystemInformation.HighContrast، وتابع تبديلاً بحدث UserPreferenceChanged. في WPF وWinUI أيضاً، إن رجعت إلى موارد فئة SystemColors، تتابع تبديل سمة تلقائيّاً. في الوقت نفسه، توقّف عن نقل معلومات «باللون وحده» ── إظهار خطأ بالأحمر فقط ── واجمعها مع أيقونة أو صياغة. حتّى في السمة العاديّة، اتّخاذ معيار WCAG لنسبة تباين نصّ 4.5:1 أو أكثر دليلاً يجعل الواجهة أيضاً أقرأ لأرضيّة سيّئة الإضاءة ولمستخدمين أكبر سنّاً.

هل دعم إمكان الوصول يساعد أيضاً الاختبار الآليّ للواجهة؟

يفعل. أدوات اختبار الواجهة الآليّ مثل FlaUI مبنيّة على UI Automation نفسه الذي تستخدمه قارئات الشاشة. Name وControlType وأنماط التحكّم التي تضعها لإمكان الوصول يمكن استخدامها كما هي من شيفرة اختبار، وAutomationId مصمَّم للاختبارات يستقرّ تحديد العناصر. بالمقابل، واجهة مرسومة مخصّصة لا تظهر في شجرة UIA غير مرئيّة لقارئ شاشة وللاختبارات. إمكان الوصول والاختبار الآليّ استثمار في الأساس نفسه، لذا وضع أيّ منهما يخفض أيضاً تكلفة الآخر.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

يركّز على تطوير برامج ويندوز، والاستشارات التقنية، والتحقيق في الأخطاء، ويتميّز في المشاريع التي تبقى فيها الأصول القديمة ناشطة، وفي تشخيص الأعطال التي يصعب تحديد سببها.