Translation of the Web Guidelines

This page contains a semi-official English translation of the Dutch Webrichtlijnen. Even though it's not yet officially approved, I publish it anyway because I think an unofficial translation is better than none at all now that interest in our Web Guidelines outside the Dutch language area is so large.

The Webrichtlijnen were translated by a company that unfortunately has little knowledge of web development. Therefore I couldn't resist the temptation to edit it here and there. I retranslated 10.1, 13.6 and 18.2. I disagree with 13.18. I added notes to the more dense or obscure guidelines (and most of them are dense and obscure in the original Dutch, too).

tabindex specialists, please take a look at 8.9 and 13.2.

Web Guidelines

Production philosophy

1.1 Keep structure and design separate as much as possible: use HTML or XHTML for the structure of the site and CSS for its design. Propose using 'presentation' instead of 'design' in the formal English translation
1.2 Build websites according to the 'layered construction' principle. 'layered construction' is a translation of Dutch 'gelaagd bouwen', which is a rephrasing of 'progressive enhancement'. Propose using 'progressive enhancement' in the formal English translation
1.3 Do not make the functioning of the website dependent on optional technology, such as CSS and client-side scripting: optional technology should complement the information on the site and its use, and should not interfere with access to it if this technology is not supported.

Building with web standards

2.1 Use HTML 4.01 or XHTML 1.0 according to the W3C specifications for the markup of government websites.
2.2 Do not use any markup which is referred to as deprecated (outmoded) in the W3C specifications.
2.3 When modifying an existing website: only use the Transitional version of HTML 4.01 or XHTML 1.0 if it is not possible or desirable to use the Strict version.
2.4 When building a new website: only use the Strict version of HTML 4.01 or XHTML 1.0.
2.5 Do not use frames on government websites. Therefore, also do not use the Frameset version of HTML 4.01 or XHTML 1.0.
2.6 Use CSS Level-2.1 according to the W3C specification for designing government websites.
2.7 If client-side script is used, use ECMAScript according to the specification. ie. no VBScript
2.8 If elements in the HTML hierarchy are to be manipulated, use the W3C DOM according to the specification. ie. no document.all
2.9 Build a website that conforms to the Web Content Accessibility Guidelines (WCAG 1.0) of the W3C.

Descriptive markup

3.1 Write markup that is both grammatically correct and descriptive.
3.2 Use markup for headings that express the hierarchy of information on the page.
3.3 Do not skip any levels in the headings hierarchy.
3.4 Use the p (paragraph) element to indicate paragraphs. Do not use the br (line break) element to separate paragraphs.
3.5 Use the em (emphasis) and strong elements to indicate emphasis.
3.6 Use the abbr (abbreviation) element for an abbreviation if confusion could arise concerning its meaning, if the abbreviation plays a very important role in the text or if the abbreviation is not listed in the Dutch dictionary.
3.7 Use the dfn (definition) element to indicate terms that are defined elsewhere in a definition list.
3.8 Use the ins (insertion) and del (deletion) elements to indicate regular changes in the content of a page. I don't understand the 'regular'
3.9 Avoid using the sup (superscript) and sub (subscript) element if possible.
3.10 Use the cite element for references to people and titles.
3.11 Avoid using the q (quotation) element. I disagree; the fact that IE doesn't automatically put quotes around a q doesn't mean it's semantically invalid
3.12 Use the blockquote element to indicate (long) quotations.
3.13 Use ol (ordered list) and ul (unordered list) elements to indicate lists.
3.14 Use the dl (definition list), the dt (definition term) and dd (definition data) elements to indicate lists with definitions.
3.15 Give meaningful names to id and class attributes.

Permanent, unique URLs

4.1 Create unique, unchanging URLs.
4.2 Dynamically generated URLs should continue to refer to the same content if content is changed or added.
4.3 Avoid using sessions in URLs.
4.4 Provide redirection to the new location if information has moved.
4.5 Automatic redirection should be done by the server, if possible.
4.6 Use friendly URLs that are readable and recognisable.
4.7 Set up a readable, expandable directory structure.

Open standards

5.1 If important information is provided through a closed standard, the same information should also be provided through an open standard. think Word

Page structure

6.1 Each HTML or XHTML document must begin with a valid doctype declaration.
6.2 Put the content of the page in the HTML source code in order of importance.

Images and alternative text

