Toegankelijkheid op het Web – een introductie

Als je eindgebruiker jouw zorgvuldig ontworpen prachtknop niet kan selecteren, dan zijn mooie kleurtjes en effectjes nutteloos want de hele knop is onbruikbaar. Of als deze niet meegenomen wordt in een screenreader; dan bestaat hij zelfs niet voor slechtziende of blinde gebruikers. Je perfecte knop is ineens verre van perfect of zelfs onzichtbaar – bad! Waarom zou je niet met dezelfde liefde en aandacht als waarmee jij je gradient vormgeeft niet ook je toegankelijkheid van je knop vormgeven? Dan komen nóg meer mensen in aanraking met jouw genialiteit.

Concluderend; websites bouwen met toegankelijkheid, accessibility, in het achterhoofd is geen vervelend klusje; het is een extra speelveld voor ontwikkelaars en ontwerpers om hun kunsten op los te laten en biedt bovendien een goede basis voor een helder ontwerp, zowel visueel als HTML-technisch.

Waarom?

Omdat het voor mensen met beperkingen soms zeer lastig is om toegang te krijgen tot informatie en diensten op het internet. Informatie en diensten die je nódig hebt in het dagelijks leven. Denk aan het boeken van een vliegticket, contact met de belastingdienst of eens kijken welke bus je moet hebben. Veel mensen kunnen wel een mooie website maken, maar niet elke website is toegankelijk genoeg om door deze groep mensen gebruikt te kunnen worden. Toegankelijkheid is voor overheid en semi-overheid dan ook gecodificeerd in de WCAG-richtlijnen.

Gebruikers

Het lijkt best een opgave, iets maken dat mensen die niet de gebruikelijke lichaamsfuncties hebben óók kunnen gebruiken. Het is al lastig om iets te ontwerpen dat bruikbaar is voor mensen die daar wel over beschikken. Gelukkig kom je een heel eind als je weet welke manieren van interactie dit deel van je publiek gebruikt.

Het zijn niet alleen mensen die onconventionele inputdevices gebruiken die baat hebben bij toegankelijkheid. Mensen die vaak en snel door je website moeten navigeren bijvoorbeeld – zogeheten power users – willen vaak met hun toetsenbord kunnen navigeren om zo hun efficiëntie te vergroten. Het zijn bijvoorbeeld administratieve medewerkers die meerdere keren per dag een formulier moeten invullen of informatie moeten vinden.

Soms zijn het ook mensen die tijdelijk baat hebben bij toegankelijkheid. In de trein, waar geen ruimte is voor een muis, is toetsenbordinput ook essentieel voor een fijne gebruikerservaring.

Toegankelijkheid kan ook worden meegenomen in het visuele ontwerp van je applicatie: mensen raken misschien overprikkeld en willen de animaties uit zetten. Mensen met kleurenblindheid hebben baat bij een colour-blind modus of een kleurenschema waar de kleuren ook door hen herkend kunnen worden. Voor hen is het ook belangrijk dat validatie van input niet (alleen) door kleur wordt gecommuniceerd maar ook door vormen.

Toetsenbord

• Gepersonaliseerde toetsenborden of andere input devices die naar toetsenbord mappen.
• Toetsenborden zijn, naast de muis, één van de populairste alternatieve input devices en toetsenbordtoegankelijkheid is dus heel belangrijk om mee te nemen in je ontwerp.
• Toetsenborden worden door een breed spectrum aan mensen gebruikt. Denk ook aan laptopgebruikers zonder muis.

Screenreaders

• Bijna alle moderne browsers hebben een ingebouwde screenreader die text-to-speech functionaliteit bieden.
• Screenreaders berusten op goede organisatie van je HTML en het meegeven van de juiste attributen zodat gebruikers snel naar de informatie kunnen gaan die ze zoeken.
• Screenreaders worden gebruikt door mensen die weinig of geen zicht hebben.
• Screenreaders kunnen content indexeren op basis van bijvoorbeeld headings `<h1 t/m h5>` of springen naar het eerste `<nav>` element. Als deze elementen niet goed gebruikt zijn zal de informatie die ze hierin gepresenteerd krijgen verwarrend of onbruikbaar zijn.

Mondstok (Mouthstick)

• Voor mensen met weinig tot geen functie in hun armen bestaat een soort stok die fungeert als joystick. Deze kunnen ze bewegen met hun kin of mond. Door erop te blazen kunnen ze klikken.
• Het kost veel precisie en oefening om een mondstok te gebruiken. Zorg er daarom voor dat je interface ook werkt met grotere knoppen.

