Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 125 reacties

Van de Nederlandse gemeentesites voldoet 98 procent nog niet aan de door de overheid opgestelde webrichtlijnen. De oorspronkelijke afspraak was dat alle sites van de overheid vanaf 31 december 2010 aan deze richtlijnen zouden voldoen.

Minister Donner heeft het rapport Accessibility Monitor 2011 uitgereikt aan de Tweede Kamer. Het rapport is het vijfde onderzoek van de Stichting Accessibility naar de mate waarin websites van gemeenten aan de webrichtlijnen voldoen.

De webrichtlijnen moeten garanderen dat mensen met een beperking, mensen met verschillende soorten computers en zoekmachines overheidssites goed kunnen benaderen. Er wordt onder andere gekeken naar de toetsenbordtoegankelijkheid, schaalbaarheid van lettergrootte, vindbaarheid in Google en leesbaarheid zonder stylesheets. Dit jaar zijn voor het eerst alle 418 gemeentesites onderzocht. Bij eerdere onderzoeken werd een steekproef gehouden.

Van alle gemeenten voldoen er slechts vier met hun site aan alle webrichtlijnen: Goirle, Houten, Krimpen aan den IJssel en Wijk bij Duurstede. Van de sites voldoet 92 procent zelfs niet aan de minimale eisen voor toegankelijkheid. "Van de sites die multimedia gebruiken, doet 87 procent dat op een niet-toegankelijke wijze. Er wordt bijvoorbeeld geen ondertiteling voor doven en slechthorenden toegevoegd. Het toenemende aantal ontoegankelijke video’s is vooral voor deze groep gebruikers een zorgwekkende ontwikkeling", constateert de Stichting Accessibility.

Ook de Rijksoverheid.nl-site voldoet nog niet aan de minimale toegankelijkseisen. Met deze resultaten voldoet de overheid bij lange na niet aan zijn oorspronkelijke doelstellingen. "Sinds juni 2006 zijn de webrichtlijnen voor websites van de rijksoverheid verplicht en per 31 december 2010 moeten alle overheidswebsites, ook die van gemeentes, provincies en waterschappen, voldoen aan de webrichtlijnen", staat op de overheidssite over de webrichtlijnen.

De overheid heeft echter onlangs nieuwe doelstellingen bekendgemaakt, die gemeenten meer tijd geven. Nu krijgen ze tot eind 2012 om te voldoen aan de minimale eisen, terwijl ze tot januari 2015 de tijd hebben om hun sites volledig aan de webrichtlijnen te laten voldoen.

Accessibility Monitor 2011

Moderatie-faq Wijzig weergave

Reacties (125)

Voldoen aan webrichtlijnen is niet eenvoudig wanneer je een website hebt met tienduizenden webartikelen. Om toch te voldoen kunnen gemeenten ervoor kiezen om alle content naar een open-pdf formaat te archiveren. Wat dan nog overblijft zijn videos die voorzien moeten worden van ondertiteling, uitgeschreven tekst en diversie alternatieven. Sommige overheidswebsites hebben grote aantallen, waardoor dit erg in de papieren gaat lopen. Wanneer je een CMS hebt die wel alle richtlijnen ondersteunen. En ik kan je vertellen dat die standaard nog niet bestaan, dan is de grootste uitdaging om je organisatie zo in te richten dat webrichtlijnen prio heeft. Dat betekend dat je auteurs moet opleiden, je webbouwers moet opleiden.

De gemeente Stadskanaal (niet appingedam) heeft een onder leiding van Koen Willems een cms laten ontwikkelen die de auteur afdwingt om in de goede volgorde H1, H2 e.d te gebruiken. Tabellen mogen alleen voor data gebruikt worden en niet voor uitlijning. Alt codes worden afgedwongen etc etc. De website van stadskanaal voldoet dan ook geheel aan de webrichtlijnen.
Ze zijn bezig om dit CMS als open-source aan te bieden. Ik heb er helaas nog niks van gehoord.

Webrichtlijnen zijn niet moelijk te implementeren als je van scratch af aan begint. Het wordt al gauw complex met veel (oude) data gebaseerd op statische html pagina's.

Een andere reden waarom de webrichtlijnen nog niet door zoveel gemeenten zijn ingevoerd is omdat het op de "pas toe" of leg uit lijst staat. Met andere woorden er zijn geen wettelijke sancties die het verplichten. Overigens wordt hier achter de schermen wel aangewerkt. En naar mijn mening terecht. Je kunt het gewoon niet maken om een grote groep uit te sluiten.

Een voorbeeld hoorde ik van een blinde man die niet instaat was om online een adreswijziging bij een gemeente door te geven. De website voldeet niet aan de webrichtlijnen. Vervolgens is deze beste man naar het gemeente huis gegaan om dan maar bij de balie dit te regelen. Hem werd vertelt dat hij dit wel mocht doen, maar dat ze een toeslag vroegen. Wanneer hij dit niet wilde betalen moest hij maar een website raadplegen. Dit is in strijd met de "recht op gelijkheid"

[Reactie gewijzigd door hydex op 28 juni 2011 23:02]

Volgens mij bedoel je Stadskanaal. Koen Willems is daar flink bezig geweest met een WYSIWYG editor die toentertijd misschien Open Source gereleased zou worden.

De status daarvan weet ik ook niet eerlijk gezegd.
Voor zover ik weet zijn veel mensen en partijen enthousiast, maar komt niemand echt over de brug. Denk dat voorlopig alleen de mensen in Stadskanaal kunnen profiteren van deze prachtige en gebruiksvriendelijke editor.
Ach, die van SIMgroep is ook wel netjes moet ik zeggen. :)
Je hebt gelijk het is stadskanaal. Had inderdaad een presentatie gezien van Koen Willems.
Is dit ook zo'n beerput waar ons belastinggeld in zit? Is er echt niemand die orde op zaken kan krijgen betreft ict bij de overheid? :X
Er zijn een aantal problemen om te beginnen, leg mij om te beginnen maar eens uit waarom elke gemeente een andere site heeft en waarom dit niet gewoon een standaard CMS is dat voor alle gemeente wordt in gezet. Dan is de problemen oplossen hele erg simpel en veel goedkoper...
Voor de klant (wij de belasting betaler dus) is het ook nog eens hele erg veel handiger omdat een enkele layout inhoud dat ik in alle gemeente ongeacht welke de data op de zelfde manier op de zelfde plaats kan vinden.

