Wie houdt zich aan de webrichtlijnen van W3C en drempelvrij?
Als 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!
Mark de Bruin (@mdebruin) schreef in 2007 zijn eerste blog bij Marketingfacts. Inmiddels zijn het er meer dan 150. Mark (1976) is senior marketeer met expertises in innovatie, online marketing, mobiliteit en digitale proposities via nieuwe media (internet, apps, social media, internet of things en AI) met focus op relevantie op langere termijn. Onderwerpen waar Mark graag over schrijft zijn: apps, Spotify, social media, trends en innovatie. Mark heeft vanaf 1997 bij deze werkgevers gewerkt aan innovatie, product ontwikkeling & marketing: Philips Origin eCommerce (1997/1998), PTT Post (1998-2000), Het Financieele Dagblad (2000-2004) 9292OV (2004-2011), ANWB (2011-2022) en 9292 (2022-2024). Vanaf 1 augustus 2024 werkt Mark als Innovatiestrateeg bij de Consumentenbond.
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.
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?
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.
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 ), 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.
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.
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).
@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.
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.
@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…
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!
Ja, da’s een goeie site:
there is no attribute “NAME”.
<form name=kurl action=index.asp method=post>
Duh…
@Peter: wat is daar “Duh” aan? 🙂
Je bent de aanhalingstekens vergeten, Peter…
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 🙂
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.
@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 🙂
Waarom is dat vreemd? Het gaat toch om of iets usable is? Niet of het onderhoudbaar is? 🙂
@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.
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!
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.
@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.
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.
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.
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’]
@ 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…
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!
@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.
@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).
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.
Ik ben het met mijn naamgenoot eens. Verder grappig om te zien dat dezelfde voordelen altijd netjes opgesomd worden :).
@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.
Met bijna 25 verbouwingen nog steeds maar 30 fouten volgens de validator……
Valt mij dus reuze mee.
Even wat tijd geinvesteerd..en we hebben er nog maar 1….
Dus kom maar op met die browser update”s.
De 28 fouten van http://www.funda.nl kwamen bijna allemaal door de javascript die niet geinclude was. Dit wordt spoedig hersteld.
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.
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?
@Martin; ja dat zegt iets over hun conversie; die was bij het volgen van de webstandaarden wellicht hoger geweest!
@ 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?
@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?
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.
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)
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.
@ Eric dit noem ik nou een zinvolle aanvulling. Prima verhaal.
Toevallig was ik gister ook een onderzoekje hier naar aan het doen. Ik zag dat dutchcowboys perfect door de validatie heen kwam!
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()”>
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.
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 😉
Gerelateerde artikelen
Marketingfacts. Elke dag vers. Mis niks!
Marketingfacts. Elke dag vers. Mis niks!