קיבלתם פנייה בנושא נגישות באתר? מה לעשות בשבוע הראשון
זה מתחיל כמעט תמיד באותו רצף: קודם מגיע המכתב, ואחריו השאלה - "אבל יש לנו תוסף נגישות באתר, לא?"
אז קודם כל - נשימה. זה לא סוף העולם, וזה גם לא משהו שמתקנים בעשר דקות. הנה סדר הפעולות שכדאי לעבוד לפיו, אחד אחרי השני.
הבהרה אחת לפני שמתחילים: אני מפתח, לא עורך דין. כל מה שכתוב כאן הוא הצד הטכני של הסיפור - מה שבור באתר ואיך מתקנים אותו. לצד המשפטי תצטרכו מישהו שזה המקצוע שלו, ורצוי מוקדם ולא מאוחר.
שלושה דברים שאסור לעשות ברגע הראשון
אל תורידו את האתר לאוויר. זו התגובה האינסטינקטיבית של הרבה בעלי עסקים - אם אין אתר, אין בעיה. בפועל עשיתם שני נזקים: איבדתם את התנועה ואת הלידים, וגם מחקתם את הראיה הכי טובה שלכם למה שהיה באתר באמת ברגע הפנייה.
אל תתקינו תוסף צף ותכריזו שתוקן. זה הפיתוי הכי גדול, כי זה לוקח חמש דקות ויש לו אייקון שנראה רשמי. הבעיה היא שווידג'ט שמרחף מעל האתר לא משנה את הקוד שמתחתיו, ומי שבודק את האתר ברצינות יראה את זה תוך דקה. הרחבתי על זה במדריך על תוספי נגישות ובמדריך על חוק הנגישות, אבל השורה התחתונה פשוטה: התוסף מוסיף שכבה, הוא לא מתקן את מה שמתחתיה.
אל תתעלמו. פנייה שלא נענית לא נעלמת, והיא גם לא משתפרת עם הזמן. אפילו אם התשובה שלכם היא "אנחנו בודקים ונחזור", עדיף שהיא תצא.
מה כן, לפי הסדר
1. לתעד את המצב הנוכחי, היום
לפני שנוגעים בשורת קוד אחת - צילומי מסך של העמודים המרכזיים, בדסקטופ ובמובייל, עם תאריך. אם יש לכם גישה לגוגל אנליטיקס או ל-Search Console, שמרו גם ייצוא של התקופה. זה נשמע ביורוקרטי, אבל ברגע שתתחילו לתקן, המצב הקודם ייעלם - ואתם עוד תרצו להיות מסוגלים להראות מה היה ומה שיניתם.
2. לבדוק מה באמת שבור, לא מה שהכלי אומר
כלים אוטומטיים (Lighthouse, axe, WAVE) הם נקודת התחלה טובה, אבל הם תופסים חלק מהבעיות בלבד. הבדיקות שמגלות את רוב מה שחשוב לא דורשות שום כלי:
- מקלדת בלבד. תנתקו את העכבר. אפשר להגיע לכל קישור, כל כפתור וכל שדה בטופס עם Tab? רואים איפה הפוקוס נמצא בכל רגע? אפשר לסגור חלון קופץ בלי עכבר?
- הגדלה ל-200%. הטקסט גדל, או שהכל נשבר?
- טפסים. לכל שדה יש תווית קבועה, או רק placeholder שנעלם ברגע שמתחילים להקליד? הודעות שגיאה אומרות מה בדיוק לא בסדר?
- תמונות. לתמונות שנושאות מידע יש טקסט חלופי אמיתי, או "image1.jpg"?
- וידאו. יש כתוביות?
תרשמו כל מה שנופל ברשימה אחת. הרשימה הזאת שווה יותר מכל דוח אוטומטי, כי היא מתארת את מה שאדם אמיתי חווה.
3. להבין מה הפער מול הדרישה

