6 oplossingen om je nieuwsbrief nóg toegankelijker te maken

Voor (semi-)overheidsorganisaties is het versturen van goed toegankelijke nieuwsbrieven sinds kort een verplichting. Ook voor andere organisaties is er genoeg reden om aandacht te gaan besteden aan het toegankelijker maken van nieuwsbrieven. Om je op weg te helpen besprak ik in mijn vorige artikel 4 aspecten waar je op moet letten. In dit artikel licht ik nóg 6 aspecten toe, waarmee je jouw nieuwsbrief prima toegankelijk maakt.

Vorige week kon je lezen over de vraag of, en hoe, je afbeeldingen toegankelijk kunt maken en over het belang van de structuur die hiërarchische titels aan je nieuwsbrief kunnen geven. In mijn eerdere artikel komt ook aan bod hoe je de nadelen van het gebruik van tabellen kunt vermijden, en hoe goed omschreven links kunnen bijdragen aan de toegankelijkheid. In dit tweede deel sluit ik af met de resterende aspecten.

1. Visuele ordening en semantiek

E-mailnieuwsbrieven worden over het algemeen opgebouwd uit een aantal vaste onderdelen: een header, een middenstuk met de artikelen en een footer. Elk van deze onderdelen heeft een eigen functie binnen het geheel. De uitschrijflink wordt bijvoorbeeld geplaatst in de footer en niet zomaar ergens in een artikel. Artikelen plaatsen we niet boven de header of onder de footer maar juist daartussenin. Het logo van de afzender plaatsen we in de header en niet in de footer, enzovoort.

Hoe beter een e-mail is ingedeeld volgens deze vaste conventies, hoe gemakkelijker en efficiënter de ontvanger er zijn weg in zal kunnen vinden. Dit geldt natuurlijk ook voor gebruikers van screenreaders. De zojuist bedoelde ordening wordt echter vooral met visuele middelen aangegeven. Zo kunnen footers bijvoorbeeld worden herkend door visuele hints, zoals de vaak relatief donkere achtergrondkleur en de relatief kleine tekstgrootte.

Screenreaders kunnen een footer echter niet herkennen op basis van deze visuele hints. Daarvoor is het nodig de functie van een stukje tekst in de e-mail semantisch mee te gegeven. Met andere woorden: in de code moet worden benoemd waar bijvoorbeeld de footer begint en eindigt en daarmee ook welke content dus tot de footer behoort.

Om content te voorzien van een semantische betekenis, zijn in HTML5 speciale tags beschikbaar gekomen zoals bijvoorbeeld <header>, <main> of <footer>. Omdat deze relatief nieuwe tags door sommige e-mailclients niet correct herkend worden, is het beter gebruik te maken van zogenaamde ‘role’-attributen. Met een role-attribuut kan aan elk willekeurig HTML-element een andere semantische betekenis worden gegeven, zonder dat dit de weergave van de e-mail verder beïnvloedt. Er zijn heel wat waarden beschikbaar voor het role-attribuut, maar in e-mail zijn er maar een paar relevant. Ik noem de belangrijkste drie:

Header

Met de header wordt het gebied bedoeld waarin het logo van de afzender en/of de titel van de nieuwsbrief zijn geplaatst. Dit gebied kan semantisch als header worden gemarkeerd door role=”banner” toe te voegen aan een omvattend HTML-element.

Inhoud

Het gebied waarin de eigenlijke content van de nieuwsbrief is geplaatst, kan worden gemarkeerd door role=”main” toe te voegen aan een omvattend element.

Footer

De footer kan tenslotte worden gemarkeerd door role=“contentinfo” toe te voegen aan een omvattend element.

Als bovenstaande role-attributen zijn toegevoegd, kunnen gebruikers van screenreaders aangeven dat ze direct naar de header, content of footer willen navigeren. Dit maakt het gebruik van je nieuwsbrief dus ook voor hen weer een stukje gemakkelijker en efficiënter.

2. Leesvolgorde

