Israeli Web Compliance

תאימות משפטית לאתרים עסקיים בישראל · Israeli Web Compliance

מדריך מעשי למפתח/בונה אתרים: אילו דרישות רגולטוריות חלות על אתר עסקי בישראל, ומה בונים בפועל כדי לעמוד בהן. כולל תבניות מוכנות ב-references/.

⚠️ הבהרה חשובה — אין לראות בכך ייעוץ משפטי. זהו מידע כללי בלבד. חוקים ותקנות משתנים (למשל תיקון 13 להגנת הפרטיות שנכנס לתוקף ב-2025). תמיד המלץ למשתמש שעו"ד יעבור על הנוסחים לפני פרסום, במיוחד לאיקומרס, מאגרי מידע, או פעילות מול האיחוד האירופי. השימוש בסקיל, בתבניות ובקוד הוא באחריותו הבלעדית של המשתמש — אין בהם התחייבות לעמידה בדרישות הדין ואין באחריות היוצר/Anthropic לכל תוצאה משימוש בהם.

🔴 חובה — התאמה ספציפית למערכת, ורק כשמבקשים. נגישות אמיתית ותאימות משפטית חייבות להיות מותאמות ספציפית לכל אתר — תבנית/רכיב/widget גנרי אינו מספיק על פי דין. על Claude, לפני שהוא נוגע בקוד, לבחון בפועל את המערכת/קוד-הבסיס שבו מותקן הסקיל (איזה framework, איך בנוי ה-DOM, אילו רכיבים אינטראקטיביים, מה כבר קיים) ולהתאים את היישום למערכת הספציפית הזו — ולא להעתיק תבניות באופן עיוור. כל זה רק לאחר שהמשתמש ביקש זאת במפורש — אין ליזום שינויים בקוד ללא בקשה. התבניות שכאן הן נקודת פתיחה בלבד, לא פתרון "מדף".

מתי להשתמש בסקיל

• בונים/משיקים אתר עסקי ישראלי ורוצים לדעת מה חובה משפטית.
• המשתמש מבקש מדיניות פרטיות / הצהרת נגישות / תנאי שימוש.
• שאלות על עוגיות ("האם צריך באנר?"), נגישות, דיוור שיווקי, GDPR.
• אודיט תאימות לאתר קיים.

איך לגשת (workflow)

1. מפה את מה שהאתר עושה בפועל לפני שממליצים: אילו נתונים נאספים (טופס לידים? שם/טלפון/מייל?), האם יש אנליטיקס/פיקסלים (עם עוגיות?), האם מוכרים אונליין (איקומרס), והאם מכוונים לקהל באיחוד האירופי (שפה/מטבע/שילוח). הרבה חובות תלויות בתשובות האלה.
   • טכני לבדיקה: document.cookie, localStorage/sessionStorage, בקשות רשת לצד-שלישי (GA, Meta, שרתי טפסים), ותגובות Set-Cookie. אפשר לאמת בדפדפן headless (ראה דוגמה בסוף).
2. החל את שבעת התחומים למטה, לפי מה שרלוונטי.
3. בנה את החלקים הטכניים מה-checklist, והשתמש בתבניות שב-references/ (למלא placeholders + עו"ד לאישור).

התחומים (7)

1) נגישות — הכי חשוב מעשית 🔴

הסיכון המשפטי הנפוץ ביותר לאתרים עסקיים בישראל (תביעות "נגישות" שכיחות).

