Tilgængelighed i iOS: Kom godt i gang

Opdateret note: Fayyaz Syed har opdateret denne vejledning til iOS 13, Xcode 11 og Swift 5. Vincent Ngo skrev den oprindelige.

Bemærk: Du skal bruge en fysisk enhed for at arbejde med VoiceOver. Denne tilgængelighedsfunktion understøttes ikke i simulatoren på nuværende tidspunkt.

Bemærk: Der findes mange andre tilgængelighedsfunktioner ud over VoiceOver, herunder Inverter farver, Øg kontrast, farvefiltre, Reducer hvidpunktet, Zoom, Skift kontrol og meget mere. I denne vejledning vil du mest fokusere på VoiceOver.

Bemærk: Opskrift-appen bruger standard UIKit-visninger og -kontroller, som allerede er tilgængelige, og som højst kræver ændring af attributstrengene. For projekter med brugerdefinerede elementer skal du sørge for at læse vores iOS-tilgængelighedsvejledning: Nu ved du, hvor VoiceOver henter de oplysninger, den giver brugerne, og det er på tide at lære et nyt værktøj at kende, som hjælper dig med at finde og rette svagheder ved tilgængelighed i din app: Tilgængelighedsinspektøren.

Anvendelse af tilgængelighedsinspektøren

Hvis du skal eftermontere en app, så den bliver mere tilgængelig, er det tidskrævende og fejlbehæftet at finde svagheder. Heldigvis er der et værktøj til at hjælpe ved navn Accessibility Inspector, som gør følgende:

• Gennemgår din app og finder almindelige tilgængelighedsproblemer.
• Lader dig kontrollere tilgængelighedsattributterne for elementer i brugergrænsefladen i inspektionstilstand.
• Giver live previews af tilgængelighedselementer uden at forlade din app.
• Understøtter alle platforme, herunder macOS, iOS, watchOS og tvOS.

Før du bruger Accessibility Inspector på Recipes, skal du tage et kig på værktøjet. Først skal du åbne det i Xcode-menuen ved at navigere til Xcode ▸ Open Developer Tool ▸ Accessibility Inspector.

Inspektøren skal se nogenlunde sådan ud:

Med målvælgeren kan du vælge, hvilken enhed du vil inspicere. Det kan være din MacBook Pro, en iOS-enhed eller din simulator.

Live previews af tilgængelighedselementer giver dig mulighed for at teste direkte i simulatoren. Da live previews er hurtigere end at lytte til VoiceOver, er det her, du vil udføre størstedelen af dit arbejde i løbet af denne iOS-tilgængelighedsvejledning.

Byg og kør i en simulator, og ændr målet for Accessibility Inspector til din simulator:

Nu, hvor du har værktøjet åbent, kan du se på nogle af dets mest nyttige funktioner.

Anvendelse af inspektionsviseren

Vælgelse af Inspektionsviseren, der ligner et sigtekornet i inspektørens brugergrænseflade, svarer til at aktivere VoiceOver på din enhed. Når du aktiverer viseren, kan du holde musen over et hvilket som helst element i brugergrænsefladen for at kontrollere dets attributter. Hvis du interagerer direkte med simulatoren via tryk på en knap, deaktiveres Inspection Pointer.

Inspection Detail-ruden har alt, hvad du behøver for at gennemgå og interagere med tilgængelighedsattributterne i din app:

• Grundlæggende: Viser attributegenskaberne for det aktuelt fremhævede element.
• Handlinger: Giver dig mulighed for at udføre handlinger, f.eks. at trykke på en knap eller rulle i visningen. Hvis du trykker på knappen Udfør i denne rude, udføres handlingen på dit mål.
• Element: Viser klasse, adresse og controller for det aktuelle element. I skrivende stund fungerer det ikke konsekvent.
• Hierarki: Viser visningshierarkiet for elementet, hvilket gør det nemmere at forstå komplekse visninger.

Brug Quicklook til at kontrollere lyd i Xcode

