I've remove the introduction text (i.e. political mambo jambo). That even I can't read :-)
The minister concerned takes care that websites of the government meet the webguidelines, as noted in the appendix attached to this decree.
This arrangement will, with explanation, be put in the Staatscourant.
The Ministry of the Interior and Kingdomrelations,
| Guideline | Description |
|---|---|
| R-pd.1.1 | Keep structure and presentation separated as much as possible: Use HTML or XHTML for the structure of the site and CSS for the presentation of it. |
| R-pd.1.2 | Build websites to the principle of layered building(layers of separation). |
| R-pd.1.3 | Don't make the function of the website dependable on optional technology, like CSS and client-side script: optional technology is there to complement the information on the site and the use of it. Not restrict access to it when this technology isn't supported. |
| R-pd.2.1 | Use HTML 4.01 or XHTML 1.0 in accordance with W3C specification for the markup of governmentwebsites. |
| R-pd.2.2 | Don't use markup that in the W3C specifications is marked as deprecated. |
| R-pd.2.3 | When changing an existing website: Of HTML 4.01 or XHTML 1.0 only use the Transitional variant when the use of the Strict variant is impossible or undesirable. |
| R-pd.2.4 | When building a new website: Of HTML 4.01 or XHTML 1.0 use the Strict variant. |
| R-pd.2.5 | Don't use frames on governmentwebsites. Therefore don't use the Frameset variant of HTML 4.01 or XHTML 1.0. |
| R-pd.2.6 | Use CSS Level-2.1 in accordance with the W3C specification to design governmentwebsites. |
| R-pd.2.7 | When using client-side script, use ECMAScript in accordance with the specification. |
| R-pd.2.8 | When manipulating elements in the HTML hierarchy, use W3C DOM in accordance with the specification. |
| R-pd.2.9 | Build websites in accordance with Web Content Accessibility Guidelines (WCAG 1.0) of the W3C. |
| R-pd.3.1 | Write grammatically correct and descriptive markup. |
| R-pd.3.2 | Use markup for headers that express the hierarchy of the information on the page. |
| R-pd.3.3 | In the markup, don't skip levels in the hierarchy of headers. |
| R-pd.3.4 | Use the p (paragraph) element for the indication of paragraphs. Don't use the br (linebreak) element to separate paragraphs. |
| R-pd.3.5 | Use the em (emphasis) and strong element to indicate emphasis. |
| R-pd.3.6 | Use the abbr (abbreviation) element for abbrevations when there could be uncertainty about its meaning, the abbrevation takes a large part in the text or when the abbrevation isn't present in the (Dutch) dictionary. |
| R-pd.3.7 | Use the dfn (definition) element to indicate definitions, that are defined somewhere else in a definitionlist. |
| R-pd.3.8 | Use the ins (insertion) and del (deletion) element to indicate frequent alterations in the content of a page. |
| R-pd.3.9 | Avoid the use of the sup (superscript) and sub (subscript) element whenever possible. |
| R-pd.3.10 | Use the cite element for references to people and titles. |
| R-pd.3.11 | Avoid the use of the q (quotation) element. |
| R-pd.3.12 | Use the blockquote element to indicate (long) citations. |
| R-pd.3.13 | Use ol (ordered list) en ul (unordered list) elements to indicate lists. |
| R-pd.3.14 | Use the dl (definition list), the dt (definition term) and dd (definition data) element to indicate a list of definitions. |
| R-pd.3.15 | Give meaningful names to id and class attributes. |
| R-pd.4.1 | Produce unique, unchanging URL's |
| R-pd.4.2 | Dynamically generated URL's should still point to the same content when content is changed or added. |
| R-pd.4.3 | Avoid the use of sessions in URL's. |
| R-pd.4.4 | Take care of redirection to the new location when moving information. |
| R-pd.4.5 | Automatic redirection should, when possible, be done by the server. |
| R-pd.4.6 | Use friendly URL's, that are readable and recognizable. |
| R-pd.4.7 | Create a readable and extendable directory-structure. |
| R-pd.5.1 | When important information is offered in a closed standard, one should also provide the same information via an open standard. |
| R-pd.6.1 | Every HTML or XHTML document has to start with a valid doctype declaration. |
| R-pd.6.2 | Put the content of the page in the HTML sourcecode in the order of importance. |
| R-pd.7.1 | The alt (alternative) attribute has to be used on every img (image) and area element and should contain an effective alternative text. |
| R-pd.7.2 | Don't use an alt attribute to create tooltips. |
| R-pd.7.3 | Don't use d-links on governmentwebsites. Use of the longdesc (long description) attribute is preferred when alternative text in the alt attribute is insufficient for the conception of the information in the image. |
| R-pd.7.4 | Images that are placed inside a link have to have a non-empty alternative text, to enable visitors that can't view images to follow links. |
| R-pd.7.5 | When using image maps provide the img element as well as every area element with an effective alternative text via the alt attribute. |
| R-pd.7.6 | Decorative images should as much as possible be added using CSS. Informative images have to be added using HTML. |
| R-pd.7.7 | The use of CSS Image Replacement techniques on essential information is not recommended. |
| R-pd.8.1 | Don't describe the mechanism behind following a link. |
| R-pd.8.2 | Write clear, descriptive text for links. |
| R-pd.8.3 | Use the minimal amount of text that is needed to understand where the link is going to. |
| R-pd.8.4 | Give enough information about the destination of a link to prevent unpleasant surprises for the visitors. |
| R-pd.8.5 | When using client-side scripting in combination with a link: make the scriptfunctionality an extension on the basic functionality of the link. |
| R-pd.8.6 | When using client-side scripting in combination with a link: when a link isn't going anywhere, don't make visitors without client-side scripting support face a none-working link. |
| R-pd.8.7 | When using client-side scripting in combination with a link: if necessary use client-side scripting as an extension of server-side functionality. |
| R-pd.8.8 | Links have to be clearly distinctive from other text. |
| R-pd.8.9 | Make sure there is a logical order in the links of the page. Use the tabindex attribute to deviate from the standard taborder of links when this order isn't sufficient for correct use of the page by keybordusers. |
| R-pd.8.10 | Don't make tabbing through links impossible. Don't remove the focus rectangle around links or the possibility to focus on a link. |
| R-pd.8.11 | Use the accesskey attribute as little as possible. When it's decided to use the attribute after all, only use it on links that are the same on the entire site (for example the mainnavigation) and limit the keycombinations to numbers. |
| R-pd.8.12 | Give blind visitors the extra abilities to skip large lists of links. |
| R-pd.8.13 | At the top of a page with a lot of subjects add a page-index with links to navigate to the different subjects. |
| R-pd.8.14 | Links on governmentwebsites shouldn't, without warning, automatically open new windows. |
| R-pd.8.15 | Don't automatically open new windows, except when the location of the link contains useful information that might be necessary during an important, uninterruptible proces. |
| R-pd.8.16 | Links to e-mail addresses: the e-mail address should be visible in the linktext. |
| R-pd.8.17 | Links to e-mail addresses: de URL in the href attribute of a link to an e-mail address, may only contain the mailto protocol and an e-mail address. |
| R-pd.8.18 | Don't apply any technical measures to the website to disguise an e-mail address for spam robots. |
| R-pd.8.19 | Be extremely careful when it comes to publishing e-mail addresses of visitors of the website. Inform the visitors about which data is published on the site, or don't publish the e-mail address of the visitor. |
| R-pd.8.20 | When offering downloadable files, inform the visitor how to download these and after that how to use them. |
| R-pd.8.21 | Serve files with the correct MIME type. |
| R-pd.8.22 | Don't automatically open links to downloadable files in a new window. |
| R-pd.8.23 | Don't, on purpose, serve downloadable files with an unknown or incorrect MIME type to force specific behavior of the browser. |
| R-pd.9.1 | CSS has to be put in linked files and not mixed with the HTML sourcecode. |
| R-pd.9.2 | Pages should still be usable when CSS isn't supported by a webbrowser. |
| R-pd.10.1 | Make sure that communicative elements don't convey their meaning by color only. |
| R-pd.10.2 | Be consistent with the use of color when given meaning. |
| R-pd.10.3 | Make sure there is enough contrast between text- and backgroundcolor. |
| R-pd.11.1 | Use tables to display relational information, not for layout. |
| R-pd.11.2 | Use the th (table header) element to describe a column of row inside a table with relational information. |
| R-pd.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. |
| R-pd.11.4 | Use the scope attribute to associate tablelabels (th cells) with columns or rows. |
| R-pd.11.5 | Use the header and id element to associate tablelabels (th cells) with individual cells in complex tables. |
| R-pd.11.6 | Give abbreviations to tablelabels (th cells) via the abbr (abbreviation) attribute when the length of the content of the tablelabel is of such length that repetition in a speech browser could create irritation. |
| R-pd.11.7 | Use the caption element or heading markup to add a header above the table. |
| R-pd.11.8 | When changing an existing website: use CSS for the presentation and layout van webpages en quit using tables for layout. |
| R-pd.11.9 | When using tables for layout: use no more than one table and use CSS as much as possible for laying out this table. |
| R-pd.11.10 | When using tables for layout: don't apply any accessibility markup. |
| R-pd.12.1 | Don't use frames on governmentwebsites. This applies to regular frames inside a framesets, as well as so called iframes. |
| R-pd.13.1 | Use the label element to explicitly associate text to an inputfield in a form. |
| R-pd.13.2 | Use the tabindex attribute to deviate from the default tab-order of formfields when this order isn't sufficient for correct use of the form by keybordusers. |
| R-pd.13.3 | Group inputfields by using the fieldset element. |
| R-pd.13.4 | Avoid automatic referral on interactive forms. |
| R-pd.13.5 | Don't use client-side scripting or forms as the only way to reach information on the site. |
| R-pd.13.6 | Don't show visitors unusable forms when optional technology - like CSS or client-side scripting - isn't supported by the browser. |
| R-pd.13.7 | Be reticent with the use of CSS on inputfields and formbuttons. |
| R-pd.13.8 | When a visitor has to give personal data, let him know what will be done with this data, for example in the form of a privacy statement. |
| R-pd.13.9 | Don't make visitors give more information than needed for the purpose of the form. Keep forms as short as possible and limit required formfields. |
| R-pd.13.10 | Indicate which fields are required or optional to fill in. |
| R-pd.13.11 | Supply alternative contactpossibilities, like addresses, phonenumbers or e-mail addresses, if these are available. |
| R-pd.13.12 | Let visitors know what will be done with the form after sending. |
| R-pd.13.13 | Give visitors the possibility to archive their reaction. |
| R-pd.13.14 | After the visitor has filled in and submitted the form, send him a confirmation that his message has arrived at the receiver (autoreply). |
| R-pd.13.15 | At the beginning of complex forms, give the visitor an indication of how big the form is. |
| R-pd.13.16 | Tell in advances which documents the visitor (possibly) needs when filling out the form. |
| R-pd.13.17 | Add instructions for the visitor to the form where needed. |
| R-pd.13.18 | Don't add reset buttons to a form. |
| R-pd.14.1 | Don't use client-side scripting crucial functionality on webpages, unless the lack of support for these scripts are sufficiently complemented by HTML alternatives and/of server-side scripting. |
| R-pd.15.1 | The possibility to choose a language should be available to the visitor on every page in the site. |
| R-pd.15.2 | Links to languageoptions should be on a clear and consistent location in the navigation of the site. |
| R-pd.15.3 | Use written in full (textual) links to the languageoptions. |
| R-pd.15.4 | Write links to languageoptions in their corresponding language. |
| R-pd.15.5 | Don't use associations with nationalities for languagechoice. |
| R-pd.15.6 | Specify the baselanguage of the page inside the markup. |
| R-pd.15.7 | Indicate languagevariations in the content of the pages in the markup. |
| R-pd.16.1 | Specify the characterset for webpages. |
| R-pd.16.2 | Specify the UTF-8 characterset. |
| R-pd.16.3 | Also specify the characterset through the HTTP headers, when possible. |
| R-pd.16.4 | Use (at least) the meta element to specify the characterset and put this element and put this element as high as possible in the head section of the markup. |
| R-pd.18.1 | On every page use an unique, descriptive title. |
| R-pd.18.2 | Write short, concise text, in which the most important message is already mentioned at the top of the page. |
| R-pd.22.1 | Use language that the visitor understands: limit the use of jargon, difficult terms end abbreviations. |
| R-pd.22.2 | Give visitors an escaperoute: possibilities to continue when they get stuck. Escaperoutes are useful links, the possibility to use of the back button, a searchfunction, or being able to immediately correct inputerror. |
| R-pd.22.3 | Don't make visitors guess: give information about how to correct a error that is made. Take common errors into account. |
| R-pd.22.4 | Make custom errorpages - for errors like dead links (404 Not Found) - where visitors are presented with options to resume their way within the site. |
| R-pd.22.5 | When reporting an error as a result of sending a form, give the visitor the option to immediately correct the error in the form and don't let him be dependant on the use of the back button. |
| R-pd.22.6 | When implementing a searchengine on the website: use smart searchtechnology that takes into account for example spellingerrors, similar searchterms, and terms in plural and singular. |
| R-pd.22.7 | Give a clear list of the most relevant searchresults. To many searchresults cost visitors to much time to find the wanted information. Give visitors the possibilities to set searchcriteria, or sort searchresults. |
| R-pd.22.8 | Give visitors the possibility to report errors on the site. |
| R-pd.22.9 | Use color, icons and textual explanation to attract the visitor's attention to an errormessage and to clarify the problem. |
| R-pd.22.10 | Give visitors the options to find information in alternative ways. For example by offering a sitemap, searchfunctionalities, or via a request by e-mail, letter of phone. |
For the publication of information on the internet there have been made international guidelines lately by the World Wide Web Consortium (W3C). These guidelines concern amongst others the construction of the website, the technical shaping of the website and the way content is attached to the website. Because application of these guidelines proved to be difficult in practice, the Ministry of the Interior and Kingdomrelations, together with the Voorlichtingsraad, commissioned the developement of so called webguidelines. Webguidelines are an umbrellastandard include the most important specifications for the webinterface and the describe the relationshup between these specifications. Websites build according to these webguidelines sattisfy the demands for accessibility for people with disabilities (as worked out the the Waarmerk drempelvrij.nl), are accessible bij all common searchenginetechnologies and are, because of their structured build, easier and cheaper to maintain. These webguidelines are also an instrument for good commissionship.
...I haven't don the rest yet, sorry...Dit voorschrift geldt voor de Rijksdienst waartoe
gerekend worden de ministeries met daaronder de ressorterende diensten,
bedrijven en instellingen. De minister is verantwoordelijk voor de
websites die onder zijn ministeriële verantwoordelijkheid vallen. De
ministeries zijn zelf verantwoordelijk voor het aantonen van de
conformiteit aan de webrichtlijnen. Om te controleren of een website
voldoet aan de eisen voor toegankelijkheid en bouwkwaliteit zijn twee
elkaar aanvullende onderzoeken nodig. Een toetsing conform de normen van
het Waarmerk drempelvrij.nl, een handmatig onderzoek, dekt het aspect
toegankelijkheid af. De Webrichtlijnentoets (http://webrichtlijnen.overheid.nl/toets/),
een geautomatiseerde meting, het aspect bouwkwaliteit. De combinatie van
beide toetsingsinstrumenten geeft een betrouwbaar beeld van de mate waarin
een website aan de Webrichtlijnen voldoet.
Het uitgebreidere
overzicht van specificaties, richtlijnen en de handleiding staat op de
website: http://webrichtlijnen.overheid.nl/.
Nieuwe websites van de rijksoverheid moeten vanaf 1
september 2006 bij oplevering voldoen aan de webrichtlijnen. Nieuwe
websites mogen uitsluitend worden opengesteld voor gebruikers nadat door
het verantwoordelijke ministerie is vastgesteld dat gebouwd is conform de
Webrichtlijnen.
Bestaande websites van de rijksoverheid, voor zover
deze nog niet voldoen aan de webrichtlijnen, zullen vanaf 1 september zo
spoedig mogelijk binnen de normale vernieuwingscyclus van de websites doch
uiterlijk 31-12-2010 moeten worden aangepast aan de webrichtlijnen. Door
de aanpassing van de websites te koppelen aan vernieuwing of een nieuwe
versie van de website, in combinatie met een juiste toepassing van de
webrichtlijnen, kan de aanpassing zonder extra financiële inspanning
worden gerealiseerd.
De Minister van Binnenlandse Zaken en Koninkrijksrelaties,
This is a translation of a dutch
decree about web-accessibility. Read some opinions about this new law
at 456bereastreet
or at quirksmode.
Please know that this isn't an official
translation. My English isn't that good, so there could be some errors. I
also tried to stay true to the original text as much as possible, so
sentences might sound a bit weird.
Since it's a government piece I don't think there are any copyright concerns. If not let me know and I'll remove it.