Accessibility Label — wat is het, basisprincipes en hoe te gebruiken voor iOS en Android

Wat is Accessibility Label

Accessibility Label is een tekenreekseigenschap die de naam van het element voor ondersteunende technologieën definieert. Wanneer de gebruiker met zijn vinger over het scherm veegt met ingeschakelde VoiceOver, leest de schermlezer het Label voor van het element waarop de focus ligt. Zonder label hoort de gebruiker alleen het type element: „knop”, „afbeelding” — zonder aanduiding van de bestemming.

Volgens Google I/O 2024, „Accessibility Testing” houdt 35% van de kritieke toegankelijkheidsschendingen in winkelapps verband met het ontbreken of onjuist zijn van het Label. Accessibility Scanner op Android detecteert het ontbreken van een label als een fout van de hoogste ernst.

Principiële beperking: Label mag geen elementtype bevatten. VoiceOver en TalkBack voegen automatisch de rol (button, header, link) toe aan de aankondiging. Als Label „Verzendknop” bevat, hoort de gebruiker: „Verzendknop, knop” — duplicatie.

Label en WCAG 4.1.2: Name, Role, Value

WCAG 4.1.2 (niveau A) vereist dat elk element van de gebruikersinterface een programmatisch bepaalbare naam (name), rol (role) en waarde (value) heeft. Accessibility Label voorziet in de naam. Als Label ontbreekt, wordt het criterium als geschonden beschouwd en doorstaat de app de basiscertificering niet.

iOS: eigenschap accessibilityLabel

In iOS wordt accessibilityLabel door alle UIView-objecten overgeërfd van het UIAccessibility-protocol. Als het element tekst bevat (UIButton met title, UILabel met text), wordt Label automatisch ingesteld op deze tekst. Voor UIImageView, aangepaste bedieningselementen en containers moet Label handmatig worden ingesteld.

Voorbeeld voor een aangepaste tabelcel:

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

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

Voor aangepaste UIView kan de getter accessibilityLabel worden overschreven:

class RatingView: UIView {
    var rating: Int = 5

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

Apple HIG, 2024 adviseert: als het element uit meerdere subelementen bestaat (bijvoorbeeld een productkaart met naam en prijs), combineer ze dan in één toegankelijkheidselement met een samengesteld Label. Stel isAccessibilityElement = true in op de ouder en false op de kinderen.

NSAttributedString en accessibilityLabel

Als UILabel NSAttributedString gebruikt, is accessibilityLabel standaard gelijk aan .string (platte tekst). Als u een semantisch andere waarde moet doorgeven (bijvoorbeeld een pictogram-symbool dat wordt gelezen als „Ster” in plaats van het symbool ★), stel dan expliciet accessibilityLabel in. VoiceOver leest Unicode-symbolen niet op een zinvolle manier.

Android: Label via contentDescription

In Android vervult contentDescription de functie van Label voor ImageView, ImageButton en aangepaste Views. Voor TextView en Button met ingebouwde tekst is het niet nodig om contentDescription in te stellen — TalkBack leest de tekst automatisch.

Programmatische instelling via Kotlin:

binding.iconStar.contentDescription = "Product in favorieten"

// Voor aangepaste weergave met meerdere elementen
binding.customCard.setContentDescription(
    "\(title) ter waarde van \(price)")

In XML voor decoratieve elementen:

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

De eigenschap importantForAccessibility = "no" sluit het element volledig uit van de toegankelijkheidsboom. In iOS is het equivalent isAccessibilityElement = false.

Compose: semantics en contentDescription

In Jetpack Compose wordt Label ingesteld via de modifier semantics:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Product zoeken",
    modifier = Modifier.semantics {
        contentDescription = "Product zoeken"
    }
)

In Compose is contentDescription een verplichte parameter voor Image — zonder compileert de code niet (waarschuwing). Dit dwingt toegankelijkheidsverbetering af via het API-ontwerp.

Label en Hint: verschil in rollen

Accessibility Label beantwoordt de vraag „Wat is dit voor element?”. Hint (accessibilityHint in iOS, extra tekst in contentDescription in Android) — „Wat gebeurt er bij interactie?”. VoiceOver spreekt ze opeenvolgend uit: eerst Label, dan Hint.

Voorbeeld voor de verwijderknop:

• Label: „Verwijder”
• Hint: „Verwijdert de geselecteerde foto onomkeerbaar”
• VoiceOver: „Verwijder. Verwijdert de geselecteerde foto onomkeerbaar”

