Rapportage digitale toegankelijk

Transcriptie

1 Rapportage digitale toegankelijk 22 februari 2016 Gemeente Eindhoven

2 Inleiding Dit document is de samenvatting van een onderzoek in januari 2015 naar de toegankelijkheid van de website van de gemeente Eindhoven. Doel van dit onderzoek is het verkrijgen van inzicht in de toegankelijkheid van de eigen website, maar ook de geleverde diensten van derden. Ook deze diensten vallen immers onder de gemeentelijke verantwoordelijkheid. De gemeentelijke verantwoordelijkheid omvat alle websites en webapps waar de gemeente eigenaar of opdrachtgever van is. Scope In overleg met de gemeente Eindhoven heeft Atticus besloten een toegankelijkheidsscan te doen van een elftal pagina s. Er is bij het selecteren van deze 11 pagina s met zorg gekozen voor 11 uiteenlopende paginatypes of diensten van derden, om een zo goed en compleet mogelijk beeld te krijgen van de toegankelijkheid. 1. Homepage 2. Categorie welkomstpagina 3. Landingpagina 4. Productaanvraag* (meerdere states) 5. Bekendmakingen 6. Melding maken* (meerdere states) 7. Zoekfunctie en -resultatenpagina 8. Afvalkalender* 9. Ingelogde omgeving met DigiD (meerdere states) 10. Andere taal 11. Formulier door GX (leverancier) * * Externe leveranciers De 11 pagina s zijn getoetst aan de hand van de internationale toegankelijkheidsnorm WCAG 2.0 niveau AA (Web Content Accessibility Guidelines). Deze norm is opgesteld door het W3C (World Wide Web Consortium) en is door de Europese Unie geadopteerd als toegankelijkheidsstandaard. 1

3 Er zijn in dit onderzoek geen pdf s of andere databestanden getoetst, omdat de gemeente Eindhoven heeft aangegeven dit op een ander moment te willen controleren. Het heeft wel degelijk aandacht binnen de organisatie, ondanks dat men op de hoogte is van vooralsnog ontoegankelijke documenten. Belangrijkste bevinding De bevindingen uit het onderzoek hebben - met uitzondering van twee of drie kleine terugkerende redactionele fouten - bovenal betrekking op technische aspecten van de pagina s. De pagina s op het hoofddomein (x.eindhoven.nl) bevatten her en der wat slordigheidsfouten in de broncode, en er zijn wat onderliggende zaken die ook niet eenvoudig meer zijn op te lossen zonder hoge kosten, zoals bijvoorbeeld het herschalen van tekst binnen de website. Het grootste gedeelte van de bevindingen zijn echter gevonden in de eformulieren van SIM, de afvalkalender van Cure, en een formulier in de GX-omgeving. Er kan worden geconcludeerd dat bij het selecteren van leveranciers onvoldoende aandacht is gegeven aan de toegankelijkheid van de betreffende dienstverlening, omdat alle bevindingen betrekking hebben op de technische basis van de betreffende diensten. We raden ten zeerste aan in toekomstige samenwerkingen met leveranciers toegankelijkheid bovenaan de agenda te plaatsen, omdat het vrijwel onmogelijk is op een later moment deze diensten met terugwerkende kracht toegankelijk te maken. 2

4 Redactionele bevindingen Er zijn twee redactionele bevindingen die op meerdere pagina s voorkomen, en in beide gevallen ook verklaarbaar. Het gaat om de volgende succescriteria: Tekstalternatieven Lange tijd werd in algemene zin gedacht dat álle afbeeldingen op een webpagina een alt-tekst moeten hebben. Dat is een brede misvatting, omdat alleen afbeeldingen een alt-tekst nodig hebben, wanneer ze onderdeel uitmaken van de inhoud van de pagina, en de inhoud niet óók in tekst beschikbaar is. Denk hierbij aan bijvoorbeeld een een afbeelding van een grafiek, of een foto waarbij de inhoud van de foto relevant is voor het begrijpen van de rest van de tekst. Het gaat dan bijvoorbeeld om de decoratieve afbeeldingen op overzichtspagina s. 3

5 2.4.4 Linkdoel (in context) Op de homepage, de subhome en de landingspagina komen links voor onderaan lijstjes met producten of diensten. De tekst in deze links is steeds Lees verder. Dergelijke teksten hebben geen betekenis wanneer ze niet in context worden bezien, bijvoorbeeld wanneer een bezoeker gebruik maakt van een screenreader en navigeert via links. Een linktekst zoals Lees meer over onze diensten of Naar het nieuwsarchief geeft dan veel meer inzage in het linkdoel dan alleen Lees meer. Omdat de pagina s achter deze links ook op andere manieren te benaderen zijn, namelijk door op de titel te klikken, is de vraag of de links überhaupt nodig zijn. Wellicht is verwijderen een betere optie in dat geval. 4

