Op één puntje na voldoet rechtspraak.nl – de website van de rechterlijke macht – volledig aan de Webrichtlijnen. En mag zich met trots een goed toegankelijke site noemen. Wat deze prestatie bijzonder maakt, is dat de website gebouwd is op basis van SharePoint 2007, een populair platform voor intranetportals en samenwerking, maar als CMS niet bepaald bekend om valide HTML en toegankelijkheid.

SharePoint en toegankelijkheid

Microsoft SharePoint is een zeer veelzijdig, krachtig en flexibel platform voor intranetportals, documentbeheer en samenwerking. Daarnaast kan het ook gebruikt worden als content managementsysteem (CMS) voor websites. In SharePoint heet dit Web Content Management (WCM).

Bij de ontwikkeling van SharePoint 2010 is veel rekening gehouden met webstandaarden en toegankelijkheid. Zo voldoet SharePoint 2010 ‘out-of-the-box’ aan de W3C-richtlijnen WCAG 2.0 op niveau AA en aan well-formed XHTML 1.0. Voor een optimale gebruikersbeleving (bv. in het Lint, dialogen en rich text editor) maakt SharePoint gebruik van WAI-ARIA, de W3C-standaard voor toegankelijke ‘rijke’ interactie.

Met voorloper Microsoft Office SharePoint Server (MOSS) 2007 is het een stuk uitdagender om websites toegankelijk en conform webstandaarden te bouwen. De lay-out – waarin webparts (widgets) een belangrijke rol spelen – wordt bijvoorbeeld voor een groot deel nog opgebouwd met opmaaktabellen, wat al jaren geen aanbevolen techniek meer is en daarmee niet-valide en ontoegankelijke HTML oplevert.

Gelukkig pakten enkele partijen al snel de handschoen op om SharePoint 2007 toegankelijker te maken. HiSoftware ontwikkelde de Accessibility Kit for SharePoint 2007 (AKS), dat een basisoplossing voor toegankelijkheid bood. Daarnaast deelden SharePoint-ontwikkelaars als Waldek Mastykarz praktische tips voor het ontwikkelen van toegankelijke sites met SharePoint 2007.

Rechtspraak.nl en de Webrichtlijnen

Binnen de Rechtspraak was SharePoint 2007 al gekozen als platform voor het nieuwe intranetportal. Vanwege de IT-architectuur en beheerwensen besloot men SharePoint 2007 ook in te zetten voor de nieuwe website. Dat was een ambitieuze keuze, aangezien de Rechtspraak zich tegelijk committeerde aan de Webrichtlijnen.

Het ontwikkelteam heeft een paar grote uitdagingen getackeld om de nieuwe website Webrichtlijnen-proof te maken:

• Alle masterpages, page lay-outs en controls zijn naar valide XHTML omgebouwd. Hiervoor zijn de ASP.NET 2.0 CSS Friendly controls gebruikt. Daarnaast moest de HTML van diverse SharePoint controls overschreven worden met behulp van maatwerktechnieken.
• Van de controls die niet omgebouwd konden worden, werd een zgn. ‘page adapter’ geschreven waarmee er in de HTML-code die SharePoint produceert nog net even wat ‘zoek en vervang’-acties worden gedaan voordat de HTML getoond wordt.
• De rich text editor is aangepast zodat webredacteuren kunnen werken met betekenisvolle stijlen en dat alle output valide HTML betreft. Uiteraard hebben alle webredacteuren ook een training gekregen om content toegankelijk op te maken.
• De Overheids Media Player werd geïmplementeerd om video toegankelijk af te kunnen spelen.

Dankzij deze aanpassingen behaalde rechtspraak.nl deze week het waarmerk voor toegankelijkheid op het niveau prioriteit 2. De site is bovendien slechts één punt verwijderd van het ‘3-sterren’ Webrichtlijnen-waarmerk: de inspectie struikelde over de volgorde content – navigatie in de HTML-code (deze richtlijn vervalt overigens in Webrichtlijnen versie 2).

Al met al een knappe prestatie. Voor zover ik weet, is dit de allereerste SharePoint-gebaseerde website die dit niveau van toegankelijkheid en bouwkwaliteit heeft bereikt. De Rechtspraak heeft laten zien dat je ook met SharePoint (MOSS) 2007 een goed toegankelijke site kunt realiseren.

Laten we de twee werelden eens met elkaar vergelijken aan de hand van een aantal (in mijn ogen) zwakke plekken van de huidige toetsingspraktijk betreffende toegankelijkheid.

Niet de doelgroep, maar de richtlijnen zijn leidend

Toegankelijkheid: Toegankelijkheid wordt beoordeeld op de uiterst zorgvuldig door het W3C opgestelde Web Content Accessibility Guidelines (WCAG). Een lijvig pakket aan documenten waar zo’n 10 jaar aan gewerkt is en waarvoor je van goede huize moet komen om het te doorgronden. Het voordeel van dit alles: de richtlijnen zijn behoorlijk volledig, universeel en objectief.

Usability: Jakob Nielsen is beroemd vanwege zijn usability-richtlijnen. Hij heeft er veel geschreven. Toch zijn de meeste usability professionals met elkaar eens: er is maar één richtlijn: “It depends”. Veel usability best practices zijn context- en doelgroepafhankelijk. Maak je iets dat afwijkt van een best practice, maar blijkt uit usability-onderzoek dat de doelgroep er goed mee overweg kan? Geen probleem.

Conclusie: Toegankelijkheid kan dankzij WCAG exacter en objectiever getest worden dan usability. Maar universele richtlijnen zijn niet altijd van toepassing op een specifieke doelgroep. En extra service en gebruiksgemak kan soms tegen je werken vanwege WCAG. Twee voorbeelden:

• Een paar maanden geleden slaagde de website van Loket aangepast-lezen (bibliotheek voor mensen met een visuele en/of leesbeperking) voor de Webrichtlijnen en WCAG prioriteit 3 (het hoogste niveau). Maar het ledengedeelte haalde nog niet eens het instap-waarmerk Drempelvrij. De reden: de bibliotheek mocht voorgelezen boeken alleen streaming aanbieden en daarvoor is JavaScript nodig. Uit eigen onderzoek bleek dat geen van de leden ooit problemen had gehad met de player, maar het was nu eenmaal een richtlijn.
• Een website bood een agenda voor bijeenkomsten in het land. Een keurige lijst met data en locaties, dat voldeed aan alle toegankelijkheidsrichtlijnen. Het team besloot de pagina visueel wat aantrekkelijker te maken door naast de agenda de locaties ook in een (embedded) Google Maps kaartje te tonen. Door enkel deze toevoeging haalde de site niet de Webrichtlijnen en ook niet WCAG prioriteit 2. Waarom? Google Maps was ‘out-of-the-box’ niet met het toetsenbord te bedienen. Dat de agenda ernaast met exact dezelfde content dat wel was, deed er niet toe.

Gevolg? Opdrachtgevers en webteams besluiten dan maar de extra functionaliteit helemaal te schrappen of om niet meer voor het waarmerk te gaan, onder het mom “We hebben ons best gedaan”.

Je bent niet aan het optimaliseren, je doet examen.

Toegankelijkheid:  Bij toegankelijkheid laat je geen test of onderzoek uitvoeren, maar een officiële inspectie. En als we kijken op het niveau van Webrichtlijnen of zelfs WCAG niveau AA, haalt bijna geen enkele site bij de eerste inspectie nul of één fout. Je ontvangt een inspectierapport met daarin de complete lijst richtlijnen, met per richtlijn een ja/nee/n.v.t., bij alle nee’s een toelichting, een totaalscore en een eindoordeel (norm wel/niet gehaald). Je krijgt 20 werkdagen de tijd om de fouten te herstellen. Je krijgt geen tips, want inspectie-instellingen mogen vanwege accreditatie geen advies meegeven.

Usability: Een (goed) usability-rapport belicht zowel positieve observaties als aandachtspunten en de onderzoekers geven aanbevelingen mee om de belangrijkste obstakels aan te pakken. Het geeft geen checklist, geen score en dus ook geen voldoende of onvoldoende. Slechts observaties en aanbevelingen.

Conclusie: Mike van Dijk (Green Valley) signaleerde: “Het beeld is ontstaan dat inspectie-instellingen er vooral zijn om je af te keuren, niet om je te motiveren aan de slag te gaan en blijven met het onderwerp toegankelijkheid.” De oorzaak hiervan ligt primair niet bij deze organisaties, maar bij de gekozen aanpak. Ten eerste wordt WCAG niet gebruikt als kapstok, maar als norm. Om die norm te halen, moet je aan alle bijbehorende richtlijnen voldoen. En omdat inspectie-instellingen geen advies mogen geven, krijg je dus alleen een schoolrapport waarin alle gevonden fouten worden vermeld.

Conclusies in usability-rapporten zijn veel relativerender en daardoor meer stimulerend, bijvoorbeeld “De nieuwe informatiestructuur sluit aan bij de beleveniswereld van de doelgroep. Uitgaande van [scenario x] kost het de gebruiker wel enige moeite om op de homepage een passende ingang te vinden. Eenmaal voorbij de homepage wordt de gebruiker goed begeleid…”. Vertaal je dit naar toegankelijkheid, dan zou de conclusie kunnen luiden: “De website is goed toegankelijk voor mensen met een functiebeperking. Wel hebben visueel gehandicapten moeite om de informatie in tabellen te lezen en zullen veel slechtzienden moeite hebben met het kleurcontrast op diverse pagina’s.”

Eén richtlijn niet volgen kan resulteren in het predicaat ‘ontoegankelijk’

Toegankelijkheid: Er zijn drie conformiteitsniveaus: A (minimaal), AA (goed) en AAA (optimaal). Bij ieder niveau hoort een aantal richtlijnen (officieel: succescriteria) die je allemaal moet opvolgen voor positief oordeel bij de inspectie. Er is één richtlijn dat bijna altijd op weerstand stuit: maak video en audio toegankelijk. Veel site-eigenaren vinden de meerwaarde hiervan niet opwegen tegen de meerkosten. Het probleem is: een richtlijn als deze hoort bij niveau A (het minimale niveau). Dus ook al volg je alle richtlijnen (ook AA en AAA) op, als je één A-richtlijn niet volgt, is je site volgens de inspectie ontoegankelijk.

Usability: Als een usability-onderzoek maar één knelpunt oplevert, ook al is het een kritieke, dan is iedereen blij. Eén issue betekent dat er heel veel goed gaat en dat je heel gericht aan de slag kunt met één aanbeveling om dat belangrijke knelpunt ook op te lossen.

Conclusie: Mensen willen graag waardering voor de inspanning en prestatie die ze geleverd hebben, horen dat ze goed bezig zijn (maar dat er nog een aantal aandachtspunten is). Alleen maar wijzen op de fouten motiveert niet en een goede prestatie met maar één – weliswaar belangrijke – fout als onvoldoende bestempelen motiveert al helemaal niet. Gevolg: met het Webrichtlijnen waarmerk binnen handbereik, haken opdrachtgever en webteam af.

Caesura en sampling? Key scenario’s?

