חנות WooCommerce היא אחד הסוגים הקשים ביותר להנגשה, לא בגלל ה-theme אלא בגלל מה שקורה אחרי הקליק: טפסים, סינון מוצרים, עגלה וצ׳קאאוט. דווקא במקומות שמייצרים את ההכנסה, רוב החנויות נכשלות ב-audit. כאן נעבור על המוקדים החוזרים שבהם בדיקת נגישות מסמנת כשל, ומה צריך לתקן בכל אחד.
החובה החוקית בישראל היא ת"י 5568 ברמה AA (מכוח תקנה 35 לתקנות שוויון זכויות לאנשים עם מוגבלות), והתקן מבוסס על WCAG 2.0 ומתייחס גם ל-2.1. כלי audit אוטומטי בודק חלק מהקריטריונים, אבל את רוב הכשלים בחנות מגלים רק בבדיקה ידנית עם מקלדת וקורא מסך.
למה חנות קשה יותר מאתר תוכן
אתר תדמיתי הוא בעיקר טקסט ותמונות. חנות היא ממשק אינטראקטיבי: המשתמש בוחר וריאציות, מסנן לפי מחיר וצבע, מוסיף לעגלה, ממלא כתובת ופרטי תשלום. כל אינטראקציה כזו חייבת להיות נגישה במקלדת בלבד ולהיות מובנת לקורא מסך. ברגע שיש JavaScript שמשנה תוכן בלי לרענן את העמוד (עגלה נפתחת, פילטר מעדכן תוצאות), נוצרים כשלים שכלי אוטומטי לרוב לא תופס.
1. טפסים בלי תוויות מקושרות
זה הכשל מספר אחת בחנויות. שדה קלט חייב label מקושר נכון (דרך for/id או עטיפה), לא רק placeholder. placeholder נעלם ברגע שמתחילים להקליד, וקורא מסך לא תמיד מקריא אותו.
מוקדי הכשל הנפוצים:
- שדות חיפוש ומסננים עם אייקון זכוכית מגדלת בלי תווית טקסטואלית
- שדה "כמות" בעמוד מוצר בלי label מוצהר
- שדות צ׳קאאוט שמסתמכים על placeholder בלבד
- כפתורים שהם רק אייקון (פח אשפה למחיקת פריט, X לסגירה) בלי
aria-label
הבדיקה פשוטה: עברו על הטופס עם Tab בלבד וודאו שקורא מסך מכריז לכל שדה מה תפקידו. אם הוא אומר רק "תיבת טקסט" בלי שם, יש כשל.
2. הודעות שגיאה שלא מזוהות
צ׳קאאוט שנכשל בוולידציה (מיקוד שגוי, שדה חובה ריק) חייב להודיע למשתמש מה הבעיה ואיפה. בחנויות רבות ההודעה מופיעה ויזואלית באדום, אבל היא לא מקושרת לשדה ולא מוכרזת לקורא מסך. משתמש עיוור לוחץ "המשך", לא קורה כלום מבחינתו, והוא תקוע.
מה שצריך:
- ההודעה צריכה להיות זמינה לקורא מסך, בדרך כלל דרך
aria-liveאו קישור לשדה עםaria-describedby. - השדה השגוי צריך לקבל
aria-invalid="true". - אסור להסתמך על צבע בלבד כדי לסמן שגיאה. צריך גם טקסט או אייקון, כי משתמשים עם עיוורון צבעים לא יבחינו באדום.
- הפוקוס צריך לעבור לשדה הראשון שנכשל, כדי שהמשתמש ימצא אותו מיד.
3. פילטרים ותוצאות שמשתנות בלי הכרזה
מסנני מוצרים (AJAX filters) הם מלכודת קלאסית. המשתמש מסמן "עד 200 ש"ח", הרשת מתעדכנת, אבל מבחינת קורא מסך שום דבר לא קרה. אין הודעה כמה תוצאות נמצאו, והפוקוס נשאר תקוע.
הפתרון הוא אזור aria-live שמכריז על השינוי ("נמצאו 12 מוצרים"), וניהול פוקוס הגיוני אחרי העדכון. זה כמעט אף פעם לא מגיע מובנה מהתוסף, וצריך לסדר אותו ידנית או לבחור תוסף סינון שתומך בנגישות.
4. ניווט מקלדת בעגלה ובתפריט המוצר
עגלה צפה (mini-cart) שנפתחת בלחיצה, חלונית וריאציות מוצר, גלריית תמונות מוצר עם זום, פופאפ הוספה מהירה לעגלה. כל אלה הם רכיבים שמשתנים דינמית. הכשלים הנפוצים:
- אי אפשר להגיע לפריטים שבתוך העגלה הצפה במקלדת
- כשפותחים פופאפ, הפוקוס לא עובר אליו ולא "נלכד" בתוכו (focus trap), אז המשתמש ממשיך לנווט מאחורי החלון
- אין דרך לסגור פופאפ עם מקש Escape
- בורר וריאציות (צבע/מידה) שבנוי כ-swatches בלי תפקיד טופס אמיתי, ולא נבחר במקלדת
5. ניגודיות, גדלים ומיקוד נראה
מוקדים ויזואליים שכמעט תמיד נופלים בחנות:
- ניגודיות נמוכה בטקסט משני: מחיר לפני הנחה, תווית "אזל מהמלאי", טקסט סינון אפור בהיר. הדרישה היא יחס 4.5:1 לטקסט רגיל.
- מחוון מיקוד (focus indicator) שהוסר ב-CSS של ה-theme. בלי מסגרת נראית סביב האלמנט הפעיל, משתמש מקלדת לא יודע איפה הוא נמצא.
- כפתורי "הוסף לעגלה" קטנים מדי או צמודים מדי במובייל.
מחוון מיקוד שנמחק הוא תיקון של שורה אחת ב-CSS, אבל הוא קריטי. הרבה themes מסחריים מסירים אותו מטעמי אסתטיקה ובכך שוברים את הנגישות.
למה overlay לא פותר את זה
מפתה להתקין widget נגישות (accessiBe, UserWay, Vee) ולסמן וי. הבעיה: overlay מתקן רק חלק קטן מהקריטריונים, ולא נוגע כלל בלוגיקה של טפסים, הכרזות aria-live או ניהול פוקוס בצ׳קאאוט, שהם בדיוק הכשלים הכבדים בחנות. ב-2025 ה-FTC קנס את accessiBe בכמיליון דולר על טענת שווא שה-widget הופך אתר לתואם. overlay הוא לא עמידה בחוק. הרחבנו על כך במאמר למה תוסף נגישות overlay לא מספיק.
איך ניגשים לתיקון בפועל
הסדר ההגיוני:
- בדיקה ידנית עם מקלדת בלבד על המסלול הקריטי: עמוד מוצר -> הוספה לעגלה -> צ׳קאאוט -> אישור הזמנה.
- בדיקה עם קורא מסך על אותו מסלול.
- תיקון בקוד של ה-theme והתוספים, לא דרך widget.
- הוספת הצהרת נגישות לאתר שמתארת את מצב ההנגשה ואת דרכי הפנייה.
מי שמטפל בחנות לבד יכול לסגור חלק מהמוקדים, אבל ניהול פוקוס וצ׳קאאוט נגיש דורשים בדרך כלל התערבות מפתח. כדאי גם לזכור שהנגשה היא לא משימה חד-פעמית: כל עדכון theme או תוסף עלול לשבור מחדש את מחוון המיקוד או הוולידציה.
הקשר לחוק ולסיכון בפועל
חנות פעילה כמעט תמיד חוצה את ספי החבות. פסיקת מאור מ-2024 (ת"צ בן אור נ' אביב) צמצמה את תופעת התביעות הסדרתיות, חייבה פנייה מוקדמת ו-60 יום לתיקון, ופסקה פיצויים זעומים. כלומר הסיכון המשפטי המיידי נמוך מכפי שמוכרים לכם סוכני הפחדה, אבל החובה החוקית קיימת, וחנות לא נגישה גם מאבדת לקוחות אמיתיים בצ׳קאאוט. רקע מלא על הספים והפסיקה יש במאמר כמה עולה הנגשת אתר ומה הקנס, ועל התקן עצמו במדריך הנגשת אתר וורדפרס לפי תקן 5568.
אחריות 360 של OCW
הנגשת חנות לא נשארת תקינה לבד. כל עדכון תוסף עלול לשבור שדה או מחוון מיקוד, ואז ה-audit שעבר אתמול נכשל היום. חבילת אחריות 360 של OCW מחזיקה את הנגישות יחד עם אבטחה, פרטיות ותחזוקה טכנית תחת מעקב שוטף, כך שהמסלול הקריטי בחנות נשאר נגיש לאורך זמן. אפשר גם להזמין בדיקת נגישות חד-פעמית ותיקון ממוקד למסלול הרכישה. לפנייה: צרו קשר.
שאלות נפוצות
למה ה-audit האוטומטי שלי עבר אבל עדיין יש בעיה?
כלים אוטומטיים בודקים חלק מהקריטריונים בלבד, בעיקר HTML סטטי. את הכשלים הכבדים בחנות, כמו ניהול פוקוס בצ׳קאאוט והכרזת תוצאות סינון, מגלים רק בבדיקה ידנית עם מקלדת וקורא מסך.
האם תוסף נגישות מספיק לחנות WooCommerce?
לא. overlay מטפל בחלק קטן מהקריטריונים ולא נוגע בלוגיקת הטפסים, הוולידציה והפוקוס, שהם בדיוק הכשלים בחנות. הוא גם אינו נחשב עמידה בחוק.
מה המוקד הראשון שכדאי לתקן?
מסלול הרכישה: עמוד מוצר, הוספה לעגלה וצ׳קאאוט. שם נמצאים גם הסיכון החוקי הגבוה וגם אובדן הלקוחות בפועל, אז זה ה-ROI הגבוה ביותר.