 |
 |
||
 |
 |
 |
|
toegankelijkheid
achtergronden project
vooronderzoeken
onderdelen Drempelsweg.nl
procesbeschrijving
evaluatie project
evaluatie stage
conclusies & aanbevelingen
projectmanagement
richtlijnen
facilitaire website
voorbeeldsites
Richtlijnenonderzoek en -ontwikkeling
Ik denk dat het deelproject Richtlijnen in twee onderdelen kan worden onderscheiden: richtlijnenonderzoek en het ontwikkelen en samenvatten van richtlijnen (met o.a. het onderzoeken van alternatieven).
Het richtlijnenonderzoek was de eerste grote opdracht die ik binnen Drempels Weg uitvoerde. Het verloop van het project en de verwachte eindprodukten waren nog uiterst vaag. Zo vaag zelfs, dat bijna alle inhoudelijke aspecten door de deelnemers zelf bedacht zijn tijdens het project.
Ik denk zelfs dat er door deze manier van werken een compleet andere uitkomst was geweest als er andere deelnemers aan het projectteam waren geweest. Ik vond deze vage omkadering in het begin moeilijk om mee te werken, maar later (met name tijdens het bouwen van de verschillende sites) heb ik er veelvuldig gebruik van gemaakt om dingen naar eigen inzicht in te richten.
Richtlijnenonderzoek
Het richtlijnenonderzoek bestond voornamelijk uit desktop research. Dit leek mij verreweg de meest voor de hand liggende manier om achter het bestaan van andere richtlijnen te komen. Tien dagen lang heb ik besteed aan het surfen en zoeken naar richtlijnen, in de laatste paar dagen geholpen door een tweede onderzoeker. De conclusie -er zijn eigenlijk geen andere richtlijnen dan die van het W3C- had ik al na twee dagen genomen. Toen heb ik nog een dag besteed om deze conclusie te verifiëren. Tijdens het verdere onderzoek is er nauwelijks extra informatie bijgekomen.
De rest van de tien dagen heb ik besteed aan het lezen en proberen te begrijpen van de W3C richtlijnen. Het eerste deel van het onderzoek was afgerond.
Waarom al zo vroeg? Nadat ik het halve Net had afgestruind op bruikbare richtlijnen kon ik niets anders concluderen dan dat er maar één soort richtlijnen was: die van het W3C. Alle sites verwezen ernaar. Maar die van het W3C waren onbruikbaar, omdat ze gewoon te omvangrijk, technisch en onoverzichtelijk waren. Het W3C streeft vooral naar compleetheid, boven bruikbaarheid. De paar samenvattingen die ik had gezien waren weer te simplistisch: omdat hier weer te weinig informatie stond werd de lezer gedwongen tekst en uitleg te gaan zoeken bij het W3C.
Ik besloot dat geen van de gevonden vormen van richtlijnen echt voldeed en webbouwers uitnodigde sites toegankelijk te maken. Er moest een nieuwe lijst komen die een goed overzicht gaf van de richtlijnen. Daarbij was het belangrijker dat gebruikers ze echt zouden kunnen gebruiken dan de compleetheid ervan.
Vooruit werken en oefenen: opstellen van standaarddocumenten
Zoals ik bij de vooronderzoeken reeds heb opgemerkt, ben ik na het interpreteren van de richtlijnen van het W3C begonnen aan een standaard document voor CSS-technieken. Dit vooruitwerken had een procesmatige reden.
Omdat het richtlijnenonderzoek snel was afgerond hadden we even weinig te doen. En dat terwijl er een hele berg werk stond te wachten. De reden dat we nog even niets te doen hadden, was dat we op de schetsen van Lust moesten wachten voor we verder konden.
Om de tijd zo nuttig mogelijk te besteden besloot ik een standaarddocument te maken voor intern gebruik binnen NMG, met daarin alle mogelijkheden en alternatieven van style sheets op een rij. Dit zou als naslagwerk kunnen dienen bij de bouw van de verschillende websites. Dit document was meteen een oefening voor de juiste interpretatie van de richtlijnen, omdat ik alles meteen 'in het echt' bouwde om te kunnen testen.
Standaardwerk
Toen later een collega begon aan een soortgelijk document voor HTML (alle tags alfabetisch getest en behandeld) voelden we ons alsof we een standaardwerk voor webbouwers aan het opstellen waren.
Alles wat we opschreven hebben we eerst in het 'echt' uitgeprobeerd. Nieuwe vindingen werden gedeeld. We vielen van de ene verbazing in de andere. Met zijn tweeën dachten we alles van HTML te weten wat er te weten viel. Het W3C beschrijft echter ook tags die nooit gebruikt worden. En zelfs tags die nog niet eens door een browser ondersteund worden.
Dit gaf een extra dimensie aan het in de praktijktesten van de richtlijnen. Dingen die (nog) niet werkten werden voorlopig geschrapt voor de Drempels Weg database. Later, toen we er niet meer uitkwamen, moesten we de hulp van enkele gehandicapten inschakelen om het eventuele effect van een tag te controleren.
Het nadeel van dit vooruitwerken was duidelijk: we waren puur theoretisch bezig en snakten aan het eind naar het bouwen van een gewone website. Toch heeft dit vooruitwerken -zeker voor ons- haar vruchten afgeworpen. Tijdens de bouw van de facilitaire site konden we terugvallen op een uitgebreide technische kennis, alsmede een uitgebreide theoretische kennis van de richtlijnen.
volgende pagina:
Facilitaire website
Voor een overzicht:
ga naar de Sitemap
Verklarende Woordenlijst
Opstellen en verrijken richtlijnen
Een veel grotere klus dan het richtlijnenonderzoek was het opstellen en indelen van de Drempels Weg richtlijnen. Toen had ik inmiddels de structuur en vorm van een individuele richtlijn bedacht en een uitvoerpagina voor de database gemaakt. Samen met de programmeur hebben we de structuur opgezet en een beheerkant gemaakt om richtlijnen aan te maken of te wijzigen. Toen konden we gaan invoeren.
We hadden wel een Nederlandse vertaling, maar deze behandelde ook de onbruikbare tags. Er moest gefilterd worden. En aangevuld.
Alternatieven moesten bedacht worden, voorbeeldcode moest worden geschreven en getest. Richtlijnen moesten van commentaar worden voorzien en gekoppeld aan elkaar in de database. Ook dit is een klus die ik eerst in mijn eentje ben begonnen. Later werd ik ook hierin geassisteerd.
Halverwege heb ik nog een systeem bedacht dat overzicht gaf in de richtlijnendatabase. Het is een soort visuele weergave van de richtlijnendatabase, gekoppeld aan het wijzig- en weergavegedeelte van een richtlijn. Onze programmeur heeft die toen gebouwd.
Onduidelijkheid
Nadat wij (de HTML-ers) ons technische verhaal hadden afgerond en voorbeeldcode en commentaar en achtergronden hadden geleverd, was het tijd voor de redacteur om de boel na te kijken op consistentie en zo nodig aan te vullen indien er onduidelijkheden zouden zijn. Wij gingen snel verder met de bouw van de facilitaire website.
Hier was sprake van onduidelijkheid over de taakverdeling. De redacteur vond dat het niet tot haar taak behoorde om commentaar te leveren op een technisch verhaal, terwijl wij het niet tot onze taak rekenden om de hele database te vullen met lappen tekst. We hadden allemaal wel meer te doen.
Uiteindelijk hebben wij het toch gedaan, omdat wij op dat moment nog steeds de enigen waren met enig inzicht in de richtlijnen.
Fig.1: visuele weergave van de richtlijnendatabase (detail). Groen is ingevuld, paars is leeg. Soms (bijvoorbeeld als het om een flag gaat) staan de waarden die zijn ingevuld al in het groene veld.
Vanaf dit scherm kan direct worden doorgelinkt naar een invulapplicatie om de richtlijn aan te vullen of om een nieuwe aan te maken.
naar boven