Ik heb het idee dat enerzijds de noodzaak ontbreekt, omdat de wetgeving rondom de webrichtlijnen niet-structureel en onvoldoende is gewaarborgd. Je kunt er blijkbaar goed mee wegkomen de eis aan je laars te lappen als overheidsinstantie, want per 1 december 2010 hadden al deze sites al meoten voldoen aan de Webrichtlijnen. Anderzijds is er simpelweg onvoldoende intrinsieke motivatie bij opdrachtgevers en -nemers om aan de slag te gaan met deze richtlijnen. Men is al bijzonder trots als men voldoet aan Prio 1 van WCAG1, wat feitelijk niets meer is dan een eenvoudige kwaliteitscontrole van je eigen werkzaamheden (met uitzondering van de richtlijnen voor video, waarover meer bij ‘Pragmatisme ontbreekt’). Het zou ieders en dus ook jouw eigen standaard moeten zijn!

Alles of niets

Liever alle Nederlandse websites 80% toegankelijk, dan 30 sites 100%

In gesprekken met opdrachtgevers, partners en mijn front-end broeders is de “Alles of niets”-aanpak het meestgehoorde pijnpunt. De webrichtlijnen bestaan uit 125 richtlijnen, die zijn samengevat in 96 ijkpunten. Wanneer je een van de richtlijnen niet haalt krijg je geen logo en ga je niet door voor de koelkast. Terwijl het in sommige gevallen simpelweg niet rendabel te maken is om te voldoen aan álle richtlijnen, en me dunkt dat geld een rol mág spelen in de aanloop naar een nieuwe website.

Het jammerlijke aan deze situatie is dat veel partijen daarom in een vroeg stadium van het project toegankelijkheid laten vallen, wat voor veel ontwikkelaars een vrijbrief is om uberhaupt geen rekening meer te houden met toegankelijkheid. Ik heb liever alle sites in Nederland voor 80% toegankelijk, dan de huidige 30 sites die voldoen aan 100% van de webrichtlijnen. Begrijp me goed, ik geloof in de webrichtlijnen, maar een campagne om van 80% naar 100% te komen is gemakkelijker dan van 0% tot 100% te komen. De 80/20 regel is immers absoluut van toepassing op de webrichtlijnen.

Pragmatisme ontbreekt

Dat is eigenlijk precies waar de webrichtlijnen de plank mis slaan. Door zo strict om te gaan met de richtlijnen raken ontwikkelaars, site-eigenaren en andere betrokkenen gedemotiveerd, en krijgen de webrichtlijnen, het Waarmerk Drempelvrij-initiatief en toegankelijkheid in algemene zin een slecht imago. Ten onrechte, want toegankelijk heeft meer vóór- dan nadelen, en wanneer je pragmatisch om kunt gaan met toegankelijkheid – doordat je bijvoorbeeld niet voor de overheid ontwikkelt, maar simpelweg een verstandige klant tegenover je hebt, vervallen de nadelen zelfs volledig. Het zou dan ook prettiger werken als er een soort van aanmoedigingsprijs te verdienen is, zoals bij Drempelvrij (gelijk aan Prio 1 van WCAG 1) wel het geval is. Daar heb je bij 12 van de 16 ijkpunten ook recht op een logo, weliswaar in oranje met daaronder “12/16″, maar het geeft in ieder geval aan dat je goed op weg bent.

Neem bijvoorbeeld het toegankelijk maken van video. Deze richtlijn is opgenomen in prio 1 van de internationale WCAG 1 standaard, en daarmee onderdeel van het Waarmerk Drempelvrij. Het is daarmee op het laagste niveau van toegankelijkheid een verplichting, die echter behoorlijk veel voeten in de aarde heeft. Video moet zijn voorzien van een losse audiodescriptie en natuurlijk ondertiteling. Hoewel het niet complex is video te voorzien van ondertiteling vereist het wel specifieke software en enige kennis. Kennis die niet op iedere webredactie zomaar voorhanden is. Omdat veel bedrijven dit niet binnen de eigen muren kunnen realiseren, wordt het vaak uitbesteed. De bedrijven die deze diensten leveren weten echter behoorlijk goed wat ze hier voor moeten rekenen, dus zeker voor kleinere organisaties hebben dit soort eisen veel impact.

Beter zou zijn om op basis van statistieken te kijken welke pagina’s veel worden bezocht, hoe deze informatie zich verhoudt tot de pagina’s die je graag veel bezocht zou zien en je in eerste instantie te concentreren op deze content (er vanuit gaande dat je algemene templates al correct zijn opgebouwd natuurlijk). Het principe van laaghangend fruit zou bijzonder goed zijn voor toegankelijkheid, en kan mensen eenvoudig over de drempel helpen. Toegankelijkheid wordt drempelvrij, zeg maar (sorry).

Geen meerwaarde

Bovendien wordt voornamelijk gestuurd op de verplichting (al was het maar louter gevoelsmatig), en absoluut niet op de meerwaarde van toegankelijk. De business value zogezegd. What’s in it for you? Ik stel onze klanten, en mijn projectmanagers altijd met veel plezier dezelfde twee vragen. Vraag 1; zijn er wensen of eisen met betrekking tot toegankelijkheid? Doorgaans is het antwoord daarop nee. Vraag 2 is dan; wil je gevonden worden in zoekmachines? Dat wordt dan meestal afgedaan als retorische vraag, hoewel het in verregaande mate dezelfde vraag is. Met blijkbaar een geheel andere perceptie. Het ene gaat over regeltjes die verplicht zijn, de andere gaat ook over regeltjes maar betekent extra euro’s of in ieder geval minder kosten op de lange termijn. Dat is een interessant gegeven. Waarom zijn mensen wel geïnteresseerd in meer bezoekers, maar niet geïnteresseerd in meer bezoekers? Toegankelijkheid en zoekmachinevriendelijkheid liggen immers dicht bij elkaar. Het gaat beide over de vindbaarheid van informatie, over structuur van de informatie en de gelaagdheid van je website. Je zou kunnen zeggen dat als je rekening houdt met zoekmachines je voor een groot deel al voldoet aan de eisen voor toegankelijkheid.

Root management

In veel van de projecten waar ik aan heb meegewerkt is zowel toegankelijkheid en zoekmachine-optimalisatie een tussenstation wat door budgetten, deadlines en stuurgroepen vaak voorbij wordt gedenderd om op het wensenlijstje te belanden voor ‘later als de website groot is’. Ik ben door Microsoft ingehuurd om dit soort problemen voor hen op te pakken en in ieder project hoog op de agenda te houden. De eerlijkheid gebiedt te zeggen dat dat zeker niet altijd eenvoudig gaat, maar met de juiste argumenten hebben we grote stappen mogen maken.

