Please ensure Javascript is enabled for purposes of website accessibility
top of page
חיפוש
Kinneret Yifrah

מיקרו-קופי נגיש לקוראי מסך


כתבו: כנרת יפרח (מומחית מיקרו-קופי) ורותם בינהיים (מומחית UX ונגישות)

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

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

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

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

איך המיקרו-קופי שלכם נשמע בקורא מסך?


Photo by Malte Wingen on Unsplash

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

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

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

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


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

1. תחשבו מלמעלה למטה ומימין לשמאל

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

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


טופס שבו ההנחיה נמצאת אחרי השדה

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


טופס שבו הטקסט המסייע נמצא אחרי השדות

אם כן, הסדר הנגיש של הרכיבים הוא: תווית > הנחיה/מידע מסייע > שדה

כך פייסבוק עושים את זה:


טופס שבו ההנחיה נמצא אחרי התווית, לפני השדה

וכך Walmart:


טופס שבו ההנחיה נמצא אחרי התווית, לפני השדה

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

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

לסיכום:

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

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

2. אפשר להתחכם, אבל לא על חשבון המסר הבסיסי

האם משתמשים שלא רואים את המסך יבינו משמיעת הטקסט לאן הגיעו ומה קורה עכשיו?

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


צילום מסך של זמן טעינה באתר

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

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

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


צילום מסך של מצב אפס של עדכונים שלא כתוב בו שאין עדכונים

מה יבינו משתמשים שלא רואים את המסך הריק ושומעים רק It's oh, so quiet?

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

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

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


טופס עם כותרת שלא אומרת מה קורה פה

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

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

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

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

מה מבינים ממנה?

האם זה חד-משמעי?

בהודעת אישור – האם משתמשים שרק שומעים את המיקרו-קופי ולא רואים את ה-וי הירוק או את האיור המחויך יחוו את האישור המרגיע ויבינו שהפעולה הושלמה בדיוק כמו שהתכוונו?

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

3. חלופה כתובה לכל אייקון ולכל תמונה

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

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


צילום מסך של פרטי טלוויזיה באתר קניות

אין צורך לתאר את תמונת הנוף שבתוך הטלוויזיה ואפילו לא את הטלוויזיה עצמה, הרי יש תיאור שלה ממש משמאלה

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

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

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


צילום מסך מאפליקציית מדיום

ליד האייקונים שבתחתית המסך באפליקציה של Medium לא כתוב כלום, אבל כשמפעילים קורא מסך הוא מקריא את ה-alt שהוגדרו להם: Home, Bookmarks, Write, Activities, You

אייקון של מידע נוסף, שמסומן בתמונה של האות i או של סימן שאלה (?) או של סימן קריאה (!) – גם לו צריך לנסח alt שאומר מה יש מעבר לו, למשל: הנחיות לבחירת סיסמה או הסבר מורחב. אם לא ניתן alt לאייקונים הקטנים-החשובים האלה, משתמשים שאינם רואים פשוט לא ידעו שיש כאן עוד מידע שדרוש להשלמת הפעולה.


טופס עם אייקונים של סימן שאלה אחרי התוויות

לסימני השאלה צריך לתת תיאור ב-alt כדי שידעו שיש כאן עוד מידע

שימו לב 1# אין טעם להתחכם ב-alt. הוא צריך להיות סופר-ברור וחד-משמעי. שימו לב 2# אם המידע חשוב מאוד, כדאי לשקול שלא להסתיר אותו בטול-טיפ אלא להשאיר חשוף תמיד.

הידעתם? לאימוג'יז יש alt קבועים מראש

רוצים לדעת מה משתמשים שומעים כשאתם משלבים אימוג'י במיקרו-קופי? תראו את הסרטון המעולה הזה:


4. לפרטים נוספים, קראו עוד, להמשך קריאה – OUT, קישורים עם תוכן – IN

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

* לקפוץ רק בין הכותרות (המוגדרות H)

* לקפוץ רק בין קישורים וכפתורים

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

אז מה שומעת משתמשת שמדלגת רק בין קישורים במסך הבא?


לוח אירועים עם קישורי לפרטים נוספים

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

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

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

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

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

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

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

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

אם לא – הפכו אותו לטקסט חי או שתיתנו לו חלופה ראויה ב-alt.


עמוד 404 שכולו תמונה אחת וטקסט שבכלל לא מסביר מה קרה

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

שהעמוד שהם רצו לא נמצא?

6. נראוּת: טקסט קבוע וניגודיות גבוהה

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

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

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

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

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


טופס עם שומרי מקום שזזים למעלה

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

אם אין לכם מחסור חמור במקום - עדיף לוותר


טופס עם שומרי מקום שנעלמים לגמרי

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

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

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


טופס עם שומרי מקום בניגודיות נמוכה

לא נגיש – ניגודיות נמוכה בתוך השדה.

אבל את שומרי המקום המיותרים האלה לא צריך לחזק אלא למחוק


טופס עם שומרי מקום בניגודיות טובה ותוויות קבועות

הכי נגיש – טופס הכניסה ל-Tesco. התוויות קבועות מחוץ לשדה, ניגודיות גבוהה גם בתוך השדה

7. פשוט זה הכי

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

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

ומילה אישית בעניין הזה לכותבי מיקרו-קופי:

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


טופס מתחכם מדי עם שומרי מקום בניגודיות נמוכה

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

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

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

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


Comentarios

No se pudieron cargar los comentarios
Parece que hubo un problema técnico. Intenta volver a conectarte o actualiza la página.
bottom of page