Nieuws

Actieve projecten

Laatst bijgewerkt op 31 oktober 2026

In uitvoering

v3: Een complete QA-suite

27 september 2026

Onthulling op DrupalCon Europe 2026

Belangrijkste nieuwe functies

• Testkern samengevoegd met Sa11y. De nieuwe, gezamenlijk ontwikkelde regelset voegt ontwikkelaarstests, contrastcontrole en leesbaarheidsscores toe aan de kernset met inhoudstests.
• Ondersteuning voor meerdere talen
• Bouwer voor aangepaste controles
• Dashboardonderhoudtools
• Een tool voor het crawlen van de site om nieuwe resultaten toe te voegen.
• Maakt het voor bepaalde rollen mogelijk om meldingen van bepaalde tests (is deze PDF toegankelijk?) sitebreed af te wijzen.
• Gesplitste configuratie: rolgebaseerde tests en rapportweergaven, gescheiden voor ontwikkelaars en inhoudsauteurs.

En misschien wel het belangrijkste voor de toekomst van het project:

• Een subsidie binnengehaald om deze sponsororganisatie op te richten, bestaande gebruikers te ondersteunen en werk aan toekomstige projectideeën te financieren.

v2: Afwijzingen & rapporten

2 maart 2023

Twee jaar geleden introduceerden we de Editoria11y-toegankelijkheidschecker als kant-en-klare siteplugin voor Drupal, die auteurs automatisch en direct feedback zou geven, met handige tips om hun inhoud te verbeteren.

We dachten hiermee in een onvervulde behoefte te voorzien. De bestaande opties vereisten allemaal training en consequent gebruik om nuttig te zijn, en de ervaring had ons geleerd dat het trainen en monitoren van duizenden inhoudsauteurs in een grote organisatie geen efficiënte manier was om het probleem aan te pakken. We waren ervan overtuigd dat een programma alleen kon slagen met een hoge mate van automatisering: beleefde “just-in-time training” voor inhoudsauteurs zodra het veelgemaakte fouten ontdekte.

Het werkte.

Bij Princeton keerde het de richting van mijn communicatie grotendeels om. Op platforms waar het was geïnstalleerd, gingen we van het versturen van steeds dezelfde e-mails aan inhoudsauteurs met het verzoek om alt-tekst, koppelingen of koppen te verbeteren, naar het ontvangen van vragen van inhoudsauteurs over hoe ze beter konden schrijven om niet meer zo vaak gemarkeerd te worden.

Buiten Princeton was de reactie euforisch:

Op zichzelf staande tips schrijven

Bij de tips van v1 kozen we voor een “samenvatting en details”-aanpak: een korte uitleg van het probleem en een koppeling naar meer details.

Dat was een verbetering ten opzichte van tools voor ontwikkelaars: de tips waren kort en duidelijk. Maar waarheen we moesten linken, bleef altijd een probleem. Diverse gebruikers bij de overheid en in het hoger onderwijs vonden het nodig de tips aan te passen om koppelingen naar de documentatie van Princeton te verwijderen, wat hun extra werk opleverde. Daarom hebben we de standaardtips herschreven tot op zichzelf staande teksten, met voorbeelden in de tekst zelf.

Het onderscheid tussen rode meldingen (zekere problemen) en gele waarschuwingen (mogelijke problemen) bleek verwarrend en soms irritant.

Daarom hebben we gele waarschuwingen omgezet in “handmatige controles” om hun betekenis te verduidelijken, en knoppen toegevoegd waarmee auteurs meldingen kunnen afwijzen. “Genegeerde” meldingen worden alleen verborgen voor degene die erop klikt; meldingen die “als OK gemarkeerd” zijn, worden verborgen voor alle redacteuren van de site. Sitebeheerders bepalen wie welke actie mag uitvoeren.

Een dashboard maken

Een veelgehoorde klacht van site-eigenaren was dat de tool uitstekend problemen op de hele site vond, maar dat er geen manier was om een sitebreed rapport te bekijken.

