
Zet eens de schermlezer van uw telefoon aan op een Nederlandse website waarvan de taal verkeerd is ingesteld. U hoort dan een Engelse stem die Nederlandse woorden probeert uit te spreken. “Gratis verzending” wordt iets als “grey-tis ver-zending”. Na twee zinnen is het niet meer te volgen. Het ligt aan één regel in de code: het lang-attribuut. Een klein detail dat voor bezoekers met een schermlezer het verschil maakt tussen een verstaanbare en een onbegrijpelijke site.
Wat het lang-attribuut doet
Bovenaan elke webpagina staat het <html>-element. Daarop hoort een attribuut dat de taal van de pagina aangeeft:
<html lang="nl">
Met die informatie doen verschillende programma’s iets:
- Schermlezers kiezen de juiste stem en uitspraakregels.
- Browsers gebruiken het voor woordafbreking, aanhalingstekens en de spellingscontrole in formuliervelden.
- Vertaaltools weten van welke taal ze vertalen.
- Brailleleesregels kunnen er de juiste tekentabel mee kiezen.
Wat WCAG vraagt
Twee succescriteria gaan hierover:
- 3.1.1 Taal van de pagina (niveau A): de standaardtaal van elke pagina moet in de code zijn aangegeven.
- 3.1.2 Taal van onderdelen (niveau AA): stukken tekst in een andere taal moeten ook als zodanig zijn gemarkeerd, met een paar uitzonderingen zoals eigennamen en woorden die in het Nederlands zijn opgenomen.
Het eerste criterium is in een paar minuten te controleren en op te lossen. Het tweede vraagt aandacht van redacteuren.
Zo controleert u de taal van uw pagina
- Open uw website en klik met de rechtermuisknop ergens op een lege plek.
- Kies “Paginabron weergeven”.
- Kijk naar een van de eerste regels: staat er
<html lang="nl-NL">of<html lang="nl">?
Beide zijn goed. Ziet u lang="en-US", of helemaal geen lang, dan is het mis.
In WordPress komt de waarde uit de instelling Instellingen, Algemeen, Taal van de site. Staat die op Engels, bijvoorbeeld omdat de site ooit zo is geïnstalleerd, dan krijgt elke pagina lang="en-US". Zet hem op Nederlands. Let op: dit verandert ook de taal van het beheerpaneel, tenzij u per gebruiker in het profiel een andere taal kiest.
Gebruikt uw thema of pagebuilder een eigen header-template, controleer dan of die de WordPress-functie language_attributes() gebruikt. Sommige oudere of zelfgebouwde thema’s hebben de taal vast in de code staan.
Stukken in een andere taal markeren
Een Nederlandse pagina bevat vaak Engelse stukken. Een citaat, de titel van een boek, een slogan, een productnaam die een hele zin is. Een schermlezer leest die met de Nederlandse stem voor, wat bij korte woorden geen probleem is, maar bij een volledige zin wel.
U markeert zo’n stuk met een lang-attribuut op het element eromheen:
<p>Ons motto is <span lang="en">"less is more"</span>, ook in ons ontwerp.</p>
<blockquote lang="fr">
<p>La simplicité est la sophistication suprême.</p>
</blockquote>
Wat hoeft niet: losse leenwoorden die in het Nederlands gangbaar zijn, zoals “website”, “e-mail” of “online”, en eigennamen. Die leest de Nederlandse stem prima voor.
In de WordPress-blokeditor is dit niet met één knop te doen. U kunt het blok bewerken als HTML en het attribuut toevoegen, of bij een heel blok via de geavanceerde instellingen werken als uw thema of een plugin daar een taalveld voor biedt. Voor redacteuren is het praktisch om af te spreken: hele alinea’s of citaten in een andere taal krijgen een markering, losse woorden niet.
Meertalige sites
Bij een site in meerdere talen moet elke taalversie het eigen lang-attribuut hebben. De Franse pagina krijgt lang="fr", de Duitse lang="de". Gangbare meertaligheidsplugins voor WordPress regelen dat voor de pagina zelf meestal goed. Waar het vaker misgaat:
- De taalkeuzelijst. In een menu met “Nederlands, Français, Deutsch” staat elke taalnaam idealiter in zijn eigen taal gemarkeerd, zodat een Franstalige bezoeker “Français” goed hoort uitspreken.
- Vaste teksten uit thema en plugins. Knoppen, foutmeldingen en labels die niet zijn vertaald, blijven Engels of Nederlands op een anderstalige pagina.
- De cookiemelding en externe widgets. Die hebben vaak hun eigen taalinstelling, los van de site.
- Automatisch vertaalde pagina’s waarvan de taal in de code niet is aangepast.
Voor Belgische sites met Nederlandse en Franse versies is dit een bekend aandachtspunt; zie ook de toegankelijkheidswet in België.
Ook documenten en e-mails hebben een taal
Het principe geldt niet alleen voor webpagina’s. Een pdf die u op de site zet, heeft ook een taalinstelling in de documenteigenschappen. Staat die verkeerd, dan leest een schermlezer ook de pdf met de verkeerde stem voor. In Word stelt u de taal in via de taalinstellingen van de tekst, en die neemt een goede export naar pdf mee.
Hetzelfde geldt voor nieuwsbrieven en automatische e-mails, zoals de orderbevestiging van uw webshop. Ook daar hoort een lang-attribuut in de HTML van de e-mail. Veel e-mailtemplates laten het weg. Het is een kleine aanpassing in het template die u één keer doet.
Zelf testen met een schermlezer
Ziende bezoekers merken een verkeerd lang-attribuut niet. De pagina ziet er precies hetzelfde uit. Pas wie de pagina laat voorlezen, hoort het verschil. Daarom duikt het in audits regelmatig op, ook bij sites die verder goed zijn gebouwd. Het goede nieuws is dat het voor de pagina als geheel een van de snelste verbeteringen is die er bestaan.
Op een Mac of iPhone zet u VoiceOver aan via de instellingen voor toegankelijkheid. Op Windows is NVDA gratis te downloaden. Laat een stuk van uw homepage voorlezen en luister: klinkt het als Nederlands? Ga daarna naar een pagina met een anderstalig citaat en luister of de stem wisselt. Meer over testen met een schermlezer vindt u op de pagina uw website testen met een screenreader. Het hele overzicht staat bij website toegankelijk maken.
Vraag een gratis websitecheck aan. Binnen één werkdag weet u waar uw website staat.