Toegankelijkheid: Inspecties worden uitgevoerd op basis van een representatieve steekproef. Om te bepalen welke pagina’s in de sample moeten komen, is een heel document opgesteld: het Evaluatie (ook wel Caesura) en sampling document. Minimaal moet (voor zover aanwezig) een aantal componenten zoals video’s en tabellen in de sample zitten, en de key scenario’s (alle belangrijke interactiepaden in een website). Ook wordt beschreven hoe de inspecteur de conformiteitsmarge bepaalt, oftewel hoe vaak mag een fout voorkomen voordat het als structurele fout wordt gezien. De inspecteur bepaalt de sample.

Usability: De onderzoeker stelt in overleg met de opdrachtgever een aantal scenario’s op waarop de site wordt getest door gebruikers. Dit is slechts een leidraad, want het komt vaak genoeg voor dat afhankelijk van de testpersoon een net iets ander scenario wordt voorgelegd, omdat die bijvoorbeeld beter aansluit op die persoon en dus ook dichter het werkelijke gebruik benadert. Ook worden vaak niet alle voorbereide scenario’s aan alle testpersonen voorgelegd. Als de opdrachtgever of onderzoeker tijdens een testsessie nog benieuwd zijn naar iets anders, wordt dit ook aan de testpersoon voorgelegd.

Conclusie: Veel mensen weten niet dat er naast de toegankelijkheidsrichtlijnen ook nog iets bestaat als caesura en sampling of snappen niet de functie ervan. Anders dan bij usability heeft de opdrachtgever bij een inspectie weinig invloed op wat er onderzocht wordt. Dat leidt soms tot flinke discussie, omdat de opdrachtgever bijvoorbeeld een gedeelte wil laten toetsen, maar de inspecteur dit weigert vanwege de key scenario’s.

Alleen specialisten en techneuten snappen waarom een site wordt afgekeurd.

Toegankelijkheid: Zowel de W3C-richtlijnen, Webrichtlijnen als de inspectierapporten zijn behoorlijk exact en technisch opgesteld. Heb je nooit gewerkt met HTML en weet je niets van webservers, dan zijn de strekking en implicatie van de richtlijnen moeilijk te begrijpen. Daarbij helpt ook de opbouw van de documenten niet erg. Droog is misschien wel een passend trefwoord.

Usability: Usability-rapporten worden meestal op managementniveau opgesteld, in ieder geval de conclusies. De problemen worden in principe ook vanuit de gebruiker beschreven, bv. “Gebruikers hebben moeite met het gebruiken van de rekentool” of “Sommige gebruikers snappen niet dat ze het ‘Home’-icoon moeten gebruiken om naar de homepage terug te keren”. Aanbevelingen worden wat meer toegespitst op de ontwerpers, maar zijn vaak te begrijpen door managers.

Conclusie: Als ik voor iedere keer dat ik door opdrachtgevers, projectleiders en zelfs developers wordt gevraagd een inspectierapport uit te leggen, een euro zou krijgen, dan zou ik nu op vakantie kunnen gaan. Voor wie niet thuis is in toegankelijkheid, komt het geheel over als een hoop technische regeltjes waar de site blijkbaar aan moet voldoen.

Volgens mij is het helemaal niet zo moeilijk om de belangrijkste conclusies van uit een gebruikersperspectief te communiceren, zodat alle doelgroepen van het inspectierapport beter snappen en voelen wat er beter kan. Bijvoorbeeld: “Mensen die blind of slechtziend zijn, begrijpen video X niet omdat in de video belangrijke informatie wel zichtbaar, maar niet hoorbaar is” in plaats van “Er wordt een audiodescriptie geleverd voor alle vooraf opgenomen videocontent in gesynchroniseerde media.”.

Liever alle sites 50% toegankelijk, dan 50 sites 100%

Alles aan toegankelijkheid, de inspectieprocedure en het ‘certificaat’ ademt ingewikkeldheid, formaliteit en regels: accreditatie, voorbehouden, caesura, gebruiksrechten waarmerk, enzovoorts. Het is moeten, moeten, moeten. De hakken gaan al snel in het zand.

Je site toegankelijk maken zou veel meer moeten lijken op het verbeteren van usability. Je kunt het laten testen, krijgt een helder rapport met screenshots, soms een paar videofragmenten en ook vooral advies waar je mee aan de slag kunt.

Ook usability testing is soms lastig te verkopen aan een opdrachtgever. Het kost aardig wat geld, en wat krijgt hij er nou voor terug? Maar als een opdrachtgever één keer live bij een usability test is geweest of videofragmenten heeft gezien waarin hij zijn klanten ziet worstelen met zijn website, dan is hij verkocht. Hij ziet de kansen: hogere conversie, minder klantenservice-vragen en blijere klanten.

Op dezelfde manier zou de impact en ROI van toegankelijkheid vanzelf zichtbaar moeten worden. De opdrachtgever snapt welke doelgroepen hij nu niet bereikt, waar mensen mee worstelen, welk effect het heeft qua vindbaarheid in Google, enzovoorts. Hij wil er iets mee doen, omdat het zijn online succes vergroot. Maar wel het liefst stap voor stap, want in één keer 100% is een hele kluif!

Loket aangepast-lezen

Het Loket aangepast-lezen is een bijzondere bibliotheek. Het biedt boeken, kranten en tijdschriften in een aangepaste leesvorm (braille, gesproken of grote letters) voor als het ‘gewone’ lezen niet meer gaat.

De website van het Loket heeft zich de afgelopen jaren ontwikkeld tot een interactief platform waarop diverse onderdelen van de dienstverlening, zoals de online catalogus met bestelfunctie, worden aangeboden. De opzet en techniek van de oude site liepen echter tegen hun grenzen aan. Daarom staat er nu een heel nieuwe site. De klanten kunnen nu direct inloggen en direct gebruik maken van de online dienstverlening: zoeken, bestellen en/of streamen van boeken in de online catalogus en het ophalen van de elektronische kranten en tijdschriften. Via de ‘Mijn Loket’-pagina hebben klanten direct toegang tot hun specifieke diensten, waarbij zij zelf hun eigen gegevens kunnen nazien en voorkeuren beheren.

Aanpak

De nieuwe site moest gezien de doelgroep natuurlijk super toegankelijk zijn. Daarom hebben we er bewust voor gekozen niet alleen conform de Webrichtlijnen te ontwerpen en bouwen, maar te gaan voor het hoogst haalbare toegankelijkheidsniveau: prioriteit 3 van de W3C-richtlijnen. Een aantal van die prio3-richtlijnen staan al in de Webrichtlijnen, maar we hebben bijvoorbeeld gezorgd voor standaard extra hoog kleurcontrast en de mogelijkheid om zelf een hoog contrast weergave naar keuze in te stellen.

Daarnaast wilden we dat de site niet alleen heel toegankelijk zou zijn, maar ook gebruikersvriendelijk. Daarom hebben we eerst november vorig jaar aan de hand van de eerste html-prototypes en later nog eens een usability test met blinden en slechtzienden uit het klantenpanel met uiteenlopende leeshandicaps gehouden. Dat leverde een veel waardevolle inzichten op, op basis waarvan we de site weer hebben verbeterd.

Ten slotte heeft het Loket ook enkele webprofessionals uit de doelgroep, Peter op ‘t Hof en Bram Duvigneau betrokken bij de ontwikkeling van de site, die ook een grote bijdrage hebben geleverd aan de kwaliteit van de site.

Resultaat

De website is helemaal opgeleverd conform de Webrichtlijnen. Een co-productie van Tam Tam (advies en ontwerp), Axendo (publieke site) en Dedicon (besloten klantdeel). Het publieke deel van de site heeft het Webrichtlijnen waarmerk ontvangen en is gelukkig zelfs ook goedgekeurd op prioriteit 3 van de W3C-richtlijnen.

Het besloten klantendeel heeft het waarmerk helaas net niet gehaald. Wegens auteursrechtelijke afspraken mag het Loket de Daisy-materialen online alleen nog maar streaming aanbieden en niet als downloadbare MP3′s. Daarom komt de Daisy-player niet door de formele toegankelijkheidsinspectie.

Maar het belangrijkste is: Het Loket heeft inmiddels al veel enthousiaste reacties ontvangen van klanten. De site is een stuk gebruikersvriendelijker geworden en sluit goed aan op hun wensen. Ook de Daisy-player wordt graag door de visueel gehandicapte klanten van het Loket gebruikt. En daar doen we het voor!

Een jaar geleden gaf Roel van Houten (Viziris) bij Tam Tam een demonstratie van zijn internetgebruik als blinde. Dat gaf al een goede indruk van bruikbaarheidsfactoren voor blinden. Daarnaast gaf hij diverse suggesties om de usability voor visueel gehandicapten te vergroten. Eind vorig jaar kregen we bij Tam Tam drie visueel gehandicapten op bezoek. Zij kwamen de nieuwe website van het Loket aangepast-lezen testen, die komende maand live gaat.

Wat we hebben geleerd? 10 usability tips aangaande visueel gehandicapten.

Hoe gebruiken visueel gehandicapten het web?

Misschien is het goed om eerst even stil te staan bij hoe blinden en slechtzienden op webpagina’s navigeren en lezen. Dan vallen de usability-tips wellicht ook beter op hun plaats.

• Veel blinden en slechtzienden gebruiken een screenreader: software die de tekst op het beeldscherm voorleest. Gelukkig hoeven ze niet te wachten tot de hele pagina is voorgelezen. Blinden scannen ook webpagina’s, maar dus op gehoor in plaats van zicht. Met het toetsenbord kunnen ze navigeren over de pagina: springend van kopregel naar kopregel of (met de ‘tab’-toets) van link naar link. Of ze laten de screenreader bv. alle links sorteren op alfabet, en lopen daar doorheen. Veel gebruikers stellen een hoge voorleessnelheid (tot wel 300 woorden per minuut!) in om een pagina sneller te kunnen scannen.
  
• Veel blinden gebruiken (ook) een brailleleesregel. Deze worden vaak aanvullend gebruikt op een screenreader, om nauwkeuriger te lezen. Bijvoorbeeld om de spelling te controleren van wat ze hebben getypt. Brailleleesregel-gebruikers overzien maar een halve tekstregel tegelijk en hebben dus geen overzicht van het grotere geheel.
  
• Een deel van de slechtzienden gebruikt een hoog contrast weergave (bv. zwart op geel) om teksten beter te kunnen lezen.
  
• Een deel van de slechtzienden gebruikt vergrotingssoftware, die een klein deel van het scherm heel sterk uitvergroot. Omdat mensen die hun pagina met 600% vergroten steeds maar een stukje (1/36e deel) van het scherm zien, is het  voor deze gebruikers heel moeilijk om de samenhang van elementen op een pagina te zien.
  
• De meeste toegankelijke webbouwers plaatsen bovenin de code zogeheten skip-links. Met deze hyperlinks – meestal onzichtbaar voor de gemiddelde gebruiker – kunnen gebruikers van een screenreader delen van de pagina overslaan (vandaar ‘skip’) en direct navigeren naar waar bv. het hoofdmenu, de zoekfunctie of juist de content begint.
• Informatie in afbeeldingen gaat aan blinden helemaal en aan slechtzienden grotendeels voorbij. Daarom is het goed gebruik die informatie toe te voegen aan het ‘alt’ (alternatief) attribuut van een afbeelding. Wordt de alt-tekst leeg gelaten, dan gaat de screenreader eraan voorbij. Voor decoratieve afbeeldingen is dit juist handig, want anders creëer je alleen maar ruis.
• Tabellen zijn lastig te lezen. Screenreader-gebruikers moeten van cel naar cel navigeren om de informatie tot zich te nemen. Door attributen mee te geven aan de rij- en kolomkoppen krijgt de gebruiker gelukkig wel bij iedere beweging binnen de tabel te horen naar welke rij of kolom hij navigeert.
• Formulieren invullen kost heel veel tijd. Zowel het lezen, het invullen, het controleren van de invoer en het signaleren van en reageren op foutmeldingen vergen veel geduld.

