Webinar ‘Toe­gan­kelijk­heid en het NL Design System’

Toegankelijkheid en het NL Design System. Daarover ging gespreksleider Peter van Grieken, adviseur digitale toegankelijkheid, in gesprek met 3 gasten aan tafel. Wil je het webinar terugkijken? Of wil je de vragen en antwoorden uit de chat lezen? Je vindt alles op deze pagina. Inclusief de links die in het webinar en in de chat werden gedeeld en de presentaties.

Over de gasten

Rozerin Ayerdem is user experience designer bij de gemeente Den Haag. Den Haag werkt al langer met het NL Design System. Roos vertelde over hoe dat gaat, waar ze tegenaan lopen en hoe ze daarbij rekening houden met toegankelijkheid. Ook gaat ze in op hun service design-traject en de koppeling met het NL Design System.

Jules Ernst houdt zich al meer dan 10 jaar bezig met digitale toegankelijkheid. Vroeger deed hij dit bij de Servicedesk Webrichtlijnen van de overheid; tegenwoordig geeft hij advies en denkt hij mee bij de bouw van toegankelijke websites voor organisaties uit een diversiteit van branches zoals luchtvaart, financiële branche, onderwijs en zorg. Met de wetgeving die ervoor moet zorgen dat mensen met een beperking een gelijke kans krijgen wordt toegankelijkheid op alle fronten belangrijk en is het geen overheidsdingetje meer.

Robbert Broersma is tech lead bij NL Design System.

Gepreksleider en gasten aan tafel

Het NL Design System en toegankelijkheid

Vanuit het NL Design System maken we componenten die aan (WCAG) toegankelijkheidseisen voldoen. Dit garandeert echter niet direct dat producten gemaakt met deze componenten 100% toegankelijk zijn. Bijvoorbeeld het combineren van componenten, het schrijven van tekst en het specificeren van kleuren kan resulteren in een product dat alsnog ontoegankelijk blijkt. Hiertoe herbergt het NL Design System tevens documentatie en ontwerp-patronen die dienen om te helpen met het bouwen van een geheel toegankelijke interface.

Ons white-label voorziet bovendien in standaardinstellingen die bijvoorbeeld een goed kleurcontrast garanderen. Door het toepassen van huisstijlkleuren vervalt echter de garantie dat deze waarden altijd toegankelijk zijn. Huisstijlkleuren en hun toepassing dienen hiertoe zelf een goed kleurencontrast te bevatten. Het white-label kan hiervoor ter informatie en inspiratie dienen.

Handige links

Deze links deelden wij en kijkers in de chat:

Gespreksleider Peter van Grieken

Verslag van de chat

Visual van Rogier Barendregt

Rogier uit het kernteam maakte een samenvatting van de chat, inclusief aanvullingen vanuit NL Design System:

Accessibility overlays

Het concept accessibility overlays kwam een aantal maal aan bod. Deze overlays zijn geen goede manier om een toegankelijk product te maken. Een product dient in de basis toegankelijk te zijn voor iedereen. Momenteel lopen er bijvoorbeeld diverse rechtzaken in de VS van o.a. blinden die ondanks (of juist door) het toevoegen van dit soort overlays producten niet kunnen gebruiken.

Toegankelijk alternatief

Ook het toevoegen van een alternatieve, toegankelijke versie van een product dat bestaat naast het daadwerkelijk (niet-toegankelijke) product is een onjuiste benadering. Buiten het feit dat dit het kernprobleem niet oplost, dient men tevens meerdere producten te onderhouden.

Figma

Voor de ontwerp-componenten in het NL Design System maken we gebruik van Figma.

Momenteel zijn we bezig om onze Figma-workflow te documenteren en te voorzien van links en uitleg van handige (toegankelijkheid) plugins. Het moet echter mogelijk zijn andere ontwerp-programmatuur zoals Adobe XD of Sketch te gebruiken. Het onderhouden van documentatie voor al deze verschillende tooling is echter geen taak van het kernteam. Omdat iedereen aan de documentatie bij kan dragen hopen we dat tips voor andere ontwerp-programmatuur vanuit de community komen.

