<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Reacties op: Webrichtlijnen: suf of sexy?</title>
	<atom:link href="http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/</link>
	<description>Nieuws en opinie over digitale trends</description>
	<pubDate>Thu, 28 Aug 2008 17:35:52 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>Door: Ferry den Dopper&#8217;s blog on User Experience &#187; Blog Archive &#187; Webrichtlijnen: suf of sexy?</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61449</link>
		<dc:creator>Ferry den Dopper&#8217;s blog on User Experience &#187; Blog Archive &#187; Webrichtlijnen: suf of sexy?</dc:creator>
		<pubDate>Sun, 23 Dec 2007 23:25:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61449</guid>
		<description>[...] Dit artikel is ook verschenen op Frankwatching. [...]</description>
		<content:encoded><![CDATA[<p>[...] Dit artikel is ook verschenen op Frankwatching. [...]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Ferry den Dopper</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61332</link>
		<dc:creator>Ferry den Dopper</dc:creator>
		<pubDate>Mon, 17 Dec 2007 21:08:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61332</guid>
		<description>Fijn dat er zoveel goede, uitgebreide reacties op dit onderwerp komen. Ik denk dat we het met elkaar eens zijn dat de Webrichtlijnen bijdragen aan de kwaliteit van websites. Webapplicaties waar veel / complexe interactie op de client (Flash/AJAX/Javascript) plaatsvindt, zijn inderdaad een stuk moeilijker te realiseren volgens de huidige richtlijnen. Maar eerder dit jaar woonde ik een &lt;a href="http://www.den-dopper.com/2007/04/20/webtoegankelijkheid-voor-gevorderden-deel-2/" rel="nofollow"&gt;workshop van Derek Featherstone&lt;/a&gt; bij waarin hij specifiek inging op de toegankelijkheid van Rich Internet Applications (RIA's) inging. Ik haalde toen ook de in ontwikkeling zijnde &lt;a href="http://www.w3.org/TR/aria-roadmap/" rel="nofollow"&gt;W3C-richtlijnen voor Accessible Rich Internet Applications (ARIA)&lt;/a&gt; aan. Er gebeurt dus zeker iets op dit gebied. En, zoals Raph ook aangeeft, als er nieuwe best practices ontstaan, zullen ook de Webrichtlijnen mee moeten evolueren.

@Remco: Jij vraagt of ik vind dat webstandaard-compliant sites ook per definitie goede sites zijn. Nee, daarover ben ik het met je eens. Usability is een kwaliteit die ik nog boven webstandaarden vind staan. Als mensen je website niet relevant vinden, niet snappen of niet kunnen gebruiken, ligt daar je eerste prioriteit. Maar hierin ligt niet de taak van de Webrichtlijnen. Zoals ik in het artikel zelf al aangeef, is usability nauwelijks te vangen in universele, meetbare richtlijnen. Usability is deels 'common practice' en deels contextafhankelijk.</description>
		<content:encoded><![CDATA[<p>Fijn dat er zoveel goede, uitgebreide reacties op dit onderwerp komen. Ik denk dat we het met elkaar eens zijn dat de Webrichtlijnen bijdragen aan de kwaliteit van websites. Webapplicaties waar veel / complexe interactie op de client (Flash/AJAX/Javascript) plaatsvindt, zijn inderdaad een stuk moeilijker te realiseren volgens de huidige richtlijnen. Maar eerder dit jaar woonde ik een <a href="http://www.den-dopper.com/2007/04/20/webtoegankelijkheid-voor-gevorderden-deel-2/" rel="nofollow">workshop van Derek Featherstone</a> bij waarin hij specifiek inging op de toegankelijkheid van Rich Internet Applications (RIA&#8217;s) inging. Ik haalde toen ook de in ontwikkeling zijnde <a href="http://www.w3.org/TR/aria-roadmap/" rel="nofollow">W3C-richtlijnen voor Accessible Rich Internet Applications (ARIA)</a> aan. Er gebeurt dus zeker iets op dit gebied. En, zoals Raph ook aangeeft, als er nieuwe best practices ontstaan, zullen ook de Webrichtlijnen mee moeten evolueren.</p>
<p>@Remco: Jij vraagt of ik vind dat webstandaard-compliant sites ook per definitie goede sites zijn. Nee, daarover ben ik het met je eens. Usability is een kwaliteit die ik nog boven webstandaarden vind staan. Als mensen je website niet relevant vinden, niet snappen of niet kunnen gebruiken, ligt daar je eerste prioriteit. Maar hierin ligt niet de taak van de Webrichtlijnen. Zoals ik in het artikel zelf al aangeef, is usability nauwelijks te vangen in universele, meetbare richtlijnen. Usability is deels &#8216;common practice&#8217; en deels contextafhankelijk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Raph de Rooij</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61321</link>
		<dc:creator>Raph de Rooij</dc:creator>
		<pubDate>Mon, 17 Dec 2007 16:53:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61321</guid>
		<description>@Walter:
Je beschrijft treffend wat Ferry in zijn artikel met 'worstelen' aanduidt. Ik heb de afgelopen jaren regelmatig contact gehad met de Belastingdienst over toepassing van de Webrichtlijnen. Toen bleek ondermeer dat, vanwege een zeer strikt beveiligingsbeleid voor de hosting van websites en (vrees voor) performanceproblemen, er praktisch geen server-side toepassingen mogen worden gebruikt. Is dat nog steeds zo? Want een dergelijke beleid beperkt een webontwikkelaar enorm in zijn mogelijkheden. Je kunt dan bijvoorbeeld praktisch geen fall-backs creëren voor client-side functionaliteit.
Als dat beleid er nog steeds is dan zijn de 'ingewikkelde en zelfs rare situaties' waar je het over hebt naar mijn mening niet enkel toe te schrijven aan de Webrichtlijnen.

Voor wat betreft het openen van een downloadbaar bestand: daar moet je helemaal geen nieuw browservenster voor *willen* openen! De term die hier van toepassing is, is content disposition. Dat komt neer op het zodanig serveren van bepaalde typen bestanden dat ze niet in een browservenster worden geladen. Het aan dat bestandstype geassocieerde programma wordt gestart, waarna het bestand in dat programma wordt geopend. Belangrijk voordeel is dat dan alle functionaliteiten van het programma beschikbaar zijn en dat het bestand niet in de browser zelf wordt geopend. Het risico dat je de hele site verliest als je het bestand sluit speelt hier dus niet. Voor meer info hierover, zie http://stijlgids.overheid.nl/actueel/weblog/downloadbare_bestanden_openen_in_een_nieuw_venster/
Overigens heb ik een tijd geleden een artikel geschreven over het openen van links in een nieuw venster, zie www.raph.nl/deprecated/target/. Het kan dus best...

Ik ben het overigens helemaal met je eens dat het tijd is voor een revisie van de Webrichtlijnen vanuit de praktische toepasbaarheid. Ik verwacht echter niet dat het openen van links of downloadbare bestanden in een nieuw venster tot aanpassing hoeven te leiden: daar bestaan prima oplossingen voor, alleen zijn die (nog) niet algemeen bekend. En dat is dan weer een probleem van een heel andere soort: betere kennisdeling kan een belangrijke bijdrage leveren aan de oplossing van een dergelijk probleem. "Het kan niet" betekent in de praktijk vaak "het is (me) nog niet gelukt". Dat maakt volgens mij in belangrijke mate deel uit van de worsteling waar Ferry het in zijn artikel over heeft.</description>
		<content:encoded><![CDATA[<p>@Walter:<br />
Je beschrijft treffend wat Ferry in zijn artikel met &#8216;worstelen&#8217; aanduidt. Ik heb de afgelopen jaren regelmatig contact gehad met de Belastingdienst over toepassing van de Webrichtlijnen. Toen bleek ondermeer dat, vanwege een zeer strikt beveiligingsbeleid voor de hosting van websites en (vrees voor) performanceproblemen, er praktisch geen server-side toepassingen mogen worden gebruikt. Is dat nog steeds zo? Want een dergelijke beleid beperkt een webontwikkelaar enorm in zijn mogelijkheden. Je kunt dan bijvoorbeeld praktisch geen fall-backs creëren voor client-side functionaliteit.<br />
Als dat beleid er nog steeds is dan zijn de &#8216;ingewikkelde en zelfs rare situaties&#8217; waar je het over hebt naar mijn mening niet enkel toe te schrijven aan de Webrichtlijnen.</p>
<p>Voor wat betreft het openen van een downloadbaar bestand: daar moet je helemaal geen nieuw browservenster voor *willen* openen! De term die hier van toepassing is, is content disposition. Dat komt neer op het zodanig serveren van bepaalde typen bestanden dat ze niet in een browservenster worden geladen. Het aan dat bestandstype geassocieerde programma wordt gestart, waarna het bestand in dat programma wordt geopend. Belangrijk voordeel is dat dan alle functionaliteiten van het programma beschikbaar zijn en dat het bestand niet in de browser zelf wordt geopend. Het risico dat je de hele site verliest als je het bestand sluit speelt hier dus niet. Voor meer info hierover, zie <a href="http://stijlgids.overheid.nl/actueel/weblog/downloadbare_bestanden_openen_in_een_nieuw_venster/" rel="nofollow">http://stijlgids.overheid.nl/actueel/weblog/downloadbare_bestanden_openen_in_een_nieuw_venster/</a><br />
Overigens heb ik een tijd geleden een artikel geschreven over het openen van links in een nieuw venster, zie <a href="http://www.raph.nl/deprecated/target/" rel="nofollow">http://www.raph.nl/deprecated/target/</a>. Het kan dus best&#8230;</p>
<p>Ik ben het overigens helemaal met je eens dat het tijd is voor een revisie van de Webrichtlijnen vanuit de praktische toepasbaarheid. Ik verwacht echter niet dat het openen van links of downloadbare bestanden in een nieuw venster tot aanpassing hoeven te leiden: daar bestaan prima oplossingen voor, alleen zijn die (nog) niet algemeen bekend. En dat is dan weer een probleem van een heel andere soort: betere kennisdeling kan een belangrijke bijdrage leveren aan de oplossing van een dergelijk probleem. &#8220;Het kan niet&#8221; betekent in de praktijk vaak &#8220;het is (me) nog niet gelukt&#8221;. Dat maakt volgens mij in belangrijke mate deel uit van de worsteling waar Ferry het in zijn artikel over heeft.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Remco Kouwenhoven</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61319</link>
		<dc:creator>Remco Kouwenhoven</dc:creator>
		<pubDate>Mon, 17 Dec 2007 14:36:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61319</guid>
		<description>Ferry, ik begon enthousiast je artikel te lezen, maar bleek een beetje op het verkeerde been te zijn gezet door je openingszin. Ik verwachte daarna een beschouwing over de toegankelijkheid van overheidswebsites, maar ik kreeg een betoog over webrichtlijnen (dat laatste komt natuurlijk wel overeen met de titel). 

Wat de webrichtlijnen betreft ben ik het wel met je artikel eens. Nuttig het weer eens op een rijtje te zien. Maar wat vind jij nu over de overheidswebsites? En als ze aan de standaarden voldoen, zijn het daarmee dan ook goede/zinvolle/toegankelijke sites? 

Mijn persoonlijke beleving is dat overheden als ze zich aan de richtlijnen houden (als ze dat al lukt) tevreden achter over leunen. Maar of de website vervolgens voldoet aan de wensen van de bezoekers (die uiteindelijk voor de site betalen) is vers twee. Kijk naar de jaarlijkse prijsuitrijking van burger@overheid. Volgens de checklist scoren sites hoog, die voor mij als gebruiker hooguit matig scoren. Kortom, richtlijnen zijn mooi, maar het is toch uiteindelijk de gebruiker (= klant?) die bepaalt of een site toegankelijk is en voldoet aan de verwachtingen.</description>
		<content:encoded><![CDATA[<p>Ferry, ik begon enthousiast je artikel te lezen, maar bleek een beetje op het verkeerde been te zijn gezet door je openingszin. Ik verwachte daarna een beschouwing over de toegankelijkheid van overheidswebsites, maar ik kreeg een betoog over webrichtlijnen (dat laatste komt natuurlijk wel overeen met de titel). </p>
<p>Wat de webrichtlijnen betreft ben ik het wel met je artikel eens. Nuttig het weer eens op een rijtje te zien. Maar wat vind jij nu over de overheidswebsites? En als ze aan de standaarden voldoen, zijn het daarmee dan ook goede/zinvolle/toegankelijke sites? </p>
<p>Mijn persoonlijke beleving is dat overheden als ze zich aan de richtlijnen houden (als ze dat al lukt) tevreden achter over leunen. Maar of de website vervolgens voldoet aan de wensen van de bezoekers (die uiteindelijk voor de site betalen) is vers twee. Kijk naar de jaarlijkse prijsuitrijking van burger@overheid. Volgens de checklist scoren sites hoog, die voor mij als gebruiker hooguit matig scoren. Kortom, richtlijnen zijn mooi, maar het is toch uiteindelijk de gebruiker (= klant?) die bepaalt of een site toegankelijk is en voldoet aan de verwachtingen.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Walter Bakker</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61277</link>
		<dc:creator>Walter Bakker</dc:creator>
		<pubDate>Fri, 14 Dec 2007 12:29:55 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61277</guid>
		<description>De Webrichtlijnen zijn een mooi initiatief, maar strikt toepassen blijkt in de praktijk ingewikkelde en zelfs rare  situaties op te leveren. Een site met "platte" content dat uit een CMS komt is nog wel makkelijk aan te passen, maar het wordt anders als om de complexere webapplicaties gaat. 
Zo kan het erg ingewikkeld worden om alternatieven te vinden voor schermen met veel interactieve velden die opgebouwd worden met "optionele technolgie" als CSS en/of Javascript. Verwijzen naar een ander, geschikter communicatiekanaal wordt daarbij niet als alternatief toegestaan, terwijl dat een heel reële optie kan zijn (misschien is men b.v. wel sneller geholpen met terugbellen of chat?). 
Een ander probleem daarbij is dat de tooling binnen je ontwikkelplatform gewoon (nog) niet geschikt kan zijn om de Webrichtlijnen in te voeren in de gestandaardiseerde  ontwikkelmethode o.b.v. componenten. 
Verder spreken de Webrichtlijnen soms de usability tegen: links naar downloadbare bestanden mogen volgens de Webrichtlijnen niet worden geopend in nieuwe vensters. Maar sluit je een op de "juiste" manier geopend PDF-bestand af, dan is al snel de hele site afgesloten.

Kortom: een goed initiatief dus, maar een zeer strikte naleving van de huidige Webrichtlijnen mag nooit het doel op zich worden. Daarom is het wat mij betreft al weer tijd voor een revisie vanuit de praktische toepasbaarheid.</description>
		<content:encoded><![CDATA[<p>De Webrichtlijnen zijn een mooi initiatief, maar strikt toepassen blijkt in de praktijk ingewikkelde en zelfs rare  situaties op te leveren. Een site met &#8220;platte&#8221; content dat uit een CMS komt is nog wel makkelijk aan te passen, maar het wordt anders als om de complexere webapplicaties gaat.<br />
Zo kan het erg ingewikkeld worden om alternatieven te vinden voor schermen met veel interactieve velden die opgebouwd worden met &#8220;optionele technolgie&#8221; als CSS en/of Javascript. Verwijzen naar een ander, geschikter communicatiekanaal wordt daarbij niet als alternatief toegestaan, terwijl dat een heel reële optie kan zijn (misschien is men b.v. wel sneller geholpen met terugbellen of chat?).<br />
Een ander probleem daarbij is dat de tooling binnen je ontwikkelplatform gewoon (nog) niet geschikt kan zijn om de Webrichtlijnen in te voeren in de gestandaardiseerde  ontwikkelmethode o.b.v. componenten.<br />
Verder spreken de Webrichtlijnen soms de usability tegen: links naar downloadbare bestanden mogen volgens de Webrichtlijnen niet worden geopend in nieuwe vensters. Maar sluit je een op de &#8220;juiste&#8221; manier geopend PDF-bestand af, dan is al snel de hele site afgesloten.</p>
<p>Kortom: een goed initiatief dus, maar een zeer strikte naleving van de huidige Webrichtlijnen mag nooit het doel op zich worden. Daarom is het wat mij betreft al weer tijd voor een revisie vanuit de praktische toepasbaarheid.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Gerrit Berkouwer</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61270</link>
		<dc:creator>Gerrit Berkouwer</dc:creator>
		<pubDate>Fri, 14 Dec 2007 09:00:05 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61270</guid>
		<description>Ferry, goed artikel. Het artikel kan nog 2x zo lang zijn wat mij betreft. Bijvoorbeeld het feit dat de snelheid van je website toeneemt door de betere en kleinere code (waarmee het dataverkeer afneemt: kostenvoordeel?) moet er zeker bij. Vooral aan de opdrachtgevers/eigenaars-kant van een website zijn er nog vele meer 'verborgen' voordelen: effectievere aansturing van opdrachtnemers, effectiever beheer aan de achterkant van de website, meer flexibiliteit in doorontwikkeling, goedkoper in doorontwikkeling, gerichter in doorontwikkeling, sneller in doorontwikkeling: allemaal aspecten die een logisch gevolg zijn van een aanpak conform webrichtlijnen in een webproject. Bij VWS hebben we daar inderdaad al een aantal jaren profijt van en dat waren absoluut geen suffe tijden kan ik je zeggen :-).</description>
		<content:encoded><![CDATA[<p>Ferry, goed artikel. Het artikel kan nog 2x zo lang zijn wat mij betreft. Bijvoorbeeld het feit dat de snelheid van je website toeneemt door de betere en kleinere code (waarmee het dataverkeer afneemt: kostenvoordeel?) moet er zeker bij. Vooral aan de opdrachtgevers/eigenaars-kant van een website zijn er nog vele meer &#8216;verborgen&#8217; voordelen: effectievere aansturing van opdrachtnemers, effectiever beheer aan de achterkant van de website, meer flexibiliteit in doorontwikkeling, goedkoper in doorontwikkeling, gerichter in doorontwikkeling, sneller in doorontwikkeling: allemaal aspecten die een logisch gevolg zijn van een aanpak conform webrichtlijnen in een webproject. Bij VWS hebben we daar inderdaad al een aantal jaren profijt van en dat waren absoluut geen suffe tijden kan ik je zeggen :-).</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Alper Çugun</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61258</link>
		<dc:creator>Alper Çugun</dc:creator>
		<pubDate>Thu, 13 Dec 2007 21:48:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61258</guid>
		<description>Leuk artikel Ferry! Het is een getuigenis voor het harde werk van de standaarden-community en sommige browser-bouwers dat webstandaarden dat zijn geworden: standaard.

In dat kader is &lt;a href="http://people.opera.com/howcome/2007/msft/" rel="nofollow"&gt;deze open brief&lt;/a&gt; van Håkon de laatste stap. We hebben gehoord dat IE8 misschien komt, nu is het voor Microsoft doorpakken of oprotten.</description>
		<content:encoded><![CDATA[<p>Leuk artikel Ferry! Het is een getuigenis voor het harde werk van de standaarden-community en sommige browser-bouwers dat webstandaarden dat zijn geworden: standaard.</p>
<p>In dat kader is <a href="http://people.opera.com/howcome/2007/msft/" rel="nofollow">deze open brief</a> van Håkon de laatste stap. We hebben gehoord dat IE8 misschien komt, nu is het voor Microsoft doorpakken of oprotten.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Door: Renata Verloop</title>
		<link>http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61243</link>
		<dc:creator>Renata Verloop</dc:creator>
		<pubDate>Thu, 13 Dec 2007 08:44:29 +0000</pubDate>
		<guid isPermaLink="false">http://www.frankwatching.com/archive/2007/12/13/webrichtlijnen-suf-of-sexy/#comment-61243</guid>
		<description>Hallo Ferry, bedankt voor je uitstekende artikel! Ik ben een warm pleitbezorger van webrichtlijnen, maar kom in de praktijk ontzettend veel onbegrip en onkunde tegen bij zowel opdrachtgevers als opdrachtnemers. Er is dus nog heel veel missiewerk nodig en dit artikel draagt daar zeker aan bij. Wel moeten we oppassen dat het voldoen aan de webrichtlijnen niet tot ultiem doel wordt verheven. Het blijft belangrijk erop te hameren dat het doel is een toegankelijke en duurzame website te realiseren.

Voor iedereen die meer wil weten over de achtergrond van de webrichtlijnen is het artikel 'De kroniek van de webrichtlijnen' van Raph de Rooij op Naarvoren.nl een aanrader:
http://www.naarvoren.nl/artikel/webrichtlijnen/</description>
		<content:encoded><![CDATA[<p>Hallo Ferry, bedankt voor je uitstekende artikel! Ik ben een warm pleitbezorger van webrichtlijnen, maar kom in de praktijk ontzettend veel onbegrip en onkunde tegen bij zowel opdrachtgevers als opdrachtnemers. Er is dus nog heel veel missiewerk nodig en dit artikel draagt daar zeker aan bij. Wel moeten we oppassen dat het voldoen aan de webrichtlijnen niet tot ultiem doel wordt verheven. Het blijft belangrijk erop te hameren dat het doel is een toegankelijke en duurzame website te realiseren.</p>
<p>Voor iedereen die meer wil weten over de achtergrond van de webrichtlijnen is het artikel &#8216;De kroniek van de webrichtlijnen&#8217; van Raph de Rooij op Naarvoren.nl een aanrader:<br />
<a href="http://www.naarvoren.nl/artikel/webrichtlijnen/" rel="nofollow">http://www.naarvoren.nl/artikel/webrichtlijnen/</a></p>
]]></content:encoded>
	</item>
</channel>
</rss>
