בדיקות נגישות - מה חשוב לבדוק באתר

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

נגישות מקלדת מלאה – בלי עכבר בכלל

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

מה לבדוק בפועל:

• מעבר בין אלמנטים עם TAB ו־SHIFT+TAB
• תפעול של תפריטים, טפסים, כפתורים, סגירת חלונות קופצים
• פוקוס חזותי ברור וגלוי לכל אורך הדרך

קישורים

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

מה לבדוק בפועל:

• כל קישור חייבת להיות אפשרות להפעלה בעזרת מקש ENTER
• לכל קישור חייב להיות טקסט שמתאר אותו.
• אם בתוך הקישור ישנה תמונה, חובה לתת לה תיאור בעזרת מאפיין ALT.

כפתורים

בדומה לקישורים, כפתורים מכילים בעיות דומות.

מה לבדוק בפועל:

• חשוב שיהיה ברור מה מטרת הכפתור בעזרת מאפיין VALUE או טקסט בתוך הכפתור או בעזרת מאפיין Aria-label.
• חשוב לוודא שניתן להגיע לכפתור בעזרת ניווט מקלדת.
• מומלץ ונכון להשתמש רק בקוד HTML  תקני.
• אם לא משתמשים בקוד HTML תקני ליצירת כפתורים (למשל: משתמשים בתגית DIV ככפתור) יש לתת לכל כפתור שכזה מאפיין TABINDEX=0
• יש לוודא שהכפתור חייבת להיות אפשרות להפעלה בעזרת ENTER.
• צריך "לומר" לקורא מסך אם הכפתור נשאר לחוץ.

היררכיה כותרות ותיוג נכון של תוכן

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

מה לבדוק בפועל:

• שיש בדיוק <h1> אחד
• שהכותרות מקוננות לפי סדר הגיוני (h2, h3…)
• שאין שימוש בכותרות רק לצורכי עיצוב

• לדוגמה היררכית כותרות:

  H1

  -      H2

  -      H2

  --H3

  --H3

  ---H4

  - H2

   

טפסים – תוויות, הנחיות וטעויות

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

מה לבדוק בפועל:

• לכל שדה יש תווית (<label>) קשורה תקנית
• קיימות הנחיות ברורות (למשל: "יש למלא 10 ספרות")
• שגיאות מוצגות בצורה נגישה, עם תיאור ברור מה הבעיה ואיך לתקן אותה
• שהשגיאות מוקראות על ידי תוכנות קוראת מסך.

תמונות ואלטרנטיבות (ALT)

אם אין תיאור לתמונה, היא שקופה לחלוטין למשתמש עיוור.

מה לבדוק בפועל:

• לכל תמונה יש alt שמשקף את משמעות התמונה
• אלט ריק (alt="") רק אם מדובר באלמנט קישוטי בלבד
• בלי שמות קבצים בתיאור (למשל: "image123.jpg")
• אם התמונה היא לאווירה בלבד – תנו מאפיין ALT עם ערך ריק
• אם התמונה קליקבילית חובה שיהיה לה תיאור

 ניגודיות צבעים

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

מה לבדוק בפועל:

• ניגודיות טקסטים מול הרקע (לפחות 4.5:1 לטקסט רגיל)
• ניגודיות במצבי פוקוס, הובר וטעויות בטופס
• ניגודיות באייקונים חשובים או כפתורים
• אם הצבעים לא עומדים בדרישות התקן ולא רוצים לשנות את הצבעים, ניתן להוסיף מנגנון המאפשר שינוי של הצבעים בעת לחיצה

 נגישות לקורא מסך

בדיקות עם תוכנת NVDA או VoiceOver (ולא רק בדיקות אוטומטיות) הן הכלי הכי יעיל למציאת בעיות נגישות עבור עיוורים. שימוש בתוכנה קוראת מסך יאפשר לכן גם איך עיוורים חווים את האתרבעת שימוש בתוכנה קורא מסך.

מה לבדוק בפועל:

• הקראת כותרות, תפריטים, קישורים, טפסים
• בדיקת כיווניות שפה ( (dir="rtl"  לעברית
• סדר קריאה לוגי ומדויק

תפקידים ו-ARIA

לא מספיק לשים <div>  לעצב. חשוב שגם דפדפן וטכנולוגיות מסייעות יבינו מה האלמנט עושה.

מה לבדוק בפועל:

• שימוש בתגיות סמנטיות (main, nav, button, form...)
• שימוש נכון בתכונות aria-label, aria-expanded וכו'
• הימנעות משימוש שגוי או מיותר ב־ARIA
• אם אתם לא בקיאים בשימוש של חוקי ARIA  בצעו חיפוש קטן או העזרו בצט AI כזה או אחר

בדיקות במובייל ובמצבים שונים

מה שנגיש בדסקטופ – לא תמיד עובד טוב בנייד.

מה לבדוק בפועל:

• תפעול במובייל עם קורא מסך
• זום עד 200% בלי שבירה
• לבדוק שיש מעבר נוח בין שדות ומרכיבים

 הצהרת נגישות

בעל האתר חשוף לתביע אם אין באתר הצהרת נגישות. 

מה לבדוק בפועל:

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

 קבצים

כל קובץ העולה לאתר האינטרנט חייב בהנגשה בהתאם לתוכנה שבה הוא נוצר או נערך. (pdf, word, excel, power point,  וכו') יש לוודא שהוא עלה נגיש או לבקש פורמט נגיש.

רכיבים צד ג'

רכיבים צד ג' לא תמיד נגישים ולעיתים כדי לקבל גרסה נגישה יש לבקש זאת במפורש.

מה לבדוק בפועל:

• יש לוודא מול הספק שמקבלים גרסה שהיא נגישה.
• אם השירות צד ג' (כל גורם המספק קוד משלו לאתר) הוא קריטי לקבלת השירות או מוצר מצד הלקוחות והשירות עצמו אינו נגיש – אין להשתמש בו.

לסיכום

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

ארגון שבודק נגישות באופן קבוע מראה לא רק שהוא עומד בדרישות – אלא שהוא באמת רואה את האנשים שמעבר למסך.

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