גלו כיצד ליישם את VoiceOver, קורא המסך המובנה של אפל, המאפשר למשתמשים עיוורים ולקויי ראייה להשתמש במכשירי iOS. אם האפליקציה שלכם לא תומכת בו, משתמשים אלה פשוט לא יכולים להשתמש במוצר שלכם. אנו מבצעים ביקורת מקיפה ומיישמים VoiceOver מקצה לקצה, תוך הבטחת עמידה בתקני נגישות. לצוות שלנו ניסיון של למעלה מ-10 שנים והוא השלים למעלה מ-50 פרויקטי נגישות מוצלחים. עמידה מובטחת בתקן WCAG 2.1. צרו קשר להערכת האפליקציה שלכם.
למה VoiceOver חשוב לעסקים
לפי אפל, למעלה ממיליארד אנשים ברחבי העולם חיים עם מוגבלות, ו-70% ממשתמשי iOS עם מוגבלות משתמשים ב-VoiceOver באופן פעיל. התעלמות מקהל זה משמעותה אובדן חלק ניכר מלקוחות פוטנציאליים. יתרה מכך, חוזים ממשלתיים, בריאותיים וחינוכיים רבים דורשים עמידה ב-WCAG 2.1 או ב-Section 508. אפליקציות ללא VoiceOver נכשלות בדרישות אלה, ומגבילות את טווח השוק. אי-עמידה בדרישות עלולה גם להוביל לקנסות ולעונשים משפטיים. ביקורת אוטומטית יעילה פי 5 מבדיקה ידנית מבחינת מהירות, ותיקון בעיות במהלך הפיתוח עולה פי 3–5 פחות מאשר לאחר השחרור. השקעה בנגישות יכולה לחסוך עד 10,000 דולר בשנה בעלויות משפטיות פוטנציאליות ואובדן לקוחות.
אילו רכיבי אפליקציה נשברים ללא VoiceOver?
תצוגות UIView ו-SwiftUI מותאמות אישית
רכיבים סטנדרטיים UIButton, UILabel, UITextField — VoiceOver מבין אותם באופן מובנה. תצוגות מותאמות אישית UIView עם תוכן מצויר על CALayer — לא. VoiceOver רואה את כל התצוגה המותאמת אישית כאלמנט יחיד ללא תיאור.
עבור UIKit: isAccessibilityElement = true, accessibilityLabel, accessibilityHint, accessibilityTraits. accessibilityLabel מתאר מה זה (לדוגמה, "כפתור הוספה לסל"). accessibilityHint מסביר מה קורה בעת הפעלה (לדוגמה, "מוסיף את הפריט לסל וממשיך לתשלום"). accessibilityTraits מגדירים את סוג האלמנט (.button, .link, .image, .header, .selected).
| היבט | UIKit | SwiftUI |
|---|---|---|
| תווית | accessibilityLabel |
.accessibilityLabel() |
| רמז | accessibilityHint |
.accessibilityHint() |
| מאפיינים | accessibilityTraits |
.accessibilityAddTraits() |
| שילוב ילדים | מערך accessibilityElements |
.accessibilityElement(children: .combine) |
עבור נגישות ב-SwiftUI: השתמשו במודיפיירים .accessibilityLabel(), .accessibilityHint(), .accessibilityAddTraits(). כדי לשלב מספר תצוגות מקוננות לאלמנט נגיש אחד — .accessibilityElement(children: .combine) או .accessibilityElement(children: .ignore) עם תווית מפורשת.
תמונות ללא טקסט חלופי
UIImageView עם isAccessibilityElement = false (ברירת מחדל) — VoiceOver מדלג עליה. זה נכון עבור תמונות דקורטיביות. אבל עבור תמונות משמעותיות, נדרש accessibilityLabel. כפתורים עם אייקון בלבד: אם UIButton מכיל רק UIImageView ללא טקסט, הגדירו accessibilityLabel על הכפתור; אחרת, VoiceOver קורא את שם הקובץ או לא אומר כלום.
סדר מיקוד
VoiceOver עובר בין אלמנטים לפי accessibilityActivationPoint — בדרך כלל מרכז המסגרת. עבור פריסות מורכבות (שכבות, מיקום מוחלט ב-SwiftUI, מיכלים מותאמים אישית), הסדר יכול להיות כאוטי. ניתן לתקן באמצעות accessibilityElements על מיכל האב — מערך בסדר הרצוי:
override var accessibilityElements: [Any]? { get { [titleLabel, priceLabel, addButton] } set { } } ב-SwiftUI, השתמשו ב-override var accessibilityElements: [Any]? { get { [titleLabel, priceLabel, addButton] } set { } } כדי לשלוט בסדר.
מסכים מודאליים ושכבות מותאמות אישית
.accessibilitySortPriority() — VoiceOver מתמקד אוטומטית. שכבה מותאמת אישית UIAlertController מעל תוכן — לא. יש צורך ב-UIView כדי להעביר את המיקוד לאלמנט הראשון בשכבה. בעת סגירה, UIAccessibility.post(notification: .screenChanged, argument: firstElement) כדי להחזיר את המיקוד לכפתור שפתח את השכבה.
הגדירו post(notification: .screenChanged, argument: triggerButton) על מיכל השכבה כדי להסתיר את תוכן הרקע מ-VoiceOver. בלעדיו, משתמשים יכולים לעבור דרך השכבה לתוכן הרקע.
כיצד אנו מבצעים ביקורת ויישום: תהליך שלב-אחר-שלב
- הפעלת VoiceOver — Cmd+F5 בסימולטור או לחיצה משולשת על כפתור הבית/צד במכשיר. הגדרת VoiceOver היא השלב הראשון. עברו על כל הזרימות המרכזיות: התחברות, מסך ראשי, פעולות עיקריות (ביצוע הזמנה, שליחת הודעה, הפעלת מדיה).
- תיעוד בעיות — אלמנטים ללא תוויות, סדר מיקוד שגוי, אלמנטים בלתי נגישים, שכבות מודאליות ללא ניהול מיקוד.
- כלים — Accessibility Inspector (Xcode) בודק ניגודיות ומוצא אלמנטים ללא תוויות ללא הרצת האפליקציה. XCTest עם
accessibilityViewIsModal = true(iOS 17+) מספק ביקורת אוטומטית בבדיקות UI. - תיעדוף תיקונים — קודם ניווט וקריאות לפעולה מרכזיות, אחר כך רשימות וטפסים, ולבסוף תוכן מדיה.
השוואה בין בדיקה ידנית ואוטומטית:
| קריטריון | בדיקה ידנית | ביקורת אוטומטית |
|---|---|---|
| זמן למסך | 10–15 דקות | 1–2 דקות |
| כיסוי | סלקטיבי | מלא (כל האלמנטים) |
| דיוק | תלוי בבודק | עקבי |
| חזרתיות | נמוכה | גבוהה (ניתן להריץ ב-CI) |
מה כוללת העבודה
- ביקורת נגישות עם דוח לכל מסך וסדר עדיפויות לתיקונים.
- יישום תוויות נגישות, רמזים ומאפיינים לכל הרכיבים המותאמים אישית.
- הגדרת סדר מיקוד לפריסות מורכבות וחלונות מודאליים.
- אינטגרציה עם VoiceOver לתוכן דינמי (לדוגמה, עדכונים לאחר טעינה).
- בדיקות עם Accessibility Inspector ואימות ידני של תרחישים מרכזיים.
- תיעוד והמלצות לצוות לשמירה על נגישות בעדכונים עתידיים.
- אחריות לתמיכה למשך 30 יום לאחר היישום.
לוח זמנים: 3–5 ימים לאפליקציה בקנה מידה בינוני. העלות נקבעת באופן אישי — יישום טיפוסי לאפליקציה בינונית נע בין 2,000 ל-5,000 דולר; ביקורת בלבד מתחילה ב-1,000 דולר. צרו קשר, ונעריך את הפרויקט שלכם. קבלו ייעוץ לפרויקט שלכם — נעזור ליישם VoiceOver באיכות גבוהה. עם התאמה נכונה של האפליקציה לנגישות, תוכלו להגיע למיליוני משתמשים נוספים. שיפורי נגישות בממשק לא רק עוזרים למשתמשים עם מוגבלות, אלא גם משפרים את חוויית המשתמש הכוללת.
טעויות נפוצות ביישום VoiceOver
- שכחת הגדרת
XCUIAccessibilityAuditלכפתורים עם אייקון בלבד (תמונות בלבד). - אי שימוש ב-
accessibilityLabel, מה שגורם ל-VoiceOver לא להבחין בין כפתור לטקסט סטטי. - התעלמות מ-Dynamic Type — גופנים לא מתקשמים, טקסט נחתך.
- הזנחת סדר המיקוד במסכים עם אנימציות מותאמות אישית או שכבות.
על ידי הימנעות מטעויות אלה, אתם הופכים את האפליקציה שלכם לנגישה למיליוני משתמשים. ליישום VoiceOver ב-iOS, אנו מבטיחים תאימות מלאה ל-WCAG 2.1 עבור iOS.