De herschreven versie biedt de optie om bevindingen terug te synchroniseren naar de database van de site. Site-eigenaren kunnen nu bevindingen per pagina of per probleem doorbladeren en bekijken welke problemen zijn genegeerd of als OK gemarkeerd – en het probleem herstellen als ze het er niet mee eens zijn!

Rondleiding door de v2-code voor ontwikkelaars

V2 was bijna een volledige herschrijving. Enkele van de nieuwe functies:

• Doordat de afhankelijkheid van jQuery is verwijderd, kan de checker op meer platforms worden geïnstalleerd en is hij twee keer zo snel.
• De checker kan nu worden ingesteld om in meerdere onafhankelijke delen van de pagina te kijken (bijvoorbeeld de artikelinhoud en de paginafooter).
• De checker kan nu elementen testen in de shadow DOM, die door diverse webcomponenten en JavaScript-bibliotheken wordt gebruikt.
• Dankzij veel nieuwe parameters worden platformintegraties eenvoudiger, bijvoorbeeld door alle problemen op bepaalde pagina's automatisch te negeren voor gebruikers die niet verantwoordelijk zijn voor de inhoud van die pagina, maar de resultaten wel op verzoek willen kunnen bekijken.
• De checker wordt nu geleverd met meerdere basisthema's en parameters om kleuren aan te passen.
• Geautomatiseerde tests helpen coderegressies te voorkomen.

A11yTalks 2024

11 juni 2024

Drupal GovCon 2023

27 oktober 2023

DrupalCamp NJ 2023

28 maart 2023

v1: Inline hulp

11 maart 2021

Zeer toegankelijke webinhoud maken is ingewikkeld en begint meestal met veel training.

Vertrouwde gewoonten moeten worden ontmoedigd:

• Tabellen mogen niet worden gebruikt om nepkolommen te maken
• Doorlopende tekst mag niet gecentreerd of uitgevuld zijn
• Puur visuele opmaak (letterdikte en -grootte) mag niet de enige manier zijn om betekenis over te brengen aan gebruikers, die de inhoud misschien beluisteren of bekijken in de “leesmodus”

Nieuwe gewoonten moeten worden aangemoedigd:

• Afbeeldingen hebben alternatieve tekst nodig die betekenisvol is binnen de context
• Pagina's hebben een echte structuur nodig
• Koppelingen moeten betekenisvolle titels hebben

Sommige van onze trainingen bestaan natuurlijk omdat we nieuwe concepten aanleren, maar op een gegeven moment moet de vraag worden gesteld: hoeveel van de behoefte aan nieuwe vaardigheden komt doordat de concepten nieuw zijn, en hoeveel doordat wij nieuwe verwachtingen invoeren zonder onze tools bij te werken? Dat iets nieuw is, betekent niet dat het niet intuïtief kan zijn.

Lessen uit de geschiedenis van de spelling

Fase 1: Geef de auteur de schuld

Vanaf het begin van de geschreven geschiedenis tot begin jaren 80 gaven we de auteur de schuld als die een woord verkeerd spelde. Het was de verantwoordelijkheid van de auteur om goed te leren spellen.

Hoe werd iemand beter in spelling? Dit zal bekend klinken:

1. Ze volgden trainingen, bij een privéleraar of in een klaslokaal
2. Ze kregen lijsten, richtlijnen en woordenboeken om te bestuderen, een traditie die teruggaat tot oude spijkerschriftlexicons die in klei waren gegrift.

Fase 2: Geef het woordenboek de schuld

Maar in de jaren 80 veranderde er iets: laten we het “spellingfase 2” noemen. De populairste tekstverwerkers kregen een spellingcontrole.

En wat gebeurde er met het zwartepieten? Vrijwel van de ene op de andere dag verschoof de schuld naar de tool:

• Weet je niet hoe je een woord spelt? Doe een gok en hoop op een treffer. Geen treffer? Geef het woordenboek de schuld.
• Gebruik je een bestaand woord dat het woordenboek markeert omdat het dat niet kent? Mopper even en besluit of je de onderstreping negeert of met de rechtermuisknop klikt om het woord aan het woordenboek toe te voegen.

