Nederlandse en Vlaamse archivarissen in beweging

Top 5 drempels bij volgen van webrichtlijnen

Het is deze week uitgebreid in het nieuws geweest: Eind 2010 moeten alle overheidswebsites aan de webrichtlijnen van de overheid voldoen. Tot nu toe gold deze verplichting alleen voor websites van de Rijksoverheid, in archievenland dus alleen voor het Nationaal Archief. Maar nu zullen ook de andere archieven er dus aan moeten geloven.

In het kort zijn de webrichtlijnen bedoeld voor betere toegankelijkheid voor gehandicapten, betere onderhoudbaarheid en betere vindbaarheid van websites. Zie de Webrichtlijnen-website voor meer informatie.

In deze post zal ik ingaan op die webrichtlijnen die in de praktijk het lastigst te realiseren zijn bij het maken van websites voor archiefinstellingen.

Alternatieve teksten voor afbeeldingen
Volgens de webrichtlijnen moet elke afbeelding een alternatieve tekst hebben (7.1). Deze alt-tekst moet effectief zijn, zodat een blinde bijvoorbeeld weet wat er op het plaatje te zien is. Maar dit stuit op problemen bij foto's van archiefstukken. Het enige volwaardige alternatief voor een foto van handgeschreven tekst is een integrale transcriptie. In veel gevallen is dit echter onbegonnen werk. Ook het op aanvraag beschikbaar maken van een transcriptie voor een gehandicapte is organisatorisch niet te doen, want hoe weet je of iemand daadwerkelijk gehandicapt is of 'gewoon' moeite heeft om het oude schrift te lezen?

Een praktische aanpak is hier om in de alternatieve tekst in elk geval duidelijk te maken om welk stuk het gaat (als dat niet uit de context blijkt). Formeel is dit niet voldoende. Maar als een dergelijke aanpak gecombineerd wordt met bijvoorbeeld een transcriptieproject (al dan niet door bezoekers van de website zelf!) dan kan bij vragen in elk geval aangetoond worden dat het archief zich maximaal heeft ingespannen om de gegevens beschikbaar te krijgen.

Bij 'gewone' afbeeldingen die als illustratie dienen is het belangrijk dat de contentbeheerders weten hoe ze effectieve alternatieve teksten moeten schrijven.

Valide HTML en CSS
Een andere richtlijn vereist dat de website onder water correct gebruik maakt van de internationale open standaarden XHTML 1.0 strict en CSS 2.1 (richtlijn 2.1, 2.4 en 2.6). Daarbij moet XHTML alleen gebruikt worden voor de inhoud en moet alle opmaak in CSS worden gedaan (richtlijn 1.1).

In de praktijk blijkt dat veel content management systemen (CMS) standaard geen valide code opleveren. De strict-variant van XHTML betekent dat allerlei verouderde elementen van HTML niet meer gebruikt mogen worden, terwijl de editors in de CMS-en hier wel gebruik van maken. Bekende voorbeelden zijn target="_blank" om een nieuw venster te openen, <b> om vette tekst aan te geven, etc. De enige manier om dit probleem op te lossen is door het CMS zelf aan te laten passen.

Het is ook belangrijk om degenen die bijdragen leveren aan de website niet alleen de goede tools te geven, maar ook te leren hoe ze die moeten gebruiken. Een voorbeeldje: volgens de specificaties moet je kopjes opmaken met een speciale opmaakcode (h1, h2, etc.). Maar als een schrijver ervoor kiest om dit gewoon in platte tekst te doen met een regelovergang, dan is die kop dus niet juist opgemaakt. Bij eigen medewerkers is dit met een stukje training op te lossen, maar het wordt pas echt spannend als je ook het publiek materiaal laat bijdragen. Dan is het extra belangrijk dat de editor duidelijk is en zich goed leent voor het correct opmaken van de informatie.

Gebruik van Javascript
Volgens de webrichtlijnen moet de website ook werken als Javascript niet beschikbaar is (richtlijn 1.3).

Juist voor archief2.0-websites kan dit een belangrijk aandachtspunt zijn voor de bouwer van de website. Typische web2.0-elementen zoals dynamisch aanpassende pagina's (a la Gmail), widgets maar ook openklappende menu's en dergelijke worden onder water vaak met behulp van Javascript gerealiseerd. Hier is niets mis mee, zolang de site ook maar werkt als Javascript uitstaat. Veel bouwers zijn hier niet van op de hoogte, wat tot vertraging kan leiden.

