ממשק משתמש, נגישות וכל מה שביניהם

תקציר

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

ההנחיות ליצירת הודעות שגיאה אפקטיביות קיימות כבר 20 שנה. הודעת שגיאה טובה צריכה לכלול:

חיווי מפורש שמשהו השתבש

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

שפה ברורה וקריאה

שימוש בשפה ברורה וקריאה במקום שפה מעורפלת או שימוש בהודעות שגיאה המשלבות קודים מתוך המערכת. לדוגמא: "ארעה שגיאה במערכת" או "an error of type 2 has occurred.".

שפה מנומסת

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

תיאור מדויק של הבעיה

תיאור מדויק של הבעיה במקום ניסוח מטושטש וכללי. דוגמא לניסוח לא מדויק: "syntax error.".

עצה מעשית ומועילה

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

הודעת 404 – The page cannot be found

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

הנחיות נוספות

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

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

ההנחיות הבאות יכולות לשפר את חווית המשתמש בעת התרחשות שגיאה:

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

 נלקח מתוך האתר של Jakob Nielsen.

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

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

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

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

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

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

מה לדעתכם מקשר בין הנשיא ברק אובמה, הסנטור בראון ממסצ’וסטס ורומי?  יכול להיות שגם מוסיקת Country אבל בעיקר שיווק רב ערוצי. נגמרו הזמנים שבהם מועמד לנשיאות, לסנאט, או לכל תפקיד ציבורי אחר יעסוק אך ורק בגיוס תומכים וכספים בעזרת הדבקת פוסטרים בחוצות הערים, ושליחת מעטפות מבוילות לתומכים פוטנציאליים. המועמד ו/או עוזריו חייבים "לחיות" באינטרנט כדי לנצל את הרב ערוציות הקיימת בה ולפנות לכלל הבוחרים הפוטנציאליים באמצעות מגוון ערוצים. גם חברות המעוניינות למכור את מרכולתן חייבות להתקדם לכיוון הזה, אחרת תמצאנה את עצמן מחוץ למרוץ – You are either in or out.

אז איך עושים את זה?

בסתיו של 2008 היו לאובמה 93,000 עוקבים בטוויטר בעוד שלהילרי קלינטון היו 5,000.  זאת ועוד, אובמה עקב אחרי 96,000 בעוד שהילרי לא עקבה אחרי אף אחד… המועמד השלישי ג’ון מק-קיין לא היה נוכח כלל ברשתות החברתיות.

במסצ’וסטס, המועמדת של הדמוקרטים, שהובילה במרוץ, בודאי חשבה שרשתות חברתיות הן לילדים או שהן תופעה חולפת. גם בבחירות אלה, צבר המועמד הנגדי (הסנטור בראון) הרבה עוקבים והוא גם עקב אחרי רבים. אך ב-2009 מי שגרם למהפכה הייתה דווקא הרשת החברתית פייסבוק. באותה שנה הצטרפו 175 מליון מנויים לרשת. בלילה הבחירות היו לבראון יותר מ- 117,000 חברים בפייסבוק. לקוקלי (מועמדת הדמוקרטים) היו רק 18,000 חברים. כאשר פורסם עדכון בדף של בראון, שערו בנפשכם כמה קליקים של like  וכמה תגובות היו – אלפים…תגובות הקהל לא נפלו על אוזניים ערלות, לבראון היו אנשים בשטח שניהלו שיחות אינטראקטיביות עם המגיבים.

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

עוד באותו נושא:

The Business lesson in Scott Brown’s Facebook Strategy

How Barack Obama Won Facebook

How social media won Obama the US Election

תגיות: טוויטר, פייסבוק, רב-ערוציות, רומי

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

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

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

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

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

האם אתם משתמשים בנייר סיכוי לאסלה?

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

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

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

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

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

אז מה דעתכם?

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

מדוע חשבתי שהנגישות לא תהיה פשוטה?

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

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

כיצד יבין המשתמש עם המוגבלות איך לשחק?

תיאור שלבי המשחק

מסך פתיחה בו שולב כפתור כניסה. המסך ברובו גרפי.

ישום הנגישות:

א. כותרת ברמה של h1 נסתרת "אוח מציג מה בתיק".

ב. שני קישורים: 1. מהלוגו לאתר המשרד 2. כניסה.

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

ישום נגישות:

א. כותרת ברמה של h1 נסתרת "מה בתיק – תפריט".

ב. 5 קישורים: 1. מהלוגו לאתר המשרד 2. התחלת משחק 3. אודות 4. לאתר שלום כיתה אלף 5. משחקים נוספים.

השגיאות:

א. אפשר היה לכתוב כותרת יותר מפורטת.

ב. חשוב שנחתור לאחידות בשמות הקישורים. אם הקישור פותח חדש (New Window) צריך להשתמש ב-ל החיבור. למשל בקישור הרביעי היינו צריכים לכתוב: למשחקים נוספים.

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

השגיאות:

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

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

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

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

ישום נגישות:

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

<label for="MyName">השם שלי:</label>
<input type="text" id="MyName" />