1. Voorkom ruis op de pagina

Op veel websites wordt geprobeerd de bezoeker zoveel mogelijk interessante informatie of functionaliteit(en) aan te bieden. Blinden en slechtzienden moeten over het algemeen veel meer tijd investeren om te bepalen welke informatie of functionaliteit(en) een pagina bevat. Het kan daarom heel verwarrend zijn als de pagina inhoud bevat die slechts zijdelings gerelateerd is aan het doel van die pagina. Het bemoeilijkt het scannen van de pagina en kan hem zelfs op het verkeerde been zetten.

Presenteer zo snel mogelijk de kerninhoud of -functionaliteit. Presenteer de ‘ook interessant’ onderdelen pas daarna (of laat ze helemaal achterwege).

Op de nieuwe site van Loket aangepast-lezen hadden we op de Aanwinsten-pagina een ‘zoek in de catalogus’ boven de aanwinsten geplaatst. Dat leek ons wel handig, maar de blinde gebruikers dachten er anders over. Nu hebben we de zoekfunctie weggehaald op deze pagina.

2. Kopregels (h2, h3): alleen voor paragrafen en secties

Veel screenreader gebruikers scannen een webpagina door snel alle (h2) kopregels af te lopen. Daarmee hopen ze alle hoofdparagrafen en belangrijke paginasecties (bv. voor navigatie) tegen te komen.

Gebruik geen kopregels voor bv. titels in een lijst van nieuwsitems. Maak daar gewoon hyperlinks van. Anders kost het screenreader gebruikers veel extra tijd om de pagina te scannen.

Vermijd ook het gebruik van kopregelniveaus 4 en 5 (h4 en h5). Visueel gehandicapten die sneltoetsen gebruiken om kopregels te scannen, verwachten paragrafen (h2) en hooguit subparagrafen (h3). Zelden is een pagina zo uitgebreid van stof dat daar nog weer kopjes onder nodig heeft. Screenreader gebruikers scannen dan ook zelden of een pagina h4-kopregels bevat. Gebruik h4 en h5 in ieder geval niet voor andere (bv. lay-out) doeleinden.

3. Links: belangrijkste woord vooraan

Zet in links het belangrijkste woord vooraan. Dit is een algemene usability-aanbeveling, maar voor visueel gehandicapten is het om nog een reden heel handig: In sommige screenreaders kun je alle links op een pagina in een alfabetisch gesorteerde lijst laten zetten om zo sneller een bepaalde link te vinden.

4. Veelgebruikte links en afbeeldingen: compact

Aanvullend op de vorige tip:  skip-links staan op iedere pagina en worden bij een gemiddeld websitebezoek dus vaak opgelezen. Screenreader gebruikers weten precies de functie van deze links en willen ze zo snel mogelijk kunnen gebruiken. Hou ze dus kort, dus niet “Ga direct naar de content”, maar “Content”. Ook niet “Naar content”. Immers: zet het belangrijkste woord vooraan.

Bied je veel documenten aan in bv. PDF en Word? Zet dan niet onder ieder icoon een alt-tekst als “Documenttype: Microsoft Word” of nog langer, maar “PDF” of “Word”. Langere alt-teksten kosten onnodig meer tijd om voorgelezen te worden.

In een bètaversie van het nieuwe aangepast-lezen.nl stond onder de icoontjes in de voorste kolom “De leesvorm is braille”.

5. Decoratieve afbeeldingen: geen alt-tekst

Decoratieve afbeeldingen horen eigenlijk in de stylesheet thuis. Maar omdat dit niet altijd mogelijk is, zien we ook regelmatig decoratieve afbeeldingen in de html-code staan. Als je dit doet, bedenk er dan geen alt-tekst bij; die zorgt alleen voor ruis. Dus laat de alt-tekst leeg (alt=””).

6. Zoekresultaat: filters achteraan

Veel zoekfuncties hebben tegenwoordig zoekfilters, waarmee je een zoekresultaat kunt verfijnen. Deze filters staan visueel vaak links, rechts of boven de resultatenlijst. En dat is goed. Maar zet de filters in de html-code ACHTER de zoekresultaten, omdat screenreader gebruikers anders eerst langs alle filters moeten voordat ze de zoekresultaten bereiken. Het is hierbij wel handig om boven de zoekresultaten een skip-link te maken naar de filters.

Natuurlijk kun je ook gewoon een skip-link maken naar de zoekresultaten, maar dat is wat krom: dat je op de pagina “Zoekresultaten” nog een keer extra moet klikken om bij de zoekresultaten te komen.

7. Layout: voorspelbaar

Voor visueel gehandicapten is consistentie nog veel belangrijker dan voor de rest. Het kost hen namelijk meer moeite om een willekeurige plek op de pagina te bereiken. Zij moeten er – danwel met hun toetsenbord, danwel met vergrotingssoftware – gericht naar op zoek gaan.

Met een vaste plaatsing van onderdelen en het volgen van conventies help je hen dus bijzonder veel. Het gaat dan bijvoorbeeld om de zoekfunctie en lettervergrotingsopties (rechts)bovenin en contactinfo rechtsbovenin en/of onderaan.

Gebruik voor lettervergrotingsopties de volgende conventie: “A A A” met de alt-teksten ‘normaal’, ‘groot’ en ‘extra groot’.

8. Gebrek aan context

Sommige slechtzienden moeten zo sterk inzoomen op het beeldscherm, dat ze steeds maar een klein stukje van een pagina kunnen zien. Daardoor missen ze veel context. Zie onderstaande voorbeelden.

Het linker voorbeeld is een stukje van een navigatiemenu. Omdat de links in het menu dezelfde kleur hebben als de lopende tekst, en geen lijntje eronder, een pijltje ervoor of een achtergrondkleur hebben, is het onduidelijk dat het om een menu-link gaat.

Het rechtervoorbeeld is veel minder sterk ingezoomd. Maar zie je hier gedeelten van 3 blokken, of 2 invoervelden of iets anders? Het bovenste witte blok is een invoerveld en het onderste witte blok is de witruimte tussen het inlogblok en het contactblok. Omdat beide blokken dezelfde kleur hebben en de witruimte ertussen sterk overeenkomt met de witte vlakken die de invoervelden vormen, is het niet duidelijk dat het de ruimte tussen 2 blokken betreft. En hoe meer je inzoomt, hoe moeilijker het wordt.

Hiermee rekening houden zal een lastige opgave zijn.  Probeer in ieder geval menulinks voldoende herkenbaar te maken.

9. Tabellen

• Gebruik tabellen alleen waarvoor ze bedoeld zijn (relationele informatie presenteren) en niet voor lay-out doeleinden.
• En andersom: als je informatie presenteert dat zich uitstekend leent voor tabelopmaak, gebruik dan ook een tabel. Dan kunnen visueel gehandicapten daar sneller doorheen navigeren dan door iets dat eruit ziet als een tabel maar het niet is.
• Maak de tabel zichtbaar, dus herkenbaar als tabel en voorzie hem van rij- en/of kolomkoppen.
• Zet de belangrijkste informatie in de eerste kolom.
• Bevat een tabel op iedere regel een call-to-action (bv. ‘plaats in winkelwagen’)? Deze knoppen verwacht men in de meest rechtse kolom.

In deze tabel zou de eerste kolom de boektitel en de tweede kolom de auteur moeten bevatten.

10. Formulieren

• Plaats labels en bijbehorende invoervelden zo dicht mogelijk bij elkaar. Vooral zeer handig voor mensen die inzoomen op het scherm.
• Formuleer labels zo kort mogelijk. De screenreader gebruiker krijgt via spraak al veel boodschappen en hoe korter het commando, hoe beter.
• Verplichte velden worden vaak aangeduid met een *. Gebruik hiervoor het liefst een afbeelding van een asterisk (sterretje), met de alt-tekst ‘verplicht veld’. Niet alleen geeft deze alt-tekst meer informatie dan een asterisk, maar screenreaders worden door gebruikers vaak ingesteld op “geen leestekens en overige tekens voorlezen” vanwege snelheidswinst bij het lezen.
• Geef niet alleen visuele feedback als het formulier een invoerfout bevat, bijvoorbeeld door het betreffende invoerveld een rood dikker kader te geven. Vermeld in tekst welke fout is opgetreden.
• Als na het verzenden van een formulier een foutmelding wordt weergegeven, vermeld die foutmelding dan ook in de paginatitel. Zo weet een screenreader gebruiker meteen wat er aan de hand is.
• Vermijd vooringevulde velden. Screenreader gebruikers hebben vaak niet in de gaten dat er al een standaardwaarde of een invoerhint staat. En als je het toch toepast: zorg dan dat de tekst automatisch wordt geselecteerd zodra het invoerveld de focus krijgt. Dan hoeft hij de vooringevulde tekst niet eerst weg te halen, maar wordt die vanzelf verwijderd bij het typen.
• Als straat en huisnummer in twee achter elkaar geplaatste velden ingevoerd moeten worden, voorzie dan elk veld van een eigen label. Dit geeft het beste overzicht met zowel screenreader als vergrotingssoftware.
• Zorg dat je met de pijltjestoetsen door een uitklaplijst (dropdown box) kunt bladeren (in tegenstelling tot meteen de pagina verversen zodra je op de eerste optie komt)
• Vermijd captcha’s. Alleen zeer ervaren screenreader gebruikers hebben een tool om captcha’s te kunnen oplossen.

De meeste van bovenstaande usability tips zijn eenvoudig toe te passen, dus ik zeg: probeer het eens! Alvast bedankt namens zo’n 300.000 Nederlanders.

Onderstaande richtlijnen zorgen niet alleen voor betere toegankelijkheid, maar ook voor betere performance, vindbaarheid in zoekmachines en browser-compatibiliteit.

• Algemeen
• Pagina-opbouw
• Opmaak
• Multimedia en dynamische content
• Formulieren
• CMS inrichten

Algemeen

• Scheid content, opmaak en interactie. Dit principe heet gelaagd bouwen (progressive enhancement) en zorgt ervoor dat de website goed functioneert wanneer bijvoorbeeld stylesheets of JavaScript niet wordt ondersteund.
  • Zorg dat alle content in het HTML-document beschikbaar is en niet afhankelijk is van scripts en plugins. Gebruik JavaScript alleen om interactie of dynamische weergave te realiseren. Plaats geen content door middel van JavaScript.
  • Regel alle opmaak in een goed georganiseerde stylesheet. Gebruik dus geen inline style-attributen.
  • Plaats JavaScript in aparte JavaScript-bestanden, niet in het HTML-document.
  • Vermijd het gebruik van verouderde HTML-elementen, zoals <center>, <font>, <b>, <i> en <u>. Deze elementen zorgen voor opmaak in plaats van semantiek en gaat tegen het principe van gelaagd bouwen in.
  • Misbruik HTML-elementen niet voor opmaakdoeleinden. <blockquote> is niet bedoeld voor het inspringen van tekst, maar voor de opmaak van citaten.