HET probleem binnen alle overheden met betrekking tot ICT en zo veel andere projecten is dat iedereen en alles zo speciaal is dat het allemaal net even anders moet dan bij de buurman dan wel de voorganger. En dus heeft elke provincie een andere pagina en een eigen CSM, gebruiken alle gemeente een andere layout en zullen ze nooit alle problemen oplossen omdat het simpel weg te duur is.

De overheid moet simpel weg een veel beter beleid gaan voeren op ICT gebied en de politiek van de IT scheiden met dat men dat doet is het op eens heel erg veel simpeler om dit soort projecten tegen een redelijke prijs en binnen een redelijke tijd uit te voeren.
Ik weet dat 2/3 van de gemeentes hetzelfde CMS hebben, alleen in een eigen jasje. Ben de naam even kwijt, maar kijk maar eens goed naar de opbouw van zo'n site. Die zien er vaak best hetzelfde uit.

Dat ze zo laag scoren ligt gewoon aan dat ene CMS, dat gewoon een beetje ouderwets is. Sinds 2001 is er weinig aan de techniek veranderd.

Verder is het inrichten van een website om aan de webrichtlijnen te voldoen gewoon een drama. Om overal aan te voldoen moet je feitelijk je hele website dubbel bouwen. Het is in deze tijd vrijwel onmogelijk om een website te bouwen zonder javascript, cookies en moderne features en die er nog een beetje 2011 uitziet.

[Reactie gewijzigd door Marcelloz op 27 juni 2011 16:54]

@Marcelloz: Gebruik van JavaScipt, Cookies en 'moderne features' is gewoon toegestaan, volgens mij ben je niet helemaal goed geÔnformeerd. Het hangt vooral af van het vakmanschap af of het op een toegankelijke manier wordt gebruikt.

Dat wil zeker niet zeggen dat de webrichtlijnen perfect zijn. Versie 1 is gebaseerd op de toegankelijkheidsspecificatie WCAG (Web Content Accessibility Guidelines), waarvan de eerste versie stamt uit 1999. Sinds afgelopen donderdag is Webrichtlijnen versie 2 een officiŽle overheidsstandaard. Die is gebaseerd op WCAG 2.0 en is specifiek ontworpen voor het maken van toegankelijke 'Rich Internet Applications' te kunnen borgen. Dus als Webrichtlijnen versie 1 volgens jou een drama is, dan is het advies om toch vooral over te stappen op versie 2.
Rijksoverheid gebruikt in ieder geval sinds de vernieuwing Hippo CMS.

[Reactie gewijzigd door linkforsoad op 27 juni 2011 17:17]

Gemeentes mogen ieder hun eigen website leverancier kiezen,
Mogen ieder hun eigen database laten bouwen en beheren
Mogen ieder zelf bepalen welke webapplicaties ze willen draaien

En ga zo maar door.

Al die websites van de gemeentes is een enorme verspilling van belastingcenten.

Hoe moeilijk is het om 1 systeem aan te schaffen en ieder hun eigen subdomein te geven, gebasseerd op hetzelfde CMS en dezelfde navigatie 8)7

In principe levert iedere gemeente dezelfde producten...

Maar nee, dat kan niet want iedere nitwit bij een gemeente wil er zijn eigen plasje over kunnen doen. }:O

[Reactie gewijzigd door p0pster op 27 juni 2011 20:11]

Je laatste zin klinkt wat grof, maar is inderdaad wel het geval, zoals meerdere lezers hierboven ook al zeiden. Ik kan me vinden in je idee om de lokale websites in ieder geval globaal te centraliseren. En dan op de een of andere manier enkel gemeente de mogelijkheid geven om aanvullingen te laten maken. Veel CMS-systemen bieden een vergelijkbaar systeem: een krachtig, goed basis systeem, waarin modules kunnen worden toegevoegd. Als hiervoor goede regels worden opgesteld moet iedere gemeente zich toch kunnen redden?

Maar de onkunde bij de (managers van) de ontwikkelaars is ook te proeven hoor! Gemeente Raalte bijvoorbeeld. Website net vernieuwd, module voor online afspraak maken gebouwd, en waarin doen we dat? Java! Natuurlijk, had ik ook gekozen. Wou laatste even snel een afspraak op de iPad maken. Helaas, kan niet, Java.
Jij bent blijkbaar niet zo heel bekend met Java. Een dergelijke module is prima, en zeer eenvoudig, met Java te bouwen. Echter je moet er geen applet (ik ga ervan uit dat jij het daar over hebt) van maken, want dan heb je inderdaad problemen met je iPad.
Bedoel je misschien SmartSite?
Verder is het inrichten van een website om aan de webrichtlijnen te voldoen gewoon een drama. Om overal aan te voldoen moet je feitelijk je hele website dubbel bouwen. Het is in deze tijd vrijwel onmogelijk om een website te bouwen zonder javascript, cookies en moderne features en die er nog een beetje 2011 uitziet.
Kortom, het ligt aan verwaande webdevelopers die hun tijd liever besteden aan grafische trucs en hun "mooie" opmaak bindend willen maken i.p.v. te proberen een toegankelijke site te maken die er dan maar wat minder flitsend en modern uitziet. Als ik op de site van mijn eigen gemeente kijk merk ik zelfs dat Ghostery Google Analytics moet tegenhouden, wat heeft dat op een gemeentesite te zoeken?
Denk je echt dat het de webdevelopers zijn die de mooie opmaak willen of denk je dat die beslissing wordt gemaakt door de gemeente die de webapplicatie laat ontwikkelen? Denk je echt dat webdevelopers zitten te wachten op die "grafische trucs" (JavaScript)? Heb je enig idee hoeveel tijd "grafische trucs" kosten t.o.v. ander web development werk?

