Wie houdt zich aan de webrichtlijnen van W3C en drempelvrij?

Wie houdt zich aan de webrichtlijnen van W3C en drempelvrij?
, ANWB
@mdebruin

w3cAls website eigenaar wil je natuurlijk een website die voldoet aan de richtlijnen die gelden op internet. Een paar jaar geleden kwam het zogenoemde World Wide Web Consortsium (W3C) met een aantal richtlijnen. Van wat ik er toen van begreep was dit de service waar ik op zat te wachten.

Ik kreeg een tool (waaronder de HTML Validator) waarmee ik mijn website kon testen op programmeerfouten. Deze webrichtlijnen zijn regels voor het bouwen van kwalitatief goede websites. Ze hebben tot doel de kwaliteit van websites te verbeteren zodat informatie en diensten bruikbaar zijn voor alle mensen, bedrijven, browsers en zoekmachines. Dat klinkt natuurlijk goed. Dat is wat je wilt als website eigenaar.

Meer over W3C en drempelvrij
Eerst iets meer uitleg over W3C en drempelvrij voor degenen die daar behoefte aan hebben. W3C maakt webstandaarden, recommendations genaamd. HTML en XML bijvoorbeeld zijn door W3C ontwikkeld als recommendations. W3C is in 1994 opgericht door de webuitvinder Tim Berners-Lee. W3C kent geen persoonlijke leden, alleen bedrijven, instellingen en overheden. De Nederlandse stichting Accessibility (onderdeel van Bartimeus) die de webrichtlijnen en de drempelvrij richtlijnen maakt, is een lid van W3C. Grofweg kun je stellen dat als je voldoet aan de W3C richtlijnen, dat je ook een heel groot eind komt met de drempelvrij richtlijnen. Al zal Accessibility het iets anders uitleggen. Het Waarmerk drempelvrij.nl is het kwaliteitsmerk waarmee toegankelijke websites in Nederland worden aangeduid. Wanneer een website voldoet aan de eisen van de Stichting Waarmerk drempelvrij.nl mag deze site het waarmerk (een groen logo) dragen. De Stichting Waarmerk drempelvrij.nl heeft als doelstelling de toegankelijkheid van Nederlandse websites te bevorderen voor iedereen, inclusief mensen met een functiebeperking en senioren. Hiervoor is een transparante regeling met logo’s en heldere normen opgezet die door de Stichting beheerd wordt.

De praktijk
W3C biedt een simpele HTML Validator tool aan waarmee je URL’s kunt controleren. Zo gebruikte ik deze tool intern bij mij om te kijken of mijn websites (9292ov.nl en routeplanner.9292ov.nl) voldeden. Dat doen zij niet. De homepage van 9292ov.nl heeft momenteel 16 fouten volgens de validator en de homepage van routeplanner.9292ov.nl heeft momenteel 2 fouten. Een van de belangrijkste oorzaken bij mij is het feit dat ik nu nog een CMS systeem uit 2003 gebruik waarmee het praktisch onmogelijk is te voldoen aan de richtlijnen uit 2007. Daarnaast is het makkelijker een nieuwe website te laten voldoen aan de richtlijnen, dan een oude site om te gaan bouwen. Daarom bouwen wij momenteel ook een nieuwe website die wel moet voldoen. In het CMS dat wij gaan gebruiken (Smartsite) wordt een functie “standard compliance” aangeboden waarmee je pagina’s voor publicatie kunt controleren. Zowel voor de ontwikkelaar van de vormgeving als voor de redacteur wordt op deze manier hulp- en controlemiddelen geboden.

Zijn andere sites W3C proof?
Ik ben benieuwd hoe andere sites het er van af brengen. Ik begin met deze website. Marketingfacts.nl heeft 421 fouten. Dat is schrikbarend veel. De nieuwe funda site heeft 28 fouten. En dan controleer ik de homepage waar je kunt kiezen uit de diverse funda-websites. Ga je naar de huizensite dan is deze wel helemaal correct. Een andere test, De Telegraaf, levert 305 fouten op. De Telefoongids levert 16 fouten op. NU.nl levert 78 fouten op. NS.nl levert slechts 2 fouten op.  De code van routenet.nl is zelfs onleesbaar voor de validator. Wat ik nog het meest verrassende vond, is dat zelfs de simpelogende site van Google nog 41 fouten geeft. Dan begint bij mij de vraag te rijzen wie zich wel aan de standaarden houdt.

Wie houdt zich aan de W3C of drempelvrij richtlijnen?
Aangezien de drempelvrij richtlijnen gestoeld zijn op de W3C richtlijnen begin ik bij een site die het drempelvrij keurmerk voert. Op accessibility.nl tref ik een lijst aan met toegankelijke websites. Op accessibility.nl lees ik dat de site ehbv.nl voldoet aan de drempelvrij reichtlijnen. Wat mijn verbazing dan schetst als ik de site controleer via de HTML Validator dat er dan toch nog 12 fouten in de homepage zitten. Nu begrijp ik het niet meer. En volgens mij ben ik niet de enige. Op 19 maart 2007 is de Stichting Waarmerk drempelvrij.nl zelf met de publieke review van het normdocument Webrichtlijnen gestart. Zij nodigden ons uit om hieraan deel te nemen. Meer informatie staat op drempelvrij.nl. Het doel van de publieke review is om mensen die niet direct betrokken zijn bij de ontwikkeling van het normdocument Webrichtlijnen in de gelegenheid te stellen om een reactie te geven op de inhoud van het document. Binnenkort verschijnen de resultaten op hun site.

Jullie mening graag
Voldoet jouw site volgens de HTML validator van W3C? Wat doen jullie met de W3C standaarden?
Ik ben benieuwd naar de discussie!


Geplaatst in

Delen



