7 veelgemaakte toegankelijkheidsfouten (en hoe ze te vermijden)

De kans is groot dat je al eerder hebt gehoord over digitale toegankelijkheid, en je weet dat het belangrijk is om je online product te optimaliseren voor mensen met een beperking. Het is begrijpelijk als je je overweldigd voelt door alle informatie en taken die je moet uitvoeren om je product te verbeteren. Misschien ben je tot de conclusie gekomen dat het zo ingewikkeld is dat je een expert moet inhuren om het werk te doen. Ondertussen geef je er wel om! Je weet alleen niet hoe je moet beginnen.

Maak je geen zorgen; het verhelpen of vermijden van deze problemen is vaak niet zo tijdrovend! Tenminste, als je weet waar je moet zoeken en wat je in plaats daarvan moet doen. In de jaren dat ik als webontwikkelaar en front-end software engineer heb gewerkt, ben ik veel toegankelijkheidsproblemen tegengekomen. Vaak komen ze neer op dezelfde punten. In de meeste gevallen kost een toegankelijkheidsgerichte aanpak niet veel tijd. Het is niet moeilijker of duurder. Het is je dagelijkse werk doen met een andere mindset die de toegankelijkheid enorm verbetert.

Maar nu het echte werk: laat me uitleggen wat de meest voorkomende toegankelijkheidsproblemen zijn en, nog belangrijker: hoe je ze kunt vermijden.

Fout 1: Slechte semantische markup

Toegankelijkheidsproblemen vermijden vereist geen extra werk. Het vereist gewoon ander werk

Een van de meest gemaakte fouten met helaas grote gevolgen is slechte semantische markup. Als je een beetje HTML kent, weet je misschien dat een pagina bestaat uit elementen die worden gedefinieerd door HTML tags, bijvoorbeeld <h1> en <p>. De meeste elementen zijn semantisch: ze beschrijven duidelijk hun betekenis op een voor mensen en machines leesbare manier.

Als je de broncode van een willekeurige webpagina bekijkt, zie je ook veel <div> en <span> elementen; dit zijn de niet-semantische elementen. Dit zijn de niet-semantische elementen. Deze elementen zijn generieke containers, die geen betekenis geven aan hun inhoud.

Schermlezers vertrouwen sterk op semantische HTML. Ze vormen een toegankelijkheidsboom op basis van de semantiek van de pagina. Een gebruiker met een schermlezer kan van element naar element springen met behulp van sneltoetsen. Het vertelt hen wat knoppen zijn, wat koppen zijn, waar de navigatie is, hoe informatie op de pagina zich verhoudt tot andere elementen op de pagina, enzovoort.

Overmatig gebruik van niet-semantische elementen

Als je <div> en <span> elementen gebruikt waar een semantisch element had moeten staan, gaat er direct essentiële informatie verloren. Gebruikers met een visuele beperking kunnen de structuur van de website niet zien op basis van wat ze zien. Ze kunnen de knoppen of het navigatiemenu niet zien. De webpagina wordt één grote stapel ongestructureerde inhoud. Erger nog, vaak worden interactieve elementen - zoals knoppen - volledig onbruikbaar. Als ik over het web surf, kom ik vaak <span> elementen tegen die worden aangestuurd door JavaScript, gestyled als een knop. De JavaScript is geschreven om geactiveerd te worden door een muisklik. Dit werkt prima voor iedereen die een muis kan gebruiken, maar het kan niet met het toetsenbord worden bediend en het is vaak onmogelijk voor een schermlezer om het te vinden.

Tip: gebruik semantische HTML

Als het eruit ziet als een knop en zich gedraagt als een knop, dan moet het een knop zijn

Mijn tip om dit ongewenste gedrag te vermijden is waarschijnlijk geen verrassing: gebruik zoveel mogelijk de juiste semantische HTML-elementen. De enige gevallen waarin je <div> en <span> elementen zou moeten gebruiken, zijn wanneer er geen ander element beschikbaar is om betekenis over te brengen. Dit komt meestal neer op decoratieve doeleinden.

