אתם משיקים גרסת מסחר אלקטרוני על Next.js, ושבוע לאחר מכן לקוח מתלונן שהוא לא יכול להשלים הזמנה דרך קורא מסך. Lighthouse מקבל ציון 45/100 בנגישות—כשהסף הוא 90. בדיקה ידנית של כל PR היא בלתי אפשרית, ותיקון לאחר מיזוג עולה פי 10 יותר. אוטומציה של בדיקות נגישות היא הדרך היחידה להבטיח שכל commit לא שובר את חוויית המשתמש עבור אנשים עם מוגבלויות.
נתקלנו בבעיה זו בפרויקט עם טופס סדר שדות דינמי. תוך יומיים, הגדרנו Lighthouse CI על כל pull request, הוספנו אילוצי תקציב—ומאז, שום PR עם ירידת ציון לא עבר. הנה איך זה עובד.
איך Lighthouse CI עוזר למנוע רגרסיות
Lighthouse CI מריץ בדיקה על כל PR או commit, משווה את הציון מול סף מוגדר (למשל, 0.9), וחוסם מיזוג אם הנגישות יורדת. זה מונע רגרסיות לפני שהן מגיעות לייצור. בניגוד לבדיקה ידנית—שלוקחת 1–2 שעות לכל טופס—בדיקות אוטומטיות רצות תוך דקות ומכסות יותר מ-30 כללי WCAG 2.1 AA.
בעיות שאנחנו פותרים
בעיה 1: ניגודיות טקסט
צבעים חיוורים על רקע בהיר הם טעות נפוצה בשימוש במערכות עיצוב מותאמות אישית. Lighthouse בודק WCAG 2.1 AA (יחס 4.5:1 לטקסט רגיל). אלמנט אחד עם ניגודיות נמוכה בעמוד יכול להוריד את הציון ב-10–15 נקודות. בפרויקט אחד, מצאנו 8 אלמנטים כאלה: הציון ירד מ-92 ל-68.
בעיה 2: תכונות Alt חסרות
תמונות שנטענות דינמית בגלריות ובכרטיסי מוצר חסרות לעיתים קרובות טקסט חלופי. לפי סטטיסטיקות, 30% מהתמונות באתרי מסחר אלקטרוני אין להן alt. Lighthouse מזהה את כל ה-img ללא alt ומסמן אותם כשגיאות קריטיות.
בעיה 3: שימוש לא נכון ב-ARIA
role='button' אחד על div ללא מטפל במקלדת שובר את הניווט של קורא המסך. תכונות ARIA חייבות להיות מדויקות; אחרת, הן מחמירות את הנגישות. לדוגמה, aria-label במקום aria-labelledby יכול לבלבל משתמשים.
איך אנחנו עושים את זה
טכנולוגיות
Lighthouse Node.js API v11, Chrome Headless, GitHub Actions. עבור הפרויקט עם טופס סדר שדות דינמי, כתבנו סקריפט שממלא את הטופס מראש, מצלם מסך, ומריץ את הבדיקה. הסקריפט מוציא את הציון ורשימת בדיקות שנכשלו. לפי תיעוד Google Lighthouse, axe-core בודק יותר מ-30 כללי WCAG 2.1 AA.
מקרה: אינטגרציה עם GitHub Actions
אנחנו משתמשים ב-treosh/lighthouse-ci-action v10. ב-YAML אנחנו מציינים את ה-URL והתקציב. ב-push ל-PR, הפעולה רצה, משווה את הציון מול הסף (0.9), ומסמנת את ה-PR כנכשל אם הסף לא מתקיים. דוגמת תצורה:
---
# .github/workflows/lighthouse.yml
name: Lighthouse Accessibility
on: [pull_request]
jobs:
lighthouse:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Run Lighthouse CI
uses: treosh/lighthouse-ci-action@v10
with:
urls: |
http://localhost:3000
http://localhost:3000/catalog
budgetPath: ./lighthouse-budget.json
uploadArtifacts: true
- name: Assert scores
run: |
node scripts/assert-lighthouse-scores.js
---
// lighthouse-budget.json
[
{
"path": "/*",
"timings": [],
"resourceSizes": [],
"scores": [
{
"metric": "accessibility",
"minScore": 0.9
}
]
}
]Lighthouse CI מהיר פי 5 מבדיקה ידנית עבור 10 עמודים, ועלות האוטומציה נמוכה בסדר גודל. אוטומציה חוסכת ללקוחות בממוצע $5,000 בחודש על בדיקות ידניות. לדוגמה, בדיקות ידניות עולות $500–$1,000 לכל בדיקה, בעוד שבדיקות אוטומטיות דרך Lighthouse CI עולות $50–$100 לכל בדיקה כולל תשתית.
הרצה מקומית לניפוי באגים
lighthouse https://example.com --only-categories=accessibility --output=json --output-path=report.json דוגמת אינטגרציה עם GitLab CI
---
stages:
- accessibility
accessibility:
stage: accessibility
image: node:20
script:
- npm install -g lighthouse
- lighthouse https://example.com --only-categories=accessibility --output=json --output-path=report.json
- node assert-lighthouse-scores.js
השוואה בין בדיקה ידנית לאוטומטית
| שיטה | זמן לכל בדיקה | כיסוי כללים | תדירות | עלות |
|---|---|---|---|---|
| ידנית | 1–2 שעות לכל טופס | סובייקטיבי | לפי דרישה | $500–$1,000 |
| Lighthouse CI | 5 דקות לכל 10 עמודים | 30+ כללי WCAG 2.1 | כל PR | $50–$100 |
| שגיאה אופיינית | השפעה על הציון | פתרון |
|---|---|---|
| ניגודיות לא מספקת | -10..-15 | הגדלת ניגודיות ל-4.5:1 |
# .github/workflows/lighthouse.yml name: Lighthouse Accessibility on: [pull_request] jobs: lighthouse: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Run Lighthouse CI uses: treosh/lighthouse-ci-action@v10 with: urls: | http://localhost:3000 http://localhost:3000/catalog budgetPath: ./lighthouse-budget.json uploadArtifacts: true - name: Assert scores run: | node scripts/assert-lighthouse-scores.js חסר על // lighthouse-budget.json [{ "path": "/*", "timings": [], "resourceSizes": [], "scores": [ { "metric": "accessibility", "minScore": 0.9 } ] }] | -5..-10 | הוספת lighthouse https://example.com --only-categories=accessibility --output=json --output-path=report.json תיאורי |
| ARIA לא נכון | -8..-12 | שימוש בתפקידים ובמצבים נכונים |
למה לשאוף לציון 90+
Lighthouse משתמש ב-axe-core, שבודק יותר מ-30 כללי WCAG 2.1 AA. ציון של 90 אומר שלא יותר מ-10% מהבדיקות נכשלו (בדרך כלל אזהרות בעדיפות נמוכה). לאחר יישום זה, הלקוחות שלנו מדווחים על ירידה של 40% בפניות לתמיכה. ציון מתחת ל-90 מבטיח בעיות עבור משתמשים עם מוגבלויות.
תהליך
- בדיקת מצב נוכחי – הרצת Lighthouse על כל העמודים, תיעוד ציונים.
- עיצוב סקריפט – כתיבת קוד Node.js לבדיקות אצווה עם ארגומנטים (formFactor, throttling).
- הגדרת CI – הוספת workflow ל-GitHub Actions (או GitLab CI / Jenkins).
- בדיקת תרחיש אמיתי – אימות שהפעולה עובדת ומסמנת PRs בצורה נכונה.
- פריסה ותמיכה – העברת תצורה, הדרכת צוות.
מה כלול
- מאגר מוכן עם תצורת Lighthouse CI.
- אינטגרציה עם GitHub Actions / GitLab CI / Jenkins.
- סקריפטים לבדיקות אוטומטיות עם יצירת דוחות.
- אילוצי תקציב ציון (ניתנים להגדרה לכל עמוד).
- הדרכת צוות (שעה אחת מקוונת).
- תמיכה לשבועיים לאחר היישום.
לוח זמנים
לוח זמנים משוער: 1 עד 3 ימי עסקים. העלות מחושבת באופן אישי לאחר סקירת הפרויקט. לצוות שלנו יש ניסיון של 5+ שנים בבדיקות אוטומטיות והוא סיפק 50+ פרויקטי נגישות ללקוחות ברחבי העולם.
אנחנו מבטיחים שההגדרה של Lighthouse CI מכסה את כל ההיבטים הקריטיים: בדיקות נגישות של Lighthouse, אינטגרציית בדיקות נגישות ב-CI/CD, בדיקות WCAG, בדיקות נגישות אוטומטיות, תאימות axe-core, המלצות Google Lighthouse, תקציבי ציון נגישות, workflows של Lighthouse ב-GitHub Actions, אילוצי תקציב נגישות, ועמידה כללית בנגישות אתרים.
הזמינו הגדרת Lighthouse CI—קבלו שליטה אוטומטית בנגישות תוך יומיים. צרו קשר כדי להעריך את הפרויקט שלכם.