Er zijn 65 reacties op dit artikel

  • Het moge overigens wel duidelijk zijn dat een website die voor 100% voldoet aan de W3C standaarden (valide markup), nog steeds volkomen ontoegankelijk kan zijn. De HTML-elementen moeten namelijk wel zinnig (lees: betekenisgevend) gebruikt worden willen "alternatieve user-agents" er iets aan hebben (zoals een GSM, PDA, screen reader, etc).

    Alle websites waar ik bij betrokken ben worden overigens volgens de W3C standaarden en toegankelijk gebouwd.

    geplaatst op
  • Nog een toevoeging m.b.t. de fouten op marketingfacts.nl: ieder nieuw artikel zorgt voor de extra fout. De teller staat na publicatie van dit artikel op 422 fouten. Marco, succes met de gesprekken met Onstuimig ;-) Na de introductie stond de teller op 187 fouten lees ik in het artikel van 16 februari 2006.

    geplaatst op
  • Da's inderdaad best veel. Zal eens met de Onstuimige jongens gaan praten maar of dat veel zal helpen. Het blijven kwajongens natuurlijk ;-)

    Maar even zonder gekheid, kan iemand mij vertellen wat de consequentie is van zoveel w3c-fouten?

    geplaatst op
  • Ah, gelukkig, de winnaar van de usability award 2007 heeft ook maar liefst 413 fouten!

    geplaatst op
  • Browsers gaan onvoorspelbaar gedrag vertonen zodra fouten te ernstig zijn. Wanneer een fout ernstig is en wat er dan gebeurt is afhankelijk van de browser.
    Als je dus zeker wil weten dat je site er goed, of in elk geval voorspelbaar uit ziet op alle browsers dan zorg je er voor dat er geen errors in zitten.

    geplaatst op
  • Toegankelijkheid en W3C standaarden staan behoorlijk los van elkaar. Toegankelijkheid gaat om het toegankelijk maken van je website voor verschillende browsers, zoekmachines, blinden, mobile devices, etc. Dit gebeurd met behulp van gescheiden opmaak en content, access keys, correct gebruik van elementen (dus geen titels in een <span class="header">), alt-tags en title-tags. De enige rol die de W3C standaarden hierin spelen is dat de kans dat een apparaat je website niet meer kan lezen groter is naarmate er meer fouten in zitten.

    Browsers op de PC zijn vrij tolerant wat fouten betreft, wat ertoe geleid heeft dat men slordig is gaan programmeren. De consequenties zijn gering. Er wordt geopperd dat sommige zoekmachines een cijfer toekennen aan de kwaliteit van het programmeerwerk (omdat dit een indicatie zou zijn voor professionaliteit). Maar zoals hierboven aangegeven, Google maakt er zelf een potje van. Voor een developer is het wel makkelijker om een website in alle browsers gelijk te krijgen als de website volledig W3C compliant is.

    Toegankelijkheid gaat voor 90% over meta-data, dat heeft niets te maken met W3C-compliance. Al maakt een webbouwer een 100% XHTML valid website, de content manager kan er alsnog een puinhoop van maken door geen aandacht te besteden aan toegankelijkheid.

    geplaatst op
  • De richtlijnen voor toegankelijkheid staan volkomen los van de richtlijnen voor (X)HTML. Een perfect toegankelijke site kan de validator volkomen op hol laten slaan en een perfecte HTML-pagina kan volkomen ontoegankelijk zijn.

    Het Waarmerk Drempelvrij betekent dat de site is getoetst aan de eigen richtlijnen, niet dat de site toegankelijk is of dat de HTML valide is. Een aardig voorbeeld is de website van Scapino die wel het waarmerk ontving maar ontoegankelijk was in Firefox. Een openbarende (schrikbarende?) test vind ik ook die van advies.overheid.nl die veel meer aspecten bekijkt.

    Ik blijf het jammer vinden dat de nadruk zo ligt op het waarmerk en veel minder (zichtbaar) op de bewustwording en kennis bij webbouwers waarmee je mogelijk veel meer toegankelijke websites krijgt.

    geplaatst op
  • Inderdaad, ik zie het ook als het future-proof, browser-onafhankelijk en toegankelijk maken van je pagina's. De basis moet altijd valide en semantisch correct XHTML zijn. Helaas zijn er browsers met foutjes die je dan weg kan werken met fixes. Valide pagina's zijn ook makkelijker in het onderhoud, vooral als structuur en presentatie goed gescheiden worden.

    Ik heb in 2002/2003 onderzoek gedaan bij het W3C in Boston. Ik ken de mensen daar (mijn baas was Tim Berners-Lee). De sfeer die daar hangt is uniek, en de boodschap van Berners-Lee is gericht op het open houden van het web met behulp van open standaarden. Standaarden die voor iedereen vrij te zijn om te gebruiken zonder dat daar patenten op rusten.

    Als meer mensen pagina's maken die valide XHTML zijn en semantisch goed in elkaar zitten kan er meer "meaning" (zin) uit het web worden gehaald (door zoekmachines bijvoorbeeld). Het motto van het W3C is niet voor niets "Leading the Web to Its Full Potential...".

    Gelukkig hebben web designers/developers steeds vaker door wat het betekent om een pagina goed in elkaar te zetten. Je ziet bijvoorbeeld steeds minder vaak tabellen voor de lay-out.

    Al mijn pagina's zijn valide XHTML, en alle onze klanten met internetprojecten krijgen van ons het advies om valide XHTML documenten te maken.

    @Marco: de fouten van Marketingfacts hebben voor het grootste gedeelte 1 bron, namelijk het feit dat het "&" teken niet goed vertaald wordt door het cms in de HTML variant : & a m p ; (en dan zonder spaties).

    geplaatst op
  • @Rutger: "Als meer mensen pagina's maken die valide XHTML zijn en semantisch goed in elkaar zitten kan er meer "meaning" (zin) uit het web worden gehaald (door zoekmachines bijvoorbeeld). Het motto van het W3C is niet voor niets "Leading the Web to Its Full Potential..."."

    Ik denk dat in bovenstaande zin de grootste 'omslag' betekent in toegankelijk bouwen nu bekend is dat het commerciëel interessant is om zoekmachines te pleasen, en dat dat toevallig een verbetering in toegankelijkheid kan betekenen. (Even afgezien van het zoekmachinemisbruik natuurlijk.)

    Ik zie vroegere pro-flash managers volledig opgaan in semantiek en tekst.

    geplaatst op
  • De reden waarom er zo weinig W3C compliant websites zijn, is dat Microsoft zich er geen reet van aantrekt.

    Sterker nog: dat bedrijf doet juist haar best om steeds weer 'leuke' niet compatible dingetjes aan haar browser-HTML toe te voegen, in de hoop dat op Microsoft computers gebouwde websites het in concurrerende browsers niet, of in elk geval veel slechter doen.

    geplaatst op
  • @Tobi: mee eens. Gelukkig zie wel steeds meer dat het lange termijn doel (semantisch/valide markup) en het korte termijn doel ("web site zo snel mogelijk") steeds meer samen vallen.

    Valide markup betekent inderdaad meer punten bij zoekmachines, maar gelukkig is valide markup ook efficiënter in bandbreedte en onderhoud. Dat is dus ook commercieel voordelig, alleen heeft het wat meer visie nodig.

    Op dit moment heeft raar genoeg Google meer macht dan het W3C in het motiveren van webbouwers om zich aan de standaarden te houden...

    geplaatst op
  • Meh...drie pagina's geneuzel over een URL waarin dingen voorkomen die dat ding niet herkent.

    Kijk, als je bepaalde tags gebruikt die volgens de puristen van de W3C niet mogen, maar die wel voor gebruikers met een bepaalde browser een meerwaarde bieden, dan moet je ze vooral gebruiken. Elke browser vind het prachtig als je de property 'height' aan een table toekent, maar officieel mag het niet.

    Boeien!

    geplaatst op
  • Mijn sites valideren eigenlijk bijna altijd, behalve op enkele stomme punten. Zo kun je experimentele css3 tags niet gebruiken, want dan valideert je style sheet niet... Niet echt uitnodigend om te testen dus, maar ja...

    @Marco: die fouten betekenen waarschijnlijk dat je ze ooit een keer tegen gaat komen bij een nieuwe release van een browser... Als je je aan de standaard houdt heb je over het algemeen weinig te vrezen, als je veel fouten hebt kan het zijn dat je werk krijgt aan je code als er iets nieuws uit komt.

    @Carl: ik ben het niet met je eens, de voorzitter van de nieuwe HTML5 werkgroep is in dienst van Microsoft en érg betrokken bij de standaarden community. MS heeft z'n les geleerd...

    @Rutger: of dat zo gek is weet ik niet. Google heeft namelijk veel geld... Dus als je het W3C ziet, kijk dan ook wie je ziet. Een van de belangrijkste mannen binnen de HTML / CSS wereld is Ian Hickson. Ian Hickson is in dienst van... Je raadt het al, Google.

    Dan zie je nog wat andere mensen die belangrijk zijn, die werken allemaal voor Mozilla. Mozilla's geld komt bijna allemaal van? Juist. Google. Om nog maar even te vergeten dat een aantal belangrijke Mozilla ontwikkelaars zelfs ook direct in dienst zijn van Google.

    Of ik dat erg vind? Nee. Google doet daar mijns inziens een heleboel goed werk mee.

    geplaatst op
  • Ja, da's een goeie site:

    there is no attribute "NAME".
    <form name=kurl action=index.asp method=post>

    Duh...

    geplaatst op
  • @Peter: wat is daar "Duh" aan? :)

    geplaatst op
  • Je bent de aanhalingstekens vergeten, Peter...

    geplaatst op
  • Ik weet ook niet tegen welke standaard je wil valideren? In XHTML is name "deprecated", dus die kan een error geven. Name is namelijk vervangen door id :)

    geplaatst op
  • Over XHTML gesproken: zonder al te technisch te worden komt het erop neer dat je geen XHTML kunt gebruiken volgens de specificaties (serveren als 'application/xhtml+xml'), omdat IE (zowel 6 als 7) er dan niet mee overweg kunnen. Iedereen die XHTML gebruikt serveert het daarom maar als 'text/html', waardoor het per definitie al niet volgens de standaarden is.

    geplaatst op
  • Toegankelijke sites zijn essentieel niet alleen voor gebruikers met bijzondere eigenschappen, maar ook voor andere toegang via andere applicaties (het web is niet alleen maar voor desktop browsers bedoeld) en inderdaad ook voor zoekmachines.

    Validiteit is een ander punt. Het internet is gebouwd op de mogelijkheid om de bron van een pagina te kunnen bekijken om effecten na te kunnen bouwen. Als je op die manier werkt (en wie is er niet zo begonnen), loop je het risico om fouten te maken. Ik ken weinig mensen die websites maken met de specificaties van de W3C ter hand.

    Het probleem met XHTML is dan dat als je een fout maakt in je XML (iets wat veel vaker voorkomt dan je zou willen of denken), dat er dan een foutmelding wordt getoond in plaats van de rest van de webpagina. Dit is niet echt gebruikersvriendelijk.
    Daar komt nog eens bovenop dat geen enkele versie van IE XHTML ondersteunt en dat je pagina's dus als HTML moeten worden aangeleverd, wat het hele concept XHTML overbodig maakt.

    Gelukkig is de W3C weer begonnen met werken aan een nieuwe versie van HTML. Daar zit voorlopig meer toekomst in.

    Zie:
    http://www.robertnyman.com/2005/06/26/xhtml-and-error-handling/
    http://www.xml.com/pub/a/2003/03/19/dive-into-xml.html
    http://blogs.msdn.com/ie/archive/2005/09/15/467901.aspx

    geplaatst op
  • @Roy: Met een paar simpele regels PHP of andere code kun je gewoon afvangen dat je IE text/html stuurt en alle andere browsers application/xhtml+xml. Ik zou echter al lang blij zijn als iedereen gewoon eens zou beginnen met HTML 4 op een goede manier te gebruiken :)

    geplaatst op
  • @allen: leuk dat er zoveel inhoudelijk wordt gereageerd!

    @Carl: Toch valt het mee hoeveel fout nl.msn.com heeft: maar 6 fouten

    @Marco: Een schrale troost: websites met veel fouten kunnen wel goed geidexeerd worden door de zoekmachines. Jouw site is daar een voorbeeld van.

    @Joost: Dus ooit voldoet google.nl wel aan W3C ;-) Google.com heeft trouwens nog meer fouten (64) dan google.nl (41)

    geplaatst op
  • @Marco: ja ik begrijp ook niet dat wehkamp.nl voor zoveel geld is verbouwd en dan zoveel fouten heeft. Terwijl de bouwer wel groot vermeld staat in de code en ook een doctype van W3C toepast. Dan weten ze wel dat W3C bestaat ;-)


    <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
    <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="nl" lang="nl">

    <meta name="author" content="Ordina Clockwork / Wehkamp BV" />
    <!-- |=========================================================| -->
    <!-- | Project : Wehkamp.nl | -->
    <!-- | Realisation : Clockwork Internet Solutions Zwolle | -->
    <!-- | : Clockwork is een 100% dochter van Ordina | -->
    <!-- | Email : .(JavaScript moet ingeschakeld zijn om dit e-mail adres te bekijken) | -->
    <!-- |=========================================================| -->

    Misschien gebruikt Wehkamp.nl een huisgemaakt CMS dat niet zo goed met de standaarden om kan gaan. En misschien is geld verdienen belangrijker dan schone code?

    Wel vreemd dat schone code geen onderdeel is van de criterea voor de usability award....

    geplaatst op
  • Waarom is dat vreemd? Het gaat toch om of iets usable is? Niet of het onderhoudbaar is? :)

    geplaatst op
  • @Joost: Misschien haal ik accessibility en usability een beetje door elkaar, maar ik vind eigenlijk wel dat die twee begrippen hand in hand zouden moeten gaan. Ik vind dat een gebruiksvriendelijke website ook toegankelijk zou moeten zijn. Ook daar kun je een artikel over schrijven ;-)

    In de usability tips op internet kom ik accessibility niet tegen

    geplaatst op
  • @Mark: Schone code hoeft accessibility niet direct te beïnvloeden. Het vergeten van een / of het gebruiken van & i.p.v. & zorgt ervoor dat een pagina niet valideert maar zegt niet dat de pagina niet toegankelijk is.

    Dat accessibility een onderdeel is van usability ben ik met je eens, maar (helaas) kan dat ook met code vol fouten. Dat nette code geen onderdeel uitmaakt van de awards kan ik me daarom goed voorstellen. Dat is tenslotte niet wat je wilt beoordelen, zoals je bij de grand prix niet beoordeelt hoe schoon de auto is.

    geplaatst op
  • Ja. Er is totaal geen reden waarom je site niet valideert. Echter, zoals iedereen al zegt, validatie op zich zegt niet zo veel. Het is een spelling controle, waarbij geen rekening wordt gehouden met context of uberhaupt de juiste keuze van elementen. Semantische markup is het allerbelangrijkste -- wellicht zelfs belangrijker te noemen dan validatie.

    Daarentegen, een niet validerende site zegt evenmin. Er zijn situaties te bedenken (ik ben ze nog niet tegengekomen) dat je bewust niet gestandaardiseerde markup (of in het geval van CSS3 properties) gebruik wil maken. Daarnaast zijn moderne browsers in staat om in quirks mode allerlei fouten toch nog netjes te renderen voor de gebruiker.

    Het enige wat validatie zegt is dat de ontwikkelaars van de betreffende site bewust zijn van de huidige standaarden. Echter, ik wil niet zeggen dat validatie onbelangrijk is. Zeker niet, validatie is het startpunt om betere websites te maken. Zonder validatie zal de gemiddelde ontwikkelaar niet beginnen aan semantische markup en concepten als progressive enhancement. Al deze dingen dragen direct bij aan de toegankelijkheid van een website.

    @Roy, XHTML met een text/html mime-type is zeker toegestaan op het moment dat je voldoet aan de eisen in Appendix C. Dat is wat het meeste voorkomt op het moment.

    Mark brengt een goed punt naar voren betreffende CMSen. Veel software (of in het geval van .NET zelfs een geheel framework) maakt het gewoon moeilijk om valide en semantische markup er uit te gooien. Jammer, maar het is nu eenmaal zo.

    Niet dat het een excuus is... er is gewoon geen excuus om het niet goed te doen.

    geplaatst op
  • Grappig. De 2 errors op mijn nieuwe site (gebouwd door http://www.paragin.nl) hebben betrekking op mijn verificatieURL als Google AdWords Professional. Die vermeld ik als alt-tag bij het logo op mijn homepage. Pluim dus voor Paragin!

    geplaatst op
  • Ik zie nog dagelijks sites gemaakt door de grote bureau's als Lost Boys en Clockwork die honderden fouten bevatten als je ze door de W3C check heenhaalt. Ik vind het erg belangrijk dat de site niet teveel fouten bevat want dit kan leiden tot problemen in de verschillende browsers. Daarnaast is het voor de zoekmachine beter te indexeren als de site een beetje netjes opgemaakt is.

    geplaatst op
  • Ik streef er naar mijn sites bij oplevering volledig te laten valideren. Zowel (X)HTML, CSS als op accessiblity. Zoals al opgemerkt is er een groot verschil tussen valide code en een goede accessibility. Ter illustratie:

    Je kunt volledig geldige XHTML/CSS code presenteren, die barst van de (geneste) tabellen, waardoor de accessibility verschrikkelijk is. Aan de andere kant kun je bij wijze van spreken alleen een pagina met een body-tag hebben, waarin je je content zet (zonder verdere opmaak), die wel helemaal toegankelijk is, maar misschien aan de usability criteria voldoet. Tot slot kun je ook nog een geldige en toegankelijke site bouwen en er vervolgens hele lappen tekst in zetten waardoor het toch niet usable is.

    Samenvattend: Het is een samenspel tussen verschillende disciplines. De meesten kun je afzonderlijk meten, maar om ze samen te laten werken vereist een professionele webbouwer. Mijn streven richting klanten is om op alle gebieden te voldoen aan de gestelde criteria: Een overzichtelijke, linearizable (van boven naar beneden te lezen sourcecode), toegankelijke en usable site. Belangrijkste kenmerken van een site in mijn ogen zijn: title, headers (structuur) en liquid design.

    Mijn meest succesvolle site tot nu toe is die van een beddenspeciaalzaak, welke inmiddels weer enkele fouten
    tags heeft (ipv
    ), maar dat vind ik niet zo schokkend.

    geplaatst op
  • @Karel, hartelijk dank voor je pluim. Wij van Paragin leveren altijd alles op volgens de W3C-standaard. Naast het maatschappelijke belang kleeft er namelijk voor onszelf ook een groot voordeel aan mbt aanpassing en onderhoud.

    geplaatst op
  • Een gevalideerde XHTML pagina heeft veel voordelen:
    - enigzins voorspelbare weergave in veel (toekomstige) browsers
    - gestructureerde documentsopbouw (alhoewel je daar binnen de regels nog erg veel fouten kunt maken)
    - zoekmachinevriendelijk
    - bijzonder goed centraal beheersbaar
    - kleine bestandsgrootte (wie let daar tegenwoordig nog op?) en, mede daardoor
    - snelle rendering

    Wat dat laatste punt betreft heb ik begrepen dat je DTD aangeeft hoe groot de set van tekens is die de browser gaat gebruiken om de pagina op te bouwen. Hoe beperkter die set (XHTML strict), hoe sneller de rendering. Een semantisch opgebouwde en gevalideerde pagina bouwt zich echt razendsnel op en dat is pas gebruiksvriendelijk!

    Een 100% gevalideerde pagina is best lastig om te maken (en te houden) en dat doel dwingt je om secuur en doordacht te werken, maar ik denk niet dat je erg druk hoeft te maken over een paar fouten. Binnen de punten hierboven heeft het in ieder nauwelijks invloed. Gaan ze in de honderden lopen, dan moet je je natuurlijk wel gaan afvragen waarom je het uberhaupt probeert... En dan zal het ook wel merkbaar worden.

    Natuurlijk staat de validering los van de usabillity en accessability, maar als je de richtlijnen volgt wordt het maken van een goed te gebruiken en benaderen website wel een stuk makkelijker.

    Oh ja, en de reden waarom er nu zo weinig sites volledig compliant zijn komt natuurlijk niet omdat 'Microsoft zich er geen reet van aantrekt' (flauw), maar omdat opdrachtgevers nog maar kort openstaan voor het belang ervan. 'Vroeger' was een site een site en of dat met plakband, HTML of Flash in elkaar werd gezet boeide ze gewoon niet. Als het er maar goed uitzag... En nu moet het opeens zoekmachine- en gebruiksvriendelijk en dan is de W3C opeens wel logisch en een voorwaarde.

    Peter.

    geplaatst op
  • Wat ik er zelf prettig vind als mijn site valideert, is dat als er tijdens het ontwikkelen gekke dingen gebeuren met de pagina, je de validator kan gebruiken om te zoeken of je fouten in de html hebt gemaakt.

    Tja, en dat gaat makkelijker als er niet 400 fouten staan.

    Blijft natuurlijk waar dat een valide pagina maar 1 onderdeel is van een toegankelijke website. Goede semantisch correcte html is veel belangrijker.

    geplaatst op
  • We hebben bij Interpolis het informatieve gedeelte van de website toegankelijk gemaakt op prioriteit 1 t/m 3 van accessibility.nl. Er zijn op dit moment niet veel sites die dit al bereikt hebben.

    Nu moeten echter de applicaties nog volgen. Die voldoen nog lang niet aan alle standaarden. Doel is om de applicaties in ieder geval aan de hoogst noodzakelijke standaarden te laten voldoen [ in termen van drempelvrij; 'het oranje mannetje']

    geplaatst op
  • Het grote probleem bij de standaarden van w3 is dat het simpel weg niet werkt in de praktijk. Zo kan een site die 100% goed is opgemaakt, nog steeds er anders uitzien in diverse browsers. Er zijn diverse tests die dit laten zien , en die geven zelfs problemen weer bij firefox en natuurlijk internet explorer (bv de acid 2 test. http://www.webstandards.org/files/acid2/test.html). Zolang w3 niet daad krachtig is, en de browsers de standaarden niet 100% opvolgen zullen de webmasters ook geen belang aan 100% valid site's geven.

    geplaatst op
  • @ P.Bakker: de acid2 test, hoe gaaf ook, is niet echt een goed voorbeeld aangezien dat eigenlijk voornamelijk de error handling test, en niet de features... "de webmasters" bestaan niet, zoals ook wel blijkt uit de comments hier zijn er vele mensen die w?l waarde hechten aan compliance...

    geplaatst op
  • Nog een voordeel als je webstandaarden volgt: leveranciersonafhankelijkheid (3x woordwaarde, noteer je 'em even ha). Denk bijv. aan de inwerktijd van een gedetacheerde webbouwer, scheelt al wat uurtjes hoor, dat uitzoekwerk!

    geplaatst op
  • @Wowbagger, ik ben het niet met al je punten eens.

    Een gevalideerde XHTML pagina heeft veel voordelen:
    1 enigzins voorspelbare weergave in veel (toekomstige) browsers
    3 zoekmachinevriendelijk
    4 bijzonder goed centraal beheersbaar

    1 Het punt XHTML ga ik niet opnieuw bespreken aangezien dat al vaak genoeg gedaan is in dit bericht. XHTML werkt niet in IE en een eventuele opvolger zal er alleen komen voor HTML (HTML 5).
    3. Zoekmachine vriendelijkheid heeft niets met validatie te maken. Zoekmachine vriendelijkheid is afhankelijk van het juist en semantisch gebruik van de juiste elementen op de juiste plaats. Daarbij is de gehanteerde structuur en de daarin geplaatst content belangrijk. Dat kan zowel in een gevalideerde als een niet gevalideerde site.
    4. Dit punt begrijp ik niet, waarom zou een gevalideerde pagina beter beheersbaar zijn? Omdat hij over het algemeen makkelijker te lezen is? Dat heeft meer met semantiek te maken dan met validatie.

    geplaatst op
  • Overigens is de hypeterm die we hier even niet moeten vergeten te noemen natuurlijk POSH: Plain Old Semantic HTML.

    geplaatst op
  • @André

    Mmwja, op de punten 3 en 4 moet ik je denk ik wel gelijk geven. Dat zijn eerder voordelen van de techniek (XHTML en CSS), gevalideerd of niet. Maar dat validatie je dwingt om secuur en doordacht te werken geeft er toch wel weer meerwaarde aan. En validatie kan toch ook semantische onjuistheden aan het licht brengen?

    Punt 1 is me uit bovenstaande niet duidelijk geworden. Of XHTML er in 'werkt' of niet, in IE7 is de uitkomst in ieder geval bijzonder voorspelbaar geworden (en met wat oefening ook in IE6). Maar misschien ook weer voordelen van de techniek (die je wat mij betreft moeilijk los kan zien van validatie).

    geplaatst op
  • @wowbagger, nee, validatie is een spelling controle, geen grammatica controle. Met andere woorden, het geeft alleen aan of de door jouw gebruikte elementen en de resulterende hiërarchie correct zijn. Het doet geen uitspraken over de keuze van de elementen met betrekking tot de content.

    Zoals André al zei, er is niets als XHTML voor MSIE. Voor MSIE moet XHTML als text/html worden geserveerd, waardoor het in feite gewoon HTML is (mits het aan Appendix C voldoet, anders tagsoup). Er kan ook geen gebruik gemaakt worden van application/xhtml+xml, omdat deze MIME-type niet ondersteunt wordt door MSIE.

    Ik denk waar jij op doelt is het wel of niet gebruik van een correcte DTD. Ook de DTD is eigenlijk niet van belang in het hele standaarden verhaal. De DTD wordt alleen gebruikt voor twee dingen.

    1. De W3C validator te informeren over de te verwachten smaak van de HTML
    2. De browser te informeren over de rendering mode die aangehouden moet worden (quirks mode of standards compliance mode). Zie doctype switching.

    Wat dat laatste betreft heb je gelijk. Het is geen doen om te proberen te standaarden aan te houden als je MSIE niet forceert om ook de juiste algoritmes toe te passen. Zoals meerdere browsers implementeert MSIE hier en daar twee versies, afhankelijk van de betreffende mode die wordt getriggerd door de DTD. Het voornaamste voorbeeld hiervan is het CSS box model.

    geplaatst op
  • Nu moet Onstuimig natuurlijk ook iets zeggen. :-)

    Wij vinden standaarden belangrijk. Erg belangrijk. Maar geen doel op zich.

    Het tellen van 'fouten' in sites met behulp van de w3c-validator is dan ook -behalve wel leuk om eens te doen- niet zo zinvol:

    1. Elke fout lijkt op deze manier even zwaar te tellen, terwijl een enkele fatale fout veel ernstiger kan zijn dan 10 fouten die er niet zo toe doen. Het beeld is dus per definitie enorm vertroebeld zonder een goede interpretatie en weging.

    2. Een goed voorbeeld bij het eerste punt: dezelfde 'fout' die herhaaldelijk 100 keer voorkomt in een pagina, wordt 100 keer geteld. Zoals Rutger al aangaf: een groot deel van de fouten in Marketingfacts wordt veroorzaakt door een kleine, zich elke keer opnieuw herhalende overtreding in de output van het cms (Expression Engine in het geval van Marketingfacts). Een groot schrijver met een spelfout is nog steeds een groot schrijver. Dat geldt ook voor blogsoftware :-)

    Een dosis purisme is dus waardevol -dat houdt ons bij de les- maar andere factoren als usability, design, de stabiliteit en mogelijkheden van Expression Engine en het pragmatischer 'goed bruikbaar in alle gangbare browsers' wegen voor Onstuimig in de praktijk zwaarder dan volledig zonder kleerscheuren door de w3c-validator komen.

    Zoals mijn oma vroeger zei: boerenverstand is ook voor stadse mensen.

    geplaatst op
  • Ik ben het met mijn naamgenoot eens. Verder grappig om te zien dat dezelfde voordelen altijd netjes opgesomd worden :).

    geplaatst op
  • @Carl: Ik weet zo net nog niet of het Microsoft niets kan schelen...

    Ik lees net het volgende persbericht:

    Microsoft Nederland organiseert een wedstrijd voor de bouw van een zo toegankelijk mogelijke website, in het bijzonder voor ouderen en mensen met een visuele beperking. Het beste ontwerp wint tweeduizend euro.

    De wedstrijd promoot Microsofts nieuwe designsuite Expression Web. Deelnemers die zich op http://www.rockmywebsite.nl hebben ingeschreven, kunnen vanaf 8 mei de starterskit downloaden. Microsoft richt zich met deze wedstrijd vooral tot webdesigners en studenten, maar iedereen boven de achttien jaar mag meedoen.

    Het is de bedoeling om een zeer toegankelijke site te bouwen voor Stichting Waarmerk drempelvrij.nl. Die organisatie geeft waarmerken uit (zie foto) voor sites die ook toegankelijk zijn voor bijvoorbeeld slechtzienden. De stichting beoordeelt sites aan de hand van allerlei criteria, zoals doordacht kleurgebruik en controle van flikkeringen.

    De site van de stichting mag zélf echter ook wel wat toegankelijker, en daar ligt dus de uitdaging voor wedstrijddeelnemers. Het winnende ontwerp gaat live voor Drempelvrij.nl en levert een geldprijs van tweeduizend euro op. De nummer twee verdient duizend euro. De meest innovatieve website wint een XBox 360-pakket.

    De inzendingen worden beoordeeld door een vijfkoppige vakjury met daarin onder anderen de creatief directeuren van Lost Boys, Wunderman en Mirabeau. Op 8 juni worden de vijf finalisten bekendgemaakt. Zij mogen hun ontwerp demonstreren tijdens Microsoft Developer Days & Remix 2007 op 14 juni in de Rai te Amsterdam. Daar wordt ook de winnaar gekozen.

    geplaatst op
  • Voor iedereen die deze thread volgt is de webdesign survey van alistapart eigenlijk een verplicht nummer :)

    geplaatst op
  • En rockmywebsite.nl is inderdaad W3C compliant! 0 fouten....

    geplaatst op
  • Met bijna 25 verbouwingen nog steeds maar 30 fouten volgens de validator......

    Valt mij dus reuze mee.

    geplaatst op
  • Even wat tijd geinvesteerd..en we hebben er nog maar 1....

    Dus kom maar op met die browser update''s.

    geplaatst op
  • De 28 fouten van http://www.funda.nl kwamen bijna allemaal door de javascript die niet geinclude was. Dit wordt spoedig hersteld.

    geplaatst op
  • We hebben bij goomla.nl vrij strict de w3c validatie in het achterhoofd gehouden tijdens de ontwikkeling. Als er vanaf moment één serieus mee wordt omgegaan is het absoluut geen probleem om goede valide pagina's te bouwen.

    Ik zie nu terwijl ik dit artikel lees dat onze rencte kleuren zoekfunctie wel een paar foutjes heeft. Die moeten we maar even gaan fixen vandaag.

    geplaatst op
  • De webstandaarden zijn een goed ding, echter het probleem is dat verschillende browsers op dezelfde code totaal verschillend reageren. Hiervoor zijn vaak trucs om deze op te lossen, maar je raad het al, deze trucs zijn over het algemeen geen nette trucs en leveren fouten op.

    Een ander probleem van de webstandaarden is de volgende: de standaarden leveren redelijk wat beperkingen op het maken van een website. Ik vind dat je bij het ontwerpen van een website niet moet denken in wat er mogelijk is, maar vanuit de kwaliteit & functionaliteit die het kan opleveren.

    Kortom, webstandaarden zijn goed, maar niet heilig.

    geplaatst op
  • Het is een erg leuke tool maar geen doel op zich. Het gaat erom dat je de gebruiker een goed werkende site voorschoteld waarbij hij snel de informatie vind waarbij naar op zoek is. Bij de bouw moet uiteraard rekening houden met de webstandaarden maar tot welk detail. Het feit alleen al dat Bol.com en Wehkamp enkele honderen foutmeldingen krijgen ,zegt dat iets over de gebruikersvriendelijkheid en de conversie?

    geplaatst op
  • Heb hier nu weer een gast die per se de boel wil afleveren in XHTML omdat dat netter zou zijn en beter gelezen wordt etc. etc. Dit slaat nergens op, dezelfde voordelen kunnen ook gehaald worden met HTML4 en dat wordt tegelijkertijd overal beter ondersteund.

    Lees dit artikel waarin door de mensen van IE, Mozilla, Opera, Apple, W3C en Google wordt afgeraden om XHTML te gebruiken: http://www.webdevout.net/articles/beware-of-xhtml

    geplaatst op
  • @Martin; ja dat zegt iets over hun conversie; die was bij het volgen van de webstandaarden wellicht hoger geweest!

    geplaatst op
  • @ Maurice; beweer je dus dat mensen zijn afgehaakt of de website niet goed hebben kunnen bekijken vanwege het niet volledig in acht nemen van de W3C regels? Natuurlijk heb je gelijk dat je een website goed moet opleveren. Maar tot welke prijs? Het gaat om tijd, geld / omzet en kosten. Hoeveel hoger zou in jou ogen de conversie zijn geweest? o,oooo1% of 0,2?

    geplaatst op
  • @Martin,

    % zijn moeilijk te noemen op jouw reactie...

    Maar: ga er nou eens vanuit dat je site niet 100% w3c compliant is en je hebt 32.000 unieke bezoekers tot op heden in de maand april (realistisch voorbeeld).

    Hiervan komt 1,29% met de Safari Browser. en dit werkt niet? (aanname).

    Conversie gemiddelde is: 3,02%.

    Dan zou ik dus in het ergste geval bijna 13 conversies hebben gemist in 1 maand.

    Van het totaal zou ik dus 0,14% minder conversie hebben gehad.

    Dan zou ik dus in het ergste geval 97,74% als browser dus pak je het grootste deel, maar het verschil zit hem toch vaak in de details?

    geplaatst op
  • Hm...

    Die laatste zin klopt niet helemaal....

    Maar ik wilde ermee aangeven dat je dus in het ergste geval van de 100% leads die je kan pakken als je w3c Compliant bent dat je ca. 2,3% van je totale omzet kan laten liggen....

    bij een site als wehkamp gaat dit dan toch al snel om veel geld.

    geplaatst op
  • Nog even terug naar het artikel zelf en om de onduidelijkheid bij Mark weg te nemen: Het klopt inderdaad dat op dit momen een site drempelvrij kan zijn en geen valide code oplevert.

    Het Waarmerk drempelvrij.nl gaat op dit moment over prioriteit 1 van WCAG. Valide code is prioriteit 2. De nieuwe norm waaraan op dit moment wordt gewerkt zal zowel prioriteit 1, prioriteit 2 als de webrichtlijnen van de overheid omvatten.

    Het Waarmerk zal straks naar verwachting in 3 kwaliteitsniveaus behaald kunnen worden:
    1) voldoet aan prio 1
    2) voldoet aan prio 1+2
    3) voldoet aan de webrichtlijnen (=prio1 + prio2 + aanvullende webrichtlijnen)

    geplaatst op
  • Zoals hierboven al wordt gezegd heeft validatie aan de W3C-standaarden veel voordelen, maar moet het geen doel op zich worden. Het zal je misschien verbazen, maar een CMS kan nog zo goed zijn, volstrekt W3C-valide code gebruiken is soms onmogelijk. Wanneer je bijvoorbeeld bij formulieren client-side validatie wilt toepassen (dus al in de browser laten checken of ingevulde waarden kunnen kloppen) heb je al een fiks probleem. Ja, maar het W3C heeft toch ook formulieren? Jazeker, maar die zijn wel erg simpel en hebben hooguit server-side validatie. Het is eigenlijk heel eenvoudig: de standaarden van het W3C lopen nu eenmaal achter op de ontwikkelingen in de techniek. Dat maakt de standaarden niet minder waardevol, maar gezond verstand blijft de beste leidraad. Dat laat onverlet dat valide code de bruikbaarheid in diverse browsers vergroot en daarom zeker een factor hoort te zijn bij het maken van een website. Het vailderen van je code is geen speeltje voor techneuten, het is service aan de bezoekers van de site en daarmee aan je opdrachtgever.

    Het gegoochel met statistieken in enkele reacties hierboven is leuk, maar geeft een vertekend beeld. Ik surf zelf met Opera en kom daardoor iets vaker dan gemiddeld fouten in websites tegen. Soms waag ik daar een mailtje aan om er op te wijzen. Om de haverklap krijg je als reactie terug: "Ja, maar niet meer dan 0,5 % van onze bezoekers komt met Opera, daar gaan we geen moeite voor doen."
    Dat klinkt logisch, maar even doordenken levert een flinke "maar" op: als je site op een essentieel onderdeel niet werkt in een wat exotischer browser of een fijne interactieve gadget blijft halverwege hangen, wat doet zo'n bezoeker dan de volgende keer? Precies, die zioekt meteen een andere site op. Dus waar de Explorerbezoeker terugkomt en misschien wel 100 keer per jaar je site bezoekt, komt de Operabezoeker 1 keer en nooit meer. Ja, zo krijg je vanzelf statistieken met enorme percentages bezoekers met IE! Dat wil niet zeggen dat je in elke browser moet testen en voor elke browser alles moet proberen op te lossen, maar code valideren en kleine foutjes oplossen scheelt daarin al heel wat. Dat is immers niet een fout in een browser die je probeert op te lossen, je zorgt dat je eigen site alles netjes aanlevert.

    Code valideren is iets wat elke serieuze webbouwer hoort te doen in mijn opinie, maar er kunnen soms goede argumenten zijn om foutmeldingen te negeren.

    geplaatst op
  • @ Eric dit noem ik nou een zinvolle aanvulling. Prima verhaal.

    geplaatst op
  • Interessante discussie; jammer alleen dat ik 'm zo laat heb ontdekt.

    Het gaat in de discussie tot dusverre vooral over het belang van toegankelijkheid en van valide code en da's op zichzelf wel logisch. Die valide code is echter geen doel op zich. De Webrichtlijnen zijn - in 2004 alweer - ontwikkeld als instrument om de kwaliteit van overheidswebsites te verbeteren, door het opdrachtgeverschap te versterken.

    De Webrichtlijnen zijn een model waarmee een opdrachtgever dat doel kan bereiken. Toegankelijkheid en valide code zijn in het model verwerkt als kwaliteitsaspecten. Het grote probleem tot dusverre met die twee onderwerpen is dat toegankelijkheid wordt gezien als iets dat je doet voor gehandicapten en standards compliance als iets voor nerds. Belangrijk voordeel van beide is dat ze vrij goed toetsbaar zijn en dat is interessant, want zo kun je kwaliteit meetbaar maken. Je hoeft dus niet de bouwer van een site op z'n woord te geloven dat de site goed is, je kunt het ook meten. Daarmee geef je de opdrachtgever een middel in handen om te (laten) controleren of contractueel vastgelegde afspraken zijn nagekomen. Voor overheden is dat met name van belang, omdat een overheidsorganisatie in principe niemand mag buitensluiten van de informatie en diensten die zij aanbiedt. Dat is voor de rijksoverheid inmiddels formeel vastgelegd in een kabinetsbesluit, dat werd genomen naar aanleiding van een motie van de Tweede Kamer.

    Of een site aan de Webrichtlijnen kan voldoen hangt in belangrijke mate af van: (1) de kennis en kunde van de opdrachtnemer, (2) de mate waarin de opdrachtgever stuurt op de kwaliteit van het uiteindelijke product en (3) de wijze waarop controle op de (bouw)kwaliteit tijdens en na de bouw, èn tijdens het beheer van een site in een proces is verankerd. Toepassing van techniek (XHTML versus HTML, validatie etc.) is dus 'slechts' een deel van het verhaal. De meeste opdrachtgevers hebben hier weinig affiniteit mee, maar met de Webrichtlijnen wel een middel om voorafgaand aan een opdracht gedetailleerde eisen te stellen en tijdens de bouw en achteraf te (laten) controleren aan de eisen is voldaan. En als ze het ècht goed hebben georganiseerd is het opgeleverde product bovendien eenvoudiger in beheer.
    Voor alle duidelijkheid: De Webrichtlijnen bieden geen garantie voor succes; ze zijn naar mijn mening wel een belangrijke randvoorwaarde voor succes.

    Mijn top-3 favoriete websites waarbij de Webrichtlijnen bij de ontwikkeling een belangrijke rol hebben gespeeld, en die het vanwege de ver doorgevoerde semantiek waard zijn om eens nader te bekijken, zijn (in willekeurige volgorde ;-)
    * De regelingenbank van Stadskanaal
    * De corporate website van het ministerie van VWS
    * Opvallendeplanten.nl

    Die laatste is overigens mijn eigen proeftuintje (hoezo bescheiden...), waar gebruik wordt gemaakt van een database en geëxperimenteerd met unobtrusive JavaScript, standards compliant Flash, zoomable layout etc. De eigenaar van de site is niet zo geïnteresseerd in de Webrichtlijnen, maar vindt het allemaal best zolang het hem maar niet hindert. Dat is tot dusverre niet gebeurd. Dat z'n site inmiddels hoog staat in Google als je 'kniphofia' intikt vindt-ie daarentegen helemaal top.

    geplaatst op
  • PSje bij de vorige post. Bij 2 URL's is het fout gegaan:
    * De regelingenbank van Stadskanaal: http://www.regels-stadskanaal.nl/
    * De corporate website van het ministerie van VWS: http://www.minvws.nl/

    geplaatst op
  • Toevallig was ik gister ook een onderzoekje hier naar aan het doen. Ik zag dat dutchcowboys perfect door de validatie heen kwam!

    geplaatst op
  • Bij Nedforce ontwikkelen wij pagina's volgens de Webrichtlijnen. Onze eigen site scoort 100% op de automatische test. Het team dat de Webrichtlijnen ontwikkelt heeft duidelijk verstand van zaken: de punten zijn zeker best practices en bovendien goed onderlegd.

    De moeilijkheid in het "volhouden" van de Webrichtlijnen zit niet in de initiële implementatie, maar in het filteren van content van gebruikers en externe systemen. Hiervoor moet goed worden gefilterd c.q. afspraken worden gemaakt met de gebruikersorganisatie.

    geplaatst op
  • Ik word eerlijk gezegd schijt ziek van W3C en zijn richtlijnen.
    W3C geeft aan dat ik 1 fout heb, ik werk met webdesign pro en voeg zelf html codes toe.
    Ik heb een laptop als plaatje staan echter geeft W3C steeds deze fout aan, echter maakt niet uit of ik het aanpast aan de Wc richtlijnen. hij blijft hem steeds aangeven.
    Error Line 48, Column 126: Attribute "ONLOAD" is not a valid attribute. Did you mean "onload"?

    …ame="laptop" title="" alt="" onload="OnLoadPngFix()"></div>
    Terwijl andere plaatjes zelfde code hebben hoor je W3C hier niet over, ook niet over ONLOAD.

    Ik heb er zelf wel vrede mee, zker als ik lees hoeveel fouten grote namen hebben in hum website.

    geplaatst op
  • Sorry voor mijn slordige tekst hier boven.

    Maar ben echt ......... ;-)
    Zeker aangezien de rest van dezelfde codes goed door de keuring heen komen.
    Heb mijn website op verschillende browser getest en het geeft geen enkel probleem.

    Maar goed het lucht wel op om hier je hart te luchten ;-)

    geplaatst op

Plaats zelf een reactie

Log in zodat je (in het vervolg) nóg sneller kunt reageren

Vul jouw naam in.
Vul jouw e-mailadres in. Vul een geldig e-mailadres in.
Vul jouw reactie in.

Herhaal de tekens die je ziet in de afbeelding hieronder


Let op: je reactie blijft voor altijd staan. We verwijderen deze dus later niet als je op zoek bent naar een nieuwe werkgever (of schoonmoeder). Reacties die beledigend zijn of zelfpromotioneel daarentegen, verwijderen we maar al te graag. Door te reageren ga je akkoord met onze voorwaarden.