נגישות אתרים: WCAG, קוראי מסך, ניווט מקלדת
באתר של בנק גדול, כפתור "שלח בקשה" סומן כ-<div class="btn" onclick="...">. קורא המסך NVDA לא הכריז עליו, Tab דילג עליו, ו-Enter לא עבד. עבור אלפי משתמשים עיוורים, הבנק הזה פשוט לא היה קיים כשירות מקוון. אנו רואים בעיות כאלה מדי יום בעשרות פרויקטים — ופיתוח אתרים נגישים לפי WCAG 2.2 AA הפך לדרך היחידה להימנע מאפליה וסיכונים משפטיים. קנסות על חוסר נגישות לגופים משפטיים יכולים להגיע לסכומים משמעותיים, ותביעות למיליונים.
בכרטיס זה — כיצד אנו גורמים לנגישות אתרים a11y לעבוד, בהתבסס על מקרים אמיתיים, עם תשתית טכנולוגית ספציפית ומספרים. ללא ביטויים כלליים.
מדוע סימון סמנטי הוא הבסיס לנגישות אתרים (a11y)?
רוב בעיות הנגישות נפתרות על ידי HTML נכון, לא על ידי מאפייני ARIA נוספים. <button> במקום <div onclick>, <nav> במקום <div class="navigation">, <h1>–<h6> בהיררכיה נכונה, <label for="field-id"> במקום <div class="label">. זו הרמה הבסיסית, אבל בפועל, כל טופס שני בחנויות מקוונות רוסיות אינו כולל תגי <label> נכונים.
ARIA נחוץ במקום שבו HTML טבעי אינו מספיק: רכיבים מותאמים אישית — תפריטים נפתחים, טולטיפים, חלונות מודאליים, טאבים, אקורדיונים. וכאן מתחילה המורכבות.
טעות אופיינית בתפריטים נפתחים מותאמים אישית: קורא המסך אינו יודע שזהו combobox, אינו מכריז על מספר האפשרויות, אינו אומר איזו נבחרה, והפוקוס אינו עובר לרשימה בעת פתיחתה. יישום נכון:
-
role="combobox"על שדה הקלט -
aria-expanded="true/false"בעת פתיחה/סגירה -
aria-controls="listbox-id"מצביע על הרשימה -
aria-activedescendant— מזהה הפריט הנבחר כעת -
role="option"ו-aria-selectedעל כל אפשרות
זו לא תיאוריה; זה נבדק עם קורא מסך. NVDA + Chrome או VoiceOver + Safari הם חלק חובה מ-QA.
דוגמת יישום של combobox מותאם אישית עם ARIA
<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0"> <label for="input-1">Выберите город</label> <input id="input-1" type="text" role="combobox" aria-autocomplete="list" /> <ul id="listbox-1" role="listbox" aria-label="Города"> <li role="option" aria-selected="false" id="opt-1">Москва</li> <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li> </ul> </div> העלות של תיקון הפרה אחת ברמה A משתנה בהתאם למורכבות. יישום a11y משלב התכנון מפחית את תקציב ה-refactoring פי 2–3 בהשוואה להתאמה של אתר שכבר גמור.
כיצד לבנות נכון ניווט מקלדת?
סדר ה-Tab צריך להתאים לסדר החזותי של האלמנטים. אם ב-HTML כפתור "ביטול" מופיע לפני "אישור", אבל CSS מחליף ביניהם — משתמש המקלדת מתבלבל.
מלכודת פוקוס בחלונות מודאליים. כאשר חלון מודאלי נפתח, Tab צריך לנוע רק בתוכו. בעת סגירה, יש להחזיר את הפוקוס לאלמנט שפתח את החלון. ללא זאת, המשתמש מוצא את עצמו בראש העמוד לאחר הסגירה.
<div role="combobox" aria-expanded="false" aria-controls="listbox-1" aria-activedescendant="" tabindex="0"> <label for="input-1">Выберите город</label> <input id="input-1" type="text" role="combobox" aria-autocomplete="list" /> <ul id="listbox-1" role="listbox" aria-label="Города"> <li role="option" aria-selected="false" id="opt-1">Москва</li> <li role="option" aria-selected="false" id="opt-2">Санкт-Петербург</li> </ul> </div> — אלמנט שאינו נכנס לרצף ה-Tab אך יכול לקבל פוקוס באמצעות קוד. משמש לאלמנטים שמקבלים פוקוס דרך JavaScript (כותרות מקטעים לאחר ניווט עוגן).
tabindex="-1" ומעלה הוא כמעט תמיד שגיאה. סדר מפורש שובר את הסדר הטבעי ויוצר התנהגות בלתי צפויה. שלטו בסדר דרך ה-DOM, לא דרך tabindex.
קישורי דילוג — קישור "דלג לתוכן", מוסתר ויזואלית, נראה בעת לחיצה על Tab. מאפשר למשתמשי קורא מסך לדלג על ניווט חוזר.
צבע וניגודיות: דרישות והפרות נפוצות
WCAG 2.2 AA דורש ניגודיות 4.5:1 לטקסט רגיל, 3:1 לטקסט גדול (18px+ או 14px+ מודגש). AAA דורש 7:1 ו-4.5:1.
ההפרות הנפוצות ביותר: placeholder אפור בשדות קלט (#999 על לבן = 2.9:1), טקסט משני אפור בהיר, טקסט לבן על רקע פסטלי.
צבע לא צריך להיות האינדיקטור היחיד: "שדות חובה מסומנים באדום" ללא כוכבית — הפרה עבור משתמשים עם עיוורון צבעים.
כלי בדיקה: axe DevTools, WAVE, Accessibility Inspector ב-Chrome DevTools. axe-core משתלב בבדיקות Playwright: בדיקה אוטומטית של 80+ כללים בכל deployment. בדיקה ידנית מוצאת כ-60% יותר שגיאות מאשר בדיקה אוטומטית.
מה חשוב לגבי תוכן מדיה ודינמיקה?
תמונות ללא tabindex="1" — כשל בסיסי נפוץ. alt צריך להיות משמעותי: לא alt, אלא תיאור של התוכן הרלוונטי להקשר. תמונות דקורטיביות — alt="image_123.jpg" (ריק, לא מאפיין חסר).
וידאו צריך לכלול כתוביות. כתוביות אוטומטיות של YouTube אינן תקן; הן עושות טעויות. קבצי WebVTT עם כתוביות נכונות לכל תוכן הווידאו החינוכי והשיווקי.
אנימציות — בעיה עבור משתמשים עם הפרעות וסטיבולריות. alt="" — media query שמשבית או מאט אנימציות עבור משתמשים עם הגדרת מערכת הפעלה זו.
מה השתנה ב-WCAG 2.2?
גרסה 2.2 נכנסה לתוקף עם קריטריונים חדשים:
| קריטריון | רמה | מהות |
|---|---|---|
| 2.5.7 תנועות גרירה | AA | כל פעולות הגרירה חייבות להיות בעלות חלופה למקלדת |
| 2.5.8 גודל מטרה | AA | גודל מינימלי של אלמנט אינטראקטיבי 24×24 פיקסלים |
| 3.2.6 עזרה עקבית | A | מיקום יצירת קשר/צ'אט צריך להיות זהה בכל העמודים |
| 3.3.7 הזנה מיותרת | A | אין לחייב הזנה חוזרת של אותו מידע באותו סשן |
קריטריונים אלה מעלים את הרף, אבל אנו כבר כוללים אותם ברשימת הבדיקה הסטנדרטית שלנו.
| רמה | ניגודיות טקסט מינימלית | ניגודיות טקסט גדול |
|---|---|---|
| AA | 4.5:1 | 3:1 |
| AAA | 7:1 | 4.5:1 |
ביקורת ותיקון
כלים אוטומטיים מוצאים כ-30–40% מההפרות. השאר הוא רק בדיקה ידנית. תרחיש מינימלי: לעבור על כל זרימת המשתמש הקריטית (הרשמה, רכישה, טופס) באמצעות מקלדת וקורא מסך בלבד.
תהליך
- ביקורת אוטומטית — axe-core, Lighthouse, WAVE — מפיקה 80+ כללים.
- בדיקה ידנית — NVDA, VoiceOver, מקלדת — 2–3 ימים לאתר טיפוסי.
- תיעדוף הפרות — P1 (חוסם שימוש), P2 (יוצר קשיים), P3 (שיפורים).
- תיקון — איטרטיבי, שילוב בדיקות ב-CI דרך Playwright + axe.
- ביקורת חוזרת — סגירת כל ה-P1/P2 לפני השקה.
- תיעוד ומסירה — דוח עם תוצאות, המלצות תחזוקה, הדרכת צוות.
תוצאות והיקף
- דוח ביקורת מלא עם תיעדוף הפרות (PDF/HTML)
- קוד מתוקן: סימון סמנטי, ARIA, ניווט מקלדת
- שילוב axe-core ב-CI/CD לבקרת רגרסיה
- הדרכה למפתחי הלקוח בנושא a11y (מפגש של שעתיים)
- גישה למאגר עם דוגמאות רכיבים נכונות
- התחייבות לעמידה ב-WCAG 2.2 AA במועד המסירה
לוח זמנים
| שלב | משך |
|---|---|
| ביקורת אתר (עד 50 עמודים) | 3–7 ימים |
| תיקון הפרות A/AA בפרויקט קיים | 3–8 שבועות |
| פיתוח פרויקט חדש בעמידה ב-WCAG 2.2 AA | החל מ-6 שבועות |
התקציב מחושב באופן אישי לאחר הביקורת. צרו קשר — נבחן את הפרויקט שלכם תוך יום אחד. קבלו ייעוץ ורשימת בדיקה חינם בהזמנת ביקורת.
ניסיון והתחייבויות
אנו עובדים בתחום נגישות אתרים a11y למעלה מ-8 שנים. השלמנו יותר מ-50 פרויקטים עבור בנקים, קמעונאות ומגזר ממשלתי. מומחים מוסמכים (IAAP CPACC, WAS). אנו מתחייבים לעמוד בביקורת צד שלישי או נתקן ללא עלות.
תקן WCAG 2.2 — המלצה רשמית של W3C המגדירה דרישות נגישות לתוכן אינטרנט. ויקיפדיה: הנחיות נגישות לתוכן אינטרנט ויקיפדיה: ARIA
— רמות נגישות אתרים a11y לפי גרסה 2.2.
הזמינו ביקורת עכשיו — קבלו רשימת בדיקה והערכה ראשונית. צרו קשר — נגיב תוך שעה.