• Lever HTML, CSS en scripts op conform W3C-specificaties.
  • HTML: XHTML 1.0 strict
  • CSS: CSS level 2.1
  • Scripting: ECMAScript, DOM

  In Internet Explorer 8 kun je eenvoudig programmacode valideren op HTML en CSS. Via functietoets F12 kom je terecht bij de Ontwikkelhulpprogramma’s (Engels: Developer Tools). In het menu ‘Valideren’ vind je W3C-validators voor HTML en CSS.

• Zorg dat alle content bereikbaar en bedienbaar is met alleen het toetsenbord. Vermijd dus apparaatspecifieke event handlers als “onmouseover”.

Pagina-opbouw

Begin met het opzetten van een skelet. Hiermee creëer je een consistente pagina-opbouw, die blinden helpt sneller te navigeren en ook beter onderhoudbaar is. Vervolgens kun je per template specifieke elementen toevoegen.

• Definieer het “XHTML 1.0”-doctype bovenaan het HTML-document voor een correcte representatie van de website. HTML5 is nog geen formele W3C-standaard.

  <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Strict//EN” “http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd”>

• Vermeld de basistaal van de pagina in het ‘HTML’-attribuut.

  <html xmlns=”http://www.w3.org/1999/xhtml” xml:lang=”nl” lang=”nl”>

• Gebruik de UTF-8 karakterset. Dit is de officiële, internationale standaard en zorgt voor de beste ondersteuning voor alle talen.
• Plaats de belangrijkste contentblokken vooraan in de broncode. Navigatie, zoekfunctie, meta-menu en dergelijke komen daarna pas aan bod.
  • Positioneer de onderdelen op de pagina met behulp van de stylesheet.
  • Plaats boven de content hyperlinks waarmee de gebruiker direct naar de navigatie en de zoekfunctie kan gaan. Deze links hoeven niet zichtbaar te zijn als de stylesheet is ingeschakeld.
• Zorg voor een correcte kopregel (heading) structuur.
  • Reserveer <h1> voor de paginatitel. Iedere pagina heeft dus één <h1>.
  • Gebruik <h2> voor paragraaftitels en kopregels voor de belangrijkste paginaonderdelen, zowel zichtbaar (bv. “Gerelateerde pagina’s”) als onzichtbaar (bv. “Hoofdmenu”).
  • Gebruik <h3> voor subparagrafen.
  • Gebruik geen <strong> of iets dergelijks voor het aangeven van kopregels.
  • Sla geen stappen over. Gebruik dus geen <h3> zonder een <h2> begin altijd met de <h1>.
• Gebruik tabellen alleen voor tabulaire data. Tabellen voor de opmaak van content is niet toegestaan.
• Gebruik geen iframes en frames.

Opmaak

Content moet betekenisvol en correct opgemaakt worden, zodat er geen informatie verloren gaat voor gebruikers.

• Maak lijsten op met <ul> of <ol> elementen. Tip: Een navigatiemenu is ook een lijst.
• Voorzie iedere afbeelding van een alt-attribuut.
  • Brengt de afbeelding informatie over, communiceer deze informatie dan in de alt-tekst.
  • Is de afbeelding puur decoratief of illustratief, laat de alt-tekst dan leeg (alt=””).
  • Maakt de afbeelding onderdeel uit van een hyperlink die al een tekstlabel heeft, laat de alt-tekst dan leeg. Twee keer het zelfde label is te veel van het goede.
• Plaats decoratieve afbeeldingen zoveel mogelijk met CSS.
• Vermijd afbeeldingen voor tekst.
• Zorg dat alle content tot minimaal 200% kan schalen als gebruikers inzoomen.
• Ontneem links niet het outline attribuut met CSS, omdat het voor mensen die met het toetsenbord werken duidelijk moet zijn welk element de focus heeft.

Multimedia en dynamische content

• Zet een toegankelijke mediaspeler in voor het afspelen van video’s. De mediaspeler moet gebruikers in staat stellen:
  • Ondertiteling in/uit te schakelen;
  • Ondersteunend geluidsspoor in/uit te schakelen;
  • Video-bestand te downloaden als JavaScript of plugin uitgeschakeld is.
• Zorg dat bewegende, knipperende, scrollende of automatisch actualiserende content gepauzeerd, verborgen, vertraagd en/of gestopt kan worden.

Formulieren

• Breng in grote formulieren structuur aan door het groeperen van aan elkaar gerelateerde invoervelden. Gebruik bijvoorbeeld fieldsets voor ‘Persoonsgegevens’ en ‘Bedrijfsgegevens’.
• Voorzie ieder invoerveld van een label.
• Geef aan welke invoervelden verplicht ingevuld moeten worden.
• Geef concrete feedback bij het foutief invullen van het formulier. “U heeft niet alles ingevuld” is onvoldoende. Maak zowel in tekst als visueel duidelijk wat de gebruiker precies is vergeten of welke invoer foutief is.
• Wees terughoudend met het gebruik van CAPTCHA’s om spambots te weren. Omdat de meeste CAPTCHA’s veel eisen van zicht- of gehoorcapaciteiten, moet je meerdere output alternatieven geven. Denk ook eens na over alternatieve oplossingen. Een simpele vraag als “Hoeveel is 1+1?” met invoerveld is ook effectief en toegankelijk.

CMS inrichten

• Zorg dat redacteuren voor iedere pagina de titel, pagina-beschrijving en trefwoorden kunnen opgeven.
• Zorg dat de editor alle functies ondersteunt die nodig zijn om toegankelijke content te kunnen produceren:
  • Minimaal: kopregels voor (sub)paragrafen (H2+H3), opsommingen (genummerd en ongenummerd), hyperlinks, afbeeldingen, taalaanduiding (per alinea en geselecteerde tekst), belangrijke woorden (vet), nadruk (cursief).
  • Bij voorkeur: afkortingen, tabellen (met ondersteuning voor titel, labels en scope) , blokcitaat, tekst uitlijnen (voor in tabellen), aangepaste stijlen (indien van toepassing, bijvoorbeeld voor een intro-alinea, tip of citaat).
• Schakel functies in de editor uit die content alleen maar ontoegankelijker kunnen maken:
  • Minimaal: lettertype, tekstkleur, achtergrondkleur, tekstmarkeringskleur
  • Bij voorkeur: onderstrepen, kopregel voor paginatitel (H1), broncode bewerken (maar alleen als tabellen via de editor volledig conform richtlijnen kunnen worden opgemaakt)
• Zorg dat de editor alleen valide code produceert, dus bijvoorbeeld geen <b> maar <strong>.

Heb je aanvullingen of opmerkingen? Laat het weten!

Zie ook

• Toegankelijkheid voor ontwerpers
• Toegankelijkheid voor redacteuren
• Richtlijnen voor Toegankelijkheid van Webcontent (WCAG) 2.0

Jeroen Hulscher is collega bij Tam Tam en frontend code-purist. Houd zijn nieuwe blog goed in de gaten voor meer artikelen over toegankelijk en kwalitatief bouwen!

Het volgen van toegankelijkheidsrichtlijnen vergroot niet alleen de bruikbaarheid voor mensen met een beperking, maar vergroot bijvoorbeeld ook de vindbaarheid van content via zoekmachines.

• Structuur en opmaak
• Taal
• Afbeeldingen
• Hyperlinks
• Downloads
• Video en audio
• Formulieren
• Tabellen

Structuur en opmaak

Het aanbrengen van een goede paginastructuur is een belangrijk instrument voor zoekmachineoptimalisatie en om content via andere media, zoals mobiel, RSS en voorleessoftware, aan te bieden. Bovendien helpt het blinden sneller door de content bladeren.

• Geef iedere pagina een titel die het onderwerp of doel zo goed mogelijk beschrijft.  Een titel die relevante trefwoorden bevat, maakt de pagina ook beter vindbaar in zoekmachines.
• Breng structuur aan met kopregels voor (sub)paragrafen. Tekstverwerkers zoals Microsoft Word kunnen alleen een inhoudsopgave genereren als je titels van hoofdstukken, paragrafen en subparagrafen netjes opmaakt met kopregel-stijlen. De software moet de structuur van het document kunnen begrijpen.

  

  Bij webpagina’s werkt dit net zo:

  • Paginatitel: heading 1 <h1>
  • Paragraaf: heading 2 <h2>
  • Subparagraaf: heading 3 <h3>

  Als je dit goed toepast, kan een blinde door middel van sneltoetsen heel eenvoudig van paragraaf naar paragraaf springen. En voor zoekmachines wegen woorden in kopregels zwaarder, dus beschrijvende kopregels helpen ook de vindbaarheid van je pagina.

  Sla geen niveaus over, hoe verleidelijk dat soms ook is. In een rapport kun je in hoofdstuk 1 ook geen subparagraaf 1.1.1 maken als je geen paragraaf 1.1 hebt.

• Zet de belangrijkste informatie zoveel mogelijk bovenaan. Dan kunnen bezoekers snel inschatten of het zin heeft de rest van de pagina te lezen.
• Gebruik vet en cursief om nadruk te leggen op woorden of fragmenten, maar niet om kopregels te maken (zie vorige punt) of voor vormgeving.
  • Gebruik cursief met mate. Het is vaak wat moeilijker leesbaar en niet alle telefoons ondersteunen cursieve tekst. Cursief is vooral geschikt om wat nadruk te geven op een enkel woord, zoals het woord ‘niet’ hierboven.
  • Gebruik vet om een woord of fragment te laten opvallen omdat het belangrijke informatie betreft.
  • Maak niet zelf bijvoorbeeld de hele eerste alinea vet omdat het zo mooi staat. Als je dit visuele effect wilt bereiken, vraag dan aan de bouwer of hij een ‘intro’-stijl wil toevoegen aan de tekst-editor.
• Maak bij opsommingen altijd gebruik van de daarvoor bedoelde knoppen. Zet niet zelf cijfers, mintekens of sterretjes voor iedere regel. Dan snapt de computer niet dat het een opsomming betreft.
• Gebruik in de tekst-editor nooit de knoppen voor onderstrepen, lettertype, lettergrootte, letterkleur en achtergrondkleur. Onderstreepte tekst lijkt teveel op een hyperlink. Het handmatig aanpassen van de tekststijl maakt de content minder toegankelijk en het ondermijnt ook de huisstijl.

Taal

Als je schrijft voor algemeen publiek, bedenk dan dat 60% van de Nederlanders qua taalniveau niet uitkomt boven de derde klas vmbo-t (voorheen mavo). Sterker nog, Nederland telt ongeveer 1,5 miljoen laaggeletterden: mensen die zo’n grote moeite hebben met lezen en schrijven dat ze worden beperkt in functioneren op het werk en in de samenleving.

• Schrijf teksten op taalniveau B1. Dit komt neer op eenvoudige communicatie, met alledaagse woorden en niet te lange zinnen. De meeste Nederlanders kunnen dit begrijpen.
  • Meer informatie over  taalniveaus
  • Test het leesniveau van je tekst
