עקרונות לשיפור הנגישות של אפליקציות

כדי לסייע למשתמשים עם צורכי נגישות, המסגרת של Android מאפשרת יצירת שירות נגישות שיכול להציג למשתמשים תוכן מאפליקציות וגם להפעיל אפליקציות בשמם.

מערכת Android מספקת כמה שירותי נגישות למערכת, כולל השירותים הבאים:

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

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

כל אחת מהשיטות המומלצות הבאות מתוארת בסעיפים הבאים, יכול לשפר עוד יותר את הנגישות של האפליקציה:

רכיבי תווית

המשתמשים חייבים להיות מסוגלים להבין את התוכן והמטרה של כל אירוע אינטראקטיבי וגם רכיב ממשק משתמש משמעותי באפליקציה.

הוספת פעולות נגישות

הוספת פעולות נגישות תאפשר לך להפעיל את משתמשי הנגישות כדי להשלים תהליכים קריטיים של משתמשים בתוך האפליקציה.

הרחבת ווידג'טים של המערכת

להסתמך על רכיבי התצוגה שכלולים ב-framework, ולא על יצירת תצוגות מותאמות אישית משלכם. התצוגה וסיווג הווידג'טים של ה-framework כבר מספקות את רוב יכולות הנגישות שהאפליקציה צריכה.

משתמשים ברמזים שאינם צבע

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

שיפור הנגישות של תוכן המדיה

להוסיף תיאורים לתוכן הווידאו או האודיו של האפליקציה כדי שמשתמשים יוכלו שצורכים את התוכן הזה לא צריכים להסתמך על סימנים ויזואליים או אודיויים לחלוטין.

רכיבי תווית

חשוב לספק למשתמשים תוויות שימושיות ותיאוריות לכל רכיב בממשק משתמש אינטראקטיבי באפליקציה שלך. כל תווית צריכה להסביר את המשמעות למטרה של אלמנט מסוים. קוראי מסך כמו TalkBack יכולים להכריז את התוויות האלה למשתמשים.

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

רכיבים שניתנים לעריכה

כשאתם מוסיפים תוויות לרכיבים ניתנים לעריכה, כמו EditText אובייקטים, כדאי להציג אותם טקסט שנותן דוגמה לקלט חוקי ברכיב עצמו, בנוסף להפוך את הטקסט לדוגמה הזה לזמין לקוראי מסך. במצבים כאלה, יכול להשתמש במאפיין android:hint, כפי שמוצג בקטע הקוד הבא:

<!-- The hint text for en-US locale would be
     "Apartment, suite, or building". -->
<EditText
   android:id="@+id/addressLine2"
   android:hint="@string/aptSuiteBuilding" ... />

במצב הזה, לאובייקט View צריך להיות מאפיין android:labelFor משלו מוגדר למזהה של הרכיב EditText. פרטים נוספים זמינים במאמרים הבאים .

זוגות של אלמנטים שבהם אחד מתאר את השני

לעיתים קרובות לרכיב EditText יש אובייקט View שמתאר מה המשתמשים חייבים מזינים ברכיב EditText. אפשר לציין את הקשר הזה באמצעות הגדרה המאפיין android:labelFor של האובייקט View.

בקטע הקוד הבא מוצגת דוגמה לתיוג של זוגות רכיבים כאלה:

!<-- Label text for en-US locale would be "Username:" --
>T<extView
   android:id="@+id/usernameLabel" ...
   android:text="@string/username"
   android:labelFor="@+id/usernameEntry" /
>
E<ditText
   android:id="@+id/usernameEntry" ... /
>
!<-- Label text for en-US locale would be "Password:" --
>T<extView
   android:id="@+id/passwordLabel" ...
   android:text="@string/password
   android:labelFor="@+id/passwordEntry" /
>
E<ditText
   android:id="@+id/passwordEntry"
   android:inputType="textPassword" ... /
>

רכיבים באוסף

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

בפרט, תכלול טקסט נוסף או מידע הקשרי רכיבים בפריסות שנעשה בהן שימוש חוזר - כמו RecyclerView אובייקטים – כך שכל רכיב צאצא מזוהה באופן ייחודי.

כדי לעשות זאת, צריך להגדיר את תיאור התוכן כחלק מהטמעת המתאם, מוצגת בקטע הקוד הבא:

