Verklaring van www.oldebroek.nl

Inhoud

• Samenvatting
• Verklaring
  • Nalevingsstatus
  • Akkoordverklaring
  • Feedback en contactgegevens
  • Aanvullende informatie van Gemeente Oldebroek
• Onderbouwing van de verklaring
  • Onderzoeksresultaten
  • Afwijkingen van de toegankelijkheidsstandaard
  • Andere toegankelijkheidsissues
  • Onevenredige last
• Algemene toelichting
  • Uitleg over de nalevingsstatussen
  • Uitleg over onevenredige last
  • Inhoud buiten de werkingssfeer van het Besluit
  • Links naar bronnen

Onderbouwing van de verklaring

Onderzoeksresultaten

De website www.oldebroek.nl is onderzocht op toegankelijkheid en uit de rapportage blijkt volgens Gemeente Oldebroek dat nog niet aan alle onderstaande kenmerken wordt voldaan:

• De onderzoeksresultaten waarop de claim is gebaseerd zijn beschikbaar via:
  • https://www.oldebroek.nl/Contact/Over_deze_website/Toegankelijkheid/Herinspectie_contentonderzoek_www_oldebroek_nl
    Kenmerken die in de rapportage zijn vastgelegd:
    • Datum: 21-02-2023
    • Type onderzoek: handmatig onderzoek (eventueel deels automatisch)
    • Onderzoek uitgevoerd door: een onafhankelijke derde partij
    • Oké. Gebruikte standaard: EN 301 549 / WCAG 2.1 niveau AA
    • Oké. Actualiteit: voldoet aan de voorwaarde. Uit de rapportage blijkt dat de meet- en onderzoeksgegevens waarop het onderzoek is gebaseerd jonger zijn dan 36 maanden.
    • Oké. Onderzoeksmethode: voldoet aan de voorwaarde. Uit de rapportage blijkt dat bij het handmatige onderzoek een goed gedocumenteerde evaluatiemethode (WCAG-EM of gelijkwaardig) is gebruikt.
    • Oké. Vastlegging: voldoet aan de eisen. Uit de rapportage blijkt dat de onderzoeksresultaten zijn vastgelegd in een voor mensen leesbaar formaat, of in het machineleesbare formaat EARL.
  • https://www.oldebroek.nl/Contact/Over_deze_website/Toegankelijkheid/Toegankelijkheidsonderzoek_Roxit_Rx_Front_CMS
    Kenmerken die in de rapportage zijn vastgelegd:
    • Datum: 01-09-2022
    • Type onderzoek: handmatig onderzoek (eventueel deels automatisch)
    • Onderzoek uitgevoerd door: een onafhankelijke derde partij
    • Oké. Gebruikte standaard: EN 301 549 / WCAG 2.1 niveau AA
    • Oké. Actualiteit: voldoet aan de voorwaarde. Uit de rapportage blijkt dat de meet- en onderzoeksgegevens waarop het onderzoek is gebaseerd jonger zijn dan 36 maanden.
    • Oké. Onderzoeksmethode: voldoet aan de voorwaarde. Uit de rapportage blijkt dat bij het handmatige onderzoek een goed gedocumenteerde evaluatiemethode (WCAG-EM of gelijkwaardig) is gebruikt.
    • Oké. Vastlegging: voldoet aan de eisen. Uit de rapportage blijkt dat de onderzoeksresultaten zijn vastgelegd in een voor mensen leesbaar formaat, of in het machineleesbare formaat EARL.
• De (gecombineerde) onderzoeksresultaten:
  • Oké. Omvatten alle eisen uit hoofdstuk 9 Web (voor websites) of 11 Software (voor mobiele applicaties) van de Europese toegankelijkheidsnorm EN 301 549. De eisen voor websites, mobiele applicaties en downloadbare documenten in deze norm zijn identiek aan de niveau A en AA succescriteria van de wereldwijd toegepaste toegankelijkheidsstandaard WCAG 2.1.
  • Oké. Zijn representatief voor alle content op het hoofddomein en eventuele de sub- en andere domeinen die in de verklaring worden genoemd.
