Vue accessibility specialist

Standaard toegankelijkheidsproblemen in Vue.js

Wij weten wat er in een standaard project van Vue.js al mis gaat met toegankelijkheid. Daarnaast weten we wat de meest voorkomende fouten zijn met toegankelijkheid en zijn we up to date over complexere patronen zoals dialogs. Naast dat wij helder in het zicht hebben wat er mis kan gaan, kunnen wij door onze Vue.js kennis jouw volledige implementatie in al haar logische paden nalopen om vast te stellen of deze fouten ergens voorkomen. 

Aan de WCAG richtlijnen voldoen

Deze controles voeren wij uit in de vorm van een drill-down waarbij we eerst naar de overkoepelende standaardproblemen kijken en dan steeds specifieker gaan werken.

1. Standaardproblemen in Vue: We controleren of screenreaders paginatitels en foutmeldingen voorleest en of toetsenbord gebruikers herhalende blokken op pagina’s kunnen overslaan met een skip links component. 

2. Automatische tests: Automatische tests kunnen 50% van de fouten voorkomen, daarom sluiten we geautomatiseerde axe tests op elke component in elke state aan, gebruiken we vue accessibility linting door heel de applicatie heen en gebruiken we een vue axe scanner op pagina niveau. 

3. Manuele pagina tests: We doorlopen elke pagina met het toetsenbord en de screenreader om te kijken of we alles netjes voorgelezen krijgen en we nergens vast komen te zitten met ons toetsenbord. Daarnaast houden we natuurlijk onze vue axe scanner nauwlettend in de gaten. We kijken vooral naar problemen met notificaties, validatie foutmeldingen, dialoogvensters, actie- en navigatie menu's en tabs. Ook wordt elke paginatitel en de headings structuur nagekeken. 

4. WCAG-EM template: Voordat we beginnen aan de opvolgende controles werken we het standaard template voor de WCAG-EM voor jouw organisatie uit. Dit template stellen we op met de standaard wizard hiervoor. In dit template sluiten we alle tests uit waarvan we weten dat de achterliggende technieken niet worden gebruikt. Bijvoorbeeld als audio of video niet wordt gebruikt in je applicatie. 

5. Eerste WCAG checks: Voor we de complexere controles uitvoeren voeren we de volgende acties uit: We controleren op contrast van de gebruikte kleuren, we bekijken de applicatie in 200% zoom, 200% text only zoom en met een digitaal vergrootglas, we zoeken naar flitsende, bewegende en knipperende content, we kijken of de nodige multimedia alternatieven aanwezig zijn en doen een structuur check van elke pagina. 

6. Volledige WCAG-EM check: we voeren de overige controles van de WCAG-EM check uit. Denk hierbij aan controles of de hele applicatie op het kleinste toegestane formaat werkt, of het in landscape en portrait oriëntatie werkt en of je alle tijdgebonden events ook kan instellen.

7. Libraries: Wanneer er een componentenbibliotheek wordt gebruikt of wanneer er door onszelf complexe toegankelijkheidscomponenten worden gebouwd controleren wij of de oplossing in elke screenreader & browser combinatie werkt en zorgen we voor een echte gebruikerstest.  

In dit proces zullen we vaak tijdens en minstens na elke stap de verbeteringen aanbrengen in vue en deze uitrollen. 

Daarnaast helpen wij jouw organisatie ook met het opzetten van een testgroep van mensen met een beperking. Het liefste zetten we in op het vinden van een testgroep van mensen die daadwerkelijk je applicatie gebruiken. Natuurlijk doen we alles in nauw overleg met jou. 

De laatste fase voor het voldoen aan de WCAG richtlijnen is het organiseren van een audit via een van onze partners. Met deze laatste stap bewijzen we voor jou en alle externe stakeholders dat de applicatie volledig toegankelijk is gemaakt. 

Terugval voorkomen