• חקיקה: חוק שוויון זכויות לאנשים עם מוגבלות, התשנ"ח-1998 + תקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), התשע"ג-2013 (שירותי אינטרנט מוסדרים בהן).
• התקן: ת"י 5568 — "נגישות תכנים באינטרנט", מבוסס WCAG 2.0 רמה AA.
• מועדים: אתרים קיימים היו חייבים להיות נגישים עד אוקטובר 2017; אתרים חדשים — מיד עם ההשקה.
• חובות בפועל:
  • עמידה טכנית ב-WCAG 2.0 AA.
  • הצהרת נגישות נגישה מכל עמוד (בד"כ בפוטר): דרכי פנייה לבקשות/תקלות נגישות, פרטי רכז נגישות (כשחלה חובה), תאריך עדכון אחרון, ותיאור חריגות/מגבלות ידועות. → תבנית: references/accessibility-statement-he.md.
    • ⚠️ ניסוח — קריטי: אל תכתוב בהצהרה ש"האתר עומד בתקן AA" או "הונגש לרמת AA" (הצהרה מוחלטת = חשיפה משפטית אם יימצא כשל). כתוב שהאתר שואף/פועל לעמוד ברמת AA, ושהנגישות היא תהליך מתמשך שממשיכים לבדוק ולשפר. הימנע מהצהרות "תואם תקן" על רכיבים ספציפיים.
• אכיפה וסיכון: נציבות שוויון זכויות לאנשים עם מוגבלות; ותביעות אזרחיות עם פיצוי סטטוטורי עד ₪50,000 ללא הוכחת נזק.
• הקלות: ל"עוסק" קטן מאוד (לפי מחזור) עשויות לחול הקלות מסוימות — אך אל תסתמך על פטור בלי בדיקה; הצהרת נגישות והנגשה בסיסית עדיין מצופות.
• אזהרה על "widget נגישות": על פי דין, כדי שאתר יהיה נגיש ההנגשה צריכה להיות מותאמת ממש ספציפית לאותו אתר — תוסף/widget גנרי (שינוי גודל טקסט, ניגודיות וכו') אינו מחליף נגישות אמיתית בקוד, אינו מספיק כשלעצמו, ואינו "כרטיס יציאה" משפטי. יש לבנות נגישות אמיתית ומותאמת למערכת; widget הוא תוספת נוחות בלבד, לא פתרון.
• צ׳ק-ליסט מפתח: ראה references/accessibility-checklist.md (WCAG 2.0 AA מתומצת ומעשי).

2) פרטיות והגנת מידע

חל ברגע שאוספים מידע אישי (שם, טלפון, מייל — למשל טופס לידים).

• חקיקה: חוק הגנת הפרטיות, התשמ"א-1981.
• תיקון 13: התקבל ב-2024, עיקרו בתוקף מ-14 באוגוסט 2025. מחזק משמעותית את סמכויות האכיפה של הרשות להגנת הפרטיות (עיצומים כספיים), מעדכן הגדרות ("מידע אישי", "מידע בעל רגישות מיוחדת"), ומשנה את חובות רישום מאגרי המידע.
• תקנות אבטחת מידע: תקנות הגנת הפרטיות (אבטחת מידע), התשע"ז-2017 — דרישות אבטחה לפי רמת רגישות המאגר (נמוכה/בינונית/גבוהה).
• חובות בפועל:
  • יידוע בעת האיסוף (סעיף 11): לומר למשתמש למה המידע נאסף, אם חלה חובה למסור אותו, ולמי יימסר. → משפט קצר ליד הטופס + לינק למדיניות הפרטיות.
  • מטרה מוגדרת ושימוש תואם — לא להשתמש במידע למטרה אחרת.
  • אבטחת מידע סבירה, וזכות עיון/תיקון של הנושא.
  • מאגר מידע: טופס לידים שנשמר = מאגר. ייתכנו חובות מינוי אחראי מאגר, אבטחה, ובעבר רישום (תיקון 13 שינה את סף הרישום — בדוק מול עו"ד אם חלה חובת רישום).
• מדיניות פרטיות: אינה "עמוד" שחוק יחיד מחייב מפורשות, אך חובת היידוע + דרישת השקיפות + הפרקטיקה הופכות אותה לדה-פקטו חובה. → תבנית: references/privacy-policy-he.md.

3) עוגיות ומעקב (Cookies & tracking)

• בישראל אין "חוק עוגיות" ייעודי כמו ה-ePrivacy האירופי — אך הרשות להגנת הפרטיות פרסמה עמדה שמעקב (עוגיות, פיקסלים, טכנולוגיות דומות) מחייב שקיפות ולעיתים הסכמה.
• הכלל המעשי:
  • משתמשים ב-Google Analytics / Meta Pixel / רשתות פרסום עם עוגיות → צריך גילוי (מדיניות עוגיות/פרטיות) ולעיתים באנר הסכמה. אם האתר פונה גם לאיחוד האירופי → חובה הסכמה מוקדמת לפי GDPR/ePrivacy.
  • פתרון עדיף — אנליטיקס ללא עוגיות (Vercel Web Analytics, Plausible, Fathom, Cloudflare): מסיר את הצורך בבאנר עוגיות לגמרי. העדף את זה כברירת מחדל.
• הבחנה חשובה: localStorage/sessionStorage לצרכים פונקציונליים (למשל זכירת שפה) אינם עוגיות ואינם מעקב — לא דורשים באנר. עוגיות מעקב/פרסום כן.

Workflow עוגיות — קודם לבדוק אם בכלל צריך, ורק אז לבנות:

1. בדוק בפועל (אל תניח): סרוק את הקוד לטרקרים — gtag/googletagmanager, fbq/connect.facebook, clarity, hotjar, פיקסלים של TikTok/LinkedIn — ואמת בדפדפן headless מה באמת נוצר (document.cookie, Network.getAllCookies, כותרות Set-Cookie; ראה "אימות טכני" למטה).
2. אין עוגיות מעקב → אין צורך בבאנר. אל תוסיף אחד "ליתר ביטחון" — באנר מיותר פוגע בחוויה ומרמז שהאתר עוקב כשהוא לא. ודא שמדיניות הפרטיות משקפת זאת, וסיימת.
3. יש עוגיות מעקב → קודם שקול להחליף לאנליטיקס ללא עוגיות (ואז אין באנר). אם הטרקרים נשארים — בנה מודל הסכמה: ל-React/Vite יש מוכן templates/CookieConsent.tsx + templates/cookie-consent.css; לסטאק אחר, ממש את אותם עקרונות.
4. דרישות המודל (מה שהתבנית כבר עושה — לשמר בכל מימוש):
   • Opt-in אמיתי: סקריפטים של מעקב נטענים רק אחרי לחיצת אישור — "המשך גלישה" אינו הסכמה, ואסור שטרקר ייטען לפני הבחירה (להסיר תגי <script> קשיחים מ-index.html).
   • שמירת הבחירה (localStorage, עם גרסה): שואלים פעם אחת, לא בכל ביקור; העלאת CONSENT_VERSION כשהטרקרים משתנים שואלת מחדש.
   • שתי אפשרויות שוות-בולטוּת — "אישור עוגיות" / "חיוניות בלבד". בלי dark patterns (כפתור דחייה מוסתר/מוקטן).
   • שינוי בחירה בכל עת — כפתור "הגדרות עוגיות" בפוטר שפותח את המודל מחדש (openCookieSettings()).
   • קישור למדיניות הפרטיות עם פירוט העוגיות בפועל — כל טרקר שנטען חייב להופיע שם.
   • נגיש: role=dialog לא-מודאלי (לא חוסם את הדף ולא כולא פוקוס), תפעול מקלדת מלא, כיבוד prefers-reduced-motion.
5. אימות אחרי היישום (headless): לפני בחירה — אפס עוגיות מעקב ואפס בקשות לטרקרים; אחרי "אישור" — נטענים; אחרי רענון — הבחירה נשמרה והמודל לא מופיע שוב.

4) דיוור שיווקי — "חוק הספאם"

