Toegankelijk coderen: de WCAG voor developers

Hallo allemaal, goedemiddag, welkom bij de webinar toegankelijk ontwikkelen. en even iets later, er was een probleem met PowerPoint. Maar we beginnen gewoon binnen nu en een minuut of twee. Heel even tot de mensen zijn binnengestroomd en dan gaan we lekker starten. Ik ga jullie alvast goed neerzetten. Als het goed is zien jullie ook nu ook mijn scherm. Dan wacht ik heel even tot we er allemaal zijn en dan gaan we beginnen. Ik geef het nog even drie minuutjes en dan starten we. Ja klopt, er is geen comments veld, alleen Q&A. En dat betekent dus dat ook alleen ik de vraag kan zien. Dat is even een limitatie die we nu hebben,. maar ik lees sowieso altijd alle vragen in zijn volledigheid voor, zodat ze ook mooi in recording komen. Dus maak je je zorgen. Je kan dus niet elkaars commentaar zien, alleen ik kan het zien, maar. je mag erop vertrouwen dat ik netjes alles doorgeef. 5 over 1 gaan we starten. Het is 5 over 1, we gaan beginnen. Welkom allemaal bij de webinar toegankelijk ontwikkelen. De laatste alweer van deze week. Ik heb er deze week vier gegeven. Dus bear with me als ik een beetje. afgeleid of uitgepraat ben inmiddels. Maar we gaan er gewoon een mooi uurtje van maken. Tussen nu en 1 uur gaan we lekker bezig met toegankelijk ontwikkelen. Ik zie een hoop mensen erbij die mij al een keer gezien hebben, maar toch stel ik me altijd eventjes voor. Mijn naam is Joris. De Learning en Development coördinator van Cardan en ik werk nu inmiddels een jaar of twee hier. en ik praat eigenlijk dagelijks over de WCAG en de implementatie daarvan. Dat doe ik met UX designers, content specialisten, PDF makers. Maar vandaag dus ook zeker voor developers. Verder ben ik 29 jaar, woon in Nijmegen. Je kan mijn achtergrond niet zien, maar het is mooi zonnig hier in Nijmegen. En ja, mijn baan bestaat voornamelijk uit het informeren van jan en alleman over de. WCAG en de implementatie ervan, over de wetgeving die er is. En zo reis ik normaliter het hele land door om deze sessies in het echt te doen. ‘in the flesh’ zoals we dat dan zeggen. Maar vandaag dus even digitaal recht in je huiskamer / kantoor. Vandaag over development.. volgens mij development.. ja! Allereerst hoe wil ik dit dit uurtje even structureren? Wat ik eigenlijk weer wil doen is een snippet geven uit de training die we normaliter geven. Maar hou je achterhoofd, deze training duurt normaliter 6 uur, dus dat betekent dat we best wel gaan inkorten. vandaag, want ik ga het allemaal binnen een uurtje proberen te proppen en vandaag dus ook gewoon. wat meer technisch inhoudelijk. Wat ik heb gedaan. Ik heb bijna al m'n slides bij voor die training van 6 uur, maar wat ik doe is. in plaats van dat ik dus door de hele slide ga, voor elke slide een paar voorbeelden ga geven, et cetera... dat ik er nu even één punt uit pik waar ik het over wil hebben, en vervolgens gaan we weer verder. En aan het einde sluit ik ook nog even af met een drietal veelvoorkomende technische fouten. Wel zelf uitgekozen welke technische fouten dat zijn om het een beetje. schappelijk te houden qua tijd, ook vandaag. Maar weet dus dat we daar nog mee eindigen. En dan nog een paar cadeautjes van mij. Als je nu thuis zit en je hebt zoiets van; ik wil heel graag. meer interacteren, maak je geen zorgen, dat kan. In het Q&A veld kan jij mij alle vragen stellen die je wilt. Die lees ik hier dan hardop voor. Om je dan vervolgens ook antwoord te geven. Dat is wel zo fijn. Dus ik wil je zeker uitdagen. Stel lekker al je vragen, nu kan het, nu heb je mij voor je. Ik ken de WCAG zo goed als uit mijn hoofd, dus een mooi moment om gewoon lekker alle vragen te stellen die je hebt. als ze natuurlijk gaan over digitale toegankelijkheid. En met dat gezegd hebbende... trouwens je krijgt ook deze opname. Die wordt gewoon naar iedereen opgestuurd, wanneer we hem digitaal toegankelijk hebben gemaakt. Dat is voornamelijk wat ondertiteling toevoegen, maar weet dus dat je de recording krijgt... de slides niet. Dat is een vraag die ik tot nu toe elke keer heb gekregen. Dus weet dat, maar de slides staat ook vrij weinig op en als ik die weg geef, dan geef ik wel heel veel weg. Dan weet je dat. Dan gaan we starten met development voor vandaag. Allereerst even over de WCAG 2.2, A, dubbel A en de European Accessibility Act. Want dat is natuurlijk waarom veel van ons hier zitten. Ik heb afgelopen week al iets meer uitweiding gedaan over de. wetgeving rondom overheid, maar vandaag dus even iets meer over de European Accessibility Act. Dit is natuurlijk een vereiste, dat moet onder de Wet Digitale Overheid. Natuurlijk ook onder de Nederlandse grondwet. Dat is artikel één, dat is een beetje geparafraseerd. Er staat daar geen discriminatie en dus ook geen discriminatie op grond van handicap of chronische ziekte. Dat is de volledige term die gebruikt wordt. Jammer van het woord handicap, dat gebruiken we niet graag meer. Maar goed, het staat er zo in. Het is immers ook een wat oudere wet natuurlijk; de grondwet. Voor commerciële bedrijven gaan we het hebben over de European Accessibility Act,. oftewel de Europese toegankelijkheids wet,. die is ingegaan op 28 juni 2025 vanuit een VN verdrag. Kort gezegd moeten we daar dus gewoon simpelweg allemaal aan voldoen. En waar moeten we dan aan voldoen? Dat is in dit geval de WCAG 2.2. Web Content Accessibility Guidelines. Dat zijn natuurlijk richtlijnen waarmee bepaald kan worden of een website, app of document. toegankelijk zijn en dus een gelijkwaardige ervaring creëert voor iedereen. Daar gaan we het dus vandaag heel erg over hebben. Hoe kan je er nou voor zorgen dat mensen geen cognitieve inspanning, tijd of hulp hoeven in te leggen. om dezelfde handelingen te doen, die mensen zonder functionele beperkingen kunnen uitvoeren op het web. Dat klinkt heel ingewikkeld, maar dat valt eigenlijk wel mee. Daarvoor heb je eigenlijk alleen maar dit document nodig. Allereerst beginnen we met vier principes.. o, deze is in het Engels, maakt verder niet uit... Vier principes, dat is perceivable, opperable, understandable en robust,. oftewel waarneembaar, bedienbaar, begrijpbaar en robuust. We gaan vandaag extra focussen op robuust. Robuust is iets waar wij als ontwikkelaars veel mee kunnen doen, maar weet dat lijstje bestaat. Wil je nou aan andere mensen. op een korte manier vertellen wat die WCAG inhoudt, dan kun je dus die principes gebruiken. Daaronder vallen de richtlijnen. En die richtlijnen zijn nog steeds super algemeen. Denk aan bijvoorbeeld de richtlijn 1.2 waarin gezegd wordt: die gaat over toetsenbord. Dan kun je een soort extrapolatie maken en dan moet je dus gaan nadenken: Is alles omtrent het toetsenbord waarneembaar? Is alles omtrent het toetsenbord bedienbaar, et cetera. Alleen als je dat doet, dan heb je daar misschien niet genoeg aan. Want hoe zorg je er nou voor,. wat is nou precies belangrijk om waarneembaar te zijn als het gaat om het toetsenbord? Nou, als je dan hebt over een specifieke richtlijn, dan hebben we het dus eigenlijk over de succescriteria. Dat zijn 55 stuks. Als we het hebben over de WCAG 2.2 A en dubbel A. komen dus uit op mooie 55. Daar ga ik zeker niet allemaal doorheen vandaag, daarvoor mag je op een ander moment bij ons aankloppen. Maar ik heb wel de grootste richtlijnen hierin staan. Als je dan bijvoorbeeld hebt over wat moet nou zichtbaar zijn, in het geval van een toetsenbord,. dan heb je het dus bijvoorbeeld over de focus rand die om geactiveerde elementen heen staan. Die moet altijd zichtbaar zijn en ook niet bedekt. Dat even als een soort specifieke richtlijn. Dan kun je dus zelf ook een beetje kiezen hoe je hier over communiceert met mensen,. waar je dus van hoofdtaak naar subcategorie naar echte handvatten slash werkinstructies kan gaan. Ik focus natuurlijk vandaag, zoals je misschien zou verwachten, zeker absoluut op. de handvatten slash werkinstructies, oftewel de succescriteria zelf. Super! Let op dat alleen de WCAG geen mooie toegankelijke website zal maken. Wel toegankelijk in de platte zin, maar. wat je dus zal zien is dat je dan misschien alsnog gewoon een rot ervaring creëert. Er zijn ook zat experimenten op het internet te vinden,. waarin dus gekeken wordt; kunnen wij een website maken die. helemaal aan de WCAG voldoet, maar dan vervolgens echt een zure ervaring voor iedereen oplevert? En ja, je kunt het zien aankomen? Dat kan. Dat is zeker makkelijk,. met als resultaat.. je zal dus altijd bezig moeten zijn, ook met die gebruiker, met gewone user stories. zoals je dat gewend bent, met optimalisaties en de feedback die gebruikers geven. Dat zal altijd een belangrijke rol blijven. We gaan die dus ook absoluut niet negeren, ook niet de gebruikers zonder functiebeperking. De WCAG is een supplementaire. succescriteria set die ervoor zorgt dat je wel kan garanderen dat dus. iedereen een gelijkwaardige ervaring heeft. Maar ook een gelijkwaardige ervaring kan natuurlijk vervelend zijn. Dus ik ga je echt niet vertellen hoe jij je designs moet maken. Hoe jij om moet gaan met jouw werk. Ik ga je alleen een toevoeging geven die er dus voor zorgt dat mensen met een functiebeperking een veel. gelijkwaardiger ervaring hebben en dus veel minder cognitie of tijd moeten inleveren om. dezelfde taken te vervullen die andere gebruikers ook in een relatief korte tijd kunnen vervullen. Hoe lees je die WCAG nou? Zie dit als je technische documentatie. Ik denk dat voor developers specifiek, dat die een selecte groep zijn waarin dus. de WCAG zelf, oftewel het brondocument echt nut kan hebben. Maar zoals je misschien weet, als je in een nieuw framework aan het werk gaat, superleuk! Er zijn weinig mensen die dan de volledige documentatie van het framework een keer doornemen. Dat kan dus lekker doortastend. Maar ik zou het zelf ook als technisch trainer niet aanraden. Wat je natuurlijk doet is die technische documentatie raadplegen op het moment dat je het nodig hebt. Dus ben je bezig met het toetsenbordbediening uitwerken op een user story, pak dan een keer, laten we zeggen.. richtlijn 2.1 erbij; ‘toetsenbord’ en ga dan even kijken wat heb ik hier nou nodig? Neem dat globaal door, de dingen die je nog niet begrijpt kun je wat dieper in gaan lezen. Dus ga zeker niet het hele document doorlezen. Het leest ook zeker niet lekker weg zoals je hier al ziet op het scherm. Tenzij je een keer niet lekker kan slapen, zou ik je zeker niet aanraden om dit van kop tot staart door te lezen. Maar zie dit dus gewoon als technische documentatie die je dus raadpleegt op het moment dat je die nodig hebt. Ik denk wel echt dat dit soms nuttig kan zijn. Dan even over ARIA, ARIA kennen jullie misschien wel. Wat je met ARIA kan doen, is eigenschap toewijzen aan elementen die dus niet standaard zijn. Dit is dus een super handige tool als je werkt met zelf gebouwde componenten, die dus niet in. standaard HTML specificatie zijn opgenomen, om wat voor reden dan ook. Wat dan wel belangrijk is, is om die even te vertalen naar standaard HTML eigenschappen.. die de accessibility API, die weer praat met de assistieve technologie, kan begrijpen. Doe je dat niet, dan wordt dat in het geval van bijvoorbeeld het gebruik van een screenreader, super incoherent. Die weet dan namelijk niet wat een element doet, hoe het element heet en het is dan dus niet. mogelijk voor assistieve technologie om te bepalen of er met bijvoorbeeld elementen geïnteracteert kan worden. Dat is natuurlijk een groot probleem, want je wil natuurlijk wel dat als je je aan die. regels houdt, dat het dan ook wel aankomt bij de gebruiker. Dat zit hem dus heel erg in het stukje robuust. We hebben daar een heel specifiek succescriteria voor en daar kom ik op het einde nog even op terug. Nou, de belangrijkste regel van ARIA is: doe het niet! Dat klinkt misschien als een beetje raar advies, maar in principe in theorie als je een purist bent. is ARIA helemaal niet nodig. Als je jezelf namelijk heel goed aan de HTML specificatie houdt, als je... als je ervoor zorgt dat je geen zelf gebouwde componenten hebt. In theorie is ARIA dan volstrekt niet nodig bij correct gebruik van de HTML specificatie,. het is namelijk helemaal niet per se nodig om heel veel extra moeite te doen voor die digitale toegankelijkheid. Probleem is natuurlijk, en dat weten we denk ik thuis allemaal, dat dat niet de realiteit is. We gaan gewoon met componenten werken die zelf gemaakt zijn, die we geërfd hebben. of gewoon omdat de functionaliteit in de standaard HTML niet zitten die je dus wel wil gebruiken. Dus je zal hier en daar toch ARIA moeten gebruiken. Verkeerd ARIA gebruik is slechter dan helemaal geen ARIA gebruik. Dan kan het namelijk misleidend worden. Dan kan je bijvoorbeeld het idee geven dat iets een bepaalde functionaliteit of naam heeft. die misschien niet correct is. En dan vind ik het dus eigenlijk slechter, als je helemaal niet zegt.. als je gewoon zegt: ‘ja, dit is een element’,. dan dat je zegt: ‘dit is een knop’, terwijl het eigenlijk een heading is. Dat zou je in theorie met ARIA kunnen opleveren, al zou dat natuurlijk niet zo vaak gebeuren. Maar ook ARIA zelf, het W3 instituut zegt: ‘no ARIA is better than bad ARIA’. Dus als je niet weet wat je doet, ga hier alsjeblieft niet mee klieren. Je bent een rund als je met ARIA stunt zeggen we dan altijd, om even terug te gaan naar de. oldskool vuurwerk campagnes. Ben je op zoek naar of er ARIA gebruikt wordt, kan je natuurlijk even zoeken op ‘ARIA’ of ‘Role’. Een goede resource die je hieronder in het scherm ziet staan is de ARIA best practices. Maar je kan ook zeker Googlen op de ARIA patterns. Dat is eigenlijk een soort, daarin heb je een groot scala aan design blauwdrukken. Daar wordt eigenlijk uitgelegd: dit is de correcte manier om op bijvoorbeeld een navigatiemenu ARIA te gebruiken. Dit is de correcte manier om op een combobox ARIA te gebruiken, als je het nodig hebt. Dat soort zaken. Je kan dus inderdaad zeggen goh, als je dus een verkeerde rol ergens toewijst.. dan als resultaat kun je dus je website minder toegankelijk maken. Dus zie dit alsjeblieft niet als een catch all oplossing.. ‘Als ik wat ARIA opgooi dan zijn we digitaal toegankelijk.’. Gebruik je dit namelijk verkeerd, dan stuur je mensen dus nog verder het bos in. Oké, nou, wat ik dus nu ga doen is. even kort door de training heen zoals we die normaliter geven, maar dan echt op een super summiere manier. Ik heb nog 40 minuten om door 6 uur aan content heen te gaan, dus. ik ga ook lekker snel vandaag. Ik denk dat die boost op vrijdag lunchpauze. even gebruikt kan worden. Wat ik doe voor deze training is de thema's die. wij gebruiken om de WCAG uit te leggen, om die aan te houden. In dit geval zijn dat zeven thema's. Ik denk dat dat nuttiger is dan de hele WCAG van A tot Z doorlopen. De succescriteria staan soms namelijk qua ontwikkel en testmethoden niet op de juiste volgorde. Ze springen namelijk een beetje van de hak op de tak. Vandaar dat ik dus mijn eigen groepering heb gemaakt op die succescriteria. Om jullie wat te vertellen over wat er belangrijk is. En ik denk dat dit een logischere indeling is voor educatieve, maar ook voor uitvoerende werkzaamheden. Dit zijn ook de thema's die wij intern gebruiken voor ons interne personeel. Ik begin even met thema 1. Niet mega interessant voor ons ontwikkelaars,. maar we gaan het dus even hebben over geluid en bewegende content. En dan kom je dus vaak uit op video. Hier een een dikke buts aan zaken. Ik zal er hier en daar even een paar uitpikken. Een van de dingen die ik nog steeds heel vaak fout zie gaan, zijn iframes met een missende titel attribuut. De WCAG verplicht ons om webpagina's een unieke en. beschrijvende titel te geven, maar dat doe je natuurlijk in het geval van een HTML documentje,. doe je dat met het titel attribuut en dat kun je dus herkennen, voor de mensen die daar dus niet zo. bekend mee zijn,. aan de naam die je bijvoorbeeld in het browser tabblad te zien krijgt van:, dit is dit tabblad. Ik ben zelf iemand die dus altijd met 300 open tabbladen werkt en. ik vind het dus erg belangrijk om te kunnen weten welke pagina welke zijn, en ook van welke organisatie ze zijn. Dus een goede best practice daarvoor is bijvoorbeeld te zeggen ‘onze diensten’.. en dan een pipe, dus een opstaand streepje, ‘Cardan’. Dit omdat bijvoorbeeld. de pipe eigenlijk nooit voorgelezen wordt. Dus je krijgt dan ook niet dat je hoort; ‘onze diensten min Cardan’. Als je bijvoorbeeld de normale dash gebruikt. Zoals we misschien al weten is een iframe in principe een HTML pagina in een HTML pagina. Dus ook dan geldt: elke HTML pagina moet een unieke en beschrijvende titel hebben. Oftewel een iframe moet verplicht een titel attribuut hebben. Doe je dit niet, moeten we je daar helaas op afkeuren op paginatitel, want een HTML pagina mist een titel. Twee andere zaken die belangrijk zijn: let goed op als bewegende inhoud automatisch start. en parallel wordt gepresenteerd aan andere content, dat je een manier vindt om. die te pauzeren, stoppen of verbergen. Zorg dus dat je of automatisch bewegende inhoud korter houdt dan 5 seconden,. maar laat ook zeker als je dat wel doet... ik vind het sowieso niet altijd de beste. manier om mensen te introduceren op een webpagina met automatisch bewegende content. Doe je het wel, zorg dan dat het korter is dan 5 seconden of dat er een pauze knop aanwezig is. En dit is voor mensen die snel afgeleid raken, die dus oprecht gewoon niet meer verder kunnen lezen. op het moment dat er iets beweegt. Natuurlijk erg vervelend voor hen. Dit geldt dus ook voor audio. Let daar goed op, dan gaat het om 3 seconden. Dit gaat wat minder voor mensen op die snel afgeleid raken. Dit is voor schermlezer gebruikers. Je kan je voorstellen dat als je heel hard audio gaat afspelen op een webpagina,. dat je dan eventueel door een schermlezer heen praat. Doe je dat, dan is iemand vanaf dat moment volledig geblokkeerd,. want die gebruikt natuurlijk die schermlezer in zijn volledigheid om te navigeren. Dat betekent dus dat je ook niet meer kan horen op welk element je staat, waar jd in de pagina bent, et cetera. Dus je bent dan eigenlijk gewoon helemaal uitgespeeld. Doe dit maar gewoon niet, dat is meestal een advies. Het is ook niet meer van deze tijd om automatisch afspelend geluid te gaan afspelen. bij binnenkomst op een webpagina. Even zien, Ik heb nog geen vraag voor jullie ontvangen, dus ik ga gewoon lekker verder. Thema twee gaat over navigatie. Een van de dingen die we vaak fout zien gaan binnen apps. is dat de verschillende weergave modi niet ingewijd worden. Daarmee bedoel ik dus, als jij je telefoon draait is het dus verplicht dat de app meedraait. Let daar op. Dit gaat dus heel vaak fout binnen apps. Ik zie elke week nog tientallen apps die dit dus niet toestaan. Dat is een groot probleem, want als jij bijvoorbeeld verlamd bent en je apparaat gemonteerd hebt op je. rolstoel of iets dergelijks en ik ben niet in staat om die telefoon zelf te draaien. Je telefoon is liggend gemonteerd op jouw rolstoel. Dan is het dus praktisch onmogelijk vanaf dat punt om. de website of de app te gebruiken. Zorg ervoor dat je dat altijd toestaat. Dit gaat dus niet over als iemand zelfs zijn draaifunctie aan heeft staan of niet. Je moet hem gewoon draaibaar maken. Als iemand dat zelf uitzet, dan geen probleem. Ook hier zie je dus weer de unieke en beschrijvende paginatitels. Daar zie je ook even een voorbeeld van die best practices. Verder is een ander probleem wat we nog wel eens zien helaas, is. dat er niet meerdere manieren zijn om naar een webpagina te komen. Dit is erg belangrijk voor mensen die dus alternatieve manieren nodig hebben om te kunnen navigeren. De navigatie methode die natuurlijk altijd gebruikt wordt, is de navigatie via links. Er zijn vrijwel geen websites waarin dit niet gebeurt met wat edge cases hier en daar gelaten. Maar niet voor iedereen is dat fijn. Stel dat je bijvoorbeeld eyetracking gebruikt, of een blaasrietje of iets in die trant,. kan het best wel vervelend zijn om van de ene link naar de andere link naar de volgende link te gaan. en zo eigenlijk vrij langzaam over de pagina of over de website te navigeren. Soms zijn gebruikers ook gewoon op zoek naar iets specifieks. Er zijn zat websites waar gewoon ontzettend veel informatie op te vinden is en een van. de problemen die dan ontstaat is dat het soms best wel lang kost... en dat geldt ook voor mij trouwens om de juiste informatie te vinden. De stelregel onder de WCAG is dat elke pagina op meerdere manieren gevonden moet kunnen worden. Eén manier is natuurlijk de standaard navigatie en dan is er dus nog één extra manier nodig,. om het ‘meerdere manieren’ te maken. Twee dingen die je daarvoor kan doen is bijvoorbeeld een sitemap waar alle links op staan. Dan kun je dus via de sitemap, heel snel naar een specifieke pagina navigeren. Maar de allerbeste manier in mijn persoonlijke mening, is het implementeren van een zoekmachine. Iemand kan dan gewoon zelf met een paar toetsaanslagen de specifieke pagina vinden die ze willen. Ook als ze dus nog niet helemaal zeker weten op welke pagina ze moeten zijn. Het is dan natuurlijk fijn om bijvoorbeeld. de zoekmachine dicht bij de start van de toetsenbord navigatie te houden. Denk aan bijvoorbeeld een navigatiebalk of iets dergelijks. Zorg ook voor consistente identificatie en navigatie. Zorg dus dat items in een menubar altijd op dezelfde consistente volgorde staan. Is het nou bijvoorbeeld niet relevant om naar een specifieke pagina te gaan omdat je daar bent? Of wil je een pagina uit het menu halen? Dat is geen probleem, maar zorg dus dat dezelfde relatieve volgorde aangehouden wordt in navigatie elementen. Voor identificatie hebben we het dan meer over: als je een bepaalde identificatie gebruikt om te zeggen. dit heeft deze functionaliteit, denk aan bijvoorbeeld een icoon of misschien van een persoontje,. dan is het belangrijk dat je dat icoon of dat klikbare element altijd voor dezelfde identificatie gebruikt. Oftewel ga nou niet op meerdere pagina's datzelfde icoon gebruiken waar het op de ene pagina misschien inlog betekent. en op de andere pagina misschien betekent dat je je persoonlijke gegevens gaat aanpassen als je al. ingelogd bent. Dan heb je namelijk hetzelfde icoon dat voor twee verschillende doeleinden gebruikt wordt. En dat is dus geen consistente identificatie van dat element. Soms best belangrijk om dat goed in de smiezen te houden. Even kijken. Ik heb hier een vraagje gekregen. Als je je scherm zelf vast hebt gezet en dus niet meedraait, hoe werkt dat? Dat is een mooie... o, die vraag moet ook weer geschrapt worden. Hier wordt gezegd. Bedoel je met een zoekmachine een vraagteken? Ja, met een zoekmachine bedoel ik dus: zoekfunctionaliteit waarmee je dus de pagina's op de gehele website. kan doorzoeken op de zoekterm die jij hebt gespecificeerd. Meestal zie je dat bijvoorbeeld in de vorm van een vraagtekentje of een zoekbalk boven in het scherm. Iets in die trant. Kleur en tekst. Een van mijn favorieten en dit is een hele specifieke. Een van de dingen die dus hiervoor belangrijk is, is dat je die pagina taal instelt. Dat moet je dus altijd doen. We raden bijvoorbeeld aan om daar de simpelste code te gebruiken die je kan. Bijvoorbeeld lang=”nl”. En niet lang=”nl-NL”. Daarmee suggereer je dus dat het een Nederlandse taal is en geen Vlaamse. Maar het helpt altijd om gewoon zo simpel mogelijk te zijn daar . Die lang elementen zijn belangrijk voor mensen die screenreaders gebruiken,. die meerdere stemmen geïnstalleerd hebben. En ik denk dat we allemaal wel de ervaring kennen van bijvoorbeeld met een TomTom rondrijden. met een Engelse stem die Nederlandse straatnamen probeert uit te spreken,. wat natuurlijk ontzettend incoherent en zo is dus je hele webpagina,. als je dus geen taal wissel aangeeft. Dus zorg ervoor dat er altijd een lang attribuut aanwezig is van de hoofdtaal van de pagina. Verder is het erg belangrijk om informatie niet alleen over te brengen door middel. van kleur en daar zeg ik dan hier specifiek ook bij, ook in formulieren. Want wat er nog wel eens wil gebeuren is dat we bijvoorbeeld de foutmeldingen.. in plaats van een foutmelding, de instructie rood maken, of misschien het invoerveld rood maken. Ik ben zelf rood groen kleurenblind en dit is in sommige situaties gewoon niet detecteerbaar voor mij. Ik denk dan dus bijvoorbeeld dat de verzendknop van het formulier stuk is,. dat ik dus niet daardoorheen kan komen. En dan ga ik dus bijvoorbeeld contact met jullie opnemen,. wat natuurlijk helemaal niet de bedoeling is. Ik heb namelijk zelf gewoon een typefout gemaakt. Zorg dus altijd voor een goede tekstuele foutmelding en eventueel een icoon. En zorg dus dat als je informatie overbrengt door middel van kleur. Denk ook aan bijvoorbeeld de actieve pagina waar je nu bent, in een selectie met meerdere pagina's. Dat die niet alleen door kleur worden overgebracht, maar dus ook door iets als vorm of locatie. Alle inhoud en functies moeten beschikbaar zijn bij een resolutie van. 1280 pixels, bij 1024 pixels op 200 en 400%. En let op dit is mega klein en zorg. ervoor dat je hierop test, dat is mijn voornaamste advies voor jullie,. want dit zijn dusdanig kleine resoluties en zoom niveaus dat je heel weinig horizontale ruimte gaat overhouden. Zorg er dus echt voor dat je website responsief genoeg is om dat aan te kunnen. en ga desnoods ook even mimeren met extra opmaken om ervoor te zorgen dat dus ook. bij die extreme niveaus alle content en functionaliteit beschikbaar is. En dat bij het zoomen naar 400%, dat een horizontale scrollbalk ook niet aanwezig is. Daarmee bedoelen we dus dat je ook nog van links naar rechts moet scrollen. En die ervaring, die herken je vast ook als je bijvoorbeeld op je smartphone probeert een tekst goed te lezen. Als je dan inzoomt, zul je als je pinch to zoom gebruikt, vaak van boven naar beneden moeten scrollen. om de tekst te kunnen lezen,. maar dan ook nog per zin van links naar rechts, om het begin en het einde van de zin te kunnen lezen. Dat is gewoon super zuur voor je tekstbegrip. En zorg er dus voor dat die tekst dan gewoon onder elkaar komt te staan. Een tip die ik eergisteren tijdens mijn UX webinar heb gegeven: je kan ook gewoon beginnen met het kleinste design, als je designed voor een klein scherm, hoef je daarna alleen. nog maar uit te wijden in plaats van in te croppen, wat soms makkelijker maakt om dit soort beproevingen te doorstaan. Hier staat verder ook nog wat over contrast, maar dat is voor ons iets minder relevant Verder gaan we het nu hebben over invoer van de gebruiker. Nou, een aantal dingen die belangrijk zijn is dat je. correct autocomplete gebruikt. Dit is natuurlijk om ervoor te zorgen dat. mensen niet honderdduizend keer hun persoonlijke informatie opnieuw moeten invoeren. Op zich logisch. Wat je vaak ziet is dat er een autocomplete attribuut op input velden is gezet. met bijvoorbeeld autocomplete is true of iets dergelijks of autocomplete is on. Dat is niet goed genoeg. Je moet een specifieke naam of attribuut specificeren in het geval van het gebruik van autocomplete. In de WCAG zit een addendum bij. Dat heeft te maken met autocomplete. Daar staat een lijst in. En die lijst, kun je raadplegen om op te zoeken welke autocomplete attributen je specifiek nodig hebt. Dus er is dus gewoon een hele specifieke lijst gedefinieerd. van gegevens die een autocomplete attribuut behoeven en daar waar het dus verplicht is. Een paar voorbeelden daarvan zijn bijvoorbeeld naam. Hebben we het bijvoorbeeld over voornaam hebben we geloof ik over given name. Veel creditcard informatie is verplicht om een autocomplete te gebruiken. Adresgegevens en dat soort zaken. Let er goed op dat je deze in je invoervelden gebruikt. Vergeet je ze namelijk, dan keuren wij je dus hierop af. Dat zou natuurlijk zonde zijn. Het is echt een kwestie van één of enkele attributen toevoegen aan formulieren. Zorg ook voor zichtbare labels en instructies. Want het is belangrijk natuurlijk dat je altijd een. duidelijk zichtbaar visueel label hebt bij de invoervelden die je in moet vullen. Het is ooit een beetje trendy geweest om daar de placeholder voor te gebruiken, maar die volstaan daar dus niet. Let dus op dat wij placeholder teksten in invoervelden niet als geldige label en of instructie zien. Dat betekent dus: doe je het alleen maar een instructie geven, bijvoorbeeld een format instructie. Denk aan bijvoorbeeld één, twee, drie, spatie a b. Geef je die instructie alleen maar in het postcode veld in de placeholder,. dan zien wij dat dus niet als geldig label of instructie. Dan zou het kunnen zijn dat je afgekeurd wordt op het feit dat er dus geen instructie is voor het postcode veld. Dat is natuurlijk zonde. Verder moeten inputs en labels expliciet aan elkaar gekoppeld zijn. En daarmee bedoel ik dus dat er in het geval van een enkele invoer en een label gebruik moet. worden gemaakt van het for attribuut en een ID attribuut. En in het geval van invoervelden met meerdere opties moet er gebruik gemaakt worden. van een field set en een legend, ofwel een veldenset en legenda. En vergeet dat niet, want dat is een directe afkeuring. Nou, zorg voor duidelijke foutmeldingen. Hier heb ik het van de week al iets meer over gehad. Let er dus op dat je dus geen instructie geeft en niet een.... dat je als foutmelding dus niet de instructie herhaalt. Bijvoorbeeld vul een geldige plaatsnaam in, maar dat je daar dus een duidelijke foutmelding van maakt. en een duidelijke foutmelding bevat altijd in veld de fout is gemaakt en ook dat er een fout is. En dat doen we dus door een negatief woord te plaatsen. Dus in het geval van bijvoorbeeld vul een geldige plaatsnaam als foutmelding te verbeteren,. zou ik bijvoorbeeld er maken: ongeldige plaatsnaam ingevuld, vul een correcte plaatsnaam in. Plaatsnaam is natuurlijk een beetje moeilijk veld, om zo'n foutmelding überhaupt voor te maken. Maar zorg er dus voor dat je dus altijd een negatief woord in foutmeldingen gebruikt. Plus het veld waar de fout is gemaakt. Probeer altijd ook suggesties voor verbeteringen te geven. Dus een mooie combinatie van informatie. Bijvoorbeeld dit verplichte veld is niet ingevuld of is niet correct ingevuld. Vul dit veld in en dan maak je dus een soort combo van hey, je hebt het niet gedaan en doe het. wel want anders dan mag je niet door. Toetsenbord en focus. Zoals je ziet ik skip echt over super veel informatie heen,. maar dan weet je dus, die informatie is beschikbaar maar dan moet je even bij ons in de lucht komen. Terug naar het toetsenbord en de focus. Let erop dat de focus indicator altijd zichtbaar moet zijn en dat betekent dus dat als je met de tabtoets navigeert. Vaak krijg je dan een zwart of een. blauw lijntje om het geselecteerde element heen en die moet dus altijd zichtbaar zijn. Ga die dus niet bedekken met dingen als model pop-ups en dergelijke of lightboxes of hoe je ze ook wil noemen. In ieder geval schermvullende pop-ups. Als je namelijk achter zo'n pop-up kan komen, dan. zul je dus vaak zien dat de focus indicator dan bedekt raakt door deze pop-up. Dit is ook een directe afkeuring hier. Hier staat dus specifiek als je een aangepaste aangepaste indicator gebruikt,. zorg dan dat die ook voldoende contrast heeft tot de achtergrond. Dit als je dus geen aangepaste indicator gebruikt, oftewel gewoon de standaard indicator zo laat,. dan zien we dat als een stukje user agent oftewel daar kan jij als ontwikkelaar helemaal niks aan doen. Dat heeft iemand dan eventueel zelf de controle over dat die welke kleur niet heeft. Goed design voor een aangepaste focus indicator is. eentje met een zwarte buitenrand en een witte binnenrand of vice versa. Als je dat namelijk doet, dan zorg je ervoor dat als je op een donkere achtergrond valt,. het wit voldoende achtergrond heeft. En natuurlijk op een lichte achtergrond altijd de zwarte lijn genoeg contrast heeft. En verder zorg ervoor dat je geen context veranderingen intreedt bij focus. Dat betekent dus dat je niet een pagina wil herladen, de focus wil verplaatsen. of een nieuw tabblad wil openen bij focus. Is natuurlijk een beetje raar, maar dat gaat nog wel eens mis bij radio buttons waarin het. standaard gedrag van een radio button of een checkbox is dat die aangevinkt wordt als je er focus aan geeft. En bij filteropties wil je dus nog wel eens zien dat op het moment dat je dus focus geeft aan een radio button,. dat de optie dan verandert en dat dan de resultaten en de pagina ook herladen. Met als resultaat dat iemand elke keer terug naar boven wordt gezet, als ze dus met toetsenbord bediening op. dat element komen te staan en dat is natuurlijk blokkerend voor iemand. Iemand kan dus nooit meer langs die radio button set gaan,. dus zorg voor dat je nooit een context wijziging intreedt bij focus. Met context veranderingen bedoelen we dus grote wijzigingen voor de semantiek van de pagina. En plat gezegd is dat dus het verplaatsen van de focus, het herladen van de pagina. en het het openen in een nieuw tabblad. Alle functionaliteiten moet dus simpelweg met het toetsenbord bedienen zijn. Oftewel alles wat je met de muis kan moet ook met het toetsenbord kunnen. Lijkt me op zich vrij simpel. Wat ik jullie vooral hierover zou willen meegeven is van zorg dat je dit ook echt test of laat testen. Als je dedicated testers in dienst hebt,. maar zorg er dus echt ervoor dat dit gewoon in de standaard UX of UI testen wordt meegenomen. Dat dus elk element te bedienen is met het toetsenbord en een van de dingen is. rare toetsenbord overvulling. Daarmee bedoel ik een toetsenbord val. Oftewel wat we daarmee bedoelen is dat als je in een element.... Als je met een toetsenbord navigatie in een element kan, dan moet je ook altijd uit het element kunnen. Doe je dat niet, dan zit dus iemand vast en dan zit iemand als het ware voor altijd in dat element. Het enige wat je dan kan doen is de pagina herladen. om weer verder te gaan. En vanaf dat moment is ook proberen altijd te voorkomen dat je ooit nog dat element aanraakt. Op het moment dat je het aanraakt zit je vast. Ik ga even kijken of er nog vragen zijn. Is een skip link verplicht? Ja, een skip link is zeker verplicht. Hoe dat zit? Dat is een succes criterium en dat heet blokken omzeilen. En dat verplicht ons dus om blokken die herhalen op elke pagina, om die te kunnen omzeilen. En met blokken die zich herhalen op elke pagina. Dan zit je al heel snel te denken aan bijvoorbeeld een top navigatie. Een navigatiebalk met selecteerbare secties van de website. Die staat gewoon op alle pagina's en het is natuurlijk vervelend als jij snel aan het navigeren bent. Bijvoorbeeld je gaat van pagina één naar pagina twee naar pagina drie, pagina vier. en het kost je ongeveer dertig tab toetsaanslagen om door het top menu heen te komen. En dan ben je dus 120 tab toetsaanslagen of zo verder voordat je bij de content bent waar je naartoe wil dus. In deze gevallen is een skip link dus 100% verplicht, waarin je. dus over dat hele top menu heen moet kunnen springen. En dat verlaagt het aantal tab toetsaanslagen van 120 naar acht of zo. Op zich best een mooie optimalisatie natuurlijk, dus ja, die is verplicht bij dus blokken die zich. zelf herhalen op alle pagina's van de website. Kan bijvoorbeeld ook een filter optie balk zijn. Mijn advies is wees zeker niet te lichtjes in het gebruiken van die skip link. Wat je bijvoorbeeld zou kunnen doen is direct naar de hoofd content, direct naar de. filteropties, direct naar zoeken en direct naar de footer. En dan heb je een soort van een beetje alle belangrijke schakel punten op de website. of op de pagina uitgelicht. Kan iemand echt met weinig tab aanslagen daar naartoe gaan, dus het is ook gewoon een UX optimalisatie. Maar het is dus ook verplicht bij blokken die dus op meerdere pagina's zichzelf herhalen. Dan even over aanwijzer apparaten. Niet zo heel spannend. Het gros van de WCAG gaat natuurlijk vooral over het stukje toetsenbord navigatie,. omdat we dat vaak vergeten. We testen standaard veel meer met de muis, maar zorg er dus voor dat bij app. bijvoorbeeld multitouch en pad afhankelijke gebaren, dat daar een single touch of pointer vervanging voor is. Denk aan dingen als een swipe. Een swipe moet je natuurlijk op een specifieke manier, een specifiek pad afleggen leggen. Door met je vinger te slepen. Met de muis is dat vaak redelijk goed te doen, maar. als je ook maar iets anders gebruikt dan een muis, dan is dat gelijk onmogelijk. Dus zorg er dan voor dat je bijvoorbeeld lang kan vasthouden en dan extra control kan aanraken. De alternatieven die je dus hebt voor multitouch, bijvoorbeeld pinch to zoom. Dat zijn een enkele tik, dubbele tik en lang vasthouden. Dat zijn een beetje de opties waar je uit mag kiezen om een eenvoudig alternatief te bieden. Let ook op dat je klikbare objecten groot genoeg maakt. Altijd groter dan 24 bij 24 pixels. Dit is mega klein, dus mijn advies zou zijn maak ze dubbel zo groot. Maak ze bijvoorbeeld 48 bij 48 pixels als je echt safe wil spelen. 24 bij 24 vooral op mobiele apparaten veel te klein. Mijn advies is dus ontwerp voor dikke vingers. Even kijken. Hebben we nog meer vragen? Nee. Dan over afbeeldingen, semantiek en dynamische inhoud. Zoals je ziet. Ja, flink lijstje, maar we gaan er gewoon even kort doorheen. Veel van de zaken die we hier zien hebben te maken met succescriteria 1.3.1, info en relaties. Info en relaties verplicht ons om de visuele opmaak gelijk te trekken met de programmatische opmaak. Oftewel hoe zorg je ervoor dat datgene, dus de informatie,. de relaties en de interacties die je kan hebben die visueel zichtbaar zijn, dat die. ook programmatisch zichtbaar zijn? Om een voorbeeld te geven van wat zo'n relatie al kan zijn, is bijvoorbeeld hier op. mijn slide zie je in grotere en dikkere tekst: afbeelding, semantiek en dynamische inhoud. Wat duidelijk is, is dat die grotere dikke tekst hoort bij de bulletpoints die daaronder staan, right? En dat doe je op het web natuurlijk in de vorm van een kop. Nou kan dit wel zo opgemaakt zijn en dan is het visueel inderdaad een kop,. dit werkt voor mijn ogen hartstikke goed. Probleem is alleen is het in de code ook een kop. Is dat niet zo dan zo'n schermlezer deze slide bijvoorbeeld oppakken als gewoon een lange lap tekst. Dan kun je dus veel minder zien; wat hoort nou bij wat. Datzelfde over zoiets als die bulletpoints die we hier op de slide hebben staan. Voor mij is het gelijk duidelijk dat het hier gaat om. een lijst met belangrijke informatie die hoort bij de kop die erboven staat. Nou, visueel dus supersnel duidelijk. Alleen let dus goed op dat in de achtergrond in dit geval een order list is gebruikt in de code. Daar zie je de HTML tags voor op het scherm. Dat is de

