Valide code en Webstandaarden

Valide code en Webstandaarden

Valide code en webstandaarden dragen bij een een heldere structuur en een voorspelbare presentatie en gedrag.

Structuur, presentatie en gedrag

Het W3C (World Wide Web Consortium) heeft webtalen ontwikkeld en vastgesteld, in samenspraak met zoveel mogelijk belanghebbenden. Er is daarbij zoveel mogelijk rekening gehouden met onder andere de toegankelijkheid en bruikbaarheid voor iedereen. De codetalen worden door het W3C 'Recommendations' of Aanbevelingen genoemd. Buiten het W3C worden ze vaak 'Webstandaarden' genoemd (in het Engels 'Web Standards' of kortweg 'Standards').

Webstandaarden kunnen in drie gebieden worden verdeeld: Structuur, presentatie en interactie (behavior).

Structuur

Webpagina's worden geschreven in de structuurtaal HTML (Hyper Text Markup Language). De laatste versie is XHTML. Dit is de basis van iedere pagina en iedere site. Naast HTML zijn er nog andere structuurtalen, zoals MathML (taal voor wiskundige definities), SVG (schaalbare afbeeldingen), XML (opmaaktaal), SMIL (taal voor multimedia).

Presentatie

Naast structuurtalen bestaan er presentatietalen. Dit is bijvoorbeeld CSS (Cascading Style Sheets). Een andere presentatietaal is XSL, die voornamelijk bij XML-gerelateerde documenten worden gebruikt. Het doel van deze talen is de opmaak van een document te regelen, ofwel de zichtbare presentatie zoals kleurgebruik, lettertype en positionering.

Interactie (behavior)

Tenslotte zijn er op het gebied van interactie nog standaarden. Het DOM (Document Object Model) is een standaard voor het beschrijven van de hiërarchie van XML en HTML elementen. ECMA is een scriptingtaal die gebruik maakt van het DOM waarmee het elementen en attributen kan manipuleren.

Een webpagina bestaat altijd uit een structuurtaal. Maar hiernaast kunnen webstandaarden uit de andere gebieden gebruikt zijn.

Tag soup

HTML is dé taal voor het schrijven van webpagina's. De afkorting staat voor Hyper Text Markup Language. De eerste versies van HTML waren puur gericht op de structuur van de documenten. Maar al snel bestond de wens om pagina's er ook mooi uit te laten zien. Omdat er nog geen goede manier was ontworpen in HTML om dit te doen, deden de volgende ontwikkelingen zich voor:

• Mensen die webpagina's maakten gingen structuurelementen gebruiken voor presentatiedoeleinden. De tabel die bedoeld was voor het presenteren van datagegevens werd gebruikt voor het positioneren van stukken tekst (opmaak). En bijvoorbeeld het element blockquote, bedoeld om langere citaten aan te geven, werd gebruikt voor het laten inspringen van een stuk tekst.
• Browserfabrikanten zorgden ervoor dat er meer opmaakmogelijkheden kwamen voor hun nieuwe browserversies. Hiervoor brachten ze eigen elementen en attributen uit die wanneer opgenomen in de code een bepaald opmaakeffect bewerkstelligden. Deze 'browser-specifieke' elementen en attributen hadden alleen resultaat in die browser.
  Netscape kwam bijvoorbeeld met het element 'blink' dat tekst liet knipperen en het element 'layer' om te positioneren. En voor Internet Explorer was er bijvoorbeeld het element 'marquee', waarbij tekst door het beeld schuift.
  Voor het positioneren van de pagina moest bij Internet Explorer 'topmargin', 'leftmargin', 'rightmargin', 'bottommargin' aan het body-element worden toegevoegd en bij Netscape 'marginwidth'en 'marginheight'.
  Om dezelfde resultaten te bereiken in verschillende browsers werden veel verschillende browser-specifieke codes gebruikt.
• Toen het presenteren van informatie op webpagina's nog in de kinderschoenen stond, werd gedacht dat het belangrijk was dat de informatie er, net zoals bij geprinte informatie, overal het zelfde uit ziet (Inmiddels is de nadruk aan het verschuiven naar bruikbaarheid). Webbouwers gebruikten veel extra code en trucs om in meerdere browsers hetzelfde visuele effect te krijgen.
• Doordat browsers vaak soepel omgaan met fouten in code, werd er geen grote aandacht besteedt of alle elementen en attributen wel goed werden afgesloten of genest. Er werd in een aantal bekende browsers getest of er werd gemeld dat de site voor één browser met een bepaalde resolutie was ontworpen. Het resultaat in niet alledaagse browsers of met hulpapparatuur was van ondergeschikt belang en vaak niet bekend.

