Skip to content

BLOG

NSSPAINX 2022: Toegankelijkheid in app ontwikeling

Incluse developement

Deze blog is geschreven door Mart Zonneveld, iOS Developer bij Triple.

Na twee jaar virtuele congressen konden we in 2022 allemaal weer opgelucht ademhalen. Daarom was de 10e editie van de NSSpain conferentie in september dan ook groter dan ooit en barstte het er van de sprekers, informatie en veel enthousiaste developers. Met 22 presentaties in 2 dagen waren er veel te veel interessante onderwerpen om in één blogpost te bespreken, want elke presentatie was de moeite waard om dieper in te duiken. Daarom kiezen we er voor om het hier specifiek te hebben over de wereld van de toegankelijkheid. Een onderwerp dat eigenlijk niet alleen relevant is voor developers, maar ook voor designers en copywriters.

Uitsluiting

Toegankelijkheid is voor de meeste mensen eigenlijk onbekend terrein, want 85% van jullie heeft waarschijnlijk helemaal geen behoefte aan de meeste van de toegankelijkheidfuncties die tegenwoordig beschikbaar zijn. Maar wacht, betekent dat dus dat 15% van de mensen wel enige vorm van ondersteuning nodig heeft bij het gebruik van hun smartphone? Jazeker. 15%. Laat dat percentage maar even bezinken. Het betekent dat jij, als developer, 15% van je doelgroep kunt mislopen als jouw app niet voldoet aan tenminste enkele van de ondersteuningsfuncties die beschikbaar zijn. De getalenteerde developer Bas Broek opende de ogen van veel deelnemers aan NSSpain toen hij deze cijfers liet zien. De realiteit is dat de meeste developers ernaar streven hun product te laten werken zoals ze dat zelf ervaren. Dit wordt misschien deels veroorzaakt door de extra uren die ze eraan zouden moeten werken om specifieke functies te integreren voor mensen die de app op een andere manier ervaren.

Apps voor iedereen

Hoewel Apple veel manieren biedt om mensen met specifieke handicaps te ondersteunen, betekent dat niet dat je die allemaal tegelijk hoeft te implementeren. Een app zonder enige ondersteunende functies is misschien waardeloos voor een gehandicapte gebruiker, maar een app met al enkele functies er in maakt al een enorm verschil. Zoals Daniel Devesa Derksen-Staats op Twitter Novall Swift citeerde: "We hebben één taak, en dat is om apps te laten werken. Als je geen toegankelijkheidsfuncties implementeert, vergeet je jouw app voor veel gebruikers te laten werken."

Het eerste en eenvoudigste wat developers zouden moeten doen bij het implementeren van toegankelijkheidsvoorzieningen, is gebruik maken van de ` accessibilityLabel ` eigenschappen op de meeste `NSObjects`. Die geven meestal een beschrijving van wat het specifieke object inhoudt, zoals het label ‘Sluiten’ op een button. Bedenk dat Apple hardop voorleest wat voor soort element het is, dus in het geval van een ‘Sluiten’ knop vertelt het de gebruiker al dat het een knop is. Copywriters moeten daarom praktisch zijn en de labels eenvoudig en kort houden, zonder de essentie van het element weg te laten.

Bij het opzoeken van de `accessibilityLabel` documentatie zie je dat er nog veel meer te winnen valt, zoals `accessibilityValue`, `accessibilityHint` en `accessibilityTraits`. Dit zijn quick wins die je vrij gemakkelijk in je apps zou kunnen implementeren. En als je toch bezig bent, probeer dan eens de `heading` functie en kijk wat voor verschil je daarmee kunt maken.

Verder moet je bij de verdere ontwikkeling van je app goed bedacht zijn op teveel onoverzichtelijke informatie. Een lijst met items kan bijvoorbeeld uitgebreide metadata bevatten. Als een gebruiker 10 of meer elementen moet doorlopen om de betekenis van het item te begrijpen, is hij na item nummer 3 of 4 waarschijnlijk de weg al kwijt. Om dit te voorkomen kun je de parent waar de informatie in zit eenvoudig configureren als een toegankelijkheidselement, en een samengevatte omschrijving van alle subvensters opnemen. De gebruiker moet met verschillende soorten gebaren naar de specifieke elementen kunnen navigeren of naar het volgende item kunnen gaan: horizontaal of verticaal vegen, met één, twee, drie of zelfs vier vingers.

