יסודות הבדיקה הידנית
בבדיקות נגישות ידניות משתמשים במקלדת, בבדיקות חזותיות ובדיקות קוגניטיביות, בכלים ובטכניקות כדי למצוא בעיות שלא ניתן לזהות באמצעות כלים אוטומטיים. מכיוון שכלי אוטומטיים לא מכסים את כל קריטריוני ההצלחה שמופיעים ב-WCAG, חשוב להריץ בדיקות אוטומטיות של נגישות ולהמשיך לבדוק.
ככל שהטכנולוגיה מתקדמת, יותר בדיקות יכולות להתבצע רק באמצעות כלים אוטומטיים, אבל כיום, כדי לכסות את כל נקודות הבדיקה הרלוונטיות של WCAG, צריך להוסיף לפרוטוקולי הבדיקה גם בדיקות ידניות וגם בדיקות של טכנולוגיה מסייעת.
היתרונות של בדיקות נגישות ידניות:
- התהליך פשוט יחסית ומהיר
- לזהות אחוז גבוה יותר של בעיות מאשר בדיקות אוטומטיות בלבד
- לא נדרשים כלים רבים או מומחיות כדי להצליח
חסרונות של בדיקות נגישות ידניות:
- מורכבות יותר וגוזלות יותר זמן מבדיקות אוטומטיות
- יכול להיות שיהיה קשה לשחזר את התוצאות בקנה מידה נרחב
- נדרשת מומחיות רבה יותר בתחום הנגישות כדי להריץ בדיקות ולפרש את התוצאות
משווים בין רכיבי הנגישות והפרטים שאפשר לזהות באמצעות כלי אוטומטי לבין אלה שלא יזוהו.
סוגים של בדיקות ידניות
יש הרבה כלים וטכניקות ידניים שכדאי להשתמש בהם כשבודקים את הנגישות הדיגיטלית של דף אינטרנט או אפליקציה. שלושת התחומים העיקריים בבדיקות ידניות הם פונקציונליות המקלדת, בדיקות שמתמקדות בתוכן חזותי ובדיקות כלליות של התוכן.
במודול הזה אנחנו מסבירים כל אחד מהנושאים האלה ברמה גבוהה, אבל הבדיקות הבאות לא נועדו להיות רשימה מקיפה של כל הבדיקות הידניות שאפשר או שצריך להריץ. מומלץ להתחיל עם רשימת בדיקה ידנית לנגישות ממקור מהימן, ולפתח רשימת בדיקה ידנית ממוקדת משלכם בהתאם לצרכים הספציפיים של המוצר הדיגיטלי והצוות שלכם.
בדיקות מקלדת
ההערכה היא שכ-25% מכל בעיות הנגישות הדיגיטלית קשורות לחוסר תמיכה במקלדת. כפי שלמדנו במודול בנושא הדגשת המיקום במקלדת, הבעיה הזו משפיעה על כל סוגי המשתמשים, כולל משתמשים רואים שמשתמשים רק במקלדת, משתמשים לקויי ראייה או עיוורים שמשתמשים בקורא מסך, ואנשים שמשתמשים בתוכנת זיהוי קולי שמסתמכת על טכנולוגיה שדורשת שהתוכן יהיה נגיש גם באמצעות המקלדת.
בדיקות המקלדת עונות על שאלות כמו:
- האם דף האינטרנט או התכונה דורשים שימוש בעכבר כדי לפעול?
- האם סדר המעבר בין הכרטיסיות הגיוני ואינטואיטיבי?
- האם אינדיקטור מוקד ההקלדה תמיד מוצג?
- האם אפשר להיתקע באלמנט שלא אמור ללכוד את המיקוד?
- האם אפשר לנווט מאחורי או מסביב לרכיב שאמור לכלוא את המיקוד?
- כשסוגרים רכיב שהמיקוד עבר אליו, האם המיקוד חוזר למקום הגיוני?
ההשפעה של פונקציונליות המקלדת היא עצומה, אבל הליך הבדיקה הוא פשוט למדי. כל מה שצריך לעשות הוא להניח את העכבר בצד או להתקין חבילת JavaScript קטנה ולבדוק את האתר באמצעות המקלדת בלבד. הפקודות הבאות חיוניות לבדיקה באמצעות המקלדת.
בדיקות ויזואליות
בבדיקות ויזואליות מתמקדים באלמנטים ויזואליים בדף ומשתמשים בכלים כמו הגדלת המסך או שינוי גודל התצוגה בדפדפן כדי לבדוק את הנגישות של האתר או האפליקציה.
בדיקות ויזואליות יכולות להראות לכם:
- האם יש בעיות בניגודיות הצבעים שלא ניתן לזהות באמצעות כלי אוטומטי, כמו טקסט על גבי מעבר צבע או תמונה?
- האם יש אלמנטים שנראים כמו כותרות, רשימות ואלמנטים מבניים אחרים, אבל לא מקודדים ככאלה?
- האם קישורי הניווט וקלט הטופס עקביים בכל האתר או האפליקציה?
- האם יש הבהוב, אפקט סטרובוסקופי או אנימציה שחורגים מההמלצות?
- האם יש רווחים מתאימים בתוכן? לאותיות, למילים, לשורות ולפסקאות?
- האם אפשר לראות את כל התוכן באמצעות הגדלת המסך או הגדלת התצוגה בדפדפן?
בדיקות תוכן
בניגוד לבדיקות ויזואליות שמתמקדות בפריסות, בתנועה ובצבעים, בדיקות התוכן מתמקדות במילים שבדף. חשוב לא רק לבדוק את העותק עצמו, אלא גם את ההקשר כדי לוודא שהוא מובן לאחרים.
בדיקות התוכן מספקות תשובות לשאלות כמו:
- האם כותרות הדפים, הכותרות ותוויות הטפסים ברורות ותיאוריות?
- האם הטקסט החלופי של התמונות תמציתי, מדויק ושימושי?
- האם הצבע לבדו משמש כדרך היחידה להעברת משמעות או מידע?
- האם הקישורים תיאוריים או שאתם משתמשים בטקסט כללי כמו "מידע נוסף" או "לחצו כאן"?
- האם יש שינויים בשפה בתוך הדף?
- האם נעשה שימוש בשפה פשוטה והאם כל הראשי תיבות מפורטים בהתייחסות הראשונה אליהם?
חלק מבדיקות התוכן יכולות להתבצע באופן אוטומטי, לפחות בחלקן. לדוגמה, אפשר לכתוב כלי לבדיקת קוד JavaScript שמחפש את הטקסט 'לחצו כאן' ומציע לבצע שינוי. עם זאת, כדי שהפתרונות המותאמים אישית האלה יפעלו, לרוב עדיין צריך שאדם ישנה את הטקסט כך שיתאים להקשר.
הדגמה: בדיקה ידנית
עד עכשיו, הפעלנו בדיקות אוטומטיות בדף האינטרנט של ההדגמה שלנו, ומצאנו ותיקנו שמונה סוגים שונים של בעיות. עכשיו אנחנו מוכנים להריץ בדיקות ידניות כדי לראות אם נוכל לגלות עוד בעיות נגישות.
שלב 1
בהדגמה המעודכנת של CodePen מיושמים כל העדכונים האוטומטיים של הנגישות.
כדי להמשיך לבדיקות הבאות, צריך להציג את התוצאה במצב ניפוי באגים. זה חשוב כי הפעולה הזו מסירה את התג <iframe> שמקיף את דף האינטרנט של ההדגמה, וזה עלול להפריע לכמה כלי בדיקה. מידע נוסף על מצב ניפוי הבאגים של CodePen
שלב 2
כדי להתחיל את תהליך הבדיקה הידנית, צריך להניח בצד את העכבר או את משטח המגע ולנווט למעלה ולמטה ב-DOM באמצעות המקלדת בלבד.
בעיה 1: אינדיקטור מיקוד גלוי
הבעיה הראשונה במקלדת אמורה להופיע מיד – או יותר נכון, לא להופיע – כי הסרנו את אינדיקטור המיקוד הגלוי. כשסורקים את ה-CSS בהדגמה, אמורה להופיע השורה המפחידה outline: none שנוספה לבסיס הקוד.
:focus {
outline: none;
}
כפי שלמדתם במודול בנושא מיקוד במקלדת, צריך להסיר את שורת הקוד הזו כדי לאפשר לדפדפני אינטרנט להוסיף מיקוד גלוי למשתמשים. אפשר להוסיף עוד שלב וליצור סגנון של אינדיקטור למיקוד שמתאים לאסתטיקה של המוצר הדיגיטלי.
:focus {
outline: 3px dotted #008576;
}
בעיה 2: סדר המיקוד
אחרי שמשנים את סימן המיקוד ומוודאים שהוא גלוי, חשוב להשתמש במקש Tab כדי לעבור בין הרכיבים בדף. במהלך ההקלדה, תשימו לב ששדה להזנת קלט של הטופס שמשמש להרשמה לניוזלטר לא מקבל מיקוד. הוסר מסדר המיקוד הטבעי באמצעות tabindex שלילי.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
כדי שאנשים יוכלו להשתמש בשדה הזה כדי להירשם לניוזלטר שלנו, כל מה שצריך לעשות הוא להסיר את ה-tabindex השלילי או להגדיר אותו לאפס כדי שהקלט יוכל לקבל שוב פוקוס מהמקלדת.
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>
שלב 3
אחרי שבודקים את המיקוד במקלדת, עוברים לבדיקות ויזואליות ובדיקות תוכן.
בעיה 3: ניגודיות הצבע של הקישור
כשעברתם על בדיקות המקלדת באמצעות מקש Tab למעלה ולמטה בדף ההדגמה, סביר להניח ששמתם לב שהמקלדת התמקדה בשלושה קישורים מוסתרים ויזואלית בפסקאות על המצבים הרפואיים השונים.
כדי שהדף שלנו יהיה נגיש, הקישורים צריכים להיות בולטים מהטקסט שמסביב ולכלול שינוי סגנון שאינו מבוסס על צבע כשמעבירים את העכבר מעל הקישור או כשמתמקדים בו באמצעות המקלדת.
פתרון מהיר הוא להוסיף קו תחתון לקישורים בתוך הפסקאות כדי שהם יבלטו. הפעולה הזו תפתור את בעיית הנגישות, אבל יכול להיות שהיא לא תתאים לאסתטיקה העיצובית הכוללת שאתם רוצים להשיג.
אם בוחרים שלא להוסיף קו תחתון, צריך לשנות את הצבעים כך שיעמדו בדרישות של הרקע והטקסט.
כשבודקים את ההדגמה באמצעות כלי לבדיקת ניגודיות של קישורים, אפשר לראות שצבע הקישור עומד בדרישה של יחס ניגודיות של 4.5:1 בין טקסט בגודל רגיל לבין הרקע. עם זאת, קישורים שלא מודגשים בקו תחתון צריכים גם לעמוד בדרישה של ניגודיות צבעים של 3:1 ביחס לטקסט שמסביב.
אפשרות אחת היא לשנות את צבע הקישור כך שיתאים לרכיבים האחרים בדף. אבל אם משנים את צבע הקישור לירוק, צריך לשנות גם את הטקסט בגוף ההודעה כדי לעמוד בדרישות הניגודיות הכוללות בין שלושת הרכיבים: הקישורים, הרקע והטקסט שמסביב.
בעיה 4: ניגודיות הצבע של הסמל
בעיה נוספת של ניגודיות צבעים שלא זוהתה היא הסמלים של הרשתות החברתיות. במודול צבע וניגודיות למדתם שצריך שיהיה יחס ניגודיות של 3:1 בין צבע הרקע לבין צבע האייקונים החיוניים. עם זאת, בהדגמה, יחס הניגודיות של הסמלים של הרשתות החברתיות הוא 1.3:1.
כדי לעמוד בדרישות של ניגודיות צבעים של 3:1, הסמלים של הרשתות החברתיות משתנים לאפור כהה יותר.