Het gevolg van deze ontwikkelingen was dat er hoofdzakelijk pagina's op internet bestonden die uit een brei van niet officiële, ongeordende code bestonden, de zogeheten 'Tag Soup'.

Scheiding van opmaak en inhoud

Op dit moment begint de nadruk bij professionele webontwikkelaars steeds meer op scheiding tussen opmaak en inhoud te liggen. Dat wil zeggen dat alle structuur in een structuurtaal aangegeven wordt, en alle opmaak in een presentatietaal. Wanneer inhoud en presentatie gescheiden zijn is het voor zo veel mogelijk gebruikers mogelijk om pagina's zo optimaal mogelijk te gebruiken.

HTML wordt slechts gebruikt voor documentstructuur, waaronder:

• koppen;
• alinea's;
• citaten;
• links;
• opsomminglijsten;
• datatabellen.

En alle opmaak wordt vastgelegd in een presentatie (zoals CSS) waaronder:

• lettertype;
• kleurgebruik;
• positionering;
• keuze van opsommingtekens.

De scheiding tussen inhoud en presentatie was niet altijd duidelijk. In HTML 3.2 werden bijvoorbeeld expliciete mogelijkheden geïntroduceerd voor opmaak, zoals achtergrondkleur, tekst en linkkleuren en centreren. In HTML 4 werden veel van de opmaakmogelijkheden afgekeurd en werd de nadruk gelegd op volledige ondersteuning van Cascading Style Sheets. Voor de opmaak van webpagina's werden verschillende CSS-versies (Cascading Style Sheets) uitgebracht, die nu ook steeds beter door alle browsers ondersteund worden. In eerste instantie was die style sheet-ondersteuning van browsers er niet, waardoor veel mensen toch HTML gebruikten.

Doctypes

Latere ontwikkelingen bestaan er dus uit dat HTML (en opvolger XHTML) alleen als een taal gezien moet worden voor het opmaken van de structuur van een document. Opmaakelementen en -attributen van de taal zijn grotendeels uit de taal verwijderd (zie ook het artikel afgekeurde elementen en attributen).

In het begin van elke pagina dient u het doctype (DTD: doctype definition) aan te geven. De doctype informeert browsers en validators welke DTD u gebruikt en is van invloed op hoe een browser het document weergeeft. In de DTD staat de HTML-versie die u gebruikt en een verwijzing naar een document waarin staat aan welke grammatica het document voldoet en welke attributen en elementen hier binnen mogelijk zijn. Er zijn doctypes voor gewone pagina's en aparte doctypes voor pagina's die uit frames bestaan.

Vanwege de trend van het scheiden van structuur en presentatie zijn in de nieuwere HTML-versies een aantal elementen en attributen afgekeurd. Omdat niet alle pagina's op het internet zomaar zijn aangepast en niet iedereen alle opmaak in CSS kan schrijven is er een tussenoplossing bedacht: Er zijn er voor de laatste HTML-versies twee taalvarianten: één waarbij je wel de afgekeurde HTML-opmaakelementen -en attributen mag gebruiken binnen HTML (transitional doctype) en één waarbij dat niet meer mag (strict doctype). Wanneer u bijvoorbeeld het element 'font' gebruikt, dat een afgekeurd element is, mag dat alleen in een transitional HTML 4.01 of XHTML doctype.

Valide code

Het begrip 'valide code' wordt gebruikt wanneer webpagina's geschreven zijn volgens de officiële grammatica van de betreffende taal zoals vastgesteld door het W3C.

De Prioriteit 2 IJkpunten van de W3C Richtlijnen voor de Toegankelijkheid van Web Content 1.0 van het W3C bevatten ook een ijkpunt waarin gesteld wordt dat valide code gebruikt dient te worden:

IJkpunt 3.2 'Creëer documenten die zich conformeren aan een gepubliceerde formele grammatica'.

