בדיקת נגישות למובייל: איתור ותיקון הפרות לפני בדיקת חנות האפליקציות

בתרגול שלנו, VoiceOver באייפון קורא "כפתור" במקום "הוסף לעגלה" — כי UIImageView עם אייקון העגלה חסר accessibilityLabel. משתמש עם לקות ראייה מקיש בעיוורון. זה לא תיאורטי: 2.2 מיליארד אנשים סובלים מלקויות ראייה, ואפל/גוגל דוחות כיום אפליקציות עם הפרות נגישות חמורות במהלך הבדיקה. אנחנו צוות מהנדסים עם 6 שנות ניסיון בפיתוח מובייל; השלמנו מעל 40 ביקורות נגישות. אנו מבצעים ביקורות נגישות ומבטיחים עמידה בWCAG 2.1 AA.

מדוע accessibilityLabel כל כך חסר?

רכיבים מותאמים אישית — מחוונים, כפתורים מותאמים, אלמנטים עם אייקון בלבד — חסרים תוויות אוטומטיות. VoiceOver קורא קואורדינטות או שמות מחלקות. ב-iOS יש להגדיר במפורש accessibilityLabel ו-accessibilityHint. באנדרואיד — contentDescription ב-XML או דרך ViewCompat.setAccessibilityDelegate. מפתחים שוכחים לעתים קרובות להגדיר תווית בעת יצירת תצוגה מותאמת. ב-70% מהמקרים, הבעיה נפתרת על ידי הוספת שורת קוד אחת.

כיצד לנהל נכון את הפוקוס לאחר סגירת מודאל?

לאחר סגירת מודאל, הפוקוס של VoiceOver/TalkBack נשאר על אלמנטים שאינם על המסך — המשתמש הולך לאיבוד. ב-iOS אנו שולטים באמצעות UIAccessibility.post(notification: .screenChanged, argument: targetView). באנדרואיד — ViewCompat.setAccessibilityPaneTitle ו-sendAccessibilityEvent(AccessibilityEvent.TYPE_WINDOW_STATE_CHANGED). בדיקה ידנית של תרחיש זה היא חובה: כלים אוטומטיים לא תמיד תופסים אובדן פוקוס.

כלי בדיקה

Accessibility Inspector (Xcode). הפעלה דרך Xcode → Open Developer Tool → Accessibility Inspector. בדיקה בלחיצה אחת מוצאת תוויות חסרות, אזורי מגע קטנים, בעיות ניגודיות. עובד על סימולטור ומכשיר אמיתי.

Accessibility Scanner (אנדרואיד). אפליקציה של גוגל שסורקת את המסך ומפרטת בעיות לפי סוג. משתלבת ב-Espresso דרך AccessibilityChecks.enable() — מריצה אוטומטית בדיקות על כל פעולת בדיקה:

@Before fun setup() { AccessibilityChecks.enable() .setRunChecksFromRootView(true) } 

כל בדיקת Espresso עכשיו בנוסף מאמתת נגישות — כל הפרה מכשילה את הבדיקה. Accessibility Scanner מעבד מסך תוך 2–3 שניות, פי 5 מהר יותר מבדיקות ידניות.

בדיקה ידנית עם VoiceOver/TalkBack. אנו עוברים על תרחישי מפתח: הרשמה, רכישה, זרימת משתמש ראשית — תוך שימוש רק במחוות של קורא מסך, ללא משוב חזותי. זה תופס בעיות סמנטיות שכלים אוטומטיים מפספסים: סדר קריאה הגיוני, ניסוח תווית לא ברור, פוקוס אבוד.

axe DevTools Mobile. כלי מסחרי עם סיווג מפורט של הפרות לפי WCAG. מספק דוח עם חומרה והפניות לקריטריונים. שימושי להכנה לעמידה בחוק הנגישות האירופי (EU Accessibility Act).

מתי נדרשת בדיקה ידנית?

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

מטריצת ביקורת

השוואת כלים

התהליך שלנו

1. ביקורת — ריצה דרך Accessibility Inspector ו-Scanner, קבלת רשימה ממוינת של הפרות.
2. אוטומציה — הוספת @Before fun setup() { AccessibilityChecks.enable() .setRunChecksFromRootView(true) } לבדיקות Espresso כך שכל פעולה בודקת נגישות.
3. בדיקה ידנית — מעבר על תרחישי מפתח עם VoiceOver ו-TalkBack, תיעוד בעיות סמנטיות.
4. דוח — תיעוד כל ההפרות מסווגות לפי WCAG 2.1 (A/AA) עם המלצות לתיקון.

מה כלול

אנו מספקים דוח מפורט עם ההפרות שנמצאו וחומרתן, המלצות לתיקון לכל סוג שגיאה, בדיקות אוטומטיות מעודכנות עם בדיקות נגישות מופעלות, מדריך קצר לצוות iOS/אנדרואיד למניעת רגרסיות, ותעודת עמידה ב-WCAG 2.1 AA (לפי בקשה). לפי קריטריון הצלחה 1.4.3 של WCAG 2.1, יחס הניגודיות המינימלי לטקסט רגיל הוא 4.5:1.

לוחות זמנים ותמחור

ביקורת של אפליקציה ממוצעת אורכת 2–4 ימים. תיעוד מלא לחוק הנגישות האירופי עשוי להוסיף עוד יומיים. התמחור מחושב באופן אישי לפי מספר המסכים ומורכבות התרחישים. צרו קשר — נעריך את הפרויקט שלכם ונציע תוכנית אופטימלית. בקשו ייעוץ נגישות עוד היום.

טעויות נפוצות ביישום נגישות

• ניגודיות נמוכה ב-placeholders ובהנחיות — לעתים קרובות שימוש באפור #999999 על לבן.
• כפתורים קטנים בסרגלי ניווט ובסרגלי כלים — פחות מ-44pt/48dp.
• התעלמות ממחוות — אם יש החלקה למחיקה, יש לשכפל אותה עם לחיצה ארוכה.