Het gebruik van semantische elementen zal de toegankelijkheid van je webpagina exponentieel vergroten. Deze bevatten namelijk informatie voor de browser over hoe ze moeten worden gebruikt. Bovendien bespaar je als ontwikkelaar of engineer zelfs tijd. Je hoeft niet na te denken over het nabootsen van het gedrag van bijvoorbeeld een knop, omdat die al op die manier werkt.

De verkeerde semantische elementen gebruiken

Een andere veelgemaakte fout in deze categorie is het kiezen van het verkeerde semantische element. Dit is vaak het resultaat van het kiezen van een element voor hun uiterlijk in plaats van hun gedrag of hun doel. Misschien heb je een native <button> niet gebruikt omdat je dacht dat het er lelijk uitzag. Of misschien heb je een paar kopniveaus overgeslagen en een <h4> gekozen in plaats van een <h2>, omdat je die een kleinere lettergrootte vond hebben. Dit is de verkeerde manier; daar hebben we CSS voor.

Tip: kies een element vanwege zijn betekenis

Gebruik HTML-elementen om je inhoud te structureren op basis van de betekenis van elk element, niet het uiterlijk. Pas vervolgens stijlen naar wens toe met CSS.

Tip: gebruik geautomatiseerde tools

Een mooie manier om je te helpen met semantiek is het gebruik van een HTML validator tool. Sommige tools nemen dit op in geautomatiseerde toegankelijkheidstests, zoals bijl Tools. Onthoud dat geautomatiseerde tools niet alles kunnen testen en vaak valse positieven en negatieven bevatten. Maar het kan wel helpen om snel fouten te vinden die je misschien over het hoofd hebt gezien. De beste optie is om geautomatiseerde en handmatige tests voor toegankelijkheid te combineren.

Fout 2: Slecht gestructureerde formulierlabels

Als het eruit ziet als een knop en zich gedraagt als een knop, dan moet het een knop zijn.

Deze fout heeft ook veel te maken met semantische HTML. Vergis je niet: het ontwerpen en implementeren van een bruikbaar, toegankelijk en mooi uitziend formulier is een hele uitdaging!

Het aanmeldingsformulier van Easy LMS. De labels schuiven op als je een formulierveld invult, zodat ze zichtbaar blijven.

Invoer en label zijn niet gekoppeld

Elk formulier heeft een invoerveld en een label dat dat invoerveld beschrijft. Ik heb bijvoorbeeld drie invoervelden: "Naam", "E-mailadres" en "Bedrijf". Ik zou de namen in platte tekst boven de invoervelden kunnen zetten (zoals in een <span> element ?). Helaas zal een schermlezer drie lege tekstinvoervelden vinden zonder een indicatie van wat er ingevuld moet worden.

Tip: label en invoer koppelen

Met het gebruik van semantische HTML-elementen voor de labels kom je al een heel eind, maar als je je gebruikers echt wilt helpen, moet je ook koppel je label en invoer. Nu weet de browser dat de twee bij elkaar horen. Bij Easy LMS zouden we zeggen: winst!

Plaatshouderattributen gebruiken als labels

Een andere toegankelijkheids no-go is het weglaten van labels en in plaats daarvan plaatshouderattributen gebruiken op de ingangen. Dit is om een paar redenen een slechte praktijk. Ten eerste is het vaak niet beschikbaar voor veel ondersteunende technologieën. Ten tweede verdwijnen de labels zodra een gebruiker de invoer typt (of het formulier automatisch invult). Op die manier is het moeilijk om het formulier te controleren op fouten. Ten slotte is een placeholder bedoeld als extra hint - niet als label.

Tip: Vervang een label niet door een placeholder