In valide code worden geen browser-specifieke elementen en attributen gebruikt. Deze zijn verzonnen door browserfabrikanten en zijn geen geldige code.

Bouwers van websites gebruiken zelden valide code. Vaak wordt alleen gekeken naar hoe 'gewone' browsers de website met informatie presenteren, of zelfs alleen hoe de bekendste browser een pagina laat zien.

Er kan niet altijd voorspeld worden hoe hulpsoftware en -apparatuur omgaan met fouten in de code. Onjuist gebruik van HTML kan ook leiden tot fouten bij het gebruik van bijvoorbeeld JavaScript en CSS. Valide code geeft meer zekerheid dat webpagina's lees- en bruikbaar zijn op verschillende platformen, met verschillende browsers en met verschillende hulpapparatuur.

Met een validator kan gecontroleerd worden of code valide is, bijvoorbeeld met de W3C Validator voor HTML en XHTML of de W3C CSS Validator. Voor HTML-validatie is een doctype vereist. De validator weet dan tegen welke HTML-versie, met bijbehorende grammatica en lijst van elementen en attributen, getoetst moet worden.

Het gebruik van valide code biedt onder andere de volgende voordelen:

• Pagina's worden beter en sneller weergegeven;
• Kosten en tijdsbesparing doordat geen browser-specifieke code nodig is;
• De HTML van een pagina is eenduidig, waardoor het werk beter overdraagbaar is, fouten makkelijker te herstellen zijn en aanpassingen makkelijker gemaakt kunnen worden;
• De pagina's zijn stabieler en de interactie met scripts en andere technieken zal beter verlopen;
• Valideren is een eenvoudige en goedkope manier van foutopsporing, ook kleine typefouten of syntaxfouten kunnen grote gevolgen hebben en zijn zo makkelijk op te sporen.
• Meer zekerheid dat webpagina's lees- en bruikbaar zijn op verschillende platformen, met verschillende browsers en met verschillende hulpapparatuur.

Webstandaarden

De term webstandaarden omvat meer dan het begrip 'valide code'. De gebruikte code is niet alleen valide, maar bovendien zijn elementen, attributen en talen gebruikt voor het doel waarvoor ze ontworpen zijn. Zo gebruik je voor opmaak geen tabellen (die gebruik je alleen voor datatabellen), maar CSS.

Een document dat valide is kan bijvoorbeeld koppen bevatten die opgemaakt zijn met HTML waarmee alleen visueel informatie over de structuur wordt overgedragen. Bij een pagina die voldoet aan de webstandaarden bestaat de kop uit een header (een structuurelement), waarbij opmaak geregeld is in de style sheet.

Bij een valide pagina zijn opmaak en content niet persé gescheiden, en het kan zo zijn dat er nauwelijks structuurelementen worden gebruikt, of dat ze voor andere doeleinden worden gebruikt dan bedoeld. Bijvoorbeeld een tabel voor opmaak, of een willekeurige header om tekst ergens vetter en groter te maken.

Het gebruik van webstandaarden biedt naast de voordelen van valide code, nog de volgende voordelen:

• Een site conform webstandaarden is beter toegankelijk voor zoekmachines en beter te evalueren en te indexeren door zoekmachines omdat de structuur van de pagina goed in elkaar zit en duidelijk is wat titels, koppen en inhoud van de pagina zijn;
• Een eigen zoekmachine op de site zal beter werken;
• Zowel oudere als nieuwere browsers kunnen pagina's goed (of op zijn minst bruikbaar) weergeven;
• Er is maar één site voor iedereen nodig. Een site conform webstandaarden is beter toegankelijk voor zowel een bezoeker die de website met een lage resolutie bekijkt, als een blinde met hulpapparatuur als iemand die de site met een mobiele telefoon bekijkt;
• Meer bezoekers hebben toegang tot de site;
• Door de scheiding van opmaak en presentatie kunnen bezoekers de site bijvoorbeeld bekijken met een ander style sheet, waardoor de site toch bruikbaar voor hen is;
• Vermindering van bandbreedte (onder andere omdat alle opmaak in style sheets is vastgelegd) betekent lagere kosten.

JavaScript en Flash

Bij het bespreken van de webstandaarden heeft u in dit artikel nog niets kunnen lezen over JavaScript en Flash, terwijl dit toch op heel veel pagina's voorkomt. Kunnen JavaScript en Flash wel gebruikt worden op valide pagina's of sites conform webstandaarden?

