iOS
Tillgänglighet

Introduktion

Gör en vy tillgänglig

Markera din UIView underklass som ett tillgängligt element så att det är synligt för VoiceOver.

myView.isAccessibilityElement = YES;

Se till att vyn talar en meningsfull etikett, värde och ledtråd. Apple ger mer information om hur du väljer bra beskrivningar i Handbok för tillgänglighetsprogrammering .

Tillgänglighetsram

Tillgänglighetsramen används av VoiceOver för hittestning av beröring, ritning av VoiceOver-markören och beräkning var i det fokuserade elementet för att simulera en kran när användaren dubbelknapper på skärmen. Observera att ramen är i skärmkoordinater!

myElement.accessibilityFrame = frameInScreenCoordinates;

Om dina element eller skärmlayouter ändras ofta, överväg att åsidosätta - accessibilityFrame att alltid ge en aktuell rekt. Beräkning av skärmens relativa ram i undervyer för rullningsvy kan vara felaktig och tråkig. iOS 10 introducerar ett nytt API för att göra det enklare: accessibilityFrameInContainerSpace .

Skärmbyte

VoiceOver fungerar utmärkt för det mesta och läser hårt skärmar fulla av innehåll och intuitivt följer användaren. Tyvärr är ingen allmän lösning perfekt. Ibland är det bara du, apputvecklaren som vet var VoiceOver ska vara fokuserad för en optimal användarupplevelse. Lyckligtvis lyssnar VoiceOver på meddelanden om systemtillgänglighet för ledtrådar om var fokus hör hemma. Om du vill flytta VoiceOver-markören manuellt ska du lägga upp en tillgänglighetskärm som har ändrats:

UIAccessibilityPostNotification(UIAccessibilityScreenChangedNotification, firstElement);

När det här meddelandet publiceras meddelar en kort serie toner användare om ändringen. Den andra parametern kan vara antingen nästa element att fokusera eller en sträng som meddelar ändringen. Skicka bara en skärmändringsmeddelande om VoiceOver-upplevelsen är dålig utan den och ingen annan lösning finns. Att flytta VoiceOver-markören är som att titta på en synlig användares skärm. Det kan vara irriterande och desorienterande att bli ledd på det sättet.

Layoutändring

I många fall kommer innehåll inom en enda skärm att uppdateras med nytt eller annorlunda innehåll. Föreställ dig till exempel ett formulär som visar ytterligare alternativ baserat på användarens svar på en tidigare fråga. I det här fallet kan du meddelandet om "layoutändring" antingen meddela ändringen eller fokusera på ett nytt element. Meddelandet accepterar samma parametrar som skärmändringsmeddelandet.

UIAccessibilityPostNotification(UIAccessibilityLayoutChangedNotification, firstElement);

Meddelande

Meddelanden är användbara för att varna användare om händelser som inte kräver någon interaktion, till exempel "skärmlåst" eller "färdig laddning." Använd ett mer specifikt tillkännagivande för att meddela användare om skärmändringar eller mer mindre layoutändringar.

UIAccessibilityPostNotification(UIAccessibilityAnnouncementNotification, @"The thing happened!");

Beställa element

VoiceOver navigerar från högst upp till vänster till höger, oavsett visningshierarkin. Det här är vanligtvis hur innehåll är ordnat på språk från vänster till höger eftersom synskilda individer tenderar att skanna skärmen i ett "F-format mönster". VoiceOver-användare förväntar sig att navigera på samma sätt som vanliga användare. Förutsägbarhet och konsistens är mycket viktiga för tillgängligheten. Avstå från att göra anpassningar som "förbättras" på standardbeteendet (t.ex. beställa flikfältet först i svepordningen). Som sagt, om du har fått feedback om att ordningen på element i din app är överraskande, finns det ett par sätt att förbättra upplevelsen.

Om VoiceOver skulle läsa en vys undervyer en efter nästa men inte är det, kan du behöva antyda VoiceOver att elementen i en enda vy är relaterade. Du kan göra detta genom att ställa in shouldGroupAccessibiltyChildren :

myView.shouldGroupAccessibilityChildren = YES;