7.1 The alt (alternative) attribute should be used on every img (image) and area element and should provide an effective alternative text.
7.2 Do not use an alt attribute to display tooltips. Instead, use the title attribute
7.3 Do not use d-links on government websites. Use of the longdesc (long description) attribute is preferred if the alternative text on the alt attribute is inadequate for understanding the information in the image. a d-link seems to be an alternative to a longdesc attribute. Previously I'd never heard of it
7.4 Images placed in a link should have a non-empty alternative text to enable visitors who do not see the image to follow the link.
7.5 When using image maps, indicate an effective alternative text for both the img element and each area element by means of the alt attribute.
7.6 Decorative images should be inserted via CSS as much as possible. Informative images should be inserted via HTML. except for company logos, as far as I'm concerned
7.7 Applying CSS Image Replacement techniques for replacing essential information is not recommended.

Links and navigation

8.1 Do not describe the mechanism behind following a link. no 'click here'
8.2 Write clear, descriptive text for links.
8.3 Use the minimum amount of text that's necessary for an understanding of where the link leads.
8.4 Provide sufficient information on the destination of a link to prevent unpleasant surprises for the visitor.
8.5 When using client-side script in combination with a link: make the script functionality an expansion of the basic functionality of the link.
8.6 When using client-side script in combination with a link: if the link does not lead to anything, do not confront the visitor without support for client-side script with a non-working link. If the link only makes sense when JavaScript is enabled, generate it by JavaScript
8.7 When using client-side script in combination with a link: if necessary, use client-side script as an expansion of server-side functions.
8.8 Links must be easy to distinguish from other text.
8.9 Provide a logical order for the links on the page. Use the tabindex attribute to deviate from the standard tab order for links if this order is inadequate for correct use of the page by keyboard users. Doubting this one. Need advice from a tabindex specialist
8.10 Do not make it impossible to tab to links. Do not remove the focus rectangle surrounding a link or the possibility of focusing on a link.
8.11 Avoid using the accesskey attribute. If it is used nonetheless, only use it on links that remain unchanged throughout the site (e.g. main navigation) and limit the shortcut key combinations to numbers.
8.12 Give blind visitors additional options to skip long lists of links.
8.13 At the top of pages with many topics, provide a page index with links to navigate to the different topics.
8.14 Links on government websites should not automatically open new windows without warning.
8.15 Do not open any new windows automatically, unless the location of the link contains useful information that may be necessary during an important uninterruptible process.
8.16 Links to e-mail addresses: the e-mail address to which the message is addressed must be visible in the link text.
8.17 Links to e-mail addresses: the URL in the href attribute of a link to an e-mail address may only contain the mailto protocol and an e-mail address.
8.18 Do not apply any technical measures to the website to hide an e-mail address from spam robots.
8.19 Be extremely cautious when publishing e-mail addresses of visitors on the website. Inform the visitor which information will be published on the site, or do not publish the visitor's e-mail address.
8.20 When presenting downloadable files, inform the visitor how to download and then use them.
8.21 Serve files with the correct MIME type.
8.22 Do not automatically open links to downloadable files in a new window.
8.23 Do not intentionally serve downloadable files with an unknown or incorrect MIME type to force the browser to do something.

Cascading style sheets

9.1 CSS should be placed in linked files and not mixed with the HTML source code.
9.2 Pages should remain usable if a web browser does not support CSS.

Colour use

10.1 Make sure that communicative elements don't express their meaning only through colour. retranslated
10.2 Be consistent when using colours to indicate meaning.
10.3 Make sure there is sufficient brightness contrast between the text and the background colour.


11.1 Use tables to display relational information and do not use them for layout.
11.2 Use the th (table header) to describe a column or row in a table with relational information.
11.3 Group rows with only th (table header) cells with the thead (table head) element. Group the rest of the table with the tbody (table body) element.
11.4 Use the scope attribute to associate table labels (th cells) with columns or rows.
11.5 Use the header and id elements to associate table labels (th cells) with individual cells in complex tables.
11.6 Provide abbreviations for table labels (th cells) by means of the abbr (abbreviation) attribute if the content of the table label is so long that repetition in a speech browser could cause irritation.
11.7 Use the caption element or heading markup to provide a heading above a table.
11.8 When modifying an existing website: use CSS for the presentation and layout of web pages, and avoid using tables for layout.
11.9 When using tables for layout: do not use more than one table and use CSS for the design of this table as much as possible. a transitional measure, as far as I'm concerned
11.10 When using tables for layout: do not apply any accessibility markup. Means you should use only trs and tds in layout tables, no ths, captions etc.