• Niet Oké. Tijdens het onderzoek zijn afwijkingen gevonden op de toegankelijkheidsstandaard, die niet konden worden hersteld voordat het onderzoek werd afgerond.
• Oké. Op basis van de onderzoeksresultaten verklaart Gemeente Oldebroek dat de website gedeeltelijk voldoet aan de toegankelijkheidsstandaard.

(Onder het kopje Uitleg over de nalevingsstatussen worden de kenmerken van de verschillende statussen beschreven).

Afwijkingen van de toegankelijkheidsstandaard

1. SC 1.3.1 - Info en relaties [niveau A]
   • Beschrijving van de afwijking:

     Informatie, structuur en relaties overgebracht door presentatie kunnen door software bepaald worden of zijn beschikbaar in tekst.

   • Oorzaak:

     De zoeksuggesties zijn niet te gebruiken door screenreadergebruikers.

     Bij heronderzoek: De rol combobox is niet toegestaan op een form-element. Nu wordt er verkeerde informatie gegeven aan screenreadergebruikers, en dat maakt het niet duidelijker.

     Voor dit component is documentatie geschreven, waar ook voorbeelden in staan: 3.8 Combo Box.

     Het voert voor dit rapport te ver om uit te schrijven hoe dit component toegankelijk gemaakt kan worden. Test het component bij het bouwen ook met verschillende browser/screenreader-combinaties.

     Zie ook:

     • https://www.w3.org/TR/wai-aria-1.1/#combobox

     Tweede heronderzoek: Dit component ontoegankelijk voor niet-visuele gebruikers, omdat zij er niet van op de hoogte worden gebracht dat de suggesties verschijnen, waardoor ze deze missen. Blijf testen met screenreader.

     Een aantal niet-decoratieve iconen zijn geplaatst met het before/after pseudo-element en CSS content (font icons). Deze iconen kunnen wegvallen voor mensen die andere weergaven van een pagina nodig hebben.

     Dit komt op allerlei pagina's voor, op de homepage bijvoorbeeld bij:

     • Het vergrootglas van de zoekknop in de header
     • Het kruisje van de sluitknop in het calamiteitenblok
     • Het groter-dan-teken dat achter de link 'Nieuws' staat (en ook achter sommige andere links)

     Bij heronderzoek: Oplossing was hier niet om tekst voor screenreaders toe te voegen, maar afbeeldingen niet met CSS te plaatsen. Het gaat erom dat mensen met een eigen stylesheet de afbeelding kunnen blijven waarnemen. Oplossing is om betekenisvolle iconen niet met CSS te plaatsen, maar als img met een alt-tekst. In dat geval kunnen title-attributen, verborgen teksten en aria-labels verwijderd worden. Zie https://www.w3.org/WAI/WCAG21/Techniques/failures/F87

     Bij tweede heronderzoek: Bij de voorbeelden die de vorige keer zijn aangegeven gaat dit nu goed. Helaas blijven er ook nog andere plaatsen waar dit niet goed gaat. BIjvoorbeeld de WhatsApp en telefoon iconen in het locatieobject en de footer, of het icoontje "opleidingsniveau" in het vacatureblok. Ga goed na voor elke afbeelding wat hiermee moet gebeuren.

     Wanneer je bent ingelogd verschijnt het veld 'Uw reactie'. Naast het label staat een link met een vraagteken en verborgen tekst 'Wat moet ik bij "Uw reactie" invullen'. Bij activeren van de link verschijnt de tekst 'Uw reactie, probeer constructief te zijn door ook uit te leggen waarom u iets vindt.' Dat dit gebeurt wordt niet doorgegeven door een screenreader. De focus komt terecht in het veld 'Uw reactie'.

     Dit komt bij meerdere formulieren voor.

     Bij heronderzoek: Het is niet duidelijk waar de helptekst is verschenen. Die staat namelijk in de DOM onder het veld. Hij zou meteen na de knop moeten komen, dan kun je hem wel vinden als je met een screenreader werkt.

     Tweede heronderzoek: implementatie is beter zo. Wel is de status van aria-expanded verkeerd om: het is nu true wanneer de helptekst is ingeklapt.

     Onder het kopje "Commentaar" staan nog twee teksten die structuur aanbrengen. Namelijk de kopjes "Autofill" en "Verder". Deze zijn in de code niet als koppen opgemaakt. Hierdoor ontbreekt de visuele structuur dus voor niet-visuele gebruikers.

     Het advies is om hier ook kopelementen van te maken.

     De kalender om een datum te selecteren is opgemaakt als tabel. Dat is correct voor de data en dagen, maar de controls horen daar niet bij omdat deze geen datarelatie weergeven.

     Het advies is om de controls buiten de code van de tabel aan te bieden.

     Het is voor screenreadergebruikers niet duidelijk welke delen van de kaart bij elkaar horen (knoppen, zoekveld, etc.).

     Dit komt op meerdere plekken met een kaart voor.

     Bij heronderzoek: Kaart van Google, dit kan niet worden aangepast. Omdat dit een toegankelijkheidsprobleem blijft, zal de bevinding blijven staan. Dit dient aangegeven te worden in de toegankelijkheidsverklaring.

     De gebruiker kan snel zien dat er in totaal 4 tabbladen zijn. Een niet-visuele gebruiker kan dit niet waarnemen. Hierdoor weet deze gebruiker niet hoeveel tabbladen er zijn.

     Het advies is om de tabbladen in een lijst te zetten.

     Het tabblad "Nabespreken" heeft een aria-describedby dat verwijst naar een "nabespreken". Dit element is de knop waarmee dit tabblad wordt opgelezen. Hierdoor wordt de tekst "4 nabespreken" eerst opgelezen wanneer de gebruiker op het tabje komt en daarna nog twee keer wanneer de gebruiker naar de inhoud van het tabblad gaat. Drie keer in totaal dus.

     Het advies is om de aria-describedby weg te laten om overbodige herhaling te voorkomen. Dit geldt ook voor de andere tabbladen.

   • Gevolg:

     Gebruikers van screenreaders kunnen sommige informatie/functionaliteiten niet zien of goed gebruiken.

   • Alternatief:
   • Maatregel:

     Het is aan de leverancier van het CMS om de gevonden afwijkingen te verhelpen.

   • Planning voor de uitvoering van de maatregel: 01-09-2023