• Markeer een taalwissel als je een volledige zin (of meer) in een andere taal schrijft.  Nederlandse voorleesstemmen kunnen buitenlandse woorden niet goed uitspreken, waardoor de tekst onbegrijpelijk wordt voor mensen die afhankelijk zijn van voorleessoftware. Daarnaast zorgt taalaanduiding ervoor dat zoekmachines de informatie beter kunnen indexeren.

  Je hoeft niet voor ieder los woordje in een andere taal een taalwissel aan te geven. We maken in Nederland gebruik van veel leenwoorden, die meestal wel goed uitgesproken worden. Daarnaast vinden veel blinden het continu wisselen tussen voorleesstemmen irritanter dan het verkeerd uitspreken van losse woorden.

  Let op: Niet alle tekst-editors ondersteunen het markeren van taalwissels standaard. Overleg met de bouwer als dit het geval is.

Afbeeldingen

Niet iedereen kan zien wat afbeeldingen uitbeelden, zoals visueel gehandicapten, maar ook zoekmachines. Anderen kiezen er bewust voor geen plaatjes te laten tonen, bijvoorbeeld mobiele internetters met langzaam/duur internetabonnement of met een oudere telefoon.

• Beschrijf in de alt-tekst welke informatie de afbeelding overbrengt. Zet hierbij de boodschap van de afbeelding centraal.

  “Prinses Maxima luistert samen met de president van Abu Dhabi naar de openingstoespraak van Prins Willem-Alexander van de World Future Energy Summit (WFES)” geeft veel relevantere informatie dan “Westerse vrouw zit tussen Arabische mannen”.

  

  Uitzonderingen:

  • Als een plaatje puur decoratief of illustratief is en geen informatie toevoegt aan de tekst, heeft het bij voorkeur geen ingevulde alt-tekst. Dit zou dan juist voor ruis zorgen.
  • Als een hyperlink uit een plaatjes en een linktekst bestaat, moet het plaatje geen ingevulde alt-tekst hebben. Anders leest een screenreader twee keer dezelfde tekst achter elkaar op.

Hyperlinks

• Zorg voor beschrijvende en onderscheidende hyperlinks.  Een blinde kan op een webpagina door middel van sneltoetsen springen van link naar link. Als hij achter elkaar “Lees verder” of “Klik hier” hyperlinks tegenkomt, heeft hij geen idee waar al die hyperlinks naar wijzen.

  Ook voor zoekmachineoptimalisatie zijn beschrijvende hyperlinks zinvol. Woorden in hyperlinks wegen zwaarder dan woorden in de lopende tekst.

• Laat hyperlinks niet automatisch een nieuw venster openen. Het komt regelmatig voor dat gebruikers niet doorhebben als een webpagina in een nieuw venster opent en in verwarring raken als ze proberen terug te keren naar de vorige pagina.

  Laat de keuze aan de gebruiker. Alle browsers bieden de mogelijkheid om pagina’s in een nieuw venster of nieuwe tab te openen.

• Vermeld in e-maillinks het volledige e-mailadres. Een linktekst “Neem contact met ons op” is niet voldoende. Een e-maillink opent namelijk het standaard e-mailprogramma op de computer, maar het is goed mogelijk dat een bezoeker de e-mail wil versturen via een online mailservice zoals Hotmail.

Downloads

Jaarverslagen, brochures, rapporten, zomaar wat voorbeelden van documenten die vaak als downloadbaar bestand worden aangeboden. Ook deze documenten moeten voor iedereen goed leesbaar zijn.

• Bied informatie alleen als download aan als het gaat om achtergrondinformatie of documenten die primair voor print zijn bedoeld. Gebruik downloads dus niet als uitweg om belangrijke content niet toegankelijk te hoeven opmaken in html.
• Bied informatie in downloadbare bestanden toegankelijk en minimaal in één open standaard aan. Als je informatie niet op een webpagina aanbiedt, maar in een ander soort document, zorg dan dat het document toegankelijk is, dus met behoud van (voorleesbare) tekst en structuur. Soms (bv. bij PDF) moet je bij het opslaan expliciet aangeven dat het document toegankelijk moet blijven.

  Het is ook aan te raden documenten in minimaal één open standaard aan te bieden. Je mag er namelijk niet vanuit gaan dat iedereen dezelfde software gebruikt. Voor populaire documenttypen als Microsoft Word en PDF zijn open standaard varianten beschikbaar:

  • MS Office: docx, pptx, xlsx (vanaf Office 2007)
  • PDF: PDF/A-1a
    > Tools om PDF/A documenten te creëren en valideren
• Vermeld bij hyperlinks naar documenten het bestandstype en liefst ook de bestandsgrootte. Zo weet de bezoeker wat hij gaat downloaden en hoe lang het ongeveer kan duren.
• Laat downloadbare bestanden niet automatisch in een nieuw browservenster openen. Behandel een link naar een bestand als een normale link. De bouwer moet ervoor zorgen dat bezoekers de mogelijkheid krijgen het bestand te openen of op te slaan.
• Zorg dat ergens op de site informatie staat over hoe bezoekers de downloadbare bestanden kunnen openen en gebruiken. Dit kan bijvoorbeeld geplaatst worden in de colofon-pagina waar in ieder geval vermeld staat hoe de bezoeker aan de software kan komen om het betreffende formaat te kunnen openen.

Video en audio

Steeds vaker wordt informatie overgebracht door middel van video’s, animaties, podcasts en andere multimedia. Dit kan problemen opleveren voor visueel en auditief gehandicapten, maar in sommige gevallen ook voor mensen met epilepsie. Los hiervan is informatie die wordt verteld in een video niet vindbaar voor zoekmachines. Gelukkig is een toegankelijke video maken niet moeilijk.

• Zorg ervoor dat belangrijke informatie die alleen maar visueel wordt overgebracht, ook voorgelezen wordt.  Blinden en slechtzienden ontgaat anders die informatie.
• Geef een ondertiteling van wat er gezegd wordt en van eventuele geluidseffecten.  Doven en slechthorenden begrijpen anders niet waar de video over gaat.
• Bied voor podcasts en andere audio-content ook een transcriptie aan.

Alles over het toegankelijk maken van video en audio

Formulieren

Niet iedere redacteur heeft zelf met formulieren te maken. Maar voor wie hier wel bij betrokken is:

• Voorzie in alternatieve contactmogelijkheden zoals adresgegevens, telefoonnummers of e-mailadressen, als deze beschikbaar zijn. Mensen die moeite hebben met formulieren invullen, willen wellicht liever bellen. Omgekeerd versturen doven en slechthorenden liever een e-mail of contactformulier.
• Geef bij complexe formulieren aan hoe groot het formulier ongeveer is. Dan kan de bezoeker bepalen of hij het formulier nu of later wil invullen. Dit is met name handig voor mensen bij wie het invullen van formulieren extra moeite kost.
• Noem documenten die de bezoeker (eventueel) nodig heeft bij het invullen van het formulier. Hiermee voorkom je dat mensen het invullen lang moeten onderbreken om documenten op te zoeken, met als risico dat de browser-sessie verloopt.
• Voorzie formulieren van labels en instructies voor de bezoeker waar nodig.  Hiermee voorkom je zoveel mogelijk dat gebruikers fouten maken. Met name voor mensen met een beperking kost het corrigeren van een formulier veel moeite.
• Laat de bezoeker weten wat er met eventueel ingevulde privégegevens gedaan wordt, bijvoorbeeld in de vorm van een privacyverklaring. Wees ook uiterst terughoudend met het publiceren van e-mailadressen van bezoekers van de website.
• Laat de bezoeker weten wat er met het formulier na verzending gedaan wordt.

Tabellen

Van alle redactionele aandachtspunten voor toegankelijkheid, zijn tabellen het meest complex. Dat komt voornamelijk doordat er nog nauwelijks CMS’en zijn die uit zichzelf toegankelijke tabellen produceren. Veel redacteuren zullen tabellen dus handmatig in html moeten creëren.

Bekijk de anatomie van een tabel

• Gebruik tabellen niet voor lay-out, bijvoorbeeld om content in twee kolommen te tonen. Het risico bestaat dat hierdoor de leesvolgorde voor hulpsoftware fout gaat. Gebruik tabellen dus alleen voor het relationeel weergeven van informatie in rijen en kolommen.
• Geef tabellen een titel. Hierdoor kunnen blinden sneller begrijpen waar de tabel over gaat.

  <table>
  <caption>Vergelijking tussen Windows Vista en Windows 7</caption>

• Associeer tabellabels met kolommen en/of rijen.  Dankzij het ‘scope’ attribuut weet hulpsoftware van iedere tabelcel bij welke rij en kolom die cel hoort, en kan dat voorlezen.
  • Rij-label: <th scope=”row”>Vergrootglas</th>
  • Kolom-label: <th scope=”col”>Windows 7</th>
• Maak afkortingen voor lange rij- of kolomlabels. Als spraaksoftware steeds opnieuw een lang tabellabel moet voorlezen, kan dit irritant worden voor de gebruiker.

  <th abbr=”Sneltoetsen”>Gebruik deze toetsenbord sneltoetsen</th>

• Vermijd complexe tabellen. Als je echt complexe tabellen toegankelijk wilt maken, dan moet je nog meer meta-informatie meegeven aan de verschillende tabelelementen. Kijk dus eerst of je de informatie op een andere manier kunt presenteren; dat scheelt werk. Lukt dat niet, kijk dan hoe je complexe tabellen maken kunt.

Zie ook

• Toegankelijkheid voor ontwerpers
• Toegankelijkheid voor ontwikkelaars
• Richtlijnen voor Toegankelijkheid van Webcontent (WCAG) 2.0

• Algemeen
• Kleur
• Video en audio
• Toetsenbord en touchscreen
• Taalkeuze
• Alternatieve navigatie
• Formulieren en contact

Algemeen

Als ontwerper begin je het liefst met het ideaalplaatje. Dat is volkomen logisch en prima. Maar vraag jezelf als ontwerper regelmatig af: “Is dit zo toegankelijk voor iedereen?” Zo niet, in welke vorm dan wel?

• Bespreek alle belangrijke ontwerpkeuzes met het team. Laat ontwerpen eerst intern beoordelen op toegankelijkheid voordat je het presenteert aan de klant. Een feature achteraf toegankelijk maken kost veel meer tijd dan het meteen goed doen.
• Houd rekening met je doelgroep. Hulpmiddelen als een voorleesfunctie of knoppen voor tekstschaling zijn niet verplicht voor toegankelijkheid, maar zijn wel nuttig voor bv. laaggeletterden, mensen met dyslexie en ouderen.
• Ontwerp in lagen. Wat ziet iemand die geen Silverlight of Flash gebruikt? Hoe werkt dit het beste op een mobiele telefoon? Je hoeft geen creatieve, interactieve interfaces overboord te gooien, maar denk wel na over hoe de interface toegankelijk blijft als iemand niet de meest rijke interactie kan beleven.

Kleur

Eén op de 12 mannen is kleurenblind. Bij vrouwen komt het minder voor. De meest voorkomende vorm van kleurenblindheid is dat men het verschil tussen rood en groen niet ziet. Dit heet Protanopia. Maar ook andere vormen komen geregeld voor.

