בדיקת הנגישות של אפליקציית Angular באמצעות Codelyzer

רוצים להפוך את האתר שלכם ב-Angular לנגיש לכולם? זה המקום הנכון!

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

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

שימוש ב-codelyzer כדי לזהות רכיבים שאינם נגישים

codelyzer הוא כלי שמבוסס על TSLint ובודק אם פרויקטים של Angular TypeScript פועלים בהתאם לקבוצה של כללי איתור שגיאות בקוד. פרויקטים שהוגדרו באמצעות ממשק שורת הפקודה (CLI) של Angular כוללים את codelyzer כברירת מחדל.

ל-Codelyzer יש יותר מ-50 כללים לבדיקה אם אפליקציה ב-Agular פועלת לפי השיטות המומלצות. מתוך הקריטריונים האלה יש כ-10 כללים לאכיפת הקריטריונים לנגישות. במאמר כללי נגישות חדשים ב-Codelyzer מוסבר על בדיקות הנגישות השונות ש-codelyzer מספק ועל הסיבות להן.

נכון לעכשיו, כל כללי הנגישות הם ניסיוניים ומושבתים כברירת מחדל. כדי להפעיל אותם, מוסיפים אותם לקובץ התצורה של TSLint‏ (tslint.json):

{
  "rulesDirectory": [
    "codelyzer"
  ],
  "rules": {
    ...,
    "template-accessibility-alt-text": true,
    "template-accessibility-elements-content": true,
    "template-accessibility-label-for": true,
    "template-accessibility-tabindex-no-positive": true,
    "template-accessibility-table-scope": true,
    "template-accessibility-valid-aria": true,
    "template-click-events-have-key-events": true,
    "template-mouse-events-have-key-events": true,
    "template-no-autofocus": true,
    "template-no-distracting-elements": true
  }
}

אפשר להשתמש ב-TSLint בכל סביבות הפיתוח המשולבות (IDE) ועורכי הטקסט הנפוצים. כדי להשתמש בו ב-VSCode, צריך להתקין את פלאגין TSLint. ב-WebStorm, TSLint מופעל כברירת מחדל. בקובץ ה-README של TSLint מפורטות הוראות לשימוש בכלים אחרים.

כשמגדירים את בדיקות הנגישות של codelyzer, מוצג חלון קופץ עם שגיאות נגישות בקובצי TypeScript או בתבניות בתוך שורות קוד בזמן הכתיבה:

צילום מסך של חלון קופץ של Codelyzer בכלי לעריכת טקסט.
חלון קופץ של Codelyzer שבו מוצגת שגיאה בתיוג של רכיב טופס.

כדי לבצע איתור שגיאות בקוד של הפרויקט כולו (כולל תבניות חיצוניות), משתמשים בפקודה ng lint:

איתור שגיאות בקוד (linting) באמצעות CLI זוויתי

השלמת codelyzer

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

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

אכיפה של בדיקות נגישות באינטגרציה רציפה (CI)

הוספה של בדיקות נגישות סטטיות באינטגרציה הרציפה (CI) יכולה לשפר מאוד את תהליך הפיתוח שלכם. עם Codelyzer אפשר לאכוף בקלות כללי נגישות מסוימים או שיטות אחרות על ידי הרצת ng lint בכל שינוי של קוד (לדוגמה, בכל בקשת משיכה חדשה).

כך, עוד לפני שממשיכים לבדוק את הקוד, מערכת ה-CI יכולה לומר לכם אם יש הפרות של נגישות.

סיכום

כדי לשפר את הנגישות של אפליקציית Angular:

  1. מפעילים את כללי הנגישות הניסיוניים ב-codelyzer.
  2. איך מבצעים בדיקת נגישות בכל הפרויקט באמצעות Angular CLI.
  3. מתקנים את כל בעיות הנגישות שדווחו על ידי codelyzer.
  4. כדאי להשתמש ב-Lighthouse כדי לבדוק נגישות בזמן הריצה.