Wat ik hierdoor ook heb ontdekt is dat het probleem vaak in generieke problemen schuilt, bijvoorbeeld een backend-systeem dat incorrecte templates genereert, of een text editor die verouderde code uitschrijft ondanks juiste invoer. Bij Microsoft speelt ook mee dat veel sites dezelfde ‘verouderde’ templates gebruiken waarmee de toestand van alle sites soms slechter lijkt dan het feitelijk is. Ik probeer dus zoveel mogelijk generieke problemen aan te pakken om met minimale inzet maximaal effect te bereiken. Deze generieke problemen komen niet alleen bij Microsoft voor, maar ongetwijfeld ook in jouw projecten. Een CMS met een editor die niet conform webrichtlijnen output kan genereren, of veelgebruikte Javascript-plugins die aan de haal gaan met de code van tientallen sites die jij of jullie voor klanten ontwikkelen waardoor de gelaagdheid van je pagina verloren gaat. Door dergelijke problematiek bij de wortels aan te pakken kun je met enkele aanpassingen een veel grotere kwaliteit waarborgen in al je projecten. En daarmee kun je impact hebben op bezoekersaantallen, campagnesuccessen en uiteraard ook het ontsluiten en delen van jouw boodschap. Sounds like good business, right?

Toekomstmuziek

Vorige week, op 23 juni is versie 2 van de webrichtlijnen aangenomen als officiële overheidsstandaard. Wat betekent dit? De nieuwe versie is in basis al een stuk pragmatischer, en afgestemd op moderne technieken zoals HTML5 en CSS3. Webrichtlijnen 2 is gebaseerd op de internationaal vastgestelde WCAG2 standaard, welke integraal is opgenomen in de nieuwe webrichtlijnen. WCAG2 is samengesteld op basis van 4 principes: Waarneembaar, Bedienbaar, Begrijpelijk en Robuust. Webrichtlijnen 2 voegt hier nog één extra principe aan toe; Universeel. In deze 5 principes worden beter dan in versie 1 handvatten geboden om je site toegankelijk te maken, en zijn sommige ijkpunten weliswaar minder open voor interpretatie, maar leiden er wel meer wegen naar Rome bij het vinden van een oplossing.

Webrichtlijnen 2 is de nieuwe standaard, maar onduidelijk is nog hoe dit zich gaat verhouden tot wetgeving. Vermoedelijk zal ‘Webrichtlijnen 2, level AA’ het verplichte niveau zijn voor overheidsinstaties, waarbij er nog een overgangsfase van enkele jaren zal zijn van WR1 naar WR2. Waar ik vooral benieuwd naar ben is of het ‘Alles of niets’-principe gehandhaafd blijft, of dat er ruimte is voor meer aanmoediging op weg naar een toegankelijke site. Ik ben er van overtuigd dat wanneer het logo van de webrichtlijnen echt een kwaliteitsaanduiding is, met verschillende gradaties en aanmoedigingsvarianten, waarbij je kunt aangeven hoe ver jij als organisatie bent met toegankelijkheid dat voor veel van deze partijen makkelijker is te handhaven dan de huidige opzet. Ook wordt men niet langer teleurgesteld wanneer er veel tijd en geld is geinvesteerd in de toegankelijkheid van een website waarbij uiteindelijk enkele onderdelen niet voldoen en daarmee het logo niet wordt gehaald. Natuurlijk is er dan nog steeds een toegankelijkere site dan gemiddeld opgeleverd, maar gevoelsmatig is het werk voor niets geweest.

Die consequente deceptie zorgt voor een negatief imago van de webrichtlijnen en het waarmerk Drempelvrij, wat enorm afleidt van de kracht van deze principes. Tijd voor een ommezwaai, geliefd Den Haag. Het moment is daar voor pragmatisme dat hoort bij deze tijd, voor een helpende hand in plaats van een wijzend vingertje. Tijd voor een toegankelijker internet.

Als projectmanager ben ik toch niet verantwoordelijk voor de Toegankelijkheid van een website, vraag ik mij weleens af. Het is wel mijn verantwoordelijkheid dat aan alle aspecten van project ‘Nieuwe Website’ gedacht wordt. Bijvoorbeeld:

• integratie met andere campagnes,
• ervoor zorgen dat de website gemeten wordt op bezoekers en behaalde doelstellingen,
• monitoren dat de doelstellingen niet uit het oog worden verloren tijdens de bouw van de website,
• of de banaan (is de belangrijkste CTA steeds in beeld, ) aanwezig is,
• of de website SEO (Search Engine Optimalisatie) vriendelijk gebouwd is,
• of iedereen zijn input heeft kunnen leveren voor de website én
• niet te vergeten is de website toegankelijk gebouwd.

Toegankelijke websites bouwen, is een website zo bouwen dat iedereen de website kan gebruiken op de manier waarop en waarvoor hij bedoeld is.
Helaas wordt dit laatste punt juist wel vergeten of half half gedaan. Onze leveranciers zijn nog niet gewend aan toegankelijk bouwen en denken er meestal niet aan. Halverwege het project is het eigenlijk al te laat om ‘toegankelijkheid’ er in te bouwen. Mijn opdrachtgevers willen er vooral niet meer tijd of geld aan uit geven. (stel je voor…) En ik ben dan niet duidelijk genoeg geweest… Of snap er nog te weinig van om het te kunnen checken. En wat gebeurt er als de druk op de ketel staat? Dan doen we een ‘beetje toegankelijk’ en laten we eigenlijk het liefst zoveel mogelijk weg. Dan ga ik er vanuit (altijd gevaarlijk) dat als een leverancier zegt dat de site toegankelijk is gebouwd dat het ook zo is. Totdat de website live staat en onze Accessibility Evangelist naar mij toe komt en vraagt of hij mijn website als worst case practice mag gebruiken (arghhh…).

Mmm. Zonde. Want een toegankelijk gebouwde site is niet alleen belangrijk voor de 4 miljoen mensen met een beperking waardoor het internet voor hen niet zo vanzelfsprekend te gebruiken is als voor jou en mij. Maar des te meer om de doelstellingen te behalen.
Want wie wil er nou geen site die:

• goed vindbaar is in zoekmachines,
• prettig in gebruik is,
• makkelijk aan te passen is en
• snel laadt?
• Oh ja en dus potentieel voor 4 miljoen meer mensen bereikbaar is (kleurenblinden, dyslectici, blinden/slechtzienden, lichamelijk gehandicapten, doven/slechthorenden, laaggeletterden)

Wie zegt daar nou nee tegen?

Gelukkig heeft diezelfde Accessibility Evangelist een slimme website gemaakt: www.kleedjesiteuit.nl waarop ik als projectmanager heel makkelijk kan controleren hoe toegankelijk mijn website is gebouwd. Dat maakt het voor mij een stuk makkelijk om ook toegankelijk mee te nemen in project ‘Nieuwe Website’.

Wil je meer weten over wat toegankelijk bouwen is? Hoe je toegankelijk kunt bouwen? Waarom je het zou doen? Hoe je dit dan verwerkt in je projectmanagement? Kijk dan op www.microsoft.nl/toegankelijk

Jitske Lochtenberg
Job: Accessibility Evangelist en Marketing Project manager bij Microsoft
Email: v-jiloch@microsoft.com
Twitter: twitske

De video staat inmiddels online van die sessie, en hoewel het nog niet ondertiteld is (en dus eigenlijk niet echt heel toegankelijk is vooralsnog) wilde ik de video toch alvast met jullie delen. Ik ben benieuwd naar reacties, vragen en/of opmerkingen!