• Breng informatie niet uitsluitend door kleur over. Stel, je wilt in een webwinkel in de productoverzicht direct een indicatie van de levertijd geven. Dan ligt het voor de hand dit met kleuren aan te geven: groen voor direct leverbaar, oranje voor een paar dagen en rood voor niet leverbaar. Heel helder, behalve voor een kleurenblinde.

  

  Test je ontwerp altijd voor kleurenblinden. Met behulp van de volgende kleurenfilters kun je zelf door de ogen van een kleurenblinde  kijken:

  • Vischeck plugin voor Photoshop
  • Colorblind Web Page Filter

  Er is overigens niets op tegen om de kleuren groen en rood naast elkaar te gebruiken, zolang de kleur maar niet de enige onderscheidende factor is. Je kunt prima een groen vinkje voor ‘goed’ en een rood kruisje voor ‘fout’ gebruiken.

• Wees consistent met kleurgebruik bij het geven van betekenis aan informatie. Consistent kleurgebruik, bijvoorbeeld voor hyperlinks, is voor iedereen belangrijk, niet alleen belangrijk voor mensen met een visuele beperking. Hoe consistenter, hoe sneller men vertrouwd raakt met de user interface.
• Zorg voor voldoende contrast tussen tekstkleur en achtergrondkleur. Mensen die slechtziend zijn, hebben moeite met lezen als het contrast laag is.

  Test de kleurcontrasten in het ontwerp. Houd hierbij de volgende richtlijn aan:

  • Grote tekst (groter dan 14pt bold of 18pt normaal) heeft een contrastverhouding van minimaal 3.
  • Overige tekst heeft een contrastverhouding van minimaal 4,5.
  • Voor tekst in logo’s, in decoratieve of in inactieve elementen gelden geen contrasteisen.

Video en audio

Steeds vaker wordt informatie overgebracht door middel van video’s, animaties, podcasts en andere multimedia. Dit kan problemen opleveren voor visueel en auditief gehandicapten, maar in sommige gevallen ook voor mensen met epilepsie. Los hiervan is informatie die wordt verteld in een video niet vindbaar voor zoekmachines. Gelukkig is een toegankelijke video maken niet moeilijk.

• Zorg ervoor dat belangrijke informatie die alleen maar visueel wordt overgebracht, ook voorgelezen wordt. Blinden en slechtzienden ontgaat anders die informatie.
• Geef een ondertiteling van wat er gezegd wordt en van eventuele geluidseffecten. Doven en slechthorenden begrijpen anders niet waar de video over gaat.
• Vermijd snel knipperende fragmenten. Content die meer dan 3x per seconde flitst, is riskant voor mensen met een bepaalde vorm van epilepsie. Als het toch noodzakelijk is, meld dit dan van tevoren.
• Laat video en audio niet automatisch starten. Voor mensen die gebruikmaken van voorleessoftware, is het irritant als de audio van multimedia en de voorleessoftware door elkaar heen lopen.
• Gebruik niet enkel geluid als feedback. Combineer dit altijd met een tekstuele melding.

Alles over het toegankelijk maken van video en audio

Toetsenbord en touchscreen

Het gebruik van internet, e-mail en applicaties op mobiele telefoons en tablet pc’s neemt een vogelvlucht. De meeste van deze apparaten hebben een touchscreen of toetsenbord, maar geen muis. Toch worden er nog veel interfaces ontworpen (zoals uitklapmenu’s) die alleen met de muis bedienbaar zijn.

• Zorg ervoor dat alle pagina-elementen met een toetsenbord benaderd kunnen worden. Ontwerp geen interactieve componenten die alleen maar met een muis bediend kunnen worden.

Taalkeuze

Vlaggetjes in de rechterbovenhoek van websites zien we gelukkig steeds minder. En dat is maar goed ook, want vlaggetjes zijn niet de ideale manier om een taalkeuze aan te bieden. Een Amerikaan of Australiër zal zich namelijk niet aangesproken voelen door een Britse vlag. En zou iedere Congolees de Franse vlag herkennen?

• Schrijf links voor taalkeuze voluit in hun corresponderende taal.
• Presenteer links voor taalkeuze consistent op iedere pagina.

Alternatieve navigatie

Soms hebben gebruikers moeite hun weg te vinden binnen een website. Dan is het handig als zij alternatieve navigatiemiddelen tot hun beschikking hebben om de content toch te vinden.

• Bied meer dan één manier om content te vinden, bijvoorbeeld door een zoekfunctie of sitemap.

Formulieren en contact

Niemand houdt van formulieren invullen, maar voor mensen met een beperking vormen formulieren vaak een extra uitdaging.

• Houd formulieren zo kort mogelijk en beperk het verplicht invullen van formuliervelden. Voor mensen die bijvoorbeeld hun handen niet of nauwelijks kunnen gebruiken, is het invoeren van tekst een grote opgave. Afgezien daarvan, vindt iedereen een kort formulier prettiger.
• Voorzie in alternatieve contactmogelijkheden, zoals adresgegevens, telefoonnummers of e-mailadressen, als deze beschikbaar zijn. Mensen die moeite hebben met formulieren invullen, willen wellicht liever bellen. Omgekeerd versturen doven en slechthorenden liever een e-mail of contactformulier.
• Voorzie formulieren van labels en instructies voor de bezoeker waar nodig. Hiermee voorkom je zoveel mogelijk dat gebruikers fouten maken. Met name voor mensen met een beperking kost het corrigeren van een formulier veel moeite.
• Plaats labels zo dicht mogelijk bij het invoerveld. Slechtzienden die hun beeldscherm sterk moeten vergroten of die kokervisie hebben, zien maar een klein gedeelte van wat er op het scherm staat. Daarom is het handig om formuliervelden en hun bijbehorende labels dicht bij elkaar te plaatsen.
• Geef bij het automatisch signaleren van invoerfouten duidelijk aan waar de fout optreedt en wat er precies fout is.
• Stel gebruikers bij transactionele formulieren in de gelegenheid hun invoer te controleren en te verbeteren.

Zie ook

• Toegankelijkheid voor redacteuren
• Toegankelijkheid voor ontwikkelaars
• Richtlijnen voor Toegankelijkheid van Webcontent (WCAG) 2.0

Deze vragen c.q. ideeën kruisen regelmatig mijn pad en zijn op zich ook heel logisch. Via Google vind je inderdaad alles. En veel mensen hebben een voorkeur voor zoeken op websites. Althans, zo lijkt het. Zes redenen om je navigatiestructuur niet overboord te gooien:

1. De meeste mensen gaan op websites niet direct zoeken
2. Bol.com is anders dan jouw website
3. Google is anders dan jouw website
4. Niet iedereen kan goed zoeken.
5. Een effectieve zoekfunctie is vaak complexer te realiseren dan een navigatiesysteem.
6. Alleen een zoek-interface aanbieden kan je site zelfs onvindbaar maken in zoekmachines als Google.

Men gaat niet direct zoeken

Bijna iedereen googlet. Sommige mensen gebruiken zelfs een zoekmachine om op een website te komen waarvan ze de URL al kennen. Zoeken op het web is dus al bijna ‘second nature’. Desondanks wenden de meeste mensen – of zelfs maar de helft – zich niet direct tot de zoekfunctie als ze binnenkomen op de homepage van een website.

Als je regelmatig meekijkt bij usability tests – liefst waar ook eyetracking gebruikt wordt – zie je dat bijna iedereen bij binnenkomst op een homepage eerst de pagina en navigatie scant, op zoek naar de ingang (link) die aansluit bij zijn zoekvraag. Pas als bij deze eerste scan geen match wordt gevonden met de zoekvraag (en alles wat daar voldoende mee associeert), krijgt de zoekfunctie aandacht.

Drie weken geleden was ik aanwezig bij een usability onderzoek van een grote website. De webmanager had aangegeven dat volgens de webstatistieken de meeste bezoekers de zoekfunctie en de links onder de ‘vouw’ gebruiken. In de usability test zagen we hoe dat kwam. Iedere respondent begon vol goede moed met het scannen van de uitklapmenu’s. Maar omdat de navigatielabels niet goed aansloten op het referentiekader van de bezoekers, verloren de meeste respondenten het vertrouwen in de navigatie en zochten ze hun heil bij de zoekfunctie en de links onder de vouw.

Bol.com is anders

Natuurlijk zijn er uitzonderingen. Bijvoorbeeld bij sites als Amazon of Bol.com. Daar gaan veel mensen direct zoeken.

Het verschil tussen Bol.com en de gemiddelde (marketing/communicatie) website is dat op Bol.com de meeste bezoekers zoeken op de titel van een boek of de naam van een auteur. Deze exacte zoekvragen vind je tien keer zo snel met een zoekopdracht dan via een sitenavigatie. Op andere websites komt dit ook wel voor, maar in veel mindere mate. Daar zijn de zoekvragen grotendeels associatief. Ter vergelijking: zoek op Bol.com maar eens op “spannend boek spionage” of “Zweedse schrijver”.

Zoeken op ‘Zweedse schrijver’ levert geen romans met Zweedse schrijvers op (die momenteel zo populair zijn).

Google is anders

Via Google vind je alles. Is dat zo? De zoekindex van Google bevat miljarden pagina’s. De kans dat een willekeurige zoekvraag geen resultaten oplevert, is uiterst klein. Er zijn altijd wel pagina’s die minstens één van de ingevoerde trefwoorden bevatten. Maar of het ook de meest relevante bronnen zijn die je had kunnen vinden, is zeer de vraag. Als ik in Google zoek naar ‘tweedehands auto’, dan vind ik ongetwijfeld relevante sites, maar niet de sites die alleen spreken over ‘occasions’.

Binnen een site heb je als gebruiker deze luxe niet. Als ik zoek op ‘contract’ terwijl in de content alleen ‘arbeidsovereenkomst’ wordt gebruikt, dan krijg ik 0 zoekresultaten. Gevolg: ik neem aan dat deze website de gewenste informatie niet bevat en ik probeer het op een andere website.

Vindbaarheid van content via zoeken is dus sterk afhankelijk van hoe goed de content (inclusief metadata) aansluit op de zoekvragen van de doelgroep. Het is heel lastig en veel werk om alle variaties in zoekvragen goed te dirigeren naar de relevante contentpagina’s. En niet in de laatste plaats omdat lang niet iedereen goede zoekvragen invoert.

Niet iedereen kan goed zoeken

Behoorlijk wat mensen hebben moeite met informatie zoeken op het internet. In een onderzoek naar digitale vaardigheden van Nederlanders (PDF) is gekeken naar de informatievaardigheden van ruim honderd proefpersonen.

Informatievaardigheden zijn het kunnen vinden en gebruiken van informatie, door:

• Het kiezen van een geschikt zoeksysteem (of plaats om informatie te zoeken),
• Het definiëren van zoekwoorden die zich op het informatieprobleem richten,
• Het selecteren van geschikte informatiebronnen,
• Het evalueren van informatiebronnen.

Uit het onderzoek bleek dat ruim de helft van de mensen zoekvragen invoert die niet passen bij het informatieprobleem of te ruim geformuleerd zijn. Eén op de tien (vooral oudere) proefpersonen typt een webadres (www.) in het zoekveld van Google of plakt alle zoekwoorden aan elkaar. Lager opgeleiden typen vaak maar één trefwoord in het zoekveld. Bijna niemand gebruikt speciale zoektekens (b.v. aanhalingstekens of minteken) om effectiever te zoeken.