För att stödja komplexa navigationsstrukturer som sträcker sig över flera containrar eller inkluderar gränssnitt som gjorts utan UIKit, bör du överväga att implementera behållarprotokollet i överordnade vyn.

Behållare för tillgänglighet

VoiceOver kan navigera i många appar på iOS eftersom de flesta UIKit klasser implementerar UIAccessibilityProtocol . Funktioner som inte representerar element på skärmen som använder UIView , inklusive appar som utnyttjar Core Graphics eller Metal för att utföra ritning, måste beskriva dessa element för tillgänglighet. Från iOS 8.0 kan detta göras genom att tilldela en egenskap på UIView innehåller otillgängliga element:

myInaccessibleContainerView.accessibilityElements = @[elements, that, should, be, accessible];

Varje objekt i arrayen kan vara ett exempel på UIAccessibilityElement eller någon annan klass som följer UIAccessibilityProtocol . Barnelementen ska returneras i den ordning användaren ska navigera i dem. Som applikationsförfattare kan du använda tillgänglighetsbehållare för att åsidosätta standardbeställningen överst till vänster till höger om VoiceOver-svepnavigering. Med tanke på att UIView implementerar UIAccessibilityProtocol kan du kombinera förekomster av UIAccessibilityElement och UIView i samma serie med barntillgänglighetselement. Observera att om du tilldelar element manuellt behöver du inte implementera några dynamiska protokollmetoder för tillgänglighet, men du kan behöva utfärda en skärmändringsmeddelande för de element som ska upptäckas av VoiceOver.

Modalvy

Modala vyer fångar användarens uppmärksamhet helt tills en uppgift är klar. iOS klargör detta för användare genom att dimma och inaktivera allt annat innehåll när en modalvy, t.ex. en varning eller popover, är synlig. En app som implementerar ett anpassat modalt gränssnitt måste antyda till VoiceOver att denna vy förtjänar användarens odelade uppmärksamhet genom att ställa accessibilityViewIsModal . Observera att den här egenskapen endast ska ställas in på vyn som innehåller modalt innehåll, inte element som finns i en modalvy.

myModalView.accessibilityViewIsModal = YES;

Att märka en vy som modal uppmuntrar VoiceOver att ignorera syskonvyer. Om du efter att ha ställt in den här egenskapen upptäcker att VoiceOver fortfarande navigerar i andra element i din app kan du försöka dölja problemvisningar tills modalen avslutas.

Dölja element

De flesta UIKit-klasser, inklusive UIView, följer UIAccessibilityProtocol och returnerar korrekta värden som standard. Det är lätt att ta för givet att en UIView som är dold också saknas från tillgänglighetshierarkin och inte kommer att navigeras av VoiceOver. Även om detta standardbeteende vanligtvis är tillräckligt, finns det tillfällen då en vy kommer att finnas i visningshierarkin men inte synlig eller navigerbar. Till exempel kan en samling knappar överlappas av en annan vy, vilket gör dem osynliga för en synskad användare. VoiceOver kommer dock fortfarande att försöka navigera dem eftersom de tekniskt inte är dolda från UIKit och därför fortfarande finns i tillgänglighetshierarkin. I sådana fall måste du antyda VoiceOver att föräldervyn inte är tillgänglig. Du kan göra detta genom att uttryckligen dölja vyn från UIKit genom att ställa in dold när vyn går utanför skärmen:

myViewFullofButtons.hidden = YES;

Alternativt kan du lämna föräldervyn synlig och helt enkelt dölja sina barn från tillgänglighetshierarkin:

myViewFullofButtons.accessibilityElementsHidden = YES;

Tillfälliga vyer är en annan plats som du vill dölja element från tillgänglighetshierarkin medan du lämnar dem synliga för användare. Den vy som dyker upp när du trycker på volymknappen är till exempel synlig för synskådade användare men kräver inte uppmärksamhet på samma sätt som en normal varning. Du skulle inte vilja att VoiceOver ska avbryta användaren och flytta markören bort från vad de gjorde för att tillkännage den nya volymen, speciellt med tanke på att justering av volym redan ger hörselåterkoppling genom klickljudet som det gör. I sådana fall vill du dölja vyn med accessibilityElementsHidden .