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

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

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

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

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

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

עקרונות בסיסיים של בדיקות אוטומטיות

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

שלב 1

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

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

שלב 2

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

שלב 3

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

שלב 4

לוחצים על 'ניתוח של טעינת דף' ולתת ל-Lighthouse זמן להריץ את הבדיקות.

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

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

שלב 5

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

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

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

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

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

בואי נפתור את זה.

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

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

בואו נפתור את זה.

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

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

שלב 6

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

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

השלב הבא

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

בדיקת ההבנה

בחינת הידע שלכם לגבי בדיקות נגישות אוטומטיות