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

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

השלב הבא

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