בעיה 5: פריסת התוכן
אם בוחנים את הפריסה של תוכן הפסקה, הטקסט מיושר באופן מלא. כמו שלמדתם במודול בנושא טיפוגרפיה, זה יוצר 'נהרות של רווחים', שיכולים להקשות על חלק מהמשתמשים לקרוא את הטקסט.
p.bullet {
text-align: justify;
}
כדי לאפס את יישור הטקסט בהדגמה, אפשר לעדכן את הקוד ל-text-align: left; או להסיר את השורה הזו לגמרי מ-CSS, כי יישור לשמאל הוא ברירת המחדל בדפדפנים. חשוב לבדוק את הקוד, למקרה שסגנונות אחרים שעברו בירושה יסירו את יישור הטקסט שמוגדר כברירת מחדל.
p.bullet {
text-align: left;
}
שלב 4
אחרי שמזהים ומתקנים את כל בעיות הנגישות הידניות שמתוארות בשלבים הקודמים, הדף אמור להיראות כמו צילום המסך שלנו.
יכול להיות שתמצאו בעיות נגישות נוספות בבדיקות הידניות שלכם, שלא כיסינו במודול הזה. במודול הבא נדבר על הרבה מהבעיות האלה.
השלב הבא
כל הכבוד! השלמתם את המודולים של הבדיקות האוטומטיות והידניות. אפשר לעיין בגרסה המעודכנת של CodePen, שבה מיושמים כל התיקונים האוטומטיים והידניים של הנגישות.
עכשיו אפשר לעבור למודול הבדיקה האחרון שמתמקד בבדיקת טכנולוגיה מסייעת.