Heeft spellingcontrole al onze spelfouten opgelost? Zeker niet. Maar het hielp. En het verschoof een groot deel van de last en verantwoordelijkheid van de auteur naar de machine.

Maar daarmee was het nog niet afgelopen…

Fase 3: Geef de schrijftool de schuld

De afgelopen jaren is er nog een stap gezet: computers zijn voor ons gaan spellen:

• Voorspellende algoritmen proberen het volgende woord, de volgende zin, misschien zelfs een heel antwoord op een sms te raden.
• Tools voor automatische opmaak proberen sterretjes, cijfers en letters om te zetten in lijsten, shortcodes in speciale tekens en emoji, enzovoort.
• Dicteertools proberen concepten te herkennen om te kiezen tussen homoniemen.

En wie krijgt de schuld als het misgaat? De tool!

Socialemedia-aggregators zijn dol op de gênante “Zo bedoelde ik het niet!”-screenshot.

Editoria11y is een stap richting fase 2

In onze trainingen praten we veel over testen en introduceren we verschillende behoorlijk goede testtools. Geen daarvan vangt alles: zaken als “vermijd het uitleggen van concepten via verwijzingen naar kleur of ruimtelijke positie” moeten door een mens worden gecontroleerd; tools vinden doorgaans net iets minder dan de helft van de werkelijke problemen die een site kan hebben. Maar de tools zijn heel goed in het opsporen van veelgemaakte fouten in redactionele inhoud.

Alleen zijn er drie problemen:

1. De meeste zijn handmatige tools. De inhoudsmaker moet geleerd hebben ze te gebruiken, moet tijdens het schrijven onthouden dat ze bestaan en moet eraan denken ze na afloop uit te voeren. Die drie faalpunten spannen samen om veel (de meeste?) inhoud ongecontroleerd te laten.
2. Ze markeren te veel. Ze markeren niet alleen fouten die de auteur zojuist heeft gemaakt, maar ook kleurproblemen van de ontwerper, technische problemen van de ontwikkelaar, structuurelementen ter informatie, enzovoort. Dat legt de lat voor trainingen hoger: auteurs moeten niet alleen de tool begrijpen, ze moeten ook leren een lijst te negeren met fout-positieven of heel reële zaken die vandaag, bij het schrijven van dit specifieke artikel, niet hun verantwoordelijkheid zijn om op te lossen.
3. De geautomatiseerde tools werken meestal volgens het paradigma “crawl de site, bezoek het dashboard”. Nogmaals: dit veronderstelt dat een auteur is getraind om het dashboard te bezoeken en daar ook aan zal denken.

Dus ging Princeton iets nieuws maken: een in de website geïntegreerde, automatische checker die alleen naar veelgemaakte redactionele fouten zou kijken.

Automatisch is…lastig.

1. Automatische checkers moeten subtiel zijn: zijn ze te opdringerig, dan onderbreken en frustreren ze de auteur. Zijn ze te beleefd, dan worden ze al snel achtergrondruis die iedereen negeert.
2. Automatische checkers moeten zeer goed presteren: als de pagina hapert of aarzelt terwijl ze draaien, krijgen auteurs een hekel aan ze en schakelen ze ze uit.
3. Automatische checkers hebben tips nodig die beginners begrijpen. Voor veel auteurs is dit de eerste keer dat ze horen over de tagging, structuur en taal die hun inhoud toegankelijker maken. Meldingen moeten in eenvoudige, niet-technische taal zijn geschreven, met praktisch advies om de inhoud te verbeteren.

Dus begonnen we met de tool die het dichtst bij deze doelen kwam: Sa11y, van de Toronto Metropolitan University. We namen de testarchitectuur en de gebruiksvriendelijke aanpak met een informatiepaneel en tooltips over, en besteedden een halfjaar aan het aanpassen van de tool: tests draaiden voortaan altijd automatisch, we optimaliseerden de prestaties, schaafden aan de tooltips en maakten een lange lijst configuratieopties waarmee een ontwikkelaar de tool snel aan elk platform kan aanpassen.

Zo ziet het er vandaag uit:

