יסודות נגישות באפליקציות Windows — UI Automation והכנה לחובת reasonable accommodation

“עובד עם לקות ראייה לא יכול להשתמש באפליקציית הזנת ההזמנות המרכזית עם screen reader. הוא משתמש בדפדפן ובדואר בלי בעיה, אבל רק באפליקציה העסקית שלנו ההכרזות לא עובדות.” שאלות מהסוג הזה ממחלקות IT של לקוחות הולכות וגדלות.

נקודת ההתחלה לפתרון היא להסתכל על מה אתם אומרים ל-assistive technology, לא על איך המסך נראה. ל-Windows יש UI Automation (UIA), המנגנון שבו screen readers קוראים את מידע האפליקציה. ברגע שמבינים איך הוא עובד ומכסים את היסודות של שמות, מקלדת וצבע, השימושיות של אפליקציה עסקית משתפרת מהותית.¹

גם בצד החוק, אפליקציות Windows פנימיות אינן פטורות. תיקון 2021 לחוק ביטול האפליה נגד אנשים עם מוגבלות נכנס לתוקף ב-1 באפריל 2024, ומתן reasonable accommodation הפך לחובה גם לעסקים. תחום התעסוקה, כמו בדוגמה שבפתיחה, נכנס תחת חוק קידום תעסוקת אנשים עם מוגבלות במקום, והוא חובת מעסיק מאז אפריל 2016. פרק 2 מסדר את ההבדל הזה.²³

ל-accessibility של אפליקציות desktop של Windows יש פחות מידע מאשר לאינטרנט, ואין דרך לפתור הכול בבת אחת בדיעבד. הרבה מהשיפור הנחוץ, עם זאת, גם מעלה את הפרודוקטיביות של כל משתמש, עם מוגבלות או בלי.

המאמר כתוב למפתחי אפליקציות עסקיות יפניות ולאנשי IT. הוא מכסה את המסגרת החוקית והתקנים ואיך 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. מפרידים reasonable accommodation אישי משיפור סביבה מראש. Reasonable accommodation הוא תהליך של מענה לפנייה בדיאלוג בונה, בטווח שאינו נטל מופרז. עסקים מחויבים מאז אפריל 2024, ומעסיקים בתחום התעסוקה מאז אפריל 2016. תיקון אפליקציה מראש נכנס ל-“שיפור הסביבה” (חובת מאמץ), שזה עניין אחר מלגרום לכל מסך להיות מושלם מההתחלה.²³
2. התשתית הטכנית היא חשיפת מידע ל-UIA, פלוס יסודות של שמות, מקלדת וצבע. ה-Name וה-ControlType של עץ UIA, ו-patterns כמו Invoke, Value ו-SelectionItem, הם החומר להכרזה ולהפעלה. מתן שם בא קודם. WinForms מטפל בזה עם AccessibleName והשיוך בין Label לסדר Tab, WPF עם AutomationProperties.Name/LabeledBy; גם מפעילים מקלדת, סכמת צבעים שמונחית ביחס ניגודיות 4.5:1, ותצוגות שאינן נסמכות על צבע בלבד.¹⁴⁵⁶
3. בודקים ומתקנים החל מהעבודה בפועל. משלבים FastPass ב-Accessibility Insights עם בדיקות מעשיות ב-screen reader, ועובדים דרך המסכים שהמשתמש נסמך עליהם, אחר כך מסכים חדשים, אחר כך פקדים משותפים, בסדר הזה. אותם שיפורים גם עוזרים לבדיקות UI אוטומטיות כמו FlaUI, שמשתמשות באותה תשתית UIA.⁷

תקני הטכנולוגיה אפשר לארגן סביב WCAG. JIS X 8341-3:2016 הוא תקן מקביל עם אותו תוכן כמו WCAG 2.0, ו-WCAG2ICT מספק הנחיה ליישום על תוכנה שאינה Web. סעיף 2.2 נכנס לפרטים.⁸⁹

אם רוצים לקרוא לפי מטרה, מתחילים מהפרק למטה.

במשפט אחד, תמיכת accessibility פירושה “לחשוף שמות והפעלה נכונים בעץ UIA, ולשמור על יסודות מקלדת וצבע.”

ב-diagram, solid line מציינת relation שתמיד מתקיים ו-dashed line מציינת relation מותנה (התנאים מופיעים בהסבר של כל relation ב-detail page). הרשימה המלאה של ה-relations (סה”כ 16, כולל evidence ו-certainty) וההגדרות של ה-concepts המרכזיים נמצאות ב-detail page של ה-knowledge map (ביפנית). Data: JSON-LD / Turtle

2. המסגרת החוקית והתקנים — מה ה”חובה” שינתה

2.1. חוק ביטול האפליה נגד אנשים עם מוגבלות — מאז אפריל 2024, גם עסקים חייבים לספק reasonable accommodation

הסעיף הזה מפריד שלוש שאלות: מה הפך לחובה, איפה תיקונים מראש נכנסים, ואיזה חוק חל בתחום התעסוקה.

Reasonable accommodation בידי עסקים השתנה מחובת מאמץ לחובה

חוק ביטול האפליה נגד אנשים עם מוגבלות אוסר על רשויות מנהליות ועסקים “טיפול מפלה בלתי צודק” באנשים עם מוגבלות ודורש מהם “לספק reasonable accommodation.” עם תיקון 2021 (Reiwa 3), מתן reasonable accommodation בידי עסקים, עד אז חובת מאמץ, הפך לחובה, והתיקון נכנס לתוקף ב-1 באפריל 2024 (Reiwa 6).²

העלון של משרד הקבינט מסביר זאת כמענה, בטווח שאינו נטל מופרז, כשאדם עם מוגבלות מביע רצון להסיר מחסום. כי הפרטים שונים לפי סוג מוגבלות, סצנה ומצב, “דיאלוג בונה,” שבו האדם והעסק מדברים ושוקלים אפשרויות יחד, חשוב. העלון קובע במפורש שסירוב חד-צדדי לדיאלוג יכול להוות הפרה של חובת הסיפוק.²

