עד עכשיו למדתם על ההיבטים האישיים, העסקיים והמשפטיים של נגישות דיגיטלית, ועל העקרונות הבסיסיים של תאימות לנגישות דיגיטלית. למדתם על נושאים ספציפיים שקשורים לעיצוב ולתכנות כוללים, כולל מתי כדאי להשתמש ב-ARIA לעומת HTML, איך למדוד את הניגודיות בין צבעים, מתי JavaScript חיונית ועוד.
במודולים הנותרים, נעבור מהתכנון והפיתוח לבדיקת הנגישות. אנחנו נשתמש בתהליך בדיקה בן שלושה שלבים שכולל כלים ושיטות לבדיקת טכנולוגיות אוטומטיות, ידניות ועזר. נשתמש באותו דף הדגמה בכל המודולים האלה כדי לשפר את הנגישות של דף האינטרנט.
כל בדיקה – אוטומטית, ידנית וטכנולוגיית עזר – חיונית כדי ליצור מוצר נגיש ככל האפשר. הבדיקות שלנו מבוססות על רמת התאימות A ו-AA של ההנחיות לנגישות בתוכן אינטרנטי (WCAG) 2.1.
חשוב לזכור שהתחום שבו אתם פועלים, סוג המוצר, החוקים והמדיניות המקומיים והמדינתיים או היעדים הכוללים של הנגישות קובעים אילו הנחיות לפעול לפיהן ואילו רמות צריך לעמוד בהן. אם אתם לא צריכים תקן ספציפי לפרויקט, מומלץ להשתמש בגרסה העדכנית של WCAG. למידע כללי על ביקורות נגישות, סוגי תאימות או רמות תאימות, WCAG ו-POUR, אפשר לעיין במאמר איך מודדים נגישות דיגיטלית?
כפי שאמרנו, תאימות לנגישות לא מספיקה כדי לתמוך באנשים עם מוגבלויות. עם זאת, זו נקודת התחלה טובה כי היא מספקת מדד שאפשר לבדוק נגדו. אנחנו ממליצים לבצע פעולות נוספות מלבד בדיקת התאימות לנגישות, כמו ביצוע בדיקות נוחות השימוש לאנשים עם מוגבלויות, העסקת אנשים עם מוגבלויות לעבודה בצוות או התייעצות עם אדם או חברה שיש להם מומחיות בנגישות דיגיטלית כדי לעזור לכם לפתח מוצרים שוויוניים יותר.
יסודות של בדיקות אוטומטיות
בדיקות נגישות אוטומטיות עושות שימוש בתוכנה לסריקת המוצר הדיגיטלי כדי לאתר בעיות נגישות בהתאם לתקני תאימות מוגדרים מראש לנגישות.
היתרונות של בדיקות נגישות אוטומטיות:
- קל לחזור על בדיקות בשלבים שונים של מחזור החיים של המוצר.
- רק כמה שלבים לביצוע והתוצאות מגיעות מהר מאוד.
- כדי להריץ את הבדיקות או להבין את התוצאות נדרש מעט ידע על נגישות.
החסרונות של בדיקות נגישות אוטומטיות:
- כלים אוטומטיים לא מזהים את כל שגיאות הנגישות במוצר
- דיווחים על תוצאות חיוביות כוזבות (מדווח על בעיה שאינה הפרה אמיתית של WCAG)
- יכול להיות שיהיה צורך בכמה כלים לסוגים שונים של מוצרים ולתפקידים שונים
בדיקה אוטומטית היא שלב מצוין לבדוק את הנגישות של האתר או האפליקציה, אבל לא ניתן לבצע אוטומציה של כל הבדיקות. נפרט יותר איך בודקים את הנגישות של רכיבים שלא ניתנים לאוטומטיים במודול בדיקת נגישות ידנית.
סוגי הכלים האוטומטיים
אחד מהכלים הראשונים לבדיקות נגישות אוטומטיות פותח ב-1996 על ידי המרכז לטכנולוגיה שימושית (CAST) בתחום, ונקרא "דוח עופר". היום יש יותר מ-100 כלים לבדיקות אוטומטיות לבחירה.
הטמעת כלים אוטומטיים משתנה בהתאם לכלי, החל מתוספים לדפדפנים לשיפור הנגישות ועד לכלי לניפוי שגיאות בקוד, אפליקציות למחשב ולנייד, לוחות בקרה אונליין ואפילו ממשקי API בקוד פתוח שאפשר להשתמש בהם כדי ליצור כלים אוטומטיים משלכם.
הכלי האוטומטי שתבחרו להשתמש בו תלוי בגורמים רבים, ביניהם:
- אילו רמות ותקינות אתם בודקים? התקן יכול לכלול את WCAG 2.1, WCAG 2.0, סעיף 508 בארה"ב או רשימה מותאמת של כללי נגישות.
- איזה סוג מוצר דיגיטלי אתם בודקים? הפריט יכול להיות אתר, אפליקציית אינטרנט, אפליקציית נייטיב, קובץ PDF, קיוסק או מוצר אחר.
- באיזה שלב במחזור החיים של פיתוח התוכנה אתם בודקים את המוצר?
- כמה זמן נמשך תהליך ההגדרה של הכלי והשימוש בו? לאדם פרטי, לצוות או לחברה?
- מי עורך את הבדיקה: המעצבים, המפתחים, בקרת האיכות או מישהו אחר?
- באיזו תדירות ברצונך לבדוק את הנגישות? אילו פרטים צריך לכלול בדוח? האם צריך לקשר את הבעיות ישירות למערכת ניהול בקשות תמיכה?
- אילו כלים הכי מתאימים לסביבה שלכם? לצוות שלך?
יש עוד הרבה גורמים נוספים שצריך להביא בחשבון. במאמר של WAI בנושא בחירת כלים להערכת נגישות האינטרנט מוסבר איך לבחור את הכלי המתאים לכם ולצוות שלכם.
הדגמה: בדיקה אוטומטית
לצורך ההדגמה האוטומטית של בדיקת הנגישות, נשתמש ב-Lighthouse של Chrome. Lighthouse הוא כלי אוטומטי ברישיון קוד פתוח שנועד לשפר את האיכות של דפי אינטרנט באמצעות סוגים שונים של ביקורות, כמו ביקורות בנושא ביצועים, אופטימיזציה למנועי חיפוש ונגישות.
הדמו שלנו הוא אתר שנוצר לארגון בדיוני, מועדון התעלומות הרפואיות. האתר הזה לא נגיש במכוון לצורך ההדגמה. יכול להיות שחלק מהבעיות האלה יהיו גלויות לכם, וחלק מהן (אבל לא כולן) יתגלו בבדיקות האוטומטיות שלנו.
שלב 1
מתקינים את התוסף Lighthouse באמצעות דפדפן Chrome.
יש הרבה דרכים לשלב את Lighthouse בתהליך הבדיקה. בדגמה הזו נשתמש בתוסף ל-Chrome.
שלב 2
יצרנו דוגמה ב-CodePen.
פותחים אותו במצב ניפוי באגים כדי להמשיך לבדיקות הבאות. הפעולה הזו חשובה כי היא מסירה את <iframe>
שמקיף את דף האינטרנט להדגמה, דבר שעלול להפריע לחלק מכלי הבדיקה.
מידע נוסף על מצב ניפוי הבאגים ב-CodePen
שלב 3
פותחים את כלי הפיתוח ל-Chrome ועוברים לכרטיסייה Lighthouse. מנקים את כל האפשרויות של קטגוריות, מלבד 'נגישות'. משאירים את המצב כברירת המחדל ובוחרים את סוג המכשיר שבו מריצים את הבדיקות.
שלב 4
לוחצים על ניתוח של טעינת הדף וממתינים ש-Lighthouse ירוץ את הבדיקות שלו.
בסיום הבדיקות, מערכת Lighthouse מציגה ציון שמשקף את רמת הנגישות של המוצר שאתם בודקים. הציון של Lighthouse מחושב על סמך מספר הבעיות, סוגי הבעיות וההשפעה של הבעיות שזוהו על המשתמשים.
בנוסף לדירוג, דוח Lighthouse כולל מידע מפורט על הבעיות שזוהו וקישורים למקורות מידע עם מידע נוסף על דרכים לפתרון הבעיות. הדוח כולל גם בדיקות שעברו או לא רלוונטיות, וכן רשימה של פריטים נוספים שצריך לבדוק באופן ידני.
שלב 5
עכשיו נעבור על דוגמה לכל אחת מבעיות הנגישות שהתגלו באופן אוטומטי, ונתקן את הסגנונות והסימון הרלוונטיים.
בעיה 1: תפקידי ARIA
בבעיה הראשונה כתוב: " ברכיבים עם [role] של ARIA שמחייבים ילדים לכלול [תפקיד] ספציפי, חסרים חלק מהצאצאים הנדרשים האלה או בכולם. חלק מתפקידי ההורה של ARIA צריכים לכלול תפקידי צאצא ספציפיים כדי לבצע את פונקציות הנגישות הייעודיות שלהם. מידע נוסף על כללי התפקידים ב-ARIA
בדמו שלנו, הלחצן להרשמה לניוזלטר נכשל:
<button role="list" type="submit" tabindex="1">Subscribe</button>
ללחצן 'הרשמה' שלצד שדה הקלט מוקצה תפקיד ARIA שגוי. במקרה כזה, אפשר יהיה להסיר את התפקיד לגמרי.
<button type="submit" tabindex="1">Subscribe</button>
בעיה 2: ARIA מוסתר
רכיבי "[aria-hidden="true"]
כוללים רכיבי צאצא שאפשר להעביר אליהם את המיקוד. צאצאים שניתן להתמקד בהם ברכיב [aria-hidden="true"]
מונעים מהרכיבים האינטראקטיביים האלה להיות זמינים למשתמשים בטכנולוגיות מסייעות כמו קוראי מסך. מידע נוסף על כללי aria-hidden
<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
הוחל מאפיין aria-hidden="true"
על שדה הקלט. הוספת המאפיין הזה מסתירה את הרכיב (וכל מה שמתחתיו) מטכנולוגיות עזר.
<input type="email" placeholder="Enter your e-mail address" tabindex="-1" required>
במקרה כזה, צריך להסיר את המאפיין הזה מהקלט כדי לאפשר לאנשים שמשתמשים בטכנולוגיה מסייעת לגשת לשדה הטופס ולהזין בו מידע.
בעיה 3: שם הלחצן
ללחצנים אין שמות נגישים. כשאין ללחצן תווית נגישות, קוראי מסך אומרים את המילה 'לחצן', ובמצב כזה אנשים שמסתמכים על קוראי מסך יתקשו להשתמש בלחצן.
מידע נוסף על כללים למתן שמות ללחצנים
<button role="list" type="submit" tabindex="1">Subscribe</button>
כשמסירים את התפקיד הלא מדויק של ARIA מרכיב הלחצן בבעיה 1, המילה 'Subscribe' הופכת לשם הלחצן הנגיש. הפונקציונליות הזו מובנית ברכיב הלחצן הסמנטי ב-HTML. יש אפשרויות נוספות של דפוסים שאפשר להשתמש בהן במצבים מורכבים יותר.
<button type="submit" tabindex="1">Subscribe</button>
בעיה 4: מאפייני alt של תמונות
לרכיבי התמונה חסרים מאפייני [alt]
. רכיבים אינפורמטיביים צריכים לכלול טקסט חלופי קצר ותיאורי. אפשר להתעלם מרכיבי עיצוב עם מאפיין alt ריק. מידע נוסף על הכללים בנוגע לטקסט חלופי של תמונות
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png">
</a>
מאחר שתמונת הלוגו היא גם קישור, מודול התמונות מאפשר לכם לדעת שהיא נקראת תמונה עם פעולה שאפשר לבצע, ושצריך להוסיף לה טקסט חלופי עם מידע על מטרת התמונה. בדרך כלל, התמונה הראשונה בדף היא לוגו, כך שאפשר להניח שהמשתמשים עם AT ידעו זאת, ויכול להיות שתבחרו לא להוסיף את המידע ההקשרי הנוסף הזה לתיאור התמונה.
<a href="index.html">
<img src="https://upload.wikimedia.org/wikipedia/commons/….png"
alt="Go to the home page.">
</a>
בעיה 5: טקסט הקישור
לקישורים אין שמות ייחודיים. כשהטקסט של הקישור מובן וייחודי וניתן למיקוד, משתמשים שנעזרים בקורא מסך נהנים מחוויית ניווט משופרת. המצב הזה נכון גם לגבי טקסט חלופי של תמונות כשנעשה בהן שימוש כקישורים. מידע נוסף על כללים בנוגע לטקסטים של קישורים
<a href="#!"><svg><path>...</path></svg></a>
כל התמונות בדף שאפשר לבצע עליהן פעולה חייבות לכלול מידע על היעד שאליו הקישור מפנה את המשתמשים. אחת מהדרכים לפתרון הבעיה הזו היא להוסיף לתמונה טקסט חלופי לגבי המטרה, כמו שעשיתם בתמונה של הלוגו בדוגמה. השיטה הזו מתאימה במיוחד לתמונה עם תג <img>
, אבל אי אפשר להשתמש בה בתגים מסוג <svg>
.
בסמלי הרשתות החברתיות, שמשתמשים בתגי <svg>
, אפשר להשתמש בדפוס תיאור חלופי אחר שמטרגט קובצי SVG, להוסיף את המידע בין התגים <a>
ו-<svg>
ואז להסתיר אותו באופן חזותי מהמשתמשים, להוסיף ARIA נתמכת או לבחור באפשרויות אחרות. בהתאם לסביבה ולמגבלות הקוד, יכול להיות ששיטה אחת תהיה עדיפה על פני שיטה אחרת.
כדאי להשתמש באפשרות התבנית הפשוטה ביותר עם הכיסוי הטכנולוגי המסייע ביותר, שמוסיף role="img"
לתג <svg>
וכולל את הרכיב <title>
.
<a href="#!">
<svg role="img">
<title>Connect on our Twitter page.</title>
<path>...</path>
</svg>
</a>
בעיה 6: ניגודיות צבעים
יחס הניגודיות של צבעי הרקע והחזית אינו מספיק. למשתמשים רבים קשה או בלתי אפשרי לקרוא טקסט עם ניגודיות נמוכה. למידע נוסף על כללים לניגודיות של צבעים
דווחו על שתי דוגמאות.
זוהו באתר הרבה בעיות בניגודיות צבעים. כמו שלמדתם במודול צבע וניגודיות, לטקסט בגודל רגיל (פחות מ-18pt / 24 פיקסלים) יש דרישה של ניגודיות צבעים של 4.5:1, ואילו טקסט בגודל גדול (לפחות 18pt / 24px או 14pt / 18.5px מודגש) וסמלים חיוניים חייבים לעמוד בדרישה של 3:1.
בכותרת הדף, הטקסט בגוון כחול-ירקרק צריך לעמוד בדרישה של ניגודיות צבעים ביחס של 3:1, כי מדובר בטקסט גדול בגודל 24 פיקסלים. עם זאת, הלחצנים בצבע טורקיז נחשבים לטקסט בגודל רגיל בכתב מודגש של 16px, ולכן הם חייבים לעמוד בדרישת הניגודיות של 4.5:1.
במקרה כזה, נוכל למצוא צבע ירוק-כחול כהה מספיק כדי לעמוד ביחס של 4.5:1, או להגדיל את גודל הטקסט של הלחצן ל-18.5px מודגש ולשנות מעט את ערך הצבע הירוק-כחול. כל אחת מהשיטות משתלבת היטב עם האסתטיקה של העיצוב.
גם כל הטקסט האפור על הרקע הלבן לא עומד בקריטריונים של ניגודיות צבעים, מלבד שתי הכותרות הגדולות ביותר בדף. צריך להכהות את הטקסט הזה כדי לעמוד בדרישות יחס הניגודיות של 4.5:1.
בעיה 7: מבנה הרשימה
יש פריטים ברשימות (<li>
) שלא נמצאים בין רכיבי הורה של <ul>
או <ol>
.
כדי שקוראי מסך יוכלו לקרוא כראוי פריטים ברשימות (<li>
), הם צריכים להופיע בין רכיבי הורה מסוג <ul>
או <ol>
.
מידע נוסף על כללים ליצירת רשימות
<div class="ul">
<li><a href="#">About</a></li>
<li><a href="#">Community</a></li>
<li><a href="#">Donate</a></li>
<li><a href="#">Q&A</a></li>
<li><a href="#">Subscribe</a></li>
</div>
בדמו הזה השתמשנו במחלקת CSS כדי לדמות את הרשימה ללא סדר במקום להשתמש בתג <ul>
. כשכתבנו את הקוד בצורה שגויה, הסרנו את תכונות ה-HTML הסמנטיות שמובנות בתג הזה. כדי לפתור את בעיית הנגישות הזו, מחליפים את הכיתה בתג <ul>
אמיתי ומשנים את קובץ ה-CSS הרלוונטי.
<ul>
<li><a href="#">About</a></li>
<li><a href="#">Community</a></li>
<li><a href="#">Donate</a></li>
<li><a href="#">Q&A</a></li>
<li><a href="#">Subscribe</a></li>
</ul>
בעיה 8: הוספת כרטיסיות
לחלק מהרכיבים יש ערך tabindex
גדול מ-0. ערך גדול מ-0 מציין סדר ניווט מפורש. למרות שטכנית זו חוקית, לרוב החוויות האלה יוצרות חוויות מתסכלות עבור המשתמשים שמסתמכים על טכנולוגיות מסייעות.
מידע נוסף על כללים ליצירת טבלת כרטיסיות
<button type="submit" tabindex="1">Subscribe</button>
אלא אם יש סיבה ספציפית לשינוי סדר הלחצן Tab באופן טבעי בדף אינטרנט, אין צורך להגדיר מספר שלם חיובי במאפיין tabindex. כדי לשמור על סדר הקלדת Tab הטבעי, אפשר לשנות את tabindex ל-0
או להסיר את המאפיין לגמרי.
<button type="submit">Subscribe</button>
שלב 6
אחרי שתתקנו את כל הבעיות האוטומטיות שקשורות לנגישות, פותחים דף חדש במצב ניפוי באגים. מריצים שוב את הביקורת של Lighthouse לגבי נגישות. הציון שלכם צריך להיות הרבה יותר טוב מאשר בריצה הראשונה.
יישמנו את כל העדכונים האוטומטיים האלה בנושא נגישות ב-CodePen חדש.
השלב הבא
עבודה טובה. כבר עשית הרבה דברים, אבל עוד לא סיימנו! בשלב הבא נעבור לבדיקות ידניות, כפי שמפורט במודול בדיקת נגישות ידנית.
בדיקת ההבנה
בדיקת הידע שלכם בנושא בדיקות נגישות אוטומטיות
איזה סוג בדיקה צריך לבצע כדי לוודא שהאתר נגיש?
אילו שגיאות מתגלות בבדיקות האוטומטיות?