הנגשת אתר נשמעת כמו משימה ענקית, אבל היא מתחילה מכמה צעדים מסודרים: להבין מה שבור, לבדוק עם כלים אוטומטיים, ואז לעבור לבדיקה ידנית מול מקלדת וקורא מסך. במאמר הזה נראה איך מתחילים נכון, אילו כלים באמת עוזרים, ואיפה אתרים נופלים שוב ושוב. זה החלק הראשון בסדרה, והוא מתמקד בשלב האבחון.
לפני שמתחילים, חשוב להבין על איזה תקן מדברים. בישראל הנגשת אתרים מעוגנת בתקנה 35 לתקנות שוויון זכויות לאנשים עם מוגבלות, שמפנה לתקן ישראלי 5568 ברמת AA. התקן מבוסס על הנחיות WCAG 2.0 (ומתייחס גם ל-2.1), כך שכל הכלים והעקרונות שנדבר עליהם כאן רלוונטיים ישירות לעמידה בחוק.
איך מתחילים להנגיש אתר?
הצעד הראשון הוא מיפוי. אנחנו צריכים להבין אילו שגיאות נגישות קיימות באתר לפני שניגשים לתקן. הדרך המהירה לעשות זאת היא להריץ כמה כלים אוטומטיים שמסמנים את רוב הבעיות הבולטות. חשוב לזכור: כלים אוטומטיים מזהים בערך 30 עד 40 אחוז מבעיות הנגישות. הם נקודת התחלה מצוינת, אבל הם לא תחליף לבדיקה ידנית.
כלים אוטומטיים מומלצים
הנה שלושה כלים חינמיים שכדאי שיהיו לכם בארגז הכלים:
- axe DevTools מבית Deque. תוסף לכרום ולפיירפוקס שנחשב לסטנדרט בתעשייה. הוא מבוסס על מנוע הקוד הפתוח axe-core ושם דגש על אפס התרעות שווא, כך שכמעט כל מה שהוא מסמן הוא בעיה אמיתית שצריך לתקן.
- WAVE מבית WebAIM. כלי ויזואלי ידידותי שמציג אייקונים ישירות על גבי העמוד הנבדק: היכן חסר טקסט חלופי לתמונה, היכן יש בעיית ניגודיות, והיכן היררכיית כותרות שגויה. מצוין למי שמתחיל. קיים גם כתוסף לדפדפן וגם כגרסת אונליין.
- Lighthouse המובנה בכלי המפתחים של כרום (לשונית Lighthouse). נותן ציון נגישות מהיר לצד ביצועים ו-SEO. הבדיקה שלו בסיסית יחסית, אבל היא נוחה למעקב אחרי מגמה לאורך זמן.
הערה חשובה: בדיקת ולידציה של HTML (כמו Markup Validation Service של W3C) היא כלי טוב לבריאות הקוד, אבל היא אינה כלי נגישות. קוד תקין לא אומר שהאתר נגיש, ואתר עם שגיאות HTML יכול בהחלט להיות שמיש לקורא מסך. שווה להריץ את הוולידטור כי קורא מסך בונה את העמוד על בסיס מבנה ה-HTML, אבל אל תתבלבלו בין השניים.
אחרי שהוצאתם רשימת שגיאות ויש לכם תמונה ברורה של מה לא תקין, הגיע הזמן לבדיקה הידנית.
בדיקה ידנית
הבדיקה הידנית היא הלב של ההנגשה. כאן מתגלות הבעיות שאף סורק אוטומטי לא יתפוס.
גלישה באמצעות מקלדת בלבד
חלק מהגולשים אינם משתמשים בעכבר ומנווטים במקלדת בלבד (מקש TAB ו-SHIFT+TAB). נסו לעבור על כל האתר כך, בלי לגעת בעכבר. שתי דרישות מרכזיות:
- מחוון פוקוס נראה. בכל רגע הגולש חייב לראות היכן הוא נמצא. אסור להסתיר את מסגרת הפוקוס. אם יש לכם אלמנט שמציג טקסט ב-hover, חובה לתת לו את אותו אפקט גם ב-focus.
- שליטה מלאה ברכיבים. סליידרים, תפריטים נפתחים וחלוניות חייבים להיות נגישים ופעילים מהמקלדת, לא רק מהעכבר.
מלכודות מקלדת
ודאו שאתם מצליחים לעבור על כל האתר בעזרת TAB בלי להיתקע. מלכודת מקלדת היא מצב שבו הפוקוס נכנס לרכיב (למשל חלונית מודאל) ולא מצליח לצאת ממנו. זו אחת הבעיות שחוסמות לחלוטין משתמש מקלדת, והיא לא תמיד מופיעה בסריקה אוטומטית.
הנגשת סרטוני וידאו
הנגשת וידאו היא נושא למאמר בפני עצמו. בקצרה: נגן יוטיוב עצמו נחשב נגיש וניתן לתפעול במקלדת, אבל התוכן של הסרטון אינו נגיש כל עוד אין כתוביות. הוסיפו כתוביות, ורצוי גם תמלול וטקסט מסכם מתחת לסרטון. זה מאפשר לכבדי שמיעה ליהנות מהתוכן, ובונוס נחמד הוא שיפור ה-SEO.
הנגשת מסמכים
יש לכם מסמכים להורדה (PDF, Word, Excel)? גם הם חייבים להיות נגישים, וזו עבודה שגוזלת זמן רב. אם המסמך לא עבר תהליך הנגשה מסודר, סביר מאוד שהוא אינו נגיש. הכלל הפרקטי: אם אפשר להציג את המידע כתוכן HTML רגיל בעמוד במקום כקובץ להורדה, עדיף. תוכן בעמוד קל יותר להנגיש ולתחזק ממסמך מצורף.
טפסים נגישים
טפסים הם אחד המוקדים הבעייתיים ביותר באתרים. בניגוד לתפיסה ישנה, היום קיימים פתרונות טפסים נגישים בוורדפרס. אפשר להגיע לטופס נגיש עם תוספים נפוצים, כל עוד מקפידים על העקרונות, ויש גם תוספי טפסים ששמים דגש מובנה על נגישות. מה שחשוב הוא לא התוסף הספציפי אלא היישום הנכון:
- תוויות (labels) מקושרות לשדות. לכל שדה תווית ברורה ומקושרת תכנותית, לא רק placeholder.
- הודעות שגיאה מוסברות ונגישות. השגיאות צריכות לתאר מה לתקן, ולהיקרא על ידי קורא מסך מבלי שהמשתמש יצטרך לחפש אותן ידנית בכל העמוד.
- קישור בין שדה לשגיאה שלו באמצעות תכונות ARIA מתאימות, כך שהמשתמש מבין מיד איזה שדה בעייתי.
דמיינו משתמש עיוור שלחץ "שלח" בלי למלא שדה חובה. אם השגיאה לא מוכרזת לו במקום ובאופן ברור, הוא נאלץ לדפדף בעשרות מקשי TAB עד שיבין מה קרה. זה ההבדל בין טופס שמיש לטופס מתסכל.
אבחנתם בעיות. מה עכשיו?
המאמר הזה נתן לכם את ארגז הכלים לשלב האבחון. בחלק הבא בסדרה נעבור לתיקון בפועל: כלים שעוזרים להנגיש מהר יותר, סדר עדיפויות בתיקונים, וטעויות נפוצות בדרך.
אם בדקתם וגיליתם שהאתר רחוק מהתקן, או שאין לכם זמן לרדת לרזולוציה הזו, זה בדיוק המקום שבו אנחנו נכנסים. ב-OCW אנחנו מבצעים בדיקת נגישות מלאה מול תקן 5568, מתקנים את האתר ברמת הקוד, ומלווים אותו לאורך זמן במסגרת חבילת אחריות 360 שמכסה אבטחה, נגישות, פרטיות ותחזוקה טכנית תחת קורת גג אחת. אפשר לפנות אלינו לבדיקה ולקבל תמונת מצב מסודרת.
חשוב להדגיש מה לא פתרון: תוספי overlay (כמו accessiBe) אינם הופכים אתר לנגיש. ה-FTC אף קנס את accessiBe במיליון דולר ב-2025 על טענת שווא שה-widget שלו הופך אתר לתואם WCAG. הרחבנו על כך במאמר על למה תוסף נגישות לא מספיק. למי שרוצה את התמונה המלאה של החובות והתהליך, ראו את המדריך המלא להנגשת אתר לפי תקן 5568, ולשאלת העלות והקנסות ראו כמה עולה הנגשת אתר ומה הקנס.
שאלות נפוצות
האם מספיק להריץ כלי אוטומטי כדי לדעת שהאתר נגיש?
לא. כלים כמו axe ו-WAVE מזהים בערך שליש מבעיות הנגישות. הם מצוינים לאבחון ראשוני, אבל עמידה אמיתית בתקן 5568 דורשת גם בדיקה ידנית של ניווט במקלדת, קורא מסך והגיון התוכן.
בדיקת W3C Validation מספיקה לנגישות?
לא. ולידציה של HTML בודקת תקינות קוד, לא נגישות. אתר יכול לעבור ולידציה ועדיין להיות בלתי נגיש לחלוטין, ולהיפך.
האם אפשר ליצור טופס נגיש בוורדפרס?
כן. קיימים היום פתרונות טפסים נגישים בוורדפרס. המפתח הוא יישום נכון: תוויות מקושרות לשדות, הודעות שגיאה שמוכרזות לקורא מסך, וקישור ARIA בין שדה לשגיאתו.
תוסף נגישות (overlay) פותר את הבעיה?
לא. overlays מתקנים חלק קטן מבעיות ה-WCAG ואינם מהווים עמידה בחוק. הפתרון הוא הנגשה ברמת הקוד.