Onderdeel van zoeken is ook het beoordelen van de resultaten en het kiezen van de meest relevant lijkende link. Ook hier hebben aardig wat mensen moeite mee. Ze gaan er vanuit dat Google het altijd goed heeft en bekijken dus alleen de 3 bovenste resultaten, die ze qua relevantie en betrouwbaarheid niet goed op waarde (kunnen) schatten.

Bij informatievaardigheden speelt opleidingsniveau verreweg de belangrijkste rol. Dus wil je op je website een zoekfunctie inzetten als primair (of zelfs enige) navigatiemiddel, wees er dan van bewust dat waarschijnlijk alleen hoger opgeleide mensen goed in staat zullen zijn informatie op de website te vinden.

N.B. Het gemiddelde opleidingsniveau in Nederland is vmbo-t (voorheen mavo).

Een goede zoekfunctie is complexer dan navigatie

Hoeveel moeite het kost om een succesvol zoeksysteem te realiseren, wordt zwaar onderschat. Veel mensen denken dat een zoekfunctie ‘plug & play’ is: installeren, pagina’s laten indexeren en klaar. Bezoekers weten wel beter. Zij verwachten – net als site-eigenaren – dat alle zoekfuncties op websites net zo (goed) werken als Google. Dat valt in praktijk vies tegen. Niet voor niets maken sommige site-bezoekers een uitstapje naar Google om daar naar informatie binnen de website te zoeken.

Wat is er nodig voor een optimale zoekbeleving? Pagina’s waarop de belangrijkste trefwoorden verwerkt zijn in de kopjes en content, die als metadata een bruikbare korte beschrijving bevatten, evenals synoniemen en veel voorkomende typefouten van de belangrijkste trefwoorden en andere gerelateerde trefwoorden. Maar ook een zoekmachine die snapt dat meerdere zoekwoorden minder resultaten moet opleveren, die zelf herkent als bv. een postcode wordt ingevoerd en die natuurlijk met en zonder spatie accepteert, die snapt dat ‘tafel’ en ‘tafels’ hetzelfde is, die bij nul resultaten zoeksuggesties geeft, die bij veel resultaten filters aanbiedt, die alle zoekopdrachten logt zodat nieuwe trefwoorden kunnen worden toegevoegd aan pagina’s. En wat dacht je van best bets, of automatische suggestie van trefwoorden tijdens het invoeren van trefwoorden?
Kortom, een zoeksysteem goed inrichten (inclusief metadata op alle pagina’s) kost wellicht veel meer tijd dan het ontwerpen van een goede informatiestructuur.

Een grote zoekknop kan je site onvindbaar maken

Ten slotte, ook niet onbelangrijk: als je informatie op je website alleen maar ontsluit via een zoekfunctie, maak je jezelf onvindbaar op zoekmachines als Google. De spiders die het internet indexeren, komen dan namelijk niet voorbij je homepage. Zij kunnen immers zelf geen zoektermen invoeren.

Bottom line: Gooi je navigatiestructuur niet overboord. Sterker nog: steek daar juist energie in. Het maakt je website gebruikersvriendelijker en beter vindbaar. De zoekfunctie wordt daarmee niet onbelangrijk: het is op zijn minst de back-up van je navigatie, of – idealiter – een complementerend, gelijkwaardig navigatiemiddel.

Daarom wil ik graag de volgende vraag voorleggen: Welke eigenschappen heeft een kwalitatief goede website volgens jou?

Afgelopen week heb ik zelf hier ook al over nagedacht, met onderstaande lijst als eerste aanzet. De lijst bestaat uit 3 lagen:

1. Hoofdthema’s
2. Kwaliteitsaspecten (per thema)
3. Voordelen (per kwaliteitsaspect)

Bekijk onderstaande lijst en vul aan / geef commentaar. Ik zal aanvullingen en opmerkingen tussendoor verwerken en hopelijk hebben we dan straks een bruikbare kapstok en een goede businesscase om te werken met de nieuwe Webrichtlijnen.

Nieuwste update: 5/4/2010, 21:00

1. Duurzaamheid / flexibiliteit

1. Milieuvriendelijk
   1. Pagina’s zijn licht, dus besparing op infrastructuur (servers en bandbreedte) en energie
   2. Pagina’s zijn efficiënt printbaar (geen overbodige pagina’s, zuinig met kleur)
2. Technologie- en leverancieronafhankelijk
   1. Blijvend vindbaar dankzij permanente, leesbare URLs
   2. Programmacode geschikt voor alle software die zich houdt aan webstandaarden
   3. Programmacode eenvoudig overdraagbaar aan nieuwe leverancier (dankzij webstandaarden)
   4. Koppelbaar met externe content en diensten
3. Gelaagd bouwen
   1. Vormgeving gescheiden van structuur, dus redesign vergt geen complete herbouw

2. Bereik

1. Vindbaar
   1. Beter vindbaar in zoekmachines (SEO best practices, graag nog concreet maken met richtlijnen, bv. verborgen tekst, meta keywords, robots.txt)
   2. Blijvend vindbaar door permanente, leesbare URLs (geen of minimale parameters)
2. Interoperabiliteit
   1. Werkt in alle browsers
   2. Werkt op mobiel (aangepaste stylesheet, automatische herkenning mobiele opvraging, switch naar normale stylesheet aanwezig)
   3. Vereist geen specifieke software
3. Toegankelijk
   1. Toegankelijk voor digitale risicogroepen (ouderen / laaggeletterden)
   2. Toegankelijk voor mensen met een beperking
4. Uitwisselbaar
   1. Content is eenvoudig te distribueren via diverse media (RSS, e-mail, print)
   2. Content is eenvoudig te delen (social)

3. Service

1. Gebruikersvriendelijk
   1. Eenvoudig navigeren door de website
   2. Eenvoudig formulieren invullen
   3. Goede foutafhandeling
   4. Goede hulpfuncties (bv. sitemap, zoekfunctie)
   5. Website werkt snel (laadtijd)
   6. Informatie goed te printen (aangepaste stylesheet)
2. Bereikbaar
   1. Biedt meerdere contactmogelijkheden
   2. Directe feedback na contactaanvraag

4. Betrouwbaarheid

1. Veilig
   1. URL’s en formulieren beveiligd tegen script-injectie
   2. Waarschuwing voor phishing, etc. (indien van toepassing)
   3. Staat op een veilige server met een hostingpartij die een protocol heeft tegen hackeraanvallen (zoals DoS & brute force)
   4. Belangrijke data (wachtwoorden en persoonsgegevens) worden versleuteld opgeslagen in de database zodat bij toegang door een hacker de schade wordt beperkt
   5. Alle wachtwoord invulvelden werken met een vertraging en maximum aantal pogingen zodat iemand niet door een willekeurig computerscript eindeloos wachtwoorden kan proberen totdat hij de juiste heeft
   6. Elke gebruiker heeft een uniek zogenaamd sessienummer bij zijn bezoek. Sessienummers kunnen niet gemakkelijk geraden kunnen worden zodat iemand een bezoek van iemand anders kan overnemen.
2. Privacy
   1. Verantwoorde omgang met persoonsgegevens (bv. versturen via veilige connectie, minimaal benodigde gegevens vragen)
   2. Website heeft privacyverklaring
3. Afzender
   1. Het is duidelijk wie de afzender van de website is.

5. Imago

1. Service (gebruikersvriendelijk, bereikbaar)
2. Verantwoord ondernemen / corporate responsibility (milieuvriendelijk, toegankelijk)
3. Juridisch / bestuurlijk risico (vanwege discriminatie, onbereikbaarheid, onveiligheid)

6. Projectmanagement

1. Aanbesteding / acceptatie bij oplevering
   1. Duidelijke/concrete kwaliteitseisen aan leveranciers en technologie
2. Efficiënt werken
   1. Minder discussie over implementatiekeuzes door concrete richtlijnen
   2. Eenduidiger processen

7. Beheer

1. Webstatistieken
   1. Belangrijke gebruiksdata beschikbaar voor analyse (bv. entry en exit pages, ingevoerde zoektermen)
2. CMS
   1. Editor produceert valide code
   2. Editor beschikt over spellingscontrole

Ik ben erg benieuwd naar jullie aanvullingen en opmerkingen. Alvast bedankt voor het meedenken!

Veel laaggeletterden kampen met een gevoel van schaamte en proberen zoveel mogelijk te verhullen dat ze niet goed kunnen lezen en schrijven. Internet is voor hen een goed medium om antwoorden te krijgen en zaken te regelen. Het is nagenoeg anoniem en bovendien zeer toegankelijk (de meeste laaggeletterden hebben toegang tot internet).

Helaas blijken de meeste websites te moeilijk voor hen. Organisaties en internetprofessionals (ook veel user experience designers en copywriters) staan er nauwelijks bij stil dat de gemiddelde Nederlander vmbo-geschoold is in plaats van havo of hbo, en dat 10% van de volwassenen heel laaggeletterd is.

Taalniveaus

Op Europees niveau – in het Common European Framework of reference for languages (CEF) – zijn de volgende taalniveaus gedefinieerd:

• A1: zeer eenvoudig, basisbegrippen
• A2: eenvoudige communicatie
• B1: standaard eenvoudige communicatie, niet te lange zinnen
• B2: normale communicatie
• C1: moeilijke of specifieke communicatie
• C2: zeer ingewikkelde communicatie

In Nederland komt 60% van de bevolking niet verder dan taalniveau B1. Het eindniveau van een inburgeringscursus is ook ongeveer B1. Veel communicatie geschiedt echter op niveau B2 of C1 (net als dit artikel ). De gemiddelde Nederlander heeft hier vaak al moeite mee, laat staan laaggeletterden.

Voorbeeld (meer voorbeelden):

• C1: “Met dit product bouwt u een voorziening op voor een aanvulling op uw pensioen.”
• B1: “Wilt u straks extra pensioengeld? Dat kan met deze verzekering.”

De Nederlandse overheid heeft al jaren de ambitie om alle communicatie op B1-niveau te schrijven. Maar dat lukt nog lang niet altijd en overal.

Laaggeletterdheid

Wat is nu precies laaggeletterdheid? Het gaat in ieder geval verder dan alleen het beschikken over lees- en schrijfvaardigheden. Belangrijk is de beperking met betrekking tot het kunnen functioneren in de maatschappij die het met zich meebrengt.

Stichting Lezen & Schrijven definieert laaggeletterdheid of functioneel analfabetisme als volgt: “Het beheersen van lees- en schrijfvaardigheden op een dusdanig niveau dat iemand niet in staat is zich te ontwikkelen of om te functioneren in de maatschappij thuis en op het werk.”

De International Adult Literacy Survey (IALS) gebruikt een schaal met 5 geletterdheidniveaus. Niveau 3 (het kunnen combineren en integreren van verschillende typen informatie in een tekst) is nodig om goed te kunnen functioneren in de kenniseconomie en in onze samenleving. Mensen op niveau 1 of 2 hebben dus onvoldoende vaardigheden om goed te kunnen functioneren. Zij kunnen wel informatie vinden in een simpele tekst en hier eenvoudige gevolgen uit afleiden, maar daar blijft het bij.

De groep laaggeletterden is heel omvangrijk. In Nederland functioneert 10,3% van de bevolking op niveau 1 en 27,1% op niveau 2, totaal dus 37,4% van de Nederlandse bevolking. Enkele wetenswaardigheden over deze groep:

