Content Description: vad det är, principer och hur man ställer in för accessibility

Vad är Content Description i tillgänglighet

Content Description — en sträng egenskap för ett gränssnittselement som överför textrepresentationen av visuellt innehåll till hjälpmedelstekniker. Skärmläsaren (VoiceOver i iOS, TalkBack i Android) läser beskrivningen istället för att försöka visuellt känna igen elementet. Beskrivningen tillämpas på bilder utan textlager, ikoner, grafer, anpassade kontroller och alla icke-textuella element.

Enligt Google Material Design, 2024 bryter element utan contentDescription mot regeln WCAG 1.1.1 (Non-text Content). Kontroll med Accessibility Scanner visar att upp till 40% av ikonerna i butiksappar saknar beskrivning. VoiceOver-användaren hör bara ”bild” eller ”knapp” utan specificering — ett sådant gränssnitt blir oanvändbart för navigering.

Content Description ersätter inte elementets synliga text. Om knappen innehåller en textetikett ”Skicka” behövs ingen extra beskrivning — skärmläsaren läser texten. För bilder, ikoner och inmatningsfält är beskrivning obligatorisk.

Verktygen Accessibility Scanner (Android) och Xcode Accessibility Inspector (iOS) kontrollerar automatiskt förekomsten av beskrivningar. Det rekommenderas att utföra dessa kontroller på varje skärm före publicering.

Varför Content Description behövs: användarscenarier

En användare med synnedsättning förlitar sig på VoiceOver för att förstå gränssnittet. Om varukorgsikonen saknar beskrivning hör han bara ”knapp”. För att ta reda på vad knappen gör måste han trycka på den blindt — risk för oåterkallelig handling. Beskrivningen ”Ta bort produkt från varukorg” löser detta problem på en sekund.

En användare med tillfälliga begränsningar (starkt solljus utomhus, trasig skärm) använder också VoiceOver. Enligt Apple Accessibility Report, 2023 har cirka 20% av VoiceOver-användarna inte permanenta synnedsättningar — de aktiverar denna funktion situationsbaserat.

WCAG 1.1.1: Non-text Content

Kriteriet WCAG 1.1.1 (nivå A) kräver att varje icke-textinnehåll har ett textalternativ. Undantag: innehåll som är dekorativt, endast används för visuell design eller inte bär information. Dekorativitetstest: om vi tar bort elementet, ändras sidans betydelse? Om inte — kan det döljas för skärmläsaren.

Hur skiljer sig Content Description från Label

Accessibility Label (accessibilityLabel i iOS) — namnet på elementet som skärmläsaren uttalar vid fokus. Content Description (accessibilityHint i iOS) — en extra förklaring som läses upp efter namnet och informerar om resultatet av åtgärden.

Skillnaden syns tydligt i exemplet med ”Varukorg”-knappen. Label: ”Varukorg”. Description: ”Öppnar beställningsskärmen”. VoiceOver säger: ”Varukorg. Öppnar beställningsskärmen”. Om endast Label har ställts in vet användaren inte vad som händer efter tryckningen.

Tabell: Label versus Description

Regel: Label svarar på frågan ”Vad är detta?”, Description — ”Vad kommer att hända?”. I Android kan contentDescription fylla båda rollerna, men i praktiken är det bättre att separera dem: använd sammanslagning ”[namn], [förklaring]”.

När Description är viktigare än Label

För komplexa gester (svep för att ta bort, lång tryckning för kontextmeny) är accessibilityHint obligatoriskt. VoiceOver-användaren vet inte om dolda gester om de inte beskrivs. Ange: ”Svep åt vänster för att ta bort” i elementets hint.

iOS: attributet accessibilityHint

I iOS-plattformen ställs accessibilityHint in via egenskapen för UIView eller NSObject. Värde — en sträng upp till 80 tecken. VoiceOver läser hint efter label om läget för detaljerade beskrivningar är aktiverat (i VoiceOver-inställningar — ”Verbosity”).

Exempel på inställning av hint för en anpassad knapp:

import UIKit

class CustomButton: UIButton {
    override func awakeFromNib() {
        super.awakeFromNib()
        self.accessibilityLabel = "Lägg till i favoriter"
        self.accessibilityHint = "Sparar produkten i favoritlistan"
    }
}

För UIImageView utan textinnehåll är det obligatoriskt att ställa in isAccessibilityElement = true och accessibilityHint:

let imageView = UIImageView(image: UIImage(named: "chart-sales"))
imageView.isAccessibilityElement = true
imageView.accessibilityHint = "Försäljningsdiagram för senaste kvartalet"

VoiceOver läser: ”Försäljningsdiagram för senaste kvartalet”. Om hint är tom — endast ”bild”. Apple HIG, 2024 rekommenderar att inte använda verb som ”tryck” eller ”vidrör” i hint — VoiceOver lägger automatiskt till gestinstruktion.

SwiftUI: modifieraren accessibilityHint

I SwiftUI ställs hint in via en kedjemodifierare:

Image(systemName: "trash")
    .accessibilityLabel("Ta bort")
    .accessibilityHint("Tar bort det valda elementet permanent")

SwiftUI kombinerar automatiskt modifierare för sammansatta vyer. Om Image finns inuti Button använder SwiftUI knappens label som primär accessibilityLabel.

Android: egenskapen contentDescription

I Android ställs contentDescription in antingen i XML-märkning eller programmatiskt via setContentDescription(). TalkBack läser beskrivningen vid fokus på elementet.

Exempel i XML:

<ImageView
    android:layout_width="wrap_content"
    android:layout_height="wrap_content"
    android:src="@drawable/ic_search"
    android:contentDescription="Produktsökning" />

Programmatisk inställning för dynamiska element:

binding.iconSearch.contentDescription =
    "Sökning. Öppnar sökskärmen med filter"

För dekorativa bilder (avskiljare, bakgrunder, dekorativa ikoner) ställ in contentDescription = "@null" eller setContentDescription(null) — TalkBack hoppar över ett sådant element. I XML: android:contentDescription="@null". Tom sträng "" fungerar inte — TalkBack säger fortfarande ”bild”.

Android: viktiga detaljer för ImageButton och CheckBox

För ImageButton ställ alltid in contentDescription — TalkBack ser inte texten på bilden. För CheckBox bör beskrivningen ändras dynamiskt: ”Vald” / ”Ej vald” istället för en statisk beskrivning. Använd setContentDescription i tillståndslyssnaren.

Regler för att skriva beskrivningar

Informativitet — beskrivningen bör förmedla innebörden, inte det yttre utseendet. Inte ”Blå ikon med bock”, utan ”Produkt tillagd i varukorgen”. Skärmläsaren bryr sig inte om färger — den bryr sig om resultatet.

Korthet — optimal längd 2–4 ord (upp till 80 tecken). Långa beskrivningar saktar ner navigeringen: VoiceOver läser sekventiellt, varje ord är en sekund av användarens tid. Enligt Apple WWDC 2023, ”Accessibility by Design” avbryter en fras som tar längre tid än 5 sekunder att läsa det kognitiva flödet.

Unikhet — det bör inte finnas två element med samma beskrivning på en skärm. Användaren kommer inte att kunna skilja på vilket resultat fokus på första och andra elementet ger. Om det finns flera ”Köp”-knappar — lägg till identifierare: ”Köp iPhone 15”, ”Köp iPhone 15 Pro”.

Lokalisering — Content Description översätts till alla språk som appen stöder. Ett lokaliseringsfel i beskrivningen är en av de vanligaste orsakerna till misslyckad Accessibility Review i App Store.

Beskrivningslängd: forskning

Forskning från Nielsen Norman Group, 2024 visade att den optimala beskrivningslängden för skärmläsare är 3–5 ord (upp till 50 tecken). Längre beskrivningar minskar navigeringshastigheten med 30%, eftersom användaren måste vänta på att uppläsningen avslutas innan nästa steg.

Vanliga misstag vid användning

Överflöd — beskrivningen duplicerar den synliga texten. Om knappen innehåller texten ”Skicka”, ställ inte in accessibilityHint = ”Skicka-knapp”. VoiceOver läser texten automatiskt och hint lägger till onödigt brus.

Förväxling med Label — användning av contentDescription istället för label för textknappar. I iOS bör accessibilityLabel matcha knapptexten (eller vara tom om texten redan är synlig), och hint förklarar endast åtgärden. Enligt Google Testing Blog, 2024 har 23% av granskade appar i Play Store duplicerade beskrivningar.

Ignorering av dynamik — beskrivningen uppdateras inte vid tillståndsändring. Till exempel förblir beskrivningen för ”Wi-Fi”-omkopplaren ”Aktivera Wi-Fi” även efter aktivering. Korrekt: ändra beskrivningen dynamiskt till ”Inaktivera Wi-Fi” genom tillståndsövervakning.

Renderingscykler och regressioner

Efter en designuppdatering (byte av ikoner, omarrangering av element) går Content Description ofta förlorat. Orsak: designern byter ut bilden, utvecklaren kontrollerar inte tillgänglighetsegenskaperna för den nya tillgången. Lösning: gör tillgänglighetskontroll till ett obligatoriskt steg i code review — lägg till en checklista med punkten ”Content Description uppdaterat?”.

Hur man kontrollerar Content Description

• I iOS: Xcode → Accessibility Inspector — välj elementet, kontrollera fälten Label och Hint
• I Android: installera Accessibility Scanner från Play Store — kör på din skärm
• På båda plattformarna: aktivera VoiceOver/TalkBack och navigera genom hela skärmen med gester
• Skriv ett UI-test som kontrollerar contentDescription för alla ImageView

Exempel på UI-test för iOS

func testContentDescriptionExists() {
    let app = XCUIApplication()
    app.launch()
    let image = app.images["chart-sales"]
    XCTAssertNotNil(image.label)
    XCTAssertGreaterThan(image.label.count, 0)
}