Ik werk dus voor zo'n software ontwikkelaar die een CMS voor een aantal gemeentes heeft gemaakt (en nog steeds onderhoud pleegt). Het enige waar een gemeente geld aan wil uitgeven zijn features (en design). Al het andere is van ondergeschikt belang en zeker als het teveel uren/geld kost.

Onderhoud (en security) willen ze zo min mogelijk geld/tijd aan besteden.

Webrichtlijnen worden alleen meegewogen in hun beslissing als we hen er op wijzen dat de nieuwe feature mogelijk problemen hiermee veroorzaakt. Vaak bieden we een alternatieve oplossing aan, maar als dat teveel euro's kost in verhouding tot de niet-compatibele oplossing, dan is de keuze snel gemaakt.

Ohja, en jij denkt dat een gemeente niet wil zien welke pagina's mensen bezoeken en welke niet? Wat is er mis met Google Analytics? Alle gemeentelijke sites en subsites die we onderhouden gebruiken Google Analytics. En ik kan je verzekeren dat het niet de webdesigners zijn die erom gevraagd hebben. Ik verwacht trouwens dat in de praktijk bijna alle gemeentelijke sites Google Analytics gebruiken.
Wat Ruliz ook zegt, het ligt niet aan de developers. Gemeentes willen ook mee met de tijd qua technieken en technologieŽn. Social media wordt ook steeds meer gebruikt en Javascript mag ook gewoon gebruikt worden, mits de website ook werkt als er geen Javascript aanstaat.
Omdat iedere gemeente weliswaar verantwoordelijk is voor dezelfde taken, maar elke gemeente vrij is om deze verantwoordelijkheid wel/niet/beperkt op te pakken. De website zal dit dan ook weerspiegelen.

Vergelijk www.houten.nl maar eens met www.wijkbijduurstede.nl. Beiden hebben de richtlijn gehaald, en hebben ruw weg dezelfde opmaak. Redelijk vergelijkbare gemeenten. Maar leg dat eens naast de sites van utrecht.nl of rotterdam.nl.

Elke gemeente heeft zo zijn eigen speerpunten naar buiten toe, en z'n eigen interne problemen. Met ťťn CMS doe je daar niet recht aan.

Zelfs iets basaals als het digitale loket is niet eenvoudig te harmoniseren, want dan zou elke gemeente ook het zelfde koppeling naar de agenda's etc. moeten gebruiken, en dit ook ondersteunen met een bedrijfsproces.

Of wil je een draak van een 'customizable' cms opzetten waar elke gemeente gebruik van kan maken?

Waarom denk je dat gewone bedrijven allemaal hun eigen website hebben? Elke schoenenmaker/ICTbedrijf verkoopt toch ook dezelfde diensten? Tip: onderscheiden van de concurrent is een reden/gevolg van de onderling verschilllen.
dus de sites die aan de eisen voldoen zijn redelijk gelijk???

maar als je dat vergelijkt met een site die z'n zaakjes niet op orde heeft is het opeens heel anders... ik denk dat daar inderdaad het probleem zit.

dus geef ze tot 31-12-2011 en anders gaat ie automatisch op zwart naar een zeer simpele basis-pagina die op vertelt waarom deze site niet meer te bereiken is. (of eventueel die simpele CMS-pagina)
neee. we gaan ze nog 5 jaar geven, waarin ze weer niets doen.. en dan nog eens 5 jaar...

zo kan het nog wel even gaan duren
Nou, dan ligt er mooi de mogelijkheid om al die interne processen ook te stroomlijnen. Dan is Amsterdam ook meteen uit de brand. Iedere gemeente heeft te maken met dezelfde regelgeving, moet dezelfde 'diensten' aanbieden en kan dus van hetzelfde automatiseringssysteem gebruik maken. Alleen de benodigde servercapaciteit zal verschillen met het aantal inwoners.
en voor varierende server-capaciteit hebben ze "de cloud" bedacht toch...
Alle gemeenten naar 1 CMS klinkt mooi, maar de meeste hebben een heleboel custom systemen om gemeente "diensten" via het internet aan te bieden.

Al die system ombouwen en alle data uit verschillende CMSen porten naar 1 CMS is echt een mega klus en wie gaat dat allemaal betalen? (wie wil daarvoor betalen?)
Nouja, wat zijn de gemeenten op het moment kwijt aan hun web-aanwezigheid? D'r zijn gemeenten die elke paar jaar een nieuwe website laten bouwen (Š tien- tot honderdduizenden euro's), al dan niet met een nieuw CMS en weer een overgangstraject.

Ik ben er vlak voor om de gemeentelijke softwarediensten onder ťťn dak te gooien, goeie developers en designers (met concurrerende lonen) aan te trekken, en alle problemen centraal op te lossen.
Zo'n standaardisering moet zeker mogelijk zijn. Als een gemeente dan toch echt specifieke diensten levert, dan zouden die diensten eventueel op een eigen site gedraaid kunnen worden waar vanuit het algemene CMS naar toe gelinked wordt. Om in de loop van de jaren die systemen te migreren naar het CMS (vaak is het ook niet meer dan een Frontend voor een Database)
ja, leuk twee websites voor 1 gemeente.
Wil je je paspoort aanvragen? Dan zit je hier verkeerd! Ga naar onze andere overheidswebsite!.

Leukers kunnen we het niet maken ...
In principe hoef je daar als gebruiker niets van te merken, met een goed CMS is de huisstijl aan te passen maar blijft het op de achtergrond gewoon hetzelfde.
Een goed CMS is overigens ook aan te passen aan andere voorkeuren, de ene gemeente heeft immers andere behoeftes als een andere bv omdat de ene klein en de andere groot is, aan zee/rivier ligt of juist niet, en zo zijn er nog wel enkele variabelen.