• Een derde van de laaggeletterden is allochtoon.
• Relatief veel ouderen zijn laaggeletterd.
• Er zijn meer vrouwen dan mannen laaggeletterd.
• Laaggeletterden zijn vaker dan gemiddeld ongeschoold, doen slecht betaald werk of zijn werkloos.
• Vaak hebben ze ook minder maatschappelijke perspectieven, waardoor zij afhankelijk zijn van anderen.

In de International Adult Literacy Survey worden 3 typen geletterdheid onderscheiden:

• Prozageletterdheid: het kunnen verwerken van informatie uit redactionele artikelen, nieuwsberichten, gedichten, fictie en dergelijke;
• Documentgeletterdheid: het kunnen vinden en gebruiken van informatie in diverse ‘geconcentreerde’ tekstvormen als gebruiksaanwijzingen, kaarten, tabellen en grafieken;
• Kwantitatieve geletterdheid: het kunnen uitvoeren van rekenkundige bewerkingen zoals het invullen van een cheque of het berekenen van de rente op een lening.

Oplossingen voor eenvoudig communiceren

Welke instrumenten en richtlijnen hebben we voorhanden om te zorgen dat laaggeletterden daadwerkelijk in staat zijn om online informatie van overheden en bedrijven te begrijpen en om hun eigen zaken te kunnen regelen?

Kees ter Beek ging met deze vraag aan de slag bij de Belastingdienst, ten behoeve van zijn afstudeerscriptie voor de masteropleiding Communication Science. Hij onderzocht wat er nodig was om de website Toeslagen.nl begrijpelijker te maken voor laaggeletterden, zonder dat dit negatieve gevolgen zou hebben voor de overige gebruikers van de informatie.

Ter Beek onderzocht 3 instrumenten:

• Herschrijven van de content naar taalniveau A2/B1;
• Aanbieden van een voorleesfunctie;
• Aanbieden van een begrippenlijst.

Richtlijnen

Om de leesbaarheid van een tekst te vergroten, kun je bijvoorbeeld kortere en taalkundig eenvoudigere zinnen maken, gangbaarder woorden gebruiken en de tekst afstemmen op de kennis van de lezer.

Voor zijn opdracht bekeek Ter Beek verschillende sets met richtlijnen voor eenvoudige communicatie:

• “Easy-to-read” richtlijnen (Freyhoff et al., 1998);
• “Richtlijnen Eenvoudig Communiceren” (Stichting Eenvoudig Communiceren, 2006);
• “Kenmerken van een goed leesbare tekst” (Stichting Makkelijk Lezen, 2004, PDF);
• “Easy Read Guidelines” (Grant, 2009).

Deze sets heeft hij vervolgens samengevoegd in één handige lijst:
Lijst met richtlijnen voor eenvoudige taal (pdf)

Herschrijven van toeslagen.nl

Samen met de webredactie keek Ter Beek welke richtlijnen uit bovenstaande lijst de Belastingdienst nog niet toepaste op het web, om vervolgens aan de hand van die richtlijnen enkele teksten op toeslagen.nl te herschrijven.

Een alinea van de originele en hertaalde tekst van de pagina “Hoe werkt zorgtoeslag”

Resultaten gebruiksonderzoek

Herschrijven tekst naar A2/B1-niveau

Dankzij het herschrijven van teksten konden laaggeletterden beter stukjes informatie lokaliseren binnen de tekst. Helaas zorgde het er niet voor dat ze de tekst beter konden interpreteren.

Begripsproblemen ontstonden:

• vooral bij het koppelen van de gelezen informatie aan een gestelde vraag;
• soms bij het tegenkomen van een moeilijk woord.

In dit onderzoek is gebleken dat veel begripsproblemen ook voortkomen uit de andere, met name voorgaande, fasen in de taak, bijvoorbeeld het formuleren van het probleem en het kiezen van de informatiebron. Dit zijn fasen waar geen invloed op uitgeoefend kan worden door het hertalen van een tekst. Dit laat zien dat er bij het begrijpen van informatie op een website meer dingen een rol spelen dan alleen de tekst.

Het gebrek aan verbetering op interpretatie in dit onderzoek is mogelijk ook te wijten aan het feit dat bij het herschrijven voornamelijk aanpassingen zijn gemaakt om het technisch lezen makkelijker te maken, maar het probleem ligt bij het begrijpend lezen.

Naast bovenstaande resultaten leverden de testsessies met laaggeletterden nog enkele interessante waarnemingen op. Een deel van de laaggeletterden:

• is niet goed in staat om op basis van een informatiebehoefte een zoekdoel vast te stellen.
• heeft de neiging op zoek te gaan naar exacte stukken informatie. Een voorbeeld hiervan is een respondent die zegt: “Over 21-jarigen staat er niets in.”, waarbij niet begrepen wordt dat iemand van 21 jaar valt in de categorie “boven de 18”.
• gaat het liefst uit van wat hij zelf weet over het onderwerp. Wanneer eigen kennis wordt gebruikt, hoeft hij geen gebruik te maken van de “moeilijke informatie” van de organisatie. Helaas is die eigen kennis vaak ontoereikend.
• scant geen pagina’s, maar leest ze van begin tot eind. Dit geldt zowel voor het navigeren naar de juiste pagina, als het vinden van een antwoord op een pagina. Dit heeft tot gevolg dat laaggeletterden beduidend langer doen over het vinden van informatie en antwoorden.

De geletterden die aan het onderzoek meededen, waren positief over het niveau van de tekst (“voor iedereen begrijpbaar”) en de bondigheid (“to the point” en “overzichtelijk”). Het beginnen van iedere zin op een nieuwe regel werd echter met wisselende reacties ontvangen. De helft van de geletterden vond het overzichtelijk, maar de andere helft vond het niet prettig (“kinderachtig”, “lijkt wel een gedichtje”).

Voorleesfunctie

De voorleesfunctie is een goed hulpmiddel om de toegankelijkheid te vergroten voor laaggeletterden. Met name de laaggeletterden die over beperkte technische leesvaardigheden beschikken, hebben profijt van de voorleesfunctie.

Voor de laaggeletterden die wel voldoende technische leesvaardigheden hebben is het een goed ondersteunend middel om sneller de tekst te kunnen lezen en verwerken. Het blijkt geen enkel probleem om informatie gelijktijdig in twee modaliteiten te verwerken. Het bevordert het leesproces: men leest vaak mee met de tekst terwijl deze wordt voorgelezen.

Toch heeft de voorleesfunctie wel zijn beperkingen. Het feit dat er maar een paar bestuurknoppen zijn voor het luisteren (starten, stoppen en pauzeren) maakt dat gebruikers ervan soms een pagina helemaal opnieuw beluisteren als ze iets nog een keer willen horen.

Begrippenlijst

De begrippenlijst werd positief gewaardeerd door de laaggeletterde respondenten. Dit is in lijn met eerdere onderzoeken. Het was niet meteen duidelijk voor de respondenten hoe de lijst werkt, maar zodra dit duidelijk was, konden alle respondenten er goed mee uit de voeten. De begrippenlijst had ook effect: de respondenten waren overwegend goed in staat om in eigen woorden uit te leggen wat de betekenis van een begrip was.

Belangrijkste minpunt was de vindbaarheid van de begrippenlijst op Toeslagen.nl. Bijna niemand merkte de lijst aan de rechterkant uit zichzelf op. (Maar dit is voor usability-mensen geen verrassing )

De begrippenlijst op Toeslagen.nl springt niet direct in het oog 

Conclusies en aanbevelingen

• Het is aan te raden de richtlijnen voor eenvoudige communicatie toe te passen bij het schrijven van teksten voor een doelgroep waar laaggeletterden ook deel van uit maken. Zowel geletterden als laaggeletterden houden van duidelijke en simpele taal die ‘to-the-point’ is.
• Kort en duidelijk schrijven helpt vooral informatie sneller te lokaliseren.
• Zorg ervoor dat de tekst er natuurlijk uitziet, zodat de presentatie van de tekst geen aanleiding kan geven om het als kinderachtig te ervaren. Plaats dus niet iedere zin op een nieuwe regel.
• Als laaggeletterden een belangrijke doelgroep zijn: Test teksten met gebruikers om te ontdekken waar begripsproblemen ontstaan.
• Een voorleesfunctie is een goed hulpmiddel voor laaggeletterden. Het helpt ze teksten sneller te kunnen lezen en verwerken.
• Functioneel kan er nog wel wat verbeterd worden aan de gemiddelde voorleesfunctie:
  • Veel mensen lezen mee tijdens het voorlezen. Het zou dus goed zijn om tekst tijdens het voorlezen te laten oplichten. Zo is men beter in staat te volgen wat er voorgelezen wordt.
  • Het zou mogelijk moeten zijn om gebruikers een tekstgedeelte te laten selecteren en dit voor te laten lezen. Hierdoor zal men veel gemakkelijker in staat zijn gewenste stukken informatie te beluisteren.
  • Veel mensen hebben niet door dat ze in de afspeelbalk kunnen klikken om terug of vooruit te gaan in de voorgelezen tekst. ‘Terug’ en ‘verder’ knoppen zouden wellicht een goede aanvulling zijn.
    
• Een begrippenlijst vormt een goede aanvulling op het gebrek aan kennis dat bezoekers hebben over specifieke termen.
• Als je een begrippenlijst inzet: beperk je niet tot een pagina ergens in de site waarop alle begrippen in een alfabetische lijst staan, maar biedt uitleg direct aan bij moeilijke begrippen in een tekst. Zo hoeft de gebruiker niet tussendoor naar een andere pagina om het begrip op te zoeken.
• Een goede informatiestructuur met duidelijke, begrijpelijke labels is voor laaggeletterden extra belangrijk. Omdat zij meer moeite hebben met navigeren, zorgen doodlopende paden voor meer problemen en verwarring.

Tot slot: vraag je af of alle informatie zich wel leent om toegankelijk gemaakt te worden voor deze specifieke doelgroep:

• Complexe en/of gedetailleerde informatie is niet altijd dusdanig te versimpelen dat het geschikt is voor laaggeletterden. Bijvoorbeeld bij terminologie (“toetsingsinkomen”) die binnen het thema zeer gangbaar is, maar waarvan de conceptuele inhoud veel laaggeletterden ontgaat. Of bij procedures waarin specifieke voorwaardelijkheden een uitkomst bepalen. Dit type informatie is moeilijker in een eenvoudige taal op te schrijven.
• Veel laaggeletterden zijn eraan gewend om voor het regelen van zaken (bv. toeslag aanvragen) te vertrouwen op iemand uit de directe omgeving: een partner, familielid of kennis. Zij hebben angst fouten te maken vanwege mogelijke financiële gevolgen. Het is dus goed mogelijk dat ze er zelf niet eens aan beginnen.
• Een deel van de laaggeletterden heeft al moeite met het formulieren van een probleem/zoekvraag en het vinden/kiezen van een informatiebron. De kans dat deze mensen je website vinden door middel van inhoudelijke zoekacties, is dus misschien niet zo groot.

Download scriptie

Toegankelijke teksten op toeslagen.nl? (PDF)
Onderzoek naar de toepassing van richtlijnen voor eenvoudige communicatie op een overheidswebsite
Kees ter Beek, okt. 2009