קיבלתם פנייה בנושא נגישות באתר? מה לעשות בשבוע הראשון

זה מתחיל כמעט תמיד באותו רצף: קודם מגיע המכתב, ואחריו השאלה — "אבל יש לנו תוסף נגישות באתר, לא?"

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

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

שלושה דברים שאסור לעשות ברגע הראשון

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

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

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

מה כן, לפי הסדר

1. לתעד את המצב הנוכחי, היום

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

2. לבדוק מה באמת שבור, לא מה שהכלי אומר

כלים אוטומטיים (Lighthouse, axe, WAVE) הם נקודת התחלה טובה, אבל הם תופסים חלק מהבעיות בלבד. הבדיקות שמגלות את רוב מה שחשוב לא דורשות שום כלי:

• מקלדת בלבד. תנתקו את העכבר. אפשר להגיע לכל קישור, כל כפתור וכל שדה בטופס עם Tab? רואים איפה הפוקוס נמצא בכל רגע? אפשר לסגור חלון קופץ בלי עכבר?
• הגדלה ל-200%. הטקסט גדל, או שהכל נשבר?
• טפסים. לכל שדה יש תווית קבועה, או רק placeholder שנעלם ברגע שמתחילים להקליד? הודעות שגיאה אומרות מה בדיוק לא בסדר?
• תמונות. לתמונות שנושאות מידע יש טקסט חלופי אמיתי, או "image1.jpg"?
• וידאו. יש כתוביות?

תרשמו כל מה שנופל ברשימה אחת. הרשימה הזאת שווה יותר מכל דוח אוטומטי, כי היא מתארת את מה שאדם אמיתי חווה.

3. להבין מה הפער מול הדרישה

בישראל התקן הרלוונטי הוא ת"י 5568, שמבוסס על WCAG 2.1 ברמה AA. זה לא מסמך שצריך לקרוא מהתחלה לסוף — צריך לדעת אילו סעיפים נוגעים לאתר שלכם בפועל. אתר תדמית של חמישה עמודים והנגשה של חנות עם צ'קאאוט הן שתי עבודות בסדר גודל שונה לחלוטין.

4. לתקן בקוד, לפי סדר עדיפויות

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

1. חסימות מוחלטות — כל מה שלא מאפשר להשלים פעולה: טופס שאי אפשר למלא במקלדת, חלון קופץ שלא נסגר, תפריט שלא נפתח.
2. ניווט ומבנה — היררכיית כותרות תקינה, ניווט עקבי, מצב פוקוס שרואים.
3. טפסים — תוויות, הודעות שגיאה, קישור בין שדה לשגיאה שלו.
4. ניגודיות וטקסטים חלופיים — הכי קל לתקן, ולכן קורה הרבה שמתחילים כאן. אל תתחילו כאן.

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

5. הצהרת נגישות אמיתית

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

6. לשמור תיעוד של מה תוקן ומתי

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

כמה זמן זה לוקח

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

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

איך יודעים שבאמת סגרתם את זה

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

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

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

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

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

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

שורה תחתונה

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

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

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