Aangeven van taalveranderingen
De webrichtlijnen vereisen dat je van alle tekst op de website in code aangeeft in wat voor taal die geschreven is (richtlijn 15.7). Veel archieven hebben een Engelse versie van de site, waarbij slechts een deel van de content vertaald is en andere teksten (bijvoorbeeld de inhoud van databases) in het Nederlands staan. Onder water moet dan elke taalwissel worden aangegeven. Dit is niet alleen een aandachtspunt voor de bouwer van de website, maar moet ook in het content managementsysteem worden opgenomen zodat de contentbeheerders van hun teksten kunnen aangeven in welke taal die geschreven zijn.

Ook bij deze richtlijn is content die door bezoekers is aangeleverd een aandachtspunt. Hoe weet je in wat voor taal een reactie van een bezoeker is? Waarschijnlijk wil je de bezoeker er niet mee lastigvallen om dat te vragen, dus dan blijft het een gok. Bij een meertalige website zou je ervoor kunnen kiezen om de huidige taalkeuze op te slaan bij bijdragen van bezoekers, aangezien dat de beste gok is die je kunt maken. Een dergelijke aanpak is bijvoorbeeld gebruikt bij de commentaar-functie van de beeldbank van het Nationaal Archief. Commentaar van bezoekers van de Engelse versie wordt daar met taalcode Engels opgeslagen.

Unieke, vaste en vriendelijke URLs
Een andere webrichtlijn vereist dat de adressen (URLs) van de pagina's binnen de website uniek en onveranderlijk zijn (richtlijn 4.1). Dit moet ons als medewerkers van archiefinstellingen aanspreken: zo wordt de toegankelijkheid voor de toekomst gegarandeerd. Tevens moeten de URLs vriendelijk en leesbaar zijn (richtlijn 4.6).

In de praktijk blijkt dit nogal weerbarstig te zijn. Veel content management systemen hebben out-of-the-box geen mooie URLs, zodat deze zullen moeten worden aangepast. Omdat URLs niet meer mogen veranderen is het belangrijk dat bij het bepalen van de links goed wordt nagedacht over een onderhoudbare en uitbreidbare structuur.

Ook de leesbaarheid van URLs is een aandachtspunt. Vooral bij grote databases, zoals genealogische databases, is het vrijwel onvermijdelijk om toch het identificatienummer mee te geven. Dat zorgt echter al snel voor onleesbare URLs, aangezien de vuistregel daar is dat er niet meer dan 5 cijfers in voor mogen komen omdat het anders niet te onthouden is.

Slot
De webrichtlijnen gaan voor archieven een nieuwe uitdaging vormen, zeker als we ook onze bezoekers content bij laten dragen. Ik hoop dat ik jullie met deze toelichting een stukje heb kunnen helpen. Mochten jullie aanvullende tips of vragen hebben, maak dan vooral gebruik van de commentaarmogelijkheid!

Tags: webrichtlijnen

Reactie van Christian van der Ven op 7 Februari 2009 op 19.04: Yvette, dank voor deze informatie! Inderdaad staan ons met die webrichtlijnen nogal wat uitdagingen te wachten, zeker omdat we onder de vlag van 2.0 een deel van de website "uit handen" willen geven.

Wat dat laatste betreft denk ik dat we door slimme interfaces aan te bieden problemen kunnen voorkomen, zonder daarmee de nietsvermoedende klant last te vallen.

Kijk bijvoorbeeld naar het gebruik van kopjes. Bij het BHIC willen we mensen in de toekomst onder een eigen profiel graag verhalen met foto's laten toevoegen aan de website. Door een interface te maken met een apart invulveld voor de titel van het verhaal, kan het cms dit standaard als kopje in de html aanmerken. Om tekst vet te maken enzovoort, moeten voor gebruikers gewoon knopjes beschikbaar zijn, die op de achtergrond de juiste codes toevoegen. (Want een gebruiker heeft natuurlijk gewoon een wysiwyg-editor ter beschikking.)

Vooral de cms'en zullen dan dus aangepast moeten worden. En blijkens jouw toelichting op vele fronten.

Hoe dat met dat JavsScript zit weet ik niet, want volgens mij zijn er talloze andere mogelijke plugins enzovoort om een beetje beweging op een pagina te krijgen. De nadruk op JavaScript lijkt me persoonlijk een beetje een relikwie uit het verleden van internet.