data class MovieRating(val title: String, val starRating: Integer)

class MyMovieRatingsAdapter(private val myData: Array<MovieRating>):
        RecyclerView.Adapter<MyMovieRatingsAdapter.MyRatingViewHolder>() {

    class MyRatingViewHolder(val ratingView: ImageView) :
            RecyclerView.ViewHolder(ratingView)

    override fun onBindViewHolder(holder: MyRatingViewHolder, position: Int) {
        val ratingData = myData[position]
        holder.ratingView.contentDescription = "Movie ${position}: " +
                "${ratingData.title}, ${ratingData.starRating} stars"
    }
}

public class MovieRating {
    private String title;
    private int starRating;
    // ...
    public String getTitle() { return title; }
    public int getStarRating() { return starRating; }
}

public class MyMovieRatingsAdapter
        extends RecyclerView.Adapter<MyAdapter.MyRatingViewHolder> {
    private MovieRating[] myData;


    public static class MyRatingViewHolder extends RecyclerView.ViewHolder {
        public ImageView ratingView;
        public MyRatingViewHolder(ImageView iv) {
            super(iv);
            ratingView = iv;
        }
    }

    @Override
    public void onBindViewHolder(MyRatingViewHolder holder, int position) {
        MovieRating ratingData = myData[position];
        holder.ratingView.setContentDescription("Movie " + position + ": " +
                ratingData.getTitle() + ", " + ratingData.getStarRating() +
                " stars")
    }
}

קבוצות של תוכן קשור

אם באפליקציה מוצגים מספר רכיבים בממשק המשתמש שמהווים קבוצה טבעית, כמו פרטים של שיר או מאפיינים של הודעה, מסדרים את הרכיבים האלה בתוך שהוא בדרך כלל תת-מחלקה של ViewGroup. הגדרת מאגר התגים של האובייקט android:screenReaderFocusable ל-true, והפלט של כל אובייקט פנימי android:focusable ל-false. כך שירותי הנגישות יכולים להציג אלמנטים תיאורי תוכן, אחד אחרי השני, בהודעה אחת. איחוד של אלמנטים קשורים עוזר למשתמשים בטכנולוגיה מסייעת לגלות את המידע במסך בצורה יעילה יותר.

קטע הקוד הבא מכיל קטעי תוכן שקשורים לפריט אחד אחר, כך שלרכיב הקונטיינר, מופע של ConstraintLayout, המאפיין android:screenReaderFocusable מוגדר ל-true ולמאפיין הפנימי לכל רכיב TextView מוגדר המאפיין android:focusable false:

<!-- In response to a single user interaction, accessibility services announce
     both the title and the artist of the song. -->
<ConstraintLayout
    android:id="@+id/song_data_container" ...
    android:screenReaderFocusable="true">

    <TextView
        android:id="@+id/song_title" ...
        android:focusable="false"
        android:text="@string/my_song_title" />
    <TextView
        android:id="@+id/song_artist"
        android:focusable="false"
        android:text="@string/my_songwriter" />
</ConstraintLayout>

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

קבוצות בתוך קבוצות

אם ממשק האפליקציה מציג מידע רב-מימדי, כמו כדי להציג רשימה של אירועי הפסטיבל מדי יום, צריך להשתמש בפונקציה android:screenReaderFocusable בקונטיינרים הפנימיים של הקבוצה. סכמת התיוג הזו מספקת איזון בין מספר ההודעות שנדרשות כדי לגלות את תוכן מסוים ומשך כל הודעה.

קטע הקוד הבא מציג שיטה אחת לתיוג קבוצות בתוך קבוצות גדולות יותר:

<!-- In response to a single user interaction, accessibility services
     announce the events for a single stage only. -->
<ConstraintLayout
    android:id="@+id/festival_event_table" ... >
    <ConstraintLayout
        android:id="@+id/stage_a_event_column"
        android:screenReaderFocusable="true">

        <!-- UI elements that describe the events on Stage A. -->

    </ConstraintLayout>
    <ConstraintLayout
        android:id="@+id/stage_b_event_column"
        android:screenReaderFocusable="true">

        <!-- UI elements that describe the events on Stage B. -->

    </ConstraintLayout>
