📋 תוכן עניינים
המאמר הזה לא חוזר על דרישות התקן; על כך יש לנו מדריך מלא להנגשת אתרים לפי תקן IS5568. כאן נתמקד בשאלה צרה יותר: מה בדיוק מודלי AI מייצרים לא נכון, למה זה קורה, ואיך מזהים את זה תוך עשר דקות.
למה דווקא אתרי AI נכשלים בנגישות
מודל שמייצר ממשק לומד מדוגמאות קוד שראה באימון. רוב הקוד שקיים ברשת אינו נגיש, ולכן זה מה שהמודל משכפל. חשוב מכך — המודל מבצע אופטימיזציה למה שנראה נכון בצילום מסך, ונגישות היא בדיוק התכונה שאינה נראית בצילום מסך. אין שום אות במהלך הייצור שמעניש מודל על כפתור שקורא מסך לא יכול להקריא.
שבעת הכשלים החוזרים
1. div במקום button
זה הכשל הנפוץ ביותר. המודל מייצר <div onclick="..."> שנראה ומתנהג ככפתור עבור משתמש עכבר, אבל אינו קיים עבור מקלדת ועבור קורא מסך. משתמש שמנווט ב-Tab פשוט ידלג עליו.
בדיקה: נווטו באתר עם מקש Tab בלבד, בלי לגעת בעכבר. אם אתם לא מגיעים לכפתור כלשהו או לא רואים איפה הפוקוס נמצא — זו הבעיה.
2. ניגודיות צבעים נמוכה
אפור בהיר על לבן הוא ברירת המחדל האסתטית של כמעט כל מודל. התקן דורש יחס ניגודיות של 4.5:1 לטקסט רגיל ו-3:1 לטקסט גדול. טקסט משני באתרי AI נופל בדרך כלל סביב 2.5:1.
בדיקה: אפשר לבדוק כל צמד צבעים בבודק הניגודיות החינמי שלנו.
3. תמונות בלי טקסט חלופי
מודלים מייצרים alt="" ריק, או גרוע מכך — טקסט חסר משמעות כמו "image" או שם הקובץ. לתמונה שנושאת מידע חייב להיות תיאור אמיתי; לתמונה דקורטיבית בלבד מתאים alt="" ריק, וזה תקין.
4. טפסים בלי תוויות מקושרות
הדפוס הנפוץ הוא שדה קלט עם placeholder בלבד, בלי <label> מקושר. שתי בעיות: קורא מסך לא יודע להכריז מה השדה מבקש, וה-placeholder נעלם ברגע שמתחילים להקליד — כך שגם משתמש רואה עם קשיי זיכרון נשאר בלי הקשר.
5. היררכיית כותרות שבורה
משתמשי קורא מסך מנווטים בעמוד לפי כותרות, בדיוק כמו שאדם רואה סורק בעיניים. כשהמודל מייצר ארבעה H1 או קופץ מ-H2 ל-H4, הניווט הזה קורס. זו גם בדיוק אותה בעיה שפוגעת ב-SEO — שני העולמות קוראים את אותו מבנה.
6. אין דילוג לתוכן ואין ניהול פוקוס
בלי קישור "דלג לתוכן הראשי", משתמש מקלדת נאלץ לעבור בכל פריט בתפריט בכל עמוד מחדש. בנוסף, חלונות קופצים שמודלים מייצרים כמעט אף פעם לא לוכדים את הפוקוס בתוכם ולא נסגרים ב-Escape.
7. אנימציות בלי כיבוד העדפת המשתמש
אפקטי גלילה ומעברים הם חתימת הסגנון של אתרי AI. משתמשים עם רגישות לתנועה מגדירים במערכת ההפעלה העדפה להפחתת אנימציות, ואתר תקין מכבד אותה. כמעט אף בילדר לא מייצר את הכלל הזה.
בדיקה עצמית של עשר דקות
| בדיקה | איך | תוצאה תקינה |
|---|---|---|
| ניווט מקלדת | Tab בלבד לאורך העמוד | מגיעים לכל רכיב, הפוקוס נראה |
| זום 200% | Ctrl ופלוס | אין חיתוך טקסט ואין גלילה אופקית |
| ניגודיות | בודק ניגודיות | 4.5:1 ומעלה |
| כותרות | תוסף בדיקת מבנה | H1 יחיד, בלי דילוגים |
| טפסים | לחיצה על טקסט התווית | הפוקוס קופץ לשדה |
מה שתוסף נגישות לא פותר
הפיתוי הוא להתקין ווידג'ט נגישות ולסמן וי. חשוב להבין מה ווידג'ט כזה באמת עושה: הוא מוסיף שכבת שליטה למשתמש — הגדלת טקסט, ניגודיות גבוהה, הדגשת קישורים. הוא אינו מתקן div שאינו כפתור, הוא אינו ממציא טקסט חלופי לתמונות, והוא אינו מקשר תוויות לשדות. אלה תיקונים ברמת הקוד.
הווידג'ט הוא שכבה משלימה נכונה מעל אתר תקין, ולא תחליף לו. זו בדיוק הסיבה שאנחנו מטפלים בהנגשת אתרים ברמת הקוד ולא רק בהתקנת תוסף.
סדר תיקון מומלץ
- ניווט מקלדת ומחוונים ויזואליים לפוקוס — ההשפעה הגדולה ביותר
- תוויות בטפסים — קריטי לכל טופס יצירת קשר
- ניגודיות צבעים — לרוב שינוי של כמה ערכי צבע
- טקסט חלופי לתמונות
- היררכיית כותרות — מרוויח פעמיים, גם ב-SEO
- קישור דילוג לתוכן וניהול פוקוס בחלונות
- כיבוד העדפת הפחתת תנועה
שלושת הראשונים מכסים את רוב החשיפה המשפטית ואת רוב החוויה בפועל, והם גם הזולים ביותר לתיקון.
רוצים לדעת איפה האתר שלכם עומד? אנחנו עושים בדיקת נגישות ראשונית ללא עלות שמסמנת בדיוק אילו מהשבעה קיימים אצלכם ומה סדר הטיפול.
איך מבקשים מ-AI לייצר קוד נגיש מלכתחילה
אפשר להוריד חלק ניכר מהכשלים כבר בשלב הבנייה, פשוט על ידי ניסוח הבקשה אחרת. מודל שלא התבקש במפורש לא ייצר נגישות מעצמו.
הנחיות שכדאי לכלול בבקשה:
- להשתמש באלמנטים סמנטיים אמיתיים —
button,nav,main,header— ולאdivעם מאזין לחיצה - לכל שדה בטופס תווית
labelמקושרת דרך מזהה, לא רק placeholder - ניגודיות של 4.5:1 לפחות בכל טקסט מול הרקע שלו
- מחוון פוקוס נראה לעין לכל רכיב שניתן להגיע אליו במקלדת
- H1 יחיד בעמוד והיררכיית כותרות רציפה בלי דילוגים
- כיבוד העדפת המערכת להפחתת תנועה באנימציות
זה משפר מאוד את נקודת הפתיחה, אבל לא מייתר בדיקה. המודל אינו מריץ קורא מסך על התוצר שלו ואינו יודע אם מה שייצר באמת עובד — הוא רק יודע שהקוד נראה כמו קוד נגיש.
דוגמה: הכפתור שאינו כפתור
זה ההבדל המעשי, והוא מסביר למה זה קריטי. הדפוס שמודלים מייצרים:
<div class="btn" onclick="send()">שליחה</div>
הוא נראה ככפתור, הוא מגיב ללחיצת עכבר, והוא בלתי נגיש לחלוטין: לא ניתן להגיע אליו ב-Tab, לא ניתן להפעיל אותו ברווח או באנטר, וקורא מסך יקריא אותו כטקסט רגיל בלי לרמוז שאפשר ללחוץ.
החלופה התקינה:
<button type="submit">שליחה</button>
הדפדפן מספק כאן בחינם את כל מה שחסר — מיקוד מקלדת, הפעלה במקשים, והכרזה נכונה כ"לחצן". אותו עיצוב בדיוק, בלי שורת קוד נוספת. זו הסיבה שרוב תיקוני הנגישות הם החלפה של אלמנט, לא כתיבת לוגיקה חדשה.
מה קורה בפועל כשמגיעה פנייה
בישראל, ההליך הנפוץ מתחיל בפנייה בכתב מגולש או מארגון, ולא בתביעה. לרוב יש חלון זמן לתקן. עסק שמגיב מהר, מתקן את הליקויים המהותיים ומפרסם הצהרת נגישות מעודכנת — מסיים את העניין ברוב המקרים בשלב הזה.
מה שמסבך הוא דווקא ההתעלמות. לכן כדאי שיהיו במקום שני דברים בסיסיים: הצהרת נגישות זמינה באתר עם דרך ליצור קשר בנושא, ותיעוד של הבדיקות והתיקונים שבוצעו. אפשר לייצר הצהרה בסיסית בעזרת מחולל הצהרת הנגישות שלנו, ולעדכן אותה בכל שינוי מהותי באתר.
לקבל מאמרים כאלה ישירות למייל?
הרשמה חינמית. מאמרים חדשים + קורסים — ישירות לתיבה שלך. ללא ספאם, הסרה בקליק.
ללא ספאם · הסרה בקליק אחד · כבר 32+ מנויים
