בדיקת נגישות ידנית

יסודות הבדיקה הידנית

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

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

היתרונות של בדיקות נגישות ידניות:

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

חסרונות של בדיקות נגישות ידניות:

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

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

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


סוגים של בדיקות ידניות

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

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

בדיקות מקלדת

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

בדיקות המקלדת עונות על שאלות כמו:

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

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

מפתח תוצאה
Tab מעבר קדימה מרכיב פעיל אחד לרכיב פעיל אחר
Shift + Tab מעבר אחורה מרכיב פעיל אחד לרכיב פעיל אחר
חיצים מעבר בין הגדרות קשורות
מקש הרווח מעבר בין מצבים וגלילה למטה בדף
Shift + מקש הרווח מעבר למעלה בדף
Enter מפעיל אמצעי בקרה ספציפיים
Escape הסרת אובייקטים שמוצגים באופן דינמי

בדיקות ויזואליות

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

בדיקות ויזואליות יכולות להראות לכם:

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

בדיקות תוכן

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

בדיקות התוכן מספקות תשובות לשאלות כמו:

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

חלק מבדיקות התוכן יכולות להתבצע באופן אוטומטי, לפחות בחלקן. לדוגמה, אפשר לכתוב כלי לבדיקת קוד 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

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

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

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

רוצה לפתור את זה יחד?

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

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

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

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

צילום מסך של WebAIM לטקסט קישור מראה שהקישור לטקסט הגוף לא עומד בדרישות של רמה A ב-WCAG.
אם הקישור וטקסט הגוף זהים, הבדיקה נכשלת.
צילום מסך של WebAIM מראה שכל הבדיקות עוברות כשהצבע של הקישור הוא ירוק.
אם הקישור והטקסט של גוף ההודעה שונים, הבדיקה עוברת.

בעיה 4: ניגודיות הצבע של הסמל

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

רוצה לפתור את זה יחד?

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

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

בעיה 5: פריסת התוכן

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

p.bullet {
   text-align: justify;
}
רוצה לפתור את זה יחד?

כדי לאפס את יישור הטקסט בהדגמה, אפשר לעדכן את הקוד ל-text-align: left; או להסיר את השורה הזו לגמרי מ-CSS, כי יישור לשמאל הוא ברירת המחדל בדפדפנים. חשוב לבדוק את הקוד, למקרה שסגנונות אחרים שעברו בירושה יסירו את יישור הטקסט שמוגדר כברירת מחדל.

p.bullet {
   text-align: left;
}

שלב 4

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

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

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

השלב הבא

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

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