2. SC 1.3.1 - Info en relaties [niveau A]
   • Beschrijving van de afwijking:

     Informatie, structuur en relaties overgebracht door presentatie kunnen door software bepaald worden of zijn beschikbaar in tekst.

   • Oorzaak:

     In de PDF https://www.oldebroek.nl/dsresource?objectid=da8c49f2-8262-47e8-b3d1-d89f46e1d5dd&type=pdf zijn meerdere teksten opgemaakt als kop maar dit is niet in de code aangegeven. Bijvoorbeeld: "Voorwoord". Een kop moet altijd een heading-tag hebben, bijvoorbeeld H2. Wanneer deze kop met een heading-tag wordt opgemaakt wordt de structurele informatie die de tekst geeft ook overgedragen aan hulpsoftware. Dit komt bijvoorbeeld ook voor bij de kop "Oldebroek voor Mekaar" in PDF https://www.oldebroek.nl/dsresource?objectid=447e0b32-480f-41fa-ba1a-35ad7e001d76&type=pdf&& In PDF https://www.oldebroek.nl/dsresource?objectid=da8c49f2-8262-47e8-b3d1-d89f46e1d5dd&type=pdf zijn bijvoorbeeld op pagina 52 de kolomrijen met een <th> element opgemaakt in plaats van een <td> element. Bijvoorbeeld 'Naam document'. Dit komt bijvoorbeeld ook voor op pagina 55. De kop "12. Bijlage Afkortingen en documenten" op pagina 66 van de onderstaand PDF is met een <h2> element opgemaakt, terwijl dat opgevolgd wordt door een <h1> element. Hierdoor is de koppenstructuur niet in de juiste volgorde geplaatst. https://www.oldebroek.nl/dsresource?objectid=da8c49f2-8262-47e8-b3d1-d89f46e1d5dd&type=pdf

   • Gevolg:

     Blinde bezoekers hebben geen toegang tot alle informatie in het PDF bestand.

   • Alternatief:

     Geen.

   • Maatregel:

     Het originele Word bestand is waar nodig aangepast, maar bij het omzetten naar PDF gaat sommige informatie in de code verloren. Hier kunnen we niks aan doen, omdat we daar niet de juiste software voor in huis hebben.

   • Planning voor de uitvoering van de maatregel: 24-02-2024
