הנגשת אתר בקוד ולא בתוסף: למה סרגל נגישות לא מספיק ומה כן עושים

בקצרה (TL;DR): לפי נציבות שוויון זכויות לאנשים עם מוגבלות, אתר נגיש הוא אתר שעומד בתקנות הנגישות לשירות ובתקן הישראלי ת"י 5568, המבוסס על WCAG 2.0 ברמה AA. סרגל נגישות הוא לא חובה, והנציבות מדגישה שהוא אינו פוטר מעמידה בדרישות התקנות והתקן. הסיבה פשוטה: חלק גדול מהדרישות נוגע למבנה הקוד, כמו כותרות, תוויות בטפסים, סדר מקלדת והתאמה לקורא מסך, ותוסף שיושב מעל האתר לא יכול לשכתב אותו באופן אמין. הדרך הנכונה היא לתקן את האתר עצמו, לבדוק אותו בכלים אוטומטיים וגם ידנית, לפרסם הצהרת נגישות ולתחזק. המאמר אינו ייעוץ משפטי.

מי שמחפש הנגשת אתר נתקל בהצעות ל"נגישות בהתקנה של דקה": שורת קוד אחת וכפתור כחול בפינה. זה מפתה, אבל הוא לא מה שהרגולטור מתאר כהנגשה. המדריך הזה מפרט מה אומרים המקורות הרשמיים, מה עושים בקוד, איך בודקים ומתי תוסף עדיין שימושי. את התמונה המשפטית הרחבה יותר, כולל הסיכון מתביעות, כיסינו במדריך נגישות אתרים בישראל, ואת שאלת העלות במאמר על עלות הנגשת אתר. בגילוי נאות, Aiterra מבצעת הנגשות באתרים, ולכן אנחנו צד מעוניין.

מה המקורות הרשמיים אומרים

הדברים הבאים לקוחים ממדריכי הנציבות באתר gov.il. מומלץ לקרוא אותם במלואם:

• הבסיס. אתר אינטרנט נגיש הוא אתר העומד בדרישות סימן ג' לפרק ה' בתקנות שוויון זכויות לאנשים עם מוגבלות (התאמות נגישות לשירות), התשע"ג-2013, ובתקן ישראלי 5568, המבוסס על מסמך ההנחיות WCAG 2.0 ברמה AA (שאלות נפוצות, נציבות שוויון זכויות).
• סרגל נגישות. לפי הנציבות, שילוב סרגל נגישות "אינו פוטר" מחובת העמידה בכל דרישות התקנות והתקן ומביצוע כל התאמות הנגישות הנדרשות, ו"אין כל חובה" להשתמש בסרגל כדי להגיע לרמת ההנגשה הנדרשת (אותו מקור).
• הצהרת נגישות. חובה לפרסם באתר הצהרה שמפרטת את התאמות הנגישות שבוצעו ואת פרטי רכז הנגישות. הצהרה אינה "סוף פסוק": הנציבות או גורם אחר רשאים לבדוק את האתר, ואף להגיש תביעה במקרים המתאימים (אותו מקור; ראו גם מדריך הצהרת נגישות).
• אין תו תקן. הנציבות אינה נותנת תו נגישות לאתרים, ויש לתחזק את רמת הנגישות דרך קבע.
• פלטפורמה. לפי הנציבות, אסור לבנות אתר חדש על פלטפורמה שאינה מאפשרת הנגשה מלאה לפי התקן.
• בדיקה. רוב הבדיקה מתבצעת על ידי אנשים, וכשליש ממנה בלבד אפשר לבצע בכלים אוטומטיים.

הנקודה האחרונה חשובה במיוחד: אם רק כשליש מהבדיקה אוטומטי, כלי שפועל אוטומטית ולא מבין הקשר לא יכול לבדוק או לתקן את כל השאר.

למה תוסף לבד לא מספיק

תוסף נגישות (overlay) הוא סקריפט שנטען על האתר ומוסיף שכבה: סרגל להגדלת טקסט, שינוי ניגודיות, הדגשת קישורים, ולעיתים ניסיון תיקון אוטומטי של הקוד. הוא יכול לעזור למשתמשים מסוימים, אבל יש לו מגבלות מובנות:

• הוא לא מתקן את המקור. כותרות שלא בנויות בסדר הגיוני, טופס ללא תוויות או כפתור שאינו נגיש למקלדת נשארים כמו שהם בקוד שקורא המסך מקבל.
• הוא לא מבין משמעות. טקסט חלופי טוב לתמונה צריך לתאר את תפקידה בדף, ותיאור שנוצר אוטומטית לא יודע אם התמונה דקורטיבית או מעבירה מידע.
• הוא לא מכסה תוכן שאינו בדף. מסמכי PDF, סרטונים בלי כתוביות ותוכן חדש שנוסף אחרי ההתקנה דורשים טיפול נפרד.
• הוא לא תמיד מתיישב עם טכנולוגיות מסייעות. משתמש בקורא מסך מגדיר את ההעדפות שלו בעצמו, ושכבה נוספת עלולה להפריע לו במקום לעזור, ולכן חשוב לבדוק זאת.
• הוא לא מחליף בדיקה ולא הצהרה. גם עם תוסף צריך להצהיר ולתחזק.

כלומר התוסף הוא תוספת אופציונלית, והעבודה האמיתית נעשית באתר.

מה כוללים תיקוני נגישות בקוד

אלה התחומים שאנחנו בודקים ומתקנים כדי להתאים אתר ל-WCAG 2.0 AA:

1. מבנה סמנטי. כותרת H1 אחת, H2 ו-H3 בסדר היררכי, ואזורים מסומנים (header, nav, main, footer). כך קורא מסך יכול לדלג בין חלקים בדף.
2. ניווט מקלדת. כל קישור, כפתור, תפריט וחלון קופץ ניתנים להפעלה ב-Tab, Enter וחיצים. סדר המעבר הגיוני, והמוקד גלוי תמיד.
3. טפסים. לכל שדה תווית (label) מקושרת, הודעות שגיאה ברורות שמוקראות, ושדות חובה מסומנים גם בטקסט ולא רק בצבע.
4. טקסט חלופי. תמונות מידע מקבלות תיאור קצר ומשמעותי, ותמונות דקורטיביות מסומנות כך שקורא המסך ידלג עליהן.
5. ניגודיות וצבע. יחס ניגודיות מספק בין טקסט לרקע לפי WCAG, ואי הסתמכות על צבע בלבד להעברת מידע.
6. תוכן דינמי. תפריטים נפתחים, קרוסלות, חלונות ואקורדיונים עם תכונות ARIA נכונות ושליטה במקלדת, כולל אפשרות לעצור תנועה אוטומטית.
7. מדיה. כתוביות לסרטונים ותמלול לתוכן קולי.
8. שפה וכיוון. הגדרת שפת הדף (lang="he") וכיוון RTL תקין, וסימון קטעים באנגלית בתוך טקסט עברי, כדי שקורא המסך יבטא נכון.
9. ריענון ותוכן חדש. תהליך שמוודא שעמוד או מוצר חדש שמתווסף לא שובר את הנגישות.

איך בודקים נגישות

הנציבות מפנה לטופס בדיקה לאתרי אינטרנט, והבדיקה משלבת כלים אוטומטיים עם בדיקה ידנית. אפשר להתחיל בעצמכם:

• מקלדת בלבד. הניחו את העכבר בצד ועברו על דף הבית ועל תהליך הרכישה או יצירת הקשר. האם אפשר להגיע לכל פעולה, והאם רואים איפה המוקד?
• כלי אוטומטי. הריצו Lighthouse או axe כדי לאתר בעיות שגרתיות. הם מצילים זמן, אבל כלי אוטומטי מוצא רק חלק מהבעיות.
• קורא מסך. הנציבות מציינת שהקוראים הנפוצים הם JAWS ו-NVDA, ובטלפונים VoiceOver ו-TalkBack, ושהדרישה היא לבדוק לפחות אחד מהם (רצוי כולם) ולפרט בהצהרה לאיזה קוראי מסך האתר נגיש.
• הגדלה. הגדילו את הטקסט בדפדפן ובדקו שהתוכן לא נחתך.
• טופס עם שגיאות. מלאו טופס בכוונה לא נכון ובדקו שהודעות השגיאה ברורות, מקושרות לשדה הנכון ומוקראות.
• הגדלה והתאמה לנייד. בדקו גם במסך קטן ובטלפון, כי רוב הגלישה היום נעשית שם.

תוסף מול תיקון בקוד: טבלת השוואה

