أساسيات إمكان الوصول في تطبيقات Windows ── UI Automation والاستعداد لإلزام الترتيبات التيسيرية

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

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

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

إمكان الوصول لتطبيقات سطح مكتب Windows أقل معلوماتاً من الويب، ولا سبيل لحلّه كله دفعة بعد الواقعة. غير أن كثيراً من التحسين المطلوب يرفع أيضاً إنتاجية كل مستخدم، مع إعاقة أو دونها.

هذه المقالة مكتوبة لمطوّري تطبيقات الأعمال اليابانية ولموظفي أقسام تقنية المعلومات. تغطي الإطار القانوني والمعايير وكيف يعمل UIA، ثم تنتقل إلى التنفيذ في 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. إصلاح التطبيق مسبقاً يقع تحت «تحسين البيئة» (التزام جهد)، وهو أمر مختلف عن جعل كل شاشة كاملة من البداية.²³
2. الأساس التقني عرض المعلومات على UIA، مع أساسيات الأسماء ولوحة المفاتيح واللون. Name وControlType في شجرة UIA، وأنماط مثل Invoke وValue وSelectionItem، هي مادة الإعلان والتشغيل. التسمية تأتي أولاً. WinForms يعالجها بـ AccessibleName وربط Label بترتيب الجدولة، وWPF بـ AutomationProperties.Name/LabeledBy؛ وترتيب أيضاً تشغيل لوحة المفاتيح، ومخطط ألوان يهتدي بنسبة تباين 4.5:1، وعروضاً لا تعتمد على اللون وحده.¹⁴⁵⁶
3. تحقق وأصلح انطلاقاً من العمل الفعلي. اجمع FastPass في Accessibility Insights مع تحققاً عملياً بقارئ شاشة، واعمل بالترتيب على الشاشات التي يعتمد عليها المستخدم، ثم الشاشات الجديدة، ثم عناصر التحكم المشتركة. التحسينات نفسها تساعد أيضاً الاختبار الآلي للواجهة مثل FlaUI، الذي يستخدم أساس UIA نفسه.⁷

يمكن تنظيم المعايير التقنية حول WCAG. JIS X 8341-3:2016 معيار مقابل بالمحتوى نفسه لـ WCAG 2.0، ويقدّم WCAG2ICT إرشاداً لتطبيقه على برمجيات غير الويب. القسم 2.2 يدخل في التفاصيل.⁸⁹

إن أردت القراءة وفق هدفك، ابدأ من الفصل أدناه.

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

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 16، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

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

هذا القسم يفصل ثلاثة أسئلة: ما الذي صار التزاماً، وأين يقع الإصلاح المسبق، وأي قانون ينطبق في مجال التوظيف.

تقديم المنشآت للترتيبات التيسيرية تغيّر من التزام جهد إلى التزام

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

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

عامل إصلاح التطبيق مسبقاً على أنه «تحسين بيئة»

وجود كل شيء في مكانه مسبقاً ليس ما صار التزاماً. التدابير المتخذة مسبقاً لعدد غير محدد من ذوي الإعاقة، كمراجعة الأدلة والتدريب وجعل المنشآت خالية من الحواجز، تُدعى «تحسين البيئة» وتقع تحت التزام جهد.²

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

حيث يتدخل الموظفون، انظر إلى قانون تعزيز توظيف ذوي الإعاقة

التوظيف والعمل يقعان تحت قانون تعزيز توظيف ذوي الإعاقة، لا تحت قانون القضاء على التمييز ضد ذوي الإعاقة. نشرة مكتب مجلس الوزراء تسجّل هذا التمييز أيضاً.²

تحت قانون تعزيز توظيف ذوي الإعاقة، ألزم التعديل الذي دخل حيّز التنفيذ في أبريل 2016 (هيسي 28) أصحاب العمل بالامتناع عن التمييز بسبب الإعاقة في التوظيف وبتقديم الترتيبات التيسيرية ضمن نطاق ليس عبئاً مفرطاً. السؤال الافتتاحي، «موظف لا يستطيع استخدام تطبيق الأعمال»، كان إذن في مجال الالتزام منذ ما قبل 2024 بمدة.³

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

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

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

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