JavaScript

JavaScript is geen W3C-taal, maar u kunt het wel gebruiken en een valide HTML- of XHTML-pagina schrijven. JavaScript wordt door middel van het script-element in een HTML-pagina opgenomen. Wat er in het script staat wordt niet meegevalideerd wanneer de HTML-pagina gevalideerd wordt. Een valide HTML-pagina kan dus een niet-werkend JavaScript hebben.

JavaScript bevat meer browser-specifieke functies dan de W3C-scriptingtaal ECMA. Er is geen W3C-validator voor JavaScript. Wel bestaan er verschillende debuggers. Omdat JavaScript veel browserspecifieke functies bevat is het goed om de functionaliteit van de pagina's in verschillende browsers te testen.

Er wordt wel gedacht dat de groep mensen zonder JavaScript-ondersteuning erg klein zou zijn, maar van alle internetgebruikers zou 13% geen JavaScript gebruiken (bron: The Counter.com global statistics, mei 2003) gebruiken. Daarnaast zijn er veel mensen die wel gebruik maken van JavaScript maar een pop-up killer gebruiken of een aantal cookies weigeren. Ook komt het steeds vaker voor dat werknemers om veiligheidsredenen geen scriptondersteuning hebben.

JavaScript kan ook gebruikt worden op een toegankelijke pagina, op voorwaarde dat een site of delen van een site niet afhankelijk zijn van JavaScript. Zorg ervoor alle onderdelen van een site ook bruikbaar zijn voor mensen die geen JavaScript kunnen gebruiken.

Flash

Flash is een applicatie die je als een object in een HTML-pagina plaatst, en die alleen gebruikt kan worden met een speciale plug-in. Een pagina kan valideren, maar dat zegt nog niets over de kwaliteit van het Flash-object. Voor de toegankelijkheid geldt dat het Flash-object zelf toegankelijk gemaakt moet worden, omdat Flash niet standaard toegankelijk is.

Alhoewel JavaScript en Flash geen W3C-talen zijn, kunt u ze gewoon gebruiken en toch valide pagina's schrijven. Ze zijn niet 'verboden' of af te raden voor noch een toegankelijke pagina, noch een valide pagina, noch voor een pagina die gebouwd is conform webstandaarden.

Valide code, Webstandaarden en webtoegankelijkheid

Valide websites en webtoegankelijkheid

Websites met louter valide pagina's zijn niet automatisch toegankelijk. Om aan prioriteit 2 van de Richtlijnen voor Toegankelijkheid te voldoen moet er weliswaar valide code gebruikt zijn, maar een valide site voldoet daarmee niet automatisch aan andere ijkpunten van prioriteit 1, 2 of 3.

Ter illustratie van de relatie tussen validiteit en webtoegankelijkheid enkele (fictieve) voorbeelden:

Voorbeeld 1:

De website van de gemeente Klarendom is gebouwd met XHTML. Op deze site is elke afbeelding voorzien van een alt-attribuut. Een alt-attribuut is bedoeld om een tekstuele omschrijving te geven van een afbeelding, zodat de informatie die in de afbeelding gegeven wordt ook toegankelijk is voor mensen die de afbeelding niet kunnen zien. Op deze website is bij elke afbeelding het alt-attribuut 'illustratie'.
De website van de gemeente Klarendom valideert op alle punten. Wanneer er helemaal geen alt-attributen gebruikt zouden zijn zouden de pagina's niet valideren omdat het alt-attribuut verplicht is in XHTML 1.0 De website is echter niet toegankelijk omdat de informatie die in deze afbeeldingen gegeven wordt niet toegankelijk gemaakt is: De website voldoet daarmee niet aan IJkpunt 1.1 van prioriteit 1.

Voorbeeld 2:

Alle pagina's van de site van Tremethe Tractors en de gebruikte style sheet valideren, maar de alineakoppen zijn slechts visueel opgemaakt in CSS. Alhoewel zelfs inhoud en opmaak gescheiden zijn, voldoet deze pagina niet aan de Richtlijnen voor Toegankelijkheid, prioriteit 2. In IJkpunt 3.5 wordt immers gesteld 'Gebruik headerelementen om de documentstructuur over te brengen en gebruik ze volgens de specificatie'.

