Verhoogt een voorlees functie zoals websitevoice.com mijn SEO en toegankelijkheid? Vooral de toepassing van websitevoice.com in het bijzonder, is verrassend.
Via LinkedIn word ik nog wel eens getagd om mijn licht te werpen op een technisch gerelateerde vraagstuk. Veelal betreffen het pagespeed vraagstukken, soms is het gerelateerd aan toegankelijkheid.
Vandaag werd ik gevraagd naar de voorleesfunctie van websitevoice.com. Websitevoice.com levert een widget in JavaScript vorm, welke een voorleesknop introduceert.
De vraag is:
- verhoogt een voorleesfunctie de toegankelijkheid?
- verhoogt voorleesfunctie de SEO waarde (immers waardeert Google websites die gebruiksvriendelijk zijn).
Zelden ben ik kort van stof. Met de karakterbeperking in je LinkedIn-reacties, kwam het idee het antwoord op deze toegankelijkheids- en SEO-vraagstukken om te gieten in een blog.
Voor de lezers met beperkte tijd
Geen tijd om het hele artikel te lezen? Het antwoord is tweemaal "nee". Zeker de toepassing van websitevoice.com is verrassend; deze is op zichzelf niet toegankelijk.
Websites en (online) toegankelijkheid
Heb ik het over toegankelijkheid, dan heb ik het over de WCAG, voluit de Web Content Accessibility Guidelines, opgesteld en gepubliceerd door het World Wide Web Consortium (W3C). Voor overheidsinstanties is het verplicht deze richtlijnen te volgen bij online publicaties, zoals websites en documenten.
Gelijkenissen tussen SEO en toegankelijkheid
Voor de meer technisch georienteerde SEO specialist, als ook online toegankelijkheids-voorstander is het niet nieuw dat SEO en toegankelijkheid zelfs hand in hand gaan met elkaar. De reden is semantiek, betekenisleer, maar dan omtrent HTML.
Is je website toegankelijk, dan is dit bovendien bevorderlijk voor crawlability. En net als SEO, is toegankelijkheid een combinatie van factoren (waaronder techniek). Focus op beide, verbetert normaliter ook de gebruiksvriendelijkheid.
Echter, wat is de rol van een voorleesfunctie hierin?
Verbetert de websitevoice.com widget de toegankelijkheid?
Wanneer je naar de website van websitevoice.com kijkt, claimen ze (logischerwijs) dat de toegankelijkheid toeneemt. Dit valt echter vanuit de techniek te ontkrachten.
- wil je een basis (maar goede) test doen of je site toegankelijk is? Gebruik dan enkel de toetsenbord (tab toets, enter toets, spatiebalk) om te navigeren en linkjes/knoppen aan te klikken, terwijl je tegelijkertijd blijft zien waar je je bevindt op de website. Weersta de verleiding om toch naar de muis te grijpen;
- hieruit zal blijken dat de voorlees-button zoals geleverd door websitevoice.com niet bereikt kan worden met toetsenbord, omdat het technisch/semantisch gezien geen button is;
- het kan dus geen focus ontvangen en mensen met bijvoorbeeld parkinson of andere motorische aandoening die als gevolg geen muis meer kunnen bedienen, kunnen dus nooit deze knop bereiken;
- dezelfde vlieger gaat op voor slechtzienden of blinden, die veelal gebruik maken van alternatief hulpmiddelen en waarbij de semantiek een grote rol speelt.
In onderstaande afbeelding wordt aan de hand van de achterliggende code duidelijk dat de knop semantisch gezien geen knop is. Waar het idealiter een button zou moeten zijn, is de button functioneel gemaakt middels een div-element, aangevuld met JavaScript.
Is een toegankelijke voorleesfunctie bevorderlijk voor blinden en slechtzienden?
Kortom, ongeacht of een voorlees-functie de toegankelijkheid verbetert, dient de button op zichzelf dus ook toegankelijk te zijn. Wanneer websitevoice.com er wèl in geslaagd zou zijn het eindresultaat van hun widget toegankelijk te maken, kan afgevraagd worden of dit mensen met een visuele handicap ondersteunt.
Die kans is klein, aangezien deze gebruikers veelal reeds een alternatieve hulpmiddel zoals een screenreader hebben geïnstalleerd. Zo een screenreader leest juist ook tekst voor, maar komt met beduidend meer mogelijkheden, waar een gebruiker meer ondersteund wordt en bovendien vertrouwd mee raakt. Bijvoorbeeld:
- altijd dezelfde stem en accent, in plaats van per website mogelijkerwijs een andere stem;
- voorlees-snelheid;
- snelkoppelingen om verder te springen naar volgende paragrafen, secties of knoppen, waar de voorleesfunctie actief op anticipeert.
Voorleesfunctie uitschakelen voor screenreaders
Voor deze doelgroepen is het soms zelfs beter geen voorlees-functie te introduceren, omdat in het ergste geval twee stemmen tegelijk hoorbaar zou kunnen zijn.
In dat geval kan het de moeite waard zijn een voorlees-functie juist weer uit te schakelen voor mensen die gebruik maken van screenreaders. Doordat de toepassing van websitevoice.com in zijn geheel niet toegankelijk is, kan het bij voorbaat niet conflicteren met screenreaders.
Welke gebruikers hebben wel baat bij een voorleesfunctie?
Uiteraard kan een voorleesfunctie alsnog van toegevoegde waarde zijn. Denk aan:
- gebruikers die bijvoorbeeld onderweg zijn en een blog liever voorgelezen krijgen;
- mensen die de Nederlandse taal minder machtig zijn, zoals analfabeten of immigranten.
Dit laatste valt overigens onder inclusiviteit, in plaats van toegankelijkheid. Binnen de webrichtlijnen (WCAG) dien je weliswaar rekening te houden met je doelgroep, maar dat dient in de vorm van juiste taal-niveau te zijn. Een voorlees-functie betreft dus geen onderdeel van de webrichtlijnen.
Verbetert een voorleesfunctie je SEO?
Een voorleesfunctie kan gebruiksvriendelijkheid bevorderen. Ook Google focust via bijvoorbeeld pagespeed en juiste content op gebruiksvriendelijkheid; Een snelle site levert minder gebruikersfrustratie op en teksten moeten leesbaar zijn voor echte gebruikers, in plaats van zoekmachine bots.
Herkent Google je voorlees-functie?
De vraag is of een widget die gebruiksvriendelijkheid in de hand kan werken, directe invloed heeft op je ranking. Als Google's algoritme zo zou werken, zou de voorlees-button dus op zijn minst herkenbaar moeten zijn voor Google.
De button getoond via JavaScript. JavaScript en SEO kan een goed huwelijk zijn, mits de juiste liefde er in wordt gestoken. De button van websitevoice.com zijn niet semantisch, doordat het geen anker of button elementen betreft, waardoor deze liefde al vroegtijdig ophoudt te bestaan.
Zelfs in de zogenaamde second wave of indexing is er geen redden aan. De reden is simpel: Google gaat niet voor elk element binnen een website een muisklik afvuren. Dat zou in sommige gevallen ondoenlijk zijn. Juist hierom is semantiek binnen het web belangrijk. Het geeft een indicatie af aan browsers, maar ook zoekmachines waar een element en zijn content voor dient.
Vervolgens geldt bij gebruik van Javascript dat de juiste event-listeners gebruikt dienen te worden. Zoekmachines zullen beperkte acties afvuren op HTML elementen. Veelal beperkt zich dit tot de (on)click-event. Gebruik van juiste event listeners is dus belangrijk om content achter JS gestuurde buttons geïndexeerd te krijgen.
Hoe kan een voorleesfunctie invloed hebben op je ranking?
Stel dat een voorleesfunctie op zichzelf toegankelijk zou zijn, heeft het dan positieve invloed op je ranking? Als die invloed er is, zal het hooguit een indirecte invloed zijn. Hoe? Bijvoorbeeld doordat meer gebruikers content kunnen gaan consumeren en ze wellicht langer op je website blijven (maar misschien ook korter, wanneer de eigen leessnelheid langzamer is dan de voorlees-functie).
Third party widget en snelheid metrics
We zouden onszelf niet zijn als we laadtijd en dus website snelheid er niet bij zouden betrekken. Weinigen zullen een eigen voorleesfunctie gaan bouwen, dus ligt het voor de hand om een bestaande oplossing te integreren. We hebben het dan over third party widgets.
De FAQ van websitevoice.com suggereert dat het de website niet zal vertragen. De vervolgvraag die gesteld dient te worden, is naar welke metrics ze hebben gekeken. Doordat de widget via Wordpress onderaan de HTML code wordt geplaatst, heeft de widget geen invloed op de Time to First Byte of bijvoorbeeld First Meaningful Paint.
Snelheid is echter meer dan dit, weet juist ook Google. Via hun Lighthouse analyse-tool voor website snelheid wordt duidelijk dat er meer is dan alleen TTFB. Kijk dus juist ook naar de invloed van JavaScript.
De claim van websitevoice.com dat het de laadtijd niet vertraagt, is correct wanneer je naar de First Meaningful Paint kijkt. Kijk je naar de DOMContentLoaded (DCL), die weer van invloed is op gebruikerservaring, dan is er wel degelijk een invloed, zoals te zien in onderstaande afbeelding. Het document wordt geëvalueerd na de FMP metric, maar voor de DCL metric.
Met bovendien een aanvullend benodigde DNS lookup, TLS handshake en TTFB (deze lijkt altijd boven de 100ms te liggen, vrij hoog voor een statisch bestand) van het JavaScript-bestand zelf zijn er naast het evalueren van de JavaScript code, andere vertragende factoren in het spel.
Als gevolg vertraagt dit ook weer nakomende JavaScript, die zelfs direct gelieerd zijn aan de website. Bij een timeout van websitevoice.com, zal het first party JavaScript nog verder vertragen en functionaliteit in de weg kunnen staan.
Third party invloed verbeteren
Het wrange van een voorleesfunctie is aanvullend dat niet iedereen het zal benutten, maar de impact op snelheid wel op iedereen van toepassing is. De mate waarin, hangt uiteraard af van onder meer aanwezige internetsnelheid, gebruikte toestel. De invloed is er echter altijd.
De vertragende factor van een third party widget kan uiteraard getackeld worden, maar vergt programmeer-kennis:
- preload de benodigde bestanden kunnen preloaden resource hints (CSS, JS);
- maak de button na en plaats de CSS in je eigen stylesheet;
- pas minimale JavaScript toe, waarbij je de third party widget pas toevoegt (en afspeelt) als men werkelijk klikt.
Dat deze tactiek werkt, bewezen we eerder bij een chatbot die de mobiele pagespeed score van in de 90 degradeerde tot een 51%.