Ik ben benieuwd... Vooral die vaste, vriendelijke url's gaan een uitdaging worden, vermoed ik. Maar sowieso - ook zonder de webrichtlijnen - eentje waaraan we zouden moeten willen werken!

Reactie van Bob Coret op 7 Februari 2009 op 20.32: Yvette,

Leuk artikel, het stuk over "Aangeven van taalveranderingen" was nieuw voor mij!

@Christian,

Javascript is zeker geen relikwie uit het verleden! Kijk eens naar sites als GMail en Google Reader: één en al Javascript. Maar het knappe is dat je deze sites ook zonder Javascript kunt gebruiken. En dat is toch een uitdaging om voor elkaar te krijgen! Voor de grap heb ik ook nu even Javascript uitgezet en ook Ning blijft werken, alhoewel, je ziet in de header de tekst "Hallo, om dit netwerk te gebruiken, dien je JavaScript aan te zetten.", dus waarschijnlijk doet niet alles het... De richtlijn gaat overigens niet alleen of specifiek over Javascript maar over "Niet rekenen op optionele technologie". Vooral Flash is een beruchte. Ook voor deze elementen zul je een alternatief moeten hebben.

Reactie van Christian van der Ven op 7 Februari 2009 op 21.01: @Bob: Ik bedoel ook niet zozeer JavaScript op zich, maar de nadruk op enkel JavaScript als een probleem. Dat was jaren terug nog wel zo. In negen van de tien keer dat je beweging had op een site, kwam dat door JavaScript, later door Flash ook. Tegenwoordig is het scale aan toepassingen veel groter en is het probleem dus veel breder voor gehandicapten, dan alleen JavaScript. De webrichtlijnen zouden dus beter al dat soort dingen kunnen noemen onder een soort koepelterm of zo, in plaats van het enkel over JavaScript te hebben. (Even op het gevaar af dat ze dat doen, want ik heb er nog niet helemaal doorheen gelezen.)

Reactie van Yvette Hoitink op 7 Februari 2009 op 23.54: @Christian
Veel 'widgets' werken overigens ook op basis van Javascript, en zullen dus niet werken als Javascript is uitgeschakeld...

Reactie van Bob Coret op 8 Februari 2009 op 0.01: o, o, http://www.bhic.nl/index.php?id=10139 ;-)

Reactie van Yvette Hoitink op 8 Februari 2009 op 0.27: @Bob
Mooi voorbeeld :-) Redenen waarom dit niet mag:
* Slecht te onthouden
* Afhankelijk van de huidige implementatie (PHP)
* Niet geoptimaliseerd voor zoekmachines (geen zoektermen in URL)

Reactie van Yvette Hoitink op 8 Februari 2009 op 0.27: Stukje over Javascript iets aangepast nav comments.

Reactie van Christian van der Ven op 8 Februari 2009 op 11.00: Wat nog wel een lastige is: juist 2.0-websites, zoals Yvette aangeeft, maken erg veel gebruik van embedded technologieën, zoals widgets, en van functionaliteiten die van of via andere websites worden geplukt. De techniek daarachter heb je zelf niet in de hand. Het is al lastig genoeg om je eigen cms en de applicaties van al je databaseleveranciers webrichtlijn-proof te krijgen en te houden. Sowieso zul je heel vaak merken dat een boel dingen gewoon niet kunnen als je je strikt aan die webrichtlijnen wilt houden. Keuzes dus.

Niet dat ik de gehandicapte medemens tekort wil doen, maar het moet niet zo zijn dat de 'zwakste schakel' in dit geval de maximumlijn voor functionaliteit op een website gaat bepalen. (Komt dit nou heel erg onaardig over?)

Ik verwacht dat er nog best heel wat gediscussieerd zal worden over dit onderwerp...

Reactie van Bob Coret op 8 Februari 2009 op 11.21: @Yvette,

Ik gaf de voorbeeld URL omdat juist op die pagina het BHIC één van mijn widgets heeft opgenomen. En laat deze nou ook niet geheel aan de richtlijnen voldoen, deze doet het alleen als Javascript aan staat... Ga er vandaag eens over nadenken hoe deze widget zonder Javascript kan werken, moet kunnen!

Reactie van Christian van der Ven op 8 Februari 2009 op 11.31: @Bob: Door alle 'fouten' in de url was Yvette tot de widget zelf niet eens meer gekomen, vrees ik... ;-)

Ik hoop dat alle widgetbouwers jouw instelling hebben!

Opmerking