voor lijsten met opsommingstekens. Wat we dus nog wel eens zien is dat hier een minnetje en dan een spatie en dan het bullet item is gebruikt. En als dat niet automatisch gecorrigeerd wordt door het CMS systeem wat je gebruikt naar een lijst code. Dan krijg je dus dat mensen een hele lange lijst met minnetjes erin krijgen,. die ook nog uitgesproken worden. Dus dan zou je op deze slide krijgen: min alle img elementen moeten puntje puntje. min het moet mogelijk zijn om blablabla en dat leest natuurlijk helemaal niet. lekker weg en het geeft je ook geen indicatie van hoe lang die lijst gaat zijn. Dus die lijst kan 500 items zijn en jij zal na tien items misschien denken: goh ik snap het wel, maar dan zul je dus toch moeten wachten totdat je. het einde tegenkomt, waarbij het gebruik van de correcte lijst item gewoon. gezegd wordt ‘item 1 van 500’ en dan denk je oh die is misschien een beetje lang. Misschien wil ik niet door die hele lijst heen bijvoorbeeld. Vergeet ook niet dat alle img-elementen verplicht een alt attribuut hebben,. maar het alt attribuut mag wel leeg zijn. Dat alt attribuut leeg laten dat doe je om een decoratieve afbeelding te laten negeren. Dat zie je ook hier in mijn slide. Verder plaats geen lege koppen en doe dat dus ook niet voor dingen als SEO of zo. Ik weet niet waarom je het tegenwoordig nog zou doen, maar we zien het nog wel eens. En zorg dat als je dik- of schuingedrukte teksten wil, dat je daar niet de en. de tags voor gebruikt. Doe je dat wel, dan geef je dus meer nadruk aan een bepaald stuk tekst. Maar als je een hele alinea nadruk geeft, dan heeft die eigenlijk helemaal geen nadruk meer. En let goed op dat er voorheen stemmen waren die dus ook strong en em tags met extra nadruk voorlezen. Je kan je voorstellen dat dat niet de meest schappelijk ervaring biedt voor mensen. die dus een hele alinea met nadruk voorgelezen krijgen. De strong en em tags. gebruik je dus alleen voor één of enkele woorden. Andere opmaak van tekst voor een intro, een. alinea of iets dergelijks raad ik aan om met CSS te doen,. of waar als het echt moet de tag te gebruiken van bold. Zo, even in een half uur door de zeven thema's heen gepraat. Wat mij nog grappig leek om te doen is de drie meest voorkomende... of even een selectie te maken van drie veelvoorkomende fouten die door ontwikkelaars opgelost kunnen worden. en daar ook even bij te vertellen welke tool er is gebruikt om vast te stellen of dit nou fout is gegaan of niet. Nou, dan gaan we het eerst hebben over succescriteria 1.1.1. Succescriterium 1.1.1 heet niet tekstuele content en in niet tekstuele content. wordt gespecificeerd dat alles wat niet tekst is, een tekstueel alternatief moet hebben. Een aantal zaken waarin het net wat anders gaat. In theorie wil je dus gewoon zeggen dit is een stukje niet tekst. Bijvoorbeeld dit is een knop, maar daarvoor moet dus een niet tekstueel alternatief komen. Bijvoorbeeld de knop heet versturen. De visuele tekst op de knop. is het woord versturen en dan is dus belangrijk om dat dan ook als tekst alternatief te gebruiken. In het geval van een knop zal dat waarschijnlijk gewoon uit de knop inhoud komen... de contents en opgepakt worden als toegankelijkheidsnaam. We kennen dit succescriterium. natuurlijk veel meer vanuit afbeeldingen waarin dus een afbeeldingen verplicht een alt tekst moet hebben. Als deze afbeelding informatie met zich meebrengt. Dat is in korte zin wat hier dus vaak fout gaat. Is dat er dus afbeeldingen geen alternatieve tekst hebben die dus wel informatie met zich meedragen. Iets anders dat nog wel eens fout wil gaan is logo's. Daar wil dit nog wel eens fout gaan. Een aantal zaken waar je bij logo's goed aan moet denken is het feit dat iets een logo is ook informatie is. Het zegt bijvoorbeeld iets over de authenticiteit van de webpagina. Heb je het over logo’s, dan zijn ze ook vaak functioneel. Je kan er dus op klikken. Dat betekent dus dat uit de alt tekst ook vaak duidelijk zal moeten worden waar die link naartoe gaat. In het geval van een logo is dat wat minder belangrijk. Kun je er vanuit gaan dat de gebruiker wel weet dat als ze op het logo klikken dat ze dan naar de homepage gaan. En als laatste is het ook belangrijk dat. alle visuele zichtbare tekst in het logo, dat die beschikbaar is in het alternatieve attribuut. Dit zodat mensen met voice control ook op die afbeelding kunnen klikken. Denk bijvoorbeeld dat wij in ons hele logo ‘Cardan, voor iedereen’ hebben staan. Als ik dan de alternatieve tekst van dat logo alleen Cardan maak en ik zeg dan tegen mijn voice control: ‘hey, klik op voor iedereen’ dan zegt voice control. dat bestaat niet, terwijl ik dat toch wel kan waarnemen met mijn ogen. Dus dan is het belangrijk dat je de volledige zichtbare tekst, dus in zo'n geval. ‘Cardan, voor iedereen’ meeneemt met de tekst alternatief. Dan even over de zichtbare focus. Let er goed op dat de focus van elementen altijd zichtbaar is. Dat betekent dus dat een gefocust element. per definitie een duidelijk zichtbare focus rand moet hebben. We hebben hier dus niet... Even voor de duidelijkheid we hebben het hier specifiek niet over contrast. Dat is een ander succes criterium. Maar dit gaat dus echt over. de focus rand die überhaupt zichtbaar is. En het zal je nog steeds verbazen hoe vaak die focus rand niet zichtbaar is op websites. Een voorbeeld dat ik daarvoor kan geven is helaas nog steeds Hema.nl,. waarin dus geen enkele focus rand zichtbaar is. Wat dus als resultaat heeft, dat je als gebruiker zelf moet gaan tellen. Bijvoorbeeld ik wil naar het vijfde menu van het hoofdmenu. Dan moet je dus gaan tellen één, twee, drie, vier vijf keer op tab drukken. en dan hopen dat je als je op enter drukt naar de goede pagina gaat. Je kan je voorstellen hoe ontzettend veel cognitieve inspanning het kost om dan vast te stellen. waar je naar toe gaat. Dus zorg ervoor dat elk interactief element wat je kan selecteren,. dat dat een duidelijke visuele hint geeft dat daar focus is met het dashboard. Dat kan natuurlijk gewoon met de standaard rand,. maar in het geval van een knop die bijvoorbeeld vorm, kleur of whatever,. iets van een interactie laat zien,. een duidelijke visuele hint dus dat er focus op is. Dat mag in principe in dit geval ook gewoon hartstikke prima. Zorgt er dus voor dat menu's kunnen openklappen. Pop-ups, denk aan cookie meldingen, denk aan AI chatbots die je tegenwoordig veel ziet. Zorg er dus voor dat die allemaal niet de focus rand kunnen bedekken, als de focus elders is. In het geval van. pop ups waarin de achtergrond. zwart of grijs of dat rondom transparant wordt gemaakt, zorg voor dat je dan de focus. ook niet uit die pop up kan bewegen, want anders kun je natuurlijk achter die pop up terecht komen. En dan is de focus niet zichtbaar. Hier is dus aan kenmerken is focus gegeven,. maar de enige manier waarop je dat kan herkennen is doordat de tekst van kleur verandert. En dat was dus voor mij niet niet zichtbaar. De tool trouwens die ik hiervoor heb gebruikt is mijn toetsenbord. Je kan gewoon prima gewoon met je normale toetsenbord testen. Je hoeft dus niet allemaal technologie te gaan aanschaffen. En dan nog even 4.1.2: naam, rol, waarde. Dit is het robuust succescriteria zoals ik hem altijd noem. Wat de WCAG ons verplicht, is dat we dus alle informatie die de accessibility API nodig heeft om vast te stellen. wat iets doet,. wat de status van een element is en hoe het uitgesproken moet worden door een screen reader. Dat je al die informatie hebt doorgegeven. Dat betekend dus in simpele zin en hier doen we. soms wel tientallen afkeuringen in een bepaald onderzoek op. In simpele woorden betekent dit succescriterium. dat elk element een toegankelijkheidsnaam heeft,. dat elk element een rol heeft, bijvoorbeeld de rol is button of de rol is heading, noem maar op. En dat sommige elementen ook een waarde hebben. Denk aan bijvoorbeeld of een menu is uitgeklapt of ingeklapt. Denk bijvoorbeeld aan een checkbox of ie aangevinkt is of niet. Denk aan dingen als een progressie balk in een formulieren sequentie bijvoorbeeld. Je bent nu op 50%. Dit zijn allemaal dingen die natuurlijk gewoon voorgelezen moeten kunnen worden door een schermlezer,. maar dan moet je die dus wel meegeven. Het geval van zo'n in en uitgeklapt menu, is dat een mooie plek om aria te gebruiken. Je kan er ARIA expanded voor gebruiken en die zet je dan naar true als hij open is en false als ie gesloten is. Nou ik denk dat ik nog nooit zo'n beknopte beschrijving van 4.1.2 heb gegeven. Dit is nog veel complexer dan dit, maar daar heb ik helaas geen tijd voor vandaag. Wat wel leuk is, is dat Jesse weer een nieuwsbrief heeft geschreven. Onze Cardanner. Die gaat deze keer ook specifiek over robuust programmeren. Super leuk als je die een keer wil lezen. Die vind je bijvoorbeeld op LinkedIn. Die gaat dus specifiek over succescriterium 4.1.2. Dus wil je nog even wat nalezen zo, dan kan dat zeker. Nou dan ben ik weer redelijk aan het einde beland en dan is mijn vraag aan jullie,. hebben jullie vragen voor mij? Ik neem even een slokje water. Ik zie zo niets voorbij komen. Dit was misschien best wel een beetje snel en misschien best wel een beetje een woordenbrij voor jullie. Het is natuurlijk ook vrijdag, het is ook lunch eigenlijk,. Dat snap ik helemaal, maar ik hoop wel dat je in ieder geval iets van een indicatie hebt gekregen. wat we nou precies bij dit soort trainingen behandelen. Hoe deze training er normaliter uit ziet, is dat we eigenlijk 4 uur nemen om al die theorie door te nemen. Daar krijg je ook al het naslagwerk van tevoren en natuurlijk achteraf nog van mij toegestuurd,. dus we kunnen dan veel sneller de diepte in. In de middag bij deze training. Ga ik gewoon echt naast jullie zitten,. kunnen we casussen bekijken, kunnen we kijken welke producten zijn opgeleverd. en kan ik daar jullie dus vanuit deze theorie, die we in de ochtend en een stukje van de middag besproken hebben,. gelijk toepassen om eigenlijk gelijk met oplossingen te komen, ook voor op de lange termijn. Om ervoor te zorgen dat dus je aan de WCAG blijft voldoen. Hier op het scherm nog een lijst met allemaal andere trainingen die we aanbieden. Van bijna al deze trainingen zijn deze week ook webinars geweest. Ik hoop dat je daar ook eventueel bij bent geweest als het je interesseert. Maar weet dus dat je bij ons altijd een aanvraag kan doen om een van deze trainingen te volgen. Vandaag dus een kleine snippet uit de digitale toegankelijkheid voor developers training. Wil je daar nou meer over weten, kun je ons altijd even mailen op bijvoorbeeld joris@cardan.com. trainingen@cardan.com of gewoon info@cardan.com. Kan natuurlijk ook gewoon via onze website makkelijk contact met ons opnemen als dat fijner vindt. Als laatste cadeautjes voor iedereen. Iedereen krijgt onze checklist voor digitaal toegankelijk development toegestuurd. In de bedankmail die je zometeen al van ons krijgt. Je krijgt ook zeker toegang tot deze volledig webinar als die is opgeleverd aan ons. Of als we hem ondertiteld hebben. We moeten nu niet doen alsof we dat niet zelf doen. Weet dus dat je dat je die twee dingen sowieso krijgt. En voor iedereen die vandaag aanwezig of ingeschreven was, kunnen wij wederom. 5% korting op het volgen van deze training aanbieden. Dat is voor de incompany sessies, maar ook zeker voor de open trainingen die we hosten. Heb je nou zoiets van nou, ik ben eigenlijk alleen de enige persoon in mijn bedrijf die. dit wil doen, is het misschien niet helemaal nodig dat ik langs ga komen, maar dan kan je bij ons langskomen. Dan maken wij gewoon klasjes met allemaal mensen om deze training te gaan volgen. Knoop in je hoofd: 5% korting op deze training. Inmiddels is het 1 voor 1. Ik krijg alweer bedankjes in de chat, dus ik ga ook zeker even lekker afsluiten. Ik wens jullie allemaal een super fijn weekend toe. Bedankt dat jullie mij allemaal hebben gesupport en mee hebben gekeken. tijdens de week van de digitale toegankelijkheid. En ik hoop ook dat je in gaat zien dat eigenlijk misschien elke week een beetje. meer de week van de digitale toegankelijkheid is, zodat we een mooier web hebben voor iedereen. Hartstikke bedankt en jullie horen zeker allemaal van ons en een fijn weekend!