בדיקות נגישות אוטומטיות וידניות במחזור חיי הפיתוח (CI/CD)

נגישות שנבדקת רק פעם בשנה, בסקירה ידנית חד-פעמית, כמעט תמיד נשחקת מהר — כל עדכון קוד קטן יכול לשבור משהו שכבר תוקן. הפתרון: להטמיע בדיקות נגישות כחלק אוטומטי מתהליך הפיתוח עצמו (CI/CD), כך שבעיות נתפסות לפני שהן מגיעות לייצור. הכתבה הזו מסבירה איך.

למה בדיקה חד-פעמית לא מספיקה

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

מה כלים אוטומטיים בצנרת ה-CI/CD יכולים לתפוס

כלים כמו axe-core, Pa11y או Lighthouse CI אפשר להריץ אוטומטית בכל Pull Request או לפני כל דיפלוי — הם בודקים תוך שניות דברים כמו: ניגודיות צבעים, תגיות ARIA שגויות או כפולות, טקסט חלופי חסר, תוויות טופס חסרות, וסדר כותרות שגוי. אם הבדיקה נכשלת, ה-Pull Request נחסם אוטומטית מלהתמזג — בדיוק כמו בדיקת קוד רגילה או בדיקת יחידה (Unit Test) שנכשלת.

איפה עדיין נדרשת בדיקה ידנית

בדיוק כמו בבדיקת מסמכים, כלים אוטומטיים בצנרת ה-CI/CD תופסים בעיות מבניות ברורות, אבל לא יכולים לשפוט חוויית שימוש בפועל: האם ניווט מקלדת הגיוני, האם קורא מסך "מספר סיפור" הגיוני על הדף, האם רכיב מותאם אישית (כמו קרוסלה או מודאל) באמת נגיש בשימוש אמיתי. לכן מומלץ לשלב גם ביקורת ידנית תקופתית — למשל רבעונית — לצד הבדיקות האוטומטיות השוטפות.

איך מטמיעים בפועל

1. בחרו כלי בדיקה שמתאים לסטאק הטכנולוגי שלכם (axe-core לרוב פרויקטי JavaScript, Lighthouse CI לפרויקטים מבוססי דפדפן).
2. הריצו אותו כשלב בצנרת ה-CI — לרוב כ-GitHub Action, GitLab CI Job, או שלב מקביל בכלי ה-CI/CD שלכם.
3. הגדירו סף כישלון ברור (למשל: אין בעיות ברמת "קריטי" לפי axe-core) לפני שהבדיקה הופכת לחוסמת.
4. שלבו את קובצי ה-PDF וגם: אם הארגון מפיק מסמכים אוטומטית (חשבוניות, דוחות), שקלו הטמעת סריקה אוטומטית גם עליהם כחלק מתהליך הפרסום.