עד כה בקורס הזה למדתם על ההיבטים האישיים, העסקיים והמשפטיים של נגישות דיגיטלית, ועל העקרונות הבסיסיים של תאימות דיגיטלית לנגישות. למדתם נושאים ספציפיים שקשורים לעיצוב ולקידוד כוללני, כולל מתי יש להשתמש ב-ARIA לעומת HTML, איך למדוד ניגודיות של צבעים, כששימוש ב-JavaScript חיוני ועוד נושאים אחרים.
במודולים שנותרו, אנחנו עוברים מתכנון ובנייה לבדיקת נגישות. נשתמש בתהליך בדיקה בשלושה שלבים שכולל כלים וטכניקות אוטומטיים, ידניים וטכנולוגיות מסייעות. נשתמש באותה הדגמה בכל המודולים של הבדיקה כדי להתקדם בדף האינטרנט ממצב לא נגיש לנגיש.
כל בדיקה – אוטומטית, ידנית וטכנולוגיה מסייעת – חיונית להשגת המוצר הנגיש ביותר.
הבדיקות שלנו מסתמכות על הסטנדרטים שלנו לנגישות תוכן באינטרנט (WCAG) 2.1 רמת תאימות A ו-AA. חשוב לזכור שההנחיות הבאות נקבעות לפי ההנחיות שיש לציית להן ולפי סוג המוצר, לפי החוקים, כללי המדיניות והחוקים המקומיים או יעדי הנגישות הכוללים. אם אתם לא דורשים תקן ספציפי לפרויקט, מומלץ להשתמש בגרסה האחרונה של WCAG. קראו את המאמר איך נמדדת נגישות דיגיטלית?" למידע כללי על ביקורות נגישות, רמות וסוגים של תאימות, WCAG ו-POUR.
כפי שאתם יודעים, תאימות לנגישות היא לא הסיפור המלא כשמדובר בתמיכה באנשים עם מוגבלויות. עם זאת, זוהי נקודת התחלה טובה, מאחר שהיא מספקת ערך שתוכל לבחון באמצעותו. מומלץ לבצע פעולות נוספות מעבר לבדיקת תאימות לנגישות, כמו הרצת בדיקות של נוחות השימוש לאנשים עם מוגבלויות, העסקת אנשים עם מוגבלויות לעבוד בצוות או ייעוץ לאדם או לחברה שיש להם מומחיות בנגישות בדיגיטל, כדי לעזור לכם ליצור מוצרים שמתאימים לכולם.
מידע בסיסי על בדיקות אוטומטיות
בבדיקות הנגישות האוטומטיות נעשה שימוש בתוכנה לסריקת המוצר הדיגיטלי כדי לאתר בעיות נגישות בהתאם לתקני תאימות מוגדרים מראש לנגישות.
היתרונות של בדיקות נגישות אוטומטיות:
- קל לחזור על בדיקות בשלבים שונים של מחזור החיים של המוצר
- רק עוד כמה שלבים להרצה ותוצאות מהירות מאוד
- נדרש ידע מועט בנגישות כדי להריץ את הבדיקות או להבין את התוצאות
חסרונות של בדיקות נגישות אוטומטיות:
- הכלים האוטומטיים לא מזהים את כל שגיאות הנגישות במוצר
- תוצאות חיוביות כוזבות שדווחו (דיווח על בעיה שאינה הפרה אמיתית של WCAG)
- יכול להיות שיהיה צורך בכמה כלים לסוגים שונים של מוצרים ולתפקידים שונים
בדיקות אוטומטיות הן התחלה מצוינת לבדיקת הנגישות של האתר או האפליקציה, אבל לא כל הבדיקות יכולות להיות אוטומטיות. במאמר זה נסביר בפירוט איך בודקים את הנגישות של רכיבים שאי אפשר להגדיר באופן אוטומטי במודול בדיקת הנגישות הידנית.
סוגי כלים אוטומטיים
אחד מהכלים האוטומטיים הראשונים לבדיקת נגישות באינטרנט פותח ב-1996 על ידי המרכז לטכנולוגיה מיוחדת (CAST), שנקרא "The Bobby Report". כיום יש יותר מ-100 כלי בדיקה אוטומטיים לבחירה!
הטמעת הכלים האוטומטית משתנה מתוספים לדפדפני נגישות ועד לתוכנות קוד, לאפליקציות למחשב ולנייד, מרכזי בקרה אונליין ואפילו ממשקי API בקוד פתוח שאפשר להשתמש בהם כדי ליצור כלים אוטומטיים משלכם.
ההחלטה איזה כלי אוטומטי להשתמש תלויה בגורמים רבים, כולל:
- אילו סטנדרטים ורמות של תאימות אתם בוחנים? למשל, WCAG 2.1, WCAG 2.0, U.S. סעיף 508 או רשימה שעברה שינוי של כללי הנגישות.
- איזה סוג של מוצר דיגיטלי ברצונך לבדוק? האתר יכול להיות אתר, אפליקציית אינטרנט, אפליקציה המקורית לנייד, PDF, קיוסק או מוצר אחר.
- באיזה חלק במחזור החיים של פיתוח התוכנה אתם בודקים את המוצר?
- כמה זמן נמשך תהליך ההגדרה של הכלי והשימוש בו? לאדם, צוות או חברה?
- מי עורך את הבדיקה: המעצבים, המפתחים, בקרת האיכות וכו'?
- באיזו תדירות ברצונך לבדוק את הנגישות? אילו פרטים צריך לכלול בדוח? האם הבעיות צריכות להיות מקושרות ישירות למערכת הכרטיסים?
- אילו כלים הכי מתאימים לסביבה שלכם? בצוות שלך?
כמו כן, יש להביא בחשבון גורמים רבים נוספים. במאמר של WAI בנושא Selecting Web Accessibility Evaluation Tools תוכלו למצוא מידע נוסף שיעזור לכם לבחור את הכלי המתאים ביותר לכם ולצוות שלכם.
הדגמה: בדיקה אוטומטית
בהדגמה של בדיקת הנגישות האוטומטית נשתמש ב-Lighthouse של Chrome. Lighthouse הוא כלי אוטומטי בקוד פתוח שנוצר כדי לשפר את האיכות של דפי אינטרנט באמצעות סוגים שונים של ביקורות, כמו ביצועים, אופטימיזציה למנועי חיפוש ונגישות.
ההדגמה שלנו היא אתר שנבנה עבור ארגון מומצא, Medical Mysteries Club. האתר הזה הופך לבלתי נגיש באופן מכוון לצורך ההדגמה. יכול להיות שתוכלו לראות חלק מהגדרות הנגישות האלה, וחלק מהן (אבל לא את כולן) ייבדקו באופן אוטומטי.
שלב 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 ריק. מידע נוסף על כללים
לטקסט חלופי לתמונות
<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: ניגודיות צבעים
יחס הניגודיות של צבעי הרקע והחזית לא מספיק. למשתמשים רבים קשה או בלתי אפשרי לקרוא טקסט עם ניגודיות נמוכה. למידע נוסף על כללי ניגודיות של צבעים
דווחו שתי דוגמאות.
Medical Mysteries Club , יש ערך הקסדצימלי של צבע הוא #01aa9d וערך הקסדצימאלי של הרקע הוא #ffffff. יחס הניגודיות של הצבעים הוא 2.9:1.
הצגת צילום מסך בגודל מלא.
Mermaid syndrome יש ערך הקסדצימלי בטקסט של #7c7c7c, וצבע הרקע ההקסדצימלי הוא #ffffff. יחס הניגודיות של הצבעים הוא 4.2:1.
הצגת צילום מסך בגודל מלא.
כדאי לתקן את זה.
זוהו בעיות רבות של ניגודיות צבעים בדף האינטרנט. כפי שלמדתם במודול color and ניגודיות, טקסט בגודל רגיל (פחות מ-24 פיקסלים) צריך להיות 4.5:1, ואילו טקסט בגודל גדול (לפחות 18 נקודות / 24 פיקסלים או 18.5 פיקסלים מודגש) וסמלים חיוניים חייבים לעמוד בדרישה של 3:1.
בכותרת הדף, הטקסט בצבע כחול-ירקרק צריך לעמוד בדרישות הניגודיות של 3:1, מכיוון שזהו טקסט גדול בגודל 24 פיקסלים. עם זאת, הלחצנים בצבע כחול-ירקרק נחשבים לטקסט בגודל רגיל עם 16 פיקסלים מודגשים, ולכן הם חייבים לעמוד בדרישה של ניגודיות צבעים של 4.5:1.
במקרה הזה, מצאנו צבע כחול-ירקרק שהיה כהה מספיק כדי להתאים ליחס של 4.5:1, או שאפשר להגדיל את טקסט הלחצן ל-18.5 פיקסלים ולשנות מעט את הערך של הצבע הכחול. כל אחת מהשיטות מתאימה לאסתטיקה של העיצוב.
גם כל הטקסט האפור על הרקע הלבן נכשל בניגודיות של צבעים, מלבד שתי הכותרות הגדולות ביותר בדף. צריך להכהות את הטקסט כדי שיעמוד בדרישות של יחס ניגודיות צבעים של 4.5:1.
Medical Mysteries Club , קיבל ערך צבע של #008576 והרקע נשאר #ffffff. יחס הניגודיות המעודכן של הצבעים הוא 4.5:1.
הצגת צילום מסך בגודל מלא.
Mermaid syndrome יש עכשיו ערך צבע של #767676 והרקע נשאר #ffffff. יחס הניגודיות של הצבעים הוא 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 חדש.
השלב הבא
עבודה טובה. כבר הגעת להישגים רבים, אבל עדיין לא סיימנו! לאחר מכן נעבור לבדיקות ידניות, שמפורטות במודול בדיקת נגישות ידנית.
בדיקת ההבנה
בחינת הידע שלכם לגבי בדיקות נגישות אוטומטיות
אילו בדיקות צריך לבצע כדי לוודא שהאתר נגיש?
אילו שגיאות מתגלות בבדיקות אוטומטיות?