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