Het hoofdprincipe acher deze diensten kan allemaal hetzelfde zijn, iedere gemeente geeft immers paspoorten en rijbewijzen uit, maakt bestemmingsplannen, verleent bouwvergunningen en ontheffingen op het bestemmingsplan, voltrekt huwlijken, heeft te maken met inburgering en nationalisaties enzovoorts. Over alle gemeentes samen zijn de overeenkomsten groter als de verschillen.
Hier ga je juist aan het grootste probleem voorbij!
Het grootste probleem is nu juist dat een software leverancier er voor geen kant vanuit kan gaan hoe het werkt.
Als de website en CMS gestandaardiseerd is zou dat juist heeeel veel geld schelen.
Nu moet elke leverancier voor elke gemeente een nieuwe koppeling maken.
Dit moet voor elke nieuwe update van het pakket en voor elke nieuwe site weer per gemeente apart worden veranderd.
Je hebt een partij die de site gemaakt heeft, een beheerder van de site, een ICT dienst die de site host en een leverancier van de koppeling.

Succes met het zoeken waarom een koppeling niet werkt!
Waarom moet de 'tegenpartij' van de overheid altijd als 'belastingbetaler' worden aangeduid? De klanten van een gemeente zijn de inwoners, de toeristen en de ondernemers, niet per definitie belastingbetalers. Ik weet, belastingbetaler klinkt lekker dramatisch, maar het is een dooddoener voor elke uitgavepost.
Dat elke gemeente een andere website heeft is heel logisch.

1. Het CMS van een gemeente is gekoppeld aan een behoorlijk aantal andere systemen en die zijn vaak niet hetzelfde per gemeente. Sterker nog, de meeste gemeenten hebben dezelfde systemen ook vaak weer anders ingericht, waardoor de koppeling met het CMS ook weer net even anders is.

2. Het is een ontzettend slecht idee om je processen aan te passen aan een systeem in plaats van andersom. Niet elke gemeente werkt hetzelfde; dat lijkt misschien wel zo vanaf buiten (ze bieden tenslotte vaak dezelfde diensten aan), maar intern is dat vaak (helemaal) niet zo. Dat heeft onder andere te maken met cultuur; dat verschilt per gemeente, juist ook omdat er in verschillende gemeenten verschillende mensen wonen. En het heeft te maken met de geschiedenis van zo'n gemeente. Hoe is het ontstaan, welke services biedt de gemeente wel, welke niet, is het een fusiegemeente of alleen een stad, etc.

Wat er gebeurt als je je processen aanpast aan je systeem, is dat mensen niet meer met het systeem willen werken; dit zie je trouwens niet alleen bij de overheid, maar ook (heel) vaak bij bedrijven. De reden dat mensen er niet mee willen werken is omdat ze anders moeten werken terwijl ze al jaren op dezelfde manier werken, omdat de processen anders zijn, omdat er zaken in het systeem eerst wel konden en nu niet, omdat ze al wat ouder zijn en moeilijk met nieuwe technologie om kunnen gaan, omdat ze uberhaubt weinig verstand hebben van techniek, omdat ze geen training hebben gekregen, etc. Moet je je even voorstellen dat dit straks voor elke gemeente geldt.

3. Elke gemeente heeft andere prioriteiten. Dat klinkt heel basaal, maar is wel waar het om draait. Elke gemeente heeft andere zaken die ze willen realiseren en die zijn vaak gebaseerd op politieke keuzes. Dat is ook prima lijkt me, niet elke gemeente heeft hetzelfde stemgedrag van de bevolking, dus is het ook logisch dat andere keuzes worden gemaakt.

Een centraal systeem lijkt heel mooi in theorie, maar in de praktijk levert dat heel veel problemen op. Sterker nog: ik denk dat een centraal systeem ook heel duur is; je moet nieuwe functionaliteit tenslotte testen voor _elke_ gemeente. Bovendien, wat gebeurt er als de leverancier van het CMS keuzes maakt waar de gemeenten niet blij mee zijn? Of wat als er een aantal gemeenten wel blij mee zijn, maar een aantal niet? Gaan ze naar een andere leverancier? Dat is gemakkelijker gezegd dan gedaan. Zeker als je een systeem van een ander moet overnemen.

edit: leesbaarheid

[Reactie gewijzigd door Ruliz op 28 juni 2011 11:57]

Antwoord op je vraag of dit ook zo'n beerput is waar ons belastinggeld in zit: Nee.

Het is in elk geval geen groot project waarvoor miljoenen opzij zijn gezet. Sterker nog: er is geen budget aan gekoppeld. Het is een verplichting die is ingesteld om zeker te stellen dat nieuwe websites van de overheid niemand buitensluiten vanwege de manier waarop (web)technologie wordt ingezet. Het gaat dus om een recht, niet over geld. Regelmatig hoor je trouwens wel dat het heel erg duur is om aan de webrichtlijnen te voldoen. Dat kan kloppen.

Maar dan is er, in organisatorisch opzicht, iets fout gegaan. Het plaatje op http://atrophiedmind.files.wordpress.com/2011/06/design.png maakt het heel mooi duidelijk. Iets als toegankelijkheid achteraf inbouwen bij een website kost de hoofdprijs. Dus als je het in het begin niet eist, bij de selectie van een partij die het moet maken niet goed nagaat of-ie z'n beloftes kan waarmaken, of er tijdens de uitvoering van het project niet op toeziet dat er werk van wordt gemaakt om aan de gemaakte afspraken te voldoen, dan krijg je niet wat je hebben wil.

