Skip to content.
|Networking government in New Zealand.
You are here: Home » Standards » Web Standards » Web Standards (Draft v3) » Standards and Recommendations

Standards and Recommendations

Interpretation

The following defines the key terms used throughout the NZ Government Web Standards and Recommendations:

Standard

Description

Requirements of an agency which are objectively testable and which agencies Must comply with. No exceptions are anticipated.

Agencies web sites will be checked against these standards when audits for compliance are undertaken. It is the responsibility of each agency to address and bring into compliance any non-compliant standards found during the audit.

Recommended item

Description

Items that would be Standards, however for one or more reasons (principally being too wide in scope or containing a degree of subjectivity), cannot fairly be mandated as Standards. Nonetheless, they are considered high importance and agencies are expected to comply with them.

Agencies web sites will be checked against these items when audits for compliance are undertaken. Any such items that agencies are found to be not compliant will need to provide good reason as to why they are not compliant.

Good practice

Description

Examples from other organisations that have complied successfully with a particular standard or how they approached a particular problem.

Links to other websites that have information relevant to a particular standard or recommended item.

NZ government agency web site Standards

The following standards are a combination of:

  • Those devised specifically for NZ government web sites.
  • Accessibility standards which are derived from the W3C Web Accessibility Initiative (WAI) standards checklist. In many cases they have been re-worded and/or further qualified for NZ Govt agency web site requirements. Each standard has the founding WAI standard(s) in the associated rationale.

The W3C WAI standards can be found at http://www.w3.org/TR/WCAG10-HTML-TECHS/

V3.0 draft standards are based on the W3C WAI 1.0 recommendations. WCAG 1.0 was approved in May 1999. WCAG 2.0 documents are still being developed, they are documented in Requirements for WCAG 2.0.

Refer to:

Images

(Ref a)

Standard

Provide a text equivalent for every non-text element (for example "alt", "longdesc", or in element content). This includes: images, graphical representations of text (including symbols), image map regions, animations (for example, animated GIFs), applets and programmatic objects, ASCII art, frames, scripts, images used as list bullets, spacers, graphical buttons, sounds (played with or without user interaction), stand-alone audio files, audio tracks of video, and video.

Guideline

A null Alt equivalent ("") is required for layout elements e.g spacer graphics.

For images

  • Include in each <area> of an image MAP, and INPUT elements of type="image",
  • Alt text for the case where the image is displaying text should be the same as the text in the image.

Compliance assistance

"Bobby" is an automated testing tool, which can tell you if images on a web page have Alt text associated with them. Refer to http://www.cast.org/bobby.

Further Assistance

6.4.5f - Text that must be in a particular font, say, for reasons of branding, uses an image and provides the same as alt text

6.4.6m - Aim to contain the alt text to within 100 characters.

Rationale

Supports the NZ Govt Public Service value of Equity.

Users with visual impairments may have difficulty with content other than text. Screen readers will make use of the alt-text provided for non-text items.

Relates to WAI 1.1

For further detail, see

W3C http://www.w3.org/WAI/wcag-curric/gid2-0.htm

Irish National Disability Authority http://accessit.nda.ie/guideline_1_35.html#rationale

Good practice

The W3C provides 'how-to' tips for supporting and implementing text equivalents for all major web object types.

http://www.w3.org/WAI/wcag-curric/chk2-0.htm. Please note that Frames and ASCII art are not to be used on government agency web sites.

http://www.w3.org/TR/WCAG10-HTML-TECHS/#image-text-equivalent

University of Wisconsin provides some very good assistance on accessible images

http://www.doit.wisc.edu/accessibility/online-course/standards/images.htm

Wikipedia

http://en.wikipedia.org/wiki/Wikipedia:Alternative_text_for_images

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_35.html#directions

Images

(Ref g)

Standard

Client side image maps are preferred over server side image maps. You must also provide redundant text links for each active region of any image map, and locate the links as close as possible to the image map they relate to.

Guideline

Use the HTML A element as recommended by the W3C.

Technical Assistance Guide

Client side image maps are preferred over server side however

if server-side image maps must be used then

offer a text alternative to the server side map regions, or "hotpoints", at an appropriate place on the form (such as the form footer).

The text alternative must have a mechanism to be able to be navigated to and selected without a mouse or equivalent device (i.e. able to be tabbed to and selected).

Use the HTML alt text to enable this link i.e.

<img src="../images/header_nav.gif" alt="SSC Main Menu (links of this image map are available at the bottom of the page" ismap>

If use client-side image maps are used then

ensure there is an alt text i.e.

<area shape="rect" coords="9,6,79,68" href="http://www.ssc.govt.nz " alt="SSC Website"/>

See http://www.doit.wisc.edu/accessibility/online-course/standards/navigation.htm

Further Assistance

6.4.4h - Image map navigation

Rationale

Supports the NZ Govt Public Service value of Equity.

Server-side image maps do not provide adequate support for alt text nor for conventional pointing devices (i.e. a mouse).

People with cognitive or visual disabilities and/or those who do not have a "pointing device" (i.e. mouse) may require alternative methods for navigating and selecting their choices available on the site.

Derived from W3C WAI 1.2 Pty 1 & 1.5 Pty 3

For further detail, see

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_51.html#rationale and http://accessit.nda.ie/guideline_1_97.html#rationale

University of Wisconsin

http://www.doit.wisc.edu/accessibility/online-course/standards/navigation.htm#explanationssimg

Resources

W3C 'how-to' tips at http://www.w3.org/WAI/wcag-curric/sam6-0.htm

W3C discussion and tips on client side image maps

http://www.w3.org/TR/html4/struct/objects.html#h-13.6.1.1

http://www.w3.org/TR/html4/struct/objects.html#h-13.6.2

http://www.w3.org/TR/WCAG10-HTML-TECHS/#client-side-redundant-text

and

http://www.w3.org/WAI/wcag-curric/sam24-0.htm

Video

(Ref l)

Standard

Until user agents can automatically read aloud the text equivalent of a visual track, you must provide a text description [that can then be read] of the important information of the visual track of a multimedia presentation.

For any time-based multimedia presentation (e.g. a movie or animation), synchronize equivalent alternatives (e.g. captions or auditory descriptions of the visual track) with the presentation.

Guideline

Provide

  • A text equivalent or alternative.
  • An audio track to accompany a multimedia presentation, which describes important information presented in the visual track.
  • Ensure that the text and/or audio track is synchronised with the presentation.

For further details

W3C http://www.w3.org/WAI/wcag-curric/sam21-0.htm and http://www.w3.org/WAI/wcag-curric/sam22-0.htm

Rationale

There is a two fold purpose for this standard.

If information is provided primarily in multimedia clips ie, scenery, charts etc. then the conveyance of the information will be lost to users with visual impairments.

Having a written description (as opposed to recorded description) enables the text to be indexed and searched which (at the time of writing) is extremely difficult with information contained within a multimedia clip.

Relates to WAI 1.3 (1.4) Pty 1

For further detail, see

W3C http://www.w3.org/WAI/wcag-curric/sam20-0.htm

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_56.html#rationale

University of Wisconsin

http://www.doit.wisc.edu/accessibility/online-course/standards/multimedia.htm

and also provides a video clip demonstrating a screen reader encountering images without alt-text http://accessit.nda.ie/guideline_1_48.html#rationale

Note: This video requires the QuickTime player.

Good practice

The W3C provides 'how-to' tips for supporting and implementing this standard for common (at the time of writing) multimedia formats

http://www.w3.org/WAI/wcag-curric/sam21-0.htm

WebAim provides an example of creating and combining media content with text for RealPlayer".

http://www.webaim.org/techniques/captions/real/

University of Wisconsin provides a video clip demonstrating a screen reader encountering images without alt-text http://accessit.nda.ie/guideline_1_48.html#rationale

Note: This video requires the QuickTime player.

Colour

(Ref b)

Standard

Ensure that all information conveyed with colour is also available without colour. This applies principally to navigation labels and error messages.

Guideline

This applies to all content whether done in CMS, templates or completely hand coded sites.

White text is used with caution.

Red text, which is often used for important messages may not be as prominent for a colour-blind person or someone using a black and white monitor. In this case you should reinforce the message by emphasis <em> or a symbol like "*".

Related Standard(s)

???m - Foreground & Background colours

Related Web Strategy

Web Strategy - Content/Text & Fonts/Fonts

Compliance assistance

Testing should be undertaken on an approved subset of form pages, one of which is a home page. This will be the basis for testing when a compliance audit is undertaken on an agency site.

Rationale

Supports the NZ Govt Public Service value of Equity.

People who are visually impaired including colour blindness, may not perceive differences in colour. Users with browsers that do not support colour or do not support colour well will also be disadvantaged.

Relates to WAI 2.1 Pty 1

For further detail, see

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_36.html#rationale

W3C http://www.w3.org/WAI/wcag-curric/gid3-0.htm

Good practice

Use white text with caution as it may not print if background colours are ignored.

Background colours contrast with text colours. Patterned backgrounds that make text difficult to read are avoided.

W3C 'how-to' tips http://www.w3.org/WAI/wcag-curric/sam25-0.htm

A free contrast analysis tool is available at http://www.nils.org.au/ais/web/resources/contrast_analyser/

Note: This tool is for guidance only and does not eliminate the need for testing by disabled people.

Colour

(Ref m)

Standard

Ensure that foreground and background colour combinations provide sufficient contrast for navigation, text and informational elements when viewed by someone having colour deficits or when viewed on a black and white screen.

Guideline

Ensure that background colours contrast with text colours. White text is used with caution.

Avoid patterned backgrounds that make text difficult to read.

Related Standard(s)

???b - Not relying on colour alone to convey meaning.

Rationale

Poor colour contrast is difficult to read even for users with excellent eyesight. This becomes all the more difficult when users have vision impairments. Bear in mind that there is also a high level of red-green colour blindness in New Zealand.

There should be good contrast between text colour and the background colour. Patterned backgrounds make text difficult to read, particularly if you have poor vision, and should be avoided.

Use white text with caution because it may not print if background colours are ignored.

Relates to WAI 2.2

Further assistance

Irish National Disability Authority http://accessit.nda.ie/guideline_1_37.html#rationale

W3C

http://www.w3.org/WAI/wcag-curric/gid3-0.htm

Good practice

A free contrast analysis tool is available at http://www.nils.org.au/ais/web/resources/contrast_analyser/

The following site provides a useful tool to check colour contrast acceptability and for colour blindness.

http://www.vischeck.com/vischeck/vischeckURL.php

Note: These tools are given for guidance only and do not eliminate the need for testing by disabled people.

Further Assistance

6.4.7a - Colours used for text, backgrounds, hyperlinks and solid-colour graphics are from the 216-colour web-safe palette

Site Mark-up

(Ref n)

Standard

Documents, including any web page and/or form, validate to published formal grammars. For NZ government websites these are:

  • HTML 4.01 Transitional
  • HTML 4.01 Strict
  • XHTML 1.0 Strict
  • CSS1 and CSS2
  • RSS (v1.0)

