Голландия
Guidelines Description
R-pd.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.
R-pd.1.2 Build websites according to the ‘layered construction’ principle.
R-pd.1.3 Do not make the function of the website dependent on optional technology, such as CSS and client-side script: 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.
R-pd.2.1 Use HTML 4.01 or XHTML 1.0 according to the W3C specifications for the markup of websites.
R-pd.2.2 Do not use any markup which is referred to as deprecated (outmoded) in the W3C specifications.
R-pd.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.
R-pd.2.4 When building a new website: only use the Strict version of HTML 4.01 or XHTML 1.0.
R-pd.2.5 Do not use frames on websites. Therefore, also do not use the Frameset version of HTML 4.01 or XHTML 1.0.
R-pd.2.6 Use CSS Level-2.1 according to the W3C specification for designing websites.
R-pd.2.7 If client-side script is used, use ECMAScript according to the specification.
R-pd.2.8 If elements in the HTML hierarchy are to be manipulated, use the W3C DOM according to the specification.
R-pd.2.9 Build a website according to the Web Content Accessibility Guidelines (WCAG 1.0) of the W3C.
R-pd.3.1 Write both grammatically correct and descriptive markup.
R-pd.3.2 Use markup for headings that express the hierarchy of information on the page.
R-pd.3.3 Do not skip any levels in the hierarchy of headings in the markup.
R-pd.3.4 Use the p (paragraph) element to indicate paragraphs. Do not use the br (linebreak) element to separate paragraphs.
R-pd.3.5 Use the em (emphasis) and strong elements to indicate emphasis.
R-pd.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.
R-pd.3.7 Use the dfn (definition) element to indicate terms that are defined elsewhere in a definition list.
R-pd.3.8 Use the ins (insertion) and del (deletion) elements to indicate regular changes in the content of a page.
R-pd.3.9 Avoid using the sup (superscript) and sub (subscript) element if possible.
R-pd.3.10 Use the cite element for references to people and titles.
R-pd.3.11 Avoid using the q (quotation) element.
R-pd.3.12 Use the blockquote element to indicate (long) quotations.
R-pd.3.13 Use ol (ordered list) and ul (unordered list) elements to indicate lists.
R-pd.3.14 Use the dl (definition list), the dt (definition term) and dd (definition data) elements to indicate lists with definitions.
R-pd.3.15 Give meaningful names to id and class attributes.
R-pd.4.1 Create unique, unchanging URLs.
R-pd.4.2 Dynamically generated URLs should continue to refer to the same content if content is changed or added.
R-pd.4.3 Avoid using sessions in URLs.
R-pd.4.4 Provide redirection to the new location if information is moved.
R-pd.4.5 Automatic redirection should be carried by the server if possible.
R-pd.4.6 Use friendly URLs that are readable and recognisable.
R-pd.4.7 Set up a readable, expandable directory structure.
R-pd.5.1 In the event that important information is provided through a closed standard, the same information should also be provided through an open standard.
R-pd.6.1 Each HTML or XHTML document must begin with a valid doctype declaration.
R-pd.6.2 Put the content of the page in the HTML source code in order of importance.
R-pd.7.1 The alt (alternative) attribute should be used on every img (image) and area element and should be provided with an effective alternative text.
R-pd.7.2 Do not use an alt attribute to display tooltips.
R-pd.7.3 Do not use d-links on websites. Use of the longdesc (long description) attribute is preferred if the text alternative on the alt attribute is inadequate for understanding the information in the image.
R-pd.7.4 Images placed in a link should have a non-empty text alternative to enable visitors who do not see the image to follow the link.
R-pd.7.5 When using image maps, indicate an effective text alternative for both the img element and each area element by means of the alt attribute.
R-pd.7.6 Decorative images should be inserted via CSS as much as possible. Informative images should be inserted via HTML.
R-pd.7.7 Applying CSS Image Replacement techniques to essential information is not recommended.
R-pd.8.1 Do not describe the mechanism behind following a link.
R-pd.8.2 Write clear, descriptive text for links.
R-pd.8.3 Use the minimum amount of text needed to understand where the link leads.
R-pd.8.4 Provide sufficient information on the destination of a link to prevent unpleasant surprises for the visitor.
R-pd.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.
R-pd.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.
R-pd.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.
R-pd.8.8 Links must be easy to distinguish from other text.
R-pd.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.
R-pd.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.
R-pd.8.11 Avoid using the Access key attribute. If the decision is nevertheless made to apply this attribute, only use it on links that remain unchanged throughout the site (e.g. main navigation) and limit the shortcut key combinations to numbers.
R-pd.8.12 Give blind visitors additional options to skip long lists of links.
R-pd.8.13 At the top of pages with many topics, provide a page index with links to navigate to the different topics.
R-pd.8.14 Links on websites should not automatically open new windows without warning.
R-pd.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.
R-pd.8.16 Links to e-mail addresses: the e-mail address to which the message is addressed must be visible in the link text.
R-pd.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.
R-pd.8.18 Do not apply any technical measures to the website to hide an e-mail address from spam robots.
R-pd.8.19 Be extremely cautious when publishing e-mail addresses of visitors to the website. Inform the visitor of which information will be published on the site, or do not publish the visitor's e-mail address.
R-pd.8.20 When presenting downloadable files, inform the visitor how to download and then use them.
R-pd.8.21 Serve files with the correct MIME type.
R-pd.8.22 Do not automatically open links to downloadable files in a new window.
R-pd.8.23 Do not intentionally serve downloadable files with an unknown or incorrect MIME type to force the browser to do something.
R-pd.9.1 CSS should be placed in linked files and not mixed with the HTML source code.
R-pd.9.2 Pages should remain usable if a web browser does not support CSS.
R-pd.10.1 Make sure that the meaning of communicative elements is not expressed only through colour.
R-pd.10.2 Be consistent with colour use when indicating meaning.
R-pd.10.3 Make sure there is sufficient brightness contrast between the text and the background colour.
R-pd.11.1 Use tables to display relational information and do not use them for layout.
R-pd.11.2 Use the th (table header) to describe a column or row in 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 table labels (th cells) with columns or rows.
R-pd.11.5 Use the headers and id attributes to associate table labels (th cells) with individual cells in complex tables.
R-pd.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.
R-pd.11.7 Use the caption element or heading markup to provide a heading above a table.
R-pd.11.8 When modifying an existing website: use CSS for the presentation and layout of web pages, and avoid using tables for layout.
R-pd.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.
R-pd.11.10 When using tables for layout: do not apply any accessibility markup.
R-pd.12.1 Do not use frames on websites. This applies to regular frames in framesets as well as iframes.
R-pd.13.1 Use the label element to explicitly associate text with an input field in a form.
R-pd.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.
R-pd.13.3 Apply grouping of input fields by means of the fieldset element.
R-pd.13.4 Avoid automatic redirection during interaction with forms.
R-pd.13.5 Do not use client-side script or forms as the only way of accessing information on the site.
R-pd.13.6 Do not confront a visitor with a non-working form if optional technologies – such as CSS or client-side script – are not supported by the browser.
R-pd.13.7 Use CSS sparingly for input fields and form buttons.
R-pd.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.
R-pd.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.
R-pd.13.10 Indicate which fields are mandatory and which are optional.
R-pd.13.11 Provide alternate contact options, such as address details, telephone number or e-mail addresses, if available.
R-pd.13.12 Let the visitor know what will be done with the form when it is sent.
R-pd.13.13 Give the visitor the option of saving his reply.
R-pd.13.14 Once the visitor has completed and sent the form, send him confirmation that his message has been received by the recipient (autoreply).
R-pd.13.15 Before displaying complex forms, give the visitor an impression of the size of the form.
R-pd.13.16 List documents which the visitor might need while completing the form beforehand.
R-pd.13.17 Provide forms with instructions for the visitor if necessary, particularly for the applicable input fields.
R-pd.13.18 Do not add any reset buttons to forms.
R-pd.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.
R-pd.15.1 The visitor should have the option of choosing between languages on every page of the site.
R-pd.15.2 Links for language choice should have a clear and consistent place in the navigation of the site.
R-pd.15.3 Use fully written out (textual) links to the language versions.
R-pd.15.4 Write links to language versions in their corresponding languages.
R-pd.15.5 Do not use associations with nationalities for language choice.
R-pd.15.6 Specify the base language of a page in the markup.
R-pd.15.7 Indicate language variations in the content of pages in the markup.
R-pd.16.1 Specify the character set for web pages.
R-pd.16.2 Specify the UTF-8 character set.
R-pd.16.3 Also specify the character set by means of HTTP headers, if possible.
R-pd.16.4 Use (at least) the meta element to specify the character set and place this element as high as possible in the head section of the markup.
R-pd.18.1 Use a unique, descriptive title for each page.
R-pd.18.2 Write short, concise text, in which the main message is mentioned at the top of the page.
R-pd.22.1 Use language that the visitor understands: limit the use of jargon, difficult terms and abbreviations.
R-pd.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.
R-pd.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.
R-pd.22.4 Make modified error pages – for errors such as dead links (404 Not Found) – where the visitor is given options for continuing within the site.
R-pd.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.
R-pd.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.
R-pd.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.
R-pd.22.8 Give visitors the option of reporting errors on the site.
R-pd.22.9 Use colours, icons and textual explanations to draw the visitor's attention to an error message and explain the problem.
R-pd.22.10 Give visitors the option of finding information in alternate ways. For example, by providing a sitemap, search functions, or by means of a request by e-mail, letter or telephone.
|
|