מתייחסים לתיקוני אפליקציה מראש כאל “שיפור סביבה”

להיות עם הכול במקום מראש אינו מה שהפך לחובה. אמצעים שננקטים מראש למספר לא מוגדר של אנשים עם מוגבלות, כמו תיקון מדריכים, הכשרה והפיכת מתקנים לנגישים, נקראים “שיפור סביבה” וממוקמים כחובת מאמץ.²

העמדת אפליקציה עסקית במצב ש-screen reader יכול להשתמש בו מראש אפשר לראות כמאמץ בצד שיפור הסביבה הזה. ככל שהשיפור הזה הלך רחוק יותר, כך נטל מתן reasonable accommodation אישי קל יותר.

במקום שמעורבים עובדים, מסתכלים על חוק קידום תעסוקת אנשים עם מוגבלות

תעסוקה ועבודה מכוסות בחוק קידום תעסוקת אנשים עם מוגבלות, לא בחוק ביטול האפליה. גם עלון משרד הקבינט מציין את ההבחנה הזו.²

תחת חוק קידום התעסוקה, התיקון שנכנס לתוקף באפריל 2016 (Heisei 28) מחייב מעסיקים להימנע מאפליה על רקע מוגבלות בתעסוקה ולספק reasonable accommodation בטווח שאינו נטל מופרז. השאלה שבפתיחה, “עובד לא יכול להשתמש באפליקציה העסקית,” נמצאת לכן בתחום החובה כבר הרבה לפני 2024.³

flowchart TB
    accTitle: איפה reasonable accommodation ושיפור סביבה נכנסים
    accDescr: היחס בין עסק כללי לאדם עם מוגבלות נכנס תחת חוק ביטול האפליה, ומתן reasonable accommodation במענה לפנייה אישית בדיאלוג בונה הוא חובה מאז אפריל 2024; תחום התעסוקה הוא חובת מעסיק מאז אפריל 2016 תחת חוק קידום התעסוקה; תיקון אפליקציה מראש נכנס לשיפור סביבה, חובת מאמץ
    scene{"איזו סצנה?"} -->|עסק ואדם עם מוגבלות| kaisho["חוק ביטול האפליה נגד אנשים עם מוגבלות"]
    scene -->|תעסוקה ועבודה| koyou["חוק קידום תעסוקת אנשים עם מוגבלות"]
    kaisho --> moushide["מענה לפניות אישיות בדיאלוג בונה"]
    moushide --> hairyo["מתן reasonable accommodation (חובה מאז אפריל 2024)"]
    koyou --> koyougimu["מתן reasonable accommodation (חובה מאז אפריל 2016)"]
    kaisho -.-> kankyo["תיקוני אפליקציה מראש = שיפור סביבה (חובת מאמץ)"]
    kankyo -.-> moushide

איור 2: החוק החל תלוי בסצנה; reasonable accommodation הוא חובה, ותיקונים מראש נכנסים לשיפור סביבה, חובת מאמץ.

איך מקרה אישי מטופל בחוק תלוי במצב. המאמר הזה אינו נכנס לפרשנות משפטית; הוא ממשיך מנקודת המבט של מה מהנדס יכול לעשות כשמבקשים ממנו להגיב. למקורות ראשוניים, ראו את החומרים ממשרד הקבינט וממשרד הבריאות, העבודה והרווחה.²³

2.2. JIS X 8341-3 ו-WCAG — “קריטריוני ה-Web” מתרחבים גם לתוכנה

כשקוראים את תקני הטכנולוגיה בפירוט, ארגון סביב WCAG נותן את התמונה הברורה ביותר. JIS X 8341-3:2016, WCAG ו-WCAG2ICT קשורים זה לזה כך.⁸⁶⁹

לשאלה “האם WCAG אינו תקן לתוכן Web?”, WCAG2ICT הוא הגשר. שמו המלא הוא Guidance on Applying WCAG 2 to Non-Web Information and Communications Technologies.⁹

רעיונות כמו חלופות טקסט, ניגודיות, הפעלה במקלדת, ואי-העברת מידע בצבע בלבד חלים על אפליקציית desktop של Windows באותו מסגרת. מפרק 3 ואילך, המאמר הופך אותם למימוש WinForms/WPF.

flowchart TB
    accTitle: הקשר בין JIS X 8341-3 ל-WCAG
    accDescr: JIS X 8341-3:2016 הוא תקן מקביל עם אותו תוכן כמו WCAG 2.0, ו-WCAG2ICT מראה איך ליישם את קריטריוני ההצלחה של WCAG על תוכנה שאינה Web, כך שאפליקציית desktop של Windows אפשר לבדוק באותו מסגרת
    wcag["WCAG 2.0 (W3C)"] ---|תקן מקביל עם אותו תוכן| jis["JIS X 8341-3:2016"]
    wcag --> ict["WCAG2ICT"]
    ict --> soft["מיושם על תוכנה שאינה Web"]
    soft --> app["אפליקציות desktop של Windows"]

איור 3: JIS X 8341-3:2016 הוא תקן מקביל של WCAG 2.0, ו-WCAG2ICT מרחיב את אותם קריטריונים לאפליקציות desktop.

3. איך assistive technology קוראת אפליקציה — שלישיית UI Automation

3.1. עץ UIA, properties ו-control patterns

UI Automation (UIA), המובנה ב-Windows, הוא תשתית ה-accessibility שמתווכת בין האפליקציה ל-assistive technology. האפליקציה חושפת מידע UI כ-“provider”, ו-assistive technology כמו screen reader מקבלת אותו כ-“client”. גם הפעלת UI באמצעים שאינם קלט סטנדרטי מתאפשרת במנגנון הזה.¹

מתחילים בהבנה כשלישייה: מבנה המסך, טבע כל רכיב, והפעולות הזמינות.¹