Laat labels nooit weg in een formulier. Als het toch moet, gebruik dan alleen placeholders om (ziende) gebruikers extra hints te geven in formulieren. Maar nog beter: gebruik helemaal geen placeholderattributen en zorg ervoor dat de belangrijke informatie over het formulier voor iedereen beschikbaar is.

Fout 3: Niet-beschrijvende links gebruiken

Hoe vaak ben je links tegengekomen met de tekst "klik hier", "lees meer" of "ga naar deze pagina"? Mijn gok: meer dan je kunt tellen! Een van de redenen waarom dit een slechte gewoonte is, is dat het niet mogelijk is om het doel van de link uit zijn context te begrijpen. Met hulptechnologieën kunnen gebruikers snel door de links op een pagina navigeren. Stel je voor dat een schermlezer je het volgende vertelt: "Hier, link. Lees meer, link. Deze pagina, link". Dat zegt je niet echt iets, toch?

Tip: neem het onderwerp van de pagina op in de link

Hoe kunnen we dit voorkomen? In de meeste gevallen kan dit eenvoudig worden opgelost door het onderwerp of de titel van de pagina waarnaar je verwijst op te nemen in de link. Ik zal je een voorbeeld geven: je kunt meer te weten komen over verschillende soorten handicaps in dit artikel van W3C. Nu zal de schermlezer communiceren: "verschillende soorten handicaps, link". Winst!

Tip: optimaliseer herhaalde links

Ik kan me voorstellen dat je de titel niet in elke "Lees meer"-link onder een lijst met artikelen wilt opnemen. Het voegt een hoop rommel toe aan de pagina. Er zijn een aantal verschillende benaderingen om "lees meer" links toegankelijk te maken, en het verschilt per use case welke het beste zou werken. Op het overzicht van deze blog, hebben we ervoor gekozen om de links te optimaliseren voor schermlezers door een aria-label toe te voegen dat de titel van het artikel bevat.

Fout 4: Vertrouwen op afbeeldingen als de enige manier om informatie over te brengen

Omdat ik een visueel denker ben, weet ik hoeveel makkelijker het kan zijn om iets te begrijpen aan de hand van een afbeelding dan door het lezen van tekst. Ik zal niet beweren dat het slecht is om visuals te gebruiken om uit te leggen of om naar te verwijzen in een uitleg. Sterker nog, ik zou iedereen aanmoedigen om afbeeldingen op die manier te gebruiken, omdat het voor sommige beperkingen (zoals dyslexie) de toegankelijkheid verbetert. Het gebruik van afbeeldingen als de enige manier om informatie over te brengen is echter een slechte gewoonte.

Over de hele wereld zijn ongeveer 43 miljoen mensen blind en hebben ongeveer 295 miljoen mensen een matige tot ernstige visuele beperking. Dit aantal omvat niet alleen totale blindheid, maar bijvoorbeeld ook verlies van centraal of perifeer zicht en wazig zicht. Als je afhankelijk bent van afbeeldingen om je punt uit te leggen, loop je het risico dat een deel van je publiek een groot deel van de informatie mist.

Schermafbeeldingen

Een praktijkvoorbeeld van dit probleem is het uitleggen van het gebruik van een interface met behulp van schermafbeeldingen. De tekst luidt eenvoudigweg "klik op de knop die in de schermafbeelding is gemarkeerd" of "stel je configuratie in zoals in de volgende schermafbeelding". Zonder deze afbeeldingen is het onmogelijk om te weten wat je met deze instructies moet doen. Als je bedenkt dat dit soort artikelen vaak te vinden zijn in kennisbanken, documentatie of tutorials, wordt het nog problematischer.

Een voorbeeld van een schermafbeelding uit ons Helpcentrum. De begeleidende tekst van het helpartikel luidt: "Je kunt de instellingen voor je pascategorie aanpassen door Bewerken te selecteren".

Tip: je tekst moet begrijpelijk zijn zonder afbeeldingen

