Drupal heeft een goede reputatie op het gebied van gebruiksvriendelijkheid en toegankelijkheid. In deze serie van zes blogs kijken we naar hoe Drupal het doet en waar nog verbeterpunten liggen. Na deel 5 over afbeeldingen, kijken we in dit laatste deel naar de ondersteuning voor redacteuren. Hoe helpt Drupal de redactie zodat zij toegankelijke inhoud kunnen toevoegen die voldoet aan de WCAG 2.1, niveau AA. We gaan kijken wat Drupal hiervoor aanbiedt.
Dit is het zesde deel, uit een serie van zes.
Out-of-the-box doet Drupal het heel aardig qua toegankelijkheid, zie de vorige vijf delen van deze serie. De HTML-code die het genereert voldoet aan de standaard en meestal ook aan de WCAG. Een van de voordelen van het gebruik van Drupal is dat het heel goed is in het indelen van verschillende soorten inhoud in specifieke velden. Hierdoor kan de ontwikkelaar zorgen dat die op de juiste (WCAG-complient) manier worden weergegeven.
Maar dat is niet genoeg. Een belangrijke verantwoordelijkheid voor het voldoen aan de WCAG ligt immers bij de redactie. Zij zal in een WYSIWYG-veld onder meer moeten zorgen voor een juiste koppenstructuur en het toevoegen van relevante alternatieve teksten bij afbeeldingen. Doet Drupal iets om ze hierbij te assisteren?
Drupal core levert hiervoor alleen wat basale ondersteuning. Er standaard geen <h1> worden toegevoegd en ook is eenvoudig in te stellen wat de maximale diepte van de structuur mag zijn. Maar verder geeft het geen aanwijzingen voor een toegankelijke hiërarchie van de koppen.
Bij afbeeldingen is er ondersteuning voor de redactie, in die zin dat de redactie bij het invoegen van een afbeelding kan aangegeven of deze decoratief is of niet. In dat laatste geval zal het een leeg alt-attribuut toevoegen aan het img-element in de HTML.
Zoals in deel 5 over afbeeldingen is aangegeven kun je de alternatieve tekst overschrijven als je gebruikmaakt van de mediabibliotheek.
Drupal biedt gelukkig de mogelijkheid om het aantal functies in de knoppenbalk van de editor te beperken. Om de redactie te ondersteunen is het zeer aan te bevelen om goed na te denken welke functies nodig zijn en welke overbodig. Die laatste zullen altijd in de weg zitten van een handige workflow. Als de redactie niet de mogelijkheid heeft om zelf de kleur van de letters te kunnen kiezen kan die geen keuzemaken waarbij het contrast voor de WCAG niet voldoende is.
Standaard biedt Drupal een drietal opmaakprofielen met beperkte functionaliteit. Diet biedt de redactie ondesteuning. Deze profielen zijn door een sitebouwer eenvoudig aan te passen of toe te voegen.
Het bovenstaande is een goede stap in de richting. Je kunt je afvragen of het tot in detail ondersteunen van een redacteur in Drupal core moet worden opgenomen. Er zijn modules die die taak op zich kunnen nemen.
Als er inhoud is toegevoegd kan deze module aanwijzingen geven of dit volgens de WCAG-richtlijnen correct is gedaan. Dit geeft de mdoule per item aan. Een van de sterke punten van Editoria11y is dat het hierbij uitleg geeft waarom het niet goed is en hoe je dit kunt aanpassen.
Dit is een fraaie oplossing die we heel erg kunnen aanbevelen, maar werkt alleen als inhoud al is ingevoerd. Een uitbreiding om de redacteur te ondersteunen tijdens het invoeren van inhoud is er voor Drupal niet, zoals die er voor WordPress met behulp van de AWP-plugin voor Gutenberg wel is.
Vanuit core is er beperkte ondersteuning voor de redactie tijdens het invoeren van inhoud. Voor sitebouwers zijn er mogelijkheden om de functies in een WYSIWYG-veld te beperken en voor afbeeldingen zijn er opties om aan te geven of deze decoratief zijn of niet. Maar expliciete ondersteuning voor redacties is beperkt.
Wel zijn er modules die achteraf kunnen controleren of inhoud toegankelijk en volgende de WCAG-richtlijnen is ingevoerd. Editoria11y is daar een uitstekend voorbeeld van.
Neem contact op en laat een volledige audit uitvoeren. Samen kijken we hoe we dit voor jouw specifieke implementatie op kunnen lossen.