Met het bovengenoemde proces pellen we je applicatie laag voor laag af tot er een geheel toegankelijke applicatie is. Om te zorgen dat je hiervan zoveel mogelijk de vruchten plukt, voeren we zoals hierboven beschreven geautomatiseerde controles in die de kans op regressie al terug dringt. 

Daarnaast weten we dat een te grote HTML structuur voorspellend is voor meer toegankelijkheid fouten. En we durven onze hand er voor in het vuur te steken dat complexere CSS en complexere Vue.js code ook aan ditzelfde probleem bijdragen. Want uiteindelijk zorgt al deze complexiteit ervoor dat je slechter overzicht houdt over je project en dus ook over de toegankelijkheid. 

Daarom richten wij ons in het project erop om de HTML en CSS in complexiteit terug te dringen en zo veel mogelijk om te zetten naar de moderne en stabiele implementatie. 

Het omschrijven draagt bij aan kortere schrijfwijzen en daarmee aan meer overzicht. We doen dit natuurlijk alleen als de nieuwere HTML en CSS op het gebied van toegankelijkheid volledige ondersteuning heeft. 

Ook zorgen we ervoor dat elke toegankelijkheidsoplossing die we inbouwen geen overbodige implementatie is. Het komt regelmatig voor dat er om meerdere plaatsen hetzelfde probleem voor toegankelijkheid wordt opgelost, wat de kans vergroot dat het op een van die plaatsen ook weer kapot gemaakt wordt. 

Ook voor Vue.js zorgen we dat Vue 3 gebruikt en je waar mogelijk de meest standaard oplossingen uit vue en vue-use toepast. Zodoende kunnen we vaak veel legacy code wegwerken en hoeft je team zich alleen te richten op waar je applicatie daadwerkelijk onderscheidend in is. 

Documentatie, introductie en overdracht

Bij de start van ons traject laten we graag een van onze partners op het gebied van toegankelijkheid een toegankelijkheid awareness workshop geven, zodat er een basis wordt gelegd die breder is dan alleen Vue.js. 

Wanneer we jouw applicatie toegankelijk maken, zorgen we ook voor borging van de kennis in je eigen organisatie. Dat doen we door elke stap in het proces te introduceren aan het in-house team met een workshop, waarbij alle programmeurs ook hands-on een probleem oplossen en de oplossing aan elkaar presenteren. 

Voor iedereen die er niet bij kan zijn en voor wie later bij het project aansluit zorgen we dat er documentatie in het project is zodat ook zij door collega’s op weg kunnen worden geholpen om toegankelijkheid te behouden. 

Voorlopen in toegankelijkheid

Veel organisaties proberen met minimale moeite net te voldoen aan de bestaande toegankelijkheidseisen. Wij zien dit als een grote misser omdat je hiermee nogal eens kan uitkomen op een applicatie die technisch gezien door het hoepeltje springt maar in de praktijk geen fijne ervaring biedt voor de gebruikers. 

Wij zetten daarom altijd in op voorlopen in toegankelijkheid, waarbij we de nieuwste tech op dit gebied in de applicatie verwerken, zodat alle doelgroepen een geweldige ux ervaring hebben. 

De ratio hierachter is simpel en bewezen. Als organisatie wil je je omzet verhogen. Goede toegankelijkheid komt weinig voor en daardoor richt je je hiermee op een trouwe doelgroep die bij jou terecht kan. Een simpel praktijkvoorbeeld is een hypotheekverstrekker die zijn omzet met 10% zag groeien.

Als organisatie wil je dat je medewerkers hun werk zo goed mogelijk kunnen doen. 85% van de handicaps manifesteren zich tussen de 16 en 65 jaar en worden vaak door de jaren heen erger. En vaak duurt het 3 tot 4 jaar voordat een medewerker aan de bel trekt voor ondersteuning voor de handicap. Door je software al volledig toegankelijk te hebben, kunnen je medewerkers zelf al naar de ondersteuning grijpen en hoef je het niet aan te passen om aan de arbowet te voldoen.