נגישות, פרטיות ותיקון 13 באתר WordPress
מדריך מעשי ומורחב לבניית אתר WordPress שמחבר בין נגישות, טפסים, פרטיות, אבטחת מידע, ספקי צד שלישי ותיקון 13 — כחלק מהתשתית ולא כתיקון של הרגע האחרון.
נגישות ופרטיות אינן שני עמודים שמוסיפים לאתר רגע לפני ההשקה. באתר WordPress עסקי הן צריכות להיות חלק מהארכיטקטורה: איך בונים כותרות וטפסים, איך משתמשים במקלדת ובקורא מסך, איזה מידע נאסף, למה הוא נאסף, מי מקבל אותו, כמה זמן שומרים אותו, אילו ספקים נחשפים אליו ואיך המשתמש מקבל מידע ברור בזמן האיסוף. תיקון 13 לחוק הגנת הפרטיות, שנכנס לתוקף באוגוסט 2025, הרחיב וחידד את מסגרת האחריות בישראל; במקביל, דיני הנגישות ממשיכים לחייב שירותי אינטרנט רלוונטיים לעמוד בדרישות החלות עליהם. לכן הדרך הנכונה היא לבנות תהליך — לא להסתפק בתוסף.
למה נגישות ופרטיות צריכות להיבנות יחד?
במבט ראשון מדובר בשני עולמות שונים. נגישות עוסקת ביכולת של אנשים עם מוגבלות לקבל שירות ולהשתמש באתר; פרטיות עוסקת בשליטה במידע אישי, שקיפות, שימוש מותר, אבטחה וזכויות נושאי המידע. בפועל, שתיהן פוגשות בדיוק את אותם רכיבי WordPress: טופס צור קשר, טופס הרשמה, אזור אישי, מערכת תגובות, WooCommerce, כלי אנליטיקה, סרטונים, תפריטים, חלונות קופצים, CAPTCHA, צ'אט, מסמכים להורדה ותוספי צד שלישי.
טופס הוא דוגמה מצוינת. מבחינת נגישות, השדות צריכים להיות מזוהים היטב, התוויות צריכות להיות ברורות, הודעות השגיאה צריכות להיות מובנות, סדר ה־Tab צריך להיות הגיוני והטופס צריך להיות ניתן להפעלה ללא עכבר. מבחינת פרטיות, צריך להבין אילו פרטים נאספים, מה מטרת האיסוף, האם כל שדה באמת נחוץ, למי המידע עובר, איפה הוא נשמר ואיזה יידוע נדרש בזמן האיסוף. אותו רכיב בדיוק דורש אפוא חשיבה כפולה.
זו גם הסיבה שפתרון “תוסף נגישות + עמוד מדיניות פרטיות” אינו מתודולוגיה מספקת. תוסף יכול להוסיף יכולות מסוימות, ומדיניות יכולה להסביר חלק מהתהליכים, אבל אף אחד מהם אינו מחליף מבנה HTML תקין, תהליך איסוף מידע מסודר, ניהול הרשאות, בחינת ספקים, בדיקות מקלדת, טקסט חלופי או החלטה מודעת אילו נתונים בכלל צריכים להישמר. בדיוק כפי שמוסבר במדריך השוואת תוספי אבטחה ל־WordPress, תוסף הוא שכבה בתוך מערכת שלמה ולא תחליף לתשתית נכונה.
מבנה, מקלדת, ניגודיות, כותרות, טפסים, מדיה וטקסט חלופי.
מה נאסף, למה, האם חובה למסור, למי המידע יועבר ומהן זכויות המשתמש.
הרשאות, ספקים, אבטחה, שמירה, מחיקה, גיבוי ותיעוד תהליכים.
נגישות אתרי אינטרנט בישראל: מה חשוב להבין לפני שנוגעים בקוד?
תקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות) כוללות הוראות לגבי שירותי אינטרנט. לפי מדריכי נציבות שוויון זכויות לאנשים עם מוגבלות, החובה מתייחסת לשירות לציבור הניתן באמצעות האינטרנט, בהתאם להגדרות ולתנאים שבדין. התקנות מפנות לתקן הישראלי 5568, והוראות נגישות שירותי האינטרנט מתייחסות לרמת AA בכפוף להוראות התקנות.
הנקודה החשובה לבעל אתר היא שהשאלה אינה “האם התקנתי כפתור נגישות”, אלא האם השירות הדיגיטלי עצמו נגיש. אתר יכול לכלול תפריט נגישות מרשים ועדיין להיות בלתי שמיש באמצעות מקלדת. הוא יכול לאפשר הגדלת טקסט, אך להשאיר שדות טופס ללא Label. הוא יכול לשנות צבעים, אך להציג מודאל שלא ניתן לסגור בלי עכבר. לכן בדיקת נגישות אמיתית מתחילה בתוכן ובאינטראקציה.
נציבות השוויון מפרסמת גם מידע על פטורים ומצבים שבהם נבחנים פרמטרים כגון מחזור והאם האתר נחשב “חדש” או “קיים”. אין להסיק מהיקף עסק קטן באופן אוטומטי שהוא פטור; יש לבדוק את ההוראות והנסיבות הספציפיות. בנוסף, הנציבות מבהירה כי קיימת חובה לפרסום הצהרת נגישות ומידע על הסדרי נגישות במקרים הרלוונטיים, וממליצה לרכז את המידע באופן ברור ונגיש.
WCAG: ארבעה עקרונות במקום רשימת קסמים
WCAG של W3C בנוי סביב ארבעה עקרונות: התוכן צריך להיות ניתן לתפיסה, ניתן להפעלה, מובן וחסין מספיק כדי לעבוד עם טכנולוגיות מסייעות. זו דרך טובה יותר לחשוב על אתר מאשר “האם יש Alt לכל תמונה”. טקסט חלופי הוא רכיב אחד מתוך מערכת שלמה.
ניתן לתפיסה: מידע לא צריך להסתמך רק על צבע, תמונה או צליל. אם גרף מעביר מסר, צריך לספק דרך טקסטואלית להבין אותו. אם כפתור הוא אייקון בלבד, צריך שם נגיש. אם סרטון מעביר תוכן משמעותי, יש לבחון חלופות מתאימות.
ניתן להפעלה: משתמש שאינו מפעיל עכבר צריך להיות מסוגל להגיע לרכיבים, להבין היכן הפוקוס ולבצע פעולות. תפריט, Accordion, Popup, Slider וטופס צריכים לעבוד גם עם מקלדת.
מובן: תוויות, הוראות ושגיאות צריכות להיות ברורות. אם הטופס דורש פורמט מסוים לטלפון או לתאריך, המשתמש צריך להבין זאת. אם פעולה בלתי הפיכה עומדת להתבצע, הממשק צריך להיות צפוי.
חסין: הקוד צריך להיות בנוי כך שטכנולוגיות מסייעות יוכלו לפרש אותו. שימוש באלמנטים סמנטיים, שמות נגישים ויחסי Label־Input תקינים עדיף על שכבות JavaScript שמנסות “לתקן” HTML לא תקין לאחר הטעינה.
איך מיישמים נגישות נכון בתוך WordPress?
WordPress מאפשר לבנות אתר נגיש, אבל אינו מבטיח זאת אוטומטית. התוצאה תלויה בתבנית, בבונה העמודים, בווידג'טים, בתוספים, בתוכן ובקוד המותאם. גם תבנית שמצהירה על התאמה לנגישות יכולה להפוך לעמוד בעייתי כאשר מוסיפים רכיב צד שלישי שאינו תומך במקלדת. בחירת סביבת העריכה משפיעה על אופן בניית המבנה, ולכן כדאי לקרוא גם את אלמנטור או גוטנברג לאתר עסקי.
התחילו מהמבנה. לכל עמוד צריכה להיות היררכיית כותרות הגיונית. אין להשתמש ב־H2 רק מפני שהוא “נראה בגודל הנכון”; עיצוב עושים ב־CSS, וסמנטיקה קובעת את מבנה המסמך. קישורים צריכים להיות מובנים בהקשר. טקסט כמו “לחצו כאן” שחוזר עשר פעמים מקשה על משתמש שקורא רשימת קישורים באמצעות קורא מסך.
בתמונות, Alt אינו תיאור ספרותי אוטומטי. תמונה דקורטיבית שאינה מוסיפה מידע יכולה לקבל Alt ריק בהתאם להקשר, בעוד תמונה שמעבירה מידע צריכה טקסט חלופי שמעביר את הפונקציה או המסר. לוגו מקושר לדף הבית צריך להיות מובן כקישור לבית. אינפוגרפיקה מורכבת עשויה לדרוש הסבר טקסטואלי נוסף בגוף העמוד.
ב־Elementor ובבוני עמודים אחרים חשוב במיוחד לבדוק סדר DOM וסדר מקלדת. עיצוב חזותי של שתי עמודות יכול להיראות נכון אך להיקרא בסדר לא הגיוני בטכנולוגיה מסייעת. גם שימוש מוגזם ב־Motion Effects, אנימציות, Carousel אוטומטי או Popup יכול ליצור חסמים שאינם נראים למעצב המשתמש בעכבר.
טפסים: נקודת המפגש הקריטית בין נגישות לפרטיות
טופס צור קשר הוא לעיתים המקום הראשון שבו האתר הופך מצפייה פסיבית לעיבוד מידע אישי. שם, כתובת דוא"ל, טלפון, תוכן פנייה, קובץ מצורף וכתובת IP יכולים להפוך לחלק מתהליך עסקי. לכן הטופס צריך להיבחן גם כממשק וגם כצינור מידע. לבחירת מערכת הטפסים עצמה יש משמעות תפעולית, ולכן הרחבנו על כך גם במדריך השוואת תוספי טפסים ל־WordPress.
מבחינת נגישות, לכל שדה צריך להיות שם ברור שמקושר אליו טכנית. Placeholder לבדו אינו תחליף טוב לתווית קבועה. שדות חובה צריכים להיות מסומנים בצורה מובנת ולא באמצעות צבע בלבד. הודעת שגיאה צריכה לומר מה הבעיה ואיך מתקנים אותה. לאחר שליחה, המשתמש צריך לקבל חיווי ברור שהפעולה הצליחה או נכשלה.
מבחינת פרטיות, עקרון טוב הוא מינימליות: אם לצורך חזרה ללקוח מספיקים שם וטלפון, צריך לשאול למה נדרש גם תאריך לידה. כל שדה נוסף מגדיל את כמות המידע שהעסק צריך לנהל ולהגן עליו. תיקון 13 עדכן את הגדרת “מידע אישי” להגדרה רחבה של נתון הנוגע לאדם מזוהה או ניתן לזיהוי, ולכן נכון להסתכל על כל תהליך האיסוף ולא רק על שדות שנראים “רגישים”.
חובת היידוע לפי סעיף 11 לחוק הגנת הפרטיות, כפי שמסבירה הרשות להגנת הפרטיות בנוסח המעודכן בעקבות תיקון 13, כוללת מידע על מטרת האיסוף; האם קיימת חובה חוקית למסור את המידע או שהמסירה תלויה ברצון ובהסכמה ומה תוצאת אי־ההסכמה; למי יימסר המידע ומטרות המסירה; זהות בעל השליטה ודרכי ההתקשרות עמו; וכן זכויות עיון ותיקון לפי החוק. לכן הודעה כללית בתחתית האתר אינה בהכרח תחליף ליידוע במקום שבו נאסף המידע.
תיקון 13 לחוק הגנת הפרטיות: מה השתנה לבעלי אתרים?
תיקון 13 הוא שינוי רחב בחוק הגנת הפרטיות, ולא “תקנת Cookies חדשה”. לפי הרשות להגנת הפרטיות, התיקון נכנס לתוקף באוגוסט 2025. הוא עדכן מונחים מרכזיים, הרחיב את כלי האכיפה, צמצם את חובת הרישום הכללית של מאגרי מידע, יצר חובת הודעה לגבי מאגרים מסוימים הכוללים מידע בעל רגישות מיוחדת בהיקף משמעותי, והוסיף חובה למינוי ממונה על הגנת הפרטיות בקטגוריות של ארגונים הקבועות בחוק.
אחד השינויים המושגיים החשובים הוא המעבר למונח “בעל שליטה במאגר מידע” — מי שקובע, לבדו או יחד עם אחר, את מטרות עיבוד המידע. “מחזיק” מתייחס לגורם חיצוני לבעל השליטה שמעבד עבורו מידע. באתר WordPress זה חשוב במיוחד, משום שהמידע כמעט אף פעם אינו נשאר במקום אחד: חברת אחסון, שירות דיוור, CRM, מערכת טפסים, שירות ענן, ספק סליקה או מערכת תמיכה עשויים להיות חלק משרשרת העיבוד.
התיקון גם מגדיר “עיבוד” בצורה רחבה הכוללת פעולות רבות על מידע אישי — קבלה, איסוף, אחסון, העתקה, עיון, גילוי, חשיפה, העברה, מסירה ומתן גישה. מבחינה מעשית, המשמעות לבעל אתר היא שמפת המידע צריכה לתאר את המסלול כולו: מהרגע שהמשתמש מקליד פרט בטופס ועד המקום שבו עובד החברה רואה אותו או ספק חיצוני מעבד אותו.
מאגרי מידע אחרי תיקון 13: רישום, הודעה ומה עדיין חל
תיקון 13 צמצם משמעותית את חובת הרישום. לפי הרשות להגנת הפרטיות, החובה נשארה בין היתר למאגרי מידע של גופים ציבוריים, בכפוף לחריגים, ולמאגר שמטרתו העיקרית איסוף מידע אישי לשם מסירתו לאחר כדרך עיסוק או בתמורה, לרבות שירותי דיוור ישיר, כאשר מתקיימים התנאים והספים הקבועים בחוק.
במקביל קיימת חובת הודעה לרשות לגבי מאגר שאינו חייב ברישום אך כולל מידע בעל רגישות מיוחדת על יותר מ־100,000 בני אדם. הרשות מסבירה כי במקרה כזה יש להודיע בתוך 30 ימים מהמועד שבו מתקיים התנאי ולהעביר, בין היתר, מסמך הגדרות מאגר בהתאם לתקנות אבטחת המידע.
לבעלי אתרים קטנים חשוב במיוחד להבין את ההבחנה: העובדה שמאגר אינו חייב ברישום אינה אומרת שהחוק “לא חל”. הרשות מדגישה שחובות אחרות לפי חוק הגנת הפרטיות ותקנותיו ממשיכות לחול גם כאשר אין חובת רישום. לכן לא נכון להשתמש בשאלה “האם המאגר רשום?” כמבחן יחיד לציות.
ממונה הגנת פרטיות (DPO): לא לכל אתר, אבל חובה שצריך לבדוק
תיקון 13 יצר חובה למינוי ממונה על הגנת הפרטיות אצל גופים וארגונים מסוימים. ביולי 2026 פרסמה הרשות להגנת הפרטיות גילוי דעת סופי שמפרט את עמדתה ביחס להיקף החובה, תפקידי הממונה, הכישורים, מעמדו בארגון ומתכונת העסקתו.
בין הקטגוריות שמונה הרשות נמצאים גופים ציבוריים, גופים שעיסוקם העיקרי כולל או כרוך בעיבוד מידע שמחייב ניטור שוטף ושיטתי של בני אדם בהיקף ניכר, וכן גופים שעיסוקם העיקרי כולל עיבוד מידע בעל רגישות מיוחדת בהיקף ניכר. החוק והנחיות הרשות כוללים פרטים נוספים, ולכן אין לקבוע לפי “גודל האתר” בלבד אם קיימת חובה.
מבחינת פרויקט WordPress, המשמעות היא שכבר בשלב האפיון כדאי לדעת מי בארגון אחראי על פרטיות. גם אם אין חובה סטטוטורית למנות DPO, צריך שיהיה בעל תפקיד שמסוגל לענות על שאלות פשוטות: אילו טפסים קיימים, לאן הם מגיעים, אילו תוספים שולחים מידע החוצה, מי יכול לצפות בפניות, מהו תהליך מחיקה ומה קורה כאשר ספק מוחלף.
Cookies, Analytics ופיקסלים: לא להתחיל מהבאנר
אחד הכשלים הנפוצים בפרויקטים הוא להתחיל מבחירת עיצוב לבאנר Cookies לפני שממפים מה נטען באתר. באנר אינו מפת מידע. לפני שמחליטים כיצד לנהל הסכמה או יידוע, צריך לזהות בפועל אילו Cookies, Local Storage, פיקסלים וסקריפטים מופעלים, מי מפעיל אותם ומה המטרה.
באתר WordPress טיפוסי יכולים לפעול Google Analytics, Google Ads, Meta Pixel, YouTube, Vimeo, Google Maps, מערכת צ'אט, כלי Heatmap, מערכת A/B Testing, תוסף אבטחה ושירותי CDN. חלקם עשויים לטעון משאבים או לבצע עיבוד דרך צדדים שלישיים. אם בעל האתר אינו יודע מה מותקן, קשה לנסח מדיניות אמינה וקשה עוד יותר להבטיח שההתנהגות בפועל תואמת למה שנכתב.
לכן סדר העבודה הוא טכני לפני שהוא גרפי: Inventory של תוספים וסקריפטים, בדיקת Network ו־Storage, מיפוי ספקים ומטרות, החלטה אילו רכיבים נחוצים, ורק לאחר מכן התאמת מנגנון יידוע/הסכמה לפי הדין והנסיבות. אתר שמצהיר דבר אחד במדיניות ומפעיל דבר אחר בקוד יוצר פער מסוכן.
ספקי צד שלישי: הבעיה אינה רק WordPress
מערכת WordPress היא לעיתים רק שכבת התצוגה. טופס יכול להישלח ל־CRM, ניוזלטר יכול לעבור למערכת דיוור, תשלום עובר לספק סליקה, מסמך נשמר בענן ושיחת צ'אט נשמרת בשירות חיצוני. לכן מפת הפרטיות צריכה לכלול גם את השירותים שאינם “בתוך האתר”.
מבחינה תפעולית כדאי לנהל רשימת ספקים מסודרת: שם הספק, סוג המידע שאליו הוא נחשף, מטרת השימוש, אופן החיבור, בעל תפקיד פנימי שאחראי עליו, ומה קורה כאשר ההתקשרות מסתיימת. הרשימה הזו מועילה גם לאבטחת מידע וגם לתחזוקה — היא מונעת מצב שבו תוסף נשאר מחובר לחשבון של עובד שעזב לפני שנתיים.
כאשר מחליפים ספק, צריך לזכור שהסרת התוסף אינה בהכרח מוחקת את המידע שכבר נמצא אצל הספק. תהליך סיום צריך לבחון ייצוא מידע נחוץ, מחיקה בהתאם למדיניות ולדין, ביטול מפתחות API, הסרת Webhooks וביטול חשבונות משתמשים.
פרטיות בלי אבטחת מידע היא מסמך בלי מנגנון
תקנות הגנת הפרטיות (אבטחת מידע) ממשיכות להיות שכבה מרכזית בניהול מאגרי מידע. הרשות להגנת הפרטיות מפרסמת מדריכים ושאלות ותשובות בנושא, ותיקון 13 הרחיב את מנגנוני האכיפה ביחס להפרות של החוק והתקנות. באתר WordPress, אבטחת מידע אינה מתחילה ונגמרת בתוסף Firewall.
יש לבחון משתמשים והרשאות, אימות דו־שלבי, עדכוני ליבה ותוספים, תוספים נטושים, גיבויים, גישה למסד הנתונים, חשבונות אחסון, מפתחות API, הרשאות FTP/SFTP, לוגים, תהליך קליטת עובד ותהליך עזיבת עובד. כל חשבון מנהל הוא יכולת גישה למידע ולכן גם רכיב פרטיות. את שכבת העדכונים, הגיבויים והבקרה השוטפת כדאי לחבר לתהליך מסודר כמו זה שמפורט במדריך תחזוקת אתר WordPress.
עיקרון הרשאות מינימליות חשוב במיוחד. מי שצריך לערוך פוסט אינו בהכרח צריך להיות Administrator. מי שמטפל בלידים אינו בהכרח צריך גישה להגדרות תוספים. ככל שמצמצמים הרשאות, מצמצמים גם את שטח הפגיעה האפשרי במקרה של טעות, גניבת סיסמה או שימוש לא מורשה.
כמה זמן שומרים פניות וטפסים?
WordPress ותוספי טפסים נוטים לשמור מידע “עד שמישהו ימחק”. זו אינה מדיניות. עסק צריך לדעת אילו פניות נשמרות באתר, אילו עוברות לדוא"ל או CRM, ומהו הצורך העסקי בשמירה. אם ליד מלפני חמש שנים אינו נדרש עוד, עצם קיומו מגדיל את מאגר המידע ואת הנזק האפשרי מאירוע אבטחה.
מדיניות שמירה טובה אינה מספר אחיד לכל דבר. חשבוניות, פניות שירות, לידים, מועמדים לעבודה, חשבונות משתמשים ונתוני אנליטיקה עשויים להיות כפופים לצרכים ולחובות שונים. לכן מגדירים קטגוריות מידע, מטרות, תקופות שמירה ותהליך מחיקה או אנונימיזציה בהתאם לצורך ולדין.
ב־WordPress כדאי לבדוק גם עותקים “נסתרים”: גיבויים, ייצוא CSV, תיבות דוא"ל, סביבת Staging, קבצי לוג ותוספי Forms ששומרים Entries. מחיקה מהמסך הראשי של האתר אינה בהכרח מחיקה מכל המערכות.
הצהרת נגישות: מסמך חי, לא טקסט גנרי
נציבות שוויון זכויות לאנשים עם מוגבלות מפרסמת מדריך ייעודי להצהרת נגישות ולהסדרי נגישות. לפי המדריך, קיימות דרישות לפרסום הצהרת נגישות ומידע על הסדרי הנגישות בארגון במקרים הרלוונטיים, והנציבות ממליצה לרכז את המידע במקום אחד בצורה ברורה.
הצהרה טובה צריכה לתאר את מצב האתר באופן אמין, את ההתאמות שבוצעו, מגבלות ידועות אם קיימות, דרכי פנייה בנושא נגישות ופרטים רלוונטיים נוספים בהתאם לחובות החלות. העתקה של הצהרה מאתר אחר היא בעייתית במיוחד כאשר היא מצהירה על בדיקות או טכנולוגיות שלא בוצעו בפועל.
גם כאן יש קשר לתחזוקה. אתר משתנה: עולים מאמרים, מותקנים תוספים, מוחלף טופס, מתווסף Popup או נבנה אזור אישי. הצהרת נגישות שנכתבה ביום ההשקה אינה מספיקה אם האתר השתנה מהותית מאז.
מדיניות פרטיות: לכתוב לפי האתר האמיתי
מדיניות פרטיות צריכה לשקף את תהליכי המידע בפועל. רשימה גנרית של “אנו עשויים לאסוף מידע טכני” אינה תחליף למיפוי. לפני כתיבה יש לאסוף תשובות: אילו טפסים קיימים? האם יש חשבון משתמש? האם קיימת רכישה? אילו כלי אנליטיקה ופרסום פועלים? האם יש דיוור? האם האתר שומר IP? אילו ספקים מקבלים מידע? מהן דרכי יצירת הקשר בנושאי פרטיות?
חשוב להפריד בין המדיניות הכללית לבין יידוע בזמן האיסוף. משתמש שממלא טופס לא צריך לנחש מתוך מסמך ארוך מה מטרת השדה. בהתאם להוראות החלות, ייתכן שנדרש מידע ברור בזמן הפנייה לקבלת המידע. תכנון נכון משלב שכבת מידע קצרה ליד הטופס וקישור למדיניות מלאה.
תהליך עבודה מומלץ: 10 שלבים לאתר WordPress נגיש ופרטי יותר
רושמים טפסים, רכישות, הרשמות, אזורים אישיים, מסמכים, וידאו, Popups וכל רכיב אינטראקטיבי.
לכל תהליך מגדירים אילו נתונים נאספים, למה, איפה נשמרים ומי מקבל גישה.
אחסון, CRM, דיוור, אנליטיקה, סליקה, צ'אט, CDN וכל שירות צד שלישי.
כותרות, Landmarks, קישורים, Labels, Alt, שפה וסדר קריאה.
עוברים על כל האתר ללא עכבר: תפריט, חיפוש, טפסים, מודאלים, Accordion ופעולות מרכזיות.
צבע, הגדלת טקסט, Reflow, Focus וקריאות במסכים קטנים.
מצמצמים שדות, משפרים Labels ושגיאות, ומוודאים שהיידוע מתאים לתהליך האיסוף.
מנהל, עורך, ספקים חיצוניים, 2FA, עדכונים, גיבויים ומפתחות API.
מדיניות פרטיות, הצהרת נגישות ומידע נדרש נוסף צריכים לשקף את המצב בפועל.
מגדירים מי בודק שינויי אתר, תוספים חדשים, ספקים חדשים ותוכן חדש לאחר ההשקה.
טבלת אחריות: מי צריך לטפל במה?
| נושא | בונה האתר | בעל העסק | ייעוץ מקצועי |
|---|---|---|---|
| מבנה כותרות, Labels, Focus ו־HTML | יישום ובדיקות | אישור תהליך | בדיקת נגישות לפי הצורך |
| מטרות איסוף מידע | ממפה את הטפסים | מגדיר צורך עסקי | משפטי/פרטיות לפי הצורך |
| תוספי צד שלישי | מתעד ומטמיע | מאשר ספקים | בחינת הסדרים לפי הצורך |
| הרשאות WordPress | מגדיר טכנית | קובע מי צריך גישה | אבטחת מידע במערכות מורכבות |
| מדיניות פרטיות | מספק מיפוי טכני | מספק תהליכים עסקיים | ניסוח/בדיקה משפטית |
| הצהרת נגישות | מספק מצב טכני | מספק הסדרי שירות | מורשה נגישות/ייעוץ לפי הנדרש |
12 טעויות נפוצות שכדאי למנוע
1. להניח שתוסף נגישות הופך את האתר לנגיש. הוא יכול להוסיף פונקציות, אך אינו מתקן אוטומטית סמנטיקה, סדר מקלדת, Labels או תוכן לא ברור.
2. להשתמש ב־Placeholder במקום Label. ברגע שהמשתמש מתחיל להקליד, ההנחיה נעלמת, ולעיתים הקשר הטכני לקורא מסך אינו מספק.
3. לכתוב Alt לכל תמונה בצורה אוטומטית. Alt צריך להתאים לתפקיד התמונה בהקשר, ולא להיות רשימת מילות מפתח.
4. להוסיף Popup שלא ניתן לסגור במקלדת. זה עלול לחסום את כל האתר למשתמשים מסוימים.
5. להעתיק מדיניות פרטיות מאתר אחר. ספקים, טפסים ומטרות איסוף שונים מאתר לאתר.
6. לשמור כל Entry לנצח. תוסף טפסים אינו ארכיון אוטומטי. יש לקבוע צורך ותקופת שמירה.
7. להשאיר משתמשי Administrator ישנים. הרשאה שאינה נדרשת היא סיכון מיותר.
8. להתקין Analytics בלי לתעד. כל כלי חדש משנה את מפת המידע ואת התנהגות האתר.
9. לחשוב שאין חוק כי המאגר אינו חייב ברישום. צמצום חובת הרישום אינו מבטל את יתר החובות.
10. להתעלם מסביבת Staging. העתק של האתר יכול לכלול מידע אישי אמיתי ולהישאר מוגן פחות מהאתר הראשי.
11. לבדוק נגישות רק עם כלי אוטומטי. כלים אוטומטיים מועילים, אך אינם מחליפים בדיקת מקלדת, תוכן ואינטראקציות.
12. לסיים את הטיפול ביום ההשקה. נגישות ופרטיות הן תהליכי תחזוקה. כל שינוי משמעותי יכול להוסיף חסם או זרימת מידע חדשה.
צ'ק־ליסט לפני השקה
| בדיקה | מה צריך להיות ברור | סטטוס |
|---|---|---|
| כותרות | היררכיה לוגית ללא שימוש בכותרת לצורך עיצוב בלבד | □ |
| מקלדת | כל הפעולות המרכזיות זמינות ופוקוס נראה | □ |
| טפסים | Labels, שדות חובה, שגיאות וחיווי הצלחה | □ |
| תמונות | Alt לפי תפקיד התמונה | □ |
| ספקים | רשימה מעודכנת של כל שירות שמקבל מידע | □ |
| יידוע | המידע הנדרש מופיע בנקודת האיסוף בהתאם לצורך | □ |
| הרשאות | רק משתמשים פעילים עם רמת הרשאה נדרשת | □ |
| גיבוי | גיבוי ושחזור נבדקו | □ |
| מדיניות פרטיות | משקפת את האתר והספקים בפועל | □ |
| הצהרת נגישות | מעודכנת בהתאם למצב ולחובות החלות | □ |
מה עושים אחרי ההשקה?
האתר אינו מוצר קפוא. מנהל שיווק מוסיף פיקסל, מעצב מעלה Landing Page, ספק מחליף טופס, מנהל תוכן מעלה PDF, ותוסף מקבל עדכון שמשנה את ה־HTML. לכן כדאי להכניס נגישות ופרטיות לתהליך Change Management קטן: לפני רכיב חדש שואלים מה הוא עושה, איזה מידע הוא אוסף, האם הוא נגיש, מי הספק ומה צריך לעדכן. כאשר מדובר בפונקציה ייחודית, כדאי גם להחליט אם נכון להוסיף עוד תוסף מדף או לפתח פתרון ממוקד — נושא שמורחב במדריך תוסף מותאם מול תוסף מוכן.
בדיקה רבעונית יכולה לכלול מעבר על משתמשי WordPress, תוספים פעילים, אינטגרציות, טפסים, Cookies, קישורי מדיניות, עמוד הצהרת נגישות ומספר עמודים מייצגים במקלדת. באתר מסחר או מערכת עם שינויים תכופים ייתכן שיידרש תהליך תכוף יותר. אם מדובר בחנות, יש להרחיב את הבדיקה גם למסלול רכישה, סליקה וחשבוניות; ראו WooCommerce בישראל.
כדאי גם לתעד החלטות. כאשר מחליפים תוסף Forms, רושמים למה, לאן המידע עובר ומה נעשה בנתונים הישנים. כאשר מוסיפים שירות Analytics, רושמים מי אישר ומה המטרה. התיעוד מקל על תחזוקה, על מעבר בין ספקים ועל טיפול באירוע.
השוואת תוספי אבטחה ל־WordPress · השוואת תוספי טפסים ל־WordPress · תחזוקת אתר WordPress · לכל 10 מדריכי WordPress
שאלות נפוצות
1. האם תוסף נגישות מספיק כדי להפוך אתר WordPress לנגיש?
לא. תוסף יכול להוסיף פונקציות מסוימות, אך נגישות תלויה גם במבנה HTML, הפעלה במקלדת, ניגודיות, טפסים, טקסט חלופי, מדיה, סדר קריאה ותוכן. יש לבדוק את האתר עצמו ולא רק את קיומו של תוסף.
2. האם כל אתר בישראל חייב לעמוד בדיוק באותן דרישות נגישות?
לא בהכרח. החובות תלויות בהגדרות הדין, סוג השירות, זהות נותן השירות וחריגים או פטורים רלוונטיים. נציבות שוויון זכויות מפרסמת מדריכים בנושא, ובמקרה של ספק יש לבדוק את המצב הספציפי.
3. מה תיקון 13 שינה לגבי מאגרי מידע?
בין היתר, התיקון עדכן הגדרות מרכזיות, צמצם משמעותית את חובת הרישום הכללית, יצר חובת הודעה ביחס למאגרים מסוימים עם מידע בעל רגישות מיוחדת בהיקף משמעותי, הרחיב כלי אכיפה והוסיף חובת DPO לקטגוריות מסוימות של ארגונים.
4. אם מאגר המידע שלי אינו חייב ברישום, האם חוק הגנת הפרטיות לא חל?
לא. הרשות להגנת הפרטיות מדגישה שאי־חובת רישום אינה פוטרת מחובות אחרות לפי החוק והתקנות.
5. האם כל עסק צריך למנות ממונה הגנת פרטיות?
לא. החובה חלה על קטגוריות הקבועות בחוק, ובהן סוגים מסוימים של גופים ציבוריים וארגונים שעיבוד המידע אצלם עומד בתנאים הקבועים. יש לבחון את פעילות הארגון ולא את גודל האתר בלבד.
6. מה צריך להופיע ליד טופס צור קשר?
הנוסח תלוי בתהליך ובדין החל. סעיף 11 לחוק, בנוסחו המעודכן, כולל רכיבי יידוע בנוגע למטרת האיסוף, חובה או רצון למסור ותוצאת אי־הסכמה, מסירת מידע לאחרים, זהות בעל השליטה ודרכי התקשרות וזכויות עיון ותיקון.
7. האם באנר Cookies פותר את נושא הפרטיות?
לא. לפני באנר צריך לדעת אילו טכנולוגיות פועלות, אילו נתונים הן מעבדות, מי הספקים ומה מטרת השימוש. המנגנון צריך להתאים להתנהגות האמיתית של האתר ולדרישות החלות.
8. האם צריך לבדוק נגישות בכל עדכון תוכן?
לא כל שינוי דורש פרויקט מלא, אבל תוכן חדש צריך לעמוד בכללי העבודה: כותרות נכונות, Alt מתאים, קישורים ברורים, מסמכים נגישים ורכיבים שניתנים להפעלה. שינוי תבנית או רכיב אינטראקטיבי מצדיק בדיקה רחבה יותר.
9. האם CAPTCHA עלול ליצור בעיית נגישות?
כן, בהתאם לסוג וליישום. מנגנון שמחייב משימה חזותית או אינטראקציה שאינה נגישה עלול לחסום משתמשים. יש לבחור פתרון שמאזן אבטחה, פרטיות ונגישות ולבדוק אותו בפועל.
10. מי אחראי על פרטיות ונגישות — בונה האתר או בעל העסק?
האחריות אינה נפתרת בהעברה לספק טכני. בונה האתר אחראי ליישום שבתחום עבודתו, בעוד הארגון צריך להגדיר תהליכים, מטרות, ספקים והרשאות ולקבל ייעוץ מקצועי כשנדרש. נכון להגדיר אחריות מראש בהסכם ובתהליך העבודה.
מקורות מקצועיים ורשמיים
1. הרשות להגנת הפרטיות – שאלות ותשובות על תיקון 13: הגדרות, רישום, הודעה, DPO ואכיפה. למקור הרשמי
2. הרשות להגנת הפרטיות – חובת יידוע באיסוף ושימוש במידע אישי: נוסח מעודכן בעקבות תיקון 13. למסמך הרשמי
3. הרשות להגנת הפרטיות – מינוי ממונה הגנת פרטיות: גילוי דעת סופי מיולי 2026. למקור הרשמי
4. נציבות שוויון זכויות לאנשים עם מוגבלות – נגישות אתרי אינטרנט: מידע על החובות, שירות לציבור ופטורים. למקור הרשמי
5. נציבות שוויון זכויות – הצהרת נגישות: מדריך לפרסום הצהרה והסדרי נגישות. למקור הרשמי
6. W3C – WCAG 2 Overview: ארבעת עקרונות הנגישות וקריטריוני ההצלחה. למקור הרשמי
נגישות ופרטיות מתחילות באפיון
כשבונים את הטפסים, ההרשאות, הספקים והמבנה נכון מההתחלה — האתר קל יותר לתחזוקה, לבדיקה ולשיפור גם אחרי ההשקה.