22 APRIL 2025

E-mail accessibility: hoe maak je e-mails toegankelijk?

Niet iedereen leest een e-mail op dezelfde manier. Sommige mensen gebruiken een screenreader om de inhoud te laten voorlezen. Anderen navigeren met hun toetsenbord in plaats van met een muis, of hebben moeite met kleine letters en laag contrast. Maar ook zij ontvangen e-mails—en moeten de informatie kunnen begrijpen én ermee kunnen omgaan.

Daarom is het belangrijk dat je e-mails voor iedereen bruikbaar zijn. Oftewel: toegankelijk (accessible).

In dit artikel vertel ik hoe je jullie e-mailcommunicatie toegankelijk maakt. Want dat vraagt nét wat meer aandacht bij het maken van een e-mail—op het gebied van content, design én techniek.

Goed om te weten: voor dit artikel ga ik ervanuit dat je met een e-mailtemplate werkt (je hoeft dus niet in de HTML-code om een e-mail op te maken). Echter besteed ik wel aandacht aan wat er in de code moet staan, omdat dit een groot onderdeel is van het toegankelijk maken.

Een gedeelde verantwoordelijkheid

Het maken van toegankelijke e-mails is zoals ik in de introductie al aangaf een samenwerking tussen drie disciplines: content, design én techniek (development).

Waarom? Omdat toegankelijkheid alleen écht werkt als alle onderdelen van een e-mail op elkaar zijn afgestemd. De e-mailcode kan super goed geschreven zijn, maar als de content onduidelijk is of het kleurcontrast te laag, is de e-mail alsnog niet bruikbaar voor iedereen. Andersom geldt precies hetzelfde.

Mochten jullie je e-mails toegankelijk willen maken, is het dus belangrijk om al deze disciplines op één lijn te krijgen.

Wat maakt een e-mail toegankelijk?

1. Koppen met de juiste hiërarchie

Het gebruik van koppen – in de code herken je ze als <h1>, <h2>, etc., en in visuele editors vaak als “Heading 1”, “Heading 2” – helpt screenreaders begrijpen hoe de e-mail is opgebouwd.

Zie het als een inhoudsopgave:

• De <h1> is de hoofdtitel van je e-mail (vaak de kop bovenaan). Deze mag maar één keer voorkomen per e-mail.
• Daarna gebruik je <h2> voor de hoofdlijnen per sectie, en eventuele subkoppen <h3> t/m <h6>) voor verdere verdiepingen.

Belangrijk: sla geen niveaus over. Dus niet een <h2> opvolgen met een <h4>, want dat maakt het verwarrend voor gebruikers van screenreaders.

Het is ideaal als het e-mailtemplate zo gebouwd is dat je zelf het niveau van de koppen kunt kiezen. Zo kun je de hiërarchie goed bewaken zonder in de HTML te moeten duiken.

2. Een duidelijke structuur met landmarks

Net als koppen, hebben ook de zogenaamde “landmarks” (oriëntatiepunten) te maken met het creëren van een toegankelijke structuur voor screenreaders. Echter, waar koppen bedoeld zijn om aan te geven waar een stuk tekst over gaat, geeft een landmark aan wat de functie is van een bepaald onderdeel in de e-mail.

Zo heb je een landmark die aangeeft: dit is de header (role="banner"); een landmark die aangeeft: dit is de footer (role="contentinfo"); en een landmark die aangeeft: dit is de hoofdinhoud (role="main"). Deze en andere relevante landmarks dienen in de HTML-code om het betreffende onderdeel toegevoegd te worden.

Als een role meerdere keren voorkomt in de e-mail (stel je verstuurt een mail met verschillende nieuws-artikelen, krijgen al die artikelen role="article" mee), dan moet er een beschrijvende aria-label toegevoegd worden zodat het onderscheid duidelijk is. Het mooiste zou zijn als deze aria-label gelijk is aan de kop-tekst die zich binnen dat gebied bevindt. Het is een beetje afhankelijk van de ESP óf en hóe dat het beste ingebouwd kan worden in het template/de bijbehorende content blokken. Idealiter is het zo ingericht dat je bij het maken van je e-mail hier niet aan hoeft te denken.

Gebruik van role=”presentation” op tables

In e-mails wordt de layout bijna altijd opgebouwd met HTML-tables (<table>). Dat is technisch nog steeds de meest betrouwbare manier om de opmaak consistent te houden in alle e-mailclients. Alleen… screenreaders zien een <table> standaard als een datatabel met rijen en kolommen en lezen het dus ook dusdanig voor. Dat is in het geval van e-mails vaak helemaal niet de bedoeling. Daarom moet er op deze tabellen role="presentation" staan. Deze role is dus anders dan die ik eerder noemde. Het geeft aan: dit is puur bedoeld voor de presentatie (visuele opmaak); het voegt niets toe aan de toegankelijkheid.

Dit is iets wat in het e-mailtemplate zelf goed ingesteld moet staan. Zolang dit in de HTML goed staat, hoef jullie je hier zelf niet meer over na te denken.