De piloot

Een citaat van Daniel Devesa maakte veel indruk op mij:

Stel je voor dat het leger meerdere F-16 piloten heeft en meerdere straaljagers nodig heeft. Hoe weet je dan welke maat de stoel moet hebben? Al hun piloten werden opgemeten, en ze gingen uit van de gemiddelde lengte. Nadat ze de stoelen hadden gebouwd voor de gemiddelde lengte van de piloten, paste er niet één piloot goed in! Dit komt omdat de gemiddelde mens simpelweg niet bestaat.

Dus als jij denkt dat je je app bouwt voor de 'gemiddelde gebruiker', dan bouw je een app voor niemand. Je moet gebruikers van je apps verschillende opties geven om uit te kiezen, bijvoorbeeld de lettergrootte in je app. Je kunt je houden aan de systeeminstellingen van iOS, of een aangepaste schuifregelaar implementeren waarmee ze de gewenste grootte kunnen bepalen. Hetzelfde geldt voor de lichte en donkere modus of andere kleurenschema's, taal, rechts-naar-links teksten of zelfs voor de interactie met de content. Ook al moeten je knoppen een minimale grootte van 44×44px hebben, het kan zijn dat mensen knoppen niet prettig vinden of niet kunnen gebruiken. Voor die gebruikers kun je de eigenschappen `accessibilityCustomActions` en `accessibilityCustomRotor` implementeren voor je gegroepeerde items. De gebruiker kan dan een draaiknop gebruiken om tussen items te schakelen, en met een veegbeweging door de opties lopen, zoals de acties ‘like’, ‘reply’ of ‘share’ in elk item.

App inclusivity

Het gevoelige oog

Als je er in geslaagd bent de toegankelijkheid te verbeteren door de basisstappen te integreren, is het tijd om een en ander af te stemmen met de designers van de app. De meeste apps zijn ontworpen om er goed uit te zien. Mooi, kleurrijk, speels, of misschien juist heel clean om alleen de belangrijkste informatie te laten zien. Bij het ontwerpen van een app moet je goed rekening houden met het contrast tussen kleuren. Lichtgrijs werkt niet op donkergrijs, en geel bijvoorbeeld niet goed op lichtgroen. Hoewel sommige ontwerpen er prachtig uitzien als je die kleuren toepast, zullen sommige mensen de kleuren niet kunnen onderscheiden, waardoor jouw app onbruikbaar wordt. Bij twijfel zijn er allerlei tools beschikbaar om je hierbij te helpen. Wist je bijvoorbeeld dat UIColors ook toegankelijkheidsnamen kunnen hebben, zodat mensen weten welke kleur ze zijn?

Behalve contrast kan ook de vorm heel handig zijn om je gebruiker te begeleiden. In plaats van een icoon alleen een andere vulkleur te geven, kun je overwegen om de vorm te veranderen. Dat kan bijvoorbeeld groter zijn, anders gebogen of alleen onderstreept, maar verschillende manieren om een toestandsverandering weer te geven kunnen het uiterlijk van je app meer verbeteren dan je denkt.

Laten we het gewoon gaan implementeren

We hebben het al gehad over waarom de implementatie van toegankelijkheid zo belangrijk is. Een gemiddelde gebruiker bestaat gewoon niet en ongeveer 15% van de smartphonegebruikers heeft een vorm van ondersteuning nodig om je app te kunnen gebruiken. We hebben het er ook over gehad wat jij, als developer, kunt doen om je app voor iedereen toegankelijk te maken. We hebben verder een paar voorbeelden gegeven van zaken waar copywriters of designers rekening mee moeten houden als ze aan hun apps werken.

Het meeste hiervan is geen hogere wiskunde, en Apple maakt het heel makkelijk voor je om de basisfuncties te implementeren. Nu is het jouw taak om product owners en project managers te overtuigen van het belang ervan. Laten we nu het gewoon gaan implementeren.

Meer verhalen van Tripelaars

SXSW 2023: AI, Interactieve Content en de menselijke maat

Erik van Schalkwijk

Cross-cultureel design: ontwerpen voor andere culturen dan die van jezelf

Anna Koopmans

WWDC 2022: de superkrachten van developers ondersteunen

Jeroen Bakker