Voorbeeld 3:

De website van Tekstbureau Tekstquilt is gebouwd met valide HTML 4.01 pagina's. De site voldoet echter niet aan prioriteit 1 van de Richtlijnen voor Toegankelijkheid omdat er geen frametitels zijn gebruikt en omdat de taalwisselingen in de tekst niet zijn aangegeven.

Wanneer een site valide pagina's bevat, wordt de toegankelijkheid wel vergroot doordat de site geen fouten bevat die tot onvoorspelbaarheden kunnen leiden in verschillende browsers, platformen en hulpapparatuur. Ook de interactie met bijvoorbeeld CSS en JavaScript zal beter zijn. Maar daarmee voldoen de pagina's niet automatisch aan prioriteit 1, 2 of 3 van de Richtlijnen voor Toegankelijkheid.

Websites conform webstandaarden en webtoegankelijkheid

Een site die voldoet aan webstandaarden is automatisch een stuk toegankelijker dan een site die 'slechts' valide is, omdat opmaak en presentatie gescheiden zijn en omdat structuurelementen gebruikt zijn om de structuur en betekenis van verschillende onderdelen te onderscheiden.

Toch voldoet zo'n site daarmee niet automatisch aan de ijkpunten voor toegankelijkheid. Ook hier kunnen bijvoorbeeld inadequate tekstuele beschrijvingen gegeven worden, zoals in voorbeeld 1 beschreven is.

Ter illustratie van de relatie tussen het gebruik van webstandaarden en webtoegankelijkheid enkele (fictieve) voorbeelden:

Voorbeeld 4:

De website van het Ministerie van Internet is conform webstandaarden gebouwd. De opmaaktaal is XHTML 1.0 Strict en alle opmaak, inclusief positionering, is vastgelegd in style sheets. De website is echter opgebouwd met absolute eenheden in plaats van relatieve eenheden. Dit houdt in dat de website zelf niet schaalbaar is en dat de teksten op de website niet schaalbaar zijn. De website van het Ministerie van Internet voldoet hiermee niet IJkpunt 3.4 van prioriteit 2: 'Gebruik liever relatieve eenheden dan absolute eenheden als je in markuptalen waarden toekent aan attributen en eigenschappen in style sheets'. Schaalbaarheid is belangrijk zodat gebruikers met verminderd zicht pagina's, en elementen op pagina's, kunnen vergroten of verkleinen.

Voorbeeld 5:

De website van Stichting de Hessenweg heeft een website die conform webstandaarden is. Alle pagina's valideren en alle opmaak is in CSS geregeld. De site voldoet echter niet aan de prioriteit 1 IJkpunten van toegankelijkheid omdat er een groot aantal JavaScript-links is zonder alternatief en de formulieren alleen met JavaScript verstuurd kunnen worden.

Of een site conform webstandaarden gebouwd is, is niet automatisch met een tool te testen. Een goede indicatie is om in een browser de style sheets volledig uit te zetten en een site dan nog eens te bekijken. Zo kan snel zichtbaar worden of opmaak en positioneren met style sheets geregeld is, of met tabellen en in de HTML-code. In het laatste geval is de positionering en / of de opmaak van de pagina waarschijnlijk grotendeels onveranderd.

Conclusie

Valide code en webstandaarden vergroten de toegankelijkheid van een pagina. Sites die conform webstandaarden gebouwd zijn, zijn beter bruikbaar met verschillende browsers, op verschillende platformen en met verschillende hulpapparatuur. Sites die met Webstandaarden gebouwd zijn, hebben ook nog het grote voordeel dat opmaak en presentatie gescheiden zijn en de structuur van de pagina's aangegeven is.

De toegankelijkheid van een site is met valide code of webstandaarden echter nog niet gewaarborgd. Het verbetert de kwaliteit van een website enorm, maar ook andere toegankelijkheidsaspecten zullen nog nader bekeken dienen te worden.

Meer informatie:

Ontwikkelen met web standaarden
Vertaling van een uitgebreid artikel over het door Roger Johansson van 456 Berea Street over het gebruik en de voordelen van webstandaarden.

Op de website van het W3C zijn alle standaarden te vinden.

Doctypes: Lijst van DTD's.