Contentbeheerders zijn ook maar gewoon mensen

Contentbeheerders zijn doorgaans de meest onderschatte doelgroep van front-end developers. De mensen achter de schermen, die dag in, dag uit bezig zijn met het aanvullen, verdiepen en optimaliseren van jouw telg maken of kraken het succes ervan. Als deze mensen niet goed worden gefaciliteerd, en als hun acties niet netjes worden opgevangen middels een solide front-end, kunnen al je andere doelgroepen wel fluiten naar de informatie die ze zoeken.

Als front-end developer kan ik tevens bevestigen dat contentbeheerders op wonderlijke wijze vaak precies dátgene proberen te doen waar je het allemaal niet voor hebt gemaakt. Noem het een collectieve gave. Dat betekent echter wel dat je als front-end developer een waterdichte manier van werken moet hebben, en dat is zo ongeveer de enige echte complexiteit in ons vak. Gratis tip: Praat met ze. Het zijn doorgaans hele normale mensen. Spendeer een uur of 2 aan hun bureau en kijk ze op de vingers. Ervaar hun werk, zie wat ze doen en wat er gebeurt als zij content kloppen. Het zal je verbazen hoeveel profijt je hebt van zo’n, tsja…noem het een gebruikerstest. Zo ontdekte ik dat bij de Kamer van Koophandel regelmatig de behoefte bestond om een <ul> te laten volgen op een inleidende <p>. Als je echter alle <p>’s een standaard marge van 20px aan de onderzijde hebt gegeven, dan lijkt de <ul> niet langer bij de <p> te horen. Dat zijn dus visuele fouten waar zelden op wordt geanticipeerd in een ontwerp, en met al te generieke code niet kunnen worden opgevangen. In dit soort gevallen kun je de editor aan de serverkant voorzien van een aantal regular expressions waarmee je deze situaties kunt afvangen.

Ontwerpers houden van unicorns

Dat een artikel in het ontwerp exact even hoog is als het blokje ernaast is hartstikke leuk, maar zo’n ontwerper kun je het beste middels een fikse oplawaai op het achterhoofd uit zijn of haar droom helpen. In de praktijk is dat namelijk een unicum, en ook al spreek je met de klant nog zo goed af dat het echt maar 5 items van maximaal 30 karakters mogen zijn; er komt een dag dat het misgaat. Jouw verantwoordelijkheid, jouw schuld. Scenario 1: In de psd vind je 3 mooi vormgegeven lijstjes op de homepage. Ieder lijstje heeft 5 items, en ieder item is slechts een paar woorden. Lijntje aan de onderkant, icoontje aan de linkerzijde, lekkere witruimte met een line-height van 22 pixels. Alsof het er voor gemaakt is! Vervolgens vult een contentbeheerder de boel in naar behoren, maar wacht; er is een extra item dat iets langer is dan wat we hebben afgesproken. Resultaat:

Ergo, vang dit soort zaken af. Het is bedroevend hoe vaak je dit kunt tegenkomen in sites die al maandenlang live staan. Het is een kleine moeite voor de ontwikkelaar, lijkt me. Regels zijn er om te overtreden; zo ook de afspraken die een beheerder maakt met jou over jouw bloed, zweet en tranen. Het is een kleine moeite om lijsten, koptitels en links klaar te maken voor content welke over twee regels zal lopen, of langer is dan afgesproken.

Denk na over verschillende resoluties en touch

Probeer bij het schrijven van je stylesheet na te denken over het type gebruik dat je kunt verwachten. Praat met je interactie-ontwerper over de te verwachten gebruikersscenario’s. Als de verwachting is dat gebruikers veelal de site zullen benaderen via mobiele telefoons is het goed om hier in je interactie rekening mee te houden. Toevallig kwam ik dit voorbeeld enkele weken geleden helaas tegen in het werk van een collega: absoluut een gemiste kans.

Op zich is er doorgaans weinig mis met het bovenste, rode linkje. Gebruikers bewegen met de cursor naar het element, en zodra het pijltje verandert in een handje wordt er geklikt. Bij het gebruik van een touch-apparaat is dergelijke feedback echter niet aan de orde, en is de verwachting bovendien dat het gehele blauwe vlak klikbaar is, omdat je vinger nu eenmaal hoe dan ook te groot is om louter tekst te raken. Het is een kleine moeite om je code direct uit te breiden met het gewenste display: block; en op die manier altijd je links het maximale formaat te geven zoals in de groene link in het voorbeeld.

Wat betreft de verschillende resoluties: webheld Luke Wroblewski stelt dat het goed is om een website te beredeneren alsof je het voor een mobiele telefoon ontwikkelt. Hier geeft hiervoor een aantal redenen:

• Het dwingt je de site te beperken tot de informatie die er echt toe doet, of in ieder geval vanuit dat perspectief de site op te bouwen.
• Mobiel heeft de toekomst; groeit veel sneller dan het gebruik van PC’s ooit heeft gedaan, dus je kunt er maar beter klaar voor zijn.
• Laadtijden doen er opeens weer toe. Misschien toch aan de sprites of slimmer omgaan met je save for web-gedrag?

Ik test al mijn sites door op mijn iPad en een smartphone. Niet omdat ze specifiek voor deze platformen zijn ontwikkelt, maar omdat het een goede controle is voor de kwaliteit van wat ik oplever.

Meestvoorkomende open deur: het scheiden van content van opmaak en gedrag.

Rustig, rustig, ik weet ook heus wel dat ruim 99% Javascript gewoon heeft aanstaan. Je hoeft zo’n variant ook niet apart te ontwerpen, maar door het wel te berederen dwing je jezelf om goed na te denken over de gelaagdheid van je product, en voorkom je dat de klant van jouw klant een vreemde kennismaking heeft met het product en je klant omzet misloopt door jouw laksheid.

Maar eigenlijk is dat allemaal bijzaak ten opzichte van de essentie; zorg dat alle informatie altijd voor iedereen vindbaar is en je wint automatisch terrein op zaken als toegankelijkheid, vindbaarheid en onderhoudbaarheid van je code. Dát vormt de kwaliteit van wat je oplevert, en dát maakt het verschil tussen ‘veel geld’ en ‘duur’

* Tijdens mijn studie betichtte mijn twee goede vrienden, optimalisatie-guru Roel van der Ven en datavisualisatie-orakel Jasper Schelling mij van code-purisme en komma-gechicaneer. Zo kwam mijn code-fetisjisme aan het licht, en schreven wij in ons laatste studiejaar gedrieënlijk de enorm ondergewaardeerde, helaas nimmer uitgebrachte instant nummer 1-hit ‘schone code’. Op jammerlijke wijze is de tekst ervan nooit bewaard gebleven – of is nooit af geschreven, dat blijkt niet langer uit de annalen – maar mijn passie en liefde voor kwaliteit en efficiëntie van code is altijd gebleven.

