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

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

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

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

למה אפליקציה היא לא אתר

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

נושא	באתר	באפליקציה
ניווט	מקלדת: Tab, Enter וחיצים	מחוות מגע: החלקה ימינה ושמאלה, הקשה כפולה
קורא מסך	NVDA, JAWS, VoiceOver במחשב	VoiceOver ב-iOS, TalkBack באנדרואיד
פתרון מדף	קיימים תוספים (שלא מספיקים לבד)	לא קיים. אין רכיב חיצוני שמנגיש אפליקציה
בדיקה	שילוב של כלים אוטומטיים ובדיקה ידנית	בעיקר ידנית, על מכשירים פיזיים
מבנה	HTML סמנטי ו-ARIA	תוויות נגישות (Labels), תפקידים ומצבים ברכיבי Native

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

בסרטון: הנגשת אפליקציה מול הנגשת אתר

• 0:00 האם גם אפליקציה חייבת להיות נגישה.
• 1:03 התאמת דרישות התקן לאפליקציה: מחוות במקום מקלדת.
• 1:33 התאמה ל-TalkBack ול-VoiceOver.
• 2:03 למה אין תוסף נגישות לאפליקציה.
• 3:36 בדיקה ויזואלית של העיצוב, המסכים והכותרות.
• 5:10 הצהרת נגישות גם לאפליקציה.

8 נושאים שבודקים בכל מסך

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

1. היררכיה ברורה בכל מסך

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

2. שם, תפקיד ומצב לכל רכיב

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

3. סדר ניווט ופוקוס

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

4. מחוות עם חלופה פשוטה

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

5. גודל טקסט שמגיב להגדלה

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

6. צבע וניגודיות

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

7. תוכן פשוט, כפתורים ברורים

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

8. רכיבים מורכבים, תנועה ומהירות

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

איך בודקים מסך עם קורא מסך

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

1. הפעילו את קורא המסך: VoiceOver באייפון (הגדרות > נגישות > VoiceOver), או TalkBack באנדרואיד (הגדרות > נגישות > TalkBack).
2. פתחו את המסך שאתם בודקים, והחליקו ימינה כדי לעבור מרכיב לרכיב.
3. הקשיבו: האם כל כפתור ואייקון מוקרא עם שם ברור ותפקיד?
4. בדקו את הסדר: האם הפוקוס עובר לפי סדר הקריאה, ולא קופץ?
5. בצעו פעולה מלאה, למשל הרשמה או הוספה לסל, רק עם קורא המסך והקשה כפולה.
6. מלאו טופס עם שגיאה בכוונה, ובדקו שהודעת השגיאה מוקראת.
7. הגדילו את הטקסט בהגדרות הטלפון וחזרו למסך: שום דבר לא נחתך?
8. חזרו על הבדיקה במערכת ההפעלה השנייה.

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

תהליך הנגשת אפליקציה: 4 שלבים

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

בסרטון: ארבעת השלבים

• 0:31 גם אפליקציה חייבת להיות נגישה, באנדרואיד וב-iOS.
• 2:05 בדיקת נגישות עם קורא מסך בשתי מערכות הפעלה.
• 2:36 סינון הקריטריונים שרלוונטיים לאפליקציה.
• 3:09 סקר נגישות מתועד בצילומי מסך, ומעבר לצוות הפיתוח.
• 4:13 בדיקה חוזרת, ואז כתיבת הצהרת נגישות.

נגישות בלי לפגוע בעיצוב

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

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

בסרטון: חמשת השלבים, והעיצוב

• 0:32 בדיקה ידנית של כל המסכים הייחודיים בשתי פלטפורמות.
• 1:05 ליווי צוות הפיתוח צעד אחר צעד.
• 1:36 שמירה על צבעי המותג וחוויית המשתמש.
• 2:06 בדיקה חוזרת אחרי התיקונים.
• 4:12 למה כדאי לחשוב על נגישות כבר בתחילת הדרך.

בפיתוח עם כלי AI? בדקו פעמיים

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

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