בישראל התקן הרלוונטי הוא ת"י 5568, שמבוסס על WCAG 2.1 ברמה AA. זה לא מסמך שצריך לקרוא מהתחלה לסוף - צריך לדעת אילו סעיפים נוגעים לאתר שלכם בפועל. אתר תדמית של חמישה עמודים והנגשה של חנות עם צ'קאאוט הן שתי עבודות בסדר גודל שונה לחלוטין.
4. לתקן בקוד, לפי סדר עדיפויות
לא כל התיקונים שווים. אם יש לכם שבועיים, זה הסדר שאני עובד לפיו:
- חסימות מוחלטות - כל מה שלא מאפשר להשלים פעולה: טופס שאי אפשר למלא במקלדת, חלון קופץ שלא נסגר, תפריט שלא נפתח.
- ניווט ומבנה - היררכיית כותרות תקינה, ניווט עקבי, מצב פוקוס שרואים.
- טפסים - תוויות, הודעות שגיאה, קישור בין שדה לשגיאה שלו.
- ניגודיות וטקסטים חלופיים - הכי קל לתקן, ולכן קורה הרבה שמתחילים כאן. אל תתחילו כאן.
תיקון נגישות טוב לא מוסיף שכבה מעל האתר. הוא משנה את האתר עצמו, ולכן הוא גם לא נעלם בעדכון הבא של התבנית.
5. הצהרת נגישות אמיתית
לא תבנית שהורדתם מגוגל והחלפתם בה את שם החברה. הצהרה שמתארת את המצב בפועל: מה הונגש, מה עדיין לא, איך פונים אליכם בנושא, ומתי היא עודכנה לאחרונה. הצהרה שמבטיחה נגישות מלאה באתר שלא נגיש היא בעיה בפני עצמה. ככה כותבים הצהרה כזו, כולל תבנית.
6. לשמור תיעוד של מה תוקן ומתי
רשימת התיקונים, התאריכים, ובדיקה חוזרת בסוף. אם התהליך יימשך, היכולת להראות שפעלתם באופן מסודר ומיד - ולא אחרי חצי שנה - שווה הרבה.
כמה זמן זה לוקח
תלוי לגמרי במה שמצאתם בשלב 2. אתר תדמית סטנדרטי בלי טפסים מורכבים הוא בדרך כלל עניין של ימים. אתר עם אזור אישי, חנות או מערכת הזמנות הוא עניין של שבועות, כי כל מסך שמעורב בו קלט של משתמש דורש בדיקה בפני עצמו.
מה שכן - הרוב המכריע של הבעיות שאני מוצא הן חוזרות: אותם טפסים, אותם חלונות קופצים, אותם תפריטים. ברגע שמתקנים אותן ברמת התבנית, הן נסגרות בכל האתר בבת אחת.
איך יודעים שבאמת סגרתם את זה
זה החלק שהכי הרבה אנשים מדלגים עליו, ואז מגלים חצי שנה אחר כך שהתיקון לא החזיק. בדיקה חוזרת היא לא פורמליות - היא מה שהופך "תיקנו" ל"אפשר להוכיח שתיקנו".
תריצו את אותה רשימה מסעיף 2, מההתחלה. אותן בדיקות, אותם עמודים, אחרי התיקון. אם בדיקה שנפלה קודם עוברת עכשיו - סמנו תאריך. אם היא עדיין נופלת, היא לא תוקנה, גם אם מישהו אמר שכן.
תבדקו את המסלולים, לא רק עמודים בודדים. נגישות נשברת בין העמודים, לא בתוכם: מעמוד הבית, דרך הטופס, עד מסך התודה. אם לא סיימתם את המסלול במקלדת בלבד - הוא לא נגיש, גם אם כל עמוד בנפרד תקין.
תבדקו במכשיר אמיתי, לא רק בכלי. דוח אוטומטי ירוק אחרי התיקון הוא סימן טוב, לא הוכחה. חמש דקות עם מקלדת ועם הגדלת טקסט אומרות יותר.
תשמרו את התוצאה בכתב. מה נבדק, מתי, מה נמצא, מה תוקן. מסמך של עמוד אחד. אם התהליך יימשך - זה בדיוק המסמך שמראה שפעלתם מסודר.
תקבעו תאריך לבדיקה הבאה. נגישות היא לא מצב, היא תחזוקה: כל עמוד חדש, כל באנר, כל תוסף וכל שינוי בתבנית יכולים לשבור אותה שוב. פעם ברבעון זה קצב סביר לרוב האתרים.
שורה תחתונה
הפנייה היא לא הבעיה, היא הרגע שבו הבעיה נהיית גלויה. האתר לא היה נגיש גם שבוע קודם - פשוט אף אחד לא אמר את זה בכתב.
הדבר הכי גרוע שאפשר לעשות עכשיו הוא לחפש את הפתרון שנראה הכי מהיר. הדבר הכי טוב הוא לעבור על האתר ברצינות פעם אחת, לתקן בקוד - ככה נראית הנגשת אתרים לפי תקן 5568 - ולצאת מזה עם אתר שבאמת עומד בדרישות, כולל הצהרת נגישות שאפשר לעמוד מאחוריה.
רוצים אינדיקציה מיידית עוד לפני שמדברים? הבדיקה העצמית החינמית נותנת תמונת מצב ראשונית תוך דקות. וקיבלתם פנייה ואתם לא בטוחים מה מצב האתר? שלחו לי את הכתובת - אעבור עליו ואגיד לכם מה שבור, מה קריטי, ומה אפשר לתקן כבר השבוע.
עוד מהבלוג
תוסף נגישות מספיק כדי לעמוד בחוק? מה הווידג'ט עושה, ומה הוא לא יכול
תוסף נגישות צף לא הופך אתר לנגיש לפי ת"י 5568. מה הווידג'ט באמת עושה, איפה הוא נכשל, למה הוא לפעמים מזיק, ומה כן מכסה אתכם.
7 דקות קריאהאיך כותבים הצהרת נגישות לאתר? מה חובה, מה מומלץ, ותבנית מוכנה
הצהרת נגישות לפי תקנה 35: מה התקנות דורשות שיופיע בה, איפה לשים אותה, מה לא לכתוב אף פעם, ותבנית שאפשר להתאים לאתר שלכם.
7 דקות קריאהאיך מגבים אתר נכון? מה מגבים, לאן, וכל כמה זמן
גיבוי אתר שבאמת מציל: מה חייב להיכנס לגיבוי (רמז: לא רק הקבצים), לאן לא לשמור אותו, כל כמה זמן לגבות לפי סוג האתר - ואיך יודעים שהוא בכלל עובד.
6 דקות קריאה
להשיג אותי זה החלק הקל.
כמה שורות בטופס אם נוח לכם בכתב - או ישר לערוץ שאתם כבר משתמשים בו. בכל מקרה עונה לכם אני.