אתר יכול להיראות מצוין, לטעון מהר ולהביא לידים, ועדיין לחסום חלק מהלקוחות בדיוק ברגע שבו הם מנסים לבצע פעולה. טופס שאי אפשר להשלים במקלדת, כפתור ללא שם ברור או מסמך שלא ניתן לקרוא בקורא מסך אינם פרטי עיצוב שוליים. הם כשל תפעולי, שירותי ולעיתים גם רגולטורי. מדריך לבדיקת נגישות דיגיטלית חייב לכן להתחיל בהבנה פשוטה: לא בודקים רק אם הותקן רכיב נגישות, אלא אם אדם אמיתי יכול להשתמש באתר באופן עצמאי וברור.
באתרי וורדפרס מורכבים, הנגישות מושפעת מכל שכבה: התבנית, בונה העמודים, תוספים, טפסים, מערכת הסליקה, חלונות קופצים, מסמכים מוטמעים ותוכן שמתווסף לאורך זמן. בדיקה טובה אינה אירוע חד-פעמי לפני העלייה לאוויר. היא תהליך שמאתר סיכונים, מתעדף תיקונים ומכניס בקרות לשגרת הפיתוח והתחזוקה.
מה בודקים בבדיקת נגישות דיגיטלית?
הבדיקה נשענת בדרך כלל על עקרונות התקן הישראלי הרלוונטי ועל הנחיות נגישות תוכן אינטרנטי. בפועל, המטרה אינה לסמן וי על סעיפי תקן, אלא לוודא שהממשק נתפס, מופעל, מובן ויציב גם עבור משתמשים עם מוגבלויות שונות, ובתנאי שימוש שונים.
כדי להגיע לתמונה אמינה, יש לשלב בין בדיקות אוטומטיות לבדיקה ידנית. כלים אוטומטיים יעילים באיתור בעיות חוזרות כגון ניגודיות נמוכה, תמונות ללא טקסט חלופי או שדות טופס ללא תווית. אבל הם אינם יודעים לקבוע אם סדר הכותרות הגיוני, אם טקסט חלופי באמת מתאר את התמונה, או אם חלון קופץ לוכד את המיקוד ומונע מהמשתמש להמשיך באתר.
בדיקה ידנית מוסיפה את ההקשר העסקי. היא בוחנת את הפעולות שבאמת חשובות לארגון: שליחת ליד, רכישה, הרשמה לאירוע, הורדת מסמך, פתיחת פנייה או כניסה לאזור אישי. אם תהליך התשלום אינו נגיש, לא משנה עד כמה דף הבית עומד בדרישות.
מדריך לבדיקת נגישות דיגיטלית: סדר עבודה נכון
נקודת הפתיחה היא מיפוי. אין צורך לסרוק כל כתובת באתר גדול באותה רמת עומק, אך אסור להסתפק בדף הבית. בוחרים מדגם שמייצג את כל סוגי המסכים והרכיבים: עמודי תוכן, קטגוריות, חיפוש, טפסים, אזור לקוחות, סל, קופה, דפי נחיתה, מודעות קופצות ומסמכי PDF. באתר רב-לשוני או באתר שיש בו כמה תבניות תוכן, יש לכלול גם אותם במדגם.
לאחר המיפוי, מומלץ לעבוד לפי השלבים הבאים:
- בדקו ניווט במקלדת בלבד. נתקו לרגע את העכבר ועברו באתר באמצעות מקש Tab, Shift+Tab, Enter וחיצים כאשר נדרש. ודאו שניתן להגיע לכל רכיב פעיל, שהסדר הגיוני, שיש חיווי מיקוד ברור ושאפשר לצאת מתפריטים, חלונות קופצים ורכיבי בחירה.
- בדקו מבנה סמנטי. לכל עמוד צריך להיות מבנה כותרות עקבי, עם כותרת ראשית אחת והיררכיה שאינה מדלגת ללא סיבה. כפתור חייב להיות כפתור, קישור חייב להוביל ליעד, ורשימה צריכה להיות מוגדרת כרשימה. סמנטיקה נכונה משרתת קוראי מסך, אך גם משפרת את איכות הקוד ואת יכולת התחזוקה.
- עברו על טפסים ותהליכים עסקיים. ודאו שלכל שדה יש תווית מובנת, שהודעות השגיאה מפורטות ומכוונות לתיקון, ושלא מסתמכים על צבע בלבד כדי להציג בעיה. בטופס מורכב, בדקו גם מה קורה לאחר שליחה כושלת, לאחר אימות קוד, או כאשר שדה חובה נשאר ריק.
- בחנו תוכן חזותי ומולטימדיה. בדקו ניגודיות של טקסטים, מצב ריחוף, כפתורים ושדות. הוסיפו טקסט חלופי משמעותי לתמונות שמוסיפות מידע, וסמנו תמונות דקורטיביות באופן שאינו מעמיס על קורא המסך. בסרטונים יש לבחון כתוביות, ובמקרים מתאימים גם תמלול או תיאור קולי.
- בדקו התנהגות במובייל ובהגדלה. משתמשים רבים מגדילים טקסט, משתמשים בזום או גולשים במסך קטן. ודאו שהתוכן אינו נחתך, שאין גלילה אופקית מיותרת ושהכפתורים נותרים ברורים וקלים להפעלה. נגישות אינה מסתיימת בתצוגת מחשב רחב.
- הפעילו כלי סריקה, ואז אמתו את הממצאים. כלי בדיקה יכולים לחסוך זמן רב באיתור תקלות בסיסיות ובמעקב אחר תיקונים. הם אינם תחליף לאיש מקצוע שמבין את האתר, את רכיבי וורדפרס ואת מסע המשתמש. יש תקלות שכלי אוטומטי לא יזהה, ולעיתים הוא גם ידווח על בעיה שאינה בעיה בפועל.
התקלות שחוזרות באתרי וורדפרס
בפיתוח וורדפרס, מקור הבעיה אינו תמיד העיצוב המקורי. לעיתים התבנית נבנתה היטב, אבל תוסף טפסים, רכיב סליקה או חלון קופץ שהותקנו מאוחר יותר מוסיפים קוד בעייתי. לכן בדיקת נגישות צריכה להתייחס גם לממשקים חיצוניים ולתוספים שמנהלים פונקציות קריטיות.
בעיה נפוצה היא שימוש בכפתורים גרפיים ללא תיאור. אייקון של זכוכית מגדלת אולי מובן לרוב המשתמשים הרואים, אך קורא מסך זקוק לשם כמו "חיפוש". דוגמה נוספת היא קישורים כלליים בנוסח "קראו עוד" שמופיעים שוב ושוב בעמוד. כשהם נשמעים ברצף, אין למשתמש דרך לדעת לאיזה תוכן כל קישור מוביל.
גם רכיבי סליידר, טאבים ואקורדיונים דורשים תשומת לב. הם צריכים להציג מצב פתוח או סגור, לאפשר הפעלה במקלדת ולשמור על סדר מיקוד תקין. אם הרכיב נבנה באמצעות תוסף שלא מאפשר שליטה מספקת, תיקון נקודתי בקוד עשוי להיות אפשרי, אך לפעמים הבחירה הנכונה היא להחליף את הרכיב. זהו שיקול מקצועי של עלות מול סיכון ותחזוקה עתידית.
מסמכים הם נקודת כשל משמעותית במיוחד בגופים ציבוריים, עמותות וארגונים עתירי תוכן. עמוד נגיש שמוביל לקובץ סרוק שאינו קריא לקורא מסך אינו מסיים את העבודה. יש לבדוק את הקבצים עצמם, את מבנה הכותרות בהם, את סדר הקריאה ואת נגישות הטבלאות והטפסים.
תעדוף תיקונים: מה מתקנים קודם?
רשימת ממצאים ארוכה אינה תוכנית עבודה. נכון לתעד כל בעיה עם כתובת העמוד, תיאור ברור, חומרה, הרכיב שגרם לה והמלצת תיקון. לאחר מכן מתעדפים לפי השפעה על משתמשים ולפי קריטיות עסקית.
חסמים שמונעים השלמת רכישה, יצירת קשר, כניסה לחשבון או קבלת שירות צריכים לקבל קדימות עליונה. אחריהם מגיעות בעיות רוחביות שחוזרות בכל האתר, למשל ניגודיות נמוכה ברכיב גלובלי או ניווט שאינו תקין. תיקון אחד בתבנית או ברכיב משותף יכול לפתור עשרות עמודים, ולכן הוא לרוב יעיל יותר מתיקון ידני של כל עמוד בנפרד.
חשוב גם להבחין בין תיקון קוד, תיקון תוכן והחלפת מערכת. חוסר בטקסט חלופי אפשר לפתור לעיתים בעבודת תוכן מסודרת. בעיית מיקוד בתפריט דורשת לרוב פיתוח. מערכת צד שלישי שאינה נגישה, כמו שירות קביעת פגישות, עלולה לדרוש פנייה לספק או בחירה בפתרון חלופי. שקיפות לגבי ההבחנה הזו מונעת הבטחות לא מציאותיות.
למה תוסף נגישות לבדו לא פותר את הבעיה
תוספי נגישות יכולים לסייע בחלק מהמקרים, למשל בהצגת אפשרויות התאמה או בהוספת קיצורי דרך. אך הם אינם מתקנים מבנה קוד לקוי, שגיאות בטפסים, תוכן לא ברור או רכיב חיצוני שלא נבנה כנגיש. הסתמכות עליהם כפתרון יחיד עלולה ליצור תחושת ביטחון שגויה ואף להכביד על ביצועי האתר.
הגישה הנכונה היא לבנות נגישות לתוך המערכת: לבחור רכיבים מתאימים, להגדיר כללי תוכן לעורכים, לבדוק כל פיצ'ר לפני פרסום ולבצע בדיקות חוזרות לאחר עדכוני תבנית, תוספים או תהליכי מסחר. באתר שמתוחזק לאורך זמן, זה זול ובטוח יותר מאשר ניסיון לתקן הצטברות של בעיות בדיעבד.
ב-TalPress מתייחסים לנגישות כחלק מאיכות הפיתוח הכוללת – לצד אבטחה, ביצועים, יציבות ויכולת תחזוקה. אתר נגיש הוא לא שכבת ציות שמדביקים בסוף הפרויקט; הוא מערכת שמכבדת משתמשים, מצמצמת נטישה ומאפשרת לארגון להמשיך לצמוח בלי לבנות את אותה תשתית מחדש בכל שינוי.
הצעד הנכון מכאן הוא לא לחפש ציון מושלם בכלי סריקה, אלא לבחור פעולה עסקית אחת באתר ולבדוק אותה מתחילתה ועד סופה, ללא עכבר וללא הנחות. במקום שבו המשתמש נתקע, נמצאת בדרך כלל גם המשימה החשובה הבאה של צוות הפיתוח.