היבט	תוסף נגישות (overlay)	תיקון בקוד
מה נעשה	שכבה שנטענת מעל האתר ומאפשרת התאמות תצוגה	שינוי ב-HTML, CSS וב-JavaScript של האתר
מבנה כותרות וטפסים	נשאר כפי שהוא, אלא אם התוסף מנחש תיקון	מתוקן במקור
ניווט מקלדת וחלונות קופצים	לרוב לא משתנה	נבנה ונבדק
קורא מסך	תלוי באיכות הקוד המקורי	נבדק ומתועד בהצהרה
דרישת הרגולטור	לפי הנציבות אינו פוטר מעמידה בתקן	זו הדרך לעמוד בתקן
תוכן חדש	לא מבטיח נגישות שלו	נכנס לתהליך עבודה קבוע
עלות	לרוב מנוי קבוע	עבודה חד-פעמית ואחר כך תחזוקה
שימושיות למשתמשים	יכול להוסיף נוחות בהגדלה וניגודיות	מועיל לכל המשתמשים והמכשירים

רשימת בדיקה: 10 צעדים להנגשה נכונה

1. הגדירו מי חייב. בדקו אם האתר נותן שירות לציבור בישראל. לפי הנציבות, גם אתר בחו"ל שמיועד לציבור בישראל חייב, ואתר שמשרת רק חברות נחשב גם הוא.
2. בדקו את הפלטפורמה. ודאו שהמערכת שבה האתר בנוי מאפשרת הנגשה מלאה.
3. הריצו בדיקה ראשונית במקלדת ובכלי אוטומטי, ורשמו ממצאים לפי חומרה.
4. תקנו את התבניות. תבנית אחת (כותרת, תפריט, טופס) מתקנת עשרות דפים.
5. תקנו את התוכן. טקסט חלופי, כותרות וקישורים ברורים ("קראו עוד על שירות X" ולא "לחצו כאן").
6. בדקו עם קורא מסך לפחות אחד, ופרטו בהצהרה איזה.
7. מנו רכז נגישות ופרסמו את פרטיו.
8. פרסמו הצהרת נגישות בכתובת קבועה ונגישה מכל עמוד. אפשר להשתמש במחולל הצהרת הנגישות החינמי, ולהשוות לתבנית הנציבות.
9. הגדירו מנגנון לפניות. תנו ללקוחות דרך לדווח על בעיה ותקנו אותה בזמן סביר.
10. תחזקו. בדיקה חוזרת אחרי כל שינוי גדול, ובכל פרסום של תוכן חדש. לאתרים שמתעדכנים הרבה, ראו שירות תחזוקת אתרים.

טעויות נפוצות בהנגשה

• הנגשה של דף הבית בלבד. תהליך הרכישה, טופס יצירת הקשר ודפי המוצר הם המקומות שבהם משתמש עם מוגבלות נתקע בפועל, ולכן הם צריכים להיבדק קודם.
• הסתמכות על צבע. שדה שגיאה שמסומן באדום בלבד לא יובן למי שאינו רואה צבעים, וגם לא למי שמשתמש בקורא מסך.
• קישורים כמו "לחצו כאן". קורא מסך מקריא רשימת קישורים בנפרד מהטקסט, ורשימה של עשרה "לחצו כאן" חסרת משמעות.
• חלונות קופצים שלוכדים את המקלדת. חלון שאי אפשר לסגור ב-Escape או שהמוקד נשאר מאחוריו הוא מלכודת, לא עיצוב.
• כפתורים שהם div. אלמנט שנראה ככפתור אבל נבנה מ-div לא מקבל מוקד מקלדת ולא מוכרז ככפתור, אלא אם מוסיפים לו את כל ההתנהגות ידנית. הפתרון הפשוט הוא להשתמש ב-button אמיתי.
• הנגשה פעם אחת ואז שכחה. הנציבות מדגישה שיש לתחזק את הנגישות דרך קבע. כל פרסום חדש, באנר או תוסף יכולים להחזיר את הבעיות.
• הצהרה שאינה משקפת את המצב. הצהרה שמבטיחה עמידה מלאה באתר שלא נבדק יוצרת חשיפה במקום להפחית אותה. עדיף לפרט מגבלות ידועות ולהציע דרך פנייה.

מתי תוסף עדיין שימושי

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

ומה עושים עכשיו

אם יש לכם אתר קיים, התחילו בבדיקה של דף הבית ותהליך אחד מרכזי, ובחנו כמה מהצעדים למעלה כבר מתקיימים. אם האתר עתיד להיבנות מחדש, כללו נגישות כבר באפיון, כפי שהנציבות מציינת שבניית אתר נגיש חדש בדרך כלל אינה יקרה משמעותית מבניית אתר שאינו נגיש. הגישה והפירוט המלא מופיעים במדריך הרשמי של הנציבות (הנגשת אתרי אינטרנט). לשאלות משפטיות ספציפיות, כמו פטורים או חשיפה לתביעה, פנו לעורך דין המתמחה בתחום.