בניית אתר נגיש פירושה לתכנן את הנגישות מהיום הראשון, ולא להוסיף אותה בסוף. באפיון מגדירים עמידה בת"י 5568 ברמה AA. בעיצוב בודקים ניגודיות, גדלים ומצבי פוקוס. בפיתוח משתמשים בתגיות נכונות, מקלדת מלאה ותוויות לטפסים. ולפני העלייה לאוויר עושים בדיקה ידנית. זה זול יותר, מהיר יותר, והתוצאה טובה יותר מאתר שמתקנים אחר כך.
"מה עדיף, לבנות ואז להנגיש, או לבנות נגיש?" אני שואל את זה כל לקוח שבונה אתר חדש. התשובה ברורה לכולם. ובכל זאת, רוב האתרים שאני בודק נבנו בדרך הראשונה, ועכשיו מישהו צריך לפרק את התבנית כדי לתקן.
בניית אתר נגיש: מה עושים בכל שלב
| שלב | מה עושים | מה נחסך |
|---|---|---|
| אפיון | כותבים בדרישות: ת"י 5568 ברמה AA, בקוד. מגדירים תהליכים: טפסים, רכישה, אזור אישי | ויכוח בסוף על "זה לא היה בהצעה" |
| עיצוב | ניגודיות, גדלי טקסט, מצב פוקוס לכל רכיב, מידע לא רק בצבע, תפריט פשוט | עיצוב מחדש אחרי בדיקה |
| פיתוח | תגיות נכונות, מבנה כותרות, מקלדת מלאה, תוויות לשדות, רכיבים שמוקראים נכון, הגדלה ל-200% | פירוק תבניות |
| תוכן | טקסט חלופי, כותרות, קישורים ברורים, כתוביות, מסמכים נגישים | תיקון עשרות עמודים |
| בדיקה | בדיקה ידנית לפני עלייה לאוויר, ותיקון | מכתב התראה אחרי העלייה |
| השקה | הצהרת נגישות, והדרכה למי שמעלה תוכן | פערים שנפתחים מהר |
דברים שכדאי להחליט כבר בעיצוב
- תמונות: אילו תמונות מעבירות מידע ואילו הן קישוט. בלי טקסט בתוך תמונות.
- תנועה: כל סליידר, אנימציה או תוכן מתחלף צריך כפתור עצירה. בלי הבהובים.
- טפסים: כמה שפחות שדות, תווית גלויה לכל שדה, שגיאות במילים.
- קישורים וכפתורים: גדולים מספיק ללחיצה, ושונים מהטקסט לא רק בצבע.
- מבנה גמיש: עיצוב שמסתדר עם הגדלה ועם מסך קטן, בלי גובה או רוחב קבועים שחותכים תוכן.
- הגדרות עיצוב מרוכזות: צבעים, גופנים ומצבי פוקוס במקום אחד, כך שתיקון אחד מתקן הכל.
בונים אתר חדש?
נלווה את האפיון והעיצוב מבחינת נגישות, כדי שהאתר יעלה נגיש מהיום הראשון.
"המתכנת אמר שהאתר נגיש." איך בודקים?
זו השאלה שאני מקבל הכי הרבה אחרי השקה. במיוחד כשהמתכנת התקין תוסף נגישות ואמר שזה מספיק. שלוש בדיקות שאתם יכולים לעשות בעצמכם, ברבע שעה:
- Tab. עברו על דף הבית במקלדת בלבד. האם רואים כל הזמן איפה אתם? האם אפשר לפתוח את התפריט? אם לא, התוסף לא תיקן את זה.
- טופס. שלחו את טופס יצירת הקשר ריק. האם יש הודעת שגיאה במילים, ליד השדה?
- תיעוד. בקשו מהמתכנת את טופס בדיקת הנגישות של הנציבות, מלא לאתר. אם במקום זה הוא שולח לכם תעודה מהתוסף, עכשיו אתם יודעים שאף אחד לא בדק.
אם שתיים מהשלוש נכשלו, האתר צריך בדיקה מקצועית. עדיף לגלות את זה עכשיו מאשר ממכתב.
ומה עם AI?
כלי AI יכולים לעזור לבנות אתר, ואפילו לכתוב קוד נגיש יותר. אבל הם גם טועים בנגישות בביטחון מלא. מה הם עושים טוב ואיפה צריך לבדוק אחריהם, כתבתי במאמר בניית אתר נגיש עם AI. ועל כתיבת תוכן עם AI, יש מאמר נפרד על תוכן נגיש ובינה מלאכותית.
למה זה משתלם
- אתר שמשמש גם אנשים עם מוגבלות, וגם את האוכלוסייה המבוגרת.
- מבנה ברור שמנועי חיפוש מבינים טוב יותר.
- פחות פניות ותלונות, ופחות עבודה חוזרת.
שורה תחתונה
אתר נגיש לא בונים בסוף. בונים אותו מההתחלה, ומעט יותר בזהירות. אנחנו מלווים אפיון ועיצוב של אתרים חדשים מבחינת נגישות, כדי שהבדיקה בסוף תהיה קצרה. כל הפרטים בעמוד ייעוץ ואפיון נגישות.
שאלות נפוצות על בניית אתר נגיש
מתי מתחילים לחשוב על נגישות בבניית אתר?
באפיון, לפני העיצוב. כך הנגישות נכנסת לדרישות, לעיצוב ולקוד, ולא מתקנים אחר כך.
מה צריך לכתוב בדרישות לחברה שבונה את האתר?
עמידה בת"י 5568 ברמה AA בקוד, בדיקה ידנית לפני המסירה, ותיעוד של הבדיקה. לא רק תוסף נגישות.
המתכנת התקין תוסף נגישות. האתר נגיש?
לא בהכרח. בדקו במקלדת, שלחו טופס ריק, ובקשו טופס בדיקת נגישות מלא. תעודה של התוסף לא מראה שמישהו בדק את האתר.
בניית אתר נגיש יקרה יותר?
מעט, בתכנון. אבל היא זולה בהרבה מתיקון של אתר קיים, שבו לפעמים צריך לפרק תבניות ולעצב מחדש.
מומחה להנגשת אתרי אינטרנט וקצין הגנת פרטיות מוסמך (DPO). מעל 9 שנות ניסיון בליווי ארגונים לעמידה בתקנות הנגישות, ת"י 5568 ובחוק הגנת הפרטיות.
חושבים שהאתר שלכם חשוף?
אל תישארו עם התחושה. שלחו כתובת אתר ונחזור אליכם עם תמונת מצב ראשונית, בלי התחייבות.