Onze Figma-componenten zijn pas stabiel als zij alle mogelijke interactie- en feedback-staten bevatten, dus ook focus-staten. Tevens is het denkbaar om dingen als toetsenbord tab-orde in de Figma-componenten te documenteren.

Het testen op toegankelijkheid binnen ontwerp-programmatuur is geen garantie voor een 100% toegankelijk component. Kleurcontrasten, klik-oppervlakte, e.d. kunnen getest worden, maar dingen als screenreader-optimalisatie en logische koptekst volgorde zijn in ontwerp-programmatuur niet te testen. Deze dingen dienen in de ‘handoff’ van ontwerper naar ontwikkelaar duidelijk gedocumenteerd te zijn.

NB. In het NL Design System kunnen we hier op termijn wel templates voor aanbieden.

Jules Ernst, expert op het gebied van toegankelijkheid

Atomic Design

Binnen onze ontwerp- en ontwikkelstrategie past ook het gebruik van het Atomic Design-principe. Dit concept van atomen die samenkomen tot moleculen en op hun beurt weer componenten maken slaat goed aan bij onze design token-benadering. De design tokens (‘sub-atomaire deeltjes’) zorgen er voor dat componenten deelbaar zijn met verschillende organisaties met verschillende huisstijlen en visuele behoeften.

Testen

Omdat we voor het NL Design System mede afhankelijk zijn van het bijdragen door de community willen wij zoveel mogelijk testresultaten meenemen in onze documentatie vanuit de community.

Het documenteren van gebruikerstest-richtlijnen – zoals het vinden van geschikte participanten uit verschillende doelgroepen en met verschillende achtergronden, het afnemen van interviews en dergelijke – staat op de roadmap van het NL Design System. Het is een ieder vrij om hier alvast een aanzet voor te maken en bij te dragen.

Ontwerpers en ontwikkelaars kunnen zelf een begin maken met testen voor toegankelijkheid. Zo kunnen we zorgen dat componenten in de basis in ieder geval toegankelijk zijn. Denk hierbij aan browser-extensies die bijvoorbeeld de onderliggende HTML structuur blootleggen, kleurcontrast meten of door het gebruik van VoiceOver dat standaard in MacOS geleverd wordt.

Ook op front-endniveau kan deels automatisch getest worden op toegankelijkheid. Ook dit garandeert echter niet dat als alle tests succesvol zijn een product automatisch toegankelijk is.

Om 100% toegankelijkheid te garanderen is het altijd nodig om handmatig te testen. En dit uiteraard te doen met vertegenwoordigers van bepaalde doelgroepen, waaronder mensen met een vorm van (kleuren)blindheid, mensen met een motorische beperking, laaggeletterden, e.d.

Wil je zelf ook iets testen met een specifieke doelgroep? Kijk naar ons handige lijstje met overzicht van belangenverenigingen.

Component richtlijnen

Ieder component in het NL Design System moet aan een aantal richtlijnen voldoen, deze checklist aan richtlijnen is als het ware een ‘definition of done’ voor een component. Richtlijnen kunnen verschillen per component-type maar herbergen voor de meeste toegankelijkheidsrichtlijnen; waar moet een component aan voldoen om toegankelijk te zijn.

Robbert Broersma van NL Design System

Dark mode

Het maken van dark mode-thema’s (en het garanderen van een juist contrast hierbinnen) staat bij ons op de radar, maar we zijn hier nog niet aan toegekomen. Het gebruiken van design tokens voor visuele styling leggen echter al een goede basis om dark mode-thema’s te maken.

Specifieke tooling

Meerdere vragen gingen over specifieke (WordPress/Drupal) tooling. Vanuit het NL Design System doen we echter geen aannames over welke (CMS) software gebruikt dient te worden.

Vragen en antwoorden uit de chat

Veel kijkersvragen zijn door de sprekers in het webinar beantwoord, maar in de chat werden ook veel vragen van kijkers door andere kijkers beantwoord. Die hebben we voor je op een rijtje gezet. Lees ook hierboven het verslag van Rogier, daarin is ook een aantal vragen en antwoorden verwerkt.