Xcode 11 har en ny funktion i Inspektionsdetalje-ruden i Quicklook-sektionen øverst, som giver dig mulighed for at simulere i Xcode den lyd, du ville høre på din enhed. Det betyder, at du kan kontrollere, hvad dine brugere hører, når de bruger din app, uden at du behøver en egentlig enhed.

Tryk på knappen Afspil, mens appen kører i en simulator, lad Accessibility Inspector cykle gennem appen og lyt, mens den beskriver hvert element højt.

Hvis du foretrækker at gå manuelt gennem hvert element, kan du enten trykke på knappen Pause eller trykke på knappen Lyd inde i Quicklook-sektionen. Tryk på knapperne Fremad eller Tilbage for at gennemgå hvert element i dit eget tempo.

Det er hurtigere at bruge denne funktion end at køre din app på en enhed og bruge VoiceOver, især under udviklingen. Som altid skal du også teste din app, sammen med alle dens tilgængelighedsfunktioner, på rigtige enheder.

Highlighting Problems With the Inspector Audit

En af de mest nyttige funktioner i Inspector Audit er auditfunktionen, som giver dig advarsler om tilgængelighedsproblemer i din app. Hvis du vil afprøve denne funktion, skal du sørge for, at simulatoren stadig kører, og at du er på opskriftslisten. Klik på ikonet Audit i inspektøren, og klik derefter på Run audit (Kør audit).

Du vil se, at inspektøren giver flere advarsler, herunder at nogle af dine elementer mangler beskrivelse.

Når du klikker på en advarsel, fremhæver Xcode det relaterede element i simulatoren samt nederst på inspektørens revisionsskærm.

I dette tilfælde har de billedvisninger, der er knyttet til cellerne, ingen beskrivelse. Det betyder, at VoiceOver ikke vil være i stand til at beskrive dem for dine læsere.

Klik på ikonet Foreslå rettelser, der ligner et spørgsmålstegn i en cirkel, for en af advarslerne, og inspektøren vil give dig forslag til, hvordan du kan rette problemet. Du kan handle på disse forslag senere.

Klik på ikonet Øje for at tage et snapshot af appen. Dette er nyttigt for alle i kvalitetssikring, der skal oprette nøjagtige fejlrapporter.

Der er et par andre nyttige tilgængelighedsindstillinger, som du kan finde i inspektøren. Det næste er, at du tager et hurtigt kig på disse funktioner.

Tilpasningsinspektørindstillinger

Selv om de ligger uden for rammerne af denne vejledning, er det godt at vide, at du med Tilgængelighedsinspektøren også kan teste følgende tilgængelighedsindstillinger:

1. Inverter farver
2. Forøg kontrasten
3. Reducer gennemsigtighed
4. Reducer bevægelse
5. Ændrer skriftstørrelse

Du behøver ikke længere at bruge appen Indstillinger for at aktivere disse funktioner. Tilgængelighedsinspektøren tilbyder i øjeblikket kun disse fem muligheder, men Apple planlægger at tilføje flere i fremtiden.

Tilgængelighedsinspektøren sparer tid, når du tester din app. Husk dog, at du stadig bør teste VoiceOver manuelt for at afprøve den faktiske brugeroplevelse. Dette sidste trin hjælper dig med at opfange eventuelle problemer, som inspektøren overser.

Nu har du fået en rundvisning i tilgængelighedsinspektørens funktioner, og det er tid til at komme i gang med din app.

Gør opskriftsappen tilgængelig

Da du testede din app på din enhed med VoiceOver, bemærkede du, at billedernes beskrivelser ikke var særlig nyttige. Auditværktøjet viste dig årsagen til dette: Billedvisningen havde ikke en tilgængelighedsetiket. Det vil du nu rette op på.

Åbn RecipeCell.swift i Xcode, og tilføj følgende kode nederst i filen:

// MARK: Accessibilityextension RecipeCell { func applyAccessibility(_ recipe: Recipe) { // 1 foodImageView.accessibilityTraits = .image // 2 foodImageView.accessibilityLabel = recipe.photoDescription }}

