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

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

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

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