3. SC 2.4.3 - Focus volgorde [niveau A]
   • Beschrijving van de afwijking:

     Als in webpagina's sequentieel genavigeerd kan worden en de navigatiesequenties hebben invloed op de betekenis of het gebruik, dan krijgen focusbare componenten de focus in de juiste volgorde waardoor betekenis en bedienbaarheid behouden blijft.

   • Oorzaak:

     Als de video in volledige weergave is geopend dan kan de toetsenbordfocus uit de video speler terwijl de video volledig in beeld blijft.

     Bij heronderzoek: Deze bevinding is nog niet opgelost.

     Tweede heronderzoek: Bevinding is op Chrome inderdaad niet van toepassing. Een makkelijke oplossing lijkt niet mogelijk in dit geval. Wellicht is het opsluiten van de focus af te dwingen met Javascript.

     De focusvolgorde is niet logisch, daardoor is het als toetsenbordgebruiker moeilijk te volgen waar je bent op de pagina.

     Bij heronderzoek: Dit kan niet worden aangepast.

     Tweede heronderzoek: een makkelijke oplossing ligt niet voor de hand. Overweeg een simpelere layout of een slim stukje Javascript om toch een logische volgorde af te dwingen.

     Wanneer de gebruiker een filter aanvinkt herlaadt de pagina. Hierbij gaat de focus weer terug naar het begin van de pagina. Dit maakt het voor toetsenbordgebruikers zeer lastig of zelfs onmogelijk om op meerdere filters te selecteren.

     Het advies is om ofwel de pagina niet te herladen of de focus terug te plaatsen nadat een filter wordt ge(de)selecteerd.

   • Gevolg:

     Toetsenbordgebruikers kunnen bepaalde functionaliteiten van de website niet goed gebruiken.

   • Alternatief:
   • Maatregel:

     Het is aan de leverancier van het CMS om deze bevindingen op te lossen. Op www.oldebroek.nl wordt geen gebruik gemaakt van de videospeler van het CMS, ook gebruiken we geen masonry map.

   • Planning voor de uitvoering van de maatregel: 01-09-2023
