איך לשלב נגישות בתהליך של הצוות.
שיפור הנגישות של האתר יכול להיות משימה מרתיעה. אם אתם ניגשים לנושא הנגישות בפעם הראשונה, יכול להיות שהיקף הנושא יבלבל אתכם ותתהו מאיפה להתחיל. אחרי הכל, כשעובדים כדי להתאים את השירות למגוון רחב של יכולות, צריך להביא בחשבון מגוון רחב של בעיות.
חשוב לזכור שנגישות היא מאמץ קבוצתי. לכל אדם יש תפקיד. במאמר הזה מפורטים קריטריונים לכל אחד מהתחומים העיקריים (מנהל פרויקט, מעצב UX ומפתח) כדי שכל אחד מהם יוכל לשלב את השיטות המומלצות לגישה נגישה בתהליך העבודה שלו.
מנהל פרויקטים
המטרה העיקרית של כל מנהל פרויקט היא לנסות לכלול עבודה על נגישות בכל אבן דרך, ולוודא שהיא בעדיפות זהה לנושאים אחרים כמו ביצועים וחוויית משתמש. ריכזנו כאן כמה פריטים ברשימת המשימות שכדאי לזכור במהלך התהליך.
- להפוך את ההדרכה בנושא נגישות לזמינה לצוות.
- זיהוי של תהליכי המרה קריטיים של משתמשים באתר או באפליקציה.
- כדאי לשלב רשימת משימות בנושא נגישות בתהליך העבודה של הצוות.
- במידת האפשר, כדאי להעריך את האתר או האפליקציה באמצעות מחקרי משתמשים.
הדרכה בנושא נגישות
יש כמה מקורות מידע מעולים בחינם שאפשר להיעזר בהם כדי ללמוד על נגישות באינטרנט. כדאי להקדיש זמן כדי שהצוות שלכם ילמד את הנושא, כדי שיהיה קל יותר לכלול נגישות בשלב מוקדם בתהליך.
מקורות מידע מסוימים ש-Google מספקת כוללים:
Web Accessibility by Google – קורס הדרכה אינטראקטיבי שנמשך כמה שבועות.
עקרונות בסיסיים של נגישות – מדריכים בכתב ושיטות מומלצות בנושא נגישות.
הנחיות Material: נגישות – אוסף של שיטות מומלצות לשיפור חוויית המשתמש בעיצוב שמתאים לכולם.
זיהוי תהליכים קריטיים של משתמשים
לכל אפליקציה יש פעולה ראשית שהמשתמש צריך לבצע. לדוגמה, אם אתם מפתחים אפליקציית מסחר אלקטרוני, כל משתמש צריך להיות מסוגל להוסיף פריט לעגלת הקניות שלו.
יכול להיות שפעולות מסוימות יהיו חשובות פחות, או שיתבצעו רק מדי פעם. לדוגמה, שינוי תמונת הדמות היא תכונה נעימה, אבל היא לא חיונית לכל חוויה.
זיהוי הפעולות הראשיות והמשניות באפליקציה יעזור לכם לתעדף את העבודה שצריך לבצע כדי לשפר את הנגישות. בהמשך תוכלו לשלב את הפעולות האלה עם רשימת משימות לנגישות כדי לעקוב אחרי ההתקדמות ולהימנע מנסיגה לאחור.
שילוב של רשימת משימות בנושא נגישות
נושא הנגישות רחב למדי, ולכן כדאי להשתמש ברשימת משימות של תחומים חשובים שצריך להביא בחשבון כדי לוודא שאתם מכסים את כל הנושאים.
יש כמה רשימות של אמצעי נגישות, למשל:
רשימת משימות של WebAIM ל-WCAG הנחיות הנגישות של Vox
בעזרת רשימת המשימות תוכלו לבדוק את הפעולות הראשיות והמשניות כדי להתחיל לחלק את המשימות שעדיין צריך לבצע. אפשר להתייחס לתהליך הזה בצורה טקטית, ואפילו ליצור מטריקס של פעולות ראשיות ומשניות, ולקבוע בכל שלב בתהליכים האלה אם יש רכיבי נגישות חסרים.
הערכה באמצעות מחקרי משתמשים
אין כמו לשבת עם משתמשים אמיתיים ולראות איך הם מנסים להשתמש באפליקציה. אם אתם מוסיפים נגישות לחוויית משתמש קיימת, התהליך הזה יכול לעזור לכם לזהות במהירות אזורים שצריך לשפר. בנוסף, אם אתם מתחילים פרויקט חדש, מחקרי משתמשים מוקדמים יכולים לעזור לכם להימנע מלבלות יותר מדי זמן בפיתוח תכונה שקשה להשתמש בה.
כדאי לשאוף לשלב משוב ממגוון רחב ככל האפשר של משתמשים. חשוב להביא בחשבון משתמשים שמנווטים בעיקר באמצעות המקלדת, או משתמשים שמסתמכים על טכנולוגיה מסייעת כמו קוראי מסך או מגדלי מסך.
מעצב UX
אנשים נוטים לעצב על סמך ההטיות שלהם, ולכן אם אתם לא נתקלים בבעיות נגישות ואין לכם עמיתים עם מוגבלויות, יכול להיות שאתם מעצבים בלי כוונה רק לחלק מהמשתמשים. תוך כדי העבודה, כדאי לשאול את עצמכם "מהם כל סוגי המשתמשים שעשויים להסתמך על העיצוב הזה?" ריכזנו כאן כמה שיטות שאפשר לנסות כדי להפוך את התהליך למקיף יותר.
- יש מספיק ניגודיות בין הצבעים בתוכן.
- סדר הכרטיסיות מוגדר.
- לפקדים יש תוויות נגישות.
- יש כמה דרכים לבצע פעולות בממשק המשתמש.
לתוכן יש ניגודיות צבעים טובה
המטרה העיקרית של רוב האתרים היא להעביר מידע כלשהו למשתמש, באמצעות טקסט כתוב או תמונות. עם זאת, אם לתוכן הזה יש ניגודיות נמוכה, יכול להיות שיהיה קשה לחלק מהמשתמשים (במיוחד למשתמשים עם ליקויי ראייה) לקרוא אותו. הפעולה הזו עלולה להשפיע לרעה על חוויית המשתמש שלהם. כדי לטפל בבעיה הזו, כדאי להקפיד שכל הטקסטים והתמונות יהיו בעלי ניגודיות מספקת בין הצבעים.
הניגודיות נמדדת על ידי השוואה בין הבהירות של צבע החזית לבין הבהירות של צבע הרקע. לטקסט קטן יותר (כל טקסט שגודל הגופן שלו קטן מ-18 נקודות או 14 נקודות בכתב מודגש), מומלץ לשמור על יחס מינימלי של 4.5:1. בטקסט גדול יותר, אפשר לשנות את היחס הזה ל-3:1.
בתמונה שבהמשך, הטקסט בצד ימין עומד בדרישות המינימום של הניגודיות, ואילו הטקסט בצד ימין כולל ניגודיות נמוכה.
יש כמה כלים למדידת ניגודיות צבעים, כמו Material Color Tool של Google, האפליקציה של Lea Verou לחישוב יחס ניגודיות ו-aXe של Deque.
הגדרת סדר הכרטיסיות
סדר ה-Tab הוא הסדר שבו האובייקטים מקבלים את המיקוד כשהמשתמש מקשיב על מקש Tab. למשתמשים שמנווטים בעיקר באמצעות מקלדת, מקש Tab הוא הדרך העיקרית שלהם להגיע לכל מה שמופיע במסך. אפשר להתייחס אליו כאל סמן העכבר שלהם.
באופן אידיאלי, סדר הכרטיסיות צריך להיות זהה לסדר הקריאה, ולהתחיל בחלק העליון של הדף ולהמשיך כלפי מטה, כאשר פריטים חשובים יותר מופיעים גבוה יותר בסדר. כך קל יותר להגיע לפריטים האלה במהירות לכל מי שמשתמש במקלדת.
הממשק המדומה שלמעלה ממוספר כדי להציג את סדר הכרטיסיות. יצירת מודל לדוגמה יכולה לעזור לכם לזהות את סדר הכרטיסיות המיועד. לאחר מכן אפשר לשתף את הקוד עם המפתחים ובודקי ה-QA כדי לוודא שהוא הוטמע ונבדק כראוי.
לפקדים יש תוויות נגישות
תוויות מספקות מידע למשתמשים בטכנולוגיות מסייעות, כמו קוראי מסך, שבלעדיהן המידע היה זמין רק באופן חזותי. לדוגמה, לחצן חיפוש שהוא רק סמל של זכוכית מגדלת יכול לכלול תווית נגישה עם הכיתוב 'חיפוש' כדי למלא את החסך בסימן החזותי.
ריכזנו כאן כמה הצעות פשוטות שיעזרו לכם לעצב תוויות נגישות:
- קצרים וברורים – יכול להיות משעמם להאזין לתיאורים ארוכים.
- נסו לא לכלול את סוג הרכיב או המצב שלו – אם הרכיב מקודד בצורה נכונה, קורא המסך יקריא אותו באופן אוטומטי.
- כותבים את ההוראות בניסוח פעיל, במילים פשוטות עם פעלים ברורים ובלי להשתמש בז'רגון ספציפי לתחומים מסוימים.
מומלץ ליצור מודל לדוגמה עם תוויות לכל אמצעי הבקרה. אפשר לשתף את הקוד עם צוות הפיתוח ועם צוות בקרת האיכות לצורך הטמעה ובדיקה.
דרכים רבות לאינטראקציה עם ממשק המשתמש ולהבנה שלו
קל להניח שכל המשתמשים יוצרים אינטראקציה עם הדף בעיקר באמצעות עכבר. כשמעצבים, חשוב להביא בחשבון איך משתמשים יתנהלו עם אמצעי הבקרה באמצעות מקלדת.
תכנון מצבי המיקוד כלומר, קובעים איך הפקד ייראה כשהמשתמש יתמקד בו באמצעות מקש Tab או ילחץ על מקשי החיצים. מומלץ לתכנן את המצבים האלה מוקדם, במקום לנסות להכניס אותם לעיצוב מאוחר יותר.
לבסוף, בכל נקודת אינטראקציה, חשוב לוודא שלמשתמש יש כמה דרכים להבין את התוכן. נסו לא להשתמש בצבע בלבד כדי להעביר מידע, כי יכול להיות שמשתמשים עם קושי בהבחנה בין צבעים שונים לא יבחינו באותות העדינים האלה. דוגמה קלאסית היא שדה טקסט לא תקין. במקום רק קו תחתון אדום כדי לציין בעיה, כדאי להוסיף גם טקסט עזר. כך תוכלו להגדיל את הסיכוי שהמשתמשים יבחינו בבעיה.
מפתח
התפקיד של המפתח הוא מקום שבו ניהול המיקוד והסמנטיקה משתלבים כדי ליצור חוויית משתמש חזקה. ריכזנו כאן כמה דברים שכדאי למפתחים לזכור כשהם עובדים על האתר או האפליקציה שלהם:
- סדר הכרטיסיות הוא לוגי.
- המיקוד מנוהל כראוי ומוצג בצורה נכונה.
- לרכיבים אינטראקטיביים יש תמיכה במקלדת.
- תפקידים ומאפיינים של ARIA חלים לפי הצורך.
- הרכיבים מסומנים כראוי.
- הבדיקה היא אוטומטית.
סדר כרטיסיות לוגי
רכיבים מקומיים כמו input, button ו-select מצורפים לסדר הכרטיסיות בחינם, וניתן להתמקד בהם באופן אוטומטי באמצעות המקלדת. אבל לא כל הרכיבים מקבלים את אותה התנהגות. באופן ספציפי, רכיבים כלליים כמו div ו-span לא נכללים בסדר הקלדת Tab. כלומר, אם משתמשים ב-div כדי ליצור פקד אינטראקטיבי, צריך לבצע עבודה נוספת כדי לאפשר גישה למקלדת.
שתי אפשרויות הן:
- נותנים לפקד
tabindex="0". כך תוכלו לפחות להעביר אליו את המיקוד, אבל סביר להניח שתצטרכו לבצע עבודה נוספת כדי להוסיף תמיכה בהקשות על מקשים. - ככל האפשר, מומלץ להשתמש ב-
buttonבמקום ב-divאו ב-spanבכל אמצעי בקרה שנראה כמו לחצן. קל מאוד להגדיר סגנון לרכיבbuttonהמקורי, ויש לו תמיכה במקלדת בחינם.
ניהול המיקוד
כשמשנים את התוכן של הדף, חשוב להפנות את תשומת הלב של המשתמש על ידי העברת המיקוד. דוגמה קלאסית למקרה שבו השיטה הזו שימושית היא פתיחת תיבת דו-שיח מודאלית. אם משתמש שמשתמש במקלדת לוחץ על לחצן כדי לפתוח תיבת דו-שיח והמיקוד לא מועבר אל רכיב תיבת הדו-שיח, האפשרות היחידה שלו היא להקיש על Tab לאורך כל האתר עד שהוא מוצא את הרכיב החדש. העברת המיקוד לתוכן החדש ברגע שהוא מופיע יכולה לשפר את היעילות של חוויית המשתמש של המשתמשים האלה.
תמיכה במקלדת לרכיבים אינטראקטיביים
אם אתם יוצרים רכיב בקרה מותאם אישית כמו קרוסלה או תפריט נפתח, תצטרכו לבצע עבודה נוספת כדי להוסיף תמיכה במקלדת. מדריך לשיטות כתיבת ARIA הוא מקור מידע שימושי שמזהה דפוסים שונים של ממשק משתמש ואת סוגי הפעולות במקלדת שהם אמורים לתמוך בהן.
מידע נוסף על הוספת תמיכה במקלדת לאלמנט זמין בקטע Tabindex נע במסמכי העזרה של Google בנושא יסודות הנגישות.
תפקידים ומאפיינים של ARIA חלים לפי הצורך
אמצעי הבקרה המותאמים אישית צריכים לא רק תמיכה מתאימה במקלדת, אלא גם סמנטיקה מתאימה. אחרי הכל, מבחינה סמנטית, div הוא רק מאגר כללי של קיבוץ. אם אתם משתמשים ב-div כבסיס לתפריט הנפתח, תצטרכו להסתמך על ARIA כדי להוסיף שכבה של סמנטיקה נוספת, כדי שסוג הרכיב יועבר לטכנולוגיה מסייעת. גם כאן, המדריך לשיטות כתיבת ARIA יכול לעזור לכם לזהות באילו תפקידים, מצבים ומאפיינים כדאי להשתמש.
כתוספת, הרבה מההסברים במדריך ARIA כוללים גם קוד לדוגמה.
רכיבי תוויות
כדי לתייג קלט מקורי, אפשר להשתמש ברכיב <label> המובנה, כפי שמתואר ב-MDN. כך תוכלו ליצור סימון חזותי במסך, וגם לתת לשדה הקלט שם נגיש בעץ הנגישות. לאחר מכן, הטכנולוגיה המסייעת (כמו קורא מסך) מזהה את השם הזה ומקריאה אותו למשתמש.
לצערנו, <label> לא תומך במתן שם נגיש לאמצעי בקרה מותאמים אישית (כמו אמצעי בקרה שנוצרו באמצעות רכיבים מותאמים אישית או מ-divs ו-spans פשוטים). כדי להשתמש באמצעי הבקרה האלה, צריך להשתמש במאפיינים aria-label ו-aria-labelledby.
בדיקה אוטומטית
לפעמים עצלות יכולה להיות דבר טוב, במיוחד כשמדובר בבדיקות. כשהדבר אפשרי, כדאי להפוך את בדיקות הנגישות לאוטומטיות כדי שלא תצטרכו לבצע את כל הפעולות באופן ידני. יש היום כמה כלים מעולים לבדיקות בתעשייה, שבעזרתם אפשר לבדוק בקלות ובמהירות אם יש בעיות נגישות נפוצות:
aXe, שנוצר על ידי Deque systems, זמין כתוסף ל-Chrome וכמודול של Node (מתאים לסביבות של שילוב רציף). ב-A11ycast הקצר הזה מוסברות כמה דרכים שונות לשילוב aXe בתהליך הפיתוח.
Lighthouse הוא פרויקט קוד פתוח של Google לבדיקת הביצועים של אפליקציות האינטרנט המתקדמות (PWA). בנוסף לבדיקה אם ל-PWA יש תמיכה בדברים כמו Service Worker ו-Manifest של אפליקציית אינטרנט, Lighthouse מריץ גם סדרה של בדיקות של שיטות מומלצות, כולל בדיקות לבעיות נגישות.
סיכום
נגישות היא מאמץ קבוצתי. לכל אחד יש תפקיד. במדריך הזה פירטנו כמה נושאים מרכזיים שכל חבר צוות יכול להיעזר בהם כדי להתעדכן במהירות בנושא, ובתקווה לשפר את חוויית השימוש הכוללת באפליקציה.
למידע נוסף על נגישות, מומלץ לעיין בקורס החינמי שלנו ב-Udacity ובמסמכים בנושא נגישות שזמינים כאן ב-web.dev.