Content produced after 1 April 2004 must publish and validate to the above stated grammars unless

  1. a document which the agency wishes to place on its website which is to be or has been produced outside of editorial control of the agency, and cannot be sourced in HTML (or XHTML), or
  2. it is legitimately not feasible to be made directly accessible.

In this instance an agency must apply for a formal exemption, and, consider providing a service that will convert the content "on demand". Where such a service is provided it should be promoted alongside the inaccessible content. See also 6.4.2c.

Guideline

Conversion of content produced before 1 April 2004 to HTML format is at the discretion of the Agency, subject to the criteria set out in paragraph 4 of the Cabinet Minute [(03) 41/2B].

Ensure elements are closed properly.

A document title is provided in the HEAD section of the web page using the TITLE tag.

For example, <title>Example title</title>.

If an Agency uses the additional metatag instance of the document title it must contain the same information - for example <meta name="title" content="Example title">.

Related Standard(s)

6.4.2h - Special Purpose Documents - If you cannot publish a document that validates to the approved formal grammars.

6.4.2i - If you must publish a PDF file.

Further Assistance

6.3.3c - Primarily mark-up in HTML

6.4.3g - Use elements are used as they were intended

6.4.3k - Elements and content are laid out consistently.

7.4.2a - Forms designed to be completed on-screen and submitted online are in HTML or XHTML

W3C

http://www.w3.org/TR/html401/

http://www.w3.org/MarkUp/#xhtml1

Rationale

Supports the NZ Govt Public Service values of Equity, Integrity and Economy.

The web was founded on Hypertext Mark-up Language (HTML) and HTTP, the protocol for its transport.

HTML 4.01 is likely to be the last revision of the HTML recommendation based on SGML. Future recommendations for structural mark-up for the web will be based on XML, providing a framework for the language to extend.

XHTML 1.0 is the first such recommendation based on XML. Some recent browsers support XML-based mark-up like XHTML, as well as the SGML-based HTML. It is likely over time that XML browsers will be the norm, but this is not the case at the time of writing.

Relates to WAI 3.2 Pty 2

Good practice

For further details see

W3C

http://www.w3.org/TR/html401/

http://www.w3.org/MarkUp/#xhtml1

W3C (including tips for validation)

http://www.w3.org/WAI/wcag-curric/sam29-0.htm

W3C's HTML & XHTML Validator tool

http://validator.w3.org/

Site Mark-up

(Ref p)

Standard

Use heading elements to convey document structure and use them according to specification. Use <H1> .. <H6> in order.

Guideline

The meaning of the page title is clear out of context. An agency needs to clarify <h1>, <h2> heading tags for page or document titles. This not only assists with the consistent identification of documents on an agency website, but ensures users of external search engine are presented with more appropriate results

HTML structural elements, such as H1 to H6, OL, and UL, are used to denote document structure rather than custom styles.

Further Assistance

6.4.3f - Titles contain meaningful information in the first 60 characters

6.4.3e - Page titles have the same syntax consistently throughout the site.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

As stated by the Irish National Disability Authority "Many people navigate or skim through documents by reading the headings to get a feel for the structure and an overview of the content and scope of a document.

Also, some screen readers will read content assigned as a header in a different tone of voice to other content on the page"

Relates to WAI 3.5 Pty 2

For further details

http://accessit.nda.ie/guideline_1_61.html#rationale

Good practices

W3C

http://www.w3.org/WAI/wcag-curric/sam33-0.htm

Site Mark-up

(Ref q)

Standard

Mark up lists and list items properly.

Guideline

Part of providing accessible navigation.

HTML elements should not be used for formatting effects such as indentation.

Rationale

Supports the NZ Govt Public Service value of Equity.

Primarily for the benefit of screen readers for sensible ordered list navigation. Lists with a non logical structure will confuse users  who rely on screen readers.

Relates to WAI 3.6 Pty 2

For further details, see

Irish National Disability Authority http://accessit.nda.ie/guideline_1_62.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam35-0.htm

"how-to" tips for lists

http://www.w3.org/TR/WCAG10-HTML-TECHS/#lists

Site Mark-up

(Ref u)

Standard

Avoid deprecated features of W3C technologies

Guideline

The Wold Wide Web Consortium (W3C) is responsible for standardising Web technologies such as HTML, CSS, SVG, MathML, etc. Deprecated features of these technologies are those that will in the future be phased out.

This requirement requires you to avoid deprecated features and to use recommended non-deprecated alternatives instead.

The following table shows deprecated elements

http://www.w3.org/TR/html4/index/elements.html

The following table shows deprecated attributes

http://www.w3.org/TR/html4/index/attributes.html

Note at the above sites, the elements and attributes are themselves hyperlinks. Selecting these will direct to the detail of the selected element or attribute, if deprecated it will say so and suggest an appropriate alternative.

Rationale

Supports the NZ Govt Public Service values of Equity, Integrity and Economy.

Using deprecated features, e.g. deprecated HTML elements or attributes, will not stop the HTML validating against current doctypes. However it will stop HTML validating against future doctypes in which the phasing out is complete. Avoiding deprecated HTML in the first place stops you having to spend time and money down the track fixing HTML that has now become obsolete or ending up with accessibility issues because your HTML no longer validates.

Relates to WAI 11.2 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam87-0.htm and http://www.w3.org/WAI/wcag-curric/sam88-0.htm

Site Mark-up

(Ref k1)

Standard

Provide abbreviations for header labels.

Guideline

Use the "abbr" (or abbreviation) attribute of the HTML <TH> element.

Supports the NZ Govt Public Service value of Equity.

As stated appropriately by the Irish National Disability Authority, "Users of screen readers or audio browsers find listening to the content of long and complex tables with long header names cumbersome and repetitive."

Relates to WAI 5.6 Pty 3

For further details

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_99.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam51-0.htm

Special-Purpose Documents

(Ref 6.4.1d)

Standard

Links to web documents indicate as a minimum the document size and type which must either be included in the link itself and/or in the TITLE tag.

Guideline

Associated Recommendation(s)

6.4.1e - A version of the document type is provided.

Further Assistance

6.4.6d - Attempt to keep single images under 30 KB.

6.4.6e - Avoid the use of large images on a homepage.

More clarity by stating specific requirements for what are considered the two main items of information for accessibility - size and type.

Rationale

Accessibility

Special Purpose Documents

(Ref 6.4.2h)

Standard

If you cannot publish a document that validates to the approved formal grammars as stated in standard 'n' then publish the document in the most accessible format possible.

Accessible formats include:

  • Rich text format (rtf) for documents
  • Comma separated values (csv) for spreadsheets.

If it is not feasible for a spreadsheet to be provided in csv format, for example, it contains macros for modelling purposes, then the document can be published in its native format provided

  • it is for a specialised audience, and
  • the specialised audience expects the features in the spreadsheet that prevent it from being provided in csv format.

Guideline

Be cautious about using proprietary file formats such as Microsoft Word or Excel.

Related Standard(s)

'n' - Documents published published documents validate to approved formal grammars.

6.4.2i - If you must publish a PDF file.

Related Recommendation(s)

6.4.2f - Large files or collections of small files are made available compressed & uncompressed

Further Assistance

6.4.2c - When file formats other than HTML may require special software to make use of it

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Support for accessibility features in PDFs by screen readers is limited to the latest versions (which few people have). Correctly marking up a PDF document is more difficult than producing HTML http://www.webaim.org/techniques/acrobat/ http://www.alistapart.com/articles/pdf_accessibility.

rtf is considered in many courts to be more accessible than pdf - users can load into the editing tool (generally word processing) of their choice and use the search and find tools they are familiar with. Additionally, some individuals and organisations are more comfortable with rtf over Micrtosoft Word docs because they don't support embedded code and thus reduce potential virus risk.

Special-Purpose Documents

(Ref 6.4.2i)

Standard

PDF can be used to publish a document but it must be assisted with at least one other accessible format (refer to accessible formats in standard 6.4.2h on page 27) which can include web site content such as web pages & on-line forms that themselves validate to the approved formal grammars stated in standard 'n'. This covers the case where the PDF version is solely for printing purposes.

When publishing a PDF file you must:

  • show the PDF version used, and
  • follow and adhere to the Acrobat Accessibility Guidelines if publishing in version 8 or greater.

Guideline