Hoe ver gaan jullie in het toepassen van genoeg contrast? Ik kom bijvoorbeeld heel veel logo’s en kleurpaletten tegen die niet door de contrastchecker komen. Die kleuren meer contrast geven werkt wel, maar daardoor gaat het wel afwijken van de identiteit van de organisatie.

Ik gebruik de kleuren als inspiratie, maar gebruik ze nooit 1-op-1 als het niet voldoet aan de contrastwaardes.

Sowieso de huisstijlbewakers binnen de organisatie op de hoogte brengen, want op langere termijn moet de identiteit worden aangepast.

Er zijn in Nederland een aantal goede voorbeelden van hele grote organisaties die hun kleuren hebben aangepast (bijvoorbeeld die grote bank die veel oranje gebruikt), ter inspiratie.

Monochromatische schaal gebruiken van de huisstijlkleuren.

In principe hoeven logo’s niet aan contrasteisen te voldoen.

Logo’s zijn uitgezonderd van de contrast-eis. Net zoals onderdelen die puur decoratief zijn. Of onzichtbare plaatjes. Ook tekst in foto’s waarvan de inhoud niet relevant is hoeft niet te voldoen.

Rozerin Ayerdem van de gemeente Den Haag

Voor hoeveel procent kunnen accessibility plugins via Sketch bijvoorbeeld toegankelijkheid garanderen?

Voor enkele WCAG-criteria 100%. Maar het grootste deel van toegankelijkheidsproblemen kan niet automatisch met plugins worden gevonden/gecontroleerd.

Goed voorbeeld is kleurcontrast; dat kun je berekenen, en dus eenduidig van zeggen of het goed is of niet.

Accessibility plugins in Sketch is in ieder geval al een goed begin voor dingen als genoeg kleurcontrast. Bij de handoff naar developers blijven er echter natuurlijk veel dingen liggen waar ontwerpers zich ook over zouden moeten buigen; zoals toetsenbord navigatie, ontwerpen ook voor screenreader gebruikers toegankelijk maken, etc.

Heeft iemand ervaring met toegankelijk maken van QR code?

De url apart bij QR-code neerzetten.

WCAG 2.2 EN 3.0 komt eraan. Vanuit de wet moeten we voldoen aan WCAG 2.1 AA, maar voor hoe lang? Moeten we ons alvast voorbereiden voor de nieuwe varianten?

Voorbereiden kan. Bestudeer alvast de vereisten. WCAG 2.2 staat nu in het 2e deel van dit jaar gepland. WCAG 3.0 zal nog enige jaren op zich laten wachten. Deze versies zijn wel nog steeds aan wijzigingen onderhevig; nog niet alle documentatie is compleet. Bij WCAG 2.1 bijvoorbeeld is vlak voordat het de nieuwe standaard werd één succes-criterum geschrapt.

Zie je ook veel problemen met SPA’s (single page apps)? Ik vind het moeilijk om te bepalen wanneer een update in de pagina moet worden aangekondigd naar de screenreader met bijvoorbeeld aria-live regions.

Ja, alles wat standaard in de browser is gebakken moet je nu zelf opnieuw bouwen. Je ziet gelukkig wel vooruitgang bij JavaScript-frameworks. Maar ook voor onderzoekers zijn SPA’s lastig. Soms gaan dingen goed, maar als je in de code kijkt begrijp je niet hoe dat gelukt is.

Even terug naar het doel van NL Design System: een bibliotheek met gecertificeerde GUI-componenten waar je als ontwikkelaar gebruik van mag maken. Als men hier consequent gebruik van maakt, dan zijn een aantal toegankelijkheidseisen toch al ingevuld door de componenten zelf?

Ja, componenten zouden in de kern toegankelijk moeten zijn, anders krijgen ze niet het predikaat ‘volwassen component’. In het aan elkaar maken van componenten tot een interface kan er echter nog veel mis gaan qua a11y.
Dus het is een basis om toegankelijk te bouwen, maar geen garantie, dat hangt af van de uiteindelijke implementatie.

Peter in gesprek met Robbert

Vraagje over contrast licht op donker. Ericka Seastrand heeft onderzocht dat licht op donker veel minder contrast nodig heeft dan andersom en een ‘lager contrast’ zelfs fijner kan zijn. Hoe ga je daarmee om in de beoordeling?

