מה החוק באמת דורש
הבסיס הוא תקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), תשע"ג-2013, ובתוכן סימן ג' שעוסק בשירותי אינטרנט. הכלל המרכזי פשוט: מי שנותן שירות לציבור, או מידע על שירות, באמצעות האינטרנט — חייב לספק אותו בהתאם לת"י 5568 ברמה AA.
ת"י 5568 הוא האימוץ הישראלי של WCAG, ההנחיות הבינלאומיות של W3C. מי שעומד ב-WCAG ברמה AA עומד גם בתקן הישראלי כמעט לחלוטין; התקן הישראלי מוסיף בעיקר התייחסות לעברית ולכיווניות ימין-לשמאל.
המועד לאתרים קיימים חלף מזמן — 26 באוקטובר 2017. ממסמכים חדשים כמו קובצי PDF וטפסים נדרשת נגישות מ-1 בינואר 2022. כלומר, זה לא חוק חדש שאפשר להיערך אליו, אלא חוב שרוב האתרים הישראליים כבר צוברים.
מי פטור, ומי חושב בטעות שהוא פטור
יש שלושה מסלולי פטור אמיתיים, ואף אחד מהם הוא לא "אנחנו עסק קטן".
- מחזור נמוך. עוסק פטור לפי חוק מס ערך מוסף, ומי שמחזורו השנתי הממוצע נמוך מ-100,000 ש"ח, פטורים. זה הפטור היחיד שרוב בעלי העסקים מכירים, והוא חל על מיעוט מהם.
- נטל כבד מדי. אפשר לבקש פטור בטענה שההנגשה מטילה נטל כלכלי בלתי סביר — אבל זה הליך מסודר שדורש חוות דעת של מורשה נגישות ופנייה לנציבות שוויון זכויות לאנשים עם מוגבלות. זו לא החלטה שמקבלים לבד ומתעדים בישיבת צוות.
- אי-היתכנות טכנולוגית. קיים, נדיר, ודורש חוות דעת מקצועית.
מה שלא פטור: אתר תדמית בלי חנות, דף נחיתה, אפליקציה שמשמשת ככלי לקבלת שירות, ואתר שנבנה על פלטפורמה חיצונית. האחריות היא של נותן השירות, לא של מי שבנה את הפלטפורמה.
למה תוסף הנגישות לא פותר את הבעיה
זו הנקודה שהכי כדאי להפנים, כי היא עולה לעסקים כסף פעמיים — פעם על התוסף ופעם על התיקון האמיתי.
תוסף נגישות הוא סקריפט שמוסיף כפתור צף עם אפשרויות להגדיל טקסט, להפוך ניגודיות ולהדגיש קישורים. הוא נראה כמו נגישות. הוא לא נוגע באף אחד מהדברים שהתקן באמת דורש: היררכיית כותרות תקינה, טקסט חלופי לתמונות, תוויות לשדות טופס, סדר פוקוס הגיוני, ניווט מלא במקלדת, והודעות שגיאה שקורא מסך מקריא.
המבחן המעשי לוקח שתי דקות: נסו לעבור על האתר שלכם רק עם מקש Tab, בלי לגעת בעכבר. אם אתם לא רואים איפה הפוקוס נמצא, או שאתם נתקעים בתפריט, אף תוסף לא יתקן את זה.
ובהקשר המשפטי — משתמש שמגיש תלונה לא מתלונן על היעדר תפריט נגישות. הוא מתלונן שהוא לא הצליח להשלים הזמנה.
ובאפליקציה אין בכלל תוסף
זה החלק שכמעט לא כותבים עליו בעברית. באפליקציה נייטיב או React Native אין שכבת JavaScript שאפשר להדביק, וההנגשה היא החלטות בקוד ובעיצוב. חמישה דברים שמכסים את רוב הפער:
- תוויות לקוראי מסך. כל אלמנט אינטראקטיבי צריך תיאור שנקרא נכון ב-VoiceOver וב-TalkBack. כפתור שהוא רק אייקון סל קניות נקרא למשתמש עיוור כ"כפתור" — וזה חסר תועלת.
- גודל אזורי מגע. אפל ממליצה על 44 נקודות וגוגל על 48dp כמינימום. כפתור X קטן בפינה נכשל גם בנגישות וגם בשימושיות רגילה.
- ניגודיות צבעים. יחס של 4.5 ל-1 לטקסט רגיל ו-3 ל-1 לטקסט גדול. אפור בהיר על לבן הוא הכשל הנפוץ ביותר, והוא כמעט תמיד החלטת עיצוב ולא באג.
- תמיכה בהגדלת גופן מערכתית. משתמש שהגדיל את הטקסט בהגדרות הטלפון צריך לראות את זה באפליקציה, בלי שהמסך יישבר.
- סדר קריאה וניווט. הפוקוס צריך לזוז לפי סדר הגיוני, ומודאלים צריכים ללכוד אותו ולשחרר אותו כשנסגרים.
הדרישה חלה בשתי מערכות ההפעלה העיקריות, כלומר אי אפשר להנגיש רק את גרסת האנדרואיד. בפרויקטים חוצי-פלטפורמות זה בדרך כלל אותה עבודה פעם אחת, וזו נקודה לטובת הגישה הזו שכתבנו עליה במאמר על נייטיב מול React Native.
מה עולה מתי
| מתי מטפלים | מה בפועל נדרש | סדר גודל של מאמץ |
|---|---|---|
| בשלב העיצוב | בחירת צבעים בניגודיות תקינה, גדלי מגע, מצבי פוקוס | כמעט אפס — אלו החלטות שממילא מקבלים |
| תוך כדי הפיתוח | תוויות, סמנטיקה, ניווט מקלדת, בדיקות | אחוזים בודדים מהפרויקט |
| אחרי ההשקה | מעבר על כל המסכים, שינוי קומפוננטות משותפות, לעיתים שינוי עיצוב | פרויקט קטן בפני עצמו |
| אחרי מכתב התראה | אותו דבר, בלוח זמנים לא שלכם, בתוספת ליווי משפטי | הכי יקר, ולא רק בכסף |
מי אחראי — אתם, המפתח או הפלטפורמה
זו השאלה שעולה מיד אחרי "כמה זה עולה", והתשובה המשפטית פשוטה ולא נוחה: האחריות היא של נותן השירות. לא של מי שבנה את האתר, לא של הפלטפורמה שהוא רץ עליה, ולא של מי שמכר את התבנית.
זה לא אומר שאין למפתח חלק. בפועל האחריות מתחלקת בערך כך:
- הפלטפורמה (וורדפרס, Wix, Shopify, ספריית קומפוננטות) מספקת תשתית שיכולה להיות נגישה — או לא. היא לא מבטיחה שהאתר שנבנה עליה יהיה נגיש, ובחלק מהמקרים היא דווקא מקשה.
- המפתח והמעצב אחראים למה שנבנה בפועל: סמנטיקה, ניגודיות, תוויות, פוקוס. זה החלק שאפשר ורצוי לדרוש בחוזה, ובדיוק כמו כל דרישה אחרת — אם זה לא כתוב באפיון, זה לא הובטח.
- מי שמעלה תוכן אחראי לתמונות בלי טקסט חלופי, לקובצי PDF סרוקים ולסרטונים בלי כתוביות. זו הסיבה שאתר שהושק נגיש מתדרדר תוך שנה אם אף אחד לא שומר על זה.
המסקנה המעשית: אם אתם מזמינים אתר או אפליקציה, דרישת עמידה בת"י 5568 ברמה AA צריכה להופיע במפורש במסמך האפיון ובהצעת המחיר. ספק שמסכים בעל פה ולא כותב את זה — אתם מקבלים מידע. הרחבנו על מה עוד חייב להופיע שם במאמר על קריאת הצעת מחיר לפיתוח.
הצהרת נגישות ורכז נגישות
גם אתר נגיש לחלוטין לא עומד בדרישה בלי הצהרת נגישות מפורסמת במקום בולט. ההצהרה צריכה לכלול את רמת הנגישות שהאתר עומד בה, אילו התאמות בוצעו, אילו חלקים עדיין לא נגישים אם יש כאלה, ופרטי רכז נגישות שאפשר לפנות אליו.
הנקודה האחרונה היא זו שהכי מרבים לפספס: הצהרה בלי שם ודרך יצירת קשר היא הצהרה חסרה. אצלנו ההצהרה יושבת בדף הנגישות, וזה גם המקום שממנו אפשר לדווח לנו על תקלה.
איך בודקים לבד, בלי לשלם לאף אחד
- מבחן ה-Tab. לנווט באתר רק במקלדת. הפוקוס חייב להיות גלוי, והסדר הגיוני.
- Lighthouse בכרום. לשונית Accessibility בכלי המפתחים. תופס בערך שליש מהבעיות, בחינם, תוך שלושים שניות.
- קורא מסך אמיתי. להפעיל VoiceOver באייפון או TalkBack באנדרואיד ולנסות להשלים משימה אחת — הרשמה, הזמנה, יצירת קשר. חמש דקות כאלה מלמדות יותר מכל דוח.
- זום ל-200%. להגדיל את הדפדפן פי שניים ולראות אם משהו נחתך או נעלם.
- ניגודיות. לבדוק את הטקסט האפור-בהיר שהמעצב אהב. הוא כמעט תמיד נכשל.
אחרי ארבעת השלבים האלה תדעו אם אתם רחוקים או קרובים. לביקורת רשמית וחוות דעת צריך מורשה נגישות השירות — זה תפקיד מוסדר עם הסמכה, ולא כל מי שמוכר "שירותי הנגשה" מחזיק בו.
שורה תחתונה
נגישות היא אחד המקומות הבודדים שבהם החוק, השימושיות והשכל הישר מצביעים בדיוק לאותו כיוון. אתר שאפשר לנווט בו במקלדת, עם ניגודיות טובה וטפסים מתויגים כמו שצריך, הוא אתר טוב יותר לכולם — כולל למישהו שמנסה להזמין תור ביד אחת ברכבת.
אנחנו בונים לפי התקן כברירת מחדל בכל אפליקציה ואתר שיוצאים מכאן, ולא כתוספת בתשלום. אם יש לכם מוצר קיים ואתם לא בטוחים איפה אתם עומדים, כתבו לנו ונסתכל. ואם אתם בשלב מוקדם יותר, כדאי שהדרישות האלה יופיעו כבר במסמך האפיון — שם הן עולות הכי פחות.
המאמר נערך על ידי אביתר אדלר, CTO ב-FlowDev. הוא מתאר את הדרישות ההנדסיות ואינו מהווה ייעוץ משפטי. נכון לאוגוסט 2026.