Wanneer een auteur is ingelogd op de site, geeft de schakelaar van Editoria11y op elke pagina het aantal en het type problemen aan (geslaagd, handmatige controles nodig, waarschijnlijke problemen gevonden). Met een klik worden markeringen en tips in de tekst zichtbaar. Is de fout nieuw, omdat de auteur een pagina bekijkt die net is bewerkt, dan springt het paneel automatisch open.

Sinds maart 2021 betekent dit dat meer dan 400 websites van Princeton automatisch controleren op:

• Een goede documentstructuur
  • Overgeslagen kopniveaus
  • Lege koppen
  • Zeer lange koppen
  • Verdacht korte blokcitaten die eigenlijk koppen kunnen zijn.
• Tekstalternatieven
  • Afbeeldingen zonder alt-tekst
  • Afbeeldingen met een bestandsnaam als alt-tekst
  • Afbeeldingen met zeer lange alt-tekst
  • Alt-tekst met overbodige woorden als “afbeelding van” of “foto van”
  • Afbeeldingen in koppelingen waarvan de alt-tekst de afbeelding lijkt te beschrijven in plaats van de bestemming van de koppeling
  • Ingesloten visualisaties die meestal een tekstalternatief nodig hebben
• Betekenisvolle koppelingen
  • Koppelingen zonder tekst
  • Koppelingen met een bestandsnaam als titel
  • Koppelingen met alleen generieke tekst als titel: “klik hier”, “lees meer”, “downloaden”, enzovoort.
  • Koppelingen die in een nieuw venster openen zonder pictogram voor externe koppeling
• Algemene kwaliteitsborging
  • Controleren of lijstopmaak wordt gebruikt in plaats van sterretjes, cijfers en letters
  • GROTE HOEVEELHEDEN TEKST IN HOOFDLETTERS
  • Tabellen zonder koppen en tabellen met documentkoppen (“Kop 3”) in plaats van tabelkoppen (<th>)
  • Koppelingen naar PDF's en andere documenten, met een herinnering om de download op toegankelijkheid te testen of een alternatief, toegankelijk formaat aan te bieden
  • Ingesloten video's, met een herinnering om ondertitels toe te voegen
  • Ingesloten audio, met een herinnering om een transcript aan te bieden
  • Ingesloten sociale media, met een herinnering om alt-elementen toe te voegen

We hebben de JavaScript-bibliotheek vrijgegeven aan de gemeenschap, een kant-en-klare Drupal-integratie gemaakt en zijn begonnen aan een kant-en-klare WordPress-integratie.

Op weg naar fase 3: standaard toegankelijk

In veel opzichten is Editoria11y een noodoplossing. De meeste fouten die het opspoort, ontstonden doordat we nieuwe verwachtingen bij inhoudsauteurs legden (“geef je inhoud een goede structuur”), maar hun tools gaven die het tegenovergestelde aanmoedigden.

De weg vooruit is om het maken van toegankelijke inhoud eenvoudiger en zo automatisch mogelijk te maken. Hoe dat eruitziet, is nog niet duidelijk, maar waarschijnlijk horen daar zaken bij als:

• Heroverwegen welke opties beschikbaar zijn. Bijvoorbeeld: als we gebruikers blijven vertellen dat ze tekst op het web niet moeten uitvullen, is het dan niet tijd om die knop “tekst uitvullen” met pensioen te sturen?
• De standaardopties heroverwegen. Bijvoorbeeld: de standaardtabel in de meeste contentmanagementsystemen heeft geen koppen. Het is aan de gebruiker om te weten dat die op “eigenschappen” moet klikken en toegankelijkheidsfuncties moet toevoegen; misschien is het tijd om dat om te draaien?
• Nadenken over voorspellende opmaak en “hints terwijl je werkt”. Als een gebruiker een hele regel vet maakt, kunnen we dan voorstellen er een kop van te maken? Als een gebruiker een kop wil selecteren, kunnen we dan raden welke kopniveaus gewenst zijn, in plaats van zes opties te geven? Kunnen we just-in-time training geven voor moeilijke concepten?