Accessibility Label — vad är det, grunder och hur man använder för iOS och Android

Vad är Accessibility Label

Accessibility Label är en strängegenskap som definierar elementets namn för hjälpmedelsteknik. När användaren drar fingret över skärmen med VoiceOver aktiverat, läser skärmläsaren upp Label för elementet som har fokus. Utan etikett hör användaren bara elementtypen: “knapp”, ”bild” — utan att ange syftet.

Enligt Google I/O 2024, “Accessibility Testing” är 35% av kritiska tillgänglighetsöverträdelser i butiksappar kopplade till avsaknad eller felaktighet av Label. Accessibility Scanner på Android upptäcker saknad etikett som ett fel av högsta allvarlighetsgrad.

Principiell begränsning: Label ska inte innehålla elementtypen. VoiceOver och TalkBack lägger automatiskt till rollen (button, header, link) i meddelandet. Om Label innehåller “Skicka-knapp” hör användaren: “Skicka-knapp, knapp” — dubbelarbete.

Label och WCAG 4.1.2: Name, Role, Value

WCAG 4.1.2 (nivå A) kräver att varje element i användargränssnittet har ett programmatiskt bestämbart namn (name), roll (role) och värde (value). Accessibility Label tillhandahåller namnet. Om Label saknas anses kriteriet vara överträtt och applikationen klarar inte grundläggande certifiering.

iOS: egenskapen accessibilityLabel

I iOS ärvs accessibilityLabel av alla UIView från protokollet UIAccessibility. Om elementet innehåller text (UIButton med title, UILabel med text) ställs Label automatiskt in på denna text. För UIImageView, anpassade kontroller och behållare måste Label ställas in manuellt.

Exempel för en anpassad tabellcell:

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

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

För anpassade UIView kan gettern för accessibilityLabel överskuggas:

