ניהול פוקוס בתוכנות קוראות מסך

הקדמה קצרה

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

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

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

 

מה זה מצב פוקוס ומה זה מצב גלישה

פוקוס

מצב פוקוס מוכר גם כמצב טפסים, מצב הזנה (קלט או טקסט)

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

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

גלישה

מצב זה מזוהה גם כמצב דפדוף או ניווט מהיר.

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

הדוגמה של סריקת כותרות

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

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

איתור אלמנטים כגון אזורים, כותרות, רשימות, פקדי טפסים ועוד ניתן לבצע באמצעות מקש אות מייצגת במקלדת במצב גלישה. כך לדוגמה, איתור כותרות יתבצע על ידי האות h במקלדת להתקדמות קדימה לכותרת הבאה או Shift + h לחזרה אחורה לכותרת הקודמת. בנוסף לכך, ניתן להגיע ישירות לכותרות היררכיות ברמות השונות על ידי לחיצה על המספרים 1 עד 6 בהתאמה ל h1 – h6 בכדי להגיע ישירות לכותרות היררכיות בדרגות שונות. שימושי במיוחד כאשר משתמש מכיר כבר את מבנה האתר ויודע למשל שכותרות ברמה h3 הם כותרות למאמרים.

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

מעבר בין מצב פוקוס למצב גלישה

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

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

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

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

 

אתגר יישומי אינטרנט למשתמשי תוכנות קוראות מסך

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

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

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

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

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

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

אז מה עושים?

זו באמת שאלה קשה שקשה לי לענות עליה באופן גורף לכל המצבים – אבל הינה כמה כיוונים:

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

מה קורה בגלישה מהסלולר?

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

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

תוספי נגישות יכולים לסדר את זה?

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

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

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

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

לבדוק, לחשוב, לכתוב

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

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

 

ללמוד עוד

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