נגישות דיגיטלית היא תכנון ופיתוח של המוצרים הדיגיטליים שלכם כך שכל אדם, ללא קשר ליכולותיו הפיזיות או הנפשיות, יוכל לקיים אינטראקציה עם האתר, האפליקציה או מוצר דיגיטלי אחר שלכם באופן משמעותי ושוויוני.
אבל איך מודדים את הנגישות של מוצר דיגיטלי? איך אפשר לדעת אם משהו נגיש?
מבוא לבדיקת נגישות
יש הרבה דרכים לבדוק את הנגישות של מוצר דיגיטלי. אחת מהגישות הבסיסיות היא להעריך את האתר בהתאם לסטנדרטים של נגישות.
יש סוגים רבים של תקני נגישות. בדרך כלל, התחום שבו אתם פועלים, סוג המוצר, החוקים והמדיניות המקומיים והלאומיים או יעדי הנגישות הכוללים קובעים את קבוצת ההנחיות שעליכם לפעול לפיה ואת רמות הנגישות שעליכם לעמוד בהן. אם לא נדרש תקן ספציפי לפרויקט, ההמלצה הרגילה היא לפעול לפי הגרסה העדכנית ביותר של ההנחיות ליצירת תכנים נגישים לאינטרנט (WCAG).
בדיקה של המוצר הדיגיטלי בהתאם לתקן ולרמת תאימות לנגישות נקראת בדרך כלל בדיקת נגישות. בבדיקה של נגישות נעשה שימוש בשיטות, בשיטות ובכלים שונים, כולל בדיקות עיצוב, בדיקות אוטומטיות, בדיקות ידניות ובדיקות של טכנולוגיה מסייעת (AT).
ביצוע ביקורת נגישות כדי לתעד את רמת התאימות הבסיסית של מוצר דיגיטלי לנגישות. עם זאת, הפעלה אחת בתחילת הפרויקט לא מספיקה כדי לקבוע אם המוצר נגיש. מומלץ להריץ את הביקורת הזו כמה פעמים במהלך מחזור החיים של מוצרי התוכנה כדי לבדוק אם יש שינויים ברמת התאימות, בהשוואה לקבוצה של נקודות בקרה או הנחיות מוגדרות מראש בנושא נגישות.
ההמלצות להנגשת תכני אתרי אינטרנט (WCAG)
ההנחיות לגישה לתוכן אינטרנט (WCAG) הן קבוצה בינלאומית של תקני נגישות שפותחו על ידי W3C בשיתוף עם אנשים פרטיים וארגונים. המטרה של WCAG היא לספק תקן משותף אחד לנגישות דיגיטלית שיעמוד בצרכים של אנשים פרטיים, ארגונים וממשלות ברחבי העולם.
תקן WCAG מיועד בעיקר למעצבים ולמפתחים של אפליקציות מבוססות-אינטרנט ואפליקציות נייטיב. עם זאת, אנשים רבים אחרים, כולל מפתחי תוכנה, יוצרים או עורכים של תוכן וכל רמות הניהול, יכולים להפיק תועלת מהבנה של שיטות שמבוססות על WCAG ומהטמעתן בתהליך שלהם. יכול להיות שתקפים עליכם תקנים נוספים של W3C, כולל הנחיות לגבי נגישות של כלי עריכה (ATAG) והנחיות לגבי נגישות של סוכן משתמש (UAAG). לכן, חשוב לבדוק את רשימת התקנים של W3C ולהשתמש בתקנים שרלוונטיים ביותר לתפקיד ולפרויקט שלכם.
מבחינת נגישות, WCAG נחשב ל'תקן הזהב' לבדיקת תאימות. טיוטת WCAG הראשונה פורסמה בשנת 1999. הגרסה הנוכחית היא WCAG 2.2. WCAG 3.0 כולל טיוטה ראשונית נכון למאי 2024, אבל הוא לא צפוי להפוך לתקן W3C מלא עוד כמה שנים.
להנחיות WCAG יש שלוש רמות של קריטריונים להצלחה: A, AA ו-AAA. קריטריונים להצלחה קובעים את התאימות ל-WCAG. כדי לעמוד בדרישות התאימות ל-WCAG, המוצר הדיגיטלי שאתם בודקים צריך לעמוד בקריטריונים להצלחה ברמת היעד שלכם.
30
קריטריון להצלחה
20
קריטריונים להצלחה ב-AA
28
קריטריונים להצלחה ב-AAA
בתקן הנוכחי (WCAG 2.2), יש בסך הכול 87 קריטריונים להצלחה, שמחולקים לכל רמה. חשוב לציין שכל רמה היא מתקדמת יותר מהרמה הקודמת. כלומר, אם היעד שלכם הוא נגישות ברמה AA, עליכם לעמוד בקריטריונים להצלחה גם ברמה A וגם ברמה AA כדי להגיע לרמת התאימות הזו.
30
עוברים את רמת A
50
ציון עובר ברמה A + AA
78
עוברים את רמת A + AA + AAA
עקרונות הנגישות
הקריטריונים להצלחה של WCAG הם קבוצה חשובה מאוד של הנחיות מפורטות שמספקות למעצבים ולמפתחים מידע על יצירת אתרים ואפליקציות נגישים. חשוב להבין את ההנחיות האלה כדי לטפל בבעיות שמתעוררות בבדיקות התאימות לנגישות, אבל ההנחיות הופכות במהירות לטכניות מאוד.
אם אתם חדשים בתחום, כדאי להתחיל עם העקרונות של WCAG – ניתן לזיהוי, ניתן לשימוש, מובן ויציב (POUR). כשמיישמים את עקרונות POUR במוצרים הדיגיטליים, אפשר להתמקד באופן שבו אנשים אמיתיים, כולל אנשים עם מוגבלויות, משתמשים במוצרים.

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