WCAG 3.0 kijkt om die reden naar een alternatief (maar tot en met WCAG 2.1 wordt daar dus geen rekening mee gehouden). Nu is het een arbitraire waarde terwijl het contrast soms prima zichtbaar is, maar het onder de drempelwaarde ligt.

Voor dark mode en light mode zul je beide aan de contrastvereisten moeten voldoen. Bij apps heeft ongeveer 1 op de 4 mensen dit aan staan. Best wel duidelijke cijfers als 1 op de 4 dat als voorkeur heeft. Dark mode is geen vereiste uit de richtlijn, maar wel aan te bevelen uit user experience.

Witte tekst met een contrastwaarde van 3.3 is fijner dan zwart met een contrastwaarde van 6.4 bijvoorbeeld.

Het wordt inderdaad aangeraden om in dark mode niet 100% zwart en 100% wit te gebruiken maar daar iets van af te zitten. Vooral mensen met astigmatisme kunnen daar last van hebben.

Mensen met astigmatisme bijvoorbeeld. Daarbij heeft wit-op-zwart een veel groter kans om bijvoorbeeld te ghosten. Maar WCAG heeft hier inderdaad geen voorziening voor.

Ja, de formule voor contrastwaarden in WCAG 2.x houdt met dat soort dingen te weinig rekening.

Hele goede vraag. Er komt een vernieuwde meetmethode die uitgaat van de perceptuele contrast. Deze meetmethode is nog in ontwikkeling en wordt meegenomen in WCAG 3.0. Ik heb wel al de vraag voorgelegd of deze methode in de eerstvolgende versie mee zou kunnen komen, bijvoorbeeld WCAG 2.3 (als die er komt).
Ik ben er wel blij mee, want dan hoef ik eindelijk niet meer uit te leggen dat wit op oranje onvoldoende is ofschoon tweederde van de mensen dit prettiger vinden dan zwart op oranje.

Hebben gemeenten hier samengewerkt met groepen gebruikers met beperking(en) om te testen?

Wij hebben laatst getest met (ex-)laaggeletterden en blinden en slechtzienden.

Niet met groepen, we hebben wel iemand in gemeente (Leusden) met wie wij de website een keer hebben doorgenomen. Is eigenlijk iets dat structureel moet gebeuren, ook voor bijvoorbeeld formulieren.

NL Design System, leggen jullie dus ook kennis vast in de documentatie?

Ja, een groot onderdeel van het NL Design System bestaat uit documentatie voor toegankelijkheid, taalgebruik, formulieren, etc.

Peter in geprek met Rozerin

NL Design System, hoe testen jullie de toegankelijkheid van de componenten na het ontwikkelen?

We hebben een checklist met verschillende eisen waar een component aan moet voldoen voordat het component een ‘1.0’ status krijgt. Afhankelijk van een component zijn dit verschillende richtlijnen. Een interactief component heeft andere eisen dan bv. een koptekst component.

Er zijn op dit moment nog geen componenten in het stadium om naar 1.0 te gaan, dus testen komt er voor ons nog aan.

De componenten die nu ontwikkeld worden door Den Haag en Utrecht worden daar gebouwd met feedback van gebruikers. Deze feedback wordt opgenomen als documentatie in het NL Design System en zodra een component volwassen genoeg wordt om ‘stabiel’ in het NL Design System opgenomen te worden gaan we deze test nog een keer doen én gaan we kijken of er automatische tests mogelijk zijn.

NL Design System, jullie doen geen gebruikersacceptatie-tests met eventuele doelgroepen?

We doen vanuit het kernteam inderdaad nog geen gebruikersacceptatie tests met doelgroepen. Dit komt mede doordat componenten aangedragen worden door partijen aangesloten bij het NL Design System en wij niet zelf alle componenten maken.

Hoe automatiseer je accessibility-testen in Figma?

In Figma kun je met de plugin Stark kleurcontrast checken. Deze heeft ook filters voor kleurenblindheid.

Help ons te verbeteren

Wat vond je van het webinar? Je helpt ons de volgende webinars te verbeteren door deze 3 vragen te beantwoorden.

Hoort bij het thema