Veel ingewikkelder dan dit is de verklaring niet waarom het (te) vaak bij goede bedoelingen blijft. Je zou een onderwerp als dit dus kunnen beschouwen als een lakmoesproef voor projectleiders. Die worden nu vooral afgerekend de afronding van het project binnen het budget en binnen de deadline. Een goeie weet met die constraints ook een gedegen kwaliteitsniveau te halen, maar voor heel veel van zijn collega's is inboeten op kwaliteit bij complicaties een van de weinige mogelijkheden die ze hebben om binnen tijd en budget te blijven. En te vaak lukt ook dat niet.... Overigens ligt de schuld niet enkel bij projectleiders, maar ook aan opdrachtgevers die gaanderweg andere prioriteiten stellen. Tegen dat soort grilligheden zijn de meeste ICT-projecten niet goed bestand. Binnen en buiten de overheid.
Geheel eens met je derde paragraaf. Het is trouwens ook zo dat, in dit geval een gemeente, een budget vaststelt en een tijd waarin iets af moet zijn. En het is vaak niet de projectleider die dit budget vaststelt, maar de wethouder. De gemeente kiest dan een leverancier en die kiest die leverancier vaak op budget. Hoeveel features kan ik krijgen tegen x budget. Hoe meer jij als leverancier _zegt_ dat je kunt maken binnen dat budget, hoe meer kans je maakt. De praktijk is dan van later zorg.
Opdrachtgevers die gaandeweg andere prioriteiten stellen is trouwens niet direct een probleem: tenminste, niet als je agile werkt.

m.b.t. de eerste twee paragrafen: webrichtlijnen later inbouwen kost inderdaad heel veel meer dan als je het meteen doet. Maar... ook nieuwe features die worden toegevoegd kosten meer als je rekening houdt met webrichtlijnen, dan als je er geen rekening mee houdt. En daar ligt de issue. Een gemeente heeft beperkt budget en moet dus keuzes maken in features; en soms gaan features dus boven webrichtlijnen. Niet wat je wilt, maar wel wat de praktijk is.
Zoals vaak bij ICT; te veel poppetjes met te veel wensen - zeker bij lang lopende projecten worden de doelen 10x bijgesteld en andere uitgangspunten benaderd omdat er steeds andere/meer mensen mee gaan bemoeien. Zeg niet dat 't goed is, maar dat is wel vaak de praktijk (overheid/b2b)
In dit geval, mag dit geen probleem zijn. Er is een algemeen beleid, die voor alle gemeentes geld. Natuurlijk mag iedere gemeente een eigen huisstijl hebben en toepassen. Echter, er zijn een aantal eisen waar aan een site moet voldoen qua toegankelijkheid en vindbaarheid (zoals gemeld in het artikel), die universeel geldt.

het is dus niet zo, dat bij alle 418 gemeentes iemand bedenkt hoe bepaalde dingen moeten. Er is een soort blue-print beschikbaar, aan wat de site moet voldoen. De rest is aan de gemeente, om hier invulling aan te geven. Het mag dan echt niet meer zo zijn, dat een zo hoog percentage dus niet aan de minimale eisen voldoet. Zeker wanneer deze lang en breed bekend zijn.

Ja, het is bekend dat de overheid niet echt een goede reputatie heeft, als het op ICT aankomt, echter, deze eisen gelden voor iedereen, zijn geen geheim ofzo, dus elke site moet er aan kunnen voldoen.

Dit probleem, vind ik niet perse het probleem van de overheid an sich. Ja, ze stellen de regels op, maar ik vind de titel van het nieuwsbericht niet echt ideaal gekozen word. Immers, de overheid verzocht de regels, maar niet het daadwerkelijk eindresultaat, en het geld is ook niet van de overheid per se, maar van de individuele gemeentes.
Helemaal mee eens.
Of het waar is weet ik niet, maar ik heb me eens laten vertellen dat er een aantal spelers op de markt zijn die een "keurmerk" hebben om een CMS te leveren voor dit soort sites, om maar een voorbeeld te noemen: http://www.greenvalley.nl/
Ook weet ik van een aantal gemeenten dat zij werken met een "goedgekeurd" CMS en toch zie ik ze in de lijst staan met een redelijk aantal fouten.
Nu vraag ik me dan af of dat incompetentie is van de mensen die het CMS vullen (zou eigenlijk niet mogen, aangezien het CMS die dingen wel kan opvangen) of dat het keurmerk ook nergens op slaat en achterhaald is.

//edit:
Ik zie net de post van "ltcom, maandag 27 juni 2011 16:47" en hij linkt naar 2 sites, die van houten en wijkbijduurstede. Beide sites draaien op TYPO3, dus denk dat de meeste gemeenten teveel uitgeven ;)

[Reactie gewijzigd door bernardV op 27 juni 2011 21:19]

SIMgroep heeft dat keurmerk dus ook en die heeft 200+ klanten onder zijn hoede.

Zij hebben een eigen gebouwd CMS en die voldoet nu in principe aan de Webrichtlijnen. Als de webredacteuren crappy content plaatsen, dan is het nog niet goed natuurlijk. ;)
Maar ook aan de lokale overheid betalen wij belastinggeld; aan de gemeente. Het is dus wel de overheid, die opereert met het geld van de burgers.
Even terzijde: Capelle aan den IJssel voldoet ook helemaal ... die heb ik namelijk gebouwd ;)

En wat Tielenaar al zegt: er komt echt veel bij kijken wil je een site compleet laten voldoen. Denk daarbij bijvoorbeeld ook third party elementen, koppelingen met mid- en backoffice, het CMS en dan begrijp je dat er veel tijd overheen gaat om dat voor elkaar te krijgen.

Overigens is er al een tweede versie van de webrichtlijnen aangenomen die vanaf 1 januari 2014 gaat gelden.

Deze webrichtlijnen zijn al veel beter beschreven dan de eerste versie, dus dat zal hopelijk ook een boel verduidelijken.
@1st_Ro: versie 2 geldt nu al, zie http://www.webrichtlijnen...ebrichtlijnen-vastgesteld
Versie 1 is met ingang van 2015 niet meer geldig. En tot die tijd ook goed voor websites voor juni 2011 zijn vernieuwd. De overgangstermijn is dus 3,5 jaar.
Excuss, je hebt gelijk, vanaf dan wordt de eerste versie uitgefaseerd.

