בדיקות נגישות אוטומטיות

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

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

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

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

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

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

יסודות הבדיקות האוטומטיות

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

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

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

חסרונות של בדיקות נגישות אוטומטיות:

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

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

סוגים של כלים אוטומטיים

אחד הכלים הראשונים לבדיקת נגישות באינטרנט פותח בשנת 1996 על ידי Center for Applied Special Technology (CAST) (המרכז לטכנולוגיה מיוחדת יישומית), ונקרא The Bobby Report (דוח בובי). כיום יש יותר מ-100 כלים אוטומטיים לבדיקה שאפשר לבחור מתוכם.

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

הכלי האוטומטי שתבחרו להשתמש בו תלוי בהרבה גורמים, כולל:

• אילו תקנים ורמות תאימות אתם בודקים? יכול להיות שהם כוללים את WCAG 2.2,‏ WCAG 2.1,‏ U.S. Section 508 או רשימה שונה של כללי נגישות.
• איזה סוג של מוצר דיגיטלי אתה בודק? לדוגמה, אתר, אפליקציית אינטרנט, אפליקציה מקורית לנייד, קובץ PDF, קיוסק או מוצר אחר.
• באיזה שלב במחזור החיים של פיתוח התוכנה אתם בודקים את המוצר?
• כמה זמן נמשך תהליך ההגדרה והשימוש בכלי? לאדם פרטי, לצוות או לחברה?
• מי עורך את הבדיקה: מעצבים, מפתחים, בודקי QA או מישהו אחר?
• באיזו תדירות רוצים לבדוק את הנגישות? אילו פרטים צריך לכלול בדוח? האם הבעיות צריכות להיות מקושרות ישירות למערכת כרטוס?
• אילו כלים מתאימים לסביבה שלכם? לצוות שלך?

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

הדגמה: בדיקה אוטומטית

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

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

שלב 1

בדפדפן Chrome, מתקינים את התוסף Lighthouse.

יש הרבה דרכים לשלב את Lighthouse בתהליך העבודה של הבדיקות. אנחנו משתמשים בתוסף ל-Chrome בהדגמה הזו.

שלב 2

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

מידע נוסף על מצב ניפוי הבאגים של CodePen

שלב 3

פותחים את כלי הפיתוח ל-Chrome ועוברים לכרטיסייה Lighthouse. מבטלים את הבחירה בכל האפשרויות בקטגוריה מלבד 'נגישות'. משאירים את המצב כברירת מחדל ובוחרים את סוג המכשיר שבו מריצים את הבדיקות.

שלב 4

לוחצים על Analyze page load (ניתוח של טעינת הדף) וממתינים עד ש-Lighthouse יסיים להריץ את הבדיקות.

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

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

שלב 5

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

בעיה 1: תפקידי ARIA

בבעיה הראשונה מצוין: "ברכיבים עם [role] של ARIA שדורשים מצאצאים לכלול [role] ספציפי, חסרים חלק מהצאצאים הנדרשים האלה, או שכולם חסרים בהם. תפקידי הורה מסוימים של ARIA צריכים לכלול תפקידי צאצא ספציפיים כדי לבצע את פונקציות הנגישות שלהם." מידע נוסף על כללים של תפקידים ב-ARIA

בדמו שלנו, הלחצן להרשמה לניוזלטר נכשל:

<button role="list" type="submit" tabindex="1">Subscribe</button>

רוצה לפתור את זה יחד?

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

<button type="submit" tabindex="1">Subscribe</button>

בעיה 2: ARIA hidden

רכיבי "[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>

רוצה לפתור את זה יחד?

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

<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: ניגודיות צבעים

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

דווחו שתי דוגמאות.

רוצה לפתור את זה יחד?

זוהו הרבה בעיות בניגודיות הצבעים בדף האינטרנט. כפי שלמדתם במודול צבע וניגודיות, יחס הניגודיות של צבעים בטקסט בגודל רגיל (פחות מ-18 נקודות או 24 פיקסלים) צריך להיות 4.5:1, ואילו יחס הניגודיות של צבעים בטקסט בגודל גדול (לפחות 18 נקודות או 24 פיקסלים, או 14 נקודות או 18.5 פיקסלים בטקסט מודגש) ובסמלים חיוניים צריך להיות 3:1.

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

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

<button type="submit" tabindex="1">Subscribe</button>

רוצה לפתור את זה יחד?

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

<button type="submit">Subscribe</button>

שלב 6

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

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

השלב הבא

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