Ontwikkelen van toegankelijke apps

Bart Simons op 25/02/2014 - 3 reacties

Smartphones en tablets die werken met Android en iOS zijn vandaag goed bruikbaar door personen met een handicap. Zie voor meer details ons eerdere artikel Mobiel surfen met een handicap. Meer en meer krijgen we dan ook de vraag om naast websites ook apps te testen op toegankelijkheid. Hier volgen een aantal zaken om rekening mee te houden en links om je als ontwikkelaar op weg te helpen. We beperken ons in dit artikel tot apps voor het Android en iOS platform.

Jonathan Mosen toont in deze video wat de meerwaarde is van een smartphone en waarom het loont om apps toegankelijk te maken.

In theorie zijn de Web Content Accessibility Guidelines technologie-onafhankelijk geformuleerd en zouden ze dus ook bruikbaar moeten zijn om apps te testen. Sommige aspecten lijken inderdaad veel op het testen van een website, vb. zijn knoppen gelabeld, links betekenisvol, tabellen lineariseerbaar en formuliervalidatie duidelijk voor wie het scherm niet kan zien.

Het is echter moeilijker om concreet te adviseren hoe gevonden problemen verholpen kunnen worden. We kunnen immers niet even in de broncode kijken zoals bij een website. Hier volgen enkele voorbeelden:

Bruikbaar met het toetsenbord

Het eerste ijkpunt van de AnySurfer checklist vraagt dat alle functionaliteit bruikbaar is met het toetsenbord. Hoe vertalen we dit naar het aanraakscherm van een smartphone of tablet?

Een blinde gebruiker gaat heel anders om met het aanraakscherm dan iemand die het scherm kan zien. Screenreaders als VoiceOver voor iOS en Talkback voor Android doen meer dan voorlezen wat er op het scherm staat. Ze bieden een heel bedieningsconcept, ook met aangepaste aanraakgebaren (bekijk een video). Met een vinger van links naar rechts vegen, verplaatst de focus naar het volgende element. U moet er als ontwikkelaar dus voor zorgen dat deze focus bij alle elementen van de app kan komen en dat dit in een logische volgorde gebeurt.

Semantiek

Gebruik zoveel mogelijk standaardcomponenten voor interactieve elementen als keuzelijsten en aankruisvakjes. Daarvoor voorzien screenreaders zelf al alternatieve bedieningsconcepten. Als u een eigen component programmeert, moet u die grondig testen met de screenreader en zelf een aantal functionaliteiten voorzien.

Afbeeldingen hebben een alt-tekst

Afbeeldingen op websites moeten een alt-tekst hebben. In apps geldt hetzelfde voor knoppen. Het concept is hetzelfde maar de terminologie zal verschillen van de ene ontwikkelomgeving tot de andere.

Als u vergeet een knop te labelen, dan wordt de bestandsnaam van de knop voorgelezen in plaats van de functie ervan. Het is veel vlotter als je "terug" hoort in plaats van "NavBarIconBackButtonSmall".

Documentatie voor ontwikkelaars

Zowel voor iOS als Android ontwikkelaars is documentatie beschikbaar over het ontwikkelen van toegankelijke apps voor deze platformen.

Reacties

Bart Simons schreef 1 jaar geleden

Deze app van Deque toont iOS developers enkele basisaspecten die je moet kennen om toegankelijke apps te ontwikkelen

Bart Simons schreef 1 jaar geleden

Google lanceert een app waarmee ontwikkelaars hun eigen apps kunnen testen op toegankelijkheid: Download Accessibility Scanner van Google Play

Bart Simons schreef 4 maanden geleden

De ontwikkelomgeving Xcode beschikt nu ook over een een accessibility inspector. Daarmee kan je als ontwikkelaar toegankelijkheidsproblemen opsporen op eender welke app op eender welk platform (iOS, watchOS, macOS of tvOS) dat is aangesloten op je Mac waar Xcode op draait. Bekijk de introductie

Reageer

De volgende HTML tags zijn toegestaan: <a> <b> <ul> <li>