Het was warm gister ;)
Ik ben zelf eind vorig jaar en begin dit jaar bezig geweest met een gemeentelijke website in Overijssel. Niet met het technische gedeelte, maar met het vullen. Al had ik me toen wel verdiept in de richtlijnen.
Alleen wat technische richtlijnen zijn en de richtlijnen die de overheid stelt zijn niet dezelfde. De overheid wilt naast de technische richtlijnen ook dat inhoudelijk alles in orde is. Dat laatste ligt aan de gemeente en dat kan je als gemeente niet makkelijk bepalen.
Je moet een vragenlijst invullen en aan de hand daarvan wordt bepaalt met een score of je website goed is.

Verder heeft een gemeentelijke website behoorlijk wat applicaties op de achtergrond draaien waar je als bezoeker niks van merkt. Bijvoorbeeld de elektronische formulieren en het digitaal loket.
Dit moet ook aan alle eisen voldoen.

Daarnaast is de samenwerking met de webontwikkelaar en de gemeente ook goed zijn, dit was bij ons niet optimaal. Probleem lag aan beide kanten. Dit zorgt er dus voor dat de website minder aan de technische eisen voldoet, dan je zou verwachten. Management en communicatie is op dit vlak ook iets waar goed naar gekeken moet worden, wil een website goed zijn.

Wat ik trouwens interessant vond, was dat H1-6 kopjes gebruikt worden door braille toetsenborden. Alles op de website moet gelabeld zijn om met de Tab toets door de website te gaan en om goed voorgelezen te worden. H kopjes verduidelijkt schijnbaar de spreekwijze.

Een gemeentelijk website opzetten die aan de richtlijnen voldoet is dus niet zomaar even geregeld.
De gemeente moet zorgen voor een goede inhoud, de webontwikkelaar voor een goede technische oplossing en de overheid? Die zou alles in de gaten moeten houden, waar ik niks van gemerkt heb.
Als een dergelijk hoog percentage van de gemeentes niet aan de richtlijnen kan voldoen is er dan niet iets mis met de richtlijnen? Ik kan me voorstellen dat als je voor ieder filmpje dat je online zet deze ook nog eens moet ondertitelen voor de doven en inspreken voor de blinden dat dat nogal verlammend en demotiverend werkt. En dan heb ik het nog niet eens over de extra kosten die deze aanpassingen met zich mee brengen.
Nee, het is gewoon laks van de overheid. Daarnaast is de regel - en wetgeving over dit onderwerp nog niet waterdicht.
Het is namelijk wel verplicht, maar het wordt niet echt gecontroleerd door de overheid (er hangt nog geen sanctie aan, als niet webrichtlijnenproof ben).

Site om je eigen site te testen http://www.webrichtlijnen.nl/toetsen/wat-u-moet-weten

Boek over hoe een overheidswebsite kan voldoen: http://bit.ly/hSVOpN
Is in opdracht van KING (kwaliteitsinstituut Nederlandse gemeenten) opgestuurd naar alle Nederlandse gemeenten

[Reactie gewijzigd door Dakdoef op 27 juni 2011 16:09]

In opdracht van KING? Weet je dat zeker?
Nee, je hebt gelijk. Het is de ICTU.
Wow, dit is echt slecht, kennelijk kunnen ze niet eens goede koppen gebruiken, hier met informatica op school (4vwo) kunnen we het wel, is het niveau zo ver gezakt bij de overheid?
Wat kun je precies wel? Voldoen aan alle 125 webrichtlijnen? Gaat het over een HTML pagina of een compleet CMS?

Het probleem is dat veel gemeentes en delen van de overheid zitten met bestaande systemen die ze niet zo 123 kunnen opdoeken. Een bestaand product aanpassen om te voldoen aan de webrichtlijnen is niet zo eenvoudig (lees goedkoop) en soms gewoonweg niet mogelijk (omdat de richtlijnen niet alleen gaan over de HTML maar ook over de inhoud).

Wat ik echter niet snap is dat de overheid nog steeds nieuwe projecten start die niet meteen vanaf dag 1 aan de richtlijnen moeten voldoen. Op die manier komen ze er nooit....
Sorry, maar toegankelijkheid met het toetsenbord en vindbaarheid in zoekmachines is echt niets iets wat een 4VWO-er zo uit z'n mouw schud. Zelfs IT-ers die al jaren in het vak zitten en zich erin hebben gespecialiseerd hebben er nog moeite mee.

Aan de andere kant; er bestaat een website die globaal aangeeft waar men op moet letten: www.webrichtlijnen.nl (ook van de overheid).
Ik neem dus aan dat de bedrijven die deze sites maken hiermee de website controleren, en dat ook de verantwoordelijke wethouder(s) inzicht hebben over de standaarden die door het rijk worden geŽist.
Je reageert dan ook niet goed, ik heb het over de koppen, niet gezegd dat ik de rest kan, alleen die koppen en dat is gewoon basis html en css.
Dat is dus een kwestie van de (web)redacteuren bij de gemeentes goed informeren.

Het probleem is ook de gemeentes zelf verantwoordelijk zijn voor de content. Dus al lever je een goed werkend CMS aan, als zij hun content niet goed opzetten, dan haal je de webrichtlijnen toets nog niet.