</ConstraintLayout>

כותרות בתוך הטקסט

באפליקציות מסוימות נעשה שימוש בכותרות כדי לסכם קבוצות של טקסט שמופיעות במסך. אם המיקום רכיב View מסוים מייצג כותרת, אפשר לציין את המטרה שלו לשירותי נגישות על ידי הגדרת שיוך android:accessibilityHeading אל true

משתמשים בשירותי הנגישות יכולים לבחור לנווט בין כותרות במקום בין פסקאות או בין מילים. הגמישות הזו משפרת את חוויית ניווט בטקסט.

כותרות של חלונית נגישות

ב-Android מגרסה 9 (רמת API 28) ואילך, אפשר לספק כותרות נוחות לנגישות לחלוניות המסך. לנגישות למטרות, חלונית היא חלק מובחן מבחינה חזותית מהחלון, של מקטע מסוים. לשירותי נגישות כדי להבין אופן הפעולה של החלונית הצדדית, צריך לתת כותרות תיאוריות לאפליקציות חלוניות. שירותי הנגישות יכולים לספק מידע מפורט יותר כשהמראה או התוכן של החלונית משתנים.

כדי לציין כותרת של חלונית, משתמשים ב android:accessibilityPaneTitle כפי שמוצג בקטע הקוד הבא:

<!-- Accessibility services receive announcements about content changes
     that are scoped to either the "shopping cart view" section (top) or
     "browse items" section (bottom) -->
<MyShoppingCartView
     android:id="@+id/shoppingCartContainer"
     android:accessibilityPaneTitle="@string/shoppingCart" ... />

<MyShoppingBrowseView
     android:id="@+id/browseItemsContainer"
     android:accessibilityPaneTitle="@string/browseProducts" ... />

אלמנטים דקורטיביים

אם רכיב בממשק המשתמש קיים רק לריווח חזותי או למראה חזותי למטרות, להגדיר android:importantForAccessibility ל-"no".

הוספת פעולות נגישות

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

הפיכת כל הפעולות לנגישות

משתמש של TalkBack, Voice Access או ש'גישה באמצעות מתג' עשויה להזדקק לדרכים חלופיות כדי להשלים תהליכי משתמש מסוימים בתוך את האפליקציה. בפעולות שמשויכות לתנועות כמו גרירה ושחרור או החלקות, האפליקציה יכולה לחשוף את הפעולות באופן נגיש למשתמשים שירותי נגישות.

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

לדוגמה, אם האפליקציה מאפשרת למשתמשים להחליק על פריט, אפשר גם לחשוף את הפונקציונליות באמצעות פעולת נגישות מותאמת אישית, כמו:

ViewCompat.addAccessibilityAction(
    // View to add accessibility action
    itemView,
    // Label surfaced to user by an accessibility service
    getText(R.id.archive)
) { _, _ ->
    // Same method executed when swiping on itemView
    archiveItem()
    true
}

ViewCompat.addAccessibilityAction(
    // View to add accessibility action
    itemView,
    // Label surfaced to user by an accessibility service
    getText(R.id.archive),
    (view, arguments) -> {
        // Same method executed when swiping on itemView
        archiveItem();
        return true;
    }
);

With the custom accessibility action implemented, users can access the action through the actions menu.

Make available actions understandable

When a view supports actions such as touch & hold, an accessibility service such as TalkBack announces it as "Double tap and hold to long press."

This generic announcement doesn't give the user any context about what a touch & hold action does.

To make this announcement more descriptive, you can replace the accessibility action’s announcement like so:

ViewCompat.replaceAccessibilityAction(
    // View that contains touch & hold action
    itemView,
    AccessibilityNodeInfoCompat.AccessibilityActionCompat.ACTION_LONG_CLICK,
    // Announcement read by TalkBack to surface this action
    getText(R.string.favorite),
    null
)

ViewCompat.replaceAccessibilityAction(
    // View that contains touch & hold action
    itemView,
    AccessibilityNodeInfoCompat.AccessibilityActionCompat.ACTION_LONG_CLICK,
    // Announcement read by TalkBack to surface this action
    getText(R.string.favorite),
    null
);

This results in TalkBack announcing "Double tap and hold to favorite," helping users understand the purpose of the action.

