איך אוטומציה של VPATs נגישות ב-CI איך אוטומציה של VPATs נגישות ב-CI

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

פתרנו את זה. הפכנו את דוחות הנגישות שלנו לתוצר בנייה (build artifact) רציף.

ה-pipeline שלנו משתמש בשלוש שכבות כדי למצוא שגיאות:

  • בדיקות סטטיות: אנחנו משתמשים ב-axe-core לבדיקות בסיס ב-Storybook.
  • בדיקות אינטראקטיביות: אנחנו משתמשים ב-helpers מותאמים אישית של Vitest כדי לבדוק כללי מקלדת.
  • ביקורות ידניות: אנחנו שומרים תוצאות של קוראי מסך כקבצי JSON.

תהליך ה-CI שלנו ממזג את התוצאות הללו.

אם בדיקה נכשלת, ה-PR נכשל. אם כל הבדיקות עוברות, המערכת מייצרת PDF חדש. ה-PDF הזה נשלח יחד עם הגרסה (release) שלכם.

ניסינו דבר אחד שנכשל.

ניסינו להשתמש ב-LLM כדי להחליף ביקורות ידניות. הפסקנו להשתמש בזה מיד. תוצאות AI משתנות יותר מדי. צריך תוצאות יציבות עבור CI gate.

קראו את הפירוט הטכני המלא כאן:

מקור: https://dev.to/yassine_lakhdar_d0226709a/how-we-automated-our-accessibility-vpats-in-ci-46jk

ARTICLE: צוות פיתוח אוטומט את יצירת ה-VPATs (Voluntary Product Accessibility Templates) של נגישות ישירות בתוך תהליך ה-CI (continuous-integration) שלו, והפך את מה שהיה בעבר דוח ידני תקופתי לתוצר בנייה (build artifact) המצורף לכל גרסה. תהליך העבודה החדש חוסם Pull Requests שמכניסים רגרסיות בנגישות ומפיק באופן אוטומטי מסמך תאימות בפורמט PDF כאשר הבנייה מצליחה, מה שמבטיח שכל שינוי בקוד יישאר במסגרת תקני הנגישות.

Why automation matters

ביקורות נגישות הופכות למיושנות ברגע שקוד חדש נכנס למערכת. מיזוג בודד יכול להכניס טקסט אלטרנטיבי (alt text) חסר, סדר פוקוס לא תקין או בעיות בקורא מסך שפוסלות VPAT שהונפק בעבר. שמירה על תאימות באופן ידני פירושה הרצת ביקורות מחדש לאחר כל שינוי, תהליך יקר וחשוף לטעויות שלעיתים קרובות מפגר אחרי קצב הפיתוח. על ידי הטמעת בדיקות ב-CI, צוותים מקבלים משוב מיידי, שומרים על תאימות עדכנית ומונעים סיכונים משפטיים ותדמיתיים של שחרור תוכנה שאינה נגישה.

The three-layer testing approach

  1. Static checks – ה-pipeline מריץ את axe-core, ספריית קוד פתוח שסורקת רכיבים המרונדרים ב-Storybook עבור הפרות ידועות כמו חוסר ב-landmarks או ניגודיות צבע לא מספקת. בדיקות אלו תופסות בעיות לפני שמתרחשת כל אינטראקציה.

  2. Interactive checks – Vitest helpers מותאמים אישית בודקים את כללי הניווט במקלדת, ומוודאים שהפוקוס נע בצורה לוגית ושהאלמנטים האינטראקטיביים מגיבים לאירועי מקלדת סטנדרטיים. שכבה זו חורגת מניתוח סטטי כדי להבטיח שימושיות בעולם האמיתי.

  3. Manual audit artifacts – תוצאות של בדיקות קורא מסך נשמרות כקבצי JSON. מפתחים מתעדים תצפיות במהלך בדיקות חקרניות (exploratory testing) ומבצעים commit לקובץ ה-JSON לצד הקוד. משימת ה-CI ממזגת את התוצרים הללו עם התוצאות האוטומטיות, ומפיקה מקור אמת יחיד עבור ה-VPAT.

כאשר בדיקה כלשהי בשתי השכבות הראשונות נכשלת, ה-pull request נחסם, מה שמונע מהשינוי להגיע לסביבת הייצור (production). אם כל הבדיקות עוברות, ה-pipeline מרכיב את הנתונים המשולבים לתוך PDF המצורף לגרסה, ובכך מספק VPAT מעודכן ללא מאמץ נוסף.

What didn’t work

הצוות התנסה בשימוש במודל שפה גדול (LLM) כדי לייצר את חלק הביקורת הידנית באופן אוטומטי. התוצאות שנוצרו על ידי ה-AI השתנו יותר מדי, מה שהפך את ה-CI gate לבלתי אמין. עקביות היא חיונית עבור בדיקת pass/fail בינארית, ולכן הניסוי ננטש לטובת תוצרי הביקורת הידנית מבוססי ה-JSON.

What to watch next

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