עקרונות בסיסיים של בדיקות ידניות
בדיקות נגישות ידניות משתמשות בבדיקות מקלדת, ויזואליות וקוגניטיבית, כלים ושיטות לזיהוי בעיות שהכלים האוטומטיים לא יכולים. באופן אוטומטי הכלים לא מכסים את כל הקריטריונים להצלחה שצוינו ב-WCAG, חיוני שאתם לא מריצים בדיקות נגישות אוטומטיות ואז מפסיקים את הבדיקה!
עם התקדמות הטכנולוגיה, יכול להיות שכלים אוטומטיים יכסו יותר בדיקות בלבד, אבל כיום צריך להוסיף לפרוטוקולים של הבדיקה גם בדיקות ידניות וגם בדיקות של טכנולוגיה מסייעת כדי לכסות את כל נקודות הביקורת הרלוונטיות של WCAG.
היתרונות של בדיקות נגישות ידניות:
- הפעלה פשוטה ומהירה במידה סבירה
- להשיג אחוז גבוה יותר של בעיות מאשר בדיקות אוטומטיות בלבד
- מעט כלים ומומחיות נדרשים כדי להצליח
החסרונות של בדיקות נגישות ידניות:
- בדיקות מורכבות יותר ודורשות זמן רב יותר מבדיקות אוטומטיות
- יכול להיות שיהיה קשה לחזור על הפעולה בקנה מידה גדול
- נדרשת מומחיות נגישות רבה יותר כדי להריץ בדיקות ולפרש את התוצאות
נשווה בין הרכיבים והפרטים של הנגישות שאפשר לזהות כרגע באמצעות כלי אוטומטי, לעומת אלה שלא יזוהו.
סוגים של בדיקות ידניות
יש הרבה שיטות וכלים ידניים שצריך לשקול כשבודקים את לדף אינטרנט או לאפליקציה לנגישות דיגיטלית. שלושת התחומים עיקריים שבהם מתמקדים בדיקות ידניות הן פונקציונליות של המקלדת, ביקורות שמתמקדות מבחינה חזותית בדיקות תוכן כלליות.
במודול הזה נעסוק בכל אחד מהנושאים האלה ברמה גבוהה, אבל הבדיקות הבאות לא נועדו להיות רשימה מקיפה של כל הבדיקות הידניות שאפשר או כדאי להריץ. מומלץ להתחיל עם רשימת משימות לנגישות ידנית ממקור מהימן ולפתח רשימת משימות ייעודית לבדיקות ידניות בהתאם לצרכים של הצוות ולמוצר הדיגיטלי הספציפי שלכם.
בדיקות מקלדת
ההערכה היא שכ-25% מכל בעיות הנגישות הדיגיטלית קשורות בגלל היעדר תמיכה במקלדת. כמו שלמדנו במודול התמקדות במקלדת, הבעיה הזו משפיעה על כל סוגי המשתמשים, כולל משתמשים עם ליקויי ראייה, משתמשים עם ליקויי ראייה או קוראי מסך עיוורים ואנשים שמשתמשים בתוכנות לזיהוי קולי שעושות שימוש בטכנולוגיה שמסתמכת על כך שתוכן מסוים גם נגיש באמצעות המקלדת.
בדיקות מקלדת עונות על שאלות כמו:
- האם יש צורך בעכבר כדי לפעול בדף האינטרנט או בתכונה הזו?
- האם הסדר של הכרטיסיות הוא הגיוני ואינטואיטיבי?
- האם האינדיקטור של מיקוד המקלדת תמיד מוצג?
- האם אתם יכולים להיתקע באלמנט שלא אמור "ללכוד את המיקוד"?
- האם אתם יכולים לנווט מאחורי אלמנט כלשהו שאמור לתפוס את המיקוד?
- כשסוגרים רכיב שקיבל מיקוד, האם אינדיקטור המיקוד חזר למקום הגיוני?
ההשפעה של פונקציונליות המקלדת היא עצומה, אבל תהליך הבדיקה די פשוט. כל מה שצריך לעשות הוא להניח את העכבר בצד או להתקין חבילת JavaScript קטנה ולבדוק את האתר באמצעות המקלדת בלבד. הפקודות הבאות חיוניות לבדיקת המקלדת.
בדיקות ויזואליות
בדיקות חזותיות מתמקדות ברכיבים חזותיים של הדף, ונעזרות בכלים כמו הגדלת מסך או שינוי מרחק התצוגה בדפדפן כדי לבדוק את הנגישות באתר או באפליקציה.
בעזרת בדיקות חזותיות אפשר:
- יש בעיות של ניגודיות צבעים שכלי אוטומטי לא יכול לזהות, כמו טקסט על גבי הדרגתי או תמונה?
- האם יש רכיבים שנראים כמו כותרות, רשימות או אלמנטים מבניים אחרים, אבל הם לא מקודדים כך?
- האם קישורי הניווט והקלט בטופס הם עקביים בכל האתר או האפליקציה?
- האם יש הבהובים, הבהובים או אנימציה שחורגים מההמלצות?
- האם התוכן כולל רווחים תקינים? לאותיות, למילים, לשורות ולפסקאות?
- האם אפשר לראות את כל התוכן באמצעות הגדלת מסך או שינוי מרחק התצוגה בדפדפן?
בדיקות תוכן
בשונה מבדיקות חזותיות שמתמקדות בפריסות, בתנועה ובצבעים, בדיקות התוכן מתמקדות במילים שבדף. חשוב לא רק לעיין בעותק עצמו, אלא גם לבדוק את ההקשר כדי לוודא שאחרים מבינים אותו.
בדיקות התוכן עונות על שאלות כמו:
- האם הכותרות, הכותרות ותוויות הטפסים ברורות ותיאוריים?
- האם החלופות לתמונות תמציתיות, מדויקות ושימושיות?
- האם הצבע לבדו הוא הדרך היחידה להעביר משמעות או מידע?
- האם הקישורים תיאוריים או שנעשה שימוש בטקסט כללי כמו 'למידע נוסף' או 'לחצו כאן?'
- האם חלו שינויים בשפה בדף?
- האם משתמשים בשפה פשוטה והאם כל ראשי התיבות מאויתים בתחילת השם?
חלק מבדיקות התוכן יכולות להיות אוטומטיות, באופן חלקי. לדוגמה, אפשר לכתוב איתור שגיאות בקוד של 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
אחרי שבודקים את מיקוד המקלדת, עוברים לבדיקות חזותיות ותוכן.
בעיה 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 המעודכן שלנו, שבו חלים כל תיקוני הנגישות האוטומטיים והידניים.
עכשיו נעבור למודול הבדיקה האחרון שמתמקד בדיקת טכנולוגיה מסייעת.
בדיקת ההבנה
בחינת הידע שלכם לגבי בדיקות נגישות ידניות
אילו רכיבים צריכים לעמוד בסטנדרטים של WCAG לניגודיות צבעים?