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

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

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

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

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

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

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

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

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

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


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

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

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

בדיקות מקלדת

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

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

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

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

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

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

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

בעזרת בדיקות חזותיות אפשר:

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

בדיקות תוכן

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

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

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

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

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

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

שלב 1

בהדגמה של CodePen יש את כל של עדכוני הנגישות האוטומטיים שהוחלו.

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

שלב 2

מתחילים את תהליך הבדיקה הידנית: מניחים את העכבר או משטח המגע בצד ומנווטים למעלה ולמטה ב-DOM באמצעות המקלדת בלבד.

בעיה 1: אינדיקטור של המיקוד גלוי

הבעיה הראשונה במקלדת אמורה להופיע מיד, או שהבעיה לא אמורה להופיע כזאת – כי אינדיקטור המיקוד הגלוי הוסר. כשתסרקו את ה-CSS בהדגמה, אתם אמורים לראות שהמתג האימה 'outline: none' יתווסף ל-codebase.

  :focus {
    outline: none;
  }
בואו נפתור את זה.

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

:focus {
  outline: 3px dotted #008576;
}

בעיה 2: סדר המיקוד

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

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
בואו נפתור את זה.

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

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>

שלב 3

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

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

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

בואי נפתור את זה.

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

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

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

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

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