Audit digitale toegankelijkheid van website archeologie.zuid-holland.nl

#1 - Cookiebanner heeft geen role="dialog" en geen naam

Als een bezoeker de website voor het eerst opent, verschijnt er een cookiebanner boven aan de pagina. Dit dialoogvenster heeft geen juiste rol en geen toegankelijke naam. Schermlezers kunnen het element daardoor niet herkennen als dialoogvenster en kunnen het doel en de inhoud ervan niet doorgeven.

User story

Als blinde bezoeker die de site met NVDA gebruikt, hoor ik niet dat er een cookievenster opent en weet ik dus niet wat erin staat of wat ik moet doen, want mijn schermlezer kondigt het venster niet aan.

Hoe te testen

Open de pagina en roep de cookiebanner op, bijvoorbeeld door de pagina in een nieuwe sessie te openen. Inspecteer de banner met een schermlezer of met de toegankelijkheidstools van de browser. Controleer of de banner een passende rol heeft (dialog) en een toegankelijke naam die het doel beschrijft.

Oplossing

Voeg twee attributen toe aan het dialoogvenster: role="dialog" en een aria-label met een duidelijke beschrijving van de inhoud, bijvoorbeeld aria-label="Beschrijving van de inhoud".

#2 - Focus landt niet eerst op de cookiebanner

Als de website voor het eerst wordt bekeken, verschijnt er een cookiebanner boven aan de pagina. De toetsenbordfocus verspringt echter niet als eerste naar de banner of de knoppen daarin. Bezoekers moeten eerst door de hele pagina-inhoud navigeren voordat ze de cookiebanner bereiken. Daardoor kunnen bezoekers die het toetsenbord gebruiken met de pagina-inhoud bezig zijn voordat ze de kans krijgen om hun cookievoorkeuren te bekijken of in te stellen. De focusvolgorde sluit niet aan op de visuele presentatie en het belang van de cookiebanner.

User story

Als bezoeker die alleen het toetsenbord gebruikt, wil ik dat de focus direct naar de cookiebanner springt zodra die verschijnt, zodat ik mijn cookiekeuze kan maken voordat ik de rest van de pagina doorloop.

Hoe te testen

Laad de pagina met de cookiebanner zichtbaar en navigeer alleen met het toetsenbord. Controleer of de cookiebanner en de knoppen daarin te bereiken zijn vóór de hoofdinhoud, en of bezoekers niet eerst door de hele pagina hoeven te tabben om de banner te bedienen.

Oplossing

Verplaats de toetsenbordfocus naar de cookiebanner, of naar het eerste interactieve element daarin, zodra de banner verschijnt. Bezoekers moeten de cookieknoppen kunnen bereiken en bedienen voordat ze door de hoofdinhoud navigeren.

#3 - Focus niet meer zichtbaar omdat de cookiebanner bij inzoomen een deel van de pagina bedekt

Als een bezoeker de website voor het eerst opent, verschijnt er een cookiebanner. Zoomt die bezoeker daarna in tot 200% of 400% op een scherm met een resolutie van 1280 bij 1024 pixels, dan landt de toetsenbordfocus op elementen die deels onder de banner liggen. De overlay van de banner is semi-transparant, dus de focus is niet volledig bedekt en blijft gedeeltelijk zichtbaar. Toch is dit een aandachtspunt: de focus is hierdoor minder goed te zien dan gewenst. We melden dit als advies, niet als harde schending.

User story

Als slechtziende bezoeker die tot 200% inzoom en met het toetsenbord navigeer, raak ik het spoor van de focus deels kwijt als die achter de cookiebanner schuift, want ik wil altijd helder kunnen zien welk element focus heeft.

Hoe te testen

Tab door de pagina terwijl vaste headers, footers, cookiebanners en chatwidgets zichtbaar zijn. Bij elke stap moet minstens een deel van het element met focus, inclusief de focusindicator, zichtbaar blijven. Het mag nooit volledig achter andere content verdwijnen.

Oplossing

Zorg dat de cookiebanner goed meeschaalt bij inzoomen, zodat de focus zichtbaar blijft. Omdat de overlay semi-transparant is en de focus niet volledig bedekt, kun je dit als verbeterpunt oppakken in plaats van als blokkerende fout.

#4 - Strong-element in plaats van h1 tot en met h6

In de cookiebanner is de tekst "Provinciaal Archeologisch Depot maakt gebruik van cookies" een kop, maar het kopelement ontbreekt. Er wordt een strong-element gebruikt om de tekst eruit te laten zien als een kop. Het strong-element is bedoeld voor semantische nadruk, niet voor het maken van koppen. Door het in plaats van de kopelementen (h1 tot en met h6) te gebruiken, klopt de structuur van de inhoud niet en is die niet toegankelijk voor hulpsoftware. Hetzelfde probleem staat op de pagina https://archeologie.zuid-holland.nl/nieuws/subsidie-publieksbereik-archeologie_55 bij de koppen "De bruikleenaanvraag", "Enkele belangrijke punten:" en "Richtlijnen KNA voor tentoonstellen objecten".

User story

Als blinde bezoeker die met een schermlezer van kop naar kop springt, mis ik titels die alleen vetgedrukt zijn, want ik wil dat elke titel als echte kop is gemarkeerd zodat ik de paginastructuur kan volgen.

Hoe te testen

Loop de pagina door met DevTools en een schermlezer. Alle visuele koppen moeten ook echt in de HTML bestaan, niet alleen als opgemaakte tekst.

Oplossing

Verwijder het strong-element en gebruik het juiste kopelement voor deze tekst.

#5 - Skiplink ontbreekt

De pagina's bieden geen zichtbare skiplink (bijvoorbeeld "Naar de hoofdinhoud"). Er zijn deels wel landmarks en koppen aanwezig die bezoekers helpen om door de paginastructuur te navigeren. Een skiplink is daarom een aanvulling: hij geeft bezoekers die het toetsenbord gebruiken een snellere manier om de terugkerende navigatie over te slaan en direct naar de hoofdinhoud te gaan.

User story

Als bezoeker die alleen het toetsenbord gebruikt, wil ik een skiplink waarmee ik direct naar de hoofdinhoud spring, zodat ik niet op elke pagina opnieuw door dezelfde navigatie hoef te tabben.

Hoe te testen

Tab één keer vanuit de adresbalk de pagina op. Een skiplink ("Naar de hoofdinhoud") zou het eerste focusbare element moeten zijn (nadat de cookiebanner is gesloten), zichtbaar moeten worden zodra het focus krijgt, en bij activeren de focus naar de hoofdinhoud moeten verplaatsen.

Oplossing

Voeg een skiplink toe als eerste focusbare element op de pagina. De skiplink mag standaard visueel verborgen zijn, maar moet zichtbaar worden zodra hij toetsenbordfocus krijgt, en moet de focus naar de hoofdinhoud verplaatsen.

#6 - Logo is toegevoegd als achtergrondafbeelding, logolink heeft geen toegankelijke naam

Het logo boven aan de website is gemaakt als CSS-achtergrondafbeelding en is de enige inhoud van een link. Daardoor heeft de logoafbeelding geen tekstalternatief en heeft de link geen toegankelijke naam. Bezoekers die een schermlezer, spraakbesturing of andere hulpsoftware gebruiken, kunnen het doel of de bestemming van de link niet bepalen.

User story

Als bezoeker die spraakbesturing en een schermlezer gebruikt, kan ik het logo boven aan de pagina niet benoemen of activeren, want het wordt als naamloze link aangekondigd zonder de zichtbare logotekst die mij vertelt waar ik terechtkom.

Hoe te testen

Navigeer met een schermlezer naar de logolink in de header en controleer of het logo wordt aangekondigd met een betekenisvol tekstalternatief dat de organisatie of website benoemt. Controleer dat het logo niet wordt aangekondigd als naamloze link of afbeelding, maar de volledige zichtbare tekst bevat.

Oplossing

Maak de logoafbeelding toegankelijk voor gebruikers van hulpsoftware en geef die een tekstalternatief inclusief de zichtbare tekst. Zorg dat ook de logolink een betekenisvolle toegankelijke naam heeft. Die naam moet de zichtbare tekst van het logo bevatten en duidelijk maken waar de link naartoe leidt.

#7 - Carousel roteert automatisch zonder pauzemogelijkheid

Boven aan de website roteert een carousel automatisch door de slides. Bezoekers kunnen de rotatie niet pauzeren, stoppen of de timing aanpassen. Bezoekers die meer tijd nodig hebben om de inhoud te lezen, zoals bezoekers met een cognitieve beperking of gebruikers van hulpsoftware, kunnen hierdoor belangrijke informatie missen.

User story

Als bezoeker met een cognitieve beperking die snel afgeleid raakt door bewegende inhoud, mis ik de tekst in de carousel omdat die doorschuift voordat ik klaar ben met lezen, want ik wil de slide kunnen stilzetten en op mijn eigen tempo lezen.

Hoe te testen

Bekijk de carousel en controleer of die automatisch doorschuift. Controleer of er een mechanisme is om de automatische rotatie te pauzeren, te stoppen of handmatig te bedienen, en of bezoekers de huidige slide zo lang als nodig zichtbaar kunnen houden.

Oplossing

Bied een pauzeknop waarmee bezoekers de automatische rotatie kunnen stoppen. Zorg dat de knop duidelijk zichtbaar is bij de carousel.

#8 - Decoratief icoon is niet verborgen voor hulpsoftware

Boven aan de website staat een carousel met afbeeldingen. Op de eerste afbeelding staat naast de link "Lees meer" een puur decoratief pijl-icoon dat wel zichtbaar is voor schermlezers. Omdat het icoon geen informatie toevoegt, zorgt het voor onnodige ruis voor bezoekers die een schermlezer gebruiken en wordt de pagina lastiger te navigeren. Decoratieve elementen moeten worden verborgen voor hulpsoftware.