למשל, ההכרזה “אישור הזמנה, כפתור” כשכפתור מקבל focus היא בערך הצירוף של Name וסוג הפקד. כשהמשתמש מנפיק פקודת ביצוע, assistive technology לוחצת על הכפתור דרך Invoke pattern.

במילים אחרות, כפתור שמצויר על המסך וכפתור שניתן לקריאה ולהפעלה בידי assistive technology הם שני דברים שונים. אם Name וה-patterns אינם חשופים נכון, הכפתור כאילו אינו קיים, אף על פי שהוא נראה על המסך.

flowchart TB
    accTitle: שלישיית UI Automation
    accDescr: האפליקציה, כ-provider, חושפת properties ו-control patterns של כל רכיב על עץ UIA; ה-screen reader, כ-client, מכריז על Name ו-ControlType ופועל דרך patterns כמו Invoke
    app["אפליקציה (provider)"] --> tree["עץ UIA"]
    tree --> prop["Properties (Name, ControlType וכו')"]
    tree --> pat["Patterns (Invoke, Value וכו')"]
    sr["Screen reader (client)"] -->|מכריז| prop
    sr -->|מפעיל| pat

איור 4: ה-screen reader משתמש ב-properties וב-patterns שהאפליקציה חשפה על עץ UIA להכרזה ולהפעלה.

3.2. Screen reader הוא UIA client

ה-screen readers העיקריים ב-Windows הם Narrator המובנה, NVDA החופשי והקוד-פתוח,¹⁰ ו-PC-Talker, מוצר מסחרי בשימוש נרחב ביפן.

לכל אחד סגנון הכרזה משלו, אבל הנתיב העיקרי לקריאת UI של אפליקציית desktop הוא UIA בכל מקרה. לכן העבודה בצד האפליקציה מתכנסת לחשיפת מידע נכון ל-UIA, ולא לכיוון ל-screen reader מסוים.

flowchart TB
    accTitle: הנתיב המשותף של ה-screen readers העיקריים
    accDescr: אם האפליקציה חושפת מידע נכון ל-UIA, Narrator, NVDA ו-PC-Talker כולם יכולים לקרוא את ה-UI באותו נתיב, כך שהעבודה בצד האפליקציה אינה מכוונת ל-screen reader מסוים אלא מתכנסת לחשיפת מידע ל-UIA
    app["אפליקציה"] -->|חושפת מידע| uia["UI Automation (UIA)"]
    uia --> nar["Narrator"]
    uia --> nvda["NVDA"]
    uia --> pct["PC-Talker"]
    app -.-> goal["העבודה מתכנסת לחשיפה ל-UIA"]

איור 5: ה-screen readers העיקריים כולם עוברים דרך UIA, כך שעבודת האפליקציה מתכנסת לחשיפת מידע ל-UIA.

3.3. כפתור ש-Name שלו ריק מוכרז כמה?

נניח שלסרגל כלים יש כפתור שמירה שמציג רק אייקון דיסקט. אף על פי שהמטרה ברורה חזותית, אם Name נשאר ריק ה-screen reader מכריז לא יותר מ-“כפתור”. אם “פתיחה” ו”הדפסה” השכנים באותו מצב, המשתמש שומע רק “כפתור, כפתור, כפתור” ואינו יכול להבחין ביניהם.

כפתורים בלי 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 וסדר Tab

4.1. פקדים שטקסט שלהם הופך ל-Name אוטומטית, ופקדים שלא

קודם בודקים אם הפקד הוא מסוג ש-Text שלו משמש כ-Name

ב-WinForms, גם בין פקדים שמציגים טקסט, חלק משתמשים ב-Text כ-UIA Name וחלק לא.⁴

משתמשים בתווית תצוגה, ומגדירים AccessibleName במקום שאי אפשר לשים אחת

הגישה הקלה ביותר לתחזוקה היא לשים Label תיאורי מיד לפני הפקד היעד בסדר ה-Tab. אם TabIndex של הפקד היעד מגיע ישירות אחרי TabIndex של ה-Label, הטקסט של ה-Label משמש כ-UIA Name. התצוגה וההכרזה תואמות, ונמנעים מתחזוקת הניסוח פעמיים.⁴¹¹

במקום שאי אפשר לשים Label, מגדירים AccessibleName במפורש. אפשר גם להגדיר AccessibleDescription למידע משלים, ו-AccessibleRole כשהתפקיד צריך להתאים למה שהפקד באמת עושה.¹²

flowchart TB
    accTitle: איך שם של פקד WinForms מוכרע
    accDescr: ל-Button ודומים, Text הופך ל-UIA Name כמו שהוא; לפקדים כמו TextBox ש-Text שלהם אינו בשימוש חוזר, הטקסט של Label שמונח מיד לפני בסדר Tab משמש; במקום שאי אפשר לשים Label, AccessibleName מוגדר במפורש
    ctrl["פקד"] --> qtext{"Text הופך ל-Name?"}
    qtext -->|כן| usetext["Text משמש כ-Name כמו שהוא"]
    qtext -->|לא| qlabel{"Label מיד לפני בסדר Tab?"}
    qlabel -->|כן| uselabel["הטקסט של ה-Label משמש כ-Name"]
    qlabel -->|לא| explicit["מגדירים AccessibleName במפורש"]

איור 7: Name ב-WinForms מוכרע בסדר Text, ה-Label מיד לפני בסדר Tab, ואז AccessibleName.

// כפתור סרגל כלים עם אייקון בלבד: מגדירים במפורש את השם להקראה
saveToolStripButton.AccessibleName = "שמירה";

// כפתור עם תמונה בלבד: שם + תיאור משלים
btnSearchCustomer.AccessibleName = "חיפוש לקוחות";
btnSearchCustomer.AccessibleDescription = "מחפש במאגר הלקוחות לפי קוד לקוח או שם";

// שדה קלט שאי אפשר לשים לפניו Label בסדר ה-tab: מגדירים ישירות
txtOrderNo.AccessibleName = "מספר הזמנה";

