Verklaring van Mijn Kadaster

Status toegankelijkheid https://mijn.kadaster.nl

Dienst voor het kadaster en de openbare registers is wettelijk verplicht om deze website te laten voldoen aan het Besluit digitale toegankelijkheid overheid.

De status van deze website is: B - voldoet gedeeltelijk ? - Ga naar de informatie over de nalevingsstatussen

De status is toegekend op basis van een eigen verklaring,
die voor het laatst is bijgewerkt op 27-09-2022

  • De onderbouwing bij deze eigen verklaring is gecontroleerd.
    Daaruit bleek dat de onderbouwing toereikend is om door een toezichthouder inhoudelijk te kunnen worden beoordeeld.
    Meer over de controle door Logius

Op deze pagina kunt u:

Inhoud

Verklaring

Dienst voor het kadaster en de openbare registers streeft ernaar om de eigen online informatie en dienstverlening toegankelijk te maken, overeenkomstig het Tijdelijk besluit digitale toegankelijkheid overheid.
Deze toegankelijkheidsverklaring is van toepassing op de inhoud van de website Mijn Kadaster.

  • hoofddomein:
  • subdomeinen en andere domeinen die behoren tot de website:
    • (niet van toepassing)

Een overzicht van alle websites, mobiele applicaties en verklaringen van Dienst voor het kadaster en de openbare registers is beschikbaar via de link https://www.kadaster.nl/toegankelijkheidsverklaring

Nalevingsstatus: voldoet gedeeltelijk

Uit de door Dienst voor het kadaster en de openbare registers gepubliceerde informatie blijkt dat de website Mijn Kadaster gedeeltelijk voldoet aan het Tijdelijk besluit digitale toegankelijkheid overheid.

Uit toegankelijkheidsonderzoek is gebleken dat nog niet aan alle eisen wordt voldaan. Voor elke afzonderlijke afwijking van de eisen is de oorzaak bekend en is het gevolg beschreven, zijn maatregelen genomen om de afwijking te kunnen opheffen EN wordt een concrete datum genoemd waarop de maatregelen zullen zijn uitgevoerd.

In de toelichting, onder het kopje onderbouwing van de verklaring, wordt aangegeven hoe ver Dienst voor het kadaster en de openbare registers is gevorderd met de toegankelijkheid van Mijn Kadaster en welke noodzakelijke maatregelen worden genomen om de website toegankelijker te maken.

De kenmerken van de verschillende statussen worden beschreven in de toelichting, onder het kopje Uitleg over de nalevingsstatussen.

Akkoordverklaring

Deze verklaring is op 21-09-2022 getekend voor 'gezien en akkoord' door een tekenbevoegd functionaris van Dienst voor het kadaster en de openbare registers .
Functie: Manager Online.

De actualiteit, volledigheid en juistheid van deze verklaring zijn voor het laatst herzien op 27-09-2022.

Feedback en contactgegevens

Loopt u tegen een toegankelijkheidsprobleem aan? Of heeft u een vraag of opmerking over toegankelijkheid?
Neem dan contact op via [online@kadaster.nl].

Wat kunt u van ons verwachten?

  • Binnen 5 werkdagen krijgt u een ontvangstbevestiging.
  • We informeren u over de voortgang en de uitkomst.
  • Binnen 3 weken is uw verzoek afgehandeld.

Handhavingsprocedure

Bent u niet tevreden met de manier waarop uw klacht is behandeld? Of hebben we niet op tijd gereageerd?
Dan kunt u [contact opnemen met de Nationale Ombudsman].

Aanvullende informatie van Dienst voor het kadaster en de openbare registers

De streefdatum waarop de website volledig zal voldoen: 01-04-2023.

Onderbouwing van de verklaring

Onderzoeksresultaten

  • Oké. De status van de website Mijn Kadaster : voldoet gedeeltelijk