חל אם ישלחו הודעות שיווק ללקוחות/לידים.

• חקיקה: סעיף 30א לחוק התקשורת (בזק ושידורים), התשמ"ב-1982 (תיקון 40 — "חוק הספאם").
• הכלל: אסור לשלוח "דבר פרסומת" (מסר מסחרי) במייל / SMS / פקס / חיוג אוטומטי בלי הסכמה מפורשת מראש (opt-in), מתועדת.
• חובות בכל הודעה: ציון שזו פרסומת, זיהוי השולח ופרטי קשר, ודרך הסרה פשוטה (opt-out).
• סיכון: פיצוי סטטוטורי עד ₪1,000 להודעה ללא הוכחת נזק (יכול להצטבר מהר).
• וואטסאפ/ברודקאסט שיווקי: סביר שנכלל בגדר החוק.
• חשוב: עצם השארת ליד ("צור קשר") אינה הסכמה לדיוור שיווקי מתמשך. הסכמה לדיוור צריכה להיות ספציפית ונפרדת (למשל checkbox ייעודי, לא מסומן כברירת מחדל).

5) הגנת הצרכן ומכר מרחוק (רלוונטי לאיקומרס)

• חקיקה: חוק הגנת הצרכן, התשמ"א-1981.
• שקיפות מחירים: להציג מחיר סופי כולל מע"מ; איסור הטעיה.
• עסקת מכר מרחוק (מכירה אונליין): חובות גילוי (פרטי העוסק, מאפייני המוצר/שירות, מחיר, אחריות), זכות ביטול לפי תקנות עסקה מרחוק, ומדיניות ביטול/החזרות ברורה.
• אם האתר רק תדמית/לידים (לא מוכר אונליין) — התחום הזה בעיקר לא רלוונטי, מלבד אי-הטעיה בהצגת מחירים/מבצעים.