عندما تقرأ المعايير التقنية بالتفصيل، تنظيمها حول WCAG يعطي أوضح رؤية. JIS X 8341-3:2016 وWCAG وWCAG2ICT ترتبط كما يلي.⁸⁶⁹

على سؤال «أليس WCAG معياراً لمحتوى الويب؟»، WCAG2ICT هو الجسر. اسمه الكامل Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

أفكار مثل بدائل النص، والتباين، وتشغيل لوحة المفاتيح، وعدم نقل معلومات باللون وحده تنطبق على تطبيق سطح مكتب 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 والخصائص وأنماط التحكم

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

ابدأ بفهمه ثلاثياً: بنية الشاشة، وطبيعة كل عنصر، والعمليات المتاحة.¹

على سبيل المثال، إعلان «تأكيد الطلب، زر» عندما يتلقى زر التركيز هو تقريباً توليفة 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 المدمج، و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» مذكورة في أدلة إصلاح Microsoft كمشكلات نمطية توقف عمل المستخدم.⁵

عناصر تحكم WinForms/WPF القياسية تدعم UIA من البداية، ولمعظمها يُشتق Name تلقائياً من نص أو تسمية. الطرق الثلاث النمطية لانكساره كما يلي.

الفصلان التاليان يصلان هذا الفرز بإصلاحات WinForms وWPF على التوالي.

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

الشكل 6: الإعلانات المنكسرة تعود عادة إلى ثلاثة أنماط: نقص مادة الاسم، أو نقص الارتباط، أو الرسم المخصص.

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

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

أولاً، تأكد مما إذا كان عنصر التحكم من نوع يُستخدم Text فيه اسماً

في WinForms، حتى بين عناصر التحكم التي تعرض نصاً، بعضها يستخدم Text كـ UIA Name وبعضها لا يفعل.⁴

استخدم تسمية معروضة، واضبط AccessibleName حيث لا تستطيع وضع واحدة

أسهل مقاربة للصيانة وضع 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.

// زر شريط أدوات بأيقونة فقط: عيّن الاسم للقراءة جهراً صراحة
saveToolStripButton.AccessibleName = "حفظ";

// زر بصورة فقط: الاسم مع وصف مكمّل
btnSearchCustomer.AccessibleName = "البحث عن العملاء";
btnSearchCustomer.AccessibleDescription = "يبحث في سجل العملاء حسب رمز العميل أو الاسم";

// حقل إدخال يتعذّر وضع Label فوراً قبله في ترتيب الجدولة: اضبطه مباشرة
txtOrderNo.AccessibleName = "رقم الطلب";

// PictureBox مستخدم كمخطّط: اجعل الدور يطابق ما هو عليه فعلاً
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "مخطط عدد الطلبات الشهري";

عندما مسحت الاسم لكن الإعلان الافتراضي لا يعود

إن ضبطت 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

أعطِ الزر اسمه عبر Content نصي أو ضبط صريح

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

في TextBox، افصل «الاسم» عن «قيمة الإدخال»

يُعاد استخدام Text لـ TextBlock كـ Name، لكن Text لـ TextBox يُعرَض على خاصية UIA Value ولا يصير Name. حتى عندما يحمل الحقل قيمة، ذلك وحده لا يخبر المستخدم لأي شيء الحقل.¹³

لحقل إدخال، الخيار الأول ربط TextBlock التسمية المعروضة عبر LabeledBy. يتطابق العرض والإعلان، وتتجنب صيانة الصياغة مرتين.¹³

<!-- حقل إدخال: اربط تسمية العرض عبر LabeledBy -->
<TextBlock x:Name="OrderNoLabel" Text="رقم الطلب" />
<TextBox
    AutomationProperties.LabeledBy="{Binding ElementName=OrderNoLabel}"
    AutomationProperties.AutomationId="OrderNoTextBox" />

<!-- زر بأيقونة فقط: اضبط الاسم صراحة وأضف تكملة إن لزم -->
<Button
    AutomationProperties.Name="تأكيد الطلب"
    AutomationProperties.HelpText="يؤكّد الطلب قيد الإدخال ويخصّص المخزون">
    <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.

HelpText وAutomationId يلعبان أدواراً مختلفة عن الاسم

المعلومات التكميلية التي لا تتسع في Name تُعرَض عبر AutomationProperties.HelpText.⁵ AutomationId معرّف يُستخدم أيضاً لتحديد العناصر في الاختبار الآلي للواجهة. تقرير اصطلاح تسمية في مرحلة تصميم الشاشة يؤتي في الاختبارات اللاحقة.