ב. כותרת ברמה של h1 נסתרת "קצת על עצמי".

ג. קישור "להתחיל לשחק" על הכפתור הגרפי.

לחיצה על התחלת המשחק מאפשרת למשתמש לבחור את זמן המשחק הרצוי לו מבין 3 אפשרויות.

יישום נגישות:

א. כותרת ברמה של h1 נסתרת "קצת על עצמי".

ב. כותרת ברמה של h2 גלויה "בחירת זמן המשחק הרצוי".

ג. Fieldset של 3 כפתורי רדיו עם legend וגבולות נסתרים: display: none.

ד. קישור "להתחיל לשחק" על הכפתור הגרפי.

השגיאות:

א. מצד אחד, חשוב לשלב כותרת משמעותית בדף, היות וכותרות מסייעות למשתמשי קורא מסך בניווט בדף. מצד שני, יש לעטוף כפתורי רדיו ב-fieldset . היות והוגדר fieldset עם display: none לא הצליח קורא המסך לזהות את ה- Fieldset ובעקבות כך התקשה לזהות את קבוצת כפתורי הרדיו. ולכן, היה צריך להגדיר את ה- fieldset עם border:0px ו-legend עם opacity:0 וכותרת של "בחירת זמן המשחק הרצוי". כך, קורא המסך יכול היה לראות את הכותרת וכן לייחס לכל כפתור רדיו את הקבוצה שלו ומיקומו בקבוצה.

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

ג. דף זה אינו עובר נגישות לרמה AA.

 לחיצה על התחלת משחק תפתח את דף המשחק הראשי.

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

יישום נגישות:

א. לכל פריט יש טולטיפ עם כינויו. למשל, בננה, מחק.

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

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

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

השגיאות:

א. שכחנו כותרת.

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

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

ד. ה- fieldset שהוגדר סביב כפתורי הרדיו הוגדר כ-display:none כך שקורא המסך לא זיהה אותו.

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

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

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

לסיכום

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

• האם פלטפורמת הפיתוח שנבחרה (ASP.Net) אפשרה תפעול נגיש של המשחק? האם לא היה צריך לבחור פלטפורמה אחרת? למשל פלאש?
• האם משחקים בכלל צריכים להיות נגישים? האם משחקים המשלבים חווית משתמש כל כך מיוחדת של גרירה יכולים וצריכים להיות נגישים?

ארגון ה- W3C, הקובע את כללי הנגישות, הבין שלא ניתן לעצור את הטכנולוגיה וכדי לממש נגישות בתוכן דינאמי ברשת עליו להציע טכניקות מתאימות. ולכן, ארגון ה-  WAI-Web Accessibility Initiative החל יוזמה של כתיבת מסמכים המסבירים כיצד להגביר את הנגישות של תוכן דינאמי ברשת ושל רכיבי ממשק המפותחים ב- Ajax, HTML, JavaScript וכד’. סט מסמכים זה נקרא ARIA – Accessible Rich Internet Applications. להלן דוגמא של יישום Drag and Drop ב- ARIA.

חשוב להזכיר כי חוקי ה- ARIA נתמכים, לעתים רק בחלקם,  ע"י פיירפוקס (מגרסה 3 ומעלה), IE8 (ניתן לממש חלק מה- ARIA גם ב- IE7), Opera מגרסה 10, Safari מגרסה 4 ו-Chrome.

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

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

תגיות: ARIA, WAI, WCAG2.0, הנחיות נגישות, משחקים, נגישות, קריטריון 2.2.3, רמת נגישות AA

הקדמה

באוקטובר 2009 ערך אתר  WebAIM סקר בנושא העדפותיהם של משתמשי קורא מסך. בסקר השתתפו 665 משתמשי קורא מסך כאשר 10% מהם אינם אנשים עם מוגבלות וכל שאר ה- 90% הם עם מוגבלות. חשוב גם לציין שמתוך אוכלוסייה זו, 52.6% נחשבים משתמשים מתקדמים (בעלי מיומנות גבוהה בקורא מסך), 42.8% הם משתמשים רגילים ו- 4.7% הם משתמשים מתחילים. עוד נתון חשוב הוא המיומנות של המשתתפים בסקר בשימוש באינטרנט. נמצא כי 64.9% מהמשתתפים מעידים על עצמם כמשתמשים מתקדמים, 33.6% רגילים ו- 1.5% מתחילים. אנשים עם מוגבלות המשתמשים בקורא מסך דיווחו על יכולת מעט פחותה בשימוש באינטרנט מהמשתמשים בקורא מסך שאינם עם מוגבלות.

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

להלן מספר נושאים שעלו בסקר ומעניינים במיוחד לאלה העוסקים בהנגשה:

השימוש בקורא מסך במכשירים ניידים

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

Javascript

השאלה שהופנתה למשתתפי הסקר הייתה, האם אתה מכבה את האפשרות ל- Javascript בדפדפן שלך? התשובות היו מפתיעות. 74.9% מהנשאלים לא מכבים את האופציה של Javascript, הם יודעים שהדבר קיים בדף ויודעים להתגבר עליו. המסקנה היא, שניתן להמשיך ולכתוב Javascript, אך לדאוג שיהיה יותר נגיש.

