En tilgængelig responsiv hjemmeside er ikke det samme som en tilgængelig app – selvom begge "virker på telefonen." Denne artikel forklarer de kritiske forskelle mellem at gøre et websted tilgængeligt og at gøre en indbygget iOS- eller Android-app tilgængelig.

Kort sagt – hvad denne artikel dækker

  1. Forskellig teknologi, lignende regler
  2. VoiceOver og TalkBack: ikke den samme skærmlæser
  3. Hvad er unikt for native apps
  4. Sådan tester du en tilgængelig app

Forskellig teknologi, lignende regler

Et responsivt websted er bygget af HTML, som allerede har et indbygget tilgængelighedslag (semantiske tags, ARIA), som browsere og skærmlæsere ved, hvordan de skal fortolke. En indbygget app er derimod bygget af operativsystemets egne UI-komponenter (UIKit/SwiftUI på iOS, Jetpack Compose/Views på Android) - og hver komponent har brug for sin egen tilgængelighedsmærkning, adskilt fra dens visuelle design. De underliggende principper ligner WCAG (kontrast, touch-target-størrelse, et klart tilgængeligt navn), men værktøjerne til at implementere dem er helt anderledes.

VoiceOver og TalkBack: Ikke den samme skærmlæser

VoiceOver (iOS) og TalkBack (Android) er to forskellige skærmlæsere med forskellige navigationsbevægelser og forskellig understøttelse af brugerdefinerede komponenter. En komponent, der er tagget perfekt på iOS, fungerer muligvis ikke korrekt på Android, hvis udviklerne ikke har testet begge platforme separat. Du kan ikke antage, at "vi testede det på iOS, så det skal også fungere på Android."

💡 Vigtigt punkt

På begge platforme har hver interaktiv komponent (knap, inputfelt, billede) brug for: en tydelig tilgængelighedsetiket, en defineret tilgængelighedsrolle/egenskab og nogle gange også et tilgængelighedstip, der forklarer, hvad der sker, når der trykkes på den.

Hvad er unikt for indbyggede apps

Native apps står også over for udfordringer, der ikke findes på websteder: tilpassede berøringsbevægelser (swipe, knib), der har brug for et tilgængeligt alternativ; navigation mellem skærme, der også skal give mening gennem en skærmlæser; og push-meddelelser, der skal være tilgængelige, selv når de vises uden for selve appen. Derudover skal touch-target-størrelser opfylde minimum 44x44 pixels i henhold til Apples retningslinjer og 48x48dp under Googles retningslinjer - et krav, der ikke altid findes i samme form på websteder.

Sådan tester du en tilgængelig app

  1. Slå VoiceOver eller TalkBack til, og prøv at fuldføre appens kerneopgaver (tilmelding, køb, søgning) ved kun at bruge dem.
  2. Tjek kontrast og tekststørrelse med systemtilgængelighedsindstillinger slået til (større tekst, høj kontrast).
  3. Bekræft understøttelse af dynamisk tekststørrelse (Dynamic Type på iOS) uden at layoutet "bryder".
  4. Test på begge platforme separat – det er ikke nok at teste kun én.

Har du også dokumenter, der ledsager din app?

Vores værktøj scanner de PDF-filer, der er linket til din app eller hjemmeside – brugsvilkår, vejledninger, formularer – og viser dig præcis, hvilke der har brug for opmærksomhed.

Scan dit websted gratis ←

Efter scanningen kan du også gøre de dokumenter, den fandt, tilgængelige direkte og gratis viaAccessiDoc.