باختصار، Name هو الغرض، وHelpText هو التكملة، وAutomationId هو المعرّف. كيف تُستخدم في الاختبارات الآلية مفصّل في «الاختبار الآلي لواجهة المستخدم في تطبيقات سطح مكتب Windows».

5.2. عناصر التحكم المخصصة تحتاج AutomationPeer

عنصر تحكم مرسوم مخصص لا يستطيع، بذاته، عرض معلومات ذات معنى على شجرة UIA. في WPF، تعرض الاسم والنوع والأنماط بـ تجاوز OnCreateAutomationPeer على صنف مشتق من UIElement وإعادة صنف مشتق من AutomationPeer.¹⁴

إن ورثت من عنصر تحكم قائم، ارث من Peer المقابل أيضاً. لـ ButtonBase مثلاً، استخدام ButtonBaseAutomationPeer يتيح لك حمل السلوك المنفَّذ سلفاً.¹⁴

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.

// مثال عنصر تحكم يرسم حالة الخط كمصباح ملوّن رسماً مخصّصاً
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 ? "حالة الخط: متصل" : "حالة الخط: غير متصل";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // أصدر حدث تغيّر خاصية UIA في اللحظة التي تتغيّر فيها القيمة. بلا ذلك،
        // يُبقي قارئ الشاشة الاسم القديم ولا يلاحظ تغيّر الحالة
        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 مناسب لعرض حالة بلا عمليات

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

أبلغ تغيّرات الحالة، لا الاسم الحالي فقط

يجمع المثال أعلاه أمرين: إعادة اسم يعكس الحالة الحالية، وإصدار حدث تغيّر خاصية Name عندما يتغيّر 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) أن تكون كل الوظيفية قابلة للتشغيل عبر واجهة لوحة مفاتيح.⁶ مستخدمو قارئات الشاشة عموماً لا يستخدمون فأرة، لذا وظيفة لا يمكن بلوغها من لوحة المفاتيح هي نفسها وظيفة غير موجودة.

6.1. افحص الحركة والتنفيذ والموضع الحالي

افحص لا ترتيب الجدولة فحسب، بل أيضاً أن العمليات الرئيسة يمكن تنفيذها وأن التركيز الحالي مرئي.

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

6.2. عمل لوحة المفاتيح يحسّن أيضاً كفاءة الإدخال لكل مستخدم

هذا ليس مجرد «تكلفة إضافية لدعم ذوي الإعاقة». في عمل روتيني مثل إدخال الطلبات، ما إذا كان المشغّل يستطيع إكمال الإدخال دون ترك موضع المنزل يقرر كم معاملة ينجز.

ترتيب جدولة مخلخل أو عملية تتطلب الفأرة عيب يقتطع قليلاً من إنتاجية كل مستخدم كل يوم. عمل إمكان الوصول وكفاءة لوحة المفاتيح اسمان للعمل نفسه. للأولويات حسب بيئة الاستخدام، انظر أيضاً «تصميم 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 الملموسة انظر دليل Microsoft، ولألوان السمة انظر وثائق سمات التباين.¹¹¹⁵

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

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

أدرج الصمود أمام DPI العالي في الفحص نفسه

مستخدمو ضعف البصر كثيراً ما يعملون بمعامل تحجيم OS عالٍ (تحجيم DPI)، لذا دعم DPI العالي جزء أيضاً من إمكان الوصول. تطبيق ينكسر تخطيطه عند 125% إلى 200% غير قابل للاستخدام في تلك البيئة.

للتفاصيل، انظر «دعم DPI العالي في WinForms» و«دعم DPI العالي في WPF».

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

8.1. Accessibility Insights for Windows

يقدّم Accessibility Insights for Windows من Microsoft ثلاث طرق عمل، حسب هدفك.⁷

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

flowchart TB
    accTitle: الأوضاع الثلاثة لـ Accessibility Insights
    accDescr: يوفّر Accessibility Insights for Windows وضع Live Inspect لفحص خصائص UIA، و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 بـ Ctrl+Windows+Enter، أو ثبّت NVDA الحر.¹⁰ بعد ذلك، اختر مهمة ممثلة مثل «أدخل طلباً واحداً وأكّده»، وحاول إكمالها بالإعلانات وحدها، دون النظر إلى الشاشة أو والشاشة مطفأة.