6 Technische bevindingen: SIM eformulierenmodule De SIM eformulieren module wordt gebruikt voor het maken van afspraken bij de gemeente Eindhoven. Deze module is een slim ingerichte module, die in basis een goede dienstverlening is naar de burger. Er zitten echter wat haken en ogen aan, met name door de technische implementatie. De afspraken module is niet gelaagd gebouwd. Er is onvoldoende rekening gehouden met de logische structuur van de module, maar vooral uitgegaan van de visuele weergave (1.3.1, 3.2.1, 3.2.2) Door het gebrek aan onderhuidse structuur is de applicatie niet bedienbaar met een toetsenbord. Dit heeft te maken met het onjuiste gebruik van HTML-elementen (2.1.1, 2.1.2) Wanneer een gebruiker een element selecteert, is er geen feedback naar de gebruiker, behalve visueel. Dat betekent dat er ook geen feedback is naar de browser. Een manier om dit op te lossen is gebruik te maken van een gerelateerde toegankelijkheidsstandaard WAI-ARIA - Web Accessibility Initiative - Accessible Rich Internet Applications - (3.2.1, 3.2.2) Wanneer een gebruiker informatie foutief invoert, is de feedback in de formulieren alleen visueel zichtbaar, maar semantisch zijn de foutmeldingen niet gekoppeld aan de betreffende elementen. Daardoor is het voor een gebruiker van een screenreader of andere hulpapparatuur onmogelijk om te zien waar hij of zij de fout heeft gemaakt. (3.3.1, 3.3.3) N.B. Er is naar aanleiding van bovenstaande punten inmiddels contact geweest met de SIM Groep, en op 4 maart staat een bijeenkomst gepland bij de SIM Groep om over structurele verbetering van deze module te praten. 5

7 Technische bevindingen: Cure Er zijn van de afvalkalender van Cure 4 states getest. Dat wil zeggen dat er vier verschillende pagina s binnen deze tool zijn bekeken. Helaas is deze toepassing verre van toegankelijk, en zijn er ook op het gebied van gebruiksvriendelijkheid nog wel de nodige kanttekeningen te plaatsen. De primaire bevindingen zijn hieronder opgesomd, maar helaas is deze toepassing dusdanig ontoegankelijk dat een broodnodige verbeterslag vermoedelijk onevenredig veel kosten zal betekenen. Herbouw van componenten op deze pagina zou een betere aanpak zijn. Geen van de 4 states is bruikbaar met alleen een toetsenbord (2.1.1, 2.4.3, 2.4.7, 3.2.1) De pagina bevat validatie fouten, en er is gebruikt gemaakt van verkeerde htmlelementen om onderdelen op de pagina op te maken. Dat is met name een probleem bij de kalenderview (4.1.1, 4.1.2) Er is nagenoeg geen visuele feedback bij toetsenbordnavigatie, en er is helaas in het geheel geen feedback onder water, zodat screenreaders of andere hulpapparatuur de wijzigingen opvangen. Dat heeft ook te maken met voorgaande bevinding met betrekking tot de verkeerde html-elementen (3.2.1, 3.2.2, 3.3.1, 3.3.2, 4.1.1) 6

8 Technische bevindingen: GX formulier Het formulier op deze pagina lijkt te zijn gemaakt met behulp van GX. Het formulier voldoet niet volledig aan de toegankelijkheidsnorm, waarbij twee factoren een rol spelen. De validatie op het formulier werkt niet goed, en er is gebruik gemaakt van foutieve html-elementen. Ook lijkt inhoud van het formulier te zijn gedupliceerd voor vergelijkbare velden, zonder dat de naamgeving van de elementen is aangepast. Hieronder volgende de belangrijkste bevindingen. Niet alle velden in het formulier hebben een bijbehorend uniek label. Het labelelement is het element op basis waarvan screenreaders en andere hulpsoftware het formulier voorlezen. Wanneer een input-element meerdere gekoppelde labels heeft, is de logische structuur van de pagina of het formulier zoek, en kan een gebruiker vastlopen (4.1.1, 4.1.2, 3.3.2, 3.2.2) Wanneer de gebruiker het formulier onvolledig of foutief invoert vind er validatie plaats en wordt aangegeven welke velden foutief of niet zijn ingevuld. Deze meldingen zijn echter niet gekoppeld aan het element met behulp van bijvoorbeeld een aria-describedby -attribuut. Er is daardoor in technische zin geen feedback, met uitzondering van de visuele feedback (3.3.2, 3.3.3) 7

9 En nu? De website voldoet helaas niet aan de toegankelijkheidsnorm. Wel is duidelijk aanwijsbaar waar verbeteringen mogelijk zijn, en wat out of (y)our hands is. Het is belangrijk leveranciers onder druk te blijven zetten, en de bezoekers van de website op de hoogte te brengen van de situatie. Om dit te faciliteren hebben wij een toegankelijkheidsverklaring opgesteld. Toegankelijkheidsverklaring De toegankelijkheidsverklaring is een invuloefening gefaciliteerd door het Ministerie van Binnenlandse Zaken en Logius, en geeft op verantwoorde wijze inzicht in de status van toegankelijkheid, én de genomen maatregelen. Deze toegankelijkheidsverklaring is te vinden in de bijlage verklaring.html, en kan één op één worden gekopieerd naar een pagina in het CMS. Het ministerie van Binnenlandse Zaken ziet deze verklaring bij voorkeur terug op 8