Als bedrijf kan je dus maar tot op een bepaald niveau garanderen dat het systeem wat je levert voldoet aan de webrichtlijnen.
Wat zijn eigenlijk goede koppen? Als je wel H1 en H2 toepast, maar niet H3, is het dan al fout? En hoe zit dit in de markt? Passen bedrijven dit wel goed toe, bieden CMS'en wel de juiste ondersteuning om goede webcontent te genereren? Zoveel vragen...
De zwakste schakel in het gehele proces is het toevoegen van content. De gemiddelde editor doet erg zijn best om een valide (X)HTML resultaat te geven, maar gaat hier regelmatig nog op nat. Uiteraard is dit in een latere stap in een CMS op te lossen, maar uiteindelijk kun je nooit 100% garanderen dat content geheel voldoet aan de richtlijnen. Al is het alleen al omdat een aantal van de richtlijnen niet technisch meetbaar zijn, maar gevoelig zijn voor menselijke interpretatie.
Elke pagina moet beginnen met een H1 (niet per se het eerste element, wel de eerste kop) en daaronder mogen geen niveau's worden overgeslagen. Dus geen H3 gebruiken is prima, maar dan dus ook geen H4.
Hoe kan het dat er in 2011 een steiging heeft plaatsgevonden van 9% bij lay-out tabellen? Dit duidt wat mij betreft op het inzetten van de verkeerde ICT-bedrijven.

Een 14% vermeerdering bij het goed gebruiken van kopjes vind ik ook ernstig.

[Reactie gewijzigd door Interfico op 27 juni 2011 16:02]

Het gelinkte rapport vermeldt dat in 2010 een andere meetmethode werd gebruikt (dat is die noot 20 die in de tabel bij 2010 staat). Ze hebben toen slechts een steekproef van de pagina's getest en nemen aan dat de pagina's met problemen toen buiten de steekproef zijn gevallen. De cijfers uit 2010 zeggen dus eigenlijk niks.
Lekkere steekproef dan als de afwijkende waarden consequent niet zijn meegenomen...

Misschien ook nog tijd voor een cursusje statistiek, als ze klaar zijn met het analyseren van alle websites?
Standaard Sharepoint en developers die niks weten over front-end en webrichtlijnen zal verantwoordelijk zijn voor een groot deel van deze missers.

[Reactie gewijzigd door Bosmonster op 27 juni 2011 16:13]

Ik ben zelf web developer, maar deze richtlijnen zijn een hoop extra werk en je bereikt er misschien 2% meer mensen mee. Wellicht is het bij de overheid belangrijk dat ook elke slechtziende hun sites goed kunnen lezen, maar die AAA zoom-levels zijn zo vreselijk achterhaald dat het echt geen zin heeft om die dingen te programmeren.
Zorg er gewoon voor dat je site goed schaalt als iemand met zijn browser inzoomt. Daar zijn browsers veel en veel beter in dan die belabberde 3-A'tjes die nog gebaseerd zijn op de <font size> tag.
Ook zijn de juiste kopregels niet belangrijk voor de leesbaarheid of voorleesbaarheid. De tekst staat er, die is te lezen, dus waarom moet dat _per se_ in H1-6 vorm?
Dat er tabellen worden gebruikt voor iets anders dan 'tabular data' anno 2011 is natuurlijk wel een grote schande.
Ik vind juist gebruik van H1-6 kopjes een tekst anders bijzonder veel leesbaarder maken. Het laten inzoomen met de browser is gewoon lelijk omdat plaatjes en foto's dan ook meevergroot worden tot een korrelige mozaik. Nee bedankt, dan doen ze maar even wat meer moeite.
Zoom jij in IE6 of zo? Ik heb dit al jaren niet meer gezien.
Ik heb werkelijk het idee dat deze richtlijnen bedoeld zijn voor een doelgroep die op puur en alleen overheids sites surft. Op welke andere site heb je die zoom knopjes nou? Zie jij het op tweakers? Zie jij 6 header lagen in de artikelen hier? Ik zie er maar 1 of 2. En dat is voor de leesbaarheid in alle gevallen prima!
Kraak tweakers.net dan ook meteen af, wat overigens een paradepaardje is als het gaat om richtlijnen.
Dingen als vindbaarheid zijn veel belangrijker dan een kopje hier en daar.
Developers als jij, die niet begrijpen waar de richtlijnen voor zijn, zorgen er dus voor dat er te weinig vooruitgang wordt geboekt ;)

Schalen en tekstgrootte is ook een van de minste belangrijke (en meest achterhaalde) onderdelen van de richtlijnen.

Als je niet snapt waarom Headers belangrijk zijn voor navigatie en structuur (en dus voor toegankelijkheid), dan snap je het hele principe van semantisch web niet.

[Reactie gewijzigd door Bosmonster op 27 juni 2011 16:16]

Kopregel zijn juist extreem belangrijk voor de voorleesbaarheid. Hoe moet een voorleesbrowser anders titels herkennen, en de tekst structureren?

Sowieso snap ik niet waarom web developers kopregels niet correct gebruiken. Tezamen met CSS maakt dat het leven juist extreem veel gemakkelijker. Korte code, en automatische consistentie van de site.
Wellicht is het bij de overheid belangrijk dat ook elke slechtziende hun sites goed kunnen lezen, maar die AAA zoom-levels zijn zo vreselijk achterhaald dat het echt geen zin heeft om die dingen te programmeren.
Het gaat niet om AAA-zoomlevels, maar om de schaalbaarheid van de lettergrootte. Het gelinkte rapport definieert schaalbaarheid als volgt:
Wanneer geen absolute eenheden zijn gebruikt voor het opmaken van de
lettergrootte, maar relatieve eenheden is de lettergrootte schaalbaar. Dit betekent
dat de gebruiker, naar behoefte, de tekst op een website kan vergroten of
verkleinen, zodat deze voor hem of haar leesbaar is.
en refereert naar de volgende website voor meer informatie:
http://www.accessibility.nl/internet/artikelen/schaalbaar
Die 2% mensen bestaat uit slechtzienden en blinden. Je metriek gaat in dit geval dus niet op.

Het fatsoenlijk gebruik van headers zorgt dat de print-functie in elke browser goed functioneert.

Ik ga niet bepalen of je wel of geen web developer zou moeten zijn, maar ik zou voor het algemeen maatschappelijk belang geen aanbestedingen aangaan.

[Reactie gewijzigd door Sgreehder op 27 juni 2011 17:35]

