Accessibility Label — co to jest, podstawy i jak używać dla iOS i Android

Co to jest Accessibility Label

Accessibility Label to właściwość tekstowa określająca nazwę elementu dla technologii asystujących. Gdy użytkownik przesuwa palcem po ekranie z włączonym VoiceOver, czytnik ekranu odczytuje Label elementu, na którym znajduje się fokus. Bez etykiety użytkownik słyszy tylko typ elementu: „przycisk”, „obraz” — bez określenia przeznaczenia.

Według Google I/O 2024, „Accessibility Testing”, 35% krytycznych naruszeń dostępności w aplikacjach sklepowych jest związanych z brakiem lub nieprawidłowym Label. Accessibility Scanner na Android wykrywa brak etykiety jako błąd najwyższej wagi.

Zasadnicze ograniczenie: Label nie powinien zawierać typu elementu. VoiceOver i TalkBack automatycznie dodają rolę (button, header, link) w komunikacie. Jeśli Label zawiera „Przycisk wysyłania”, użytkownik usłyszy: „Przycisk wysyłania, przycisk” — powielenie.

Label i WCAG 4.1.2: Name, Role, Value

WCAG 4.1.2 (poziom A) wymaga, aby każdy element interfejsu użytkownika miał programowo określoną nazwę (name), rolę (role) i wartość (value). Accessibility Label zapewnia name. Jeśli Label brakuje, kryterium jest uznawane za naruszone, a aplikacja nie przechodzi podstawowej certyfikacji.

iOS: właściwość accessibilityLabel

W iOS accessibilityLabel jest dziedziczony przez wszystkie UIView z protokołu UIAccessibility. Jeśli element zawiera tekst (UIButton z title, UILabel z text), Label jest automatycznie ustawiany na ten tekst. Dla UIImageView, niestandardowych kontrolek i kontenerów Label trzeba ustawić ręcznie.

Przykład dla niestandardowej komórki tabeli:

class CustomTableViewCell: UITableViewCell {
    let titleLabel = UILabel()
    let priceLabel = UILabel()

    override func awakeFromNib() {
        super.awakeFromNib()
        self.isAccessibilityElement = true
        self.accessibilityLabel =
            "\(titleLabel.text ?? "") - \(priceLabel.text ?? "")"
    }
}

Dla niestandardowych UIView można nadpisać getter accessibilityLabel:

class RatingView: UIView {
    var rating: Int = 5

    override var accessibilityLabel: String? {
        get { return "Ocena: \(rating) z 5" }
        set {}
    }
}

Apple HIG, 2024 zaleca: jeśli element składa się z kilku subelementów (np. karta produktu z nazwą i ceną), połącz je w jeden accessibility-element złożoną etykietą. Ustaw isAccessibilityElement = true na rodzicu i false na dzieciach.

NSAttributedString i accessibilityLabel

Jeśli UILabel używa NSAttributedString, accessibilityLabel domyślnie jest równy .string (plain text). Jeśli potrzebujesz przekazać semantycznie inną wartość (np. ikona-symbol czytana jako „Gwiazda” zamiast symbolu ★), jawnie ustaw accessibilityLabel. VoiceOver nie czyta symboli Unicode w sposób zrozumiały.

Android: Label przez contentDescription

W Android contentDescription pełni funkcję Label dla ImageView, ImageButton i niestandardowych View. Dla TextView i Button z wbudowanym tekstem nie trzeba ustawiać contentDescription — TalkBack czyta tekst automatycznie.

Programowe ustawienie przez Kotlin:

binding.iconStar.contentDescription = "Produkt w ulubionych"

// Dla niestandardowego widoku z wieloma elementami
binding.customCard.setContentDescription(
    "\(title) za kwotę \(price)")

W XML dla elementów dekoracyjnych:

<ImageView
    android:contentDescription="@null"
    android:src="@drawable/divider"
    android:importantForAccessibility="no" />

Właściwość importantForAccessibility = "no" całkowicie wyklucza element z drzewa dostępności. W iOS odpowiednik to isAccessibilityElement = false.

Compose: semantics i contentDescription

W Jetpack Compose Label ustawia się przez modyfikator semantics:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Wyszukiwanie produktów",
    modifier = Modifier.semantics {
        contentDescription = "Wyszukiwanie produktów"
    }
)

W Compose contentDescription to obowiązkowy parametr dla Image — bez niego kod się nie skompiluje (warning). To wymusza poprawę dostępności poprzez projekt API.

Label i Hint: różnica ról

Accessibility Label odpowiada na pytanie „Co to za element?”. Hint (accessibilityHint w iOS, dodatkowy tekst w contentDescription w Android) — „Co się stanie przy interakcji?”. VoiceOver wypowiada je kolejno: najpierw Label, potem Hint.

Przykład dla przycisku usuwania:

• Label: „Usuń”
• Hint: „Nieodwracalnie usunie wybrane zdjęcie”
• VoiceOver: „Usuń. Nieodwracalnie usunie wybrane zdjęcie”

Według Deque University, 2024, prawidłowe rozdzielenie Label i Hint zwiększa wskaźnik powodzenia wykonywania zadań dla użytkowników VoiceOver o 28%. Użytkownicy z zaburzeniami poznawczymi są szczególnie zależni od Hint: ryzykując naciśnięcie „Usuń” bez wyjaśnienia, 40% rezygnuje z działania.

