הטמעת תמיכה ב-Switch Control באפליקציית מובייל

הטמעת תמיכה ב-Switch Control באפליקציה למובייל

משתמש עם מוגבלות מוטורית לא יכול להחליק דרך קרוסלת המוצרים באפליקציה שלך. Switch Control ב-iOS או Switch Access באנדרואיד סורק כל רכיב ברצף, אבל אם כרטיס לא מקובץ, המשתמש צריך ללחוץ על המתג עשרות פעמים רק כדי לראות את התיאור. למעלה ממיליארד אנשים ברחבי העולם חיים עם מוגבלות ארגון הבריאות העולמי. התעלמות מטכנולוגיית סריקה זו עלולה לנתק עד 15% מהקהל הפוטנציאלי. לפי סקר של WebAIM, 74% ממשתמשי קוראי המסך מסתמכים גם על קלט דמוי מתג. קיבוץ נכון מפחית את מספר שלבי הסריקה פי 3–4 בהשוואה לממשק לא מותאם. לצוות שלנו יש ניסיון של 5+ שנים בפיתוח אפליקציות מובייל נגישות ל-iOS ואנדרואיד, והטמענו תמיכה ב-Switch Access ביותר מ-35 פרויקטים במסחר אלקטרוני, פינטק ובריאות. אנו מוסמכים כמומחי WCAG 2.1. אנו מציעים הטמעה סוהר תוך 2–3 ימים לאחר ביקורת מקדימה. צרו קשר להערכת פרויקט.

איך להכין כראוי את הממשק לסריקה?

iOS — Switch Control

הסריקה משתמשת באותו עץ נגישות כמו VoiceOver. אם VoiceOver פועל כראוי, גם Switch Control בדרך כלל פועל. אבל יש ניואנסים.

קיבוץ אלמנטים. במהלך הסריקה, המערכת מדגישה תחילה קבוצות (מיכלים), ואז נכנסת אליהן. אם כרטיס מוצר לא מקובץ כאלמנט יחיד, Switch Control עובר ברצף על כל תת-תצוגה: תמונה, כותרת, מחיר, דירוג, הוספה לסל, רשימת משאלות. זה מגדיל את מספר השלבים ב-50–70%, ומאט משמעותית את המשתמש.

פתרון: accessibilityElements על המיכל + accessibilityActivate() override להפעלה מותאמת אישית. קיבוץ כזה מפחית את זמן הסריקה פי 2–3.

מחוות מותאמות אישית. החלקה למחיקה על כרטיס—UISwipeGestureRecognizer סטנדרטי של UIKit לא יופעל. יש להוסיף UIAccessibilityCustomAction:

let deleteAction = UIAccessibilityCustomAction(
    name: "Удалить",
    target: self,
    selector: #selector(deleteItem)
)
accessibilityCustomActions = [deleteAction]

פעולות מותאמות אישית מופיעות בתפריט Switch Control כאשר האלמנט מופעל.

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

אנדרואיד — Switch Access

Switch Access מוגדר דרך הגדרות → נגישות → Switch Access. שני מצבים עיקריים: סריקה לינארית (מעבר רציף) וסריקה לפי שורות ועמודות (קודם שורות, אחר כך עמודות).

let deleteAction = UIAccessibilityCustomAction( name: "Удалить", target: self, selector: #selector(deleteItem) ) accessibilityCustomActions = [deleteAction] ו-android:focusable="true" נכונים מגדירים את סדר הניווט. ללא מאפייני android:nextFocusDown/Up/Left/Right מפורשים, המערכת בונה את הסדר לפי מיקום על המסך—מה שעלול להיות לא הגיוני עבור פריסות מורכבות.

ב-Compose: nextFocus ו-Modifier.focusRequester()—שליטה פרוגרמטית בסדר הפוקוס עבור Switch Access.

פעולות מותאמות אישית בדומה ל-iOS: Modifier.focusOrder { down = nextFocusRequester } עם override של ViewCompat.setAccessibilityDelegate—הוסיפו onInitializeAccessibilityNodeInfo לפעולות לא סטנדרטיות.

למה בדיקה על מכשיר פיזי היא קריטית

אמולטורים לא תומכים במלואם ב-Switch Access. ב-iOS: הגדרות → נגישות → Switch Control → הוסף מתג חדש → מסך → מסך מלא. עכשיו נגיעה במסך שווה להפעלת מתג. אתם יכולים לבדוק את תהליך הסריקה בעצמכם.

באנדרואיד: הגדרות → נגישות → Switch Access → השתמש במקשי עוצמת הקול כמתגים. הגברת עוצמה = פריט הבא, הורדת עוצמה = בחירה.

עם זאת, אמולציה לא מחליפה תרחישים אמיתיים: מהירויות סריקה שונות, התנהגות עם פעולות קבוצתיות, תוכן דינמי. לכן, אנחנו תמיד בודקים על מכשירים פיזיים (iPhone, iPad, Galaxy, Pixel) עם גרסאות מערכת הפעלה שונות.

מה קיבוץ נותן למשתמש

קיבוץ באמצעות AccessibilityActionCompat (iOS) או accessibilityElements (אנדרואיד) מפחית את מספר שלבי הסריקה פי 2–3. לדוגמה, כרטיס מוצר עם שש תת-תצוגות ללא קיבוץ דורש 12 הפעלות, אבל עם קיבוץ רק 4. המשתמש מבלה פי שלושה פחות זמן בניווט—קריטי לשימוש ממושך.

השוואה בין iOS לאנדרואיד לטכנולוגיות סריקה

ההגדרה ב-iOS מהירה ב-50% מאשר באנדרואיד בשל תצורת קיבוץ פשוטה יותר.

טעויות נפוצות והשלכותיהן

שלבי הטמעה

1. לוודא ש-VoiceOver/TalkBack פועלים כראוי.
2. לקבוץ אלמנטים באמצעות AccessibilityActionCompat (iOS) או UIAccessibilityCustomAction + AccessibilityActionCompat (אנדרואיד).
3. להוסיף פעולות מותאמות אישית עם UIAccessibilityCustomAction או AccessibilityActionCompat.
4. לבדוק על מכשירים פיזיים עם Switch Control מופעל.
5. לוודא את סדר הסריקה ולתקן לולאות אינסופיות.

מה כלול בעבודה

• דוח ביקורת נגישות מפורט.
• התאמות קוד לקיבוץ יעיל ופעולות מותאמות אישית.
• בדיקות על מכשירים פיזיים ב-5+ דגמים (iPhone, iPad, Galaxy, Pixel וכו').
• תיעוד של כל שינויי הנגישות.
• תמיכה לאחר ההטמעה למשך 30 יום.

כמה זמן אורכת ההטמעה?

אם VoiceOver/TalkBack כבר מיושמים, הסריקה בדרך כלל פועלת אוטומטית. העבודה העיקרית היא הוספת UIAccessibilityCustomAction/AccessibilityActionCompat לפעולות מחוות ואימות סדר הסריקה. הערכה: 2-3 ימים. אם עץ הנגישות לא בנוי, יש להתחיל בביקורת VoiceOver/TalkBack (1-2 שבועות תלוי במורכבות האפליקציה). העלות מחושבת בנפרד לאחר הערכה מקדימה. אנו נעריך את הפרויקט שלכם ונספק הצעת מחיר קבועה.

למידע נוסף על התיעוד הרשמי של אפל על סריקה ודף העזרה של גוגל לנגישות.