@Telenaar: Waar in de webrichtlijnen staat dat die zoom-levels verplicht zijn? Er zijn al genoeg richtlijnen; niet zelf er een paar bij verzinnen, hoor!
En wat is de onderbouwing voor je betoog dat kopregels niet belangrijk zijn? Het zijn de ankerpunten van een webpagina.
"schaalbaarheid van lettergrote"
Dat wordt in veel gevallen gebouwd als zoom-knoppen in de site. Ik begrijp dit simpelweg niet, lettertypes zijn vectoren en zijn altijd te schalen, en browsers kunnen dat met alle gemak.
Google is ook blind. 8-)
Ik begrijp ook niet waarom er niet EEN goed beveiligde en toegankelijke 'basis'-website wordt gemaakt, waarna elke gemeente die met zijn eigen informatie gebruikt. Hoezo geldverspilling als iedere gemeente een eigen bedrijf in moet huren om hun website te laten maken; en dan wordt het blijkbaar nog niet eens goed gedaan.. *zucht*
Wat mij betreft is dit helemaal geen slecht idee, als je gewoon een keer een investering doet in een goed gemaakt CMS kunnen alle gemeentes deze gebruiken voor hun algemene website voor burgers. Dit zorgt voor uniformiteit tussen gemeentes en alles voldoet aan de richtlijnen van de overheid. Als een gemeente ook nog een toeristische website heeft kunnen zij deze hiervan loskoppelen.

Helaas gaat dit waarschijnlijk niet worden uitgevoerd omdat veel verschillende gemeentes met verschillende systemen voor online gemeentezaken werken. Veel gemeentes gebruiken wel een DigID andere weer niet en dan heb je nog verschillende afpraaksystemen ook.
Omdat je dan ťen basissite krijgt die voor niemand bruikbaar is in plaats van voor iedereen. Elke gemeente is anders. Een agrarische gemeente die bestaat uit diverse dorpskernen heeft andere voorzieningen en diensten en dus aansturing daarvan dan een middelgrote stad waar alles zich binnen de bebouwde kom afspeelt.
Omdat je als gemeente/land jezelf niet aan 1 bedrijf mag koppelen.

Stel er ontstaat een probleem met de betreffende aanbieder. Je kunt dan niet meer op tijd/zonder problemen wisselen. Je geeft een bedrijf macht over een stroom informatie van de overheid naar de bevolking.

Op zich ben ik het eens dat ze beter landelijk 1 website kunnen hanteren, maar dit moet wel zo opgezet worden dat diverse andere personen voor de diverse gemeentes e.d. hun eigen stukje bij kunnen houden. Dit levert dan op zijn beurt weer een "beerput" op, want iedereen wil iets anders.

voorbeeld: www.atlas.amsterdam.nl <-- dit valt mijn inziens onder het rijk, maar ik durf te wedden dat de "gewonnen" stadsdelen niet dergelijke implementaties hebben.

Je kunt natuurlijk ook wel begrijpen dat bovengenoemde kaart (vooralsnog) niet handig is voor blinden, moet dit dan wel voor blinden aangepast?
Voor websites gaat dat veelal niet op bij een gemeente.
Om er voor te zorgen dat ze geen aanbesteding hoeven te doen, kiezen ze zo'n beetje voor de goedkoopste leverancier om zich zo op te hangen aan een slecht functionerend systeem....

Zelden zo'n zootje gezien bij gemeentes, waar webbeheerders de ballen verstand hebben waar ze mee bezig zijn en geen idee hebben welke richting ze op moeten of hoe je ICT 'slim en effectief' kunt inzetten....

[Reactie gewijzigd door p0pster op 27 juni 2011 20:15]

Ik mis eigenlijk de volgende eisen in het rijtje:
- Bruikbaarheid van de site op een smartphone of tablet. Vaak is er geen versie die fijn werkt op een kleiner scherm.
- Bruikbaarheid van de site in fullscreen op hoge resolutie en/of breedbeeldschermen: vaak zie je dat er geen speciale layout is voor dit type schermen waardoor je continue omhoog/omlaag moet scrollen om een tekst te lezen.
- Verplicht gebruik van open en niet-propriŽtaire standaarden voor documenten: dus wel PostScript en OpenDocument en geen PDF, Word of Excel-bestandsformaten.
- Videostreams (live en downloads) van alle vergaderingen van de gemeenteraad.
Offtopic: PDF Ūs een open standaard. Vanwege de beschikbaarheid van gratis readers lijkt mij dit te prefereren boven willekeurig wel office-pakket (en al helemaal boven PostScript, want daar zijn gewoon veel te weinig gebruiksvriendelijke programma's voor.
PDF is dan wel open, maar is tevens propriŽtair. Adobe bepaalt hoe het formaat er nu en in de toekomst uitziet zonder inspraak van de software-industrie en gebruikers. Al met al genoeg reden om een non-propriŽtair formaat te kiezen: LaTeX of PostScript bijvoorbeeld.
En waarom dan? Zodat alle gebruikers een LaTeX of PostScript viewer kunnen gaan zoeken, en via de command line hun .ps of .tex bestand kunnen gaan laten renderen?

Zolang het een open, vrij te gebruiken standaard is, waarvoor een reader bovendien al standaard in veel OSen beschikbaar is, lijkt me dit helemaal geen slechte keuze voor de verspreiding van documenten naar burgers.

Dat de overheid voor archief-opbouw eventueel een ander formaat zou willen kiezen, zou kunnen. Maar krampachtig voor een gebruiksonvriendelijke oplossing kiezen omdat ie zogenaamd meer open is dan een ander (hoeveel invloed heb je nou echt op de ontwikkeling van LaTeX en PostScript?), is onzin.
Ik klik gewoon 2x op een .ps of .eps en dan krijg ik gewoon te zien wat het is hoor. Linux, Unix en Mac OS kunnen dat gewoon. Misschien dat windows dat niet kan, maar dat gebruik je toch niet als je serieus over kleurenbeheer bent.
Kost allemaal geld he, jouw geld.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True