Alle inputdevices maken gebruik van de DOM om de informatie te structureren en te navigeren. Zij maken gebruik van het lezen van de HTML elementen om een simpele weergave te construeren. Hieronder staat beschreven hoe dat in zijn werk gaat.

Voor de ontwikkelaar

In de introductie vertelde ik al dat als toegankelijkheid vanaf het begin al meegenomen wordt in het ontwerp, je het jezelf een stuk makkelijker maakt. Goed gebruik van de features van HTML5 creëert al een behoorlijk goed toegankelijke site. De gereedschappen die mensen gebruiken die ik onder ‘Gebruikers’ beschreef ,haken in op de HTML waaruit je site bestaat.

De DOM

Veel assistive technology is afhankelijk van de DOM structuur. Dat betekent dat hoe jouw pagina eruitziet in de geladen HTML bepaalt hoe informatie door deze technologie gevonden en gebundeld kan worden. Visueel kan iets duidelijk bij elkaar horen, bijvoorbeeld door een tekstje met de inputstate van een tekstinvoer-veld op een formulier ónder het veld te plaatsen. Visueel klopt dit, maar als dit tekstje als <p> wordt aangeleverd wordt dit gezien door screenreaders als paragraaf. Of erger: stel het zit in een <h5> – dan prioriteert een screenreader dit, terwijl een gebruiker een overzicht probeert te krijgen van de pagina. Kortom, wat visueel logisch is, is niet automatisch logisch in de DOM.

Met een goede DOM-structuur kunnen bijvoorbeeld mensen met screenreaders een lijstje krijgen van de navigeerbare elementen in de `<nav>` en een overzicht van alle subkoppen op de pagina krijgen. Mensen die afhankelijk zijn van toetsenbord input, willen misschien door de lijst met headings heen kunnen springen met hun pijltjestoetsen om zo snel naar de informatie te gaan die ze zoeken en power users willen in rap tempo een formulier kunnen invullen door te schakelen tussen de inputvelden met hun tab-knop.

Over JavaScript en Frameworks

Waar ontwikkelaars vaak de mist in gaan is bij overmatig gebruik van JavaScript en/of frameworks. Hiermee kan je de structuur van de originele HTML ondermijnen en creëer je in naam van design een onlogische DOM structuur. In feite ben je dan toegankelijkheidsproblemen die veroorzaakt worden door JavaScript aan het oplossen met meer JavaScript. In het proces kan je dan nog meer toegankelijkheidsproblemen creëren, terwijl je verwoed zoekt naar een passende oplossing. Hier zie je de paradox die ontstaat als je niet vanuit de HTML ontwerpt; goed gebruik van HTML zorgt (grotendeels) voor een goede toegankelijkheid. De enige taak van de ontwikkelaar is dan om deze niet aan te tasten tijdens verdere ontwikkeling.

Semantic HTML

Het belangrijkste voor een ontwikkelaar om te onthouden is dat er al heel veel klaarligt om te gebruiken. Het is aan de maker om deze tools te gebruiken. Eén van de grote stappen die je kan maken is het gebruik maken van HTML5 zoals het bedoeld is: gebruik voor een knop een `<button>` element en niet een eigen `<div>`. De eerste bevat integratie met alternatieve input devices en bij de tweede zal je dit zelf moeten maken. Screenreaders zullen aankondigen dat het om een knop gaat in plaats van iets anders zonder dat je daar extra moeite voor hoeft te doen.

Hetzelfde geldt voor `<h1…5>`, `<li>`, `<ul>`, `<label>` en ga zo maar door. Laat vooral de HTML het werk doen. Je maakt er elegantere code mee én je maakt je website toegankelijker. Wauw!

Conclusie

De toegankelijkheid van het web is niet vanzelfsprekend. Als ontwikkelaar kunnen we daarbij helpen door ons bewust te maken van de behoeftes van mensen en manieren waarop zij het internet gebruiken. Zo kunnen we anticiperen waar we rekening mee moeten houden.

Een ander belangrijk punt is dat we onszelf vaak in de weg zitten; in onze (terechte) behoefte om een mooi-ogend product te maken kunnen we oplossingen die voor ons zijn klaargezet in de vorm van HTML5 per ongeluk tenietdoen. Als we ontwikkelen met de beschikbare toegankelijkheidsfunctionaliteit die in HTML5 zit ingebakken wordt ons leven en dat van mensen die afhankelijk zijn van alternatieve interactievormen een stuk makkelijker.