יש רגע שחוזר על עצמו אצל כל לקוח שלנו: מייל מעורך דין, או סתם הודעה בוואטסאפ מחבר, ובה המשפט "האתר שלך לא נגיש, אתה חשוף לתביעה". מה שקורה אחר כך כמעט תמיד זהה — מתקינים תוסף נגישות, מדביקים ווידג'ט כתום בפינה, נושמים לרווחה. שלושה חודשים אחר כך מגיעה דרישה משפטית אמיתית, והווידג'ט לא עוזר.
נגישות אתרים תקן 5568 היא לא בעיה משפטית. היא בעיה הנדסית שיש לה גם תוצאות משפטיות. כשמתייחסים אליה כאל בעיה הנדסית — פותרים אותה פעם אחת, נכון, והיא נשארת פתורה. כשמתייחסים אליה כאל בעיה משפטית — קונים ביטוח שלא מכסה כלום.
המאמר הזה הוא המפרט הטכני שהיינו רוצים שמישהו ייתן לנו לפני עשר שנים: מה החוק באמת דורש, מה הווידג'ט לא פותר, מה בדיוק לבדוק, ואיך לעצב נגיש בלי להרוס את העיצוב.
מה החוק בישראל באמת דורש
המסגרת החוקית פשוטה יותר ממה שנדמה. חוק שוויון זכויות לאנשים עם מוגבלות, תשנ"ח-1998, מחייב נגישות שירות. תקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), תשע"ג-2013, מתרגמות את זה לאינטרנט בתקנה 35: מי שנותן שירות לציבור ומפעיל אתר אינטרנט — האתר צריך להיות נגיש לפי התקן הישראלי ת"י 5568.
ת"י 5568 עצמו אינו מסמך ישראלי מקורי. הוא אימוץ של הנחיות WCAG 2.0 של ה-W3C ברמת התאמה AA, עם התאמות מקומיות. זו נקודה קריטית: המשמעות היא שכל התיעוד, הכלים והמדריכים הבינלאומיים של WCAG רלוונטיים ישירות לעבודה שלך. אתה לא צריך לפענח תקן סודי — אתה צריך ליישם סטנדרט שיש עליו אלפי עמודי דוקומנטציה חינמית.
המועד להנגשת אתרים קיימים חלף באוקטובר 2017. אתר חדש נדרש להיות נגיש ממועד עלייתו לאוויר. אין תקופת חסד לאתרים שעולים היום.
התקנות כוללות פטור לעוסק שמחזור העסקאות השנתי שלו אינו עולה על 100,000 ש"ח. בפועל זה פטור שמכסה עסק שבקושי קיים. חשוב מזה: הפטור הוא על חובת ההנגשה המלאה — הוא לא פוטר מהחובה לאפשר קבלת השירות בדרך חלופית נגישה. בנוסף, ארגונים מסוימים מחויבים במינוי רכז נגישות, וזו חובה נפרדת שלא קשורה לקוד של האתר בכלל. אם בנית תוכנית משפטית סביב הפטור — בנית על חול.
מה שכן נדרש מעבר לקוד: הצהרת נגישות נגישה ומאותרת בקלות באתר, שמפרטת את מצב הנגישות, את דרכי ההתקשרות לפניות נגישות ואת ההתאמות החלופיות הקיימות. הצהרה שמוסתרת בפוטר בגופן 10 אפור על לבן — היא בעצמה כשל נגישות.
בצד האכיפה: נציבות שוויון זכויות לאנשים עם מוגבלות במשרד המשפטים מוסמכת לפעול, אבל רוב הלחץ האמיתי מגיע מכיוון אחר. החוק מאפשר פיצוי ללא הוכחת נזק בסכום של עד 50,000 ש"ח, והנושא נכלל בעילות לתובענה ייצוגית. זה מה שיצר את התעשייה הישראלית של מכתבי דרישה בסדרות.
נגישות היא לא שכבה שמורחים על אתר גמור. היא החלטה ארכיטקטונית שמתקבלת ביום הראשון של הפרויקט.— RAMS Studio
מה תוסף נגישות לא פותר — ולמה הוא לפעמים מזיק
ווידג'ט הנגישות מבטיח שלוש קטגוריות של פתרון: התאמות תצוגה למשתמש, תיקון אוטומטי של קוד לקוי, וכיסוי משפטי. הראשונה עובדת חלקית. השנייה עובדת רע. השלישית היא פיקציה.
מה הווידג'ט כן עושה טוב: הגדלת טקסט, ניגודיות גבוהה, עצירת אנימציות, הדגשת קישורים, שינוי מרווחים. אלה התאמות תצוגה לגיטימיות שעוזרות למשתמשים עם לקות ראייה קלה או רגישות לתנועה. אין שום בעיה בלהתקין ווידג'ט לצורך הזה.
מה הוא לא עושה: הוא לא הופך טופס בלי labels לטופס נגיש. הוא לא מייצר טקסט חלופי משמעותי לתמונה — במקרה הטוב הוא מנחש. הוא לא מתקן היררכיית כותרות שבורה, לא מוסיף מיקוד מקלדת לרכיב שנבנה מ-div, לא הופך קרוסלה לעבירה בטאב, ולא מייצר הודעות שגיאה שקורא מסך מכריז עליהן.
וכאן הנקודה החדה: רוב המשתמשים בקוראי מסך לא מפעילים את הווידג'ט בכלל. הם מגיעים עם NVDA או VoiceOver שכבר מוגדרים לפי ההעדפות שלהם, ופוגשים את ה-DOM האמיתי של האתר. שכבת התיקון שרצה ב-JavaScript אחרי טעינת הדף לא רק שלא עוזרת להם — לפעמים היא מתנגשת עם הכלי שהם משתמשים בו ומחמירה את המצב. ארגוני נגישות בעולם ומאות מומחי נגישות חתמו על עמדה מפורשת נגד הצגת שכבות תיקון אוטומטיות כפתרון תאימות.
כלי סריקה כמו axe, Lighthouse או WAVE מזהים בעיקר כשלים בינאריים בקוד: alt חסר, ניגודיות מתחת ליחס, label לא מקושר. הם לא יכולים לשפוט אם ה-alt נכון, אם סדר הקריאה הגיוני, אם שם הקישור מובן מחוץ להקשר, או אם ניתן להשלים תהליך רכישה שלם במקלדת. סקר WebAIM Million מצא כשלי WCAG שניתנים לזיהוי אוטומטי ביותר מ-95% מדפי הבית שנבדקו — וזה רק מה שמכונה יכולה לתפוס. הפער בין "עבר סריקה" ל"נגיש" הוא בדיוק המקום שבו נולדות תביעות.
הצ'קליסט שאנחנו עוברים בכל פרויקט
זה לא צ'קליסט מלא של 5568 — זה סדר עדיפויות אמיתי. מה שנמצא למעלה תופס את רוב הכשלים ברוב האתרים הישראליים.
מבנה וסמנטיקה
- היררכיית כותרות אחת ורציפה: H1 בודד, ללא דילוגים בין רמות. כותרות הן מבנה, לא גודל פונט.
- ציוני דרך:
header,nav,main,footer— אלמנטים אמיתיים, לא div עם קלאס. lang="he"ו-dir="rtl"ברמת ה-HTML. קטעים באנגלית מסומנים ב-lang="en"— אחרת קורא מסך יקרא אותם במבטא עברי בלתי מובן.- קישור "דלג לתוכן" ראשון בסדר הטאב, מוסתר חזותית עד למיקוד.
מקלדת ומיקוד
- כל תהליך מרכזי — חיפוש, טופס, קופה, תפריט — ניתן להשלמה במקלדת בלבד. בלי עכבר. תבדוק בעצמך, זה לוקח שלוש דקות.
- מחוון מיקוד גלוי וברור. אם מצאת
outline: noneב-CSS בלי חלופה — מצאת כשל. - סדר טאב תואם את הסדר החזותי. אל תתקן את זה ב-
tabindexחיובי, תקן את סדר ה-DOM. - מודאלים: לכידת מיקוד בתוך המודאל, סגירה ב-Escape, החזרת מיקוד לאלמנט שפתח אותו.
טקסט וצבע
- ניגודיות 4.5:1 לטקסט רגיל, 3:1 לטקסט גדול ולרכיבי ממשק. זה כולל placeholder, טקסט משני וטקסט על תמונות.
- שום מידע לא מועבר בצבע בלבד. שדה שגיאה אדום צריך גם אייקון וגם טקסט.
- הטקסט נשאר קריא ופונקציונלי בהגדלה ל-200%, ובריווח טקסט מוגדל.
תמונות, מדיה וטפסים
- alt שמתאר תפקיד, לא פיקסלים. תמונה דקורטיבית מקבלת
alt=""— לא "תמונה". - וידאו: כתוביות. שמע: תמליל. אין קיצורי דרך כאן.
- כל שדה עם
labelמקושר. placeholder הוא לא label. - שגיאות: טקסט מפורש שמסביר מה לתקן, מקושר לשדה, ומוכרז ל-assistive tech דרך
aria-live. - אין autoplay של אודיו או תנועה שלא ניתן לעצור.
תיעוד
- הצהרת נגישות מעודכנת, נגישה, עם דרך התקשרות שעובדת באמת.
- דוח בדיקה מתועד עם תאריך. אם יגיעו אליך — מסמך שמראה תהליך מתמשך שווה יותר מווידג'ט.
אנחנו בודקים אתרים מול 5568 בבדיקה כפולה — סריקה אוטומטית ובדיקת מקלדת וקורא מסך ידנית. מקבלים דוח עם סדר עדיפויות, לא רשימת אזהרות.
עיצוב נגיש שגם יפה — זו לא סתירה
ההנחה שנגישות מכריחה עיצוב משעמם היא תוצאה של יישום גרוע, לא של התקן. הדרישות של 5568 מגדירות רצפה, לא תקרה. הן אומרות מה חייב להיות ברור — לא מה אסור שיהיה יפה.
ניגודיות היא מגבלה, וזה טוב. אפור בהיר על לבן לא נראה מעודן — הוא נראה מטושטש גם למשתמש בן 25 בשמש. עבודה בתוך מגבלת 4.5:1 מכריחה היררכיה שמבוססת על גודל, משקל ומרווח במקום על שחיקת צבע. זו הגדרת עיצוב טובה, לא פשרה.
מחוון מיקוד הוא הזדמנות עיצובית. את ה-outline הדיפולטיבי של הדפדפן אף אחד לא אוהב — אז תעצב אחד. :focus-visible עם טבעת בצבע המותג, offset נקי ומעבר של 0.2 שנייה נראה מכוון ומקצועי. אתה מקבל נגישות ודטייל עיצובי באותה שורת CSS.
אנימציה נשארת — עם כיבוד העדפות. prefers-reduced-motion הוא שאילתת מדיה בת שורה אחת. המשתמשים שמבקשים פחות תנועה מקבלים פחות תנועה; כל השאר מקבלים את המעברים החלקים במלואם. אין צורך להוריד אנימציות מהאתר — צריך להתנות אותן.
רכיבים מובנים לפני רכיבים מומצאים. button אמיתי מגיע עם מיקוד, הפעלה ברווח ובאנטר, ותפקיד מוכרז — חינם. div עם onClick מחייב לשחזר את כל זה ב-ARIA ידנית, וברוב המקרים מישהו ישכח משהו. הכלל שלנו פשוט: אלמנט מובנה תמיד, אלא אם יש סיבה טכנית מפורשת לא.
מהניסיון שלנו, אתר שנבנה נגיש מהיום הראשון עולה בין 5% ל-10% יותר בזמן פיתוח. אתר שמנגישים בדיעבד עולה לפעמים 40% מעלות הבנייה המקורית, כי חלק מהרכיבים צריכים להיבנות מחדש. ההפרש הזה הוא כל הסיפור.
ויש גם צד שני למשוואה: HTML סמנטי, היררכיית כותרות נכונה, טקסטים חלופיים וסדר קריאה הגיוני הם בדיוק מה שמנועי חיפוש ומודלי שפה קוראים. נגישות טובה היא SEO טכני טוב. לא במקרה — שני הצדדים קוראים את אותו DOM.
השורה התחתונה
אל תקנה ווידג'ט ותקווה. אל תשכור עורך דין לפני שבדקת אם יש בעיה. תעשה שלושה דברים: תפתח את האתר, תנסה להשלים את התהליך המרכזי שלו במקלדת בלבד, ותראה מה קורה. תריץ סריקה אוטומטית ותקן את הכשלים הבינאריים. ותכתוב הצהרת נגישות אמיתית עם כתובת שמישהו קורא.
אם עברת את שלושת אלה — אתה במקום טוב יותר מ-90% מהאתרים בישראל. אם לא — אתה יודע עכשיו מה לתקן, ובאיזה סדר.
אנחנו מהנדסים אתרים שעומדים ב-5568 מהשורה הראשונה של הקוד — בלי ווידג'טים, בלי פשרות ויזואליות, עם תיעוד שמחזיק מול דרישה משפטית. תגיד לנו מה יש לך, נגיד לך מה חסר.