Extend system widgets

This section uses the example of implementing a special type of Switch called TriSwitch while following best practices around extending system widgets. A TriSwitch object works similarly to a Switch object, except that each instance of TriSwitch allows the user to toggle among three possible states.

Extend from far down the class hierarchy

The Switch object inherits from several framework UI classes in its hierarchy:

View
↳ TextView
  ↳ Button
    ↳ CompoundButton
      ↳ Switch

מומלץ שכיתת TriSwitch החדשה תורחב ישירות מ-Switch בכיתה. כך, הנגישות ב-Android framework מספק את רוב יכולות הנגישות המחלקה TriSwitch צריך:

• פעולות בנושא נגישות: מידע למערכת לגבי אופן הנגישות שירותים יכולים לחקות כל קלט אפשרי של משתמש שמבוצע ב-TriSwitch לאובייקט. (עוברת בירושה מ-View.)
• אירועי נגישות: מידע לגבי שירותי נגישות לגבי כל הדרך שבה המראה של אובייקט TriSwitch יכול להשתנות כאשר המסך מתבצע רענון או עדכונים. (עברה בירושה מ-View).
• מאפיינים: פרטים על כל אובייקט TriSwitch, כמו תוכן של כל טקסט שמוצג. (עברה בירושה מ-TextView).
• פרטי מצב: תיאור המצב הנוכחי של אובייקט TriSwitch, כמו 'סומן' או 'לא מסומן'. (עוברת בירושה מ-CompoundButton.)
• תיאור טקסט של מדינה: הסבר מבוסס-טקסט לגבי כל מדינה שמייצגת. (עוברת בירושה מ-Switch.)

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

הגדרת אירועים מותאמים אישית

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

הנחיה כללית היא שעבור כל קריאה חוזרת מבוססת-תצוגה שמבטלים, צריך גם להגדיר מחדש את פעולת הנגישות המתאימה על ידי ביטול ViewCompat.replaceAccessibilityAction() בבדיקות של האפליקציה, אפשר לאמת את ההתנהגות של הפעולות האלה שהוגדרו מחדש על ידי שיחות ViewCompat.performAccessibilityAction()

איך העיקרון הזה יכול לפעול באובייקטים של TriSwitch

בניגוד לאובייקט Switch רגיל, הקשה על אובייקט TriSwitch עוברת במחזורים של שלושת המצבים האפשריים. לכן, מידת הנגישות של ACTION_CLICK צריך לעדכן את הפעולה:

class TriSwitch(context: Context) : Switch(context) {
    // 0, 1, or 2
    var currentState: Int = 0
        private set

    init {
        updateAccessibilityActions()
    }

    private fun updateAccessibilityActions() {
        ViewCompat.replaceAccessibilityAction(this, ACTION_CLICK,
            action-label) {
            view, args -> moveToNextState()
        })
    }

    private fun moveToNextState() {
        currentState = (currentState + 1) % 3
    }
}

public class TriSwitch extends Switch {
    // 0, 1, or 2
    private int currentState;

    public int getCurrentState() {
        return currentState;
    }

    public TriSwitch() {
        updateAccessibilityActions();
    }

    private void updateAccessibilityActions() {
        ViewCompat.replaceAccessibilityAction(this, ACTION_CLICK,
            action-label, (view, args) -> moveToNextState());
    }

    private void moveToNextState() {
        currentState = (currentState + 1) % 3;
    }
}

שימוש ברמזים שאינם צבע

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

איור 1 מציג שתי גרסאות של פעילות. באחת מהגרסאות נעשה שימוש רק בצבע כדי להבדיל בין שתי פעולות אפשריות בתהליך העבודה. הגרסה השנייה משתמשת השיטה המומלצת ביותר היא לכלול צורות וטקסט בנוסף לצבע להדגיש את ההבדלים בין שתי האפשרויות:

שיפור הנגישות של תוכן מדיה

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

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

מקורות מידע נוספים

למידע נוסף על שיפור הנגישות של האפליקציה, אפשר לעיין במאמרים הבאים: משאבים נוספים:

שיעורי Lab

• הפעלת Android נגישות

פוסטים בבלוגים

• נגישות: האם אתם מעניקים שירות לכל הצרכים שלכם משתמשים?