הנגשת אתר היא חובה חוקית בישראל, אבל סביב הנושא הצטבר הרבה רעש: מצד אחד חברות שמבטיחות "הנגשה מלאה בלחיצת כפתור", ומצד שני אזהרות על תביעות וקנסות. המאמר הזה מסדר את התמונה. מה התקן באמת דורש, איך נראה תהליך הנגשה אמיתי של אתר וורדפרס, ולמה הפתרון האוטומטי שמוכרים לכם כנראה לא יחזיק במבחן.
מה אומר החוק - תקנה 35 ות"י 5568
החובה להנגיש אתרי אינטרנט נובעת מתקנה 35 לתקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות). התקנה לא ממציאה דרישות טכניות משלה, אלא מפנה לתקן ישראלי מחייב: ת"י 5568, ברמת התאמה AA.
ת"י 5568 עצמו מבוסס על הנחיות הנגישות הבינלאומיות של ארגון התקינה של האינטרנט (WCAG 2.0), ובפועל ההמלצות העדכניות מתייחסות גם לגרסה 2.1. רמה AA היא רף הביניים מבין שלוש רמות (A, AA, AAA) והיא הרמה המחייבת בישראל. במילים פשוטות: כשאומרים "האתר צריך לעמוד בתקן", הכוונה היא לעמידה ב-ת"י 5568 ברמה AA.
מי חייב להנגיש
לא כל אתר חייב, ויש סף מחזור שקובע:
- אתר קיים (שהיה פעיל לפני 26/10/2017) חייב בהנגשה אם מחזור העסק עולה על כמיליון ש"ח בשנה.
- אתר חדש (שעלה אחרי המועד הזה) חייב כבר ממחזור של כ-100,000 ש"ח בשנה.
לפירוט מלא של ספי החבות ושל הקנס האפשרי כתבנו בנפרד במאמר כמה עולה הנגשת אתר - ומה הקנס אם לא תנגיש.
מה תקן 5568 דורש בפועל
התקן הוא רשימה ארוכה של קריטריונים, אבל מאחוריהם עומד עיקרון אחד: כל אדם צריך לתפוס, להבין ולתפעל את האתר, גם אם הוא משתמש בקורא מסך, בניווט מקלדת בלבד, או מתקשה בראייה צבעונית. אלה המוקדים שחוזרים כמעט בכל ביקורת נגישות (audit):
- טקסט חלופי לתמונות. כל תמונה שמעבירה מידע צריכה תיאור טקסטואלי שקורא מסך יכול להקריא.
- ניגודיות צבעים. טקסט מול רקע חייב יחס ניגודיות מינימלי (4.5:1 לטקסט רגיל) כדי שיהיה קריא לכבדי ראייה.
- ניווט מלא במקלדת. אפשר להגיע לכל קישור, כפתור ושדה טופס באמצעות מקש Tab בלבד, בסדר הגיוני, עם סימון ויזואלי ברור של המיקוד.
- מבנה כותרות תקין. היררכיית כותרות (H1, H2, H3) שמאפשרת לקורא מסך להבין את מבנה העמוד.
- טפסים נגישים. לכל שדה תווית (label) מקושרת, והודעות שגיאה נגישות וברורות.
- קוד תקני (ARIA). שימוש נכון בתגיות ובמאפייני ARIA כך שרכיבים דינמיים (תפריטים, חלונות קופצים, קרוסלות) ידווחו נכון לטכנולוגיה מסייעת.
- הצהרת נגישות. עמוד ייעודי שמפרט את רמת ההנגשה, פרטי רכז נגישות ודרך ליצירת קשר לדיווח על תקלה. זו דרישה חוקית בפני עצמה, ותבנית מוכנה יש לנו במאמר הצהרת נגישות לאתר.
הנקודה החשובה: חלק מהקריטריונים נבדקים אוטומטית, אבל רבים מהם מחייבים בדיקה ידנית ושיפוט אנושי. כלי אוטומטי יכול לדעת שחסר alt לתמונה, אבל הוא לא יכול לדעת אם ה-alt שכתבתם באמת מתאר את התמונה.
למה תוסף overlay לא פותר את הבעיה
זו אולי הנקודה החשובה ביותר במאמר, כי כאן רוב בעלי העסקים מוציאים כסף לחינם. הפתרונות שמוכרים כ"וידג'ט נגישות" (accessiBe, UserWay, Vee ודומיהם) הם שכבת JavaScript שמתלבשת על האתר ומוסיפה תפריט עם אפשרויות כמו הגדלת טקסט ושינוי ניגודיות.
הבעיה: השכבה הזו לא מתקנת את הקוד הבסיסי של האתר. בדיקות עצמאיות מצאו שאוברליי אוטומטי מתקן בפועל רק חלק קטן מקריטריוני WCAG (סדר גודל של 10-16 אחוז). כל מה שדורש שיפוט אנושי, alt משמעותי, סדר ניווט הגיוני, תיאור נכון של רכיבים, פשוט לא נפתר.
ויש פה גם סיכון משפטי הפוך. בינואר 2025 ה-FTC האמריקאי הגיש תלונה נגד accessiBe, ובאפריל 2025 אושר צו סופי שחייב את החברה בתשלום של מיליון דולר, בין היתר על טענת שווא שהמוצר האוטומטי שלה הופך כל אתר לתואם WCAG. כלומר הרגולטור עצמו קבע שהבטחת ה"הנגשה בלחיצת כפתור" היא מטעה. overlay יכול להיות תוספת נחמדה, אבל הוא אינו עמידה בתקן ולא מחליף הנגשה אמיתית. הרחבנו על כל הסיפור הזה במאמר למה תוסף נגישות (overlay) לא מספיק.
איך נראה תהליך הנגשה אמיתי
הנגשה נכונה היא עבודה על קוד האתר, לא הדבקת תוסף. כך זה עובד בפועל:
- ביקורת נגישות (audit). סריקה אוטומטית לאיתור כשלים גסים, ועליה בדיקה ידנית עם קורא מסך וניווט מקלדת. התוצר הוא רשימת ליקויים מדורגת לפי חומרה.
- תיקון בקוד ובתבנית. תיקון התבנית, התוספים והתוכן עצמו כך שיעמדו בקריטריונים. כאן מתקנים ניגודיות, מבנה כותרות, תוויות בטפסים ותגיות ARIA.
- בדיקה חוזרת. אימות שכל ליקוי תוקן באמת, כולל בדיקה עם טכנולוגיה מסייעת אמיתית ולא רק עם סורק.
- הצהרת נגישות ורכז נגישות. פרסום עמוד ההצהרה ומינוי גורם שמטפל בפניות.
- תחזוקה שוטפת. וזה החלק שרובם שוכחים. כל תוכן חדש, תמונה חדשה או תוסף חדש יכולים לשבור את ההנגשה. נגישות היא מצב מתמשך, לא פרויקט חד-פעמי.
חנויות WooCommerce ואתרים עתירי טפסים הם המקרים המאתגרים ביותר, כי תהליך הרכישה והסליקה מלא ברכיבים דינמיים שנכשלים ב-audit. על המוקדים הספציפיים שם כתבנו בהנגשת חנות WooCommerce וטפסים.
האם באמת מסוכן לא להנגיש
כדאי להחזיק את הפרופורציה הנכונה. כן, הנגשה היא חובה חוקית. אבל גל התביעות הסדרתיות שהפחיד בעלי עסקים נבלם משמעותית. בפסיקה מ-2024 (עניין בן אור נ' אביב) דחה בית המשפט תביעות נגישות סדרתיות, וקבע שצריך לפנות לבעל האתר ולתת לו זמן סביר (כ-60 יום) לתקן לפני שרצים לתביעה, ופסק פיצויים נמוכים.
המסקנה היא לא "אפשר להתעלם", אלא שאין סיבה לפעול מתוך פחד או לקנות פתרון יקר ומיותר בלחץ. הגישה הנכונה היא להנגיש כמו שצריך, פעם אחת, ולתחזק. זה גם זול יותר וגם בטוח יותר מאשר overlay שלא מחזיק.
הנגשה כחלק מאחריות 360
ב-OCW אנחנו מתייחסים לנגישות לא כפרויקט שנגמר, אלא כאחד מארבעה עמודי תווך של חבילת אחריות 360: אבטחה, נגישות, פרטיות ותחזוקה טכנית. הסיבה פשוטה. כמו אבטחה, גם נגישות נשחקת עם כל עדכון תוכן, ובדיוק כמו שאתר לא מתוחזק צובר פרצות, אתר מונגש שלא משגיחים עליו צובר ליקויי נגישות בשקט.
אם אתם לא בטוחים איפה האתר שלכם עומד מול תקן 5568, אנחנו עושים בדיקת נגישות ראשונית ומסבירים בדיוק מה חסר, בלי וידג'טים ובלי הבטחות קסם. אפשר לפנות דרך עמוד יצירת הקשר ולבקש בדיקה.
שאלות נפוצות
האם תוסף נגישות מספיק כדי לעמוד בחוק?
לא. תוסף overlay מתקן רק חלק קטן מהדרישות ואינו מהווה עמידה בתקן 5568. הרגולטור האמריקאי אף קנס יצרן overlay מוביל על טענת שווא בנושא זה.
מה זה ת"י 5568?
התקן הישראלי המחייב להנגשת אתרים, מבוסס על הנחיות WCAG 2.0 ברמה AA. תקנה 35 לתקנות שוויון זכויות מפנה אליו כדרישה החוקית.
האם כל אתר חייב להנגיש?
לא. החובה תלויה במחזור העסק ובמועד הקמת האתר: אתר חדש חייב כבר ממחזור נמוך יחסית, ואתר ותיק רק ממחזור גבוה יותר. הפירוט המלא נמצא במאמר על מחיר ההנגשה והקנס.
כמה זמן לוקח להנגיש אתר?
תלוי בגודל האתר ובמורכבותו. אתר תדמיתי קטן אפשר להנגיש בימים ספורים, ואילו חנות WooCommerce עם עשרות עמודים וטפסים דורשת תהליך ארוך יותר של audit, תיקון ובדיקה חוזרת.