class RatingView: UIView {
    var rating: Int = 5

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

Apple HIG, 2024 rekommenderar: om elementet består av flera under-element (t.ex. produktkort med namn och pris), kombinera dem till ett tillgänglighetselement med en sammansatt Label. Ställ in isAccessibilityElement = true på föräldern och false på barnen.

NSAttributedString och accessibilityLabel

Om UILabel använder NSAttributedString är accessibilityLabel som standard lika med .string (ren text). Om du behöver skicka ett semantiskt annorlunda värde (t.ex. en ikon-symbol som läses som “Stjärna” istället för symbolen ★), ställ in accessibilityLabel explicit. VoiceOver läser inte Unicode-symboler på ett meningsfullt sätt.

Android: Label via contentDescription

I Android fungerar contentDescription som Label för ImageView, ImageButton och anpassade Vyer. För TextView och Button med inbyggd text behöver du inte ställa in contentDescription — TalkBack läser texten automatiskt.

Programmatisk inställning via Kotlin:

binding.iconStar.contentDescription = "Produkt i favoriter"

// För anpassad vy med flera element
binding.customCard.setContentDescription(
    "\(title) till ett belopp av \(price)")

I XML för dekorativa element:

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

Egenskapen importantForAccessibility = "no" utesluter helt elementet från tillgänglighetsträdet. I iOS är motsvarigheten isAccessibilityElement = false.

Compose: semantics och contentDescription

I Jetpack Compose ställs Label in via modifieraren semantics:

Image(
    painter = painterResource(R.drawable.ic_search),
    contentDescription = "Produktsökning",
    modifier = Modifier.semantics {
        contentDescription = "Produktsökning"
    }
)

I Compose är contentDescription en obligatorisk parameter för Image — utan den kompileras inte koden (varning). Detta tvingar fram förbättrad tillgänglighet genom API-design.

Label och Hint: skillnad i roller

Accessibility Label besvarar frågan ”Vad är detta för element?”. Hint (accessibilityHint i iOS, extra text i contentDescription i Android) — ”Vad händer vid interaktion?”. VoiceOver uttalar dem sekventiellt: först Label, sedan Hint.

Exempel för raderingsknappen:

• Label: “Ta bort”
• Hint: “Tar oåterkalleligen bort det valda fotot”
• VoiceOver: “Ta bort. Tar oåterkalleligen bort det valda fotot”

Enligt Deque University, 2024 ökar korrekt separation av Label och Hint framgångsfrekvensen för uppgifter för VoiceOver-användare med 28%. Användare med kognitiva funktionsnedsättningar är särskilt beroende av Hint: med risken att trycka på “Ta bort” utan förklaring avstår 40% från åtgärden.

När Hint inte behövs

• Element med intuitivt förståelig åtgärd (“Tillbaka”, “Stäng” — Label räcker)
• Label beskriver redan resultatet (“Skicka meddelande” — verb i själva namnet)
• Systemkontroller (UISwitch, UIButton med systemtyp) — deras beteende är standard

Misstag från praktiken: Label istället för Hint

Ett vanligt misstag: i Label skriver man “Radera-knapp” istället för “Ta bort”. Elementtypen (knapp) läggs automatiskt till av VoiceOver via trait. Som ett resultat hör användaren: “Radera-knapp, knapp” — dubbelarbete. Korrekt Label: “Ta bort”, Hint: “Tar bort det valda fotot”.

Lokalisering och bästa praxis

Lokalisering av etiketter är obligatorisk — sker via standardmekanismer: NSLocalizedString i iOS, strängresurser @string/ i Android. Ställ aldrig in Label genom sammanlänkning på engelska utan lokalisering.

Regler för en bra Label, baserade på W3C WCAG 2.2:

• Börja med nyckelordet — “Produktsökning”, inte “Fält för produktsökning”
• Inkludera inte orden “knapp”, “fält”, ”bild” — rollen läggs till automatiskt
• Använd naturligt språk, förståeligt för målgruppen
• Undvik förkortningar (förutom allmänt accepterade: “st”, “kg”) — skärmläsaren läser dem bokstavligt
• För inmatningselement, lägg till ett exempel: “E-post (example@domain.com)”

Konsistens hos Label inom varumärket

Använd en enhetlig ordlista för Label i applikationen. Om det på en skärm står “Favoriter” och på en annan “Bokmärken” blir användaren desorienterad. Skapa en tabell över tillgänglighetstermer — samordna med designers och lokaliserare.

Label för formulärelement

För inmatningsfält (UITextField, EditText) ska Label överensstämma med platshållaren eller fältets rubrik. Platshållaren försvinner dock ofta efter textinmatning. Använd accessibilityLabel för det permanenta namnet och accessibilityValue för fältets aktuella innehåll — detta är standarden WCAG 4.1.2. Lösning: ställ in accessibilityLabel statiskt (lika med fältets rubrik) och accessibilityValue dynamiskt (lika med den inmatade texten). I iOS är detta automatiskt, men för anpassade fält — manuellt via överskuggning av accessibilityValue. Kontrollera att VoiceOver läser: “E-post, example@domain.com, textfält” istället för “, textfält”.

Hur man testar tillgänglighetsetiketter

Automatiserad testning är det enda sättet att garantera att Label är korrekt på alla skärmar. iOS tillhandahåller XCUIApplication med åtkomst till .label, Android — AccessibilityCheckRule och setContentDescription.

Exempel på test för 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,
        "Dubblerade Label hittades")
}

Exempel för Android med Espresso:

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

Manuell testning: aktivera VoiceOver (iOS) eller TalkBack (Android) och svep med en gest åt höger genom alla element på skärmen. Varje element bör få ett meningsfullt meddelande. Om du bara hör “knapp” eller ”bild” — Label saknas.

VoiceOver-rotor och snabbnavigering

Efter att Label har konfigurerats kan VoiceOver-användaren använda rotorn för snabbnavigering: lägena “Knappar”, “Rubriker”, “Länkar” och andra. Om Label är korrekt inställt inkluderar VoiceOver elementet i motsvarande rotorläge. Kontrollera att alla knappar är synliga i läget “Knappar” och alla rubriker i “Rubriker”.

Label påverkar också VoiceOver-sökningen. Användaren kan ange ett ord i sökläget och VoiceOver flyttar fokus till elementet med matchande Label. Därför bör Label innehålla de nyckelord som användaren kommer att söka efter för att hitta elementet.

Integrering i CI/CD-pipeline

Lägg till Label-kontroll i pipelinen. På iOS, använd XCUITest med fastlane scan. På Android — Accessibility Test Framework med regeln AccessibilityCheckRule som upptäcker tomma contentDescription. Detta förhindrar regressioner vid sammanslagning av nya skärmar.