Je publiek moet de informatie ook zonder afbeeldingen kunnen begrijpen. Met instructies in zowel tekst als afbeeldingen kan je lezer zelf kiezen op welke manier hij of zij de informatie tot zich wil nemen of heeft hij of zij een fallback in het geval van beperkingen. Een truc die ik persoonlijk gebruik is om de tekst in zijn geheel te schrijven en de afbeeldingen achteraf toe te voegen, zoals ik voor dit blogartikel heb gedaan. Op deze manier kom ik niet in de val om informatie weg te laten omdat het zichtbaar was in een afbeelding terwijl ik aan het schrijven was.

Gebrek aan alternatieve tekst

Vaak hebben informatieve afbeeldingen op websites een slechte alternatieve tekst of ze hebben het helemaal niet. Het doel van alt-teksten is om de afbeelding te beschrijven voor gebruikers van schermlezers. Als deze leeg is, weten gebruikers van schermlezers niet wat er op de afbeelding staat of dat ze belangrijke informatie hebben gemist.

Tip: voeg alternatieve teksten toe aan functionele en informatieve afbeeldingen

De alternatieve tekst wordt gecommuniceerd naar een gebruiker die de afbeelding niet (goed) kan zien. Ik zou iedereen willen aanmoedigen deze niet te negeren, maar een duidelijke beschrijvende alternatieve tekst toe te voegen voor de afbeelding. Dit kan in de broncode. In een CMS is er vaak een speciaal invoerveld voor.

Tip: behandel decoratieve afbeeldingen voor schermlezers anders

Soms worden afbeeldingen alleen toegevoegd als versiering om een pagina visueel aantrekkelijker te maken. Soms is het het beste als afbeeldingen helemaal worden overgeslagen door een schermlezer. Er zijn verschillende benaderingen hoe om te gaan met alternatieve teksten afhankelijk van het doel van de afbeelding.

Tekst in afbeeldingen

Tekst in afbeeldingen is ook niet begrijpelijk voor mensen met een visuele beperking. Het zal je verbazen hoeveel tekst er in afbeeldingen staat (kijk maar naar een willekeurig social media platform). Nogmaals, dit is op zich niet erg, maar zorg ervoor dat je de tekst ook toevoegt in een beschrijving of als alternatieve tekst.

Fout 5: Slecht kleurcontrast

Kies een HTML-element om zijn betekenis, niet om zijn uiterlijk

Tekst met een laag contrast was het meest ontdekte toegankelijkheidsprobleem door geautomatiseerde tests uitgevoerd door WebAIM. Dit is niet alleen problematisch voor mensen met slechtziendheid, maar ook voor mensen met kleurenblindheid. Ongeveer 1 op de 12 mannen en 1 op de 200 vrouwen heeft een bepaalde mate van kleurenblindheid. Sommige mensen zijn zich er niet eens van bewust dat ze dit hebben. Als je naar de afbeelding hieronder kijkt, welk getal zie je dan?

Which number do you see? Image source

Als je 74 ziet, heb je mogelijk normaal kleurenzicht. Als je 21 of helemaal geen getal ziet, heb je misschien een rood-groen kleurenzien deficiëntie. In dat geval ben je misschien websites tegengekomen met onderdelen die moeilijk te lezen waren.

In de WCAG is een Succes Criterium gedefinieerd voor wanneer het contrast tussen tekst en de achtergrond hoog genoeg is zodat mensen met matig slecht zicht het kunnen lezen. De richtlijnen van WCAG zijn onderverdeeld in drie niveaus van conformiteit. Bij Easy LMS streven we naar niveau AA. Deze contrastverhoudingen zijn 4,5:1 voor kleine tekst en 3:1 voor grote tekst.

Tip: gebruik een hulpmiddel om het kleurcontrast te controleren