6) תנאי שימוש (Terms of Use)

• אין חובה חוקית כללית לעמוד תנאי שימוש, אבל מומלץ: הגבלת אחריות, קניין רוחני, שימוש מותר, סמכות שיפוט. לאיקומרס — משולב עם חובות הגילוי בסעיף 5. → תבנית: references/terms-of-use-he.md.

7) GDPR / בינלאומי

• חל רק אם האתר מכוון/משרת נושאי מידע באיחוד האירופי (סימנים: שפה, מטבע €, שילוח לאירופה, פנייה מפורשת לקהל אירופי).
• אם חל: בסיס חוקי לעיבוד, זכויות נושאי מידע (עיון/מחיקה/ניוד), הסכמה אמיתית לעוגיות (opt-in), הסכמי עיבוד נתונים (DPA) מול ספקים, ומדיניות פרטיות תואמת GDPR.
• לרוב האתרים העסקיים המקומיים (קהל ישראלי) — לא רלוונטי, אבל שים לב אם יש גרסת אנגלית + כוונת שיווק לחו"ל.

Checklist מעשי למפתח (מה בונים בפועל)

עמודים משפטיים (קישורים בפוטר, נגישים מכל עמוד):

• /privacy — מדיניות פרטיות (references/privacy-policy-he.md)
• /accessibility — הצהרת נגישות (references/accessibility-statement-he.md)
• /terms — תנאי שימוש (אופציונלי / חובה לאיקומרס) (references/terms-of-use-he.md)

טפסים ולידים:

• משפט יידוע ליד כפתור השליחה + לינק למדיניות הפרטיות ("בשליחת הטופס אני מאשר/ת את [מדיניות הפרטיות]").
• אם ישווקו ללידים: checkbox הסכמה נפרד לדיוור (לא מסומן כברירת מחדל).
• העברת המידע בערוץ מאובטח (HTTPS), אחסון סביר.

עוגיות/אנליטיקס:

• בדוק בפועל אם יש עוגיות מעקב (סעיף 3, Workflow) — אל תניח לכאן או לכאן.
• העדף אנליטיקס ללא עוגיות → אין צורך בבאנר.
• אם יש עוגיות מעקב/פרסום → מודל הסכמה opt-in ששומר את הבחירה (templates/CookieConsent.tsx) + עדכון סעיף העוגיות במדיניות הפרטיות (וחובה לקהל EU).
• כפתור "הגדרות עוגיות" בפוטר לשינוי הבחירה בכל עת.