12.1 Do not use frames on government websites. This applies to regular frames in framesets as well as iframes.


13.1 Use the label element to explicitly associate text with an input field in a form.
13.2 Use the tabindex attribute to deviate from the standard tab order on form fields if this order is inadequate for correct use of the form by keyboard users. Doubting this one. Need advice from a tabindex specialist
13.3 Group input fields by means of the fieldset element.
13.4 Avoid automatic redirection during interaction with forms.
13.5 Do not use client-side script or forms as the only way of accessing information on the site.
13.6 Do not confront users of a browser that does not support optional technologies (such as CSS or client-side script) with a form that does not work. retranslated, but remains an unwieldy guideline. It means that forms should not depend absolutely on JavaScript
13.7 Use CSS sparingly on input fields and form buttons.
13.8 If a visitor has to provide personal data, let him know what will be done with this data, e.g. in the form of a privacy statement.
13.9 Do not ask a visitor to provide more information by means of a form than necessary for the purpose of the form. Keep forms as short as possible and limit the mandatory completion of form fields.
13.10 Indicate which fields are mandatory and which are optional.
13.11 Provide alternative contact options, such as address details, telephone number or e-mail addresses, if available.
13.12 Let the visitor know what will be done with the form when it is sent.
13.13 Give the visitor the option of saving his reply.
13.14 Once the visitor has completed and sent the form, send him confirmation that his message has been received by the recipient (autoreply).
13.15 Before displaying complex forms, give the visitor an impression of the size of the form.
13.16 List documents which the visitor might need while completing the form beforehand.
13.17 Provide forms with instructions for the visitor if necessary, particularly for the applicable input fields.
13.18 Do not add any reset buttons to forms. Disagree. Should read "Use reset buttons only if the form initially contains data."

Client side scripting and DOM

14.1 Do not use client-side script for essential functionality on web pages, unless any lack of support for these scripts is sufficiently compensated by HTML alternatives and/or server-side script.


15.1 The visitor should have the option of choosing between languages on every page of the site. (Dutch websites commonly have an English version, too
15.2 Links for language choice should have a clear and consistent place in the navigation of the site.
15.3 Use fully written out (textual) links to the language versions.
15.4 Write links to language versions in their corresponding languages.
15.5 Do not use associations with nationalities for language choice.
15.6 Specify the base language of a page in the markup.
15.7 Indicate language variations in the content of pages in the markup.

Character encoding

16.1 Specify the character set for web pages.
16.2 Specify the UTF-8 character set.
16.3 Also specify the character set by means of HTTP headers, if possible.
16.4 Use (at minimum) the meta element to specify the character set and place this element as high as possible in the head section of the markup.

Search engine optimization

18.1 Use a unique, descriptive title for each page.
18.2 Add a short, concise text that explains the main content to the top of the page. retranslated; it means: use an introduction paragraph such as the ones I've used on this site from time immemorial

Contingency design

22.1 Use language that the visitor understands: limit the use of jargon, difficult terms and abbreviations. As far as I'm concerned this guideline does not apply to specialist sites
22.2 Give visitors an 'escape route': possibilities to continue if they get stuck. Escape routes include useful links, being able to use the back button, a search function, and being able to correct input errors immediately.
22.3 Don't make visitors guess: provide information on how they can correct errors they have made. Take into account the most common errors.
22.4 Create modified error pages for errors such as dead links (404 Not Found) where the visitor is given options for continuing within the site. I think 'modified' means 'created specially', but the word remains a bit obscure even in the Dutch original
22.5 In the event of an error message as a result of sending a form, give the visitor the option of correcting the error in the form immediately and don't make him be dependent on the use of the back button.
22.6 When implementing a search engine on the website: use 'smart' search technology that takes into account spelling errors, similar search terms, terms in singular or plural form, etc.
22.7 Provide a well-organised list of the most relevant search results. If too many search results are provided, it takes visitors too long to find the desired information. Give visitors the option of entering search criteria, or sorting the search results.
22.8 Give visitors the option of reporting errors on the site.
22.9 Use colours, icons and textual explanations to draw the visitor's attention to an error message and explain the problem.
22.10 Give visitors the option of finding information in alternative ways. For example, by providing a sitemap, search functions, or by means of a request by e-mail, letter or telephone.