De website Mijn Kadaster is onderzocht op toegankelijkheid en uit de rapportage blijkt volgens Dienst voor het kadaster en de openbare registers dat nog niet aan alle onderstaande kenmerken wordt voldaan:

  • De onderzoeksresultaten waarop de claim is gebaseerd zijn beschikbaar via:
    • https://www.kadaster.nl/documents/1953498/45343439/2022-07-14+Toegankelijkheidsonderzoek+Mijn+Kadaster+versie+2.0.pdf/53a4343f-a217-3c32-c50b-b785bd884089?t=1663753167900
      Kenmerken die in de rapportage zijn vastgelegd:
      • Datum: 14-07-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 Dienst voor het kadaster en de openbare registers 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.1.1 - Niet-tekstuele content [niveau A]
    • Beschrijving van de afwijking:

      Alle niet-tekstuele content die aan de gebruiker wordt gepresenteerd, heeft een tekstalternatief dat een gelijkwaardig doel dient. […]

    • Oorzaak:

      In het chatvenster kan een venster geopend worden waar emoji's gekozen kunnen worden. Deze emoji's hebben geen unieke naam. Een screen reader (NVDA) presenteert ze als 'afbeelding klikbaar emoji-icon'.

      Voor mensen die blind zijn, zijn de emoji's niet van elkaar te onderscheiden omdat ze geen unieke alternatieve tekst hebben.

      Geef de emoji's een unieke alternatieve tekst.

      Als het chatvenster geopend is dan is er een groen bolletje zichtbaar naast de foto van de medewerker. Dit bolletje geeft een indicatie dat de persoon aan de andere kant van de chat online is. Dit bolletje heeft geen tekstueel alternatief.

      Mensen die blind zijn missen deze informatie omdat de alternatieve tekst voor dit visuele element ontbreekt.

      Voeg een alternatieve tekst toe. Bij een img-element kan dit via een alt tekst. Bij een svg-element kan dit via een title tag binnen de svg-tag. Er zou ook een screen reader only tekst geplaatst kunnen worden.

    • Gevolg:

      Voor mensen die blind zijn, zijn de emoji's niet van elkaar te onderscheiden omdat ze geen unieke alternatieve tekst hebben.

    • Alternatief:

      Gebruikers kunnen ook telefonisch contact opnemen, e-mailen of chatten zonder emoji's.

    • Maatregel:

      Betreft een externe partij, er is inmiddels contact opgenomen met het verzoek om dit te verhelpen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  2. SC 1.1.1 - Niet-tekstuele content [niveau A]
    • Beschrijving van de afwijking:

      Alle niet-tekstuele content die aan de gebruiker wordt gepresenteerd, heeft een tekstalternatief dat een gelijkwaardig doel dient. […]

    • Oorzaak:

      Als het chatvenster geopend is dan is er een groen bolletje zichtbaar naast de foto van de medewerker. Dit bolletje geeft een indicatie dat de persoon aan de andere kant van de chat online is. Dit bolletje heeft geen tekstueel alternatief.

      Mensen die blind zijn missen deze informatie omdat de alternatieve tekst voor dit visuele element ontbreekt.

      Voeg een alternatieve tekst toe. Bij een img-element kan dit via een alt tekst. Bij een svg-element kan dit via een title tag binnen de svg-tag. Er zou ook een screen reader only tekst geplaatst kunnen worden.

      In het chatvenster kan een venster geopend worden waar emoji's gekozen kunnen worden. Deze emoji's hebben geen unieke naam. Een screen reader (NVDA) presenteert ze als 'afbeelding klikbaar emoji-icon'.

      Voor mensen die blind zijn, zijn de emoji's niet van elkaar te onderscheiden omdat ze geen unieke alternatieve tekst hebben.

      Geef de emoji's een unieke alternatieve tekst.

    • Gevolg:

      Mensen die blind zijn missen deze informatie omdat de alternatieve tekst voor dit visuele element ontbreekt.

    • Alternatief:

      hier is momenteel geen alternatief voor.

    • Maatregel:

      Betreft een externe partij, er is inmiddels contact opgenomen met het verzoek om dit te verhelpen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  3. 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 naam van knop 'scherm delen' binnen het chatvenster heeft geen goed label: 'knop aan-uitaan-uit scherm delen'.

      Dit maakt de knop lastig te begrijpen voor mensen die blind zijn.

      Het advies is om de tekst 'aan-uit' weg te halen uit het label. Of de knop actief is of niet wordt als via andere attributen op de knop doorgegeven. De screen reader zal dan ongeveer dit presenteren: "knop scherm delen uitgeschakeld". Of 'ingeschakeld' als scherm delen actief is.

      Op de dashboard pagina onder de kop Handige link staan drie links. Deze links zijn makkelijker te navigeren als ze in een ongeordende lijst staan. Omdat dit visueel ook niet zo is, is dit niet af te keuren onder WCAG. Het zou de gebruikservaring kunnen verbeteren als deze links in een lijst zouden staan.

      De knop om het dropdown-menu met de naam van de gebruiker te sluiten komt twee keer in de code voor. De eerste knop om het menu te openen is niet dezelfde knop als de knop om hem te sluiten. Beide blijven echter beschikbaar voor mensen die met een toetsenbord door de pagina gaan. De knop om te sluiten geeft nu niet de status van het menu door (open of gesloten).

      Haal de knop om te sluiten weg uit de volgorde en zorg dat het menu direct onder de knop om het menu te openen komt te staan in de volgorde. Met een knop kan het menu dan geopend en gesloten worden.

      Bij heronderzoek:

      Dit punt is nog steeds een probleem voor screenreadergebruikers. Het is niet duidelijk wat de twee knoppen doen, en ze zijn tegelijkertijd beschikbaar voor screenreadergebruikers. Het toevoegen van 'Toggle' en 'sluiten' maakt het voor hen niet duidelijker wat de knoppen doen.

      Het venster om een nieuwe gebruiker toe te voegen bevat een formulier. Dit formulier is in de code gemarkeerd als een section en niet als een form. Hierdoor ontbreekt context voor mensen die blind zijn.

      Het is robuuster om een formulier altijd in een form-element te zetten. Van deze techniek is het zeker dat het goed werkt met hulpapparatuur en browsers. De huidige implementatie werkt ook, daarom is dit als een opmerking genoteerd.

      De modal-vensters beginnen met een h2 kop. Een modal mag je zien als een nieuw document waardoor een h1 kop beter zou passen als eerste kop op de pagina. Dit is een opmerking, geen bevinding onder WCAG.

    • Gevolg:

      Dit maakt de knop lastig te begrijpen voor mensen die blind zijn.

    • Alternatief:

      Momenteel is hier geen alternatief voor.

    • Maatregel:

      Betreft een externe partij, er is inmiddels contact opgenomen met het verzoek om dit te verhelpen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  4. 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 het zij-menu om de gebruiker te sluiten zitten 2 knoppen. Het is niet duidelijk wat deze doen voor mensen die een screen reader gebruiken.

    • Gevolg:

      Gebruikers met een screenreader weten niet goed wat deze knoppen doen.

    • Alternatief:

      Er is hiervoor geen alternatief.

    • Maatregel:

      Knoppen onderling onderscheidbaar maken en functie duidelijk maken.

    • Planning voor de uitvoering van de maatregel: 01-04-2023
  5. SC 1.4.11 - Contrast van niet-tekstuele content [niveau AA]
    • Beschrijving van de afwijking:

      De visuele weergave van het volgende heeft een contrastverhouding van ten minste 3:1 ten opzichte van aangrenzende kleuren:

      • Componenten van de gebruikersinterface: Visuele informatie die vereist is om componenten van de gebruikersinterface en statussen te identificeren, met uitzondering van inactieve componenten of componenten waarvan de weergave van de component wordt bepaald door de user agent en niet wordt aangepast door de auteur;
      • Grafische objecten: Delen van afbeeldingen die vereist zijn om de content te begrijpen, behalve wanneer een specifieke weergave van afbeeldingen essentieel is voor de informatie die wordt overgebracht.
    • Oorzaak:

      De rand van het invoerveld om een bericht te schrijven heeft een te laag contrast met de omliggende kleur. De rand met kleurcode #CCCEDE heeft de contrastwaarde van 1,6:1 met de witte achtergrond (kleurcode #FFFFFF). Dit is te laag, minimaal moet dit 3:1 zijn.

      Het icoon om een bericht te versturen heeft ook te laag contrast met de achtergrond.

    • Gevolg:

      Minder goed leesbaar voor mensen met een visuele beperking.

    • Alternatief:

      Er is momenteel geen alternatief.

    • Maatregel:

      Betreft externe leverancier, er is inmiddels contact opgenomen met het verzoek om dit te verhelpen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  6. 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:

      De focus indicator van het toetsenbord kan buiten het chat venster komen wanneer deze geopend is. Hierdoor is de plek van de focus indicator niet altijd goed te volgen.

      Voor mensen die met een toetsenbord moeten werken is het niet altijd duidelijk waar hun focus indicator is. Dit maakt de pagina lastiger te gebruiken.

      Zorg dat de focus niet buiten het chatvenster kan komen als het chatvenster geopend is. Het venster kan dan weer gesloten worden via de 'minimaliseren' of 'sluiten' knop van het venster. Overweeg het venster ook te laten minimaliseren na gebruik van de ESC-toets.

    • Gevolg:

      Voor mensen die met een toetsenbord moeten werken is het niet altijd duidelijk waar hun focus indicator is. Dit maakt de pagina lastiger te gebruiken.

    • Alternatief:

      Er is momenteel geen alternatief.

    • Maatregel:

      Betreft een externe leverancier, er staat een verzoek uit om dit op te lossen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  7. 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:

      In het overzicht waar een gebruiker applicaties kan toekennen, gaat de focus niet naar de juiste, logische plek.

    • Gevolg:

      Mensen met toetsenbordbediening gaan hierdoor wat omslachtig door het scherm heen en moeten meer handelingen verrichten dan nodig.

    • Alternatief:

      Er is momenteel geen alternatief.

    • Maatregel:

      Focus aanpassen

    • Planning voor de uitvoering van de maatregel: 01-04-2023
  8. SC 2.4.6 - Koppen en labels [niveau AA]
    • Beschrijving van de afwijking:

      Koppen en labels beschrijven het onderwerp of doel.

    • Oorzaak:

      De knop om het gebruikersmenu te openen heeft visueel het label '<achternaam>' maar omdat er een aria-label="Open het gebruikersmenu" aan de knop is toegevoegd, wordt dit visuele label overschreven. Met stembediening is de knop nu niet goed te activeren, omdat de zichtbare naam afwijkt van de naam in de code.

      Voor mensen met een motorische beperking die via stembediening moeten werken is de knop niet goed te activeren.

      Het advies is om de naam in het aria-label aan te passen: aria-label="<gebruikersnaam> gebruikersmenu" De knop krijgt dan de naam: <achternaam> Gebruikersmenu.

      Bij heronderzoek:

      De menuknop heet nu 'Toggle <gebruikersnaam> gebruikersmenu'. Daarmee maakt het zichtbare label van de knop deel uit van de toegankelijkheidsnaam. Dat is goed. Alleen de functie van de knop komt niet overeen met de werkelijke functie. Het is namelijk geen toggle-knop, maar een knop die in- en uitklapt.

      Deze bevinding is daarom verplaatst naar 2.4.6, hij hangt bovendien samen met de bevinding onder 1.3.1.

    • Gevolg:

      Voor mensen met een motorische beperking die via stembediening moeten werken is de knop niet goed te activeren.

    • Alternatief:

      Er kan contact opgenomen worden met de klantenservice als men niet door deze stap heen komt.

    • Maatregel:

      Functie van de knop aanpassen

    • Planning voor de uitvoering van de maatregel: 01-04-2023
  9. SC 2.4.7 - Focus zichtbaar [niveau AA]
    • Beschrijving van de afwijking:

      Elke gebruikersinterface die met een toetsenbord te bedienen is, heeft een bedieningswijze waarbij de indicator van de toetsenbordfocus zichtbaar is.

    • Oorzaak:

      De focus cursor van het toetsenbord kan uit het mobiele menu gaan waardoor deze niet meer zichtbaar is.

      Mensen die met het toetsenbord moeten werken moeten altijd hun focus cursor kunnen zien, dat is nu niet het geval.

      Zorg ervoor dat de rest van de pagina niet bereikbaar is voor de focus als het mobiele menu geopend is. Dit kan bijvoorbeeld via JavaScript. Zet dan de focus na het laatste element op het eerste element in de focus, en andersom. Na het sluiten van het menu moet de focus op de knop komen die het menu geopend heeft.

      Bij heronderzoek: Voor toetsenbordgebruikers werkt dit nu goed. Als je met een screenreader werkt, kan de toegankelijkheidsfocus nog steeds uit het menu.

      Dit kan worden opgelost door alle elementen die geen toetsenbordfocus meer kunnen krijgen, ook uit de accessibility tree te halen. Dit kan met aria-hidden="true". Bedenk hierbij dat dit attribuut overerft naar onderliggende elementen.

      De knop om het chatvenster te activeren heeft geen duidelijke styling die duidelijk maakt dat het element de focus heeft. De eerste tab-stop op dit element heeft wel een styling, maar die activeert het venster niet. Daarna ontbreekt de styling.

      Voor mensen die met een toetsenbord moeten werken is het niet duidelijk waar de focus cursor precies is en hierdoor is het niet duidelijk waar ze zijn. Dit maakt het openen en gebruiken van de chat-functie ontoegankelijk.

      Geef de knop om het venster te openen een duidelijke focus styling zodat het direct duidelijk is waar de focus is. Zorg er ook voor dat als de elementen binnen het chatvenster de focus hebben, ze een duidelijke focus styling hebben.

    • Gevolg:

      Bij heronderzoek: Voor toetsenbordgebruikers werkt dit nu goed. Als je met een screenreader werkt, kan de toegankelijkheidsfocus nog steeds uit het menu.

    • Alternatief:

      Er is momenteel geen alternatief voor.

    • Maatregel:

      Oplossing implementeren zoals voorgesteld door auditor.

    • Planning voor de uitvoering van de maatregel: 01-04-2023
  10. SC 2.4.7 - Focus zichtbaar [niveau AA]
    • Beschrijving van de afwijking:

      Elke gebruikersinterface die met een toetsenbord te bedienen is, heeft een bedieningswijze waarbij de indicator van de toetsenbordfocus zichtbaar is.

    • Oorzaak:

      De knop om het chatvenster te activeren heeft geen duidelijke styling die duidelijk maakt dat het element de focus heeft. De eerste tab-stop op dit element heeft wel een styling, maar die activeert het venster niet. Daarna ontbreekt de styling.

      Voor mensen die met een toetsenbord moeten werken is het niet duidelijk waar de focus cursor precies is en hierdoor is het niet duidelijk waar ze zijn. Dit maakt het openen en gebruiken van de chat-functie ontoegankelijk.

      Geef de knop om het venster te openen een duidelijke focus styling zodat het direct duidelijk is waar de focus is. Zorg er ook voor dat als de elementen binnen het chatvenster de focus hebben, ze een duidelijke focus styling hebben.

      De focus cursor van het toetsenbord kan uit het mobiele menu gaan waardoor deze niet meer zichtbaar is.

      Mensen die met het toetsenbord moeten werken moeten altijd hun focus cursor kunnen zien, dat is nu niet het geval.

      Zorg ervoor dat de rest van de pagina niet bereikbaar is voor de focus als het mobiele menu geopend is. Dit kan bijvoorbeeld via JavaScript. Zet dan de focus na het laatste element op het eerste element in de focus, en andersom. Na het sluiten van het menu moet de focus op de knop komen die het menu geopend heeft.

      Bij heronderzoek: Voor toetsenbordgebruikers werkt dit nu goed. Als je met een screenreader werkt, kan de toegankelijkheidsfocus nog steeds uit het menu.

      Dit kan worden opgelost door alle elementen die geen toetsenbordfocus meer kunnen krijgen, ook uit de accessibility tree te halen. Dit kan met aria-hidden="true". Bedenk hierbij dat dit attribuut overerft naar onderliggende elementen.

    • Gevolg:

      Voor mensen die met een toetsenbord moeten werken is het niet duidelijk waar de focus cursor precies is en hierdoor is het niet duidelijk waar ze zijn. Dit maakt het openen en gebruiken van de chat-functie ontoegankelijk.

    • Alternatief:

      Er is hiervoor geen alternatief. Mensen kunnen telefonsich contact opnemen.

    • Maatregel:

      Betreft een externe leverancier, deze is verzocht om dit op te lossen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  11. SC 4.1.2 - Naam, rol, waarde [niveau A]
    • Beschrijving van de afwijking:

      Voor alle componenten van de gebruikersinterface (inclusief, maar niet uitsluitend voor formulierelementen, links en door scripts gegenereerde componenten), kunnen de naam (name) en rol (role) door software bepaald worden; toestanden (states), eigenschappen (properties) en waarden (values) die door de gebruiker ingesteld kunnen worden, kunnen door software ingesteld worden; en kennisgeving van veranderingen in deze items is beschikbaar voor user agents, met inbegrip van hulptechnologieën.

    • Oorzaak:

      De knop om het venster met alle emoji's te openen, heeft geen naam. Het is een div-element met daarin een span-element. Het icoontje komt uit een ::before pseudo-element. Geen van deze elementen geeft het element een rol die bruikbaar is voor hulpapparatuur.

      Mensen die blind zijn horen alleen 'klikbaar' maar weten dan niet waar ze precies op gaan klikken.

      Geef de knop een toegankelijke naam. Maak ook duidelijk wat de rol van het element is (knop) en of het venster geopend of gesloten is (aria-expanded).

      De chat is hierdoor ook niet volledig met het toetsenbord te bedienen. Zo is het bijvoorbeeld onmogelijk om met het toetsenbord een emoticon te kiezen. Dit is ook een bevinding onder 2.1.1 Toetsenbord maar is daar niet nogmaals genoteerd.

      Het openen van een nieuw venster is beter te begrijpen voor mensen die blind zijn als vensters met role="dialog" een naam hebben. Dit wordt dan gepresenteerd zodra het venster geopend wordt.

      Overweeg het element met deze rol te voorzien van aria-labelledby="<id van koptekst in dialoog>". Zo krijgt het venster een naam die gepresenteerd wordt. Mensen die blind zijn weten dan beter wat ze kunnen verwachten in het venster zonder er zelf naar te zoeken.

    • Gevolg:

      Mensen die blind zijn horen alleen 'klikbaar' maar weten dan niet waar ze precies op gaan klikken.

    • Alternatief:

      Er is geen alternatief beschikbaar.

    • Maatregel:

      Betreft een externe partij; deze is verzicht dit op te lossen.

    • Planning voor de uitvoering van de maatregel: 01-01-2023
  12. 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 functie om te chatten geeft meerdere statusmeldingen die niet goed worden doorgegeven aan hulpapparatuur:

      • Geen melding wanneer chat aanwezig/ afwezig is
      • geen directe melding bij ontvangen nieuw bericht met screen reader focus buiten iframe
      • geen directe melding bij ontvangen nieuw bericht met screen reader focus binnen iframe

      Mensen die blind zijn krijgen dus geen updates wanneer er iets verandert. Een nieuw bericht van de medewerker wordt bijvoorbeeld niet gemeld. Dit maakt de chat lastiger te gebruiken voor mensen die blind zijn.

      Zet de delen die veranderen in een aria-live region zodat veranderingen automatisch worden doorgegeven aan hulpapparatuur.

      In het venster om een gebruiker toe te voegen worden foutmeldingen getoond als de velden niet goed worden ingevuld. Deze worden via aria-live gepresenteerd aan hulpapparatuur maar de huidige implementatie werkt niet helemaal goed. Hierdoor worden de meldingen niet doorgegeven.

      Mensen die blind zijn horen de foutmeldingen niet zodra ze verschijnen. Ze moeten ze zelf vinden.

      Zet bij elk veld waar een melding kan verschijnen een div-element met role="alert". Dit maakt een live region die, zodra er een melding in gezet wordt, de nieuwe content direct presenteert aan een screen reader. De huidige span-elementen met daarin de meldingen moeten dus in deze div-elementen geplaatst worden.

      Bij heronderzoek:

      Het div-element heeft nu zowel de attributen role="alert" als aria-live="polite". Het tweede attribuut kan nu het beste worden verwijderd, omdat het eerste attribuut een impliciete aria-live-waarde heeft van assertive en daardoor voorrang heeft. Het verwijderen van aria-live="polite" voorkomt dat het problemen oplevert mocht de code bijgewerkt worden.

      Deze bevinding is veranderd in een opmerking.

    • Gevolg:

      Mensen die blind zijn krijgen geen updates wanneer er iets verandert. Een nieuw bericht van de medewerker wordt bijvoorbeeld niet gemeld. Dit maakt de chat lastiger te gebruiken voor mensen die blind zijn.

    • Alternatief:

      Er is hier geen alternatief voor.

    • Maatregel:

      Betreft een externe leverancier; deze is verzocht dit op te lossen.

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

Andere toegankelijkheidsissues

(geen opgegeven)

Onevenredige last

De maatregelen die Dienst voor het kadaster en de openbare registers 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 doorgegaan totdat volledig aan alle toegankelijkheidseisen 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.

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

template versie 20211209