Dus hoe kom je erachter of het contrast van de tekst hoog genoeg is? Er zijn veel tools voor kleurcontrast beschikbaar waarmee je tests kunt uitvoeren op je webpagina. Je kunt het kleurcontrast ook handmatig testen door de kleurcodes van de voor- en achtergrondkleur in te voeren in een online contrast checker.

Tip: gebruik donkere of lichtere tinten van een kleur

Een probleem dat zich hierbij vaak voordoet, is dat de kleuren die worden gebruikt in de gebruikersinterface overeenkomen met de kleuren van het merklogo. Dit kan het moeilijk maken om aan te pakken, omdat de kleuren aanvoelen alsof ze deel uitmaken van de merkidentiteit. Een goede gewoonte is om een donkerdere of lichtere tint van de gewenste kleur te gebruiken om het contrast te verbeteren. We hebben de kleuren van Easy LMS om deze reden een paar jaar geleden aangepast!

Kleur gebruiken als de enige manier om informatie over te brengen

Eerder noemde ik de problemen die voortkomen uit het gebruik van afbeeldingen als de enige manier om informatie over te brengen. Hetzelfde geldt voor kleuren. De kleuren rood en groen worden vaak gebruikt als de enige manier om informatie te geven over succes- en fouttoestanden. Helaas is rood-groen kleurenblindheid de meest voorkomende vorm van kleurenblindheid. Voor deze gebruikers lijken rood en groen op elkaar.

Tip: zorg voor meerdere manieren om over toestanden te communiceren

Het is OK om rood en groen te gebruiken voor deze doeleinden, maar zorg ervoor dat je altijd een andere manier biedt om toestanden te communiceren, zoals tekst, verschillende vormen of (gelabelde) pictogrammen.

Fout 6: Geen visuele indicatie geven van de huidige focus

De meeste gebruikers navigeren op hun computer met een aanwijsapparaat, zoals een muis of een trackpad op een laptop. Op mobiele apparaten gebruiken we onze vingers op een aanraakscherm. Voor sommige gebruikers is dit moeilijk of onmogelijk vanwege hun handicap. Voorbeelden zijn verlamming, een ontbrekend lichaamsdeel, artritis of Repetitive Stress Injury. In deze gevallen schakelen gebruikers vaak over op een toetsenbord of een alternatief invoerapparaat dat toetsenbordgedrag kan nabootsen. Gebruikers met een visuele beperking gebruiken meestal een toetsenbord naast hun schermlezer of gebaren op hun mobiele apparaten.

Als je op de Tab-toets op je toetsenbord drukt, kun je tussen interactieve elementen op een webpagina springen, zoals knoppen en links. U kunt het op deze pagina uitproberen: na elke tab ziet u een visuele indicatie van uw locatie op het scherm.

CSS focusstijlen

In CSS kun je styling toevoegen voor verschillende toestanden van knoppen, zoals zweven, focus en actief. Vaak worden sommige of al deze statussen weggelaten en verandert de knop niet van uiterlijk bij interactie. Een toetsenbordgebruiker is in dit geval blind.

Tip: pas focusstijlen toe samen met de hoverstijlen

Terwijl je stijlen toevoegt voor de hover-status van de knoppen, is het een goede gewoonte om ze ook toe te voegen voor de focus-status. Idealiter zou de focusstijl duidelijker moeten zijn dan de hoverstijl, dus je kunt ze ook afzonderlijk toevoegen in een andere tint.

Overzicht browserfocus

Een basisindicator voor focus wordt automatisch geleverd door de webbrowser en wordt meestal weergegeven als een rand. Als je net door deze pagina hebt getabd, heb je dit misschien gezien. Helaas wordt deze omlijning vaak uitgeschakeld met CSS, vanwege esthetische redenen. Maar als de omlijning is uitgeschakeld en er geen focusstijlen zijn, is het onmogelijk om door een webpagina te navigeren met alleen een toetsenbord.

Tip: schakel de contour niet uit