Volgens Deque University, 2024 verhoogt het correct scheiden van Label en Hint het slagingspercentage van taken voor VoiceOver-gebruikers met 28%. Gebruikers met cognitieve beperkingen zijn bijzonder afhankelijk van Hint: met het risico op „Verwijder” te drukken zonder uitleg, ziet 40% af van de actie.

Wanneer Hint niet nodig is

• Element met intuïtief begrijpelijke actie („Terug”, „Sluiten” — Label is voldoende)
• Label beschrijft al het resultaat („Bericht verzenden” — werkwoord in de naam zelf)
• Systeembediening (UISwitch, UIButton met systeemtype) — hun gedrag is standaard

Fouten uit de praktijk: Label in plaats van Hint

Een veelgemaakte fout: in Label schrijven ze „Verwijderknop” in plaats van „Verwijder”. Het elementtype (knop) wordt automatisch door VoiceOver toegevoegd via trait. Het resultaat is dat de gebruiker hoort: „Verwijderknop, knop” — duplicatie. Correct Label: „Verwijder”, Hint: „Verwijdert de geselecteerde foto”.

Lokalisatie en beste praktijken

Lokalisatie van labels is verplicht — gebeurt via standaardmechanismen: NSLocalizedString in iOS, tekenreeksbronnen @string/ in Android. Stel Label nooit in door concatenatie in het Engels zonder lokalisatie.

Regels voor een goed Label, gebaseerd op W3C WCAG 2.2:

• Begin met het sleutelwoord — „Product zoeken”, niet „Veld voor product zoeken”
• Voeg het woord „knop”, „veld”, „afbeelding” niet toe — de rol wordt automatisch toegevoegd
• Gebruik natuurlijke taal, begrijpelijk voor de doelgroep
• Vermijd afkortingen (behalve algemeen aanvaarde: „st.”, „kg.”) — de schermlezer leest ze letterlijk
• Voeg voor invoerelementen een voorbeeld toe: „Email (example@domain.com)”

Consistentie van Label binnen het merk

Gebruik een uniforme woordenlijst voor Label in de app. Als op het ene scherm „Favorieten” staat en op het andere „Bladwijzers”, raakt de gebruiker gedesoriënteerd. Maak een toegankelijkheidsterminologie-tabel — stem af met ontwerpers en localizers.

Label voor formulierelementen

Voor invoervelden (UITextField, EditText) moet Label overeenkomen met de placeholder of de veldtitel. De placeholder verdwijnt echter vaak na het invoeren van tekst. Gebruik accessibilityLabel voor de permanente naam en accessibilityValue voor de huidige inhoud van het veld — dit is de standaard WCAG 4.1.2. Oplossing: stel accessibilityLabel statisch in (gelijk aan de veldtitel) en accessibilityValue dynamisch (gelijk aan de ingevoerde tekst). In iOS is dit automatisch, maar voor aangepaste velden — handmatig via overschrijving van accessibilityValue. Controleer dat VoiceOver „Email, example@domain.com, tekstveld” leest in plaats van „, tekstveld”.

Hoe toegankelijkheidslabels testen

Geautomatiseerd testen is de enige manier om de correctheid van Label op alle schermen te garanderen. iOS biedt XCUIApplication met toegang tot .label, Android — AccessibilityCheckRule en setContentDescription.

Voorbeeldtest voor 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,
        "Dubbele Labels gevonden")
}

Voorbeeld voor Android met Espresso:

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

Handmatig testen: schakel VoiceOver (iOS) of TalkBack (Android) in en veeg met een gebaar naar rechts door alle elementen van het scherm. Elk element moet een betekenisvolle aankondiging krijgen. Als u alleen „knop” of „afbeelding” hoort — Label ontbreekt.

VoiceOver-rotor en snelle navigatie

Na het instellen van Label kan de VoiceOver-gebruiker de rotor gebruiken voor snelle navigatie: modi „Knoppen”, „Koppen”, „Links” en andere. Als Label correct is ingesteld, neemt VoiceOver het element op in de betreffende rotormodus. Controleer dat alle knoppen zichtbaar zijn in de modus „Knoppen” en alle koppen in „Koppen”.

Label beïnvloedt ook het VoiceOver-zoeken. De gebruiker kan een woord invoeren in de zoekmodus en VoiceOver verplaatst de focus naar het element met het bijpassende Label. Daarom moet Label de trefwoorden bevatten waarmee de gebruiker het element zal zoeken.

Integratie in CI/CD-pipeline

Voeg Label-controle toe aan de pipeline. Gebruik op iOS XCUITest met fastlane scan. Op Android — Accessibility Test Framework met de regel AccessibilityCheckRule die lege contentDescription detecteert. Dit voorkomt regressies bij het samenvoegen van nieuwe schermen.