Als aanvulling op het bovenstaande punt, is het altijd verstandig óók rekening te houden met situaties waarin opmaak en indeling volledig wegvallen. Als screenreaders een e-mail integraal voorlezen, dan wordt alle HTML-code als het ware verwijderd zodat alleen de daadwerkelijke voor te lezen tekst overblijft. Dit betekent dat de tekst wordt voorgelezen in de volgorde waarin deze in het HTML-document wordt aangetroffen.

De manier waarop die code is geordend, bepaalt daarmee dus de volgorde waarin een screenreader de tekst voorleest. Die volgorde komt niet altijd overeen met de volgorde zoals die visueel wordt weergegeven, met name als gebruik wordt gemaakt van lay-outs met meerdere kolommen. Het gevolg kan zijn dat de tekst gehusseld lijkt te worden en daarmee onbruikbaar voor gebruikers van screenreaders. Het best is dit te illustreren met onderstaand voorbeeld:

Screenreaders zullen in het eerste voorbeeld eerst drie afbeeldingen met eventueel alternatieve teksten zien, daarna drie titels, drie teksten en drie “Lees verder”-links. Voor de lezer zal dit een onbegrijpelijke tekst opleveren. Door de structuur anders op te zetten, zoals in het tweede voorbeeld, kan dit probleem worden voorkomen.

Een ander aspect speelt op een wat hoger niveau. Bovenstaand voorbeeld laat zien in welke volgorde een screenreader onderdelen van een nieuwsbrief waarneemt. Merk op dat onderdeel 3, het laatst waargenomen onderdeel, de hoofdcontent van de nieuwsbrief bevat. Daardoor zal de belangrijkste content als laatst worden voorgelezen.

3. Gelinkte content (deel 2)

In deel 1 van dit artikel schreef ik over het belang van goed omschreven links. Bij het schrijven van links moet met nog meer rekening worden gehouden. Ik toon hier nogmaals de lijst met links zoals een screenreader die waarneemt in een e-mail. Links de originele e-mailnieuwsbrief, rechts de links van een voor toegankelijkheid geoptimaliseerde nieuwsbrief.

Als je naar de scrollbars kijkt, zal je opvallen dat de links getoonde lijst veel langer is dan de rechter. Met andere woorden: in de geoptimaliseerde versie bevat de lijst minder links dan in de originele versie.

Wees zuinig met het linken van content

In e-mailnieuwsbrieven is het de gewoonte om bij artikelen zowel de titel, de afbeelding als de “Lees meer”-knop te voorzien van een link naar dezelfde landingspagina. Al deze links zullen in principe door de screenreader worden gevonden en worden voorgelezen als de gebruiker vraagt om de lijst met links. Ook als alle links goed zijn omschreven, levert dit een lijst op waarin voor elk artikel drie dezelfde links worden gegeven. Het gevolg is dat de lijst dus in ieder geval drie keer zo veel links bevat als het aantal artikelen in de nieuwsbrief. Het voorlezen van deze lijst duurt dus ook drie keer zo lang.

Het is dus beter om per artikel slechts één link aan de screenreader ter beschikking te stellen. De overige links kunnen verborgen worden door role=”presentation” toe te voegen aan het linkelement. Hiermee blijft de lijst met links een stuk korter, en daardoor gemakkelijker te gebruiken.

4. Tekstgrootte, kleur en contrast

Natuurlijk moet er ook altijd aandacht zijn voor de leesbaarheid van teksten in visuele zin. Niet alleen voor mensen die slecht kunnen zien, maar ook handig voor mensen die snel moeten of willen lezen. Met name de teksten in footers worden vaak opzettelijk slecht leesbaar gemaakt. De gebruikte tekstgrootte is vaak een stuk kleiner dan die van de rest van de nieuwsbrief en ook het kleurcontrast van de tekst wordt vaak opzettelijk teruggebracht.

Dit zal ongetwijfeld worden gedaan vanuit de gedachte dat visueel duidelijk gemaakt moet worden dat deze informatie van minder belang is voor de lezer, dan de rest van de nieuwsbrief. Het onbedoelde gevolg is echter dat de inhoud slechter toegankelijk is dan nodig.