// PictureBox שמשמש כתרשים: גם התפקיד צריך להתאים למה שזה בפועל
pictureBoxChart.AccessibleRole = AccessibleRole.Chart;
pictureBoxChart.AccessibleName = "תרשים מספר הזמנות לפי חודש";

כשניקיתם את ה-Name אבל הכרזת ברירת המחדל לא חוזרת

אם מגדירים AccessibleName פעם אחת בחלונית Properties של Visual Studio ואז מנקים אותו, הגדרה עם מחרוזת ריקה יכולה להישאר בקובץ ה-designer. אם ההגדרה הזו חוסמת את פתרון השם ברירת המחדל, מוחקים את השורה מקובץ ה-designer.⁴

flowchart TB
    accTitle: בעיית AccessibleName של מחרוזת ריקה שנשארת
    accDescr: אם מגדירים AccessibleName פעם אחת בחלונית Properties ואז מנקים, הגדרת מחרוזת ריקה נשארת בקובץ ה-designer וחוסמת את פתרון השם ברירת המחדל, כך שמתקנים במחיקת השורה מקובץ ה-designer
    set["הגדרת AccessibleName"] --> erase["ניקוי בחלונית Properties"]
    erase --> remain["הגדרת מחרוזת ריקה נשארת"]
    remain --> block["חוסמת את פתרון השם ברירת המחדל"]
    block -.-> fix["מוחקים את השורה מקובץ ה-designer"]

איור 8: ניקוי הערך בחלונית Properties משאיר מחרוזת ריקה מאחור, כך שמתקנים במחיקת השורה מקובץ ה-designer.

4.2. שיפורים נפוצים במסך הזנת הזמנות

הנה רשימת בדיקה של המקומות שאנחנו מתקנים הכי הרבה באפליקציות עסקיות.

כל אחד הוא תיקון של כמה שורות, אבל למשתמש screen reader זה ההבדל בין מסך שאי אפשר להשתמש בו למסך שאפשר.

5. מימוש ב-WPF — AutomationProperties ו-AutomationPeer

5.1. AutomationProperties.Name / LabeledBy / HelpText

נותנים לכפתור את השם דרך תוכן מחרוזת או הגדרה מפורשת

בפקד ש-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 הוא מזהה שמשמש גם לאיתור רכיבים בבדיקות UI אוטומטיות. החלטת מוסכמת שמות בשלב עיצוב המסך משתלמת בבדיקות מאוחרות.

בקצרה, Name הוא המטרה, HelpText הוא ההשלמה, ו-AutomationId הוא המזהה. איך הם בשימוש בבדיקות אוטומטיות מכוסה בפירוט ב”בדיקות UI אוטומטיות לאפליקציות desktop של Windows”.

5.2. פקדים מותאמים צריכים AutomationPeer

פקד מצויר-מותאם אינו יכול, לבדו, לחשוף מידע משמעותי על עץ UIA. ב-WPF, חושפים שם, סוג ו-patterns בדריסת OnCreateAutomationPeer על מחלקה נגזרת מ-UIElement והחזרת מחלקה נגזרת מ-AutomationPeer.¹⁴

אם יורשים מפקד קיים, יורשים גם מה-Peer המתאים. ל-ButtonBase, למשל, שימוש ב-ButtonBaseAutomationPeer מאפשר לשאת הלאה את ההתנהגות שכבר ממומשת.¹⁴

flowchart TB
    accTitle: איך AutomationPeer חושף מידע
    accDescr: פקד מותאם חושף שם, סוג ו-patterns בדריסת OnCreateAutomationPeer והחזרת מחלקה נגזרת מ-AutomationPeer; אם הוא יורש פקד קיים, הוא יורש את ה-Peer המתאים ונושא הלאה את ההתנהגות שכבר ממומשת
    custom["פקד מותאם"] --> ov["OnCreateAutomationPeer"]
    ov --> peer["מחזירים מחלקה נגזרת מ-Peer"]
    peer --> pub["חושפים שם, סוג ו-patterns"]
    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 ? "מצב קו: online" : "מצב קו: offline";

    private static void OnIsOnlineChanged(DependencyObject d, DependencyPropertyChangedEventArgs e)
    {
        // מעלים event שינוי מאפיין UIA ברגע שהערך משתנה. בלעדיו
        // ה-screen reader שומר את השם הישן ולעולם אינו שם לב לשינוי המצב
        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);
}

מודיעים על שינויי מצב, לא רק על השם הנוכחי

הדוגמה למעלה משלבת שני דברים: החזרת שם שמשקף את המצב הנוכחי, והעלאת event שינוי מאפיין Name כש-IsOnline משתנה.

תפקיד ה-Peer אינו רק להחזיר את השם אלא גם לאותת על השינוי ב-event ברגע שהוא קורה. ל-assistive technology אין תזמון משלה לשליפה מחדש של ערך, כך שבלי ה-event המימוש הוא “נכון רק כששואלים שוב,” ומשתמשי screen reader לעולם אינם לומדים שהמצב השתנה.

sequenceDiagram
    accTitle: איך שינוי מצב מגיע ל-screen reader
    accDescr: ברגע שערך הפקד משתנה, ה-AutomationPeer מעלה event שינוי מאפיין Name; assistive technology אינה שולפת מחדש מעצמה, כך שבלי ה-event היא שומרת את השם הישן ולעולם אינה שמה לב לשינוי
    participant c as פקד
    participant p as AutomationPeer
    participant s as קורא מסך
    c->>p: ערך IsOnline משתנה
    p->>s: מעלה event שינוי מאפיין Name
    s->>s: מכריז על המצב החדש
    Note over s: בלי ה-event, השם הישן נשאר

איור 11: שינוי ערך מגיע ל-screen reader רק כשה-AutomationPeer מאותת עליו ב-event שינוי.

אם לפקד יש פעולות, מממשים את ה-patterns ושמים אותם ברכיבים משותפים

לפקדים מותאמים שאפשר ללחוץ עליהם, שיש להם ערך משתנה, או שאפשר לבחור, דורסים GetPattern ומספקים ממשקי pattern כמו IInvokeProvider ו-IRangeValueProvider.¹⁴