Laat ik vooraf het volgende duidelijk maken; ik kan niet wachten tot de :nth-of-type pseudo-class door alle browsers wordt ondersteund, want deze wonder-selector bespaart ons als front-end developers flink wat tijd, en flirt er ondertussen lustig op los met mijn codepuristische hersenkwab. Toch is dat – ook semantisch gezien – niet de meest nette oplossing, omdat het suggereert dat deze elementen anders zijn dan de overige elementen, terwijl het probleem een niveau hoger ligt. Dus moeten we het ook daar oplossen.

Een voorbeeld

Stel: we willen 3 gelijke blokken van 310 x 310 pixels op een pagina met een breedte van 960 pixels uitvullen tot de beide randen met steeds netjes 15 pixels marge er tussen. Drie elementen is 930 pixels plus 3 x 15 pixels marge aan de rec… Inderdaad. Eenmaal marge teveel.

Normaliter geef je dit derde element een class-name die de marge aan de rechterzijde verwijderd voor alleen dit element. En als je de luxe van een CMS hebt geef je de back-end developer de opdracht om íeder derde item deze class mee te geven, of je kunt automatisch classnames toekennen middels Javascript. Of desnoods via een stagiair die het handmatig toevoegt aan de betreffende elementen. En ik heb de afgelopen jaren eigenlijk alle methodieken wel geprobeerd (met uitzondering van het inzetten van een stagiair natuurlijk!…), maar vond het vrijwel altijd simpelweg de verkeerde beredenering. Deze elementen zijn helemaal geen zonderlingen, dus moeten we ze ook niet als zodanig behandelen.