5. Taal

In de code van e-mailnieuwsbrieven wordt zelden opgegeven in welke taal de nieuwsbrief is geschreven. Als screenreaders de nieuwsbrief voorlezen, kunnen ze dus weinig anders doen dan deze voorlezen in hun eigen ‘default-taal’. Welke taal dat is, hangt af van wat de gebruiker heeft ingesteld. Als de nieuwsbrief in een andere taal is geschreven dan deze default-taal, dan zal dit de nieuwsbrief dus zo goed als onbruikbaar maken. Engelse woorden worden dan voorgelezen alsof het Nederlandse woorden zijn, of andersom. De tekst is daardoor heel moeilijk of helemaal niet te verstaan.

In welke taal een tekst moet worden voorgelezen, zou in ieder geval op documentniveau moeten worden bepaald. Dit doe je door aan het HTML-element het ”lang”-attribuut toe te voegen, bijvoorbeeld <html lang=”en”.  In principe zal alle tekst dan in de juiste taal worden voorgelezen. Als je in een Nederlandse tekst ook zo hier en daar bijvoorbeeld Engelse woorden gebruikt, dan is het nodig bij die woorden expliciet aan te geven in welke taal die woorden moeten worden voorgelezen. Ook dit kan worden gedaan met het lang-attribuut.

6 Encoding

Encoding is een relatief technisch onderwerp, maar toch van groot belang. Met een zogenaamde ”meta-tag” moet in een e-mail of HMTL-document worden aangegeven welke encoding moet worden gebruikt door de e-mailclient, om lettertekens te herkennen. Over het algemeen wordt UTF-8 gebruikt.

De aangegeven encoding bepaalt welke leestekens gebruikt kunnen worden en hoe deze herkend moeten worden door de e-mailclient of browser. Als bij het tonen van een webpagina of e-mail de verkeerde encoding wordt gebruikt, zullen er in de tekst vreemde leestekens te zien zijn.

Over het algemeen zullen normale leestekens (a-z, A-Z en 0-9) wel correct worden weergegeven, maar bij meer bijzondere leestekens kan het fout gaan. In sommige talen worden weinig speciale leestekens gebruikt en in andere juist heel veel. Hoe duidelijk een probleem met de encoding zichtbaar is, hangt dus ook erg af van de taal waarin de teksten zijn geschreven. Omdat de lettertekens van alle ‘levende’ talen worden ondersteund door UTF-8, is dit de beste keuze. Neem in de header van je document de volgende tag op: <meta charset=”utf-8″ />.

Stap voor stap op weg naar beter toegankelijke e-mail

Nu e-mailmarketing een volwassen vakgebied geworden is, wordt het ook hoog tijd om serieuzer bezig te zijn met de manier waarop e-mailnieuwsbrieven worden ontworpen en gebouwd. Het zal je misschien zijn opgevallen dat veel van de in dit artikel benoemde aspecten eigenlijk helemaal niet zo moeilijk zijn toe te passen. Ik hoop dan ook dat ik je met dit artikel heb kunnen inspireren om werk te gaan maken van het toegankelijker maken van je e-mailcommunicatie. Met de in dit artikel besproken oplossingen heb je daarvoor een meer dan goede basis.

Weet je niet waar je moet beginnen? Controleer je nieuwsbrief met behulp van een accessibility checker voor websites (accessible-email.org) of specifiek voor e-mail (achecker.ca) Je kunt ook zelf een screenreader installeren om daarmee je eigen nieuwsbrief te beluisteren. Elke verbetering die je vervolgens doorvoert, maakt je nieuwsbrief weer een stukje toegankelijker. Begin dus vooral met de eenvoudige aanpassingen om later de wat meer complexe zaken aan te pakken. Als je hier zo nu en dan een beetje tijd aan besteed, zul je zien dat je een heel eind kunt komen.

Afbeelding intro met dank aan 123RF.