Denne kode udfylder de manglende tilgængelighedsegenskaber baseret på Recipe-objektet for cellen. Sådan fungerer det:

1. accessibilityTraits tager en maske af egenskaber, der karakteriserer tilgængelighedselementet. I dette tilfælde angiver .image, at det er et billede.
2. Du bruger accessibilityLabel til at beskrive elementet i VoiceOver. Her er det indstillet til recipe.photoDescription, som er en streng, der beskriver indholdet af billedet.

Nu vil du også anvende dette på fremtidige opskrifter. Find configureCell(_:) i RecipeCell-klassen. Tilføj følgende linje til slutningen af metoden:

applyAccessibility(recipe)

Hver gang du opretter en celle, vil denne kode anvende tilgængelighedsattributterne på billedet ved hjælp af egenskaber i opskriftsobjektet.

Byg og kør på din enhed, og aktiver VoiceOver med tre tryk på hjemknappen. Test opskriftslisten for at se, om billedbeskrivelserne er mere meningsfulde.

Meget bedre! I stedet for blot at høre “Billede”, som ikke gav nogen specifikke detaljer, hører du nu en komplet beskrivelse af billedet. Brugeren kan nu visualisere maden i stedet for at være frustreret over ikke at vide, hvad billedet er.

Mens appen stadig kører i simulatoren, skal du køre Accessibility Inspector igen og navigere til opskriftslisten. Sørg for at slette alle advarsler i inspektøren, og tryk på Kør revision.

WOOt – ikke flere advarsler om beskrivelser! Efter at det er lykkedes at tilføje beskrivelser til billederne, er kernen i denne visning nu fuldt tilgængelig.

Nu er det tid til at gøre en opskrifts sværhedsgrad tilgængelig.

Transformering af sværhedsgradsetiketterne

I Tilgængelighedsinspektøren ser du potentielt utilgængelige tekstadvarsler, der fortæller dig, at sværhedsgradsetiketterne er usynlige for en bruger med synshandicap. For at løse disse problemer skal du gøre etiketterne tilgængelige og opdatere deres egenskaber med en meningsfuld beskrivelse.

For dit næste skridt skal du gå til RecipeCell.swift og tilføje følgende til slutningen af applyAccessibility(_:):

// 1difficultyLabel.isAccessibilityElement = true// 2difficultyLabel.accessibilityTraits = .none// 3difficultyLabel.accessibilityLabel = "Difficulty Level"// 4switch recipe.difficulty {case .unknown: difficultyLabel.accessibilityValue = "Unknown"case .rating(let value): difficultyLabel.accessibilityValue = "\(value)"}

Her er lidt flere detaljer om, hvad denne kode gør:

1. isAccessibilityElement er et flag, der gør elementet synligt for tilgængelighedsfunktioner, når true. For de fleste UIKit-klasser er standardværdien true, men for UILabel er den false.
2. accessibilityTraits er med til at karakterisere tilgængelighedselementet. Da du ikke har brug for interaktioner, indstiller du det til ikke at have nogen egenskaber.
3. Næst får du VoiceOver til kortfattet at identificere hensigten med denne etiket. Difficulty Level lader brugeren vide præcis, hvad han/hun har med at gøre.
4. VoiceOver læser accessibilityValue som en del af labelbeskrivelsen. Hvis du indstiller sværhedsgraden her, bliver dette element meget mere brugbart.

Byg og kør din app på en fysisk enhed, tryk tre gange på hjemknappen for at aktivere VoiceOver og stryg gennem opskriftslisten.

Når du ruller gennem de forskellige tilgængelighedselementer, læser VoiceOver en fuld beskrivelse af hver celle, herunder sværhedsgraden.

Kontrol for advarsler

Hver gang du eksponerer et nyt tilgængelighedselement, som du har gjort her med sværhedsgraden, skal du køre revisionen igen.

Start Tilgængelighedsinspektøren, hvis den ikke allerede kører. Kør appen på din enhed eller i simulatoren, og indstil inspektormålet i overensstemmelse hermed. Vælg nu knappen Audit toggle-knappen, og tryk på Kør audit.