טקסט חלופי לתמונות המיועדות לקישוט

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

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

תמונות מורכבות

תמונות מורכבות כמו גרפים ותרשימים דורשים הסבר נוסף למשתמש עם מוגבלות. רוב הנשאלים (28.4%) בקשו לראות את ההסבר באותו דף ממש סמוך לרכיב עצמו. חלק קטן יותר (26.6%) העדיפו לראות את ההסבר על פי בחירתם, בדף עצמו, אך במקום המיועד לכך וע"י קישור לאותו מקום. 19.8% הנשאלים העדיפו לראות את ההסבר בדף נפרד בעקבות לחיצה על קישור. מאוד מענין לראות שמספר קטן מאוד של הנשאלים (14.2%) העדיף את מילות ההסבר כטולטיפ על התמונה עצמה ורק 9.1% העדיפו לראות את ההסבר בדף נפרד כאשר קורא המסך יקריא להם את הטקסט החלופי. נקודה זו מאוד חשובה למנגישי אתרים. אני, לדוגמא, הייתי נותנת הנחיה לפיתוח, התואמת יותר לאפשרות האחרונה שהוזכרה כאן וש"זכתה" רק ל- 9.1% מהקולות !!!

רכיבים בעייתיים

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

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

רשתות חברתיות באינטרנט

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

שימו לב, שדווקא YouTube החזותי ביותר מכל הכלים המוזכרים כאן הוא השמיש ביותר. אנשים ללא מוגבלות נטו להשתמש יותר בכלים של רשתות חברתיות בעוד שאנשים עם מוגבלות העדיפו דווקא את MySpace. מתוך כל הכלים המוזכרים כאן Twitter הוא הנגיש ביותר לאנשים עם מוגבלות בגלל הטוויטר הנגיש AccessibleTwitter.com.

מציאת מידע

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

לסיכום:

הסיכום כולל מספר נושאים שאת חלקם הייתי רוצה להציף כאן:

א.      כותרות במבנה נכון הן חיוניות לנגישות;

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

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

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

תגיות: Captcha, Javascript, Mobile Accessibility, הנחיות נגישות, חלופה טקסטואלית, נגישות, סקר, קורא מסך

מתוך האתר של עמותת נגישות ישראל:

יותר מ- 10% מתושבי ישראל הם אנשים עם מוגבלות, מתוכם כ- 150,000 עם נכויות קשות.

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

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

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

עד כאן מתוך האתר.

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

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

הרשו לי לשתף אתכם בפרויקט אדיר שהחל בשנת 1987 בסין. בשנה זו נוסדה קבוצה מיוחדת במינה הנקראת China Disabled People’s Performing Art Troupe . הקבוצה זוכה לתמיכה רחבה של החברה כולה בסין ומאפשרת לאנשים עם מוגבלות בעלי כוח רצון עז לממש את חלומם האמנותי. אמנים עם מוגבלויות שמיעה וראיה למשל, מציגים את יכולתם המוסיקלית ומשולבים בקטעי ריקוד מרשימים ומרגשים.

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

שנה טובה לכולנו.

תגיות: מוגבלות ראייה, מוגבלות שמיעה, נגישות

אתם מול המחשב? צריכים למצוא מספר טלפון של חבר? מה הבעיה, היכנסו ל- 144.

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

בתוצאות לחצו על [הצג מספר].

כמה זמן זה לקח לכם?

הכניסה לאתר

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

נכנסתם לאתר.

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

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

נחזור לאתר 144.

לשוניות

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

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

שדות הזנה

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

לחצנו על כפתור חפש.

דף חדש של תוצאות

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

ניווט בדף התוצאות

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

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

הצגת המספר

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

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

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

השורה התחתונה

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

נראה לכם בסדר?

תודות

תודה רבה לעדי נתן שהסב את תשומת ליבי לנגישות של אתר 144.

תודה לאבי אשר מחברת Let’s Talk ששיתף אותי בתחושות של אדם מוגבל ראייה הגולש באינטרנט.

תגיות: Captcha, חלופה טקסטואלית, כותרת, לשוניות, נגישות

מהי שמישות או שימושיות? 

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

1. לימודיות (Learnability): כמה קל למשתמשים לבצע מטלות פשוטות ברגע שנתקלו בפעם הראשונה בממשק?
2. יעילות (Efficiency): ברגע שמשתמשים למדו את הממשק כמה מהר הם מסוגלים לבצע מטלות?
3. זכירות (Memorability): כאשר משתמשים חוזרים למערכת אחרי פרק זמן ללא שימוש בה, כמה קל להם לרכוש מיומנות חוזרת?
4. שגיאות (Errors): כמה שגיאות משתמשים מבצעים, כמה חמורות השגיאות וכמה קל לתקן את השגיאות?
5. סיפוק (Satisfaction): מהי מידת האהדה שמשתמש רוחש למערכת?

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

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

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

הנה לכם התשובה. שימו לב לאדם הבנאי.

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

ותודה לאדם.

תגיות: HCI, שמישות