בדיקת נגישות אתר משלבת שני סוגי בדיקה: כלים אוטומטיים, שסורקים את הקוד ומוצאים בעיות שאפשר לזהות במכונה — טקסט חלופי חסר, ניגודיות נמוכה, שדות בלי תוויות — ובדיקה ידנית, שבה בודק עובר על האתר במקלדת, בקורא מסך ובהגדלה, ושופט דברים שמכונה לא יכולה לשפוט. כלי אוטומטי לבד לא מספיק: הוא יכול להגיד שלתמונה יש טקסט חלופי, אבל לא אם הטקסט נכון. הנה התהליך המלא, בסדר שבו כדאי לעשות אותו.
למה ציון 100 לא אומר שהאתר נגיש
הכלי הנפוץ ביותר הוא כנראה בדיקת הנגישות של Lighthouse בדפדפן כרום. לפי התיעוד של Chrome, הציון הוא ממוצע משוקלל של בדיקות אוטומטיות, כשכל בדיקה עוברת או נכשלת, והמשקלות מבוססים על הערכות ההשפעה של axe. אותו תיעוד מציין שיש בדיקות ידניות — והן לא משפיעות על הציון. כלומר: 100 ב-Lighthouse אומר שהבדיקות האוטומטיות עברו. לא יותר.
W3C אומר את זה במפורש בעמוד Easy Checks: כלי אוטומטי יכול לזהות טקסט חלופי חסר, אבל כדי לדעת אם הוא מתאים צריך לראות את התמונה ולשפוט בהקשר. ועמוד יכול להיראות כאילו עבר את הבדיקות המהירות — ועדיין להכיל חסמים משמעותיים.
שלב 1: סריקה אוטומטית
| כלי | איפה | למה הוא טוב |
|---|---|---|
| Lighthouse | מובנה בכלי המפתחים של כרום | בדיקה מהירה של עמוד, יחד עם ביצועים |
| axe DevTools | תוסף דפדפן | מנוע הבדיקה הנפוץ, הסבר מפורט לכל ממצא |
| WAVE | תוסף דפדפן ואתר של WebAIM | מציג את הממצאים על העמוד עצמו, טוב להבנת מבנה |
| בודק ניגודיות | מובנה בכלי המפתחים / כלים חיצוניים | בדיקת צבעים ספציפיים מול יחסי הניגודיות של WCAG |
כמה כללים: בודקים תבנית, לא רק דף הבית — עמוד אחד מכל סוג (דף בית, עמוד שירות, מאמר, מוצר, טופס, תוצאות חיפוש). בודקים גם מצבים: תפריט מובייל פתוח, חלון קופץ, טופס עם שגיאות. ומה שמוצאים בתבנית, מתקנים פעם אחת לכל האתר.
לפי WebAIM Million 2026, בדיקה אוטומטית מצאה שגיאות ב-95.9% מעמודי הבית, עם 56.1 שגיאות בממוצע — וזה רק מה שמכונה מסוגלת לזהות.
שלב 2: מקלדת
מניחים את העכבר בצד ועוברים על העמוד עם Tab, Shift+Tab, Enter, רווח ו-Esc. בודקים שאפשר להגיע לכל דבר, שתמיד רואים איפה הפוקוס, שהסדר הגיוני, ושאין מקום שנתקעים בו. המדריך המלא: ניווט במקלדת.
שלב 3: קורא מסך
NVDA בווינדוס (חינמי), VoiceOver במק ובאייפון, TalkBack באנדרואיד. בודקים את מבנה הכותרות, את רשימת הקישורים, שמות של כפתורי אייקון, טפסים והודעות. איך מתחילים: קורא מסך: איך עיוורים גולשים ואיך בודקים.
שלב 4: תצוגה
- הגדלה ל-200% — שום טקסט לא נחתך, לא חופף, ולא דורש גלילה לרוחב בטקסט רגיל.
- ניגודיות — כולל טקסט על תמונות, כפתורים במצבי ריחוף ופוקוס, וטקסט אפור "עדין". ראו פלטת צבעים לאתר.
- צבע לבד — אם מידע מועבר רק בצבע (שגיאה באדום, סטטוס בירוק), צריך גם טקסט או סמל.
- תנועה — אנימציות וקרוסלות שאפשר לעצור, ושום דבר לא מהבהב יותר משלוש פעמים בשנייה.
שלב 5: תוכן
- כותרות — כותרת ראשית אחת, והיררכיה שמספרת את סיפור העמוד.
- טקסט חלופי — לא רק "יש או אין", אלא האם הוא נכון. ראו טקסט חלופי לתמונות.
- קישורים — מובנים גם מחוץ להקשר.
- מסמכים ווידאו — PDF נגיש או חלופה, כתוביות לסרטונים. ראו מסמך PDF נגיש וכתוביות לווידאו.
- שפה — הגדרת שפת העמוד ומילים בשפה אחרת.
שלב 6: תיעוד
רשימה מסודרת של כל ממצא: איפה, מה הבעיה, איזה קריטריון WCAG, מה חומרתו, ומה תוקן. התיעוד הזה הוא הבסיס להצהרת הנגישות — כולל החלקים שעדיין לא נגישים — והוא גם מה שמאפשר לבדוק שוב אחרי כל שינוי גדול באתר.
כמה פעמים בודקים
- לפני השקה — בדיקה מלאה.
- אחרי כל שינוי בתבנית, רכיב חדש או תוסף שמציג משהו לגולשים.
- בדיקה תקופתית של תוכן חדש — כי עורכי תוכן מוסיפים תמונות, טבלאות וסרטונים כל הזמן.
שאלות נפוצות
מספיק להריץ Lighthouse?
לא. הוא מוצא חלק מהבעיות האוטומטיות, ולא בודק דברים כמו ניווט במקלדת בתפריט או חוויה בקורא מסך. הוא נקודת פתיחה.
מי צריך לבצע את הבדיקה?
בדיקה עצמית לפי השלבים כאן מגלה את הבעיות הבולטות. בדיקה מעמיקה — במיוחד לאתר גדול או לחנות — כדאי לעשות עם מי שמכיר את התקן ועובד עם טכנולוגיות מסייעות.
כלים אוטומטיים בעברית עובדים טוב?
הבדיקות האוטומטיות בודקות קוד, ולכן עובדות גם באתרים בעברית. מה שהן לא בודקות — למשל אם קורא המסך מקריא נכון טקסט מעורב עברית ואנגלית — צריך לבדוק ידנית.
בדיקת נגישות היא השלב הראשון בכל הנגשה שאני עושה, ומחליטה מה מתקנים בתבנית ומה בתוכן. ראו גם בדיקת אתר כללית, ואת עמוד השירות הנגשת אתרים לפי ת״י 5568.
אהבתם את המאמר?