In plaats daarvan plaats ik de elementen in een container (in dit geval #blokkendoos) die de breedte van het parent-element + eenmaal de marge is. Dit element plaats je met position: relative; 15 pixels naar links, zodat er visueel niets veranderd en de elementen netjes uitlijnen.

Wat ik prettig vind, is dat de blokken zowel visueel als sematisch gelijk blijven aan elkaar. Je zou dit kunnen lezen en denken: waarom creëer je een nieuw element om items heen om een paar classjes te besparen? Het voordeel is dat dit extra element alleen maar bevestigd dat deze elementen bij elkaar passen. De allermooiste oplossing is dan ook om – indien dit semantisch klopt – de elementen als <li>‘s in een <ul> of <ol> te plaatsen en deze als blokkendoos te gebruiken.

Wat vind jij?

Ik ben erg benieuwd naar jouw mening over deze methode, dus deel je visie en ideeën door een reactie te plaatsen!

Toegankelijk bouwen is geen kers op de taart, maar het belangrijkste ingrediënt voor een goed beslag.

Het is buitengewoon jammer dat het zo onduidelijk is, voor wie we toegankelijk bouwen. Het antwoord is namelijk aanzienlijk eenvoudiger dan de gemiddelde reactie doet vermoeden: iedereen. Welke gebruiker vindt het tenslotte prettig om met zijn ogen te moeten knijpen om teksten met een laag contrast te lezen? Welke gebruiker wordt gelukkig van nóg een keer het formulier invullen omdat hij één veldje was vergeten, en de website zijn gegevens niet heeft onthouden? Welke gebruiker vindt het fijn om op een smartphone steeds in- en uit te moeten zoomen terwijl een mobiele stylesheet een fluitje van een cent is?

Jij mag niet mee doen.

Ik heb mijzelf in april 2010 een iPad cadeau gedaan, en iedere ochtend bij het ontwaken tik ik met een slaaplamme arm mijn wekker uit, om vervolgens op de tast naar mijn iPad te graaien. Met geknepen ogen lees ik mijn RSS-feeds, check ik mijn email en volg ik mijn vrienden en helden via Twitter en Facebook. Noem het een ochtendritueel, zo je wilt.

Het komt helaas vaker voor dan me lief is, dat ik veelbelovende links volg naar gapend witte gaten op websites of word beschuldigd van mijn gebrek aan Flash, om vervolgens in lichte depressie te raken. Mag ik als mobiele gebruiker wéér niet meegenieten van een video. Apple is misschien eigenwijs in het blokkeren van Flash (hoewel ik de beredenering overigens prima en acceptabel vind, maar dat terzijde), maar als de sitebeheerder gewoon op een toegankelijke manier video had aangeboden had ik probleemloos – desnoods met een of twee extra handelingen – kunnen meegenieten van de video.

Voor wie maak jij je site?

In een brainstorm met het Accessibility team probeerden we te definieren wat een toegankelijk internet betekent. Collega Jitske Lochtenberg omschreef het uitermate treffend: Digitale toegankelijkheid zijn websites, software en hardware waar iedereen gebruik van kan maken op de manier waarop het bedoelt is. Daar komen de woorden blind, doof, beperkt, gehandicapt of andere vooroordelen dus helemaal niet in voor. En het heeft dus niets met de voors- en tegens van ontwikkelaars te maken. Je levert dat weloverwogen ontwerp, die logisch gestructureerde code, het uitgedachte ontwerpsausje en de eenvoudige en overzichtelijke content niet alleen ‘voor een handjevol gehandicapten en bejaarden’, maar je levert een gelijkwaardige beleving op maat, voor iedere bezoeker – ongeacht het gebruikersscenario of de beperkingen van de gebruiker.

Ik kon het dan ook niet laten om onderstaand screenshot te nemen; het is een voorbeeld dat in zoveel opzichten model staat voor de stigma’s rondom toegankelijk bouwen, dat het bijna grappig is. Met de nadruk op bíjna.

We zien hier de eerste paar elementen na de <body>, waarbij twee elementen – namelijk twee koptitels – zijn toegevoegd aan de broncode, zonder dat deze elementen content bevatten noch zichtbaar zijn voor de eindgebruiker. De enige reden dat deze elementen er staan is omdat de webrichtlijnen quickscan anders niet wordt gehaald. Ik heb enkele keren mijn gevoel over deze aanpak getracht te verwoorden, om het vervolgens weer te verwijderen, omdat het geen zin heeft ten koste van de bouwer grappig te zijn. Uiteindelijk heeft iedere bouwer immers zijn of haar manier van werken, maar ik vind het buitengewoon sneu dat hun klanten dit soort code voorgeschoteld krijgen, en denken dat ze een toegankelijke site hebben.Wat dacht de developer toen hij of zij of deze oplossing koos?

Toegankelijk bouwen is geen kers op de taart, maar het belangrijkste ingrediënt voor een goed beslag. Zonder dit ingredient zal de taart nooit smaken. Hoe denk jij hierover?

De meeste websites zijn eenheidsworst van een ander varkentje

“Wij” – de online vakidioten – zijn grotendeels niet meer dan veredelde lijstenmakers. Zo. Dat is eruit. Met een team van 5 tot 7 man werken we soms maanden aan de ontwikkeling van een website. We denken na over een navigatiestructuur, ontwerpen schermpjes, kleuren die schermpjes in, maken het aanpasbaar voor de klant met een-om-het-even-welk content management systeem, en eten taart en drinken champagne omdat het project ten einde is. Terwijl we eigenlijk een blanco canvas aanleveren met een belachelijk mooie lijst en hopen dat de klant een nazaat is van Salvador Dalí. In de praktijk had paint by number misschien de betere oplossing geweest, want nu is dit het resultaat.

Er zijn een aantal cruciale onderdelen die bij onze werkzaamheden chronisch onderbelicht zijn. En dat resulteert in wat ik – wanneer ik weer vloekend en tierend de gangen be-ijsbeer bij mijn begripvolle werkgever – doorgaans omschrijf als 95%-projecten. Ja, de homepage ziet er goed uit. Ja, de klant is blij. Ja, het lijkt op wat de ontwerper maakte in Photoshop. Maar is het af? Nee.

Zou je favoriete boek minder belangrijk voor je worden als de kaft simpelweg zwart zou zijn? Waarschijnlijk niet. Zou je niet meer naar de Albert Heijn gaan omdat er niet langer een logo boven de deur hangt? Waarschijnlijk niet. Waarom? Omdat je dergelijke keuzes maakt op basis van interesse voor de inhoud. Het is misschien een beetje een vervelende mededeling voor alle grote online marketeers, maar uiteindelijk komen bezoekers niet omdat je zo’n geil logo hebt; ze bezoeken de website omdat ze dat ene formulier willen invullen (of misschien wel niet, maar dat maken we er dan maar van om complexiteit te vermijden), of omdat ze meer informatie willen hebben over onderwerp x of y. Dat betekent uiteraard niet dat er minder moet worden geïnvesteerd in ontwerp of technologie, maar wél dat er meer moet worden geïnvesteerd in een juiste balans tussen inhoud en opmaak. Het ontwerpen van je content is net zo belangrijk als het ontwerpen van de kapstok waaraan je het kunt ophangen.

Editorial design

Bij de creatie van een fatsoenlijk tijdschrift wordt evenredig veel tijd besteed aan de opmaak van artikelen als aan de tekstuele inhoud van artikelen. Fotografie wordt een onmisbaar onderdeel van de pagina-opmaak en lettertypes worden gekozen op basis van de inhoud van het artikel. Iedere pagina heeft een eigen uitstraling maar blijft doorgaans wel herkenbaar als onderdeel van dat tijdschrift. Noem het merkbeleving dat de basis vormt, en inhoud dat de boventoon voert. Zet dit af tegen de gemiddelde website, en een groter contrast vind je waarschijnlijk niet. Als er al sprake is van een grid in het ontwerp, is alles ook willens en wetens op dat grid geplaatst, en laten we vooral geen uitzonderingen maken voor de content want dan mag niet van de gridpolitie. De content is afkomstig uit de vorige website (als je mazzel hebt, het kan namelijk ook zijn dat het uit de brochure komt die per direct-mail is verstuurd naar anderhalf miljoen ongeïnteresseerde huishoudens), en de fotografie is door Willem van de postkamer gedaan. In Paint. De meeste websites zijn eenheidsworst van een ander varkentje, waarbij alleen de kleur van het logo het merk verraadt.

Voor alle Zuiderlingen die zojuist ontwaken uit hun winterslaap; Jason Santa Maria is een begenadigd webontwerper en -ontwikkelaar uit Amerika, die de kunst van het content-ontwerpen tot in de puntjes beheerst.

Zelfs in de meest contrasterende ontwerpen ten opzichte van zijn eigen ‘huisstijl’ blijft de site herkenbaar als de zijne. Het logo, het menu, de footer; herkenbaar maar ondergeschikt aan de content. De content dicteert de uitstraling. Ik heb 10 willekeurige blogs van JSM op een rijtje gezet, die volgens mij goed laten zien wat grids in basis, en creativiteit in de uitwerking kan betekenen voor je website.

Soit. Dit is een tijd- en geldrovende manier om je website te onderhouden, en eigenlijk alleen voorbehouden aan kleinere prive-websites. Helemaal mee eens. Ik hoor u denken; “Waarom laat je het dan zien, stuk verdriet?!” Omdat het aangeeft wat er mogelijk is. Omdat het de online vorm van editorial design is, omdat we daar allemaal van kunnen leren. Omdat Jason Santa Maria ons laat zien dat de kracht in de content schuilt, en wij als ontwikkelaars alleen voor de entourage kunnen en mogen zorgen.

Werk aan de winkel

Ik droom ‘s nachts wel eens van een klant die tegenover me zit aan een mooi groot en ruim bureau, dat vol ligt met prachtige ontwerpen. Als ik een ontwerp op pak valt me direct op hoeveel aandacht er is besteed aan de details; hoe goed de lettertypes eigenlijk passen bij de rest van het ontwerp, en hoe de content enerzijds onderscheidend is ten opzichte van de huisstijl en anderzijds toch prachtig aansluit, en heel goed de aandacht op zicht vestigt. God, wat een mooi ontwerp. Ik pak een ander ontwerp op, een willekeurige contentpagina en zelfs híer is tot in de puntjes uitgedacht hoe het goed kan passen. De fotografie is zo goed gekozen, en allemaal van de juiste kwaliteit, het komt lekker professioneel over. En als ik de tekst begin te lezen valt ook op hoe juist de tekst eigenlijk aansluit bij de doelgroep van de website. Helemaal geen vakjargon, geen moeilijke woorden, helemaal niet vanuit de organisatie gedacht maar juist heel duidelijk uitgegaan van de behoeftes van de gebruiker. Ik betrap mezelf op een zucht van verlichting als ik de klant tegenover me hoor mompelen; “Ik ben nog niet helemaal tevreden over de formulieren, ze zijn nog iets te zakelijk terwijl de bezoeker eigenlijk vooral behoefte heeft aan een heldere uitl -”. BEEP, BEEP, BEEP

Veel van de heersende issues in ons vak komen mijn inziens samen in het lijstenmakers-principe. Er word soms zo krom geredeneerd, dat zelfs Johan Cruijff het niet meer recht kan lullen. Ik begrijp dat u als grote multinational niet alle 163.212 pagina’s in uw navigatiestructuur apart wilt laten ontwerpen, en ik snap dat u als eigenaar van een groot internetbureau moeite heeft met het verkopen van nog meer contenttype-ontwerpen. Maar ik denk dat we met met een aantal gedachtes als leidraad voor het volgende project daadwerkelijk een betere online uiting produceren:

• Behoefte bepaalt de markt; niet meer zenden, maar delen en alleen datgene aanbieden dat men vraagt. Lang leve Google Analytics voor het bepalen van de relevantie van de content.
• Ontwerpen op de content; Nooit meer lorum ipsum (noch lorumizzle). De items in lijstjes zijn niet altijd exact 1 regel dus ontwerp het ook niet zo; blijft je ontwerp nog overeind als je ongelijke contentvlakken hebt? En als de klant geen beschikking heeft tot World Press Photo kwaliteitsbeelden, ontwerp daar dan ook niet op.
• Houd rekening met contentbeheerders; even kort door de bocht – contentbeheerders doen over het algemeen precies dát waar je als front-end developer bij voorbaat geen rekening mee hebt gehouden. Praat dus met die mensen, ga naast ze zitten als ze aan het werk zijn en constateer de problemen voordat de site live gaat, en niet pas 3 maanden na oplevering.
• Gebruik grids, maar laat het niet je denken beinvloeden; Ja, grids zijn belangrijk voor de rust, het overzicht en het algehele succes van je ontwerp. Maar de pagina’s van Jason Santa Maria laten zien dat je soms ook heel wild kunt afwijken zonder gezichtsverlies. “Step out of the box and think outside the circle.” is hier mooi van toepassing.
• It ain’t over till it’s over; Wat bepaalt het succes van een project? Klanttevredenheid? Klant-van-de-klant-tevredenheid? Trots kunnen zijn op hetgeen je oplevert? En wanneer dan, bij oplevering of 6 maanden later? Bepaal vooraf wat de parels in het project gaan zijn, en wat je jezelf – als individu en/of als team – ten doel stelt. In Agile Scrum is dat mooi af te vangen in de ‘Definition of Done’, maar ook voor andere projecten zou dit document er moeten komen.

Waterval

Er zijn een aantal belangrijke voordelen, met name voor de klant, bij het volgen van een watervalmethodiek. De klant heeft na iedere fase (FO, GO, FED en bouw) een beslissingsmoment, waarbij ook de mening van grotere groepen in overweging kan worden genomen. Met name voor grotere organisaties is hier soms niet aan te ontkomen. Bovendien wordt er meer documentatie opgeleverd, zodat er voor deze achtervang ook meer helderheid komt over wat de uiteindelijke oplevering inhoudt. Als projectmanager heb je dus altijd een stok achter de deur.

Er zijn echter ook behoorlijk wat cruciale nadelen:

• Voortschrijdend inzicht: Gedurende een project kan het zijn dat de gekozen interactiemodellen, of de gebruikte ontwerpen op basis van een interactievorm in de praktijk anders blijken te werken. Dat kan ertoe leiden (of lijden?) dat je terug moet naar de tekentafel, maar dat kan conflicteren met het volgende probleem:
• Planning: Je staat als functioneel ontwerper 32 uur ingepland voor het maken van een FO. Je levert het aan bij de grafisch ontwerper, doet een goede overdracht, en gaat door naar het volgende project. Twee weken later blijkt het FO toch problemen te kennen, of er ontbreken zelfs onderdelen. Jij bent echter al weer bezig aan het volgende project. Lastig, want nu gaat een andere FO’er het oppakken, maar die heeft misschien een andere visie. Jouw concept raakt stukje bij beetje verloren.
• Eigenaarschap: Hoe kun je dat steengoede grafisch ontwerp blijven bewaken met meerdere projecten in het vooruitzicht. De interpretaties van de programmeurs of front-end developers – hoe goed je zo ook hebt gebriefd – leiden tot een andere uitwerking, en bij oplevering voel je je niet meer volledig verbonden met datgene dat live staat. De puntjes op de i missen, het volgende 95%-project is een feit.

Agile Scrum

Agile scrum voorkomt onaangename verrassingen voor de klant.

Agile Scrum is een methodiek die behoorlijk aan bekendheid en populariteit heeft gewonnen de afgelopen 2 á 3 jaar. Het bestaat al wel wat langer, flink wat langer zelfs. De methodiek is er kort gezegd op gericht om met een klein, multidisciplinair (met ook multidisciplinaire leden) team doelgericht, meetbaar efficient te werken, waarbij je het project indeelt in kleine behapbare deelprojecten. Door steeds deze korte ‘sprints’ te trekken, waarbinnen je een aantal van deze deelprojecten oplevert, heb je steeds opnieuw resultaten die je kunt delen met het team en natuurlijk de klant. Alles is gericht op produceren, en dat is ook direct waar je op wordt afgerekend. Deelprojecten krijgen een waarde gebaseerd op de complexiteit ervan. Deze complexiteit wordt benoemd met waardes van 1, 2, 3, 5, 8, 13 en 20 (bijna Fibonacci maar niet helemaal, dat stoort me dan weer mateloos als purist). Iedere sprint, die gemiddeld 2 tot 3 weken duurt, spreek je met elkaar een doel af; “30 punten binnen deze sprint”. Blijk je dat in de sprint makkelijk te halen, dan stel je dat doel bij de volgende sprint gewoon bij. Deze zogenaamde velocity een bijzonder goede graadmeter voor het meten van het succes van het team. Iedere sprint is gericht op het opleveren van een werkend product, wat kan betekenen dat in sprint 1 een kaal CMS wordt opgeleverd, met alleen een homepage en een contactpagina. Zolang het maar een werkend product is, de gebruiker er mee uit de voeten zou kunnen en de klant een meetbare stap in de goede richting heeft gezet.

Denken vanuit de gebruiker

De deelprojecten worden niet ingedeeld op basis van functionaliteiten (“We willen in deze sprint via Google Maps al onze vestigingen tonen!”) maar op basis van user-stories. “Wat wil de klant bereiken, en hoe gaan we dat serveren?” Het kan dus ook zijn dat een user-story in een latere sprint opnieuw terug komt met de toevoeging dat de klant op een kaart de vestigingen wil kunnen bekijken, terwijl in sprint 1 misschien een lijst van lokaties voldoende was. Deze user-stories worden vervolgens opgedeeld in taken voor de verschillende disciplines. Alle user stories komen samen op het product backlog, een grote lijst waaruit voor iedere sprint een selectie kan worden gemaakt van de zaken die in die sprint moeten worden uitgewerkt.

Voordeel hiervan is dat de progressie van het project goed meetbaar is, en de klant bij aanvang van iedere sprint weet wat 2 of 3 weken later wordt opgeleverd. Wanneer de oplevering dan niet volledig is, kan de klant ook in een vroeg stadium aan de bel trekken. Het voorkomt onaangename verrassingen voor de klant. De klant is zeer nauw betrokken bij het project.

Manier van (samen)werken

Het team zit altijd bij elkaar, permanent, in dezelfde ruimte. Er is namelijk altijd voor iedereen werk, want een functioneel ontwerper werkt nooit in week 1 het volledige functioneel ontwerp uit. Dat wordt steeds in iedere sprint uitgewerkt, bijgesteld, aangescherpt. En als jouw werk er in de sprint op zit kun je de implementatie van jouw werk door collega’s testen, of je zet je ontwerp-pet even op en duikt in Photoshop / Fireworks om je collega te helpen met het uitwerken van schermen. Ook de klant is onderdeel van dit team, zit het liefst ook in het scrumhok, wordt betrokken bij beslissingen en heeft continue eigenaarschap over het product in ontwikkeling.

Iedere dag begint de dag met de daily scrum. Deze dagelijkse meeting duurt zo kort mogelijk en heeft eigenlijk voor ieder teamlid drie belangrijke vragen:

• Wat heb je gisteren gedaan?
• Wat ga je vandaag doen?
• Wat zijn eventuele problemen waar je tegenaan loopt?

Iedereen is zo goed op de hoogte van de voortgang, en de problemen die eventueel spelen. Problemen worden direct opgelost of in een lijst opgenomen waar de scrum master mee aan de slag gaat. De scrum master is verantwoordelijk voor het op snelheid houden van het team.

De voordelen op een rijtje

• Delen van kennis – In mijn ervaringen met Scrum viel het me op hoeveel je ineens meekrijgt van de beslissingsmomenten van je collega’s. “Wat nou als we x op manier y oplossen?”, “Zullen we eens kijken hoe lijst a uitklapt met de animatie uit blokje b?”. Het is veel meer een avontuur dat je met je collega’s deelt, het is van jullie allebei, je leert in iedere discussie meer van elkaar dan je ooit in een 80 pagina-tellend FO had kunnen leren.
• Klantbetrokkenheid – De klant maakt iedere dag de voortgang mee, en kan er direct op reageren. Dat kan lastig zijn voor teamleden, maar komt het project uiteindelijk ten goede. No regrets bij oplevering. In mijn ervaring kwam dat ook de band die je hebt met een klant bijzonder ten goede; je snapt steeds beter de visie, zijn of haar overwegingen en de interne politiek aan de klantzijde.
• Voortschrijdend inzicht – Doordat iedere betrokkene iedere dag ziet waar het project toe gaat leiden is het veel makkelijker om bij te sturen wanneer zaken minder goed of effectief blijken te zijn. Het zou er zelfs toe kunnen leiden dat onderdelen niet nodig blijken en komen te vervallen. Er zijn zelfs projecten bekend die halverwege de doorlooptijd en dus ook het budget zijn gestopt. Ontevreden klant? Welnee, juist heel tevreden, het was klaar. De rest van de bij voorbaat beoogde elementen bleken simpelweg overbodig. Less is more, right?
• Planning – Afgezien van het vorige voorbeeld; het is veel gemakkelijker om 5 mensen permanent op een project in te plannen dat steeds de poppetjes te verschuiven over diverse projecten. Iedereen in het scrum team kan elkaars taken overnemen, dus niemand zit ooit meer zonder werk. En als tijdens het project het einde in zicht komt kun je direct het volgende projecten aanpakken met je team; geen loze ruimtes meer in de planning.
• Plezier - Het is echt waanzinnig leuk om op deze manier met je collega’s samen te werken. Je leert in hoog tempo van elkaar, en je leert de talenten en aandachtspunten van je collega’s en de klanten kennen. Dat maakt dat je veel beter op elkaar kunt inspelen en je na verloop van tijd aan een half woord voldoende hebt. Niet dat je elkaars beste vrienden hoeft te worden, maar elkaar goed begrijpen kan nooit kwaad.

Conclusie

Maar nooit meer een waterval project dan? Jawel, maar alleen als het project daarom vraagt. Niet iedere klant kan goed omgaan met deze methodiek; als het contactpersoon aan de klantzijde verantwoording moet afleggen aan een Raad van Bestuur of een stuurgroep heeft dat meer tijd nodig, en zal dat in een Agile Scrum-project alleen maar tot vertraging en irritatie leiden.

Ik denk dat Agile Scrum de nadelen van de waterval-methodiek goed oplost, maar dat maakt het niet per definitie de betere optie. Ik denk vooral dat de voordelen van Agile Scrum het verschil maken. Dat klinkt misschien een beetje stom, maar ik persoonlijk vind vooral de winst in kennisdeling en het stukje voortschrijdend inzicht een veel fijnere manier van werken. Het is het consequent opzuigen van kennis en informatie dat het werken zoveel leuker maakt. Het contact met de klant, het begrijpen van klantvragen en -wensen, het samen chicaneren over die paar pixels, het werken naar dat 100%-project is wat deze manier van werken zoveel zinvoller en leuker maakt. En dan is werk ineens geen werk meer.

update: Ik kreeg naar aanleiding van dit blog relatief veel opmerkingen en vragen rondom: “Ja, leuk, klinkt gaaf, maar hoe verkoop je zoiets? En hoe doe je dat met budgetten?”. Laat me beginnen te zeggen dat ik geen projectleider/ scrum master ben en ook niet die ambitie heb. Dus echt waterdichte antwoorden kan ik niet bieden, maar wil wel een poging doen.

Bij de verkoop van een project spreek je samen met de klant een scope af. “We leveren een website met een nieuw ontwerp, inclusief de bestaande contentvormen en 2 killer applicaties. We werken in sprints van 2 weken met 5 teamleden, en zullen in totaal 3 sprints aan dit project werken.” Daaruit volgt natuurlijk een simpele rekensom ten opzichte van je tarieven.

Scrum werkt niet als je niet van tevoren de visie hebt een langdurige relatie aan te gaan met je klant. Je spreekt de scope voor fase 1 af en gaat daarna kijken welke stappen verder nog kunnen worden gezet, bijvoorbeeld wanneer niet alle user-stories aan bod zijn gekomen. Dit zal in de praktijk echter niet zoveel voorkomen, omdat je veel gemakkelijker de snelheid, scope en richting kunt bijstellen gedurende het project, en de aanpak sowieso leidt tot meer efficiëntie en dus een hogere velocity.

Ik kreeg ook de vraag of het voor kleinere projecten dan niet aantrekkelijk is. Ik denk dat het er vanaf hangt hoeveel user-stories je binnen een klein project probeert te beantwoorden. Als het om 1 user-story gaat zal het niet zoveel uitmaken welke aanpak je kiest, maar zodra je met meerdere teamleden in korte tijd een project wilt realiseren is het hoe dan ook rendabel.

In mijn dagelijkse beslommeringen als ontwikkelaar bij Tam Tam heb ik met vele doelgroepen en diverse browsers te maken. In ieder project dat ik ontwikkel spendeer ik enige tijd aan het conformeren van de website voor de verschillende browsers. Klanten willen tenslotte gelijkheid blijheid voor iedereen, dus dat is wat een goede front-end developer zichzelf dan ook als hoogste doel stelt. Alleen, browsers zijn nooit hetzelfde geweest. Iedere versie van Internet Explorer was compleet anders, ook nu nog. Firefox 3.5 is veel krachtiger dan Firefox 2. Dus als iedere browser iets anders rendert, waarom dan zoveel moeite doen om het terug te brengen tot een uniform ontwerp?

Goh, hoe zou deze website er eigenlijk uitzien in Firefox 3.5?

Een voorbeeldje; een klant bezoekt je website. Op een PC. Met Vista. In Internet Explorer 8. Hoe groot acht je de kans dat deze klant je website bekijkt in deze browser, en dan denkt; “Goh, hoe zou deze website er eigenlijk uitzien in Firefox 3.5?”. Precies, dat komt zelden voor. In de praktijk heeft de gemiddelde gebruiker hooguit 2 browsers op zijn of haar computer geïnstalleerd. Veelal is dit een versie van Internet Explorer in combinatie met een alternatief zoals Firefox of Chrome (die van de abri-reclames, u weet wel). Daarnaast zijn ook Safari (met name op de Mac) en Opera redelijk populair, maar onder een vrij beperkte groep mensen. Microsoft’s Internet Explorer is sinds de browser wars met Netscape nog altijd de populairste browser; zoals onderstaande grafiek aangeeft had Internet Explorer een marktaandeel van iets meer dan 60% in Nederland gedurende de afgelopen maand.

Helaas is het zo dat Internet Explorer het minst slimme jongetje van de klas is. Andere browsers, en dan met name Safari en Chrome zijn wat intelligenter, de strebertjes. Zij kunnen het beste overweg met de suggesties die worden gedaan vanuit de diverse stuurgroepen. Laten we dat even onder de loep nemen.

De droom van iedere developer

De huidige ’standaard’ (afschuwelijk woord) dateert uit 2002, en luistert naar de naam XHTML 1.0, verkrijgbaar in de smaken Strict (streng naar opbouw van code en de beste ondersteuning van standaarden) en Transitional (de Light-versie). Er is de afgelopen tijd gewerkt aan een opvolger (2.0), maar de ontwikkelingen zijn stilgelegd wegens de opkomst van een nieuwe variant die vooralsnog vooral niet als standaard wil worden gezien, maar in ieder geval veelbelovend is, en door de community maar al te graag als standaard wordt aangenomen. Beste lezer, ik stel je met plezier voor aan HTML5 en CSS3, het perfecte echtpaar met de gouden toekomst.

Sinds de intrede van het buzzword web 2.0 zijn ronde hoekjes helemaal hip. Of bijna passé, maar dat terzijde. Enfin, ronde hoekjes zijn jarenlang de nachtmerrie van front-end developers geweest. Omdat je flexibele hoogte en breedte wilt kunnen geven aan de ‘blokken’ van de website waren vaak minstens 3 en soms zelfs 9 losse vlakken nodig om de opmaak goed te realiseren. Over het gebruik in combinatie met tintverlopen en schaduwen kunnen we beter maar zwijgen. Natuurlijk zijn er diverse JavaScript-oplossingen geschreven door de jaren, maar dat werkt in veel gevallen vertragend, onbetrouwbaar, en bovendien ontoegankelijk.

CSS3 maakt dit allemaal overbodig. Je geeft het element een border-radius van bijvoorbeeld 5 pixels, et voila, het element heeft ronde hoeken. Met box-shadow geef je het blok een mooie schaduw in iedere willekeurige kleur en omvang, en je hebt zo ongeveer een half uur tot een uur tijd bespaard. Per blokje. En niet te vergeten; de pagina laadt sneller, werkt ook zonder Javascript, en schaalt netjes mee met tekstgrootte-instellingen. Geweldig toch? En het werkt in bijna alle browsers! “Sorry? Bíjna? Hoe bedoel je bíjna?”

Safari, Firefox en Chrome zijn bijna identiek en probleemloos. Opera geeft een button uit het jaar 0 weer, en IE8 kan er helemaal geen wijs uit.

Helaas is Internet Explorer grote spelbreker in deze kwestie waarbij er geen enkele ondersteuning is – behalve IE9, maar deze verschijnt pas op z’n vroegst 3e kwartaal 2010. Laat ik overigens vooral ook benadrukken dat de andere browsers óók verschillende interpretaties kennen van sommige declaraties, hoewel in bovenstaand voorbeeld de belangrijkste browsers naast Internet Explorer allen goed omgaan met de border-radius en box-shadow. Een cross-browser oplossing is er dus niet behalve door gebruik te maken van afbeeldingen, maar dat kost bijzonder veel meer tijd. Gelukkig zijn dit soort browserverschillen ook verwaarloosbaar; de content is immers gelijk en nog steeds goed bereikbaar in alle browsers. Gelijkheid blijheid op datgene dat er echt toe doet. Browsercompatibiliteit betekent immers niet automatisch identiek.

Progressive Enhancement

De titel van dit artikel staat haaks op mijn politieke voorkeur; ik zou een pruik moeten dragen om een dergelijk statement zonder enige vorm van schaamte over de bühne te kunnen brengen. Wanneer we het echter projecteren op ons eigen vak, sta ik wel degelijk achter dit statement. We hebben jarenlang het verkeerde ideaal nagestreefd, en daarmee de mogelijkheden niet altijd volledig benut.
We moeten net als in het dagelijks leven uitgaan van de kracht van het individu, of in dit geval de individuele browser. Ontwikkel de websites in basis voor de meest uitgeklede browser: Internet Explorer 6/7/8. Maak daarnaast gebruik van de krachten van Firefox, Safari, Chrome en Opera om te zorgen dat iedere gebruiker in zijn of haar browser de optimale beleving heeft van jouw website. Het feit dat alleen Safari en Chrome op dit moment het gebruik van CSS3 animaties ondersteunen betekent niet dat deze fantastische mogelijkheden dan maar achterwege moeten worden gelaten. Integendeel; werk naar de toekomst toe!

Deze manier van werken heet in de developers community progressive enhancement, maar beter nog is de term progressive enrichment zoals Dan Cederholm het noemt. Deze werkwijze houdt in dat je de website bouwt met de minimale eisen als fundament. Iedere laag die je daarna aanbrengt is voor de eindgebruiker en gaat daarbij uit van de functionaliteiten zoals de browser die ondersteunt. Daarbij kun je naast de genoemde browser ook denken aan mobiele browsers op de iPhone, iPad en Android- en Symbian-telefoons.

Even teruggrijpen op de eerdere afbeeldingen. Dat houdt dus in dat in IE6, IE7 en IE8 de gebruiker geen ronde hoeken ziet, afbeeldingen niet ziet vervagen als de muis de foto weer verlaat, geen animaties meer ervaart maar louter de statische afbeeldingen. Is dat erg? Nee, ik denk het niet, omdat de gebruiker immers geen referentiekader heeft waarin dat ooit wel zo was. De gebruiker kan overal bij, alle content is beschikbaar en omdat het geen afhankelijkheid van Javascript kent is het ook volledig toegankelijk voor tekstbrowsers, zoekmachines of welke andere doelgroep dan ook. En daarnaast heeft 40% van je gebruikers wel die rijke ervaring! Bovendien zal dat getal alleen maar groeien de komende tijd. IE9, de veelbelovende browser van Microsoft, ondersteunt namelijk wel een groot deel van deze experience enriching elementen, en komt naar verwachting eind 2010 uit. Natuurlijk zullen we nog af en toe IE6 t/m 8 tegenkomen in onze statistieken, maar dat zal hoe dan ook een uitstervend ras blijken.

“Oke, leuk, maar wat nu?”

Stop met het remmen van innovatie in webapplicaties, ook aan de esthetische kant. Ontwikkel niet wederom een ‘gemiddelde’ website. Geef niet toe aan de gebreken of beperkingen van browsers. Laat het begrip ‘browsercompatibiliteit’ los en benut de kansen die er zijn voor de verschillende browsers en zorg voor de optimale gebruikerservaring die past bij de individuele eindgebruiker, in plaats van bij de oudste browser of die vastgeroeste developer. Waarom?

• Meer value for money: Minder tijd kwijt aan corrigeren en dus meer tijd voor de optimale interface.
• Flexibiliteit is belangrijker dan compatibiliteit: Eén site die je kunt gebruiken op alle platformen inclusief de mobiele platformen en touch-interfaces; dat scheelt een hoop losse investeringen!
• Met de stroom mee, in plaats van er tegenin: Zoals gezegd, browsers zijn verschillend, dus waarom zou je enorm veel tijd verliezen aan het corrigeren van deze verschillen in plaats van ze optimaal te benutten?

Dit artikel verscheen eerder op Frankwatching