Use of PDF alone for long documents or documents with specific, complex formatting intended for specialist audiences is strongly discouraged. However, if no HTML or Rich Text Format (rtf) version is provided, the Acrobat Accessibility Guidelines should be followed (see http://www.adobe.com/products/acrobat/access_booklet.html).

Related Standard(s)

6.4.2h - Special Purpose Documents - If you cannot publish a document that validates to the approved formal grammars.

6.4.2h - Documents published published documents validate to approved formal grammars.

Rationale

Adherence to accessibility where possible.

Good practice

IRD example providing a report in pdf indicating the size, number of pages, a link to the appropriate format reader if the user needs to download software to access the file, and importantly, a link providing details if the user experiences any accessibility issues

http://www.ird.govt.nz/studentloans/about/reports/2005/

Writing Content

(Ref c)

Standard

Clearly identify changes in the natural language of a document's text and any text equivalents for

  • paragraphs
  • captions
  • navigation labels
  • block quotes

Note: an exemption to meeting this standard is granted to agencies with strict qualifications. See the exemption to this standard for further details.

Guideline

If you use a number of different languages on a page, make sure that any changes in language are clearly identified.

For example, if a website has a natural language (i.e. the predominant language used for the content of the website) of English and part of the content is descibing the greeting phrase in Māori - Kia Orā", this is a case of a change in the natural language.

Exemption to this standard

Exemption to this standard is granted where the change in natural language is Māori or a Pacific Island language. This is due to a lack of text readers that cover these languages. When sufficient coverage with text readers covers these languages, this exemption will then no longer apply.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

Screen readers will attempt to read screen content in whatever has been defined as the natural language of the web site. When a screen reader encounters a piece of text that is not in the natual language, unless told otherwise it will still attempt to pronounce the text phonetically in the natural language.

For example, if a website has a natural language of English, a screen reader would have difficulty pronouncing the following piece of content' if not indicated prior to the Russian phrase that there is a change of natural language (to Russian)

'When greeted by the Russian ambassador, he gave a "Приветствия от русского" welcome!'

Relates to WAI 4.1 Pty 1

For further detail, see

W3C http://www.w3.org/WAI/wcag-curric/gid5-0.htm

Good practice

The natural (primary or predominant) language of a website is set in HTML with the lang attribute.

For example (specifying English)

<HTML lang="en">

....rest of an HTML document written in English...

</HTML>

when specifying changes in the natural language, use the lang attribute as per the example:

W3C

http://www.w3.org/TR/WCAG10-HTML-TECHS/#changes-in-lang

Writing Content

(Ref c1)

Standard

Identify the primary natural language of a document.

Related Standard(s)

???c - Clearly indicate changes in the natural language.

Guideline

Use the HTML LANG attribute in the web document's HTML tag to identify the natural language. In XML, use "XML:LANG".

For New Zealand the natural language is New Zealand English, the LANG value is "EN-NZ".

Example (HTML):

<HTML LANG="EN-NZ">

<HEAD></HEAD>

<BODY>

...

</BODY>

</HTML>

Rationale

Supports the NZ Govt Public Service value of Equity.

This is predominantly for assistive technologies such as screen text and Braille readers, which need to be informed what the natural language of a web site is.

Relates to WAI 4.3 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam42-0.htm

Writing Content

(Ref w)

Standard

Provide metadata (such as page title and description) to add semantic information to pages and sites.

Guideline

Utilise the HTML LINK element in the header.

The NZGLS Standard is recommended for metatag blocks where the agency determines there is a business need to store metadata in web documents. This could occur if a consistent cataloguing methodology is desired for documents, and document references, available on the web site. Typically, the metadata would be derived from an internal content management system used by the agency.

see http://www.e.govt.nz/standards/nzgls/standard

Make selective use of CSS techniques to aid aural navigation.

Rationale

Metadata provides contextual information for people navigating the site, especially those with screen readers who rely on things such as page titles, structured page headings, and lists. Metadata may also be used by some search engines

Relates to WAI 13.2 Pty 2

Good practice

W3C

http://www.w3.org/TR/WCAG10-HTML-TECHS/#document-meta and http://www.w3.org/WAI/wcag-curric/sam99-0.htm

Writing Content

(Ref b1)

Standard

Specify the expansion of each abbreviation or acronym in a document where it first occurs.

Guideline

Use the HTML ABBR and ACRONYM when using abbreviations or acronyms to define their full meaning.

Rationale

Supports the NZ Govt Public Service values of Equity, Integrity and Economy.

Acronyms and abbreviations are not obvious on their own as to what they mean to all users of a web site, particularly for NZ govt agencies sites intended for public access.

Additionally, abbreviations are no more than the letters that they constitute to assistive technologies such as text and Braille readers unless they are given more details as to what they stand for.

Relates to WAI 4.2 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam41-0.htm and http://www.w3.org/TR/WCAG10-HTML-TECHS/#text-abbr

Writing Content

(Ref 6.3.8a)

Standard

Authors do not use altered fonts that substitute umlauted vowels for macronised vowels.

Guideline

Further Assistance

Web Strategy/Content/Unicode & Macrons

Writing Content

(Ref 6.4.6n)

Standard

The alt text ends with a full point and a space.

Rationale

Supports the NZ Govt Public Service value of Equity.

If the alt text does not end with a full point and space, a number of assistive technologies such as screen readers will continue reading the end of a sentence and confusing the alt text with content.

Writing Content

(Ref 6.4.6s)

Standard

Both height and width attributes are specified in the IMG element.

Guideline

The dimensions applied should be the actual dimensions of the image.

Rationale

Supports the NZ Govt Public Service value of Equity and Economy.

Users who have slow connections can still obtain most of the textual content in a requested page before all the images have been downloaded as opposed to having to wait for all content of the page to be rendered.

Good practice

W3C

http://www.w3.org/MarkUp/html3/img.html

Writing Content

(Ref 6.4.5r)

Standard

Underlining is not used for any items making up

  • navigation
  • text
  • headings.

Guideline

Related Strong Recommedation(s)

6.3.6g - Avoid the usage of underscores in URLs

Site Content

(Ref 5.4.2e)

Standard

Agency sites provide any publicly available reports the agency is required to produce by statute on their web site.

Guideline

It is up to the agency to determine how long documents remain available on their web sites. The Public Records Act has the General Disposal Authority (GDA3) which allows deletion/destruction of reproductions of documents where the original has been captured into the corporate recordkeeping system.

It is unlikely the web site of an agency (or the underlying data store it utilises behind the web site) is the sole repository and/or copy of a document. In such cases it is expected the agency has such documents under management with respect to archiving/recordkeeping.

If this is not the case (the web site and/or its respective data store being the sole copy of a document), then management of the document comes under the agencies recordkeeping initiative.

Once documents have been removed (from the web site), the agency may consider retaining metadata details of the documents and enabling such data to be available on the web site. The documents will still appear in searches (on the web site), the mechanism for accessing them however may not be on-line, for example the agency providing contact details and/or an online application form for interested users requesting access to the documents. Refer to Standard w - Provide metadata to add semantic information to titles, descriptions & keywords regarding incorporating metadata into your web site.

Related Recommendation(s)

Recommendation p - Agencies check with National Library prior to deleting copies of reports.

Site Content

(Ref 5.4.2f)

Standard

Agency sites provide consultation documents (which must also be linked to from http://www.govt.nz).

Guideline

You may use RSS to meet this requirement.

Site Content

(Ref 5.4.2g)

Standard

Agency sites provide press notices from the agency, and links to press notices from the minister, for instances that set the context for a specific release of information where relevant (e.g. Budget).

Guideline

TBD  

Site Content

(Ref 5.4.3a)

Standard

The site provides an e-mail address for each of the following

  • postmaster@<domain>
  • webmaster@<domain>

general enquiries by either at least one of:

  • enquiries@<domain>
  • enquiry@<domain>
  • privacy@<domain>
  • complaints@<domain>

It is at the discretion of the agency whether these email addresses are published on the site.

The agency must have a response mechanism for each address such that an email item coming to any of these addresses is ultimately read by an appropriate person and a response made to the sender of the email if so requested.

An auto-response should be sent back to any sender to acknowledge receipt of the email.

Guideline

It is at the discretion of the agency as to how these email addresses are "funnelled" into the agency. For instance, they may simply all combine to one group address. More important is that any messages sent do get read by appropriate personnel within the agency, the agency personnel reading a message are aware of the category (via initial email address) it was sent, i.e. they should be able to differentiate a Complaints email from a Webmaster email are responded to for acknowledgement of reception by the agency are responded to if such is requested by the message sender. Obviously this is to be qualified within reason, i.e. a reasonable request by a message sender.

If agencies have concerns regarding spamming to these email addresses then

  • the agency does not have to publish these addresses, and
  • the agency should investigate employing anti-spamming procedures & processes on its email server(s)

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

Users require a means of contacting the agency.

It is a requirement of the Internet Engineering Task Force (IETF, see http://www.ietf.org/) that Internet mail systems provide a generic postmaster@domainname email address and that a person is responsible for handling messages to that mailbox. Any domain supporting email must comply with this requirement. People typically report problems, including complaints about relayed 'spam' messages, using the postmaster address.

Not all users however are familiar with the IETF postmaster standard.

Default names over and above postmaster which are also commonly used enhances the usability and accessibility for users of email as a means of contacting back to the agency.

These email addresses need to exist and receive messages but, generally for prevention of spamming, do not need to be published on their web sites.

Site Content

(Ref 5.2.4b)

Standard

Superseded material is marked as superseded

Guideline

It is at the discretion of the agency as to where (on the appropriate page(s)) to place the mark, or indication that a section of material on the web site has been superseded. It should not be confusing to a user as to which piece of material on a page is superseded.

Effort should be made to keep the content of a web site up to date. Pages should show the date last reviewed/updated.

Sites should be continually reviewed for outdated material content, particularly of any type which relates to a fixed date such as a final date for submissions, job applications or an event to be held.

Related Recommendation(s)

5.3.1a - A plan is expected to be in place to ensure material on the website is accurate and up-to-date.

Further assistance

5.3.2c - The agency has procedures for correcting errors.

Rationale

Supports the NZ Govt Public Service value of Integrity.

Outdated material can convey incorrect information and can cause frustration amongst users if they are unaware that the material has been superseded, especially if there are actions a users chooses to respond to as a result of the information they are obtaining. Users are also likely to develop mistrust of the site. This reflects poorly on the agency and the NZ Govt.

Page Layout

(Ref y)

Standard

Associate labels explicitly with their controls. Until user agents support explicit associations between labels and form controls, for all form controls with implicitly associated labels, ensure that the label is properly positioned.

Guideline

Use the HTML LABEL tag to explicitly associate.

Every descriptive label should be tagged as <label> and associated with the name of the field. The "for" attribute of the label tag is used by modern screen readers to identify a field reached by tabbing. Without this, tabbing between fields is completely disorienting.

Put labels beside form controls, not above them. Screen readers read left to right. "Doing this will make it easy to read the form and make sense of it with a screen reader" - as stated from Irish National Disability Authority

http://accessit.nda.ie/guideline_1_79.html#directions

Rationale

Poor label & control layout is potentially ambiguous to all users. Likewise with assistive technologies such as screen readers and more so for users with visual impairment.

W3C gives a good example (Example 3) of potential ambiguity for users (and for screen readers) with a poor lable/control layout

http://www.w3.org/WAI/wcag-curric/sam78-0.htm

Relates to WAI 10.2 (12.4) Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam78-0.htm

University of Wisconsin provides good assistance and tips for creating accessible forms

http://www.doit.wisc.edu/accessibility/online-course/standards/forms.htm

Page Layout

(Ref d1)

Standard

Create a logical tab order through links, form controls, and objects.

Guideline

Tabbing through form controls is possibly the most common navigation method for web site users, so it is important to ensure the tab order follows the visual placement of controls on a web page. For NZ Govt agency websites, the logical order is left to right, top to bottom.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

Not all users utilise a mouse or other "pointing" device for navigational purposes and rely on "tabbing" (usually via the "TAB" key) to move the cursor. The tab order is expected to follow the structural order of the web page elements. Not doing so gives a poor user experience from disorientation within the site and can create confusion for assistive technologies such as screen and Braille readers.

Relates to WAI 9.4 Pty 3

For further details

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_42.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam73-0.htm

WebAim

http://www.webaim.org/techniques/forms/screen_reader.php#logical

Page Layout

(Ref f1)

Standard

Until user agents (including assistive technologies) render adjacent links distinctly, include non-link, printable characters (surrounded by spaces) between adjacent links and also have a space between links.

Guideline

The WAI Accessibility Guidelines recommend putting a printing character like a | between adjacent links.

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Apart from being difficult to distinguish visually for users even with no visual impairment, some assistive technologies (generally older) have difficulty differentiating between hyperlinks when they have no visual (and correspondingly, textual) separation.

This can also help people with motor impairments.

Relates to WAI 10.5 Pty 3

For further details

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_87.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam82-0.htm

Page Layout

(Ref 6.4.8e)

Standard

Web pages are able to be printed in whole. Any page which requires landscape orientation to achieve this must be made clear to the user.

Rationale

Supports the NZ Govt Public Service values of Integrity and Economy.

A user can expect to capture any part of a web site in hard copy without losing any information or significant layout from that experienced in the browser.

Navigation

(Ref v)

Standard

Clearly identify the target of each link to where the user is to be taken via a link. Everything that is a link is obvious as a link.

Guideline

Quoting direct from the Irish National Disability Authority guidelines on this standard, ensure that the following characteristics of navigation mechanisms are more or less uniform throughout a site, or a series of related sites creates consistency:

  • Visual presentation - navigation elements look similar from page to page.
  • Order - navigation elements are presented in a consistent sequence.
  • Language - terminology is consistent.
  • Behaviour - links and navigation controls always do the same thing when activated.

It is generally recommended against having images as links however, this can in certain cases assist with accessibility. If this is to be done then the image must be made "obvious as a link" and an associated equivalent text-based navigation must also be provided.

Further Assistance

External links make the destination of the link clear

Further details

Irish National Disability Authority http://accessit.nda.ie/guideline_1_75.html#rationale

Rationale

Supports the NZ Govt Public Service values of Integrity and Economy.

Consistency in a web site is a key factor for usability and accessibility and aids towards a good user experience. Consistency in navigation within the site is a key factor in the overall consistency of a web site. Having inconsistent navigation mechanisms and navigation that is not clear as to where the navigation leads will disorient users and lead to mistakes, confusion, frustration or more simply, a poor overall user experience. Users are unlikely to be willing to return to a site where the have had a previous poor user experience.

For the agency, maintenance of the site is made more difficult and exacerbates the further degradation of userbility & accessibility.

Relates to WAI 13.1 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam97-0.htm

Navigation

(Ref g1)

Standard

Provide navigation bars to highlight and give access to the navigation mechanism.

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Aids usability & efficiency of a web site for all users by providing an additional navigation means, which is accessible from all pages in the site.

Relates to WAI 13.5 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam103-0.htm

Navigation

(Ref 5.4.5b)

Standard

External links are valid.

Guideline

External links should be checked regularly or incorporate an automatic checking process to ensure that the links are valid. Broken or 'moved' links should be corrected, removed or the linking text updated accordingly.

Invalid links can be

  • a non existent site/page
  • a valid page but not that intended by the link.

Related Web Strategy item(s)

External Links

Rationale

Supports the NZ Govt Public Service value of Integrity.

The usefulness of a site diminishes if an external link references an invalid or non existent link. It also hinders the quality of the site from a user perspective.

Navigation

(Ref 6.4.4c)

Standard

Every web page links to a homepage. If using an agency logo on a web page, it links to the homepage and has alt text of "Go to home page - Department Name".

Guideline

This is irrespective if the user is currently on a homepage.

If using an agency logo on a web page, it links to a homepage.

Related Standard(s)

5.4.1 - An agency's web site will have at least one or more of Main, Business Unit, Cross Agency and/or Progress & Initiatives pages

Rationale

Supports the NZ Govt Public Service values of Integrity and Economy.

Assists usability & accessibility of the web site. At any point in the web site, a user should be able to the homepage with minimal effort.

Navigation

(Ref 6.4.4k)

Navigation Access keys are used within the site as follows:

  • Access key 1 is provided for Home.
  • Access key 2 is provided for Site Map.
  • Access key 3 is provided for Search.
  • Access key 9 is provided for Contact Us.
  • Access key [ is provided for beginning of main content. This is known as a Skip Link.
  • Access key / is provided for "Go to http://www.govt.nz"

Guideline

Related Standard(s)

e1 - Provide Keyboard shortcuts

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

Assists and reinforces the standard Providing keyboard shortcuts . In addition it establishes a conformity of access keys across all NZ Govt agency sites. This assists users with familiarity of web site functionality within the NZ eGovt space as a whole.

Good practice

The NZ e-Govt site provides a guide for Access Key usage support under different browser types and versions

http://www.e.govt.nz/accessibility

IRD provides a good example of an accessibility guide to its sites

http://www.ird.govt.nz/help/accessibility/help-accessibility.html

Style Sheets

(Ref d)

Standard

Organize documents so they may be read without style sheets.

Guideline

Web sites that use style sheet techniques 'degrade gracefully' so the site remains fully functional if style sheet techniques are ignored. See Glossary of Key Concepts for meaning. Test for graceful degradation by viewing the site with a text browser, such as Lynx, or use Firefox Web Developer toolbar to disable CSS.

For example, when an HTML document is rendered without associated style sheets, it must still be possible to read the document in the logical order it was intended with style sheets.

Rationale

Supports the NZ Govt Public Service value of Equity.

Style sheets are not consistently supported by different browsers and some browsers (generally older browsers) do not support them at all.

Relates to WAI 6.1 Pty 1

For further detail, see

Irish National Disability Authority http://accessit.nda.ie/guideline_1_47.html#rationale

Good practice

W3C 'how-to' tips at http://www.w3.org/WAI/wcag-curric/sam52-0.htm and http://www.w3.org/WAI/wcag-curric/sam53-0.htm

Style Sheets

(Ref o)

Standard

Use style sheets to control layout and presentation of page and elements.

Guideline

Further Assistance

Style Sheets

Use HTML structural elements, such as H1 to H6, OL, and UL, to denote document structure rather than custom styles. People who using non-visual browsers or browsers that ignore style sheets are therefore not disadvantaged.

You may use selectors, properties and values that are defined in CSS2, but only where you are sure they will degrade gracefully in browsers that don't correctly interpret CSS2 or do so poorly.

Related Standards

Sites still functional without style sheets

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

As stated by the Irish National Disability Authority "Using style sheets separates structure and presentation which brings several benefits, including improved accessibility, manageability, and portability"

This complements the use of HTML 4.01 whereby the W3C reinstated HTML as primarily a structural document mark-up language and alongside this, encouraging the use of style sheets for presentation.

Relates to WAI 3.3 Pty 2

For further details

http://accessit.nda.ie/guideline_1_59.html#rationale

For a demo of the separation of presentation to structure, visit

http://www.csszengarden.com/

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam30-0.htm

also provide a CSS Validator

http://jigsaw.w3.org/css-validator/

University of Wisconsin provides assistance for proper use of Cascading Style Sheets

http://www.doit.wisc.edu/accessibility/online-course/standards/formatting.htm#explanationd

WebAim, Invisible Content Just for Screen Reader Users

http://www.webaim.org/techniques/css/invisiblecontent/

Dynamic Content

(Ref e)

Standard

Ensure that dynamic content is accessible. Provide an alternative presentation or page, and that equivalents for dynamic content are updated when the dynamic content changes.

Guideline

Explanation is easiest by example.

Consider a site that enables a user to shop for various products offered for sale.

The products available for selection may be presented graphically in which case a text equivalent is also expected.

As a user selects products for purchase, the content of the shopping basket will increase. This is an example of dynamic content. The shopping basket content may be presented to the user with a graphic of each product selected (no doubt also with quantity). It would be expected to have a text equavalent with each product selected.

As an alternative, offer a non graphic presentation version to the user.

Rationale

Supports the NZ Govt Public Service value of Equity.

Dynamic presentation causes problems for screen readers and other screen scanning devices which may easily become confused with content changing dynamically.

It also presents difficulties for users with impaired vision.

It is difficult to provide meaningful alt-text for random images dynamically served to a page.

Relates to WAI 6.2 (6.5) Pty 1

Good practice

W3C

http://www.w3.org/TR/WCAG10-TECHS/#alt-page-note

Dynamic Content

(Ref f)

Standard

Web pages are not to contain any blinking or scrolling text nor flashing objects of any kind.

Guideline

Ensure that no elements of a page blink or scroll across the screen.

There are some allowable exceptions which do not necessarily fall into this category, but mention is made here because some readers could consider it to be so.

Dynamic Objects within a web page

Small objects within a form that change dynamically and assist usability whilst not compromising accessibility are allowed.

For example, in the following site

http://www.theeuropeanlibrary.org/portal/index.htm

When a search is being undertaken, a small book image is being slowly overturned to indicate visually that the search engine is working behind the scenes. This is deemed an acceptable object in the confines of this standard. It does not "flicker" within the deemed "no-do" rate range of between the rate of 2Hz and 55Hz (as some sites technically attempt to define "flicker"). It aids usability and the accessibility pros outweigh cons.

Awareness is made that such facilities within a site are typically going to be achieved by scripting. The web standards of a site still functioning acceptably if scripting is not available still applies. Utilising scripting is generally considered an accessibility 'con', however as should be agreed in the above site, little is lost (in the context of the functionality of the site) if scripting is not available with the dynamic book image missing.

Rationale

Supports the NZ Govt Public Service value of Equity.

People with cognitive or visual disabilities may not be able to read moving text or may be distracted by it. Flashing or blinking can trigger seizures in some people.

Relates to WAI 7.1 (7.2) Pty 1

For further detail, see

University of Wisconsin

http://www.doit.wisc.edu/accessibility/online-course/standards/flicker.htm#explanationj

Good practice

In particular, BLINK and MARQUEE elements must be avoided. Apart from violating this standard, further reasons for avoiding these elements are:

Dynamic Content

(Ref i)

Standard

Until user agents allow users to freeze moving content, avoid movement in pages.

Guideline

This recommendation covers two principal categories

  • moving content (text), and
  • dynamic graphical content.

Moving content is generally requested to be avoided however, the guidelines for the usage of RSS should be consulted as RSS, which is an endorsed and encouraged technology technically comes under the title of "moving content".

With dynamic graphical content, there are no clear cut rules for what is acceptable and what is not. In general, small graphical objects that change at a relatively slow rate and of course have good purpose to be on a web site can be considered acceptable.

"Small" and "relatively slow rate" are in the context of not causing distraction to readers of other content of the web page.

Refer to Dynamic Objects within a Web Page for further details.

Rationale

Supports the NZ Govt Public Service values of Integrity Equity.

Assistive technologies such as screen readers do not cope with dynamic content particularly well. Users who utilise assistive technologies such as screen readers will be disadvantaged.

Users who suffer visual impairments may have difficulties focussing on dynamic content.

Content that has disappeared before a user has had a chance to read it (a furthermore select it if it is also a navigational object) will become frustrated.

Dynamic graphicalcontent can be distracting when in close proximity to content that is being read.

Relates to WAI 7.3 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam62-0.htm

WebAim

http://www.webaim.org/techniques/javascript/summary

Tables

(Ref h)

Standard

For data tables, identify row and column headers.

Guideline

Await furthe Treasury feedback

Rationale

Relates to WAI 5.1 Pty 1

Tables

(Ref i)

Standard

For data tables that have two or more logical levels of row or column headers, use markup to associate data cells and header cells.

Guideline

Await furthe Treasury feedback

Rationale

Relates to WAI 5.2 Pty 1

Tables

(Ref x)

Standard

Do not use tables for layout, use style sheets instead.

Guideline

Do not use tables for layout unless the table makes sense when linearized. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearized version).

Related Standard(s)

???o - Recommended use of style sheets.

???d - Sites still able to function without style sheets.

Rationale

W3C recommendations are for Cascading Style Sheets (CSS1 and CSS2) for layout.

Tables may be helpful to place and separate elements to the right or left of a page, but they should be used sparingly and not relied on fully, since not all browsers for some devices support tables.

Relates to WAI 5.3 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam48-0.htm

???o - Recommended use of style sheets

Tables

(Ref j1)

Standard

Provide summaries for tables.

Guideline

Use the "summary" attribute within the <TABLE> element.

Rationale

Supports the NZ Govt Public Service value of Equity.

This is predominantly for assistive technologies such as screen and Braille readers, which will be able to inform users of such devices what information is presented in the table and names the table headings.

Relates to WAI 5.5 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam50-0.htm

Frames

(Ref j)

Standard

Frames are not to be used.

Guideline

Never use Frames. You can use iFrames but Cascading Style Sheets are recommended over iFrames where possible.

If iFrames must be used, don't represent external content in the iFrame as being from the original site.

Acknowledgement should be made as to any external content and where it is being pulled from.

Rationale

Supports the NZ Govt Public Service value of Equity.

People with cognitive or visual disabilities and/or those who do not have a "pointing device" (i.e. mouse) may require alternative methods for navigating and selecting their choices available on the site.

As described on Webaim.org, 'People using screen readers cannot quickly scan the contents of multiple pages. All of the content is experienced in a linear fashion, one frame at a time. Frames are not inaccessible to modern screen readers, but they can be disorienting.'

Relates to WAI 12.2 Pty 1

Scripting & Applets

(Ref k)

Standard

Ensure that pages are usable when scripts, applets, or other programmatic objects are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

Guideline

Scripting as referred to here is Client side scripting.

Scripting languages should only be used where required. A simple rule of thumb regarding the usage of scripting or applets is "is this really necessary in the web site?" and "can the functional end objective be met without scripting and/or applets?"

If scripting (or an applet) must be used, then:

  • All information and services on a government website must be available whether or not scripting is available to the user, and
  • Text-based alternatives are available.

Where active scripting is used, it should conform to the ECMAScript standard, rather than a proprietary standard, and should use the W3C Document Object Model (DOM). This is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents.

Resources

ECMAScript (http://www.ecma.ch/ecma1/STAND/ECMA-262.HTM)

W3C Document Object Model (http://www.w3.org/DOM/)

Rationale

Supports the NZ Govt Public Service value of Equity.

Some organisations and individuals do not allow scripts to be run in their browsers, and some browsers do not understand some types of scripting. Scripting languages (particularly JavaScript) are abused creating a perception of insecurity and/or invasiveness among some web users.

Scripting can reduce accessibility in certain circumstances and can 'confuse' assistive technologies such as screen readers. Dynamic drop-down menus in particular are known to cause significant accessibility problems for people with motor or visual impairments, for example when screen magnifiers are used

Applets and/or support for applets may require downloads which are either disabled for a user community or the user simply does not wish to download (and run through possible subsequent installations) for one or more reasons (excessive time to download with a slow connection, potential security issues etc.)

A web browser user generally has full control over any client side scripting giving the potential for manipulation of the script!

Most browsers provide a means to disable support for scripting thus reinforcing the need not to have reliance on scripting.

Relates to WAI 6.3 Pty 1

Good practice

3 straight forward tips from W3C regarding alternative pages

  1. Allow users to navigate to a separate page that is accessible, contains the same information as the inaccessible page, and is maintained with the same frequency as the inaccessible page.,
  2. Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.,
  3. Provide a phone number, fax number, e-mail, or postal address where information is available and accessible, preferably 24 hours a day

W3C 'how-to' tips at

http://www.w3.org/WAI/wcag-curric/sam56-0.htm

University of Wisconsin provides significant content regarding applets and scripting and alternatives to scripting

http://www.doit.wisc.edu/accessibility/online-course/standards/scripts.htm

Scripting & Applets

(Ref z)

Standard

For scripts and applets, ensure that in the absence of a mouse or equivalent device - have an alternative event handler and specify logical event handlers rather than device-dependent event handlers.

Guideline

Event handlers are input device-independent.

It is so easy to only consider the common "point & click" devices (i.e. mouse) in web design and development and then have a web site primarily dependent on the specific functionality of such devices.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

The principal consideration here is with navigation devices. Design & development consideration should be to generic navigation, not a specific navigation device (i.e. a mouse). Users who do not and/or can not use such devices are disadvantaged if a site has been designed with dependence on specific device types (such as a mouse for navigation). Likewise, the corresponding event handlers should not be device specific.

Relates to WAI 6.4 (9.3) Pty 2

For further details

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_81.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam57-0.htm and http://www.w3.org/WAI/wcag-curric/sam70-0.htm

from Irish National Disability Authority

http://accessit.nda.ie/guideline_1_81.html#directions

University of Wisconsin provides good assistance and tips on scripts & applets

http://www.doit.wisc.edu/accessibility/online-course/standards/scripts.htm

Page Refreshing

(Ref r)

Periodical page auto-refreshing is discouraged, however if deemed necessary, pages must refresh at a refresh rate of 5 minutes or greater (>=5 minutes).

Guideline

A refresh rate less than 5 minutes (< 5 minutes) will

  1. require good reason as to why this is necessary, and
  2. be expected to be a temporary measure.

It should be noted that this standard applies to auto-refreshing of web pages.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

It can be disruptive and frustrating for users if a page refreshes (particularly if the content and/or structure also changes) before they have had time to finish reading content of their interest on the page.

Screen readers also have difficulty with refreshed web pages.

If an auto refresh has been incorporated into the code (at a refresh rate less than specified in the standard), users who find the refreshing disruptive and/or frustrating have little control over this functionality.

If it is deemed necessary to auto refresh web pages, a period of 5 minutes has been determined as sufficient time for most users to have completed their interest in a page (including if they are utilising assistive technology) such that a page refresh would cause minimal concern to the user.

Relates to WAI 7.4 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam63-0.htm

Page Refreshing

(Ref s)

Standard

Until user agents provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects

Guideline

The need to introduce page redirects occasionally (i.e. pages being superseded etc.) is acknowledged.

If and when the need arises to do this it should be done by configuring the appropriate server to do so.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

It can be disruptive and frustrating for users if a page auto-redirects as they can get disorientated with the site and feel that they are not in control of navigation within the site.

Relates to WAI 7.5 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam64-0.htm

Site Behavior

(Ref t)

Standard

Until user agents allow users to turn off spawned windows, do not cause pop-ups or other windows to appear and do not change the current window without informing the user. If a window has to be spawned, then the user must be informed (giving them an option to cancel) or, a choice to the user asking if they

  1. wish to open in the same browser form, or
  2. pull up a new form.

Guideline

This standard also includes the non-allowance of scripting based pop-ups.

Rationale

Supports the NZ Govt Public Service values of Equity and Integrity.

Many users find pop-ups disruptive, annoying and frustrating as they can feel they are not in control of navigation within the site and can also cause them to become disorientated with the site.

The annoyance and frustration factor is further increased when site history links are not preserved preventing going back to the previous page.

Pop-ups are also problematic for screen readers as the focus is suddenly removed with little or no notice.

Relates to WAI 10.1 Pty 2

For further detail (and discussion)

WebAim

http://www.webaim.org/techniques/hypertext/hypertext_links.php#new_window

Irish National Disability Authority http://accessit.nda.ie/guideline_1_68.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam77-0.htm

Site Behavior

(Ref a1)

Standard

Ensure that any element that has its own interface can be operated in a device-independent manner and also directly accessible or compatible with assistive technologies.

Guideline

Related Standard(s)

???z - Mouse or equivalent device event handler independence.

Rationale

Relates to WAI 8.1 (9.2) Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam65-0.htm

Site Behavior

(Ref e1)

Standard

Provide keyboard shortcuts to important links (including those in client-side image maps), form controls, and groups of form controls.

Guideline

Related Standard(s)

6.4.4k - Navigational Access Keys defined for NZ Govt web sites

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Not all users utilise a mouse or other "pointing" device for navigational purposes and rely on "tabbing" (usually via the "TAB" key) to move the cursor. Of further assistance to all users, not just those relying on the keyboard alone, keys that duplicate a navigation link to common or expected parts of a web site assist economy and efficiency.

Relates to WAI 9.5 Pty 3

For further details

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_86.html#rationale

Good practice

W3C (HTML)

http://www.w3.org/WAI/wcag-curric/sam76-0.htm

Site Behavior

(Ref h1)

Standard

Until user agents (web browsers, screen readers, etc.) are capable of automatically detecting and skipping over long lists of unwanted links, provide a way for the user to do this themselves.

Guideline

Skip links above navigation links are the most common method of this and this already exists as a standard.

Further Assistance

6.4.4g - Provide a means of going directly to content if desired by the user.

Rationale

Supports the NZ Govt Public Service value of Equity.

Some screen readers read everything including links. Users utilising such assistive technology may wish to avoid a multitude of links. Skip links enable this.

Relates to WAI 13.6 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam104-0.htm

Archiving

(Ref 5.2.1b)

Standard

The archive preserves the context in which the documents were made available.

Guideline

Content and documents available on the web that are now "historic" should not be altered for archiving. Any item of web content or document extracted from archive must be in the wording and should be in the format as it was when on-line.

Related Standard(s)

5.2.1 - Compliance with NZ Govt Archiving policy & standards.

Rationale

TBD

Disclaiming Content

(Ref 5.2.4c)

Standard

Site(s) must have a content Disclaimer

Guideline

It is at the discretion of the agency to determine the placement of the disclaimer on the site(s) and how often it appears, i.e. on every page, on a disclaimer page, in the footer etc.

Rationale

Describe difference between disclaimer and privacy statement.

Site Layout

(Ref 5.4.1a)

Standard

Any website owned by the agency which is not the 'Main' website of the agency (defined as an 'Other' web site of the agency) has a link, as a minimum from the homepage, to the homepage of the 'Main' agency web site.

'Main' and 'Other' website of an agency as defined in the Glossary of Key Concepts.

Guideline

For example, in the case of Social Development (MSD) as the agency. Studylink and Youth Development sites link back to the main MSD site as the Agency.

Related Standard(s)

5.4.1b - Minimal requirements of all homepages.

Rationale

Supports the NZ Govt Public Service value of Integrity

Any NZ Govt agency site must be clear as to which agency is hosting the site.

Site Layout

(Ref 5.4.1b)

Standard

All homepages contain the following as a minimum :

  1. Contact Us. This can be a content header or a link to a page specifically "Contact Us". The associated content includes contacts and/or an on-line form for feedback purposes.
  2. link to www.govt.nz.
  3. About this Site. This can be a content header or a link to a page specifically "About this Site".
    The associated content contains (as a minimum) :
    1. "Site Owner". The associated content contains (as a minimum)
      • a link back to the main agency web site
      • site owner name (can contain a logo but a logo alone is insufficient)
    2. "Accessibility". This can be a content header or a link to a page specifically "Accessibility".
      The associated content contains (as a minimum)
      • Access Keys.
      • Other information detailing navigational aids within the site is preferred to be here.
    3. Copyright. This can be a content header or a link to a page specifically "Copyright".
    4. Privacy. This can be a content header or a link to a page specifically "Privacy".
  4. At least the name and/or the logo of the agency.

Homepage as defined in the Glossary of Key Concepts

Guideline

Refer to http://www.govt.nz/linking for details regarding linking to www.govt.nz

Related Standard(s)

5.4.1a - Websites owned by the agency which is not the 'Main' website of the agency link back to the Main website.

Related Guideline(s)

5.4.1k - "Contact Us" content expectations

5.4.1l - Feedback considerations as part of "Contact Us"

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

Provides consistency across all NZ Govt web sites - users will find these links and/or sections on all such sites.

In the case of any inaccessible parts of an agency's site to certain users, for whatever reason that may be, which prevents them from accessing the information they are after or completing an on-line transaction, contact details to the agency to enable such users to obtain the information and/or complete a transaction by other means is important.

It is acknowledged that most NZ govt agencies have a logo familiar to the NZ public, in some cases the logo being more recognisable than the agency name. For this reasoning, either the name in text and/or the agency logo as a minimum is required.

Site Layout

(Ref 5.4.2a)

Standard

A homepage in the Main agency web site must have "About Us" or "About <Agency Name>". This can be a content header or a link to a page specifically "About Us" or "About <Agency Name>".

Mandatory associated content with the "About Us" section or the "About <Agency Name>" page contains

  • agency purpose
  • a list of ministers relevant to the agency, and
  • a list of responsibilities for each of the relevant ministers. The primary is defining what the ministers do for the agency.
  • provide a list of links to the biographies (on http://www.beehive.govt.nz or equivalent) for each of the relevant ministers.

Main agency website as defined in the Glossary of Key Concepts.

Guideline

This constitutes minimal requirements regarding the content contained within or under "About Us"/<Agency Name>. Other relevant information about the agency can also be on this page or in this section. Agencies should consider placing links to other primary sources of information relevant to the agency's functions.

Related Standard(s)

5.4.1a - Websites owned by the agency which is not the 'Main' website of the agency link back to the Main website.

5.4.1b - Minimal requirements of all homepages.

Related Guideline(s)

5.4 - It should always be clear which organisation is accountable for the site

Rationale

Supports the NZ Govt Public Service values of Integrity and Trust.

Being clear and open about who is ultimately responsible for the agency.

Testing

(Ref 6.5f)

Standard

The following states the minimum list of web browser compliance and correspondingly the minimum that the site is tested against such that the web site "works satisfactorily" as defined in the Glossary of Key Concepts.

Minimum

Browsers that must be supported to make an agency's website accessible to about 96% of Internet users. A consistent visual experience should be attained on an agency's website on the following:

  • Internet Explorer 5.5 (Windows, Mac)
  • Internet Explorer 6.0 (Windows)
  • Firefox 1.0+ (Windows, Linux, Mac)
  • Opera 8.0+ (Windows, Linux)
  • Safari 1.2+ (Mac)

Guideline

Extensive

Add the following to the Minimal list to make an agency's website accessible to around 98% of Internet users. Due to varying levels of HTML/CSS compliance, the visual experience will differ slightly on some browsers.

  • Internet Explorer 5.0 (Windows)
  • Internet Explorer 5.2 (Mac)
  • Firefox 0.9+/Mozilla 1.0+ (Windows, Linux, Mac)
  • Netscape 7.0+ (Windows, Linux)
  • Opera 6.0+ and 7.0+ (Windows)
  • Konqueror 3.0+ (Linux)

Comprehensive

Add the following to the Minimal and Extensive lists to make an agency's website accessible on all recent and legacy graphical browsers and non-graphical browsers. Due to low levels of HTML/CSS compliance, the visual experience will be poor, often losing style and formatting or without any formatting at all.

  • Internet Explorer 4.0 (Windows)
  • Netscape Navigator 4.0+ (Windows)
  • Lynx (Windows, Linux)

Related Recommendation

6.5g - The minimal set of browsers/operating system versions supported and tested against.

Related Guideline

6.5e - Consider a range of types of computer. This is also reflected in development and QA testing.

Privacy - Tracking Data

(Ref 7.3.1b)

Standard

Any tracking data must be able to be disabled by a user at any time in the current session if the user chooses for it to discontinue.

Guideline

This standard is in the context of the definition of Tracking Data in the Glossary of Key Concepts.

Related Standard(s)

7.3.1c - Successful completion of a transaction not dependent on tracking data

7.3.1d - No Pseudonomous data persisted at client end

7.3.1e - If Temporal and Anonymous tracking data taking place

Privacy - Tracking Data

(Ref 7.3.1c)

Standard

The successful completion of any transaction within an agency's web site must not be dependent on any tracking data. If the tracking is disabled at any point in time by the user, any transaction within the web site must be able to be satisfactorily completed as it would be prior to being disabled.

Guideline

This standard is in the context of the definition of Tracking Data in the Glossary of Key Concepts.

Related Standard(s)

7.3.1b - Any tracking data able to be disabled

7.3.1d - No Pseudonomous data persisted at client end

7.3.1e - If Temporal and Anonymous tracking data taking place

Privacy - Tracking Data

(Ref 7.3.1d)

Standard

No Pseudonymous data is to be persisted on the device the user is hosting their browser on (i.e. client machine).

Guideline

This standard is in the context of the definition Pseudonomous in the Glossary of Key Concepts.

Related Standard(s)

7.3.1b - Any tracking data able to be disabled

7.3.1c - Successful completion of a transaction not dependent on tracking data

7.3.1e - If Temporal and Anonymous tracking data taking place

Privacy - Tracking Data

(Ref 7.3.1e)

Standard

If Temporal and Anonymous tracking data is taking place then

Within the disclaimer page or content, a piece of content must exist stating (as a minimum)

  • that tracking data is being recorded, and
  • why the data is being recorded
  • the benefits to the user community resulting from the collection of such data
  • in the case of a non-authenticated session, that the user can turn off the recording of such data if they do not wish such recording to continue.

Guideline

This standard is in the context of the definitions Temporal, Anonymous and tracking data in the Glossary of Key Concepts.

Related Standard(s)

7.3.1b - Any tracking data able to be disabled

7.3.1c - Successful completion of a transaction not dependent on tracking data

7.3.1d - No Pseudonomous data persisted at client end

Authentication

(Ref 7.3.2a)

Standard

All instances of requests for users to authenticate themselves in a web site must comply with the standards as set by the Authentication unit of the SSC Information and Communications Technology Branch. Refer to http://www.e.govt.nz/services/authentication/standards/authentication-key/chapter6.html

Guideline

TBD

Security

(Ref 7.3.3a)

Standard

Personal information including payment information, such as credit card details, must as a minimum:

  1. encrypted between user and agency using Secure Sockets Layer (SSLv3) or Transport Layer Security (TLS),
  2. use certificates that have a trust chain that is available in commonly used browsers (referring to .current browser list.. for this list)

Guideline

Obtain and present a qualifying browser list

Online Forms

(Ref 7.4.2b)

Standard

The FIELDSET element is used to group related form elements. The LEGEND attribute of the FIELDSET element is used to caption a set of related form elements and the LABEL element is used to associate controls with their associated label text

Guideline

Related Web Strategy Section

Corresponding with the users/Forms

Rationale

Enhanses site accessibility - makes controls better "known" to assistive technologies

Online Forms

(Ref 7.4.2)

Standard

Every descriptive label must be tagged as <label> and associated with the name of the field.

Guideline

Related Web Strategy Section

Corresponding with the users/Forms

Online Forms

(Ref 7.4.3b)

Standard

Users receive online confirmation that the information they have submitted has been received, for example by displaying a web page.

Guideline

Related Web Strategy Section

Corresponding with the users/Forms

Further Assistance

7.4.3c - Agency responses to a form submission

Tendering and Contracting

(Ref 8.2a)

Standard

Advertising of web site tenders and opportunities over NZ$50,000 per year are notified to Government Electronic Tendering Service.

Guideline

Is $50K is still the appropriate amount

GETS, see http://www.gets.govt.nz/) website

Tendering and Contracting

(Ref 8.5.1a)

Standard

RFPs, RFIs and Contracts make compliance with the Web Standards and Recommendations a requirement.

Tendering and Contracting

(Ref 8.6.9a)

Standard

If not hosting the web site in-house, then the contract with the host specifies that the host must not independently collect or reuse data collected in the course of operating the web server, including cookies, click-stream data, HTTP request header information or upstream monitoring.

NZ government agency web site Recommendations

The following recommended items (recommendations) are a combination of

  • Those devised specifically for NZ government web sites and
  • Accessibility recommendations which are derived from the W3C Web Accessibility Initiative (WAI) standards checklist. In many cases they have been re-worded and/or further qualified for NZ Govt agency web site requirements. Each recommendation has the founding WAI standard(s) in the associated rationale.

The W3C WAI standards can be found at http://www.w3.org/TR/WCAG10-HTML-TECHS/

Refer to:-

Writing Content

(Ref a)

Recommendation

Use the clearest and simplest language appropriate for a site's content.

Guideline

Guideline links

Recommended item - Content 5.1.1

For further assistance see Design - Content - Clear and simple language.

Information Collections

Structuring Documents

On-Screen Writing

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity, Trust and Economy.

In the case of NZ Govt agencies.

Relates to WAI 14.1 Pty 1

For further detail, see

W3C http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension

Irish National Disability Authority http://accessit.nda.ie/guideline_1_50.html#rationale

Good practice

The W3C provides an overview of comprehension http://www.w3.org/TR/WCAG10-CORE-TECHS/#comprehension

and some 'how-to' tips http://www.w3.org/WAI/wcag-curric/sam113-0.htm

WebAim

http://www.webaim.org/techniques/writing/

Site Delivery

(Ref b)

Recommendation

If, after best efforts, you cannot create an accessible page, provide a link to an alternative page that uses W3C technologies, is accessible, has equivalent information (or functionality), and is updated as often as the inaccessible (original) page.

Rationale

It is very frustrating for users to navigate to an alternative page, only to find that content is out of date or missing. This can happen if no editorial or quality assurance process is in place to ensure that all versions of a web page are equally up to date.

If non-W3C technologies are used, the user may be forced to download plug-ins or stand-alone applications which could be inaccessible. W3C technologies include standardised versions of HTML, XML, Style sheets, multimedia and many other technologies. The W3C continually review these technologies for accessibility. They are non-proprietary, making them usable across a wide variety of browsers and user agents. By using them, you are more likely to embed accessibility in your website.

Relates to WAI 11.4 Pty 1

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam90-0.htm

Site Mark-up

(Ref c)

Recommendation

When an appropriate markup language exists, use markup rather than images to convey information.

Guideline

Though covered by other standards, the most common and likely relevant areas that this recommendation will cover in NZ Govt web sites are

Avoid images to represent text - use text and styles sheets, and

Avoid tables (and frames) for layout and presentation - use style sheets instead.

Beyond this, if there is a W3C endorsed markup for a specific information presentation category, utilise it, especially in preferance to the easiest alternative of presenting in a graphic. A good example of this is the presentation of mathematical formulae. The W3C has markup for this, see http://www.w3.org/Math/

Related Standard(s)

???o - Use Style Sheets for presentation

???x - avoid tables for layout, use Style Sheets

???j - Do not use Frames

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

Markup is more likely to be "understood" by assistive technologies such as screen readers and Braille displays. This enhances accessibility for users who utilise such assistive technologies.

Images contain their meaning within the context of their visual presentation. They share little of their meaning to the document they are imbedded in and thus offer a weak descriptive contribution to the information describing the overall document structure.

Resizing of images is not universally supported in all browsers or the browser has limitations in this capacity. This can cause problems when text is presented as an image for users who need to enlarge the text.

Relates to WAI 3.1 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam28-0.htm

Site Mark-up

(Ref d)

Recommendation

Use relative rather than absolute units in markup language attribute values and style sheet property values.

Guideline

Avoid fonts with sizing based on absolute units such as points (pt), pixels (px), centimeters (cm), millimeters (mm) and inches (in).

Font sizes expressed a percentages (%) and "ems" (em) are preferred.

A base size font across the whole web site (for consistency) is also a recommended.

Further Assistance

6.4.5c - Fonts are specified as families of alternatives in order of preference.

6.4.5d - The principal font has in its character set glyphs for the UTF-8 encoding of the long vowels of Māori.

6.4.5e - The principal font is commonly available

6.4.5g - The site does not ask people to download fonts or software to view text

Rationale

Supports the NZ Govt Public Service values of Integrity Equity.

People with visual disabilities may have difficulty reading text, or not be able to read text at all. If the cause of the reading difficulty is principally due to the user considering the text too small, most browsers will allow the enlargement of fonts, some browsers enable scalable enlargement of the whole document (i.e. Opera).

However, most browsers will more likely resize relatively-sized fonts than absolutely-sized fonts.

Most browsers will attempt resizing with absolute fonts but the resulting web site pages will often end up with an undesired overlap of content upon enlargement.

Relates to WAI 3.4 Pty 2

Irish National Disability Authority site details on this :

http://accessit.nda.ie/guideline_1_60.html#rationale

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam32-0.htm

WebAim

http://www.webaim.org/techniques/fonts/#font_size

Irish National Disability Authority

http://accessit.nda.ie/guideline_1_60.html

http://www.alistapart.com/articles/sizematters/

Site Mark-up

(Ref e)

Recommendation

Use W3C technologies when they are available and appropriate for a task and use the latest versions when supported.

Guideline

Emphasis is made on using the latest versions "When available". It is important to check that W3C technologies, or the version intended for use is endorsed by the W3C for general use.

Not all W3C endorsed technologies and standards are likewise endorsed for use in NZ Govt web sites by the NZ Govt web standards. For this reasoning, all W3C technologies considered for use in a web site must of course also satisfy all of the NZ Govt web standards.

Two key W3C technologies referenced throughout the NZ Govt Standards & Guidelines are the use of HTML and Style Sheets.

Related Standard(s)

??? Avoid deprecated features of W3C technologies

Further Assistance

6.4.3m - Comments are few and short, adding little to the size of the web document.

6.4.3j - Templates are used to apply common document sections

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity, Trust and Economy.

The World Wide Web Consortium (W3C) is an independent world wide body that, as a major part of its function, produces open standards for web based technologies. It also sets the Web Accessibility Initiative (WAI).

The NZ Govt have endorsed for NZ Govt agency web sites as a basis

the W3C technologies, and

the WAI guidelines.

Practically all browser manufacturers attempt to adhere to the W3C's standards. By adhering to W3C technologies for web site design and development, web based applications are more likely to be usable and accessible across a wide variety of browsers and assistive technologies.

Some browser manufacturers like to add certain features that they believe assist usability, accessibility or make their browser more cognizant with other products they may offer. Such features may be outside that endorsed by the W3C and as a result are not supported by other browsers and/or assistive technologies. Likewise, "plug-ins" that do not fully incorporate W3C technologies and/or standards may present usability and accessibility issues.

Relates to WAI 11.1 Pty 2

Good practice

W3C

http://www.w3.org/WAI/

and

http://www.w3.org/WAI/wcag-curric/sam83-0.htm,

http://www.w3.org/WAI/wcag-curric/sam84-0.htm,

http://www.w3.org/WAI/wcag-curric/sam85-0.htm,

http://www.w3.org/WAI/wcag-curric/sam86-0.htm

W3C header page of W3C technologies

http://www.w3.org/TR/

Site Layout

(Ref f)

Recommendation

Divide large blocks of information into more manageable groups where natural and appropriate.

Guideline

As part of the NZ Govt agency's web strategy, this is conformal with the Web Strategy concept of Information Collections.

Related Recommendation(s)

??? - Provide information about document collections

Related Guideline(s)

5.3.1b - Information is structured into context related collections of information

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

This recommendation benefits all users.

Not all information behaves like a single document. Users are familiar with the similar structuring of conventional printed matter such as books and magazines.

It intuitively assists navigation of content.

Utilisation of relevant HTML elements (such as the "P" for paragraphs) is more likely to be "understood" by assisitive technologies such as screen readers. Utilising these elements can enhance accessibility of a web site for users utilising such assistive technologies.

Relates to WAI 12.3 Pty 2

Good practice

NZ Govt Web Standards & Guidelines Web Strategy

Information Collections (yet to be defined)

W3C

http://www.w3.org/WAI/wcag-curric/sam93-0.htm,

http://www.w3.org/WAI/wcag-curric/sam94-0.htm,

http://www.w3.org/WAI/wcag-curric/sam95-0.htm

Site Layout

(Ref g)

Recommendation

Provide information about the general layout of a site (e.g. a site map or table of contents).

The term "web site" can be vague as to the size of the site. It can be anything from a single page upwards.

The usefulness of this recommendation increases as the size of the site (number of pages) increases and common sense applies. If a site has a minimal number of pages then a site map or table of contents could quite possibly be an overkill and its usefulness questionable.

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

A site map enhances navigation particularly when the structure of the site becomes more complex. The ideal site structure is a matter of subjectivity. A site may seem a dream to navigate by its designers but found disorientating and confusing by some users who will become frustrated trying to figure out the stucture of the site. A site map or table of contents can assist no matter how much the structure of the site is perceived to have been well designed.

Relates to WAI 13.3 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam100-0.htm,

http://www.w3.org/WAI/wcag-curric/sam101-0.htm

Navigation

(Ref h)

Recommendation

Use navigation mechanisms in a consistent manner.

Guideline

As stated from the Irish National Disability Authority, ensuring that the following characteristics of navigation mechanisms are more or less uniform throughout a site, or a series of related sites creates consistency:

Visual presentation - navigation elements look similar from page to page

Order - navigation elements are presented in a consistent sequence

Language - terminology is consistent

Behaviour - links and navigation controls always do the same thing when activated

Further Assistance

6.4.4b - The main sections of the site are linked directly from the homepage

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

Consistency in the web site is a key component of good site design. It enables users to gain a quicker understanding of the structure of the site and enhances their familiarity and confidence with the site. This aids to the desired goal of a good user experience when visiting the site.

Relates to WAI 13.4 Pty 2

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam102-0.htm

Special-Purpose Documents

(Ref j)

Recommendation

Provide information so that users may receive documents according to their preferences (e.g. language, content type, etc.)

Guideline

State alongside all downloadable objects

the format, i.e. [pdf], [MS Word], [rtf], etc.

size, i.e. [15MB],

version, the earliest version of a download that can access the download, i.e. [MSWord 6.0/95 or later]

any further third party objects and their versions that are necessary for the user to access the object being downloaded, i.e. [Zip 2.3 http://www.info-zip.org/]

Alternative Style Sheets (CSS) are a means of enabling user's to specify their presentation preferances by setting specific presentation attributes. For further details refer to W3C

http://www.w3.org/TR/WCAG10-CSS-TECHS/#Alt

Aural Cascading Style Sheets assists non-sighted users and voice-browser users. This is part of W3C's CSS2 specification.

http://www.w3.org/TR/WCAG10-CSS-TECHS/#acss

Māori is an official language of New Zealand. Govt agency websites should have their content able to be provided in both English & Māori.

Most Content Management Systems (CMS) enable the presentation of page content for the same pages in multiple languages. In such cases the content is filled out in all languages (the CMS does not perform an automatic translation!) and a simple menu selection provided to the user as to their choice of content language.

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

When downloadable objects such as documents, program executables and multimedia files are presented for download, users need to know if the object downloaded is going to be accessible. If the downloaded object requires further software or a different version to that which they may have to access the object, the downloaded object is not accessible. This is frustrating for all users, all the more so if the user has persevered through a long download time and/or time-outs to capture the object.

Stating up front the format, size, version and any other third party object dependencies of an object enables the user to make a choice to proceed with the download.

Not all users will have the natural language of the web site as their first language. Downloadable documents provided in multiple languages appropriate to the likely audience of the web site will aid the accessibility of the information being made available.

Relates to WAI 11.3 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam89-0.htm

Navigation

(Ref k)

Recommendation

If search functions are provided, enable different types of searches for different skill levels and preferences.

Guideline

Specifications and guidelines for search engine technology is beyond the scope of this document. Attempting to employ "intelligence" within a search engine to predict what a user is looking for heads off into some very complex tennological areas.

Related Standard(s)

The simplest aid to this recommendation is adhering to other recommendations, notably

???a - Using the clearest and simplest language

???c - Use appropriate markup when available

???f - Divide content into related blocks

???h - Use navigation consistently throughout the website.

Some more simpler guides however that can enhance the usability & accessibility of a search facility are

  • catering for incorrect spelling, for instance, abbreviations and missing vowels.,
  • searching for the plural and non-plural instances of entered words.

Related Recommendation(s)

5.4.1h - A homepage has a link to Search or a Search box.

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Searching is a further aid to navigation thus enhancing the usability & accessibility of the web site. Not all users know the correct spelling of a word or phrase they are searching for and not all users have the natural language of the web site as their primary language.

If the underlying search engine facility can employ a degree of intelligence with respect to what a user has entered, even if not matching exactly a word or passage of text within the site, the accessibility and usefulness of the site is further enhanced.

Relates to WAI 13.7 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam107-0.htm,

http://www.w3.org/WAI/wcag-curric/sam108-0.htm,

http://www.w3.org/WAI/wcag-curric/sam109-0.htm

Site Layout

(Ref l)

Recommendation

Place distinguishing information at the beginning of headings, paragraphs, lists, etc.

Guideline

Place appropriately worded "headers" at the beginning of each content "block", i.e. chapter, paragraph, sentence etc. The header should have a minimal number of words as possible to convey the meaning of what the block represents.

Adhering to the following related recommendations will assist with this recommendation

???a - Using the clearest & simplest language

???f - Divide content into related blocks

Employing and/or gaining the assistance of a specialist in written content is also useful.

Rationale

Supports the NZ Govt Public Service values of Equity and Economy.

Users wish to find that they are after as soon as possible and having to scan through volumes of content for what is being sought is tiring and cumbersome. Users with visual impairments can tire very quickly such that continuing on to scan what they are after is not possible.

Placing distinguishing information at the beginning of headings, paragraphs, lists etc., assists the speed to scan through content and eliminate the need for reading through unnecessary content.

Relates to WAI 13.8 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam110-0.htm

Site Layout

(Ref m)

Recommendation

Provide information about document collections (i.e. documents comprising multiple pages.).

Guideline

Will already be covered in the Web Strategy

Rationale

Relates to WAI 13.9 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam111-0.htm,

http://www.w3.org/WAI/wcag-curric/sam99-0.htm#rel

Content Writing

(Ref n)

Recommendation

Supplement text with graphic or auditory presentations where they will facilitate comprehension of the page.

Guideline

Information provided in as many formats as possible will assist the accessibility of the information being portrayed. Some users who have reading difficulties may not be able to read and/or pick up the information from a sequence at all, but comprehend what is being conveyed from an associated image, video and/or soundtrack.

Rationale

Supports the NZ Govt Public Service values of Integrity, Equity and Economy.

As with content on more conventional visual media such as books, magazines and television, assisting written text with images and/or a soundtrack (if possible) enhances the ability to portray what is being presented to the reader.

This also assists users with disabilities who find difficulty reading text alone, and users who have difficulty with the language used in textual passages because it is not their first language.

A wide variety of techniques can be used to provide supporting information, including animations, icons, graphs, video, recorded speech, synthesised speech, sound effects or sound alerts.

Relates to WAI 14.2 Pty 3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam115-0.htm,

http://www.w3.org/WAI/wcag-curric/sam116-0.htm

Site Layout

(Ref o)

Recommendation

Create a style of presentation that is consistent across pages.

Guideline

Utilisation of style sheets can assist with this.

Presentation of dates.

Be mindful of international audiences where numerical formats of dates are concerned. It should not be ambiguous as to which figures represent the month and day - state the format alongside if necessary. The date format should be kept consistent, where possible, throughout the web site.

Rationale

Consistency makes your site more predictable and helps users to learn how it works, making it easier for them to navigate to the information they want, each time they visit a site. It also helps users to skip unwanted chunks of navigation or content, which makes task completion or information retrieval more efficient.

Relates to WAI 14.3

Good practice

W3C

http://www.w3.org/WAI/wcag-curric/sam117-0.htm,

http://www.w3.org/WAI/wcag-curric/sam118-0.htm

Homepage

(Ref 5.4.1h)

Recommendation

A homepage has a link to Search or a Search box.

Guideline

If a search facility is offered on a web site, then it is expected the search facility itself resides on a homepage, or, a homepage has a link to a page with more comprehensive search facilities.

The agency may offer Search facilities subject to the practicality of doing so. The value of search facilities grows in proportion the the size of a web site. If the site is very small, of the order of 3 pages or less, a search facility would be somewhat superfluous, however, the agency in such cases may still decide a search facility adds value.

A search facility can be considered and extended navigation tool. The agency may determine that the navigational facilities offered on their web site, such as a site map, are sufficient to cover the requirements of a search facility.

Forums

(Ref 5.2.5a)

Recommendation

If the agency is to accommodate any kind of discussion forum(s) on their site(s) then moderation of the discussion content is Recommended. The agency bears any potential risk of the contect on a public forum it hosts in the name of the agency. The agency is strongly advised to obtain its own legal advice regarding potential defamation of any content on public forums and advice on necessary disclaimers that the content on such forums does not necessarily reflect the policies or opinions of the agency.

Guideline

Moderation of any forum content needs to be done via human resource, which is likely to make having a pubic (non user authenticated) forum unfavourable. This is also given that the nature of the web is tending toward more usage of forums (which involve the public).

Moderation in this context means any anonymous user can enter free form content to a forum, but whatever has been submitted by the user is not available for immediate view on the forum, it is reviewed by one or more appropriate people (most likely within the agency). The content thereafter may be released onto the public forum with as much editing performed by the reviewer(s) as deemed appropriate (on behalf of the agency).

A disclaimer is recommended to be placed with such a forum if such moderation is in place to state that the agency has the right to edit such content entered as it deems appropriate, and the right to not release what was submitted on to the forum at all.

Further assistance with this recommendation can be found under Corresponding with users - On-line forums.

Rationale

Supports the NZ Govt Public Service value of Integrity.

An open forum, particularly non moderated is essentially opening an agency to allow free format content on its site.

Can result in revealing identity and/or contravening privacy laws that the agency has bound itself by. It can also expose the agency to views and opinions that are not necessarily those of the agency. It can expose the agency to grievances by users who view the material on a forum and find it offensive.

Site Content

(Ref p)

Recommendation

Prior to removal of any reports agency sites are obliged to make publicly available on their sites, they first check with the National Library as they may require agencies to make copies of reports under the National Library Act.

Guideline

Refer to National Library (url ?...)

Related Standard(s)

5.4.2e - Agency sites provide any publicly available reports by statute on their web site(s).

Site Content

(Ref 5.4.2h)

Recommendation

Paper based forms provided by an Agency are made available on its web site.

Guideline

Traditional printed forms are now available electronically on most government websites. They are either electronic replicas of the printed form (e.g. PDFs), designed to be downloaded and printed, or forms that are completed on-screen and submitted online. A form designed to be completed online will be more accessible than one that can only be printed.

Forms should be updated online when their paper based version(s) is/are modified or removed and/or archived when the paper based equivalent is removed.

Rationale

A desirable goal for eGovernment within the NZ Govt is to have as much funtionality available to a user via an agency's web site(s) as can be made possible. This includes having forms available on the web site.

It is acknowledged it would be an unreasonable mandate to request an agency to identify every form it has and make all available on its web site(s).

Site Content

(Ref 5.4.2i)

Recommendation

Agency sites provide contact details for specific policy or services.

Guideline

Related Standard(s)

5.4.1k - The web site has a "Contact Us" page.

Navigation

(Ref 5.4.5d)

Recommendation

It is clear that a link to a non-government site is not intended as an endorsement nor the responsibility of the referring agency. A disclaimer is acceptable, and one disclaimer per site is sufficient

Guideline

Disclaimmer section (when is available)

Site Content

(Ref 6.3.6f)

Recommendation

URLs use lower-case only and do not use mixed case.

Guideline

It is acknowledged that there are web servers in existence where this may create issues, particularly in the case of migrating a site from one to another. The aim however, if and when possible is to keep all lower case.

Related Standard(s)

6.4.5r - Underlining is not used for navigational items

Related Web Strategy item(s)

Designing URL's - File Naming

Rationale

Yes, why is this?

Site Content

(Ref 6.3.6g)

Recommendation

Avoid the usage of underscores in URLs.

Guideline

It is acknowledged that there are web servers in existence where this may create issues, particularly in the case of migrating a site from one to another. The aim however, if and when possible is to avoid underscores.

Hyphens are a more appropriate and commonly used alternative.

Related Web Strategy item(s)

Designing URL's - File Naming

Rationale

Get confused with underlines in the case of hypelinks.

Site Content

(Ref 6.3.6h)

Recommendation

Discovery level URLs are descriptive and less than 50 characters long.

Guideline

Related Web Strategy item(s)

Designing URL's - File Naming

Rationale

This is a trade-off figure. It is desirable to have the URL reasonably descriptive, however too long ( beyond 50 characters) becomes cumbersome and presents management./change issues with the URL.

Special-Purpose Documents

(Ref 6.4.1e)

Recommendation

A version and/or any other aspect of the document that a user should be informed about for making a decision to choose to

  1. download the document, and
  2. access the document

should be additionally be given if this is applicable

Guideline

For example, [MSWord 6.0/95 or later]

Related Standard(s)

6.4.1d - Links to web documents indicate as a minimum the document size and type

Special-Purpose Documents

(Ref 6.4.2f)

Recommendation

Large files or collections of small files are made available in both compressed and uncompressed versions. A link to a suitable decompression utility is to be provided.

Guideline

You should use the Zip 2.3 (http://www.info-zip.org/) format for compression and providing as a decompression utility for users who wish to download a suitable decmpression utility.

Disaster Recovery

(Ref 8.6.2a)

Recommendation

A comprehensive disaster recovery plan is set out whether the site is hosted in-house or hosted externally in which case this should constitute part of the contract

Guideline

Related Guideline(s)

Commercial Arrangements/Hosting Services/Disaster Recovery

8.6.2b - The disaster recovery plan covers the host's routine backup procedures.

8.6.2c - The agency should keep separate backups

Site Content

(Ref 5.3.1a)

Recommendation

A plan is expected to be in place to ensure material on the website is accurate and up-to-date.

Guideline

Online publishing is fully integrated into the agency's information processes. For example, you have a workflow process for approving and publishing online material

It should be noted that this extends to any document intended to be posted on the web (principally for download purposes) as well as straight content.

It is imperative that as much effort as possible be given to the management of style, quality and correctness of content on a par with any other medium (such as printed matter) an agency utilises for disseminating information.

Rationale

Good quality and informational correctness of content supports the NZ Govt Public Service value of Integrity.

Conversely, poor quality of content and/or incorrect information degrades the integrity of a site, frustrates users and thus reflects likewise on the agency and the NZ Govt.

Browers/Operating Systems

(Ref 6.5g)

Recommendation

The suggested minimal set of browsers/operating system versions supported and tested against to ensure a high likelihood that your web site "works satisfactorily" as defined in the Glossary of Key Concepts is:

  • Internet Explorer 5.5, on Windows 2000
  • Internet Explorer 6.0, on Windows XP
  • Mozilla Firefox 1.0.X (or 1.5.X), on Windows XP or Linux

Guideline

Consider a range of computer types. This is also reflected in development and QA testing.

Principally this should be IBM PC derivative and Apple computers. To go the extra mile, other devices besides computers can also be used for testing such as handheld devices.

Websites should be available to a range of assistive technologies, such as Braille and screen readers and tested likewise. If the standards definied in this document derived from W3C WAI accessibility standards are complied with, web sites satisfactorily working with such technologies should be automatic.

Related Standard(s)

6.5f - Minimum list of web browser compliance and testing.

Web Strategy Component

(Ref q)

Recommendation

The agency incorporates the objectives of the E-government Policy Framework for Government-held Information into its web strategy.

Guideline

Further details

Foreward on the E-government Strategy and its incorporation into your agencies web strategy.

E-government Strategy itself (http://www.e-government.govt.nz/programme/strategy.asp)

Rationale

A component of the Web Strategy which the agency is expected to construct and produce for one or more web sites under the agencies control. Refer to Strategies - Web Strategy.

Web Strategy Component

(Ref r)

Recommendation

The agency incorporates the aims of the Disability Strategy into its web strategy.

Guideline

Further details

Foreward on the New Zealand Disability Strategy and its incorporation into your agencies web strategy.

The site launched by The Minister for Disability Issues in April 2001 http://www.odi.govt.nz/nzds/.

Meeting the expectations of this web strategy component can be achieved implicitly by complying to the Standards & Recommendations in this document (particularly those derived from W3C WAI for accessibility).

Rationale

A component of the Web Strategy which the agency is expected to construct and produce for one or more web sites under the agencies control. Refer to Strategies - Web Strategy.

Web Strategy Component

(Ref s)

Recommendation

The agency incorporates the objectives of the Māori Language Strategy into its web strategy.

Further details

Foreward on the Māori Language Strategy and its incorporation into your agencies web strategy. This includes further external links of relevance.

A component of the Web Strategy which the agency is expected to construct and produce for one or more web sites under the agencies control. Refer to Strategies - Web Strategy.

Web Strategy Component

(Ref t)

Recommendation

The agency has a record keeping strategy and associated process which encompasses all documents the agency makes available on its web site(s).

Guideline

Further details

Foreward on the Record keeping strategy and its incorporation into your agencies web strategy. This includes further external links of relevance.

By extending the record keeping strategy (and processes extending from that) that your agency already has to documents including web pages on your web sites, your agency should correspondingly meet the compliance of this recommendation.

Rationale

A component of the Web Strategy which the agency is expected to construct and produce for one or more web sites under the agencies control. Refer to Strategies - Web Strategy.

[ Previous ] [ Next ]