User story

Als blinde bezoeker die de site met een schermlezer leest, hoor ik decoratieve iconen die niets toevoegen voorgelezen worden, want ik wil dat die worden overgeslagen zodat ik me op de echte inhoud kan richten.

Hoe te testen

Inspecteer elke afbeelding, elk icoon en elke SVG in DevTools. Informatieve elementen hebben een toegankelijke naam nodig die hun betekenis overbrengt: een alt-attribuut op een <img>, een aria-label of <title>-element op een SVG, of een toegankelijke naam op icoonfonts. Decoratieve elementen horen idealiter helemaal niet in de HTML, gebruik dan een CSS-achtergrond. Staat een decoratief element wel in de HTML, verberg het dan voor hulpsoftware met aria-hidden="true" (of alt="" als het echt een <img> is). Controleer met een schermlezer dat er geen ruis wordt aangekondigd.

Oplossing

Verberg het decoratieve icoon voor schermlezers door alt="" toe te voegen aan het <img>-element.

#9 - Onvoldoende contrast van linktekst

In de carousel boven aan de website heeft de blauwe (#5287C1) link "Lees meer" onvoldoende contrast met de witte achtergrond: 3,8:1.

User story

Als slechtziende bezoeker die een link wil aanklikken, lees ik de linktekst met moeite omdat die te weinig opvalt met de achtergrond, want ik wil dat linktekst altijd duidelijk leesbaar is met de achtergrond.

Hoe te testen

Gebruik een toegankelijkheidstool voor een automatische contrastcontrole en meet randgevallen daarna handmatig met Colour Contrast Analyzer. Het minimum is 4,5:1 voor normale tekst en 3,0:1 voor grote tekst (vanaf 24px normaal of 18,66px vet). Vergeet placeholders en tekst op afbeeldingen niet.

Oplossing

Pas de kleur van de linktekst of de achtergrond aan zodat de contrastverhouding voldoet aan het minimum. Voor normale tekst is minimaal 4,5:1 vereist, voor grote tekst (minstens 24px normaal of 18,66px vet) minimaal 3,0:1.

#10 - Onzichtbaar element krijgt toetsenbordfocus

Op alle pagina's van de website staat een carousel. Als een andere slide dan de eerste wordt getoond, landt de toetsenbordfocus na het logo bovenaan op een onzichtbaar interactief element (de "Lees meer"-link die buiten beeld staat). Onzichtbare interactieve elementen horen niet in de focusvolgorde. Dit kan leiden tot onbedoelde activering en verwarring, vooral voor bezoekers die op toetsenbordnavigatie zijn aangewezen. Een vergelijkbaar probleem staat op de pagina https://archeologie.zuid-holland.nl/collectie, waar de toetsenbordfocus na het veld "Vindplaats" op een onzichtbaar element terechtkomt.

User story

Als bezoeker die met toetsenbord en schermlezer werkt, land ik bij het tabben soms op elementen die ik niet zie, want ik wil dat de focus alleen op zichtbare elementen terechtkomt.

Hoe te testen

Tab van boven naar beneden door de pagina en let op sprongen die niet bij de visuele volgorde passen. Open elk modaal venster, elke dropdown en elk dynamisch onderdeel en controleer of de focus op een logische plek landt. Vermijd positieve tabindex-waarden volledig.

Oplossing

Zorg dat alleen zichtbare interactieve elementen focusbaar zijn en dat de focusvolgorde een logische volgorde aanhoudt.

#11 - Navigatieknoppen hebben geen toegankelijke rol en naam en zijn niet met het toetsenbord te bedienen

Boven aan alle pagina's heeft de carousel puntjes om tussen de slides te navigeren. Deze navigatiebediening werkt als knoppen, maar heeft geen toegankelijke rol en naam en is niet met het toetsenbord te bedienen.

User story

Als bezoeker die met toetsenbord en schermlezer werkt, kan ik niet tussen de carouselslides wisselen omdat de navigatiepuntjes geen naam hebben en niet met het toetsenbord te bereiken zijn, want ik wil ze kunnen begrijpen en bedienen.

Hoe te testen

Navigeer met het toetsenbord naar de carousel en controleer of elk navigatiepunt focus kan krijgen en geactiveerd kan worden. Controleer met een schermlezer of elk punt wordt aangekondigd met een betekenisvolle toegankelijke naam die de functie of de bijbehorende slide benoemt.

Oplossing

Maak de navigatiepunten als interactieve bediening, bijvoorbeeld als knoppen. Zorg dat elk punt met het toetsenbord te bedienen is, focus kan krijgen en een betekenisvolle toegankelijke naam heeft die het doel benoemt, bijvoorbeeld "Ga naar slide 1", "Ga naar slide 2", enzovoort. Zo kunnen bezoekers die het toetsenbord of hulpsoftware gebruiken de carouselnavigatie begrijpen en bedienen.

#12 - Carouselpuntjes hebben onvoldoende contrast en geven de actieve slide niet goed aan

De navigatiepuntjes van de carousel hebben onvoldoende contrast. Op sommige slides heeft het actieve witte puntje een contrastverhouding van 2,7:1 met de bruine (#9F9D90) achtergrond. Daarnaast is het geselecteerde puntje onvoldoende te onderscheiden van de niet-geselecteerde puntjes: de contrastverhouding tussen het actieve en de inactieve puntjes is lager dan 3,0:1. De actieve slide wordt alleen met een kleurverschil aangegeven. Bezoekers die het kleurverschil niet kunnen waarnemen, kunnen lastig bepalen welke slide actief is. Bovendien wordt de actieve status niet in de code doorgegeven, zodat hulpsoftware niet kan bepalen welk puntje bij de getoonde slide hoort.

User story

Als slechtziende bezoeker die met een schermlezer werkt, kan ik niet bepalen welke carouselslide actief is omdat het verschil alleen in kleur zit en niet in de code staat, want ik wil dat de actieve status duidelijk zichtbaar én programmatisch herkenbaar is.

Hoe te testen

Inspecteer de navigatiepuntjes en controleer of ze voldoende contrast hebben met de achtergrond. Controleer of het geselecteerde puntje te onderscheiden is van de niet-geselecteerde puntjes zonder alleen op kleur te leunen, en of de actieve status in de code wordt doorgegeven aan hulpsoftware.

Oplossing

Verhoog het contrast van de carouselpuntjes met de achtergrond en zorg dat het geselecteerde puntje visueel te onderscheiden is van de niet-geselecteerde puntjes, met een contrastverhouding van minimaal 3,0:1. Leun niet alleen op kleur om de actieve slide aan te geven. Voeg een extra visuele aanwijzing toe, zoals een andere vorm, rand, grootte of omlijning. Zorg ook dat de actieve status in de code wordt doorgegeven, bijvoorbeeld met een passend ARIA-attribuut als aria-current, zodat hulpsoftware de geselecteerde slide kan herkennen.

#13 - Interactieve elementen staan te dicht bij elkaar zonder voldoende tussenruimte

De carousel op deze pagina heeft navigatiepuntjes. Deze interactieve doelen zijn klein en staan te dicht bij elkaar zonder voldoende tussenruimte: 10 bij 10 pixels. Bezoekers met een motorische beperking of gebruikers van aanraakschermen kunnen hierdoor per ongeluk het verkeerde element activeren. Als doelen kleiner zijn dan 24 bij 24 CSS-pixels, is voldoende tussenruimte nodig om ze nauwkeurig te kunnen activeren.

User story

Als bezoeker met beperkte motoriek of tremoren raak ik bij het tikken vaak per ongeluk het puntje ernaast, want ik wil genoeg ruimte tussen de knoppen zodat ik de juiste raak.

Hoe te testen

Meet elk interactief doel (knop, icoon, link) in de weergegeven UI. Het moet minimaal 24 bij 24 CSS-pixels zijn, of er moet genoeg ruimte omheen zitten zodat een cirkel van 24 bij 24 geen buur overlapt. Carouselpuntjes, paginering en knoppen met alleen een icoon zijn veelvoorkomende valkuilen.

Oplossing

Vergroot de tussenruimte tussen de interactieve elementen (bijvoorbeeld met margin of gap) of vergroot de doelgebieden tot minimaal 24 bij 24 CSS-pixels.

#14 - Toetsenbordfocus is niet zichtbaar

Op veel pagina's van deze website is de standaard focusindicator van interactieve elementen verwijderd en is er geen eigen focusindicator als alternatief toegevoegd. Een paar voorbeelden, dit is geen volledige lijst:

• op de pagina https://archeologie.zuid-holland.nl/: de zoekknoppen in beide zoekvelden, links als "provincie Zuid-Holland" en "zuid-holland.nl", en de links "Bekijk website" onder de kop "Aanbevolen websites"
• op de pagina https://archeologie.zuid-holland.nl/contact: de link "[email protected]" en de knop "Verstuur"
• op de pagina https://archeologie.zuid-holland.nl/nieuws: de links "Bekijk bericht"
• op de pagina https://archeologie.zuid-holland.nl/collectie: de link "[email protected]", de keuzelijsten "Gaafheid" en "Periode", de knoppen "Zoek" en "Reset" en andere vergelijkbare interactieve elementen op veel andere pagina's.

De toetsenbordfocus moet zichtbaar zijn op alle interactieve elementen (links, knoppen, invoervelden). Bezoekers die alleen het toetsenbord gebruiken, hebben deze visuele aanwijzing nodig om te weten waar ze op de pagina zijn en om elementen correct te bedienen.

User story

Als bezoeker die alleen het toetsenbord gebruikt, zie ik bij het tabben niet welk element actief is, want ik wil altijd kunnen zien waar ik me op de pagina bevind.

Hoe te testen

Tab door elk focusbaar element op de pagina en controleer of je steeds kunt zien waar de focus is. Let op outline: none in de CSS zonder vervanging.

Oplossing

Verwijder de outline: none-stijl van de genoemde elementen of voeg een eigen focusindicator toe die aan de toegankelijkheidseisen voldoet (voldoende contrast, duidelijke visuele aanwijzing).

#15 - Menuknop heeft geen toegankelijke rol en naam

Op een klein scherm verschijnt op alle pagina's een menuknop (het "hamburger"-icoon met drie horizontale streepjes) om het mobiele navigatiemenu te openen. Deze knop heeft geen juiste toegankelijke rol, waardoor hulpsoftware hem niet herkent als knop. De knop heeft ook geen toegankelijke naam en is niet met het toetsenbord te bedienen. De menuknop moet de rol button hebben, omdat hij een actie uitvoert (het menu openen of sluiten), en een beschrijvende naam. Daarnaast moet hij de status van het menu (open of dicht) doorgeven aan bezoekers die het niet kunnen zien, zoals bezoekers die een schermlezer gebruiken.

User story

Als blinde bezoeker die met een schermlezer werkt, hoor ik niet dat de menuknop een knop is die ik kan activeren, want ik wil dat mijn schermlezer hem aankondigt als bedienbaar element met zijn status.

Hoe te testen

Open de toegankelijkheidsboom in DevTools (rechtsklik op het element, dan Inspecteren, dan het tabblad Accessibility) en controleer de rol. Een klikbare <div> of <span> heeft vaak geen rol, of de rol "generic". De rol moet passen bij wat het element doet: "button" voor een actie, "link" voor navigatie. Controleer met een schermlezer ook of de toegankelijke naam en status van interactieve elementen worden aangekondigd.

Oplossing

Zorg dat de knop de juiste rol heeft, op een van deze manieren:

1. Gebruik het button-element: gebruik, als dat nog niet zo is, het button-element voor de menuknop.
2. Voeg role="button" toe: als een ander element wordt gebruikt (wat over het algemeen niet wordt aanbevolen), voeg dan role="button" toe om de rol expliciet vast te leggen.

Geef de knop ook een toegankelijke naam (bijvoorbeeld met aria-label) die de functie duidelijk beschrijft. Omdat de functie verandert naar "menu sluiten" zodra het menu open is, zorg je dat de toegankelijke naam meebeweegt (bijvoorbeeld van "Open menu" naar "Sluit menu"), of gebruik je het attribuut aria-expanded op de menuknop.

#16 - Focusvolgorde in het mobiele menu klopt niet

Als de pagina is ingezoomd, verschijnt er een menuknop in de header die het mobiele menu opent. De toetsenbordfocus verspringt echter niet naar het mobiele menu zodra het opent. Dat is een belangrijk toegankelijkheidsprobleem. Bovendien kan de toetsenbordfocus uit het mobiele menu ontsnappen en naar de onderliggende pagina gaan terwijl het menu open blijft. De toetsenbordfocus moet bij mobiele menu's goed worden gestuurd. Zolang het menu open is, moet de focus binnen het menu blijven, zodat bezoekers niet per ongeluk werken met de pagina eronder. Anders raken bezoekers die het toetsenbord gebruiken het spoor van hun positie kwijt en kunnen ze onbedoeld werken met inhoud die visueel achter het menu schuilgaat.

User story

Als bezoeker die alleen het toetsenbord gebruikt, raak ik in het mobiele menu de weg kwijt omdat de focus niet in het menu landt en er weer uit ontsnapt, want ik wil dat de focus in het menu blijft zolang het open is.

Hoe te testen

Open het mobiele navigatiemenu en navigeer alleen met het toetsenbord. Controleer of de focus in het menu landt zodra het opent, in het menu blijft zolang het open is, en niet naar elementen achter het menu kan gaan. Controleer of het element met focus steeds zichtbaar blijft.

Oplossing

Zodra een mobiel menu opent, moet de toetsenbordfocus meteen en correct in het menu worden geplaatst. Zolang het menu open is, blijft de focus binnen het menu, zodat bezoekers niet per ongeluk door elementen op de onderliggende pagina navigeren. Zorg dat het element met focus altijd zichtbaar is en niet wordt bedekt door het menu of andere onderdelen. Zodra het menu wordt gesloten, keert de focus terug naar de knop die het opende.

#17 - Placeholdertekst van de zoekbalk heeft onvoldoende contrast

Op deze pagina staat onder de kop "Zoeken naar vondsten" een zoekveld. De placeholdertekst werkt als visueel label en oriëntatiepunt voor de randen van het zoekveld, zodat slechtziende bezoekers weten waar ze moeten klikken. Het kleurcontrast met de achtergrond is echter 3,7:1 (grijze (#757575) tekst met de lichtgrijze (#E5E5E5) achtergrond), wat onder het vereiste minimum ligt.

User story

Als slechtziende bezoeker met verminderde contrastgevoeligheid kan ik het zoekveld nauwelijks herkennen omdat de placeholdertekst te licht is, want ik wil dat die tekst voldoende contrast heeft zodat ik zie wat ik kan invullen.

Hoe te testen

Gebruik Colour Contrast Analyzer (CCA) om de contrasten te meten. Als je de exacte pixel niet kunt selecteren, vind je de kleurwaarde soms via de inspector van de browser. Wat telt is het contrast van het element met de achtergrond.

Oplossing

Verhoog het kleurcontrast van de placeholdertekst tot minimaal 4,5:1 met de achtergrond.

#18 - Rand van het zoekveld heeft onvoldoende contrast

Op deze pagina staat onder de kop "Zoeken naar vondsten" een zoekveld. De contrastverhouding tussen de lichtgrijze (#E5E5E5) rand en de witte achtergrond van de pagina is 1,3:1. De placeholdertekst zou bezoekers kunnen helpen de rand van het veld te herkennen, maar die tekst heeft zelf ook onvoldoende contrast. Daardoor kunnen slechtziende bezoekers en bezoekers met verminderde contrastgevoeligheid het zoekveld lastig waarnemen en zien ze niet waar ze moeten klikken. Hetzelfde probleem staat op de pagina https://archeologie.zuid-holland.nl/collectie.

User story

Als slechtziende bezoeker zie ik de rand van het zoekveld nauwelijks omdat die amper opvalt met de achtergrond, want ik wil dat elke veldrand duidelijk zichtbaar is zodat ik het veld herken.

Hoe te testen

Meet met Colour Contrast Analyzer het contrast van focusindicatoren, invoerveldranden, statussen van checkboxes en radio buttons en informatieve iconen met hun achtergrond. Het minimum is 3,0:1. Vergeet grafiekonderdelen en onderstreepte links niet.

Oplossing

Zorg dat de zichtbare rand van het zoekveld voldoende contrast heeft met de omliggende achtergrond. De randen van UI-componenten moeten een contrastverhouding van minimaal 3,0:1 hebben. Leun niet op de placeholdertekst als enige zichtbare aanduiding van de veldrand, zeker niet als die placeholdertekst zelf ook onvoldoende contrast heeft.

#19 - Tekstalternatief herhaalt andere tekst

Op deze pagina staat onder de kop "Archeologie in de provincie Zuid-Holland" een galerij met afbeeldingen. De tekstalternatieven van de afbeeldingen herhalen de tekst die op de afbeeldingen staat. Omdat deze afbeeldingen geen extra informatie geven naast wat al op de pagina staat, kun je ze als decoratief beschouwen. Dezelfde galerij staat ook op andere pagina's: https://archeologie.zuid-holland.nl/contact, https://archeologie.zuid-holland.nl/collectie, https://archeologie.zuid-holland.nl/vondst-melden en andere.

User story

Als blinde bezoeker die met een schermlezer leest, hoor ik bij een afbeelding naast beschrijvende tekst dezelfde informatie twee keer, want ik wil dat de afbeelding wordt overgeslagen zodat ik de tekst maar één keer hoor.

Hoe te testen

Controleer of het tekstalternatief niet hetzelfde is als de tekst er direct naast, zoals de kop of het bijschrift. Luister met een schermlezer: als dezelfde informatie twee keer wordt aangekondigd, is het tekstalternatief overbodig en kun je het beter leeg laten.

Oplossing

De alt-attributen van deze afbeeldingen moeten leeg zijn (alt="") om herhaling van informatie voor schermlezergebruikers te voorkomen.

#20 - Onjuist gebruik van het strong-element

Onder aan deze pagina, onder de kop "Aanbevolen websites", worden strong-elementen gebruikt om koppen op te maken, bijvoorbeeld voor de tekst "Erfgoedhuis Zuid-Holland". Daarnaast zijn de afbeelding en de koptekst samen in hetzelfde strong-element geplaatst, wat geen betekenisvolle structuurinformatie geeft. Het strong-element is bedoeld voor semantische nadruk, niet voor het maken van koppen.

User story

Als blinde bezoeker die met een schermlezer van kop naar kop springt, mis ik titels die alleen vetgedrukt zijn, want ik wil dat elke titel als echte kop is gemarkeerd zodat ik de paginastructuur kan volgen.

Hoe te testen

Loop de pagina door met DevTools en een schermlezer. Alle visuele koppen moeten ook echt in de HTML bestaan, niet alleen als opgemaakte tekst.

Oplossing

Verwijder de strong-elementen en markeer de teksten "Archeologiehuis Zuid-Holland", "Erfgoedhuis Zuid-Holland" en "Provincie Zuid-Holland" als koppen met passende kopelementen (bijvoorbeeld h3) die bij de paginahiërarchie passen. De afbeeldingen horen niet binnen de koppen.

#21 - Decoratieve afbeeldingen zijn niet verborgen voor schermlezers

Op deze pagina staan onder de kop "Aanbevolen websites" drie logo's. Hun alt-teksten bevatten de bestandsnamen van de afbeeldingen in plaats van een betekenisvolle beschrijving: "archeologiehuis-small.jpg", "erfgoedhuis-zuid-holland-small.jpg" en "04c76ecdd947a0693513f14701619795.png". Normaal gesproken zijn logo's informatieve afbeeldingen en horen ze een tekstalternatief te krijgen met de naam van de organisatie. Hier wordt elk logo echter meteen gevolgd door een kop met dezelfde organisatienaam. Daardoor is de informatie van het logo al in tekstvorm aanwezig en zijn de afbeeldingen feitelijk decoratief. Ze moeten een leeg tekstalternatief hebben.

User story

Als blinde bezoeker die met een schermlezer navigeert, hoor ik bij een decoratieve afbeelding overbodige tekst zoals een bestandsnaam voorgelezen, want ik wil dat decoratieve afbeeldingen worden overgeslagen.

Hoe te testen

Inspecteer elke afbeelding, elk icoon en elke SVG in DevTools. Informatieve elementen hebben een toegankelijke naam nodig die hun betekenis overbrengt: een alt-attribuut op een <img>, een aria-label of <title>-element op een SVG, of een toegankelijke naam op icoonfonts. Decoratieve elementen verberg je voor schermlezers met CSS, aria-hidden="true" of alt="" als het een <img> is. Controleer met een schermlezer dat er geen ruis (bestandsnaam, "afbeelding") wordt aangekondigd.

Oplossing

Verwijder de huidige niet-betekenisvolle tekstalternatieven. Omdat de organisatienamen al in de tekst direct na de logo's staan, kun je de logo's als decoratief behandelen en een leeg tekstalternatief geven: alt="".

#22 - Linktekst is niet duidelijk genoeg

Op deze pagina hebben onder de kop "Aanbevolen websites" drie links dezelfde nietszeggende tekst "Bekijk website". Die tekst beschrijft de bestemming van de link niet goed en is verwarrend, vooral voor bezoekers met een cognitieve beperking of bezoekers die een schermlezer gebruiken. Onduidelijke linkteksten als "Bekijk website" of "Klik hier" kun je beter vermijden. Hetzelfde probleem staat op de pagina https://archeologie.zuid-holland.nl/nieuws met meerdere links "Bekijk bericht".

User story

Als blinde bezoeker die met een schermlezer een lijst met links opvraagt, zie ik meerdere keren hetzelfde label "Bekijk website", want ik wil dat elke link duidelijk en uniek beschrijft waar die naartoe leidt.

Hoe te testen

Open met een schermlezer de lijst met links (Insert+F7 in NVDA) en beoordeel elke link los van de context: zou je erop klikken? Vage labels als "Lees meer", "Klik hier" of dezelfde tekst met verschillende bestemmingen zijn een signaal. Afbeeldingslinks hebben een alt nodig die de bestemming beschrijft.

Oplossing

Zorg dat de linktekst de bestemming duidelijk aangeeft. Omdat de context visueel duidelijk is (de link staat binnen een specifieke sectie), kun je de tekst "Bekijk website" aanvullen met visueel verborgen tekst die meer context geeft. Bijvoorbeeld: <a href="">Bekijk website<span class="sr-only"> van Archeologiehuis Zuid-Holland</span></a>.

autocomplete-attribuut ontbreekt

Op deze pagina mist een formulier met invoervelden voor persoonsgegevens ("Naam", "Email") het autocomplete-attribuut. Als formulieren persoonsgegevens verzamelen, hoort bij deze invoervelden het juiste autocomplete-attribuut te staan. Daarmee kunnen browsers en hulpsoftware bezoekers ondersteunen, bijvoorbeeld door de velden automatisch in te vullen. Hetzelfde probleem speelt bij het formulier op de pagina https://archeologie.zuid-holland.nl/vondst-melden.

User story

Als bezoeker met beperkte motoriek of tremoren wil ik dat mijn browser mijn naam en e-mailadres automatisch invult, want zelf typen kost me veel moeite en het autocomplete-attribuut ontbreekt nu.

Hoe te testen

Inspecteer bij elk veld dat persoonsgegevens verzamelt (zoals naam, adres, telefoon, e-mail, wachtwoord) het autocomplete-attribuut. De waarde moet overeenkomen met de WCAG-lijst. Laat de browser het formulier daarna automatisch invullen en controleer of de juiste waarde in het juiste veld terechtkomt.

Oplossing

Gebruik het autocomplete-attribuut voor alle velden waarin persoonsgegevens moeten worden ingevuld. Meer informatie over dit attribuut en de vereiste waarden vind je op https://www.w3.org/Translations/WCAG22-nl/#input-purposes.

#23 - Statusbericht van het formulier wordt niet aangekondigd

Als het formulier op deze pagina wordt verstuurd met lege of onjuiste velden, verschijnt de statusmelding "Vul alle velden met een * correct in". Deze melding wordt niet aangekondigd aan bezoekers die een schermlezer gebruiken, omdat er geen passende ARIA-liveregio of rol wordt gebruikt. Bezoekers die op een schermlezer leunen, missen zo belangrijke terugkoppeling over het resultaat van hun actie. Hetzelfde geldt voor de succesmelding na correcte verzending, "Bedankt u voor uw bericht. Wij nemen zo snel mogelijk contact met u op.", en voor het formulier op de pagina https://archeologie.zuid-holland.nl/vondst-melden.

User story

Als blinde bezoeker die met een schermlezer een formulier verstuurt, hoor ik niet of het gelukt is, want ik wil dat mijn schermlezer het resultaat van mijn verzending automatisch aankondigt.

Hoe te testen

Loop met een ingeschakelde schermlezer elke actie op de pagina door die een statusbericht oplevert zonder dat er een nieuwe pagina laadt: een formulier versturen, iets aan een selectie toevoegen, een zoekopdracht uitvoeren, een laadindicator afwachten. Elk bericht moet worden aangekondigd zonder dat de focus ernaartoe verspringt, meestal via role="status", aria-live="polite" of een vergelijkbare liveregio.

Oplossing

Gebruik een ARIA-liveregio om het statusbericht aan te kondigen. Gebruik role="status" voor succesmeldingen of role="alert" voor foutmeldingen, zodat het bericht automatisch wordt aangekondigd zonder dat de focus verspringt.

#24 - Foutmelding benoemt of verklaart de fouten in het formulier niet

Als het formulier met onjuiste of onvolledige gegevens wordt verstuurd, verschijnt alleen de algemene foutmelding "Vul alle velden met een * correct in." Die melding benoemt niet welke velden fouten bevatten en legt niet uit wat er mis is met de ingevoerde gegevens. Daardoor moeten bezoekers zelf uitzoeken welke velden aandacht nodig hebben en hoe ze de fouten oplossen. Bij een ongeldig e-mailadres is er bijvoorbeeld geen aanwijzing dat het formaat niet klopt of hoe het wel moet. Hetzelfde probleem speelt bij het formulier op de pagina https://archeologie.zuid-holland.nl/vondst-melden.

User story

Als bezoeker die een formulier invult, wil ik weten welke velden fouten bevatten en hoe ik die herstel, want met een algemene melding moet ik zelf raden wat er mis is.

Hoe te testen

Verstuur het formulier met onjuiste of onvolledige gegevens en controleer of de foutmeldingen benoemen welke velden fouten bevatten. Controleer of de meldingen de aard van de fout uitleggen en, waar mogelijk, aangeven hoe je die herstelt.

Oplossing

Geef veldspecifieke foutmeldingen die duidelijk benoemen om welke velden het gaat en wat er mis is. Geef waar mogelijk suggesties die bezoekers helpen hun gegevens te verbeteren. Geef bijvoorbeeld, in plaats van alleen een algemene melding, een melding als: "E-mail is verplicht" of "Voer een geldig e-mailadres in".

#25 - Er zit een tijdslimiet op de reCAPTCHA

Op deze pagina staat een formulier met de verificatiemethode reCAPTCHA. Als de checkbox is aangevinkt maar de verzendknop nog niet is ingedrukt, verschijnt na enige tijd de melding "Verification expired. Please check the checkbox again." Er is dus een tijdslimiet aanwezig. Dat kan een probleem zijn voor sommige bezoekers.

User story

Als bezoeker die door dyslexie langzamer leest, wordt mijn formulier afgekeurd omdat de reCAPTCHA-melding verloopt voordat ik klaar ben, want ik wil de tijdslimiet kunnen uitzetten, aanpassen of verlengen.

Hoe te testen

Blijf op een pagina met een sessietimer, carousel, automatische verversing of aftelklok tot die afloopt. De bezoeker moet de limiet kunnen verlengen, uitzetten of aanpassen, of een waarschuwing krijgen met minstens 20 seconden om te verlengen. Uitzondering: realtime gebeurtenissen zoals veilingen of livestreams.

Oplossing

Laat bezoekers de tijdslimiet uitzetten, aanpassen of verlengen.

#26 - Kop is niet als kop gemarkeerd

Op deze pagina zijn de nieuwskoppen niet als kop gemarkeerd in de code. Zie bijvoorbeeld de tekst "Depot voor bodemvondsten Zuid-Holland blijft in Alphen aan den Rijn" en andere vergelijkbare teksten. Als tekst als kop functioneert maar niet als kop is gemarkeerd, verliest die zijn semantische betekenis en is die niet toegankelijk voor bezoekers die op hulpsoftware leunen, zoals een schermlezer. Koppen zijn cruciaal om de inhoudsstructuur te navigeren en te begrijpen.

User story

Als blinde bezoeker die met een schermlezer per kop door een pagina navigeert, mis ik koppen die alleen visueel zijn vormgegeven, want ik wil dat elke zichtbare kop door mijn schermlezer als kop wordt herkend.

Hoe te testen

Snelle controle met onze tool: gebruik de Koppenstructuur-checker. Plak de URL van de pagina en bekijk de lijst met koppen.

1. Loop alle teksten op de pagina door die er visueel als kop uitzien (groter, vetter, een aparte kleur of nadrukkelijke plaatsing).
2. Staan ze allemaal in de lijst van de Koppenstructuur-checker? Zo niet, dan zijn ze niet als h1 tot en met h6 gemarkeerd.
3. Controleer met een schermlezer: navigeer met H (NVDA, JAWS) of de rotor (VoiceOver). Elke visuele kop moet als kop worden aangekondigd.

Oplossing

Zorg dat deze teksten worden gemarkeerd met de passende kopelementen (h1 tot en met h6) die hun rol en hiërarchie in de inhoud weergeven. Plaats de kop in de HTML-structuur vóór de publicatiedatum. Dat zorgt voor een logischere leesvolgorde en helpt gebruikers van hulpsoftware te begrijpen welke datum bij welk nieuwsbericht hoort. De visuele volgorde kun je zo nodig nog met CSS aanpassen.

#27 - Inhoud overlapt bij het aanpassen van de tekstafstand

Als bezoekers op deze pagina de tekstafstand aanpassen zoals dit succescriterium beschrijft, overlappen de teksten in sommige nieuwskaarten de links "Bekijk bericht" en worden ze deels onzichtbaar en onleesbaar. Bezoekers passen de tekstafstand vaak aan met eigen CSS om de leesbaarheid te verbeteren. Deze pagina houdt de inhoud niet zichtbaar bij zo'n aanpassing. Alle informatie moet toegankelijk en leesbaar blijven, ook met eigen tekstopmaak.

User story

Als bezoeker met dyslexie die de letter- en regelafstand vergroot om beter te kunnen lezen, valt een deel van de tekst weg of overlapt het, want ik wil dat alle tekst zichtbaar en leesbaar blijft na mijn aanpassing.

Hoe te testen

Pas via de Stylus-extensie het WCAG-tekstafstandsnippet toe bij een breedte vanaf 1280px: regelhoogte 1.5, alineaspatiëring 2×, letterafstand 0.12em, woordafstand 0.16em. Er mag geen inhoud of functie verloren gaan.

Oplossing

Los dit op door de hoogte en breedte van de containers responsive te maken.

#28 - Visuele opsomming is niet als lijst gemarkeerd

Op deze pagina staat onder de kop "Enkele belangrijke punten:" een opsomming van drie items. Deze inhoud is visueel als lijst weergegeven met streepjes, maar is niet als lijst gemarkeerd met de HTML-lijstelementen (<ul>, <ol>, <li>). Zonder correcte lijstopmaak kan een schermlezer de inhoud niet als lijst herkennen en het aantal items niet aankondigen. Bezoekers die op hulpsoftware leunen, missen zo belangrijke structuurinformatie die ziende bezoekers wel zien. Hetzelfde probleem speelt bij de lijst onder de kop "Richtlijnen KNA voor tentoonstellen objecten" en op de pagina https://archeologie.zuid-holland.nl/open-data.

User story

Als blinde bezoeker die met een schermlezer leest, hoor ik bij een opsomming niet dat het een lijst is of hoeveel items er zijn, want ik wil dat mijn schermlezer de structuur en het aantal items aankondigt.

Hoe te testen

Inspecteer de pagina met een schermlezer of met de DevTools van de browser en controleer of visueel gepresenteerde lijsten zijn gemarkeerd met lijstelementen (<ul>, <ol>, <li>). Controleer dat items met handmatig geplaatste streepjes of andere visuele tekens niet in plaats van echte lijstopmaak worden gebruikt.

Oplossing

Markeer visuele lijsten met de juiste HTML-lijstelementen: <ul> voor een ongeordende lijst of <ol> voor een geordende lijst, met elk item in een <li>-element.

#29 - Afbeelding opent schermvullend, linkdoel onbekend

Op deze pagina werkt de afbeelding naast de kop "Subsidie publieksbereik archeologie" als een link die bij een klik een schermvullende weergave van de afbeelding opent. De afbeelding heeft echter geen alt-tekst en deze functie is niet in de HTML vastgelegd, waardoor die niet toegankelijk is voor blinde bezoekers. Zij kunnen niet waarnemen dat de afbeelding een link is of dat die een schermvullende weergave opent. Hetzelfde probleem staat op de objectpagina's na het klikken op de afbeelding van een object: https://archeologie.zuid-holland.nl/collectie/6719, https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als blinde bezoeker die met een schermlezer een link met alleen een afbeelding activeert, hoor ik niet wat er daarna gebeurt, want ik wil dat mijn schermlezer me vertelt dat de afbeelding schermvullend opent.

Hoe te testen

Open met een schermlezer de lijst met links (Insert+F7 in NVDA) en beoordeel elke link los van de context: zou je erop klikken? Vage labels als "Lees meer", "Klik hier" of dezelfde tekst met verschillende bestemmingen zijn een signaal. Afbeeldingslinks hebben een alt-tekst nodig die de bestemming beschrijft.

Oplossing

Geef informatie over het gedrag van de link. Dat kan op deze manieren:

• Verborgen tekst toevoegen: voeg beschrijvende tekst toe binnen het link-element, zoals "(opent schermvullend)", en verberg die visueel met CSS (bijvoorbeeld display: none; of een .sr-only-klasse).
• aria-haspopup="dialog" gebruiken: voeg het attribuut aria-haspopup="dialog" toe aan het link-element om aan te geven dat er een schermvullende weergave opent, die je als een soort dialoogvenster kunt behandelen.

#30 - Dialoogvenster heeft geen role="dialog" en geen naam

Op deze pagina staat naast de kop "Subsidie publieksbereik archeologie" een klikbare afbeelding die een dialoogvenster opent. Dit dialoogvenster heeft geen juiste rol en geen toegankelijke naam. Schermlezers kunnen het element daardoor niet herkennen als dialoogvenster en kunnen het doel en de inhoud ervan niet doorgeven. Hetzelfde probleem staat op de objectpagina's na het klikken op de afbeelding van een object: https://archeologie.zuid-holland.nl/collectie/6719, https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als blinde bezoeker die de site met een schermlezer leest, hoor ik niet dat er een dialoogvenster opent en weet ik dus niet wat erin staat, want ik wil dat mijn schermlezer het venster en de inhoud aankondigt.

Hoe te testen

Gebruik bij elk interactief onderdeel (link, knop, invoerveld, eigen widget) het accessibility-paneel van DevTools en een schermlezer. Elk onderdeel moet doorgeven: wat het is (rol), zijn naam, zijn huidige status (uitgeklapt, geselecteerd, aangevinkt) en zo nodig zijn waarde. Geef de voorkeur aan standaard HTML boven eigen ARIA.

Oplossing

Voeg twee attributen toe aan het dialoogvenster: role="dialog" en een aria-label met een duidelijke beschrijving van de inhoud, bijvoorbeeld aria-label="Beschrijving van de inhoud".

#31 - Focusvolgorde is niet logisch als een dialoogvenster open is

Op deze pagina staat naast de kop "Subsidie publieksbereik archeologie" een klikbare afbeelding die een dialoogvenster opent. De toetsenbordfocus wordt echter niet automatisch in het dialoogvenster geplaatst zodra dat opent. Bovendien krijgen de interactieve elementen achter het dialoogvenster nog steeds toetsenbordfocus. Daardoor kunnen bezoekers die het toetsenbord gebruiken niet zien waar de focus is. Hetzelfde probleem staat op de pagina https://archeologie.zuid-holland.nl/collectie in dialoogvensters die openen vanuit afbeeldingen onder "3D beelden", en op de objectpagina's na het klikken op de afbeelding van een object: https://archeologie.zuid-holland.nl/collectie/6719, https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als bezoeker die met toetsenbord en schermlezer werkt, blijft mijn focus na het openen van een dialoogvenster op de achterliggende pagina staan, want ik wil dat de focus meteen in het dialoogvenster landt zodra dat opent.

Hoe te testen

Tab van boven naar beneden door de pagina en let op sprongen die niet bij de visuele volgorde passen. Open elk modaal venster, elke dropdown en elk dynamisch onderdeel en controleer of de focus op een logische plek landt. Na het sluiten van het modale venster moet de focus terugkeren naar het element dat het opende.

Oplossing

Stuur de focusvolgorde zo dat de toetsenbordfocus meteen op een logisch element in het zojuist geopende dialoogvenster wordt geplaatst.

#32 - Sluitknop heeft geen juiste toegankelijke rol en naam

Op deze pagina opent een klikbare afbeelding naast de kop "Subsidie publieksbereik archeologie" een dialoogvenster met een sluitknop (x-knop). Deze sluitknop heeft geen toegankelijke rol en geen toegankelijke naam. Zonder passende rol kunnen schermlezers het element niet herkennen als bedienbare knop die het dialoogvenster sluit. Daardoor is de knop niet toegankelijk voor bezoekers die een schermlezer gebruiken of zonder muis navigeren. De sluitknop heeft ook geen toegankelijke naam, waardoor schermlezers de functie niet kunnen doorgeven. Hetzelfde probleem staat op de objectpagina's na het klikken op de afbeelding van een object: https://archeologie.zuid-holland.nl/collectie/6719, https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als bezoeker die met toetsenbord en schermlezer werkt, herkent mijn schermlezer de sluitknop niet als knop wanneer ik een dialoogvenster wil sluiten, want ik wil horen dat ik op een knop sta die het venster sluit.

Hoe te testen

Gebruik bij elk interactief onderdeel (link, knop, invoerveld, eigen widget) het accessibility-paneel van DevTools en een schermlezer. Elk onderdeel moet doorgeven: wat het is (rol), zijn naam, zijn huidige status (uitgeklapt, geselecteerd, aangevinkt) en zo nodig zijn waarde. Geef de voorkeur aan standaard HTML boven eigen ARIA.

Oplossing

Het element heeft de rol button nodig, zodat de schermlezer doorgeeft dat het een bedienbaar element is dat je kunt aanklikken om een actie uit te voeren (een dialoogvenster sluiten). Het moet ook een toegankelijke naam hebben, die je kunt toevoegen met een aria-label-attribuut op het <button>-element.

#33 - Socialmedialinks hebben geen toegankelijke naam en duidelijk doel

Op deze pagina werken naast de kop "Subsidie publieksbereik archeologie" drie socialmedia-afbeeldingen als links, maar ze hebben geen tekstalternatief. Daardoor hebben de links geen toegankelijke inhoud en is hun bestemming onduidelijk. Dit is ook een schending van WCAG-succescriterium 4.1.2, omdat de links geen toegankelijke naam hebben. Hetzelfde probleem met dezelfde socialmedialinks staat op andere pagina's: https://archeologie.zuid-holland.nl/collectie/6719, https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als blinde bezoeker die met een schermlezer een afbeelding als link tegenkomt, hoor ik niets dat me vertelt waar die naartoe leidt, want ik wil dat elke link een duidelijke beschrijving van de bestemming heeft.

Hoe te testen

Controleer de links op de pagina met een schermlezer en controleer of elke link wordt aangekondigd met een betekenisvolle toegankelijke naam. Controleer of bezoekers zowel de bestemming als het doel van elke link kunnen vaststellen, in plaats van een naamloze link tegen te komen.

Oplossing

Geef de links toegankelijke tekstinhoud. Dat kan op deze manieren:

• Verborgen tekst in de link: voeg beschrijvende tekst toe binnen het link-element en verberg die visueel met CSS (bijvoorbeeld een .sr-only-klasse).
• aria-label gebruiken: voeg een aria-label-attribuut toe aan het link-element met een korte beschrijving van de bestemming.

#34 - Placeholderteksten hebben onvoldoende contrast

Op deze pagina hebben alle invoervelden grijze (#757575) placeholderteksten met de lichtgrijze (#E5E5E5) achtergrond. De contrastverhouding is 3,7:1, onder het vereiste minimum van 4,5:1. Omdat deze invoervelden geen ander zichtbaar label hebben, kunnen slechtziende bezoekers niet zien waar elk veld voor dient.

User story

Als slechtziende bezoeker kan ik de placeholdertekst in een invoerveld niet lezen omdat die te licht is, want ik wil dat placeholdertekst in elk veld altijd duidelijk leesbaar is.

Hoe te testen

Gebruik Colour Contrast Analyzer (CCA) om de contrasten te meten. Wat telt is het contrast van de placeholdertekst met de achtergrond van het veld.

Oplossing

Verhoog het kleurcontrast van de placeholderteksten tot minimaal 4,5:1 met de achtergrond.

#35 - Placeholderteksten worden als label gebruikt

Op deze pagina hebben alle invoervelden geen blijvend label; de placeholdertekst wordt als label gebruikt. Invoervelden hebben een label nodig dat altijd zichtbaar is. Placeholdertekst (of de geselecteerde optie in keuzelijsten) kan die rol niet vervullen, omdat de tekst verdwijnt zodra de bezoeker begint met typen. Er moet een echt, altijd zichtbaar label zijn.

User story

Als bezoeker met dyslexie weet ik na het begin van typen niet meer wat ik in een veld moet invullen, omdat de hint-tekst dan verdwijnt, want ik wil dat elk veld een zichtbaar label heeft dat altijd blijft staan.

Hoe te testen

Inspecteer elk invoerveld, elke checkbox- of radiogroep en elke keuzelijst. Elk daarvan heeft een zichtbaar label of een duidelijke instructie nodig die uitlegt wat er wordt verwacht. Placeholders alleen tellen niet. Verplichte velden en speciale formaten (datum, postcode) hebben extra uitleg nodig.

Oplossing

Voeg aan elk invoerveld een blijvend zichtbaar label toe, zodat het doel van het veld duidelijk blijft, ook nadat de bezoeker begint met typen.

#36 - Suggestielijst van "Vindplaats" mist de combobox-rol en bijbehorende attributen

Op deze pagina geeft het invoerveld "Vindplaats" tijdens het typen suggesties in een uitklaplijst en werkt het zo als een combobox. De combobox-rol en de bijbehorende attributen ontbreken echter op het invoerveld. Daardoor kan hulpsoftware niet herkennen dat het om een combobox gaat, niet aankondigen dat de suggestielijst opent of sluit, en de samenhang tussen veld en suggesties niet doorgeven. Hetzelfde probleem speelt op de pagina https://archeologie.zuid-holland.nl/collectie?search=Porselein.

User story

Als blinde bezoeker die met een schermlezer in het veld "Vindplaats" typt, hoor ik niet dat er suggesties verschijnen of hoeveel het er zijn, want ik wil dat mijn schermlezer aankondigt dat de suggestielijst opent en dat ik erdoorheen kan navigeren.

Hoe te testen

Gebruik axe DevTools of de toegankelijkheidsboom in DevTools om te controleren of de rol compleet is. Sommige rollen hebben een verplichte bovenliggende of onderliggende rol of een verplicht attribuut nodig. Controleer of alle vereiste rollen en attributen voor een combobox aanwezig zijn, anders kan hulpsoftware het onderdeel niet interpreteren.

Oplossing

Maak dit invoerveld toegankelijk als combobox door ten minste het volgende toe te voegen:

• role="combobox": voeg dit attribuut toe aan het invoerveld om aan te geven dat het een combobox is.
• aria-expanded: voeg dit attribuut toe om de status van de suggestielijst aan te geven. Stel aria-expanded="true" in als de lijst zichtbaar is en aria-expanded="false" als die verborgen is.
• aria-controls: koppel het invoerveld met dit attribuut aan de suggestielijst, zodat de samenhang in de code vastligt.

Meer informatie vind je op https://www.w3.org/WAI/ARIA/apg/patterns/combobox/. Deze attributen helpen hulpsoftware om het veld correct te herkennen en te bedienen als combobox.

#37 - Afbeelding heeft geen tekstalternatief (alt-attribuut ontbreekt)

Op deze pagina hebben onder de kop "3D beelden" alle afbeeldingen geen alt-attribuut. Elk <img>-element moet een alt-attribuut hebben. Op deze pagina zijn de afbeeldingen puur decoratief en geven ze geen extra betekenis, dus moet het alt-attribuut aanwezig maar leeg zijn (alt="").

User story

Als blinde bezoeker die met een schermlezer werkt, wil ik dat decoratieve afbeeldingen worden genegeerd door hulpsoftware, want ik wil niet door inhoud navigeren die geen informatie geeft.

Hoe te testen

Inspecteer afbeeldingen met DevTools. Let op: een ontbrekend alt-attribuut is altijd een fout. Controleer of decoratieve afbeeldingen die als <img>-element zijn toegevoegd een leeg alt-attribuut hebben.

Oplossing

Voeg aan elk <img>-element een leeg alt-attribuut toe: alt="".

#38 - Dialoogvenster heeft geen role="dialog" en geen naam

Op deze pagina staan onder de kop "3D beelden" klikbare afbeeldingen. Elke afbeelding opent een dialoogvenster. Dit dialoogvenster heeft geen juiste rol en geen toegankelijke naam. Schermlezers kunnen het element daardoor niet herkennen als dialoogvenster en kunnen het doel en de inhoud ervan niet doorgeven.

User story

Als blinde bezoeker die de site met een schermlezer leest, hoor ik niet dat er een dialoogvenster opent en weet ik dus niet wat erin staat, want ik wil dat mijn schermlezer het venster en de inhoud aankondigt.

Hoe te testen

Gebruik bij elk interactief onderdeel (link, knop, invoerveld, eigen widget) het accessibility-paneel van DevTools en een schermlezer. Elk onderdeel moet doorgeven: wat het is (rol), zijn naam, zijn huidige status (uitgeklapt, geselecteerd, aangevinkt) en zo nodig zijn waarde. Geef de voorkeur aan standaard HTML boven eigen ARIA.

Oplossing

Voeg twee attributen toe aan het dialoogvenster: role="dialog" en een aria-label met een duidelijke beschrijving van de inhoud, bijvoorbeeld aria-label="Beschrijving van de inhoud".

#39 - Iframe mist een title-attribuut

Op deze pagina staan onder de kop "3D beelden" klikbare afbeeldingen. Elke afbeelding opent een dialoogvenster met een <iframe>-element. Dit element mist het title-attribuut. Schermlezers kunnen het doel van het iframe daardoor niet aankondigen, waardoor bezoekers niet weten welke inhoud erin staat en of die de moeite waard is om in te gaan. Dat bemoeilijkt de navigatie voor gebruikers van hulpsoftware aanzienlijk.

User story

Als blinde bezoeker die met een schermlezer een ingebed element tegenkomt, hoor ik geen beschrijving en weet ik niet wat erin staat, want ik wil dat mijn schermlezer een duidelijke naam aankondigt zodat ik kan beslissen of ik het verken.

Hoe te testen

Navigeer met een schermlezer naar elk iframe en controleer of het wordt aangekondigd met een betekenisvolle titel. De titel moet de ingebedde inhoud duidelijk benoemen, bijvoorbeeld dat het een 3D-viewer voor het object is, en niet als naamloos of generiek frame worden aangekondigd.

Oplossing

Voeg een beschrijvend title-attribuut toe aan het <iframe>-element dat duidelijk maakt welke inhoud erin staat. Bijvoorbeeld: <iframe title="3D-model van [het object]" src="..."></iframe>.

#40 - 3D-viewer is alleen met slepen te bedienen

Op deze pagina staan onder de kop "3D beelden" klikbare afbeeldingen. Elke afbeelding opent een dialoogvenster met de 3D-viewer. Met de 3D-viewer kunnen bezoekers een object draaien en bekijken door het met de muis of een ander aanwijsapparaat te slepen. Diezelfde functie is echter niet beschikbaar voor bezoekers die het toetsenbord gebruiken. De knoppen in de viewer zijn ook niet met het toetsenbord te bedienen. Daardoor kunnen bezoekers die op een toetsenbord leunen het object niet draaien, niet vanuit verschillende hoeken bekijken en niet bij dezelfde informatie komen als muis- of aanraakgebruikers. Omdat de bediening op een sleepbeweging leunt en er geen alternatief is, is de functie niet voor alle bezoekers toegankelijk.

User story

Als bezoeker die alleen het toetsenbord gebruikt, kan ik 3D-objecten niet draaien en verkennen omdat dat alleen met slepen kan, want ik wil dezelfde informatie en functies als andere bezoekers.

Hoe te testen

Open de 3D-viewer en probeer het object alleen met het toetsenbord te draaien. Controleer of alle functies die met slepen beschikbaar zijn ook zonder aanwijsapparaat en zonder sleepgebaren uitvoerbaar zijn.

Oplossing

Bied een toetsenbordtoegankelijk alternatief om het 3D-object te draaien en te verkennen. Bezoekers zouden het object bijvoorbeeld met de pijltoetsen kunnen draaien, of met aparte knoppen als "Draai naar links", "Draai naar rechts", "Draai omhoog" en "Draai omlaag". Elke functie die nu slepen vereist, moet ook met een eenvoudige toetsenbordbediening beschikbaar zijn die niet afhangt van een aanwijsapparaat of sleepgebaar.

#41 - Knoppen hebben geen juiste rol en zijn niet met het toetsenbord te bedienen

Op deze pagina staan onder de kop "3D beelden" klikbare afbeeldingen. Elke afbeelding opent een dialoogvenster. In deze dialoogvensters staan knoppen met verschillende iconen, zoals "?", "x", tandwielen en andere, maar ze hebben niet de juiste toegankelijke rol. Daardoor kunnen schermlezers ze niet als knop herkennen en zijn ze niet toegankelijk voor blinde bezoekers. Zij weten niet dat het element interactief is en aangeklikt kan worden. Dit raakt ook succescriterium 2.1.1, omdat deze knoppen niet met het toetsenbord te bedienen zijn. Ze kunnen niet met de spatiebalk of de Enter-toets worden geactiveerd. Alle knoppen moeten met zowel de spatiebalk als de Enter-toets te bedienen zijn. Dat is de standaard toetsenbordinteractie voor knoppen en essentieel voor bezoekers die op toetsenbordnavigatie leunen.

User story

Als blinde bezoeker die met een schermlezer navigeert, hoor ik niet dat een element een knop is, want ik wil dat mijn schermlezer aankondigt dat ik het kan activeren.

Hoe te testen

Gebruik bij elk interactief onderdeel (link, knop, invoerveld, eigen widget) het accessibility-paneel van DevTools en een schermlezer. Elk onderdeel moet doorgeven: wat het is (rol), zijn naam, zijn huidige status (uitgeklapt, geselecteerd, aangevinkt) en zo nodig zijn waarde. Geef de voorkeur aan standaard HTML boven eigen ARIA.

Oplossing

Zorg dat de knop de juiste rol heeft, op een van deze manieren:

1. Gebruik het button-element: gebruik, als dat nog niet zo is, het button-element voor de knop, want dat geeft van zichzelf al de juiste knoprol.
2. Voeg role="button" toe: als een ander element wordt gebruikt (wat over het algemeen niet wordt aanbevolen), voeg dan role="button" toe om de rol expliciet vast te leggen.

Zorg er ook voor dat de knoppen met beide toetsen (spatiebalk en Enter) te bedienen zijn.

#42 - Knop heeft geen toegankelijke naam

Op deze pagina staat naast een geselecteerd filter een x-knop om de gekozen optie te verwijderen. Deze knop heeft geen toegankelijke naam. Knoppen moeten altijd een toegankelijke naam hebben die de functie beschrijft. Die naam moet ook meebewegen als de functie van de knop verandert. Een toegankelijke naam mag nooit leeg zijn, want zonder naam weet een blinde bezoeker niet wat de knop doet.

User story

Als bezoeker die met spraakbesturing en een schermlezer knoppen bedient, hoor ik bij deze x-knop alleen "knop" zonder dat ik weet wat die doet, want ik wil dat elke knop een naam heeft die zijn functie benoemt.

Hoe te testen

Navigeer met een schermlezer of de Tab-toets door de knoppen op de pagina. Controleer of elke knop een betekenisvolle naam heeft die de functie beschrijft. Inspecteer onduidelijke gevallen in DevTools of een toegankelijkheidstool en bevestig dat er een aria-label, een zichtbaar label of tekstinhoud is.

Oplossing

Zorg dat deze knop een toegankelijke naam heeft die de functie beschrijft. Als er meerdere filters zijn geselecteerd, moet elke x-knop een unieke toegankelijke naam hebben, bijvoorbeeld "Verwijder filter Porselein".

#43 - Aantal geselecteerde objecten wordt niet aangekondigd door de schermlezer

Op deze pagina toont de knop "MIJN SELECTIE" een teller met het aantal toegevoegde objecten zodra je een object selecteert. Deze teller is een statusbericht dat schermlezers automatisch zouden moeten aankondigen zodra het verandert. De code die dit mogelijk maakt, ontbreekt echter.

User story

Als blinde bezoeker die met een schermlezer een object uit de resultaten selecteert, hoor ik niet of het is gelukt, want ik wil dat mijn schermlezer aankondigt hoeveel objecten ik tot nu toe heb geselecteerd.

Hoe te testen

Loop met een ingeschakelde schermlezer elke actie op de pagina door die een statusbericht oplevert zonder dat er een nieuwe pagina laadt: een formulier versturen, objecten selecteren, een zoekopdracht uitvoeren, een laadindicator afwachten. Elk bericht moet worden aangekondigd zonder dat de focus ernaartoe verspringt, meestal via role="status", aria-live="polite" of een vergelijkbare liveregio.

Oplossing

Voeg aria-live toe aan het element dat de teller toont. Zorg dat het bericht duidelijk en informatief is, bijvoorbeeld "XX objecten geselecteerd".

#44 - Beschrijvingslijst ontbreekt voor term-definitieparen

Op deze pagina is de inhoud in de zoekresultaten opgebouwd uit term-definitieparen (bijvoorbeeld "Inventarisnummer: 6719"), maar die zijn niet gemarkeerd met een beschrijvingslijst (<dl>, <dt>, <dd>). De "termen" zijn in plaats daarvan met strong-elementen opgemaakt. Zonder de opmaak van een beschrijvingslijst wordt de samenhang tussen termen en hun definities niet doorgegeven aan hulpsoftware. Schermlezers kunnen niet aankondigen welke beschrijving bij welke term hoort, waardoor de inhoud lastiger te begrijpen en te navigeren is voor gebruikers van hulpsoftware.

User story

Als blinde bezoeker die zoekresultaten met een schermlezer leest, hoor ik niet welke definitie bij welke term hoort, want ik wil dat term-definitieparen als beschrijvingslijst zijn gemarkeerd zodat de samenhang duidelijk is.

Hoe te testen

Inspecteer de inhoud en zoek term-definitieparen die visueel zijn weergegeven met opmaak zoals vetgedrukte tekst. Controleer of deze relaties zijn gemarkeerd met een beschrijvingslijst (<dl>, <dt>, <dd>) en niet alleen op visuele opmaak leunen. Zo wordt de samenhang tussen termen en definities doorgegeven aan hulpsoftware.

Oplossing

Gebruik een <dl>-element voor de beschrijvingslijst, met <dt> voor elke term en <dd> voor elke bijbehorende beschrijving of definitie.

#45 - Em-element wordt gebruikt in plaats van h1 tot en met h6

Op deze pagina zijn de teksten "Bruikleenaanvragen en onderzoeksaanvragen", "Subsidie publieksbereik" en andere koppen, maar het kopelement ontbreekt. Er wordt een em-element gebruikt om de teksten eruit te laten zien als kop. Het em-element is bedoeld voor semantische nadruk, niet voor het maken van koppen. Door het in plaats van de kopelementen (h1 tot en met h6) te gebruiken, klopt de structuur van de inhoud niet en zijn de koppen niet toegankelijk voor hulpsoftware.

User story

Als blinde bezoeker die met een schermlezer per kop navigeert, mis ik titels die alleen visueel afwijken, bijvoorbeeld met cursieve tekst, want ik wil dat elke titel als echte kop is gemarkeerd zodat ik de paginastructuur kan volgen.

Hoe te testen

Gebruik een schermlezer en navigeer per kop door de pagina (bijvoorbeeld met de H-toets in NVDA). Controleer of alle visuele koppen in de koppenlijst staan en met kopnavigatie te bereiken zijn, in plaats van te zijn gemarkeerd met niet-kopelementen zoals <em>.

Oplossing

Verwijder de em-elementen en gebruik de juiste kopelementen voor deze teksten.

#46 - Een element mist de juiste toegankelijke rol

Op deze pagina werkt onder "Terug naar overzicht" een klikbare afbeelding als knop of link die een grotere weergave van de afbeelding opent. Dit element heeft niet de juiste toegankelijke rol en is ook niet met het toetsenbord te bedienen. Elk HTML-element heeft een standaardrol die het doel en het gedrag bepaalt. Schermlezers en andere hulpsoftware leunen op deze rollen om elementen goed te begrijpen en te bedienen. Hetzelfde probleem staat op andere objectpagina's: https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als bezoeker die met toetsenbord en schermlezer werkt, hoor ik niet dat dit element een knop of link is en kan ik er niet bij of het activeren, want ik wil dat mijn schermlezer elk interactief element correct herkent.

Hoe te testen

Gebruik bij elk interactief onderdeel (link, knop, invoerveld, eigen widget) het accessibility-paneel van DevTools en een schermlezer. Elk onderdeel moet doorgeven: wat het is (rol), zijn naam, zijn huidige status (uitgeklapt, geselecteerd, aangevinkt) en zo nodig zijn waarde. Geef de voorkeur aan standaard HTML boven eigen ARIA.

Oplossing

Omdat dit element eerder als knop functioneert, zorg je dat het de rol van een knop heeft, op een van deze manieren:

• Gebruik het juiste HTML-element: gebruik, als dat nog niet zo is, het button-element, want dat geeft van zichzelf al de juiste knoprol.
• Voeg ARIA toe: als een ander element wordt gebruikt (wat over het algemeen niet wordt aanbevolen), voeg dan role="button" toe om de rol expliciet vast te leggen.

#47 - Kleurcontrast van de sluitknop is onvoldoende

Op deze pagina opent de klikbare afbeelding onder "Terug naar overzicht" een dialoogvenster met een grotere weergave. De x-knop heeft onvoldoende kleurcontrast. Het grijze (#454545) x-icoon met de zwarte (#191919) achtergrond heeft een contrastverhouding van 1,8:1, onder de vereiste 3,0:1 voor grafische elementen die informatie overbrengen. Hetzelfde probleem staat op andere objectpagina's: https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als slechtziende bezoeker zie ik bleke iconen nauwelijks, want ik wil dat informatieve elementen zoals de sluitknop duidelijk opvallen met de achtergrond.

Hoe te testen

Gebruik Colour Contrast Analyzer (CCA) om de contrasten te meten. Als je de exacte pixel niet kunt selecteren, vind je de kleurwaarde soms via de inspector van de browser. Wat telt is het contrast van het element met de achtergrond.

Oplossing

Zorg dat de iconen een contrastverhouding van minimaal 3,0:1 met hun achtergrond hebben.

#48 - Vergrote afbeeldingsweergave is niet beschikbaar voor toetsenbordgebruikers

Op deze pagina opent de klikbare afbeelding onder "Terug naar overzicht" een dialoogvenster met een grotere weergave. Die geeft een extra vergrote weergave als bezoekers de muisaanwijzer over bepaalde delen van de afbeelding bewegen. Er is echter geen vergelijkbare toetsenbordtoegankelijke methode beschikbaar. Daardoor kunnen bezoekers die het toetsenbord gebruiken niet bij dezelfde vergrote details als muisgebruikers. Hetzelfde probleem staat op andere objectpagina's: https://archeologie.zuid-holland.nl/collectie/27583, https://archeologie.zuid-holland.nl/collectie/48298.

User story

Als bezoeker die alleen het toetsenbord gebruikt, kan ik de vergrote details van een afbeelding niet bekijken omdat dat alleen met de muis kan, want ik wil dezelfde informatie als andere bezoekers.

Hoe te testen

Navigeer alleen met het toetsenbord naar het dialoogvenster en controleer of de vergrote weergave zonder aanwijsapparaat te activeren en te gebruiken is. Controleer of alle informatie die via aanwijzerbediening beschikbaar is, ook via het toetsenbord beschikbaar is.

Oplossing

Bied een toetsenbordtoegankelijke manier om de vergrote afbeeldingsweergave te bekijken. Alle informatie of functies die via aanwijzerbediening beschikbaar zijn, moeten ook beschikbaar zijn voor bezoekers die alleen met het toetsenbord navigeren.

#49 - De taal is niet ingesteld in de metadata

In de metadata van deze PDF is de taal niet ingesteld. Het is belangrijk om de taal in te stellen, zodat hulpsoftware de informatie uit het bestand met de juiste uitspraakregels kan voorlezen. Je stelt dit in via de bestandseigenschappen.

User story

Als blinde bezoeker die PDF's met een schermlezer leest, hoor ik de verkeerde uitspraak omdat er geen taal in de bestandseigenschappen staat, want ik wil dat elke PDF een ingestelde taal heeft zodat mijn schermlezer niet hoeft te gokken.

Hoe te testen

Open de PDF in Adobe Acrobat. Ga naar Bestand → Eigenschappen → Geavanceerd en controleer of bij "Leesopties → Taal" de juiste taal van het document is ingesteld. Lees het document daarna voor met een schermlezer en controleer of de juiste uitspraak wordt gebruikt.

Oplossing

Los het op in Adobe Acrobat:

1. Open het PDF-document in Adobe Acrobat.
2. Ga naar Bestand > Eigenschappen.
3. Ga naar het tabblad Geavanceerd.
4. Selecteer in het veld Taal de juiste taal voor het document, bijvoorbeeld Nederlands (Dutch).
5. Klik op OK en sla het bestand op.

#50 - Structuur van het PDF-document is niet in codes vastgelegd

Dit PDF-document mist codes, waardoor de inhoud niet toegankelijk is voor schermlezers. Door het ontbreken van deze codes kunnen wij de PDF ook niet volledig onderzoeken: alle succescriteria die met de PDF-codelaag te maken hebben (zoals semantische koppen en tekstalternatieven bij afbeeldingen) kunnen we niet beoordelen. Als je dit oplost, kunnen er dus nieuwe toegankelijkheidsproblemen aan het licht komen die nu nog niet zichtbaar zijn.

User story

Als blinde bezoeker die met een schermlezer een PDF opent, vind ik geen koppen of structuur in het document, want ik wil dat een PDF zo is opgebouwd dat ik de inhoud kan begrijpen.

Hoe te testen

Open de PDF in Adobe Acrobat Pro en inspecteer de tagboom (Beeld → Tonen/verbergen → Navigatievensters → Tags). Visuele koppen, lijsten, tabellen en formuliervelden moeten allemaal als juiste tags bestaan (<H1>–<H6>, <L>, <Table> met <TH>/<TR>/<TD>, <Form>). Voer de ingebouwde toegankelijkheidscontrole en PAC (PDF Accessibility Checker) uit voor een automatische scan en controleer daarna of de structuur klopt bij lineair lezen met een schermlezer.

Oplossing

Voeg codes toe aan het document die de structuur van het document weergeven.

#51 - PDF-document heeft geen titel

Dit PDF-document heeft geen titel ingesteld in de bestandseigenschappen. Een PDF hoort een titel te hebben die het doel of de inhoud duidelijk beschrijft, en die titel hoort in de titelbalk te staan in plaats van de bestandsnaam. Dit helpt bezoekers, vooral bezoekers met een beperking, om snel te bepalen of het document relevant is. Je voegt de titel toe of corrigeert die in het bronbestand of in de eigenschappen van het PDF-document.

User story

Als blinde bezoeker die met een schermlezer een PDF opent, wil ik dat mijn schermlezer een duidelijke documenttitel aankondigt, zodat ik weet wat ik open.

Hoe te testen

Open de PDF in een PDF-lezer of toegankelijkheidstool en controleer de documenteigenschappen. Controleer of er een betekenisvolle documenttitel in de PDF-metadata is vastgelegd en of die is ingesteld om in plaats van de bestandsnaam te worden getoond.

Oplossing

Voeg een beschrijvende titel toe aan de bestandseigenschappen van de PDF. Zorg dat de titel in de titelbalk wordt getoond in plaats van de bestandsnaam. De titel moet de inhoud of het doel van het document duidelijk benoemen en bezoekers helpen beslissen of het de moeite waard is om te lezen.

#52 - Koppen zijn niet als kop gemarkeerd

In dit PDF-document zijn alle koppen niet als kop getagd. Zie bijvoorbeeld de teksten "Voorwaarden aanlevering vondsten aan Provinciaal Depot Bodemvondsten Zuid-Holland (PDB)", "Procedure van Overdracht", "Eisen aan aanlevering van documentatie" en andere koppen in het document. Daardoor verschilt de visuele informatiestructuur van de structuur in de tags.

User story

Als blinde bezoeker die een PDF met een schermlezer per kop doorloopt, mis ik visuele koppen omdat mijn schermlezer ze niet als kop herkent, want ik wil dat elke visuele kop als kop wordt aangekondigd.

Hoe te testen

Open de PDF in een PDF-lezer of toegankelijkheidstool en inspecteer de tagstructuur van het document. Controleer of alle visuele koppen zijn gemarkeerd met passende koptags (H1–H6) en of de kophiërarchie de structuur van het document goed weergeeft.

Oplossing

Vervang de P-tags door de H1–H6-tags, zodat de structuur in de tags overeenkomt met wat visueel in het document wordt getoond.

#53 - Lijsten zijn niet als lijst gemarkeerd

In dit PDF-document staan op pagina 2 en 3 meerdere lijsten met opsommingstekens. De juiste opmaak ontbreekt daarbij. Inhoud die eruitziet als lijst, moet ook als lijst zijn gemarkeerd, zodat blinde bezoekers dezelfde informatiestructuur doorkrijgen als ziende bezoekers. Een ander voordeel van een lijst is dat de schermlezer het aantal items aankondigt voordat hij ze voorleest. Zo weet een blinde bezoeker hoeveel informatie er volgt.

User story

Als blinde bezoeker die met een schermlezer een PDF leest, wil ik dat lijsten als lijst zijn gemarkeerd, zodat ik de samenhang tussen de items begrijp en makkelijker door de inhoud navigeer.

Hoe te testen

Open de PDF in een PDF-lezer of toegankelijkheidstool en inspecteer de tagstructuur. Controleer of alle visuele lijsten zijn gemarkeerd met lijsttags (L, LI, Lbl en LBody) en niet als gewone alinea's of tekst met handmatig geplaatste opsommingstekens of nummers.

Oplossing

Markeer de lijst met L-, Li-, Lbl- en LBody-tags.