4. SC 2.5.3 - Label in naam [niveau A]
   • Beschrijving van de afwijking:

     Bij componenten van de gebruikersinterface met labels die tekst of afbeeldingen van tekst bevatten, bevat de naam de tekst die visueel wordt weergegeven.

   • Oorzaak:

     Onder de kop 'Externe link naar Roxit - nieuw venster' staat een link met zichtbare tekst 'http://www.roxit.nl' en toegankelijke naam 'Externe link naar Roxit - nieuw venster (opent in een nieuw venster, opent externe website)'. De zichtbare tekst maakt geen onderdeel uit van de toegankelijke naam en kan daardoor problemen opleveren voor mensen die spraakbediening gebruiken.

     Bij heronderzoek: Dit is niet opgelost.

     Tweede heronderzoek: Deze oplossing is nog steeds niet juist. Het is belangrijk dat de hele zichtbare naam ook terugkomt in de toegankelijke naam. Alleen "Roxit" is daarvoor dus onvoldoende. Het advies is om de linktekst aan te passen naar "Roxit" en het icoon dat visueel aangeeft dat het om een externe link gaat om te zetten naar een afbeelding met de alt-tekst "Externe pagina". Het alternatief is de gehele visuele linktekst (http://www.roxit.nl) te verwerken in de toegankelijke naam (het aria-label)

   • Gevolg:

     De informatie is niet volledig beschikbaar voor mensen die gebruik maken van spraakbediening.

   • Alternatief:
   • Maatregel:

     Het is aan de leverancier van het CMS om deze afwijking op te lossen.

   • Planning voor de uitvoering van de maatregel: 01-09-2023
5. SC 4.1.3 - Statusberichten [niveau AA]
   • Beschrijving van de afwijking:

     In content die is geïmplementeerd met opmaaktalen kunnen statusberichten door software bepaald worden met behulp van rol (role) of eigenschappen (properties), zodat hulptechnologieën de berichten aan de gebruiker kunnen presenteren zonder dat ze de focus krijgen.

   • Oorzaak:

     De algemene waarschuwing bij het fout invullen van het formulier is rood gekleurd om zo de aandacht te trekken. Het advies is om de focus na het versturen op de algemene foutmelding te zetten, zodat deze tekst voor screenreaders wordt voorgelezen. Of op het invoerveld met een role=alert op de algemene foutmelding.

   • Gevolg:

     Het statusbericht is op de verkeerde plek ingevoerd.

   • Alternatief:

     Geen.

   • Maatregel:

     Het is aan de leverancier van het CMS om deze afwijking op te lossen.

   • Planning voor de uitvoering van de maatregel: 01-09-2023

Andere toegankelijkheidsissues

(geen opgegeven)

Onevenredige last

De maatregelen die Gemeente Oldebroek heeft benoemd leiden niet tot een onevenredige last.

(Zie onder uitleg over onevenredige last voor meer informatie)

---

Algemene toelichting

Uitleg over de nalevingsstatussen

De vooruitgang in digitale toegankelijkheid wordt bepaald aan de hand van nalevingsstatussen, die weergeven hoever een overheidsinstantie is gevorderd met het toegankelijker maken van een website. Voordat de wettelijke verplichting van kracht werd waren er slechts twee statussen: de toegankelijkheidsnorm schreef voor dat een website volledig moest voldoen aan alle toegankelijkheidseisen, met als resultaat status voldoet volledig. In geval het niet kon worden aangetoond dan was de status altijd voldoet niet.

De huidige aanpak kent vijf nalevingsstatussen. Doel is het bereiken van de status voldoet volledig. De statussen voldoet gedeeltelijk en eerste maatregelen genomen zijn tussenstappen op weg naar het einddoel.

De statussen en hun kenmerken zijn:

A: Voldoet volledig

• De overheidsinstantie kan aantonen dat de website of mobiele app volledig aan alle toegankelijkheidseisen uit de norm voldoet.
• De overheidsinstantie voldoet zowel aan de wettelijke verplichting als aan de norm.
• Het in de wettelijke verplichting vastgelegde doel is behaald.

B: Voldoet gedeeltelijk (= in control verklaring)

• De overheidsinstantie kan aantonen dat er een actueel, volledig en juist beeld is van de toegankelijkheid van de website of mobiele app.
• Er wordt nog niet voldaan aan alle toegankelijkheidseisen uit de norm.
• De overheidsinstantie heeft concrete verbetermaatregelen benoemd en een planning gemaakt om de afwijkingen te herstellen.
• De overheidsinstantie is daardoor in control over de toegankelijkheid van de website of mobiele app.
• De overheidsinstantie voldoet wel aan de wettelijke verplichting, maar nog niet volledig aan de norm.

C: Eerste maatregelen genomen

• Er is nog geen goed beeld van de toegankelijkheid van de website of mobiele app.
• De overheidsinstantie heeft concrete verbetermaatregelen genomen om dat beeld te krijgen.
• De overheidsinstantie voldoet wel aan de wettelijke verplichting, maar niet aan de norm.

D: Voldoet niet

• Er is geen goed beeld van de toegankelijkheid van de website of mobiele app.
• De overheidsinstantie heeft geen concrete verbetermaatregelen benoemd om inzicht te krijgen in de (mate van) toegankelijkheid.
• De overheidsinstantie voldoet enkel aan de wettelijke verplichting om een toegankelijkheidsverklaring te publiceren.
• Omdat de wettelijke verplichting voorschrijft dat overheidsinstanties de noodzakelijke maatregelen nemen om hun websites en mobiele applicaties toegankelijker te maken worden de overheidsinstantie aangespoord om binnen een bepaalde termijn concrete maatregelen te benoemen, inclusief planning.

E: Geen toegankelijkheidsverklaring gepubliceerd

• De overheidsinstantie heeft voor de website of mobiele applicatie geen toegankelijkheidsverklaring gepubliceerd.
• De overheidsinstantie voldoet niet aan de wettelijke verplichting om een toegankelijkheidsverklaring te publiceren.
• Omdat de wettelijke verplichting voorschrijft dat overheidsinstanties de noodzakelijke maatregelen nemen om hun websites en mobiele applicaties toegankelijker te maken wordt de overheidsinstantie aangespoord om op korte termijn een toegankelijkheidsverklaring te publiceren waarin concrete maatregelen zijn benoemd, inclusief planning.

Het uitgangspunt is dat verbetermaatregelen worden benoemd, ingepland en uitgevoerd. En dat daarmee wordt doorggeaan totdat volledig aan alle toegankelijkheids is voldaan.
Als een website lange tijd in een status blijft hangen, dan wordt aan de beleidsmatige eis toegankelijker maken niet langer voldaan.

Uitleg over onevenredige last

Het Tijdelijk besluit digitale toegankelijkheid overheid staat overheidsinstanties toe om gebruik te maken van de mogelijkheid om afzonderlijke eisen uit de toegankelijkheidsstandaard - tijdelijk - niet toe te passen, als dit voor hen onevenredig belastend is.

Met de uitzonderingsmogelijkheid 'onevenredige last' dient zorgvuldig te worden omgegaan; het ontbreken van prioriteit, tijd of kennis bij een overheidsinstantie zijn geen legitieme redenen om de toegankelijkheidsstandaard niet toe te passen.

Zie voor de formele, geldende tekst artikel 3, lid 2 tot en met 4 en de toelichting bij artikel 3 van het Tijdelijk besluit digitale toegankelijkheid overheid.

Inhoud die buiten de werkingssfeer valt van het Besluit

Het Tijdelijk besluit digitale toegankelijkheid overheid is niet van toepassing op de volgende content van websites en mobiele applicaties:

• Kantoorbestandsformaten die zijn gepubliceerd voor 23 september 2018, tenzij dergelijke content nodig is voor actieve administratieve processen met betrekking tot de door de betrokken overheidsinstantie vervulde taken;
• Vooraf opgenomen, op tijd gebaseerde media die zijn gepubliceerd voor 23 september 2020;
• Live uitgezonden, op tijd gebaseerde media;
• Onlinekaarten en onlinekarteringsdiensten, mits essentiële informatie op navigatiekaarten op een toegankelijke, digitale wijze wordt verstrekt;
• Van derden afkomstige content die niet door de betrokken overheidsinstantie wordt gefinancierd of ontwikkeld en evenmin onder haar verantwoordelijkheid valt;
• Reproducties van stukken uit erfgoedcollecties die niet volledig toegankelijk kunnen worden gemaakt om redenen van bewaring, authenticiteit of het ontbreken van geautomatiseerde en kostenefficiënte oplossingen om toegankelijkheid te bewerkstelligen;
• Content die enkel beschikbaar is voor een gesloten gebruikersgroep en die is gepubliceerd voor 23 september 2019, tot de betreffende website ingrijpend wordt herzien;
• Content van websites en mobiele applicaties die niet noodzakelijk is voor actieve administratieve processen en die niet wordt aangepast na 23 september 2019.

Bron: Artikel 2, tweede lid van het Tijdelijk besluit digitale toegankelijkheid overheid.

Links naar bronnen

In deze verklaring wordt gerefereerd aan verschillende bronnen. Onderstaande lijst bevat de links naar deze bronnen.

• Nederlandse regelgeving
  • Tijdelijk besluit digitale toegankelijkheid overheid: https://zoek.officielebekendmakingen.nl/stb-2018-141.html
• Europese regelgeving waarop de Nederlandse regelgeving is gebaseerd
  • Europese Richtlijn 2016/2102: https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:32016L2102
  • Modeltoegankelijkheidsverklaring: https://eur-lex.europa.eu/legal-content/NL/TXT/?uri=CELEX:32018D1523
• Gerefereerde specificaties
  • EN 301 549 v3.2.1, hoofdstuk 9 Web (voor websites) of 11 Software (voor mobiele applicaties): https://www.etsi.org/deliver/etsi_en/301500_301599/301549/03.02.01_60/en_301549v030201p.pdf
    Zie voor aanvullende informatie ook tabel A.1 (voor websites) en A.2 (voor mobiele applicaties), beide in Bijlage A.
  • WCAG 2.1: https://www.w3.org/WAI/standards-guidelines/wcag/
  • WCAG-EM 1.0: https://www.w3.org/WAI/test-evaluate/conformance/
  • ACT Rules Format 1.0: https://www.w3.org/WAI/standards-guidelines/act/
  • EARL 1.0: https://www.w3.org/WAI/standards-guidelines/earl/

template versie 20211209