Sidenote: role="list" moet worden gebruikt op tables die opgemaakt zijn als lijst (bijvoorbeeld met checkmarks, bullet-points of nummering). De screenreader geeft dan aan dat het een lijst gaat voorlezen en gaat deze dan per item af.

3. Afbeeldingen voorzien van omschrijvingen

Alt-tekst (kort voor “alternatieve tekst”) is een korte omschrijving van wat er op een afbeelding te zien is. In de code zie je dit terug in de afbeeldingstag als alt=”…”. Deze tekst verschijnt als de afbeelding niet goed laadt, én wordt voorgelezen door screenreaders.

Zo gebruik je alt-tekst:

• Is de afbeelding informatief? Geef dan een korte en duidelijke beschrijving. Bijvoorbeeld:
• Banner: alt="Banner met de tekst: Hoe maak je e-mails toegankelijk voor iedereen?"
• Grafiek: alt="Grafiek die laat zien dat 30% van de gebruikers dark mode gebruikt voor e-mail"
• Product: alt="Omslag van de whitepaper: 8 tips voor toegankelijke e-mailcommunicatie"
• Kaart: alt="Kaartje met route naar ons kantoor in Amersfoort"
• Logo (mits aanklikbaar): alt="Ga naar de homepage van [bedrijfsnaam]"
• Is de afbeelding puur decoratief? Gebruik dan een lege alt-tekst. In de code ziet dat er zo uit: alt="". Dit voorkomt dat de screenreader onnodige dingen opleest, zoals bestandsnamen of de URL van de afbeelding.

Sidenote: afbeeldingen met tekst (zoals banners) zijn minder toegankelijk, omdat screenreaders die tekst niet kunnen voorlezen. Staat er belangrijke informatie in een afbeelding? Zet die dan liever als gewone tekst in de e-mail zelf. Zo weet je zeker dat álle ontvangers de boodschap goed kunnen lezen – ook als de afbeelding niet laadt, of als iemand een screenreader gebruikt.

Tip: een tool zoals ChatGPT kan je goed helpen met passende alt-teksten schrijven.

4. Leesbare teksten met relatieve grootte

Teksten dienen leesbaar te zijn. Dat houdt in dat de tekst en regelafstand niet te klein mag zijn. Concreet betekent dit dat:

• De standaard tekstgrootte (font-size) minimaal 14px moet zijn. Voor echt de hoofdinhoud zou ik overigens een tekstgrootte van (minimaal) 16px aanhouden, omdat het anders op bepaalde beeldschermen al snel te klein is. Voor de footer (disclaimer), preheader of bijschriften, kun je dan eventueel 14px aanhouden.
• De regelafstand (line-height) voor koppen minimaal 1.2 moet zijn. Voor de rest geldt een minimum van 1.5. De 1.2 en 1.5 staan in verhouding tot de tekstgrootte. Dus als je een paragraaf hebt met een tekstgrootte van 16px, dan dient de regelafstand minstens 16 x 1.5 = 24px te zijn.

Het beste is het wanneer de tekstgroottes en regelafstanden in de code zijn ingesteld. Op die manier hoef je hier zelf niets mee hoeven te doen. Het instellen van de tekstgrootte en regelafstand op deze manier heeft nog een voordeel: het maakt het mogelijk om in plaats van pixels (px) de relatieve eenheid ‘em’ te gebruiken.

Wat doet een relatieve eenheid? Die maakt het in dit geval mogelijk dat de tekstgrootte afhankelijk is van de instellingen van de ontvanger van de e-mail. De ontvanger kan de standaard lettergrootte aangepast hebben van zijn computer of mobiel. Een relatieve eenheid gebruikt deze aangepaste tekstgrootte, zonder dat de rest van de opmaak (bijvoorbeeld de ingestelde breedte van de e-mail en van afbeeldingen) zich aanpast. Dit is dus anders dan inzoomen – waarbij álles groter wordt, en dus niet alleen de tekst. Als je pixels blijft gebruiken, staat de grootte van de tekst vast.

Sidenote: e-mail development zou geen ding zijn als de verschillende e-mailclients het ons niet zo moeilijk zouden maken 😉… Want: niet alle e-mailclients ondersteunen de relatieve eenheid ‘em’. Gelukkig is het mogelijk om in die gevallen gebruik te blijven maken van pixels. Dit artikel van Good Email Code vertelt er meer over.

5. Duidelijke link- en buttonteksten

Voor visuele lezers is een button met “Klik hier” of een linkje met “Lees meer” vaak prima te begrijpen. Je ziet de context, je snapt waar het over gaat. Maar screenreaders werken anders. Die geven gebruikers een lijst van álle buttons en links in de e-mail, zonder de omliggende tekst. Als alle buttons dan “Lees meer” heten, wordt het totaal onduidelijk waar iemand op klikt.

Daarom: maak link- en buttonteksten altijd beschrijvend. Zeg wát iemand gaat bekijken, lezen of doen. Een paar voorbeelden:

• Bekijk al onze diensten
• Download de whitepaper
• Plan een gratis adviesgesprek

Handige check: lees de linktekst hardop voor, zónder de rest van de zin. Begrijp je meteen wat er gebeurt als je erop klikt? Dan zit je goed.