Flere advarsler dukkede op! De resterende handler om, at etiketterne ikke understøtter dynamisk tekst. Du retter dem som det næste.

Dynamisk tekst

Revisor advarer dig om, at du mangler et vigtigt trin for at gøre din app anvendelig for alle: dynamisk tekst. Dette er en vigtig funktion for tilgængelighed, der giver brugere med delvis nedsat syn mulighed for at øge skriftstørrelsen for at gøre teksten læsbar. Den ikke-dynamiske skrifttype, som din app i øjeblikket bruger, giver ikke mulighed for dette.

Klik på ikonet Fix Suggestions for at se, hvad revisoren anbefaler:

Den fortæller dig, at du skal bruge en UIfont-præfereret skrifttype og indstille adjustsFontForContentSizeCategory til sand. Det gør du nu.

Inden for RecipeCell.swift tilføjes følgende kode inden for applyAccessibility(_:) helt nederst:

dishNameLabel.font = .preferredFont(forTextStyle: .body)dishNameLabel.adjustsFontForContentSizeCategory = truedifficultyLabel.font = .preferredFont(forTextStyle: .body)difficultyLabel.adjustsFontForContentSizeCategory = true

Dette indstiller preferredFont til en body-stil, hvilket betyder, at iOS vil stilisere teksten, som den ville gøre det i brødteksten i et dokument. De nærmere detaljer om størrelse og skrifttype afhænger af tilgængelighedsindstillingerne. adjustsFontForContentSizeCategory angiver, at skrifttypen skal opdateres automatisk, når brugeren ændrer tekstindholdets størrelse.

Det er nemt at teste, hvordan din app håndterer størrelsesændring af skrifttyper, takket være Tilgængelighedsinspektøren.

Byg og kør opskriftsappen sammen med Tilgængelighedsinspektøren. Kør revisionen igen, og alle dine advarsler skulle være væk.

Test af nogle andre muligheder

Navigér til indstillingsfeltet Indstillinger i inspektøren, og eksperimentér med nogle af værktøjerne:

1. Inverter farver for at få et eksempel på, hvordan din grænseflade ser ud med denne tilgængelighedsfunktion. Dette er nyttigt for personer med lysfølsomhed, dårligt syn og i nogle tilfælde farveblindhed.
2. Du kan også afprøve dynamiske ændringer af skriftstørrelsen i realtid for de brugere, der foretrækker større skriftstørrelser.

Når du tester din app, ligner den sikkert meget dette:

Inspektøren gør det nemt at teste tilgængelighedstilfælde. Ud fra dette kan du se, at opskriftslisten vil fungere godt for brugere med synshandicap.

Transformering af opskriftsdetaljeskærmen

Nu har du taget dig af listen med opskriftsindstillinger, og du vil se, hvad der sker, når en bruger klikker på en af opskrifterne. Kør appen på din enhed, aktiver VoiceOver, og se dig omkring i detaljevisningen. Det lyder nogenlunde sådan her:

Der er nogle problemer med VoiceOver-interaktionen i detaljevisningen:

1. Venstre pileknap er ikke en god beskrivelse for navigationen. Hvordan kan brugeren vide, hvad knappen gør?
2. Emoji-ansigtstilstandene er: hjerteformede øjne og forvirret ansigt. Disse forklaringer ville forvirre enhver bruger!
3. Når brugeren vælger en afkrydsningsboks, står der ikon tomt, hvilket ikke forklarer meget.

I hvert af disse tilfælde er det vigtigt at forklare, hvad kontrolelementets tilstand betyder, snarere end hvordan det ser ud. Tilbage-knappen er tydeligere end venstre pileknap. Synes godt om og Synes ikke godt om forklarer emojis kortfattet. Du foretager disse to ændringer som det næste.

For at ændre navigationen skal du åbne RecipeInstructionsViewController.swift og tilføje følgende til viewDidLoad efter assert(recipe != nil):