אם בונים את ה-Peer לספריית הפקדים המשותפת, כל מסך שמשתמש בו הופך לתואם אוטומטית. זו התשתית לפריסה שמתוארת בפרק 9.

6. האם אפשר להגיע לכל פונקציה במקלדת בלבד?

קריטריון הצלחה 2.1.1 של WCAG (Keyboard) דורש שכל הפונקציונליות תהיה ניתנת להפעלה דרך ממשק מקלדת.⁶ משתמשי screen reader בדרך כלל אינם משתמשים בעכבר, כך שפונקציה שאי אפשר להגיע אליה ממקלדת זהה לפונקציה שאינה קיימת.

6.1. בודקים תנועה, ביצוע ומיקום נוכחי

בודקים לא רק את סדר ה-Tab אלא גם שהפעולות העיקריות ניתנות לביצוע וש-focus הנוכחי גלוי.

גם ה-walkthrough של WinForms accessibility מפרט, כיסודות, הנחת תווית מיד לפני שדה קלט בסדר ה-Tab ומתן access keys לפקדים ולתפריטים שהמשתמש רוצה לעבור אליהם.¹¹

6.2. עבודת מקלדת גם משפרת יעילות קלט לכל משתמש

זה אינו רק “עלות נוספת לתמיכה באנשים עם מוגבלות.” בעבודה שגרתית כמו הזנת הזמנות, האם המפעיל יכול להשלים קלט בלי לעזוב את home position מכריע כמה פעולות הוא מספיק.

סדר Tab מבולגן או פעולה שדורשת עכבר הוא פגם שמוריד קצת מפרודוקטיביות כל משתמש כל יום. עבודת accessibility ויעילות מקלדת הם שני שמות לאותה עבודה. לסדרי עדיפות לפי סביבת שימוש, ראו גם “עיצוב UX לאפליקציות Windows”.

flowchart TB
    accTitle: האפקט הכפול של עבודת מקלדת
    accDescr: סידור סדר Tab, access keys וציון focus מייצר שני אפקטים בבת אחת, משתמשי assistive technology שיכולים להגיע לפונקציות ומהירות הקלט של כל מפעיל, בעוד פונקציה שמישה רק בעכבר זהה לפונקציה שאינה קיימת
    seibi["הפעלה במקלדת מסודרת"] --> a11y["משתמשי assistive technology יכולים לעבוד"]
    seibi --> speed["מהירות קלט של כל מפעיל"]
    mouse["פונקציות עכבר בלבד"] -.-> none["זהה לפונקציות שאינן קיימות"]

איור 12: עבודת מקלדת מספקת תמיכת assistive technology ויעילות לכל משתמש בבת אחת; פונקציה עכבר-בלבד כמעט אינה קיימת.

7. צבע וניגודיות — 4.5:1 ו-“לא בצבע בלבד”

7.1. מדריך יחס הניגודיות הוא 4.5:1

