לקראת נגישות

יום שישי הוא סוף יום העבודה. חדשות רעות תמיד מגיעות בסוף יום העבודה ביום שישי.

אתה עומד לעזוב את המשרד, בדיוק הגיע בדואר מכתב חדש על ארגון מחדש נוסף.

תודה לך xxxx, yyy מהיום תדווח על zzzz
...
והצוות של יו יבטיח שהמוצרים שלנו נגישים לאנשים עם מוגבלויות.

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

זו הייתה הזמינות לפני כמה שנים. כמה נשמות מסכנות קיבלו את התפקיד "לנקות" את ממשק המשתמש כדי לנסות ולהנגיש אותו לאנשים עם מוגבלויות.

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

אבל לפתע החלו ה"באגים" להתרבות במהירות של מפולת.

קוראי מסך שונים (אנג. קוראי מסך) ודפדפנים התנהגו אחרת לגמרי.

משתמשים התלוננו שהאפליקציה אינה שמישה.

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

ופשוט שינוי ותיקון שגיאות ממשק משתמש דרשו מאמצים של הרקולאן.

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

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

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

ניווט בממשק משתמש מורכב באמצעות הקשות Tab/Shift+Tab - זה מבאס! אנחנו צריכים משהו יותר טוב. קיצורי מקלדת, כותרות.

לאבד מיקוד בעת שינוי ממשק המשתמש זו לא בעיה גדולה, נכון? בואו נחשוב שוב - זה מבלבל להפליא.

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

אז, לקחנו צעד אחורה ובדקנו איך נוכל ליישם זאת אחרת ולהצליח, ולהפוך את התהליך לפחות משעמם!

די מהר הגענו לכמה מסקנות:

1. לא רצינו שאנשים שמפתחים את ממשק המשתמש יתעסקו עם תוויות/תפקידים של אריה וכמובן עם מבנה ה-HTML של הרכיבים. היינו צריכים לספק להם את הרכיבים הנכונים שבנו נגישות ישר מהקופסה.
2. נגישות == קלות שימוש – כלומר. זה לא רק אתגר טכני. היינו צריכים לשנות את כל תהליך העיצוב ולהבטיח שהנגישות נלקחה בחשבון ונדונה לפני תחילת עיצוב ממשק המשתמש. אתה צריך לחשוב מוקדם כיצד המשתמשים יגלו פונקציונליות כלשהי, כיצד הם ינווטו וכיצד לחיצה ימנית מהמקלדת תעבוד. נגישות צריכה להיות חלק בלתי נפרד מתהליך העיצוב – עבור חלק מהמשתמשים מדובר בהרבה יותר מסתם המראה של האפליקציה.
3. כבר מההתחלה רצינו לקבל משוב ממשתמשים עיוורים ובעלי מוגבלויות אחרות לגבי קלות השימוש באפליקציה.
4. היינו צריכים דרכים ממש טובות לתפוס רגרסיות נגישות.

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

לוקחים צעד אחורה, מסתכלים דוגמאות של ARIA ועל ידי חשיבה על זה כבעיית עיצוב ולא כבעיית "התאמה", הצגנו כמה הפשטות. לרכיב יש 'מבנה' (מורכב מאלמנטים של HTML) ו'התנהגות' (איך הוא מקיים אינטראקציה עם המשתמש). לדוגמה, בקטעים למטה יש לנו רשימה פשוטה לא מסודרת. על ידי הוספת "התנהגות" התפקידים המתאימים מתווספים לרשימה כדי לגרום לה לפעול כמו רשימה. אנחנו עושים את אותו הדבר עבור התפריט.

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

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

אתה יכול לראות את זה בפעולה ב https://stardust-ui.github.io/react/ - ספריית UX להגיב, אשר תוכנן ומיושם מתוך מחשבה על נגישות מההתחלה.

החלק השני - שינוי הגישה והתהליכים סביב העיצוב הפחיד אותי בהתחלה: מהנדסים נמוכים שמנסים לדחוף שינוי ארגוני לא תמיד מסתיים בטוב, אבל זה התברר כאחד התחומים המעניינים ביותר שבהם תרמנו תרומות משמעותיות לתהליך . בקצרה, התהליך שלנו היה כדלקמן: פונקציונליות חדשה תפותח על ידי צוות אחד, ואז צוות ההנהגה שלנו יבדוק/יחזור על ההצעה, ולאחר מכן, לאחר אישור, העיצוב יועבר בדרך כלל לצוות ההנדסה. במקרה זה, צוות ההנדסה למעשה "הבעלים" של פונקציונליות הנגישות מכיוון שהייתה באחריותם לתקן את כל הבעיות הקשורות אליה.

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

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

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

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

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

1. תובנות נגישות הוא סט כלים שניתן להפעיל גם בדפדפן וגם כחלק ממחזור הבנייה/בדיקה לזיהוי בעיות.
2. אימות שקוראי מסך פועלים כהלכה הייתה משימה מאתגרת במיוחד. עם כניסת הגישה ל נגישות DOM, סוף סוף נוכל לצלם תמונות נגישות של האפליקציה, בדומה לבדיקות חזותיות, ולבדוק אותן לגבי רגרסיה.

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

ה"הבנה" הבאה היא שמשתמשים עיוורים מניעים את הטכנולוגיה המתקדמת - הם אלה שמרוויחים הכי הרבה לא רק מהשינויים שתיארנו קודם, אלא גם שגישות ורעיונות חדשים מתאפשרים על ידי ML/AI. לדוגמה, טכנולוגיית Immersive Reader מאפשרת למשתמשים להציג טקסט בקלות ובבהירות יותר. ניתן לקרוא אותו בקול רם, מבנה המשפט מפורק מבחינה דקדוקית, ואפילו משמעויות המילים מוצגות בצורה גרפית. זה בכלל לא מתאים למנטליות הישנה של "הפוך את זה לנגיש" - זו תכונת שימושיות שתעזור לכולם.

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

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

רק משתמשים רשומים יכולים להשתתף בסקר. להתחברבבקשה.

האם אתה שם לב לנגישות האפליקציות שלך?

• כן

• לא

• זו הפעם הראשונה שאני שומע על נגישות לאפליקציה.

17 משתמשים הצביעו. 5 משתמשים נמנעו.

מקור: www.habr.com