Muisgebruikers zien de omtrek van de browser niet die je ziet als je met een toetsenbord door een webpagina bladert. Schakel deze omlijning niet uit met CSS, want het is een essentieel hulpmiddel voor gebruikers met een handicap. Het werkt ook prima als back-up voor het geval je focusstijlen te onduidelijk zijn of per ongeluk ontbreken.

Houd er wel rekening mee dat toetsenbordfocus-indicatoren door browsers kunnen variëren en verschillende vormen kunnen aannemen. Daarom kun je er niet volledig op vertrouwen. Aan de andere kant zou het veel testen vergen om zeker te weten of je focusstijlen duidelijk genoeg zijn voor gebruikers met een beperking. Daarom adviseer ik om altijd beide te gebruiken.

Fout 7: Pictogrammen zonder label gebruiken in knoppen en koppelingen

Pictogrammen in software worden herkenbaar bij herhaald gebruik

Pictogrammen zijn een geweldige manier om rommel in je online product te voorkomen. Ze kunnen ook de toegankelijkheid voor verschillende handicaps verbeteren, als ze tenminste ondubbelzinnig zijn. De meesten van ons weten dat een potloodpictogram "bewerken" betekent en een prullenbak "verwijderen". Als we pictogrammen gebruiken in een gebruikersinterface, is het het beste om ons te houden aan de pictogrammen die we kennen om gissen te voorkomen. Maar zelfs dan kan er op het gebied van toegankelijkheid veel misgaan.

Pictogrammen kunnen naast hun corresponderende tekstlabel of alleen worden gebruikt. Meestal is er geen label voorzien wanneer ze alleen worden gebruikt. Ik voeg bijvoorbeeld een knop met pictogrammen toe voor een bewerkingsactie, met alleen een potlood erin. Als ik geen tekstlabel toevoeg aan dit pictogram, wordt de knop een lege knop. Dat klopt: een schermlezer zal tegen mij zeggen: "Knop". Dat is niet erg nuttig.
Nog meer: Ik ga ervan uit dat de gebruiker weet dat een potloodpictogram "bewerken" betekent. Maar dat weet ik niet zeker.

Tip: voeg een label toe voor pictogrammen

Als het pictogram een belangrijk onderdeel is van je gebruikersinterface, dan kun je het beste een label toevoegen. Je kunt dit doen door een aria-label toe te voegen aan het pictogram. Een tweede manier is om tekst toe te voegen die je verbergt voor schermen, maar zichtbaar is voor gebruikers van schermlezers. Je kunt het beste ook een titelattribuut toevoegen. Als een muisgebruiker er dan met de muis overheen gaat, wordt het label weergegeven.

Pictogramknoppen in het Easy LMS dashboard die een titel weergeven als je er met de muis overheen gaat

Tip: decoratieve pictogrammen verbergen

Als je een pictogram puur als suiker bovenop hebt gezet en de informatie ook zonder dit pictogram begrijpelijk is, dan kun je het beste verberg het element voor schermlezers.

Conclusie: werk niet harder, maar slimmer

De gedachte dat je deze dingen moet veranderen kan nog steeds een beetje overweldigend zijn. Toen ik voor het eerst over toegankelijkheid leerde, had ik dezelfde reactie. Er is zoveel te leren en er zijn zoveel verschillende soorten beperkingen. Het is moeilijk om een gebruikersinterface perfect te maken voor iedereen.

Maar ik wil je zeggen: het gaat er niet om je product of website om te gooien. Ik heb ontdekt dat dit het beste werkt als je het in je workflow integreert. De volgende keer dat ik een deel van het product maak of herzie, pas ik meteen toe wat ik heb geleerd over toegankelijkheid. Op deze manier kunnen we toegankelijkheid stap voor stap verbeteren. Zoals een van mijn toegankelijkheidshelden Léonie Watson adviseert: "Het hoeft niet perfect te zijn; het moet gewoon een beetje beter zijn dan gisteren." Preek!