backButton.accessibilityLabel = "back"backButton.accessibilityTraits = .button

I stedet for Venstre pilknap siger VoiceOver nu Tilbage-knappen.

Nu skal du gå videre til emojierne. I samme fil erstatter du indholdet af isLikedFood(_:) med følgende:

if liked { likeButton.setTitle("😍", for: .normal) likeButton.accessibilityLabel = "Like" likeButton.accessibilityTraits = .button didLikeFood = true} else { likeButton.setTitle("😖", for: .normal) likeButton.accessibilityLabel = "Dislike" likeButton.accessibilityTraits = .button didLikeFood = false}

For både Synes godt om og Synes ikke godt om-tilstande har du tilføjet et accessibilityLabel, som er tydeligt om, hvad knappen gør. Du har også indstillet accessibilityTraits for at identificere den som en knap, så brugeren ved, hvordan de kan interagere med den.

Byg og kør på en enhed, og aktiver VoiceOver. Naviger til detailopskriftsskærmen ved hjælp af VoiceOver for at teste dine ændringer af knapperne øverst i visningen.

Nu har hver af disse funktioner klare, korte beskrivelser, der hjælper brugeren med at forstå deres hensigt. Meget bedre!

Forbedring af afkrydsningsfelterne

Det sidste problem er med tjeklisten. For hver afkrydsningsboks angiver VoiceOver i øjeblikket ikonet tomt efterfulgt af opskriftsinstruktionen. Det er slet ikke tydeligt!

For at ændre dette skal du åbne InstructionCell.swift og kigge efter shouldStrikeThroughText(_:). Udskift hele if strikeThrough-anvisningen med følgende:

// 1checkmarkButton.isAccessibilityElement = falseif strikeThrough { // 2 descriptionLabel.accessibilityLabel = "Completed: \(text)" attributeString.addAttribute( NSAttributedString.Key.strikethroughStyle, value: 2, range: NSRange(text.startIndex..., in: text))} else { // 3 descriptionLabel.accessibilityLabel = "Uncompleted: \(text)"}

Her er, hvad denne kode gør:

1. Det slår tilgængeligheden for afkrydsningsknappen fra, så VoiceOver læser den som én enhed i stedet for to forskellige tilgængelighedselementer.
2. Den accessibilityLabel for beskrivelsen bruger nu den hard-codede streng "Completed" efterfulgt af teksten. Dette giver alle de nødvendige oplysninger med et enkelt besøg på etiketten.
3. Som med den færdige kode tilføjer du "Uncompleted" før etikettens beskrivelse, hvis en bruger markerer et element som ikke-færdiggjort.

Byg og kør appen igen, og se, hvordan den lyder. Det vil være musik i dine brugeres ører. :]

Hvor skal vi gå hen herfra?

Du kan downloade den færdige version af projektet ved hjælp af knappen Download materialer øverst eller nederst i denne vejledning.

I denne iOS-tilgængelighedsvejledning har du lært om VoiceOver. Du udførte manuel auditering ved at rulle gennem hvert tilgængeligt element og teste brugeroplevelsen for dig selv. Derefter brugte du Tilgængelighedsinspektøren til at udføre revisioner, se på værdier for tilgængelighedselementer og udføre dynamiske live-ændringer for at invertere farver eller ændre skriftstørrelsen.

Nu har du de nødvendige værktøjer til at gøre din app mere tilgængelig. Det er givende at vide, at du vil have en positiv indvirkning på nogens liv.

Der er et væld af muligheder med tilgængelighedsfunktioner. Denne vejledning skraber kun på overfladen for at få dig i gang. Nedenfor er der flere ressourcer, som du kan tjekke ud:

• Kategorier af tilgængelighed
• Ressourcer til udvikling af tilgængelighed
• Anvendelse af tilgængelighed på brugerdefinerede visninger
• Levere en ekstraordinær tilgængelighedsoplevelse
• Accessibility Inspector

Hvis du har kommentarer eller spørgsmål, er du velkommen til at deltage i diskussionen nedenfor!