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

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

Minko Gechev

Zama Khan Mohammed

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

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

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

codelyzer הוא כלי שנמצא מעל TSLint ובודק אם פרויקטים של Angular TypeScript פועלים לפי קבוצה של כללים לאיתור שגיאות בקוד. כברירת מחדל, פרויקטים שהוגדרו באמצעות ממשק שורת הפקודה של Angular (CLI) כוללים 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 או בתבניות מוטבעות במהלך הקוד:

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

תוספת ל-Codelyzer

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

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

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

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

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

סיכום

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

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