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

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

Minko Gechev

Zama Khan Mohammed

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

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

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

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

Codelyzer כולל יותר מ-50 כללים לבדיקה אם אפליקציה ב-Angular פועלת לפי השיטות המומלצות. מתוכם יש כ-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:

הוספת מקודד

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

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

אכיפה של בדיקות נגישות בשילוב הרציף

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

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

סיכום

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

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