مشكلات مثل ترتيب إعلان مخلخل رغم ضبط الأسماء، أو هروب التركيز خارج حوار نمطي، تُوجد فقط عبر هذا النوع من التحقق العملي.

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

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

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

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

أعد استخدام عمل UIA للاختبارات الآلية

الاختبار الآلي للواجهة بـ 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. كيفية وضع الأولويات ── لا تصلح كل شاشة دفعة واحدة

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

9.1. ابدأ بالشاشات التي يعتمد عليها ذلك المستخدم في العمل

الترتيبات التيسيرية عملية استجابة فردية لطلب الشخص.² أولاً اجعل الشخص يشغّل عمله الفعلي بقارئ شاشة، وحدّدا معاً أين يعلق.

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

9.2. اجعل التطوير الجديد مطابقاً كمعيار

أضف قائمة تحقق الفصل 8 إلى تعريف الإنجاز (Definition of Done). السياسة أن الشاشات الجديدة تُبنى مطابقة من البداية. بخلاف التركيب اللاحق، بناؤه في وقت التصميم يضيف تكلفة صغيرة فقط.

9.3. انشر عبر الشاشات بإصلاح عناصر التحكم المشتركة

نفّذ قيم AccessibleName الافتراضية وAutomationPeer في حوارات البحث المشتركة الداخلية، والشبكات، ومدخلات التاريخ، وما شابه. أصلح مكوّناً مشتركاً، فيسري الإصلاح دفعة على كل شاشة تستخدمه. حركة أعلى مردوداً من إصلاح الشاشات الفردية واحدة فواحدة.

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

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

9.4. سجّل مجرى الحوار، لا الإصلاحات فقط

بقدر أهمية العمل التقني سجل الحوار. الترتيبات التيسيرية عملية حديث وتعديل حالة بحالة، لا تلبية كل طلب بالكامل.

لإصلاحات ستكون عبئاً مفرطاً، النظر والاتفاق مع الشخص على بدائل، كأداء المهمة على شاشة مختلفة، أو توفير تصدير 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. الأساس شجرة UIA وخصائصها (Name/ControlType/AutomationId) وأنماط التحكم. التسمية، الأعلى أولوية، تُعالَج بـ AccessibleName وLabel مع ترتيب الجدولة في WinForms، وAutomationProperties.Name/LabeledBy في WPF، وAutomationPeer لعناصر التحكم المخصصة.

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

العملية تسير بترتيب الشاشات التي يعتمد عليها المستخدم، والتطوير الجديد المطابق كمعيار، والنشر عبر عناصر التحكم المشتركة. اجمع FastPass وLive Inspect في Accessibility Insights مع تحققاً عملياً في Narrator/NVDA، وابنِها في تدفّق التطوير كقائمة تحقق للشاشات الجديدة.

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

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

• الاختبار الآلي لواجهة المستخدم في تطبيقات سطح مكتب Windows ── آلية UI Automation وبناء اختبارات لا تنكسر بسهولة باستخدام FlaUI
• تصميم UX لتطبيقات Windows - أولويات حسب بيئة الاستخدام
• دعم DPI العالي في WinForms ── أسباب الضبابية والانهيار على شاشات 4K والمعالجة الواقعية
• دعم DPI العالي في WPF ── أسباب الضبابية والتلطّخ رغم أنه «يفترض أن يكون محصّناً ضد DPI» وطرق العلاج
• لماذا يبني كومورا سوفت المواقع اعتماداً على نظام التصميم Digital Agency؟ ── يمكن الجمع بين الرخص والجودة
• مطبات الخطوط والأحرف اليابانية ── معالجة JIS2004 وIVS وgaiji في تطبيقات الأعمال

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

تتعامل شركة كومورا سوفت ذ.م.م. مع إصلاحات إمكان الوصول لتطبيقات أعمال 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 غير مرئية لقارئات الشاشة وللاختبارات على حد سواء. إمكان الوصول والاختبار الآلي استثمار في الأساس نفسه، لذا وضع أي منهما يخفض أيضاً تكلفة الآخر.

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

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

غو كومورا

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

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