Kiedy Hint nie jest potrzebny

• Element z intuicyjnie zrozumiałym działaniem („Wstecz”, „Zamknij” — Label wystarczy)
• Label już opisuje wynik („Wyślij wiadomość” — czasownik w samej nazwie)
• Systemowe kontrolki (UISwitch, UIButton z typem systemowym) — ich zachowanie jest standardowe

Błędy z praktyki: Label zamiast Hint

Częsty błąd: w Label piszą „Przycisk usuwania” zamiast „Usuń”. Typ elementu (Button) jest dodawany przez VoiceOver automatycznie poprzez trait. W rezultacie użytkownik słyszy: „Przycisk usuwania, przycisk” — powielenie. Prawidłowy Label: „Usuń”, Hint: „Usunie wybrane zdjęcie”.

Lokalizacja i najlepsze praktyki

Lokalizacja etykiet jest obowiązkowa — odbywa się poprzez standardowe mechanizmy: NSLocalizedString w iOS, zasoby ciągów @string/ w Android. Nigdy nie ustawiaj Label przez konkatenację po angielsku bez lokalizacji.

Zasady dobrego Label, oparte na W3C WCAG 2.2:

• Zaczynaj od słowa kluczowego — „Wyszukiwanie produktów”, a nie „Pole do wyszukiwania produktów”
• Nie dołączaj słowa „przycisk”, „pole”, „obraz” — rola jest dodawana automatycznie
• Używaj naturalnego języka, zrozumiałego dla docelowej grupy odbiorców
• Unikaj skrótów (poza powszechnie przyjętymi: „szt.”, „kg.”) — czytnik ekranu odczytuje je dosłownie
• Dla elementów wejścia dodawaj przykład: „Email (example@domain.com)”

Spójność Label w ramach marki

Używaj jednolitego glosariusza dla Label w aplikacji. Jeśli na jednym ekranie jest napisane „Ulubione”, a na drugim „Zakładki”, użytkownik jest zdezorientowany. Stwórz tabelę terminów dostępności — uzgodnij z projektantami i lokalizatorami.

Label dla elementów formularzy

Dla pól wprowadzania (UITextField, EditText) Label powinien być zgodny z placeholderem lub tytułem pola. Jednak placeholder często znika po wprowadzeniu tekstu. Używaj accessibilityLabel dla stałej nazwy i accessibilityValue dla bieżącej zawartości pola — to standard WCAG 4.1.2. Rozwiązanie: ustaw accessibilityLabel statycznie (równy tytułowi pola), a accessibilityValue dynamicznie (równy wprowadzonemu tekstowi). W iOS jest to automatyczne, ale dla niestandardowych pól — ręcznie przez nadpisanie accessibilityValue. Sprawdź, czy VoiceOver czyta: „Email, example@domain.com, pole tekstowe” zamiast „, pole tekstowe”.

Jak testować etykiety dostępności

Zautomatyzowane testowanie to jedyny sposób zagwarantowania poprawności Label na wszystkich ekranach. iOS udostępnia XCUIApplication z dostępem do .label, Android — AccessibilityCheckRule i setContentDescription.

Przykład testu dla iOS:

func testLabelsAreUnique() {
    let app = XCUIApplication()
    app.launch()
    let allButtons = app.buttons.allElementsBoundByIndex
    let labels = allButtons.compactMap { $0.label }
    let uniqueLabels = Set(labels)
    XCTAssertEqual(labels.count, uniqueLabels.count,
        "Znaleziono duplikujące się Label")
}

Przykład dla Android z Espresso:

@Test
fun testButtonHasAccessibilityLabel() {
    onView(withId(R.id.btnSubmit))
        .check(matches(
            withContentDescription(containsString("Wyślij"))
        ))
}

Testowanie ręczne: włącz VoiceOver (iOS) lub TalkBack (Android) i przesuń gestem w prawo po wszystkich elementach ekranu. Każdy element powinien otrzymać sensowny komunikat. Jeśli słyszysz tylko „przycisk” lub „obraz” — Label brakuje.

Rotor VoiceOver i szybka nawigacja

Po skonfigurowaniu Label użytkownik VoiceOver może używać rotora do szybkiej nawigacji: tryby „Przyciski”, „Nagłówki”, „Linki” i inne. Jeśli Label jest poprawnie ustawiony, VoiceOver włącza element do odpowiedniego trybu rotora. Sprawdź, czy wszystkie przyciski są widoczne w trybie „Przyciski”, a wszystkie nagłówki w „Nagłówki”.

Label wpływa również na wyszukiwanie VoiceOver. Użytkownik może wpisać słowo w trybie wyszukiwania, a VoiceOver przeniesie fokus na element z pasującym Labelem. Dlatego w Label powinny znajdować się słowa kluczowe, po których użytkownik będzie szukać elementu.

Integracja z pipeline CI/CD

Dodaj sprawdzanie Label do pipeline. Na iOS używaj XCUITest z fastlane scan. Na Android — Accessibility Test Framework z regułą AccessibilityCheckRule, która wykrywa puste contentDescription. Zapobiega to regresjom przy scalaniu nowych ekranów.