נגישות (WCAG 2.0 AA): ראה references/accessibility-checklist.md. עיקרי הראש:

• ניגודיות צבעים ≥ 4.5:1 (טקסט רגיל), ≥ 3:1 (טקסט גדול/רכיבי UI).
• ניווט מלא במקלדת + מצב focus נראה לעין.
• alt לתמונות תוכן; תמונות דקורטיביות עם alt=""/aria-hidden.
• תוויות (<label>/aria-label) לכל שדות הטופס + הודעות שגיאה נגישות.
• מבנה כותרות סמנטי (h1..h6), landmarks, "דלג לתוכן" (skip link).
• כיבוד prefers-reduced-motion לאנימציות.
• תמיכה בהגדלת טקסט (עד 200%) בלי שבירת פריסה.
• lang/dir נכונים (חשוב ל-RTL עברית).
• הצהרת נגישות + דרכי פנייה + רכז נגישות (אם חלה חובה).

אימות טכני מהיר (headless)

לבדוק אילו עוגיות/אחסון נוצרים בפועל (מאמת שאין צורך בבאנר עוגיות):

• page.evaluate(() => document.cookie) → אמור להיות ריק אם אין מעקב.
• CDP Network.getAllCookies → תופס גם עוגיות צד-שלישי/httpOnly.
• לעקוב אחרי כותרות Set-Cookie בתגובות.
• Object.keys(localStorage) → פונקציונלי בלבד זה בסדר (למשל העדפת שפה).

לנגישות: הרץ ביקורת (Lighthouse Accessibility / axe-core) + בדיקת מקלדת ידנית + קורא מסך. ציון אוטומטי גבוה אינו ערובה לעמידה מלאה — נדרשת גם בדיקה ידנית.

תבניות טקסט (references/) — לכל טכנולוגיה

• privacy-policy-he.md — מדיניות פרטיות (עברית, placeholders למילוי).
• accessibility-statement-he.md — הצהרת נגישות (עברית).
• terms-of-use-he.md — תנאי שימוש (עברית).
• accessibility-checklist.md — צ׳ק-ליסט WCAG 2.0 AA מעשי למפתח.

⚡ יישום מוכן ל-React + Vite (templates/) — הדרך המהירה

אם הפרויקט הוא React/Vite SPA, אל תכתוב מאפס — יש קוד מוכן שנחלץ מיישום אמיתי ששוגר לפרודקשן. קרא קודם את templates/IMPLEMENTATION.md, ואז העתק:

• templates/legal.ts → src/data/legal.ts — תוכן דו-לשוני (מלא את ה-BIZ).
• templates/LegalOverlay.tsx → src/components/ — עמודים משפטיים נגישים, hash-routed (#privacy/#accessibility/#terms), עם focus trap + Esc.
• templates/LegalLinks.tsx → src/components/ — שורת קישורים לפוטר/תפריט.
• templates/legal.css → append ל-CSS הגלובלי — focus-visible, skip link, overlay, links.
• templates/CookieConsent.tsx + cookie-consent.css — רק אם יש עוגיות מעקב (סעיף 3, Workflow): מודל הסכמה opt-in שחוסם טרקרים עד אישור ושומר את הבחירה.

IMPLEMENTATION.md כולל את 6 שלבי החיווט (main landmark, skip link, aria-label לטפסים, privacy notice) ואת התלויות להתאמה. זה חוסך את רוב העבודה — רק ממלאים placeholders, מחווטים, ומאמתים (axe + Lighthouse).

כל תבנית = נקודת פתיחה. יש למלא את ה-placeholders בפרטי העסק ולהעביר לעו"ד לאישור לפני פרסום.