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

עקרונות בסיסיים של בדיקה ידנית

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

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

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

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

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

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

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

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


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

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

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

בדיקות מקלדת

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

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

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

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

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

בדיקות חזותיות

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

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

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

בדיקות תוכן

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

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

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

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

הדגמה: בדיקה ידנית

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

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

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

בדיקת ההבנה

בדיקת הידע שלכם בנושא בדיקת נגישות ידנית

אילו רכיבים צריכים לעמוד בסטנדרטים של ניגודיות צבעים של WCAG?

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