Betreft title-attributen

In veel editors kun je bij het toevoegen van een link ook een title-veld invullen. Niet doen. Deze title-tekst is wordt op mobiele devices niet getoond en screenreaders lezen het title-attribuut vaak níet voor, of doen dat dubbelop met de gewone linktekst. Dat zorgt voor verwarring. Alles wat belangrijk is om te zeggen, moet je gewoon in de zichtbare linktekst kwijt.

6. Teksten en achtergronden met voldoende kleurcontrast

Teksten dienen voldoende te contrasteren met de achtergrondkleur. Dit is niet alleen belangrijk voor mensen met beperkter zicht, maar ook voor mensen met kleurenblindheid.

Houdt het volgende aan:

• Voor koppen (zoals <h1>; en <h2>, teksten groter dan 24px óf dikgedrukte teksten groter dan 18px) moet de contrastverhouding minimaal 4.5:1 zijn.
• Voor gewone paragraafteksten geldt een nog striktere regel: minimaal 7:1.

Test je kleurencombinaties met een contrastchecker, zoals deze van WebAIM, om zeker te weten dat deze voldoen aan de WCAG Level AAA-normen. Als je erachter komt dat dit met een bepaalde kleurencombinatie niet het geval is, ga dan met het designteam in gesprek.

7. De juiste taal

Een screenreader leest e-mails hardop voor. Maar hoe weet zo’n tool in welke taal dat moet gebeuren? Ook dat is iets wat in de code meegegeven moet worden.

De taal moet onder andere ingesteld worden op de <html>-tag. Voor Nederlandse e-mails is dat lang="nl". Voor maximale compatibiliteit moet ook xml:lang="nl" op de <html>-tag staan. Zo voorkom je dat een Nederlandse e-mail ineens in het Engels (of anderstalig) wordt voorgelezen. Helaas verwijderen sommige ESP en e-mailclients de (toevoegingen op de) <html>-tag, ook hier is een technische oplossing voor.

Bovenstaande dient ingesteld te worden in de code, zodat je daar bij het bouwen van de e-mail niets meer mee hoeft te doen. Echter, gebruik je in de e-mail zelf een stukje tekst in een andere taal? Dan is het eigenlijk het beste om dat tussen een <span> met de juiste taalcode te zetten, bijvoorbeeld: <span lang="en">different langage</span>. Stuurt een link door naar een pagina in een andere taal? Dan is het netjes om ook het attribuut hreflang toe te voegen op de <a>-tag (bijvoorbeeld: <a href="https://denisenijland.com/en" hreflang="en">Visit our English site</a>). Dit is next level en binnen veel ESP geen (standaard) optie.

8. Denk ook aan dark mode

In een eerder blogartikel schreef ik al over dark mode optimalisatie binnen e-mailclients. Dit artikel is nog steeds relevant – en zeker ook belangrijk voor de toegankelijkheid van e-mails. Sommige e-mailclients (zoals Gmail) veranderen namelijk automatisch de kleuren in de e-mail indien de ontvanger gekozen heeft voor de dark mode-weergave.

Een voorbeeld:
Je hebt een witte achtergrond, een zwarte button en witte tekst. Ziet er prima uit in light mode. Maar in dark mode wordt de witte achtergrond ineens donkergrijs – terwijl de zwarte button vaak zwart blijft. Gevolg? De button valt helemaal weg in de dark mode-weergave.

Om te voorkomen dat belangrijke elementen zoals teksten, buttons, logo’s of social media icons niet duidelijk zichtbaar zijn op dark mode, moet ook dit dus goed getest en – waar nodig – geoptimaliseerd worden.

Is dat alles?

Nee, ik ben bang van niet: afhankelijk van het design moet er soms nog wat extra’s toegevoegd worden aan bepaalde elementen in de code. Het is aan een e-maildeveloper de code goed op te bouwen, te testen én de e-mailmarketeer (of wie er met het template werkt) goed wegwijs te maken in het gebruik van het e-mailtemplate.

E-mails testen op toegankelijkheid

Binnen de testtool van Email On Acid is het mogelijk om een check te doen op toegankelijkheid. Ook accessible-email.org is een handige (en gratis) tool. Echter zijn deze tools niet perfect. Zelf test ik daarom ook wel met een screenreader. Probeer dat zelf ook eens, zodat je kan ervaren hoe dat is. Of gebruik eens toetsenbord-navigatie (bijvoorbeeld de pijltjes en de Tab-toets) om door een e-mail te navigeren.

Hulp nodig bij het toegankelijk maken van jullie e-mailcommunicatie?

Misschien zijn jullie e-mails nog niet (volledig) toegankelijk en is dit wel iets wat jullie willen óf zelfs moeten om vanwege de European Accessibility Act (EAA). Kunnen jullie hulp gebruiken bij het toegankelijk maken van jullie e-mails/templates? Als freelance E-mail Developer help ik hier graag bij! Op dit moment heb ik nog plek beschikbaar voor een (interim)opdracht. Stuur me gerust een bericht via LinkedIn of mail naar info@denisenijland.com.