קריטריון הצלחה 1.4.3 של WCAG (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. מעקב אחרי contrast themes (high contrast)

Contrast themes של Windows (לשעבר high contrast) הן סכמות צבעים שמפרידות חזית ורקע בחוזקה. ה-themes המובנים מתוכננים ליחס ניגודיות של בערך 7:1 או יותר, ומשתמשים יכולים לבחור ולערוך אותם.¹⁵

בצד האפליקציה, אל תקודדו צבעים בקשיחות; כבדו את system colors. מה לעשות בכל framework הוא כדלקמן.

להגדרות WinForms קונקרטיות ראו את ה-walkthrough של Microsoft, ולצבעי ה-theme ראו את תיעוד contrast themes.¹¹¹⁵

flowchart TB
    accTitle: מעקב אחרי contrast themes
    accDescr: מקומות שבהם צבעים מקודדים בקשיחות נשברים במעבר ל-contrast theme, לכן עוברים לסכמה מבוססת SystemColors ועוקבים דרך event שינוי ההגדרות; אם מפנים ל-system colors, ה-UI עוקב אחרי צבעי המשתמש אוטומטית
    theme["מעבר ל-contrast theme"] --> qh{"איך הצבעים מצוינים?"}
    qh -->|מקודדים בקשיחות| broken["סכמת הצבעים נשברת"]
    qh -->|הפניות ל-system color| ok["עוקב אחרי צבעי המשתמש אוטומטית"]
    broken -.-> fix["מעבר ל-SystemColors"]
    fix -.-> ev["מעקב דרך event שינוי ההגדרות"]

איור 14: רק צבעים מקודדים בקשיחות נשברים תחת contrast theme; הפניות ל-system color עוקבות אוטומטית.

כוללים הישרדות high DPI באותה בדיקה

משתמשים עם ראייה נמוכה לעיתים קרובות עובדים עם מקדם סקיילינג גבוה של ה-OS (DPI scaling), כך שתמיכת high-DPI היא גם חלק מ-accessibility. אפליקציה שפריסתה נשברת ב-125% עד 200% אינה שמישה בסביבה הזו.

לפרטים, ראו “תמיכת high-DPI ב-WinForms” ו”תמיכת high-DPI ב-WPF”.

8. בדיקה בפועל — Accessibility Insights ובדיקות screen reader מעשיות

8.1. Accessibility Insights for Windows

Accessibility Insights for Windows של Microsoft מציע שלוש דרכי עבודה, לפי המטרה.⁷

Inspect.exe ו-AccEvent, הכלולים ב-Windows SDK, יכולים גם להציג את עץ UIA ואת ה-properties, אבל הם ממוקמים ככלים ישנים, ומעבר ל-Accessibility Insights מומלץ כעת.⁷

flowchart TB
    accTitle: שלושת המצבים של Accessibility Insights
    accDescr: Accessibility Insights for Windows מספק Live Inspect לבדיקת properties של UIA, FastPass לבדיקה קלה של בעיות בעלות השפעה גבוהה, ו-Troubleshooting לעזרה באבחון ותיקון בעיות, ומעבר מכלים ישנים כמו Inspect.exe מומלץ
    ai["Accessibility Insights"] --> live["Live Inspect"]
    ai --> fast["FastPass"]
    ai --> ts["Troubleshooting"]
    live --> livef["בדיקת properties של UIA"]
    fast --> fastf["זיהוי בעיות בעלות השפעה גבוהה"]
    ts --> tsf["עזרה באבחון ותיקון"]
    legacy["Inspect.exe ואחרים"] -.->|מעבר מומלץ| ai

איור 15: ל-Accessibility Insights יש שלושה מצבים, בדיקה, זיהוי ואבחון, והוא התחליף המומלץ לכלים הישנים.

8.2. בדיקות מעשיות עם screen reader

לעבור בדיקה אוטומטית ולהיות מסוגל להשלים עבודה אמיתית הם שני דברים שונים. כלים יכולים לזהות רק בעיות שאפשר לשפוט מכנית, לכן תמיד מסיימים בהליכה בפעולה עסקית עם screen reader.

קודם מפעילים Narrator עם Ctrl+Windows key+Enter, או מתקינים את NVDA החופשי.¹⁰ אחר כך בוחרים משימה מייצגת כמו “להזין הזמנה אחת ולאשר אותה,” ומנסים להשלים אותה בהכרזות בלבד, בלי להסתכל על המסך או עם התצוגה כבויה.

בעיות כמו סדר הכרזה לא קוהרנטי אף על פי ששמות מוגדרים, או focus שבורח מחוץ לדיאלוג מודאלי, נמצאות רק בבדיקה מעשית מהסוג הזה.

flowchart TB
    accTitle: שילוב אימות כלי ובדיקות מעשיות
    accDescr: בדיקה אוטומטית כמו FastPass יכולה לזהות רק בעיות שאפשר לשפוט מכנית; לשאר, הולכים בפעולות עסקיות אמיתיות עם screen reader ומוצאים בעיות סדר הכרזה ו-focus בידיים
    tool["בדיקת כלי אוטומטית"] --> kikai["בעיות שאפשר לשפוט מכנית"]
    tool -.-> nokori["בעיות שלא ניתנות לזיהוי נשארות"]
    nokori --> sr["בדיקה מעשית עם screen reader"]
    sr --> task["הליכה בפעולה עסקית"]
    task --> mieru["בעיות סדר הכרזה ו-focus"]

איור 16: משתמשים בבדיקה האוטומטית למנות את הבעיות המכניות, ומוצאים את השאר בבדיקות מעשיות עם screen reader.

8.3. בנייתו לזרימת הפיתוח, והסינרגיה עם בדיקות UI אוטומטיות

כדי שאימות לא יהיה תלוי באנשים מסוימים, מומלץ להוסיף את רשימת הבדיקה הבאה לפריטי הסקירה של כל מסך חדש.

שימוש חוזר בעבודת UIA לבדיקות אוטומטיות

בדיקות UI אוטומטיות עם FlaUI וכלים דומים בנויות על אותו UIA ש-screen readers משתמשים בו. ה-Name וה-patterns ששמים ל-accessibility הופכים לבלוקים לקוד בדיקה, ו-AutomationId שתוכנן לבדיקות גם מקל על ניפוי ב-Live Inspect.

לעומת זאת, UI שלא מופיע בעץ UIA בלתי-נראה גם לבדיקות וגם ל-assistive technology. Accessibility ו-testability הם שני צדדים של אותה השקעה. לפרטים, ראו “בדיקות UI אוטומטיות לאפליקציות desktop של Windows”.

flowchart TB
    accTitle: הסינרגיה בין accessibility לבדיקות UI אוטומטיות
    accDescr: Screen readers ובדיקות UI אוטומטיות כמו FlaUI בנויים על אותו UIA, כך שה-Name וה-patterns ששמים ניתנים לשימוש משניהם, ו-UI שלא מופיע בעץ UIA בלתי-נראה לשניהם
    uia["עץ UIA מסודר"] --> sr["Screen readers יכולים לקרוא"]
    uia --> test["בדיקות UI אוטומטיות יכולות להשתמש"]
    sr -.-> both["שני צדדים של אותה השקעה"]
    test -.-> both
    hidden["UI נעדר מ-UIA"] -.-> invisible["בלתי-נראה לשניהם"]

איור 17: כי שניהם יושבים על אותה תשתית UIA, סידור עץ UIA עוזר גם ל-assistive technology וגם לבדיקות UI אוטומטיות.

9. איך לקבוע סדרי עדיפות — אל תתקנו כל מסך בבת אחת

שיפוץ מערכת ליבה עם מאות מסכים בבת אחת אינו מציאותי מבחינת עלות ואיכות. מומלץ להתקדם בשלושת השלבים הבאים.

9.1. מתחילים במסכים שהמשתמש נסמך עליהם בעבודה

Reasonable accommodation הוא תהליך של מענה אישי לפניית האדם.² קודם נותנים לאדם להפעיל את עבודתו האמיתית עם screen reader, ומזהים יחד איפה הוא נתקע.

ברוב המקרים, המסכים שבשימוש יומיומי מצטמצמים לאיפשהו בין קומץ לתריסר. הבעיות הקריטיות ביניהם, כמו כפתורים בלי שם או כפתור אישור שאי אפשר ללחוץ ממקלדת, ניתנות לפתרון בתיקונים שנמדדים בימים.

9.2. הופכים פיתוח חדש לתואם כסטנדרט

מוסיפים את רשימת הבדיקה של פרק 8 ל-Definition of Done. המדיניות היא שמסכים חדשים נבנים תואמים מההתחלה. בניגוד להתאמה בדיעבד, בנייתו בזמן התכנון מוסיפה רק עלות קטנה.

9.3. מגלגלים על פני מסכים בתיקון פקדים משותפים

מממשים ברירות מחדל של AccessibleName ו-AutomationPeers בדיאלוגי חיפוש משותפים פנימיים, grids, קלטי תאריך וכן הלאה. מתקנים רכיב משותף, והתיקון נכנס לתוקף בבת אחת בכל מסך שמשתמש בו. זה מהלך חסכוני יותר מתיקון מסכים בודדים אחד-אחד.

flowchart TB
    accTitle: שלושת שלבי קביעת סדרי עדיפות לתיקונים
    accDescr: מתחילים במסכים שהמשתמש נסמך עליהם בעבודה, הופכים פיתוח חדש לתואם כסטנדרט עם רשימת הבדיקה, ומגלגלים לכל מסך בתיקון פקדים משותפים
    s1["1. מתחילים במסכים שהמשתמש נסמך עליהם"] --> s2["2. פיתוח חדש תואם כסטנדרט"] --> s3["3. מגלגלים דרך פקדים משותפים"]
    s3 -.-> all["נכנס לתוקף בבת אחת בכל מסך שמשתמש בהם"]

איור 18: במקום לשפץ כל מסך בבת אחת, מתקדמים בשלושה שלבים: המסכים שבשימוש, פיתוח חדש, ורכיבים משותפים.

9.4. רושמים את מהלך הדיאלוג, לא רק את התיקונים

חשוב לא פחות מהעבודה הטכנית הוא רישום הדיאלוג. Reasonable accommodation הוא תהליך של דיבור והתאמה ממקרה למקרה, לא של עמידה מלאה בכל בקשה.

לתיקונים שיהיו נטל מופרז, שקילה והסכמה על חלופות עם האדם, כמו ביצוע המשימה במסך אחר, אספקת ייצוא CSV, או כיסוי דרך תפעול, היא תוצאה לגיטימית של דיאלוג בונה.²

רישום מה התבקש, מה נעשה, ומה הוצע כחלופה הוא מה שמדגים את תום הלב של הארגון.

flowchart TB
    accTitle: זרימת דיאלוג בונה ורשומות
    accDescr: מגיבים לפנייה מאדם עם מוגבלות בדיאלוג בונה, מבצעים את התיקונים שאפשר, לתיקונים שיהיו נטל מופרז שוקלים ומסכימים על חלופה עם האדם, ורושמים מה התבקש, מה נעשה ומה הוצע כחלופה
    req["פנייה"] --> talk["דיאלוג בונה"]
    talk --> q{"נטל מופרז?"}
    q -->|לא| kaishu["מגיבים בתיקון"]
    q -->|כן| alt["שוקלים ומסכימים על חלופה"]
    kaishu --> rec["רושמים את מהלך האירועים"]
    alt --> rec

איור 19: בדיאלוג בונה, מסכימים עם האדם על תיקון או חלופה, ושומרים רישום של איך זה הלך.

10. סיכום

הפרדת המסגרת החוקית, הטכנולוגיה והתהליך הופכת את נקודת ההתחלה לגלויה.

בצד החוק, reasonable accommodation בידי עסקים הוא חובה מאז אפריל 2024, ובידי מעסיקים בתחום התעסוקה מאז 2016. תיקון אפליקציה מראש נכנס ל-“שיפור סביבה” (חובת מאמץ), וככל שהוא הלך רחוק יותר, כך המענה האישי קל יותר. רושמים גם את מהלך הדיאלוג.

בצד הטכנולוגיה, בודקים אפליקציות desktop סביב WCAG (JIS X 8341-3:2016) דרך WCAG2ICT. התשתית היא עץ UIA, ה-properties שלו (Name/ControlType/AutomationId), וה-control patterns. מתן שם, בעדיפות הגבוהה ביותר, מטופל עם AccessibleName ו-Label פלוס סדר Tab ב-WinForms, AutomationProperties.Name/LabeledBy ב-WPF, ו-AutomationPeer לפקדים מותאמים.

מעל זה, מסדרים סדר Tab, access keys וציון focus כך שאפשר להגיע לכל פונקציה במקלדת בלבד. לצבע, משתמשים ביחס ניגודיות 4.5:1 כמדריך, לא נסמכים על צבע בלבד, ומכבדים את system colors תחת contrast themes. השיפורים האלה גם מעלים את הפרודוקטיביות של כל מפעיל.

התהליך רץ בסדר מסכים שהמשתמש נסמך עליהם, פיתוח חדש תואם-כסטנדרט, וגלגול דרך פקדים משותפים. משלבים FastPass ו-Live Inspect ב-Accessibility Insights עם בדיקות מעשיות ב-Narrator/NVDA, ובונים אותם לזרימת הפיתוח כרשימת הבדיקה למסכים חדשים.

כצעד ראשון, מומלץ לבחור אחד מהמסכים העיקריים שלכם, להריץ FastPass ב-Accessibility Insights for Windows, ואז ללכת בעבודה במקש Tab בלבד. תוך 30 דקות תראו, באופן קונקרטי מפתיע, איפה האפליקציה שלכם עומדת כעת.

מאמרים קשורים

• בדיקות UI אוטומטיות לאפליקציות desktop של Windows — איך UI Automation עובד ובניית בדיקות חסינות עם FlaUI
• עיצוב UX לאפליקציות Windows - סדר עדיפויות לפי סביבת שימוש
• תמיכת high-DPI ב-WinForms — למה ה-UI מטשטש או נשבר במסכי 4K, ותיקונים מעשיים
• תמיכת high-DPI ב-WPF — למה זה עדיין מטשטש ודולף אף על פי שזה ‘כביכול DPI-aware,’ ואיך מתקנים
• למה KomuraSoft בונה אתרים על ה-design system של Digital Agency — מחיר נמוך ואיכות יכולים לדור יחד
• גופנים יפניים באפליקציה עסקית: JIS2004, IVS ו-gaiji

תחומי ייעוץ קשורים

KomuraSoft LLC מטפלת בתיקוני accessibility לאפליקציות עסקיות WinForms/WPF (תמיכת screen reader, הפעלה במקלדת, תמיכת contrast theme), מימוש AutomationPeer לפקדים משותפים, ואבחון מצב נוכחי וקביעת סדרי עדיפות עם Accessibility Insights. אפשר להתחיל משלב של “אנחנו רוצים לבדוק אם עובד יכול להשתמש באפליקציה שלנו עם screen reader.”

• Windows Custom Software Development
• ייעוץ טכני וסקירת תכנון
• יצירת קשר

קישורים

מאמרים קשורים

מאמרים עדכניים עם אותן תגיות, להעמקה בנושאים קרובים.

נושאים קשורים

העמודים האלה ממקמים את הנושא בהקשר רחב יותר של שירותים והחלטות.

שירותים הקשורים לנושא הזה

המאמר קשור ישירות לשירותים הבאים.

שאלות נפוצות

שאלות נפוצות בפניות בנושא המאמר.

האם תמיכת accessibility לאפליקציה עסקית נדרשת בחוק?

תיקון 2021 לחוק ביטול האפליה נגד אנשים עם מוגבלות ביפן נכנס לתוקף ב-1 באפריל 2024, ומתן reasonable accommodation לאנשים עם מוגבלות הפך לחובה גם לעסקים. Reasonable accommodation היא תגובה שמסירה, כשאדם עם מוגבלות מבקש, מחסום אישי בטווח שאינו נטל מופרז; תיקון האפליקציה מראש כדי שתהיה קלה יותר לשימוש ממוקם כחובת מאמץ שנקראת שיפור הסביבה. שימו לב שתחום התעסוקה, כמו היחס בין עובד לחברה, אינו תחת החוק ההוא אלא תחת חוק קידום תעסוקת אנשים עם מוגבלות, שחייב מעסיקים לספק reasonable accommodation מאז התיקון שנכנס לתוקף באפריל 2016. במילים אחרות, מצב של "עובד לא יכול להשתמש באפליקציה העסקית" נמצא בתחום החובה כבר זמן מה. עד כמה לתמוך תלוי במצב האישי, לכן מאשרים מקורות ראשוניים ממשרד הקבינט וממשרד הבריאות, העבודה והרווחה ומחליטים דרך דיאלוג עם האדם הנוגע בדבר.

איך screen reader קורא אפליקציית desktop של Windows?

Screen readers כמו Narrator ו-NVDA קוראים את ה-UI של האפליקציה דרך תשתית accessibility שנקראת UI Automation (UIA). צד האפליקציה חושף רכיבי מסך במבנה שנקרא עץ UIA; לכל רכיב יש properties כמו Name (מטרה) ו-ControlType (סוג), ו-control patterns כמו Invoke (לחיצה) ו-Value (ערך). ה-screen reader מכריז על המידע הזה כ"כפתור אישור הזמנה" ופועל דרך ה-patterns. פקדי WinForms ו-WPF סטנדרטיים יש להם את המנגנון הזה מההתחלה, ולכן העבודה העיקרית של המפתח היא לא להשאיר Name ריק, להפוך את הממשק להפעלה ממקלדת, ולממש מידע על פקדים מותאמים.

באפליקציית WinForms קיימת, מאיפה מתחילים?

הנתיב הקצר ביותר הוא להריץ FastPass ב-Accessibility Insights for Windows מול המסך היעד ולמנות פקדים ש-Name שלהם ריק ובעיות סדר Tab. התיקונים מתחילים בהגדרת AccessibleName על כפתורי-אייקון-בלבד, בשיוך Label בסדר ה-Tab מיד לפני שדה קלט, ובסידור TabIndex כך שיתאים לסדר החזותי. אחר כך מפעילים Narrator או NVDA והולכים בפעולה עסקית אמיתית בלי להסתכל על המסך, ומאשרים איפה נתקעים. אין צורך לתקן כל מסך בבת אחת; התחלה ממסכים שמישהו באמת משתמש בהם, והפיכת מסכים חדשים לתואמי-תקן עם רשימת בדיקה, היא מציאותית.

מה לעשות לתמיכת contrast theme (high contrast)?

הבסיס הוא לא לקודד צבעים בקשיחות ולכבד system colors. ב-WinForms, משאירים ForeColor/BackColor בברירת המחדל או משתמשים ב-SystemColors, בודקים את המצב עם SystemInformation.HighContrast, ועוקבים אחרי החלפה עם אירוע UserPreferenceChanged. גם ב-WPF וב-WinUI, אם מפנים למשאבי מחלקת SystemColors, עוקבים אחרי החלפת theme אוטומטית. באותו זמן, מפסיקים להעביר מידע "בצבע בלבד" — הצגת שגיאה באדום בלבד — ומשלבים עם אייקון או ניסוח. גם ב-theme הרגיל, לקיחת קריטריון WCAG של יחס ניגודיות טקסט 4.5:1 או יותר כמדריך גם הופכת את הממשק לקריא יותר לרצפת מפעל חשוכה ולמשתמשים מבוגרים.

האם תמיכת accessibility עוזרת גם לבדיקות UI אוטומטיות?

כן. כלי בדיקות UI אוטומטיות כמו FlaUI בנויים על אותו UI Automation ש-screen readers משתמשים בו. ה-Name, ControlType ו-control patterns ששמים ל-accessibility יכולים לשמש כמו שהם מקוד בדיקה, ו-AutomationId שתוכנן לבדיקות מייצב זיהוי רכיבים. לעומת זאת, ממשק מצויר-מותאם שלא מופיע בעץ UIA בלתי-נראה גם ל-screen reader וגם לבדיקות. Accessibility ובדיקות אוטומטיות הן השקעה באותה תשתית, ולכן הצבת כל אחת מהן גם מורידה את עלות השנייה.

פרופיל הכותב

עמוד היכרות עם כותב המאמר.

Go Komura

מנהל KomuraSoft LLC

מתמחה בפיתוח תוכנה עבור Windows, ייעוץ טכני וחקירת תקלות, בעיקר בפרויקטים עם מערכות קיימות ובאגים שקשה לשחזר.