These results are intended to be a discussion document, highlighting some of the techinical issues that were found.
This is not a guarantee of accessibility or usability.
On the right, you can filter the particular results you are interested in, and you can use the 'next result' and 'previous result' links to jump to the next result matching your interests.
The following defines the key terms within standards and recommendations:
Standard
Requirements of an agency which are objectively testable and with which agencies Must comply.
It is anticipated that there are no exceptions for an agency not complying with these.
In the case of your agency, these standards apply to all web pages under ownership of your agency. 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 in any web page under ownership of the agency during the audit.
Recommendation
Recommendations are items considered of high importance that:
would otherwise be a standard but cannot fairly be mandated as such for one or more reasons, principally being too wide in scope or containing a degree of subjectivity, or,
are considered not quite as critical or appropriate to mandate absolutely as a standard.
Agencies are however expected to comply with recommendation items.
Agencies' web sites will be checked against these items when audits for compliance are undertaken. Where an agency is found not to be compliant with any such items, the agency will be required to provide a good reason for non-compliance.
Good practice
This section will provide examples from organisations that have complied successfully with a particular standard, and/or how they approached a particular problem.
This section may also include links to other web sites that have information relevant to a particular standard or recommended item.
Those devised specifically for NZ government web sites and
Accessibility standards derived from the W3C Web Accessibility Initiative (WAI) standards checklist. In many cases, they have been re-worded and/or further qualified for NZ Government agency web site requirements. Each standard has the founding WAI standard(s) in the associated guide to the standard.
All standards are intended to enhance accessibility and usability of agency web sites.
Version 1.0 standards and recommendations are based on the W3C WAI 1.0 recommendations. WCAG 1.0 was approved in May 1999 and is the stable version able to be referenced. WCAG 2.0 documents are still being developed. They are documented in Requirements for WCAG 2.0.
Refer to:
Interpretation - Standard (page 9), defining a standard in the context of this document.
Accessibility - what is it? (page 128) for further details of accessibility in NZ government agency web sites.
Accessibility and emerging technologies (page 129) for further details of newer technologies including Rich Internet Applications.
Usability - what is it? (page 130) for further details on usability in NZ government agency web sites.
Provide alternative text for every non-text element such that it conveys the same meaning or information as the non-text element conveys (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.
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.
This standard covers the W3C WAI checkpoint 1.1 (http://www.w3.org/TR/WCAG10-TECHS/#tech-text-equivalent) for NZ government agencies.
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
Guidance on Images - Text Equivalents on page 107.
Sub section Images - Text Equivalents - Alt text within 100 chars (page 107) discussing the containment of the alt text to within 100 characters.
Sub section Texts and Fonts - Fonts and branding (page 107) - Text that must be in a particular font, say, for reasons of branding, uses an image and provides the same as alt text.
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.
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.
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, for example:-
<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 client-side image maps are used then Ensure there is an alt text, for example:-
<area shape="rect" coords="9,6,79,68" href="http://www.ssc.govt.nz " alt="SSC Website" />
This standard covers the W3C WAI checkpoints 1.2 (http://www.w3.org/TR/WCAG10-TECHS/#tech-redundant-server-links) and 1.5 (http://www.w3.org/TR/WCAG10-TECHS/#tech-redundant-client-links) for NZ government agencies.
Further Assistance
Sub section Navigation - Image map navigation (page 117)
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.
Until user agents can automatically read aloud the text equivalent of a visual track, provide a text description [that can then be read] of the important information of the visual track of a multimedia presentation.
To assist understanding of this requirement, an analogy is a Karaoke machine. If video with the music has someone singing the track, the lyrics presented in written form on the screen are expected to be in sync with the music and the lip movements of the singer(s).
Provide a text equivalent or alternative, and an audio track to accompany a multimedia presentation, which describes important information presented in the visual track.
If possible, attempt to have the text and/or audio track synchronised with the presentation.
If information is provided primarily in multimedia clips i.e., 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.
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.
This applies to all content whether done in CMS, templates or completely hand coded sites.
Use white text 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 "*".
Testing should be undertaken on an approved subset of form pages, one of which is a homepage. This will be the basis for testing when a compliance audit is undertaken on an agency site.
Note: 'Homepage' as defined in the Glossary of Key Concepts, page 138.
Related Standard(s)
2.2 - Contrast between foreground and background colours on page 15.
Further Assistance
Sub section Text and Fonts - Font colour on page 108.
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.
A free contrast analysis tool is available at http://www.nils.org.au/info.aspx?page=628
Note: This tool is for guidance only and does not eliminate the need for testing by disabled people.
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.
2.1 - Information conveyed with colour must be available without colour on page 14.
Further assistance
Sub section Text and Fonts - Font colour on page 105.
Sub section Colour (page 110) - suggesting colours used for text, backgrounds, hyperlinks and solid-colour graphics are from the 216-colour web-safe palette.
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.
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.
Documents, including any web page and/or form, validate to published formal grammars. For NZ government web sites these are:
HTML 4.01, Strict or Transitional
XHTML 1.0, Strict or Transitional
CSS, CSS1 or CSS2
RSS, 1.0
Content produced after 1 April 2004 must publish and validate to the above stated grammars unless the following exception criteria qualify:
a document that the agency wishes to place on its web site, which is to be or has been produced outside of editorial control of the agency, and cannot be sourced in HTML (or XHTML), or
a document that the agency wishes to place on its web site, which has all its content duplicated elsewhere within the same web site (where the duplicated content validates to the above stated grammars), or
it is legitimately not feasible to be made directly accessible.
If content cannot qualify via the exceptions as stated above, an agency must apply for a formal exemption, and consider providing a service that will convert the content "on demand".
Notes:
Documents qualifying via the exceptions to validating to the formal published grammars in cases i) and iii) must be assisted with a summary of the key points contained within the document (which itself must validate to the approved formal grammars), located such that the summary's association with the document is unambiguous as to which document the summary pertains.
Documents "legitimately not feasible to be made directly accessible" (as in case iii) of the exception criteria) would qualify as such by being deemed
For a "specialist audience" (as defined in the Glossary of key concepts, page 141), or
A "special-purpose document" (as defined in the Glossary of key concepts, page 142).
Documents "made directly accessible" (as in case iii) of the exception criteria). Refer to standard 4.2 on page 22, regarding the publishing of documents in the most accessible format.
Selectors, properties and values that are defined in CSS2 must degrade gracefully (as defined in the Glossary of key concepts, page 140), in browsers that don't correctly interpret CSS2, or do so poorly.
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.
Elements and content are laid out consistently.
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 meta-tag instance of the document title it must contain the same information - for example <meta name="title" content="Example title">.
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.
HTML structural elements, such as H1 to H6, LI, OL, and UL, are used to denote document structure rather than custom styles.
HTML elements should not be used for formatting effects such as indentation.
Use HTML headers <h1>..<h6> in document order (i.e., not styling order).
The meaning of the page title should be 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 web site, but ensures users of external search engine are presented with more appropriate results.
Items that are intended to be associated as a list are accordingly marked up as a list.
Titles should contain meaningful information in the first 60 characters.
Page titles have the same syntax consistently throughout the site.
Related Standard(s)
3.3 - Do not use deprecated features of W3C technologies on page 20.
4.2 - Publish documents in most accessible format possible on page 22.
Related Recommendation(s)
3.1.1 - Use appropriate mark-up language when it exists on page 71.
3.1.2 - Use W3C technologies when available on page 72.
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. Lists with a non-logical structure will confuse users who rely on screen readers. Also, some screen readers will read content assigned as a header in a different tone of voice to other content on the page."
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Results
All heading elements were used in the correct fashion.
3.3 Do not use deprecated features of W3C technologies
The World Wide Web Consortium (W3C) (http://www.w3c.org/) is responsible for standardising Web technologies such as HTML, CSS, SVG, MathML, etc. Deprecated features of these technologies are those that have been declared obsolete by the W3C and will in time be phased out from devices that interpret them i.e., browsers.
This requirement requires you to avoid deprecated features and to use recommended non-deprecated alternatives instead.
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.
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 prevents you from spending 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.
Sub section Text and Fonts - Families of alternatives (page 105) - Fonts should be specified as families of alternatives in order of preference.
Sub section Text and Fonts - Principal font (page 105) - The principal font should be commonly available and has in its character set glyphs for the UTF-8 encoding of the long vowels of Māori.
Sub section Text and Fonts - Font downloading (page 105) - The site should not ask people to download fonts or software to view text.
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.
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 and usable to them. Presenting information including the document size enables the user to make a decision as to whether they wish to download the document. The user may choose not to do so, for a number of reasons. For example, determining that they may not obtain a successful download with their current connection type, the download may take too long or the download may incur a degree of cost (with the user's ISP) that the user may not wish to incur. Information provided about the document type may result in the user deciding to avoid download, due to not having the necessary tools/software on hand to access the document.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Results
No links to alternative formats where found
4.2 Publish documents in most accessible format possible
If you cannot publish a document that validates to the approved formal grammars as stated in standard 3.1 on page 16, then publish the document in the most accessible format possible.
Accessible formats include:
Rich text format (rtf) for documents
Separator character separated values for spreadsheets e.g. comma separated variable (CSV).
If it is not possible or not feasible to publish in an accessible format, then the document can be published in its native (considered non-accessible) format if and only if the document is
for a specialised audience, or
considered a special-purpose document, or
a PDF document
In all cases of any of the above non-accessible format documents being published, the document must
be assisted with a summary of the key points contained within the document (which itself must validate to the approved formal grammars stated in 3.1 on page 16)., and
be assisted with contact details (which can be a link to contact details) so that the content may be discussed or requested in an accessible format., and
state why the web site is providing the document only in a non accessible format., and
all of the content provided for i., ii. and iii. is located on the web site in association with the document such that it is unambiguous as to which document this content pertains.
Notes:
"specialist audience" (as defined in the Glossary of key concepts, page 138)
"special-purpose document" (as defined in the Glossary of key concepts, page 139).
Be cautious about using proprietary file formats such as Microsoft Word or Excel.
An agency is expected to have good reason to deem a document as special-purpose and/or for a specialist audience. Your agency may be asked to justify why a document on your agencies web site(s) qualifies as such, if and when a site audit is undertaken.
Open Document Format (ODF)
ODF shows a lot of promise for open document accessibility and usability.
At the time of writing, ODF is still in relatively early days and there are still variants. It is not considered mature enough as yet to include as an accessible format, however developments and uptake of ODF will be monitored and the position on ODF adjusted and expanded accordingly.
3.1 - Documents validate to published formal grammars on page 16.
4.3 - Usage of PDF documents on page 24.
4.4 - Web site documents for specialist audiences identified as such on page 25.
4.5 - Web site special-purpose documents identified as such on page 25.
Related Recommendation(s)
4.1.3 - Compression of large files or collections of small files (page 75) - Large files made available broken down to collections of small files and/or made available in compressed and uncompressed "duo" versions.
4.1.4 - Create documents primarily in the valid formal grammars on page 76.
Further Assistance
Sub section Special-purpose documents - Special software (page 123)- When file formats other than HTML may require special software to make use of it.
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 Microsoft Word docs because they don't support embedded code and thus reduce potential virus risk.
A comma is a common separator character used for an accessible spreadsheet format (referred to as a comma separated variable or CSV format), such that it has become a de facto "standard" separator character. When the separator character is not a comma, it is good practice to use a character that is easily selected from a NZ keyboard and state with any such document what the separator character is.
PDF is not considered an accessible format, however if PDF must be used to publish a document you must:
Show the PDF version used (located in association with the PDF document such that it is unambiguous as to which document the PDF version pertains)., and
If publishing in version 8 or greater, follow and adhere to the Acrobat Accessibility Guidelines, and
If the PDF version is the only version of the content on the web site i.e, it does not qualify under exemption point ii) of standard 3.1 (page 16), then adhere to the requirements for publishing non-accessible format documents in standard 4.2 on page 22.
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).
The agency is expected to provide as much detail as possible in the associated HTML summary of key points contained within a PDF. However, this can be, at a minimum, a sentence describing what the topic of the PDF is.
Related Standard(s)
4.2 - Publish documents in the most accessible format possible on page 22.
3.1 - Documents validate to published formal grammars on page 16.
PDF format has become a de-facto standard. However, it does have some accessibility issues. The extent of the accessibility issues is related to how the pdf document has been constructed. WebAim discusses some of the issues regarding accessibility of pdf documents http://www.webaim.org/techniques/acrobat/ in more depth.
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/
Any document, content and/or forms/applications on an agency web site that is deemed for a specialist audience (as defined in the Glossary of key concepts, page 138) must state that the document/content/application is for a specialist audience, and have no ambiguity as to what part of on the web site (i.e., document, content) applies to the specialist audience.
A document for specialist audience does not necessarily imply exclusion of users outside that specialist audience. If it is intended to constrain the document to the specialist audience, then this would normally be achieved within an authenticated site.
Related Standard(s)
4.2 - Publish documents in the most accessible format possible on page 22.
3.1 - Documents validate to published formal grammars on page 16.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This applies to all information the NZ government wishes to make available to the public. Correspondingly, it is important to minimise any reasons for excluding information from being accessible to all members of the public, as much as feasibly possible.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Results
No links to specialist documents were found.
4.5 Web site special-purpose documents identified as such
Any document, content and/or forms/applications on an agency web site that is deemed a special-purpose document (as defined in the Glossary of key concepts, page 139) must state that
the document/content/application is a special-purpose document, and
why it is a special-purpose document
and have no ambiguity as to what part thereof on the web site (i.e., document, content) is special-purpose.
A special-purpose document should not imply exclusion of users who are outside of the specialist audience for the document, or who do not have the tools to make sense of the document. The specialist audience qualification can be on the basis of a specialist tool(s) to present and/or make sense of the data (e.g., an Excel spreadsheet with modelling macros). In this case, if the underlying data is intended for (not excluded from) public view, the agency is expected to provide an alternative means for users to access the data in a logical presentation format. This can be achieved via various means, such as providing contact details (i.e., phone, fax, email, online form for request submissions) for users to request the data, and in a particular the desired presentation "view". Such details can then be sent out to users who have submitted such requests. Another alternative is providing accessible online applications, which present the data online, subject to one or more user selectable criteria. This eliminates or reduces the need for specialist presentation/modelling tools to be present on the client device.
Related Standard(s)
3.1 - Documents validate to published formal grammars on page 16.
4.2 - Publish documents in the most accessible format possible on page 22.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This applies to all information the NZ government wishes to make available to the public. Correspondingly, it is important to minimise any reasons for excluding information from being accessible to all members of the public, as much as feasibly possible.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Results
No links to specialist documents were found.
Writing Content
5.1 Identify changes in natural language of document text
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 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.
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 web site has a natural language (i.e. the predominant language used for the content of the web site) of English and part of the content is describing the greeting phrase in Māori - "Kia Orā", this is a case of a change in the natural language.
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 natural language, unless told otherwise it will still attempt to pronounce the text phonetically in the natural language.
For example, if a web site 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!'
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.
The meaning of acronyms and abbreviations are not obvious on their own to all users of a web site, particularly for NZ Government 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.
Unicode is a standard that allows characters from a wide variety of languages to be encoded electronically, including the Māori macronised vowels. Unicode is now more widely supported by operating systems, fonts and browsers than was previously the case. Its use is recommended. Using altered fonts cannot guarantee this same level of support.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
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
Agency sites provide any publicly available reports the agency is required to produce by statute on their web site(s). Refer to your communications department, legal teams or representative to determine what these reports are for your agency.
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 record-keeping 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 that the agency have such documents under management with respect to archiving/record-keeping.
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 agency's record-keeping initiative, as required under the public records act (refer The Public Records Act 2005 page 135).
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); however, the mechanism for accessing them may not be online. For example, the agency may provide contact details and/or an online application form for interested users requesting access to the documents. Refer to standard 5.7 - Provide metadata to pages and sites on page 29 regarding incorporating metadata into your web site.
The National Library also keeps a record of reports that agency sites have made public. The National Library attempts to identify and capture these reports themselves. However, to assist the National Library with this process, agencies are encouraged to lodge a copy of such reports with the National Library.
Further Assistance
Public Information - examples of agency public information on page 116.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This means that the NZ Government makes all public information available where feasible.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Agency sites provide consultation documents on their web site(s). Refer to your communications department, legal teams or representative to determine what these documents are for your agency.
Consultation links on the home page should be labelled "Currently Consulting on..." for consistency across government.
The National Library also keeps a record of documents agency sites have made public. The National Library attempts to identify and capture these documents themselves. However, to assist the National Library with this process, agencies are encouraged to lodge a copy of such documents with the National Library.
Related Standard(s)
6.1 - Agency sites provide publicly available reports on page 30.
Related Recommendation(s)
6.1.9 - Media releases and consultation documents available as an RSS feed on page 82.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This means that the NZ Government makes all public information available where feasible.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
6.3 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).
Agency sites provide press notices from the agency, and links to press notices from the minister on their web site(s), for instances that set the context for a specific release of information where relevant (E.g. Budget).
Currently this is at the discretion of the agency as to where on an agency web site this is placed. Further versions of the standard may suggest, recommend or mandate where press releases are to reside.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This means that the NZ Government makes all public information available where feasible.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
The site provides an email address for each of the following:
info@<domain>
postmaster@<domain>
webmaster@<domain>
privacy@<domain>
complaints by at least one of:
complaints@<domain>
abuse@<domain>
general enquiries by at least one of:
enquiries@<domain>, or
enquiry@<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 appropriate person ultimately reads an email item coming to any of these addresses, and a response is 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.
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) for which it was sent. That is, personnel should be able to differentiate a Complaints email from a Webmaster email, and ensure that they are responded to appropriately. The agency must acknowledge receipt of the email, if this is requested by the sender. Obviously, this is to be qualified within reason, i.e. that the request from the sender is reasonable.
If agencies have concerns regarding spamming to these email addresses then
the agency does not have to publish these addresses, and
the agency is advised to investigate employing anti-spamming procedures and processes on its email server(s)
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, enhance 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.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
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 that relates to a fixed date such as a final date for submissions, job applications or an event to be held.
Related Recommendation(s)
6.1.7 - Plan in place to ensure material on the web site is accurate and up-to-date on page 80.
Further assistance
Sub section Expectations of web site content - Up to date on page 103.
Sub section Content change management - Procedures for correcting errors (page 104) - The agency has procedures for correcting errors.
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 user 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 Government.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Paid advertising is not carried, including advertorial that is unrelated to an agency's core business, unless the agency has significant involvement in a commercial event, such as a conference, where it may be appropriate to promote the event and link to a commercial web site.
The Public Service code of conduct requires public servants to "avoid situations which might compromise their integrity or otherwise lead to conflicts of interest" (see http://www.ssc.govt.nz/coc). NZ government agencies are not mandated to gather revenue via the hosting of advertising.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
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.
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.
The label should immediately precede the control in code. Screen readers read left to right. This will make it easy to read the form and make sense of it with a screen reader. See also the Irish National Disability Authority: http://accessit.nda.ie/guideline_1_79.html#directions
Poor label and control layout is potentially ambiguous to all users. Likewise, with assistive technologies such as screen readers, and more so for users with visual impairment.
Refer to the definition of tab order (page 139) in the Glossary of Key Concepts.
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 Government agency web sites, the logical order is left to right, top to bottom.
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.
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.
The main content of a web page must print correctly within the width of a portrait A4 sheet of paper.
Content must not be cut off from either side. Where a page requires landscape orientation, or specific print settings (such as adjusted margins) to print correctly it must be made clear to the user.
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.
The following article kindly provided by Pete McVicar in "A List Apart" http://www.alistapart.com/articles/printtopreview provides a discussion and examples for print preview and use of print style sheets. Coding for an example implementation of this standard is available at http://www.menace.co.nz/egovt/13.1.html, also kindly provided by Pete McVicar.
Results
Where a page requires landscape orientation to achieve this, it must be made clear to the user.Click here to confirm this
This standard is based on the Irish National Disability Authority guidelines. 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.
Consistency in a web site is a key factor for usability and accessibility, and helps create 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 does not make it clear where the user is being led, will disorient users and lead to mistakes, confusion, frustration or more simply, a poor overall user experience. Users are unlikely to willingly return to a site where the have had a previous poor user experience.
For the agency, maintenance of the site is made more difficult, which exacerbates the further degradation of usability and accessibility.
External and internal 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
Further Assistance
Sub section External Links - External link pointers on page 119.
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.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
As a minimum, every web page under ownership of the agency must have the following 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 - Agency Name". This is irrespective of whether the user is currently on a homepage. Note: 'Homepage' as defined in the Glossary of Key Concepts, page 138.
To "About this Site", as defined in standard 16.3 on page 53. The name of the link is "About this site"
To a privacy notice. The name of the link must contain the word "Privacy". The privacy notice is as per standard 16.7 on page 57 and located within a web site as per standard 16.3 on page 53.
Assists usability andaccessibility of a web site. At any point in the web site, a user should be able to return to the homepage with minimal effort. Users need to refer back to key points within a web site from any page within the web site.
Assists and reinforces the standard 15.3 (page 50) regarding the keyboard shortcuts required for NZ government agency web sites. In addition, it establishes conformity of access keys across all NZ Government agency sites. This assists users with familiarity of web site functionality within the NZ e-Government space as a whole.
Web sites that use style sheet techniques 'degrade gracefully' (definition of page 137 in the Glossary of Key Concepts), so that the site remains fully functional if style sheet techniques are ignored. 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.
Use HTML structural elements, such as H1 to H6, OL, and UL, to denote document structure rather than custom styles. People 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' (defined on page 137 in the Glossary of Key Concepts) in browsers that don't correctly interpret CSS2 or do so poorly.
This standard covers the W3C WAI checkpoint 3.3 (http://www.w3.org/TR/WCAG10-TECHS/#tech-style-sheets) for NZ government agencies.
Related Standards
9.1 - Organise documents so they may be read and still function without style sheets on page 41.
Further Assistance
Sub section Web Document Mark-Up - Styles sheets on page 119.
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, encouraged the use of style sheets for presentation.
Ensure that dynamic content is accessible. Provide an alternative presentation or page, and ensure that equivalents for dynamic content are updated when the dynamic content changes.
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 equivalent with each product selected.
As an alternative, offer a non-graphic presentation version to the user.
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.
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.
Use the <TH> element in tables for cells that serve as headers in rows or columns, rather than <TD>, which should be used for cells containing data or cells that are empty.
User agents (including assistive technologies) can render header cells distinctly from data cells even when style sheets are not used e.g. a visual browser might bold the text in header cells, while a speech synthesiser might pronounce the header text with a different inflection and/or repeat the header information for each data cell in a row.
Style sheets can be used to style the visual appearance and alignment of text in cells marked as headers.
Where a cell's contents serves as both data and header information for other cells you can use the <TD> element and use the "id" and "header" attributes or "scope" attribute for <TD> to associate data cells and header cells.
Users who rely on assistive technologies, particularly those with visual impairments, can either not see, or have difficulty seeing the structure of a table. In such cases, identifying row and column headers enables the assistive technology device to describe to the user the structure of a table.
There are two techniques for providing the association between header and data cells:
The "scope" attribute on a <TH> cell specifies the set of data cells for which that <TH> cell provides header information. The "scope" attribute can have values of "row", "col", "rowgroup" or "colgroup".
The "id" and "header" attributes on <TH> and <TD> cells. The "header" attribute on a cell specifies a list (separated by spaces) of the names of header cells that provide header information for that cell; those names are set by adding "id" attributes to the header cells.
For very complex tables, inconsistencies in the way assistive technologies interpret the scope attribute mean that a 'belt and braces' approach to ensuring accessibility of the table is to use both the "scope" and the "id" and "headers" approaches in the table mark-up.
Complex tables, such as the HTML versions of the printed financial statements from an agency's annual report, cannot readily be simplified for the web, because they still need to retain their structural integrity in order to be interpreted properly (as financial statements) by sighted users. Use of "id" and "header" attributes, at least on <TH> and <TD> cells can ensure that such tables are reasonably accessible for users of assistive technologies as well.
The Treasury has researched best practice for mark-up of complex HTML tables of data, in particular financial statements and the Estimates of Appropriations tables, which typically have multiple levels of both column and row headings.
Contact the Treasury Web Sites Manager (webmaster@treasury.govt.nz), for information about the Treasury's practice in marking up complex HTML tables and for the Treasury's extensions (commands) for Macromedia Dreamweaver® that can be used to automate the application of "id" and "header" attributes in complex HTML tables.
Users who rely on assistive technologies, particularly those with visual impairments, can either not see, or have difficulty seeing the structure of a table. In such cases, using mark-up to associate data cells with header cells enable the assistive technology device to describe to the user the structure of a table.
An additional technique that can be used in long and/or complex tables is to group rows into a table head (using the <THEAD> element), table foot (<TFOOT>), and one or more table body (<TBODY>) sections. <THEAD> and <TFOOT> contain information about the table's columns, while <TBODY> sections contain data. Dividing the structure of tables this way enables user agents to support scrolling of table bodies independently of the table head and foot. When long tables are printed, the table head and foot information may be repeated on each page that contains table data.
Do not use tables for layout unless the table makes sense when linearised. Otherwise, if the table does not make sense, provide an alternative equivalent (which may be a linearised version).
Supports the NZ Government Public Service values of Equity, Economy and Integrity.
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.
Use the "summary" attribute within the <TABLE> element.
For complex tables, the summary attribute should contain text that helps users of assistive technologies form a mental picture of the structure of the table e.g. by describing the number of rows and columns, significant groups of rows and the column headings.
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 name the table headings.
If iFrames must be used, be conscious of representing external content in the iFrame as being from the original site. If it is not obvious (i.e., transparent) that content is from another site, acknowledgement is required to be made as to any external content and where it is being pulled from. This falls under standard 16.6 - Copyright of third parties on page 57.
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.'
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Results
No frames were found.
Scripting and Applets
13.1 Pages usable when scripts, applets and other programmatic objects turned off
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.
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 web site must be available whether or not scripting is available to the user, and
Text-based alternatives are available.
If using Javascript, adopt the principals of "unobtrusive Javascript". This is principally enhancing usability without decreasing accessibility with the use of Javascript.
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.
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.
Three straightforward tips from W3C regarding alternative pages
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.
Instead of static alternative pages, set up server-side scripts that generate accessible versions of a page on demand.
Provide a phone number, fax number, email, or postal address where information is available and accessible, preferably 24 hours a day.
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.
It is so easy to only consider the common "point and 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.
The principal consideration here is with navigation devices. Design and 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.
Periodical page auto-refreshing is discouraged. However, if deemed necessary, pages must refresh at a refresh rate of 5 minutes or greater (>=5 minutes).
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.
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.
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 the option given to the user asking if they
Many users find pop-ups disruptive, annoying and frustrating, as they can feel they are not in control of navigation within the site. It 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 a return to the previous page.
Pop-ups are also problematic for screen readers, as the focus is suddenly removed with little or no notice.
Ensure that any element that has its own interface can be operated in a device-independent manner and is also directly accessible or compatible with assistive technologies.
A mouse as a navigation tool is a common example. Not all users utilise a mouse for navigational purposes. A mouse is a device that assists navigation, but not the only one. Users who suffer from one or more impairments may use other devices for navigation assistance. Correspondingly, if events catered for assistive devices and user interfaces are device specific (such as "drag and drop" with a mouse), or alternative events are not additionally catered for, they may not be recognised by other devices substituted for equivalent functionality.
Supports the NZ Government 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.
8.4 - Navigational Access Keys defined for NZ Government web sites on page 38.
Further Assistance
Sub section Designing accessible navigation - Further pointers for navigation assistance (page 118) - in particular, point 6) - provide a means of going directly to content if desired by the user.
Some screen readers read everything including links. Users of such assistive technology may wish to avoid a multitude of links. Skip links enable this.
Any web site owned by the agency which is not the 'Main' web site 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.
Note: 'Main' and 'Other' web site of an agency as defined in the Glossary of Key Concepts on page 136.
It must be clear which agency is administering a web site. For example, Studylink and Office for Disability Issues are web sites administered by the Ministry of Social Development(MSD). The Studylink and Office for Disability sites contain links back to the main agency (MSD) web site.
Contact Us. This can be a content header or a link to a page titled "Contact Us". The associated content includes full contact details, including those for feedback and complaints.
About this Site. This can be a content header or a link to a page titled "About this Site". The content within "About this Site" is specified in 16.3 on page 53
At least the name and/or the logo of the agency.
Note: 'Homepage' as defined in the Glossary of Key Concepts, page 138.
Contact details should include phone and fax numbers, physical and postal addresses and email address(es) or online enquiry forms. Explicit invitations should be made to submit feedback and complaints about the web site or overall agency comments.
The link to the all-of-government portal can be text or an image (logo), however the text or logo used should be that provided in the page to http://www.govt.nz/linking.
Related Standard(s)
16.1 - Links to homepage of "Main" agency web site on page 52.
16.3 - Minimal content within "About this Site" on page 53.
Further Assistance
Sub section Corresponding with the users - "Contact Us" (page 113) - "Contact Us" content expectations.
Sub section Corresponding with the users - Feedback (page 113) - Feedback expectations as part of "Contact Us".
Provides consistency across all NZ Government web sites - users will find these links and/or sections on all such sites.
In the case of any parts of an agency's site that are inaccessible to certain users for whatever reason, which prevents those users from accessing the information they require or completing an online transaction, it is important to provide contact details to the agency to enable such users to obtain the information and/or complete a transaction by other means.
It is acknowledged that most NZ Government agencies have a logo familiar to the NZ public, in some cases the logo being more recognisable than the agency name. By this reasoning, either the name in text and/or the agency logo as a minimum is required.
The content of the section or page titled "About this Site" contains (as a minimum):
"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)
Accessibility". This can be a content header or a link to a page titled "Accessibility". The associated content contains (as a minimum):
Access Keys, refer standard 8.4, page 38.
Other information detailing navigational aids within the site is preferred.
"Copyright". This can be a content header or a link to a page titled "Copyright".
If the agency is providing a general crown copyright statement, it is expected to reside here, refer standard 16.5, page 56 for further detail.
"Privacy". This can be a content header or a link to a page titled "Privacy".
The associated content contains (as a minimum):
A privacy statement, refer standard 16.7, page 57.
A general crown copyright statement is to be provided in the "Copyright" page or content section on the agency web sites within "About this Site", as required in standard 16.3 - Minimum content within "About this Site" on page 54.
Related Standard(s)
8.4 - Navigation Access keys used within the site on page 38.
16.2 - Minimum content of homepages on page 52.
16.5 - Crown Copyright on page 56.
16.7 - Privacy Statement on page 57.
Related Recommendation(s)
6.1.8 - Disclaiming content on page 81.
Further Assistance
Privacy;
The Privacy Act 1993 on page 134.
Guidance on Personal information and privacy on page 124.
Web sites can supplement the privacy content with additional targeted privacy messages e.g. where the web site collects information by means of a form.
Accessibility; an overview of accessibility on page 128.
Agencies are expected to condense the content within "about this site" as appropriate, to minimise the need for users to scroll down to cover at a glance all the headers as prescribed (i.e., Site Owner, Accessibility, Copyright and Privacy).
Assistance with this standard is provided incorporating this and related standards in a number of examples.
Although this is aimed specifically at a privacy notice, the multi-layering concept can equally apply to each of the categories under the other three headers.
This constitutes minimal requirements regarding the content contained within or under "About Us"/About <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 (such as clearly defining the services provided by the agency).
It should always be clear which organisation is accountable for the site.
The definition of 'homepage' for NZ government agency web sites is in the Glossary of Key Concepts, page 138.
Related Standard(s)
16.1 - Links to homepage of "Main" agency web site on page 52.
Provides consistency across all NZ Government web sites - users will find these links and/or sections on all such sites and thus the relevant information therein.
Every web site under ownership of the agency must contain a Crown copyright statement which states (as a minimum) that:-
the material on the web site is protected by crown copyright, and
anyone can utilise any of the material available on the web site free of charge and without permission of the agency provided
The material is not altered
The source and copyright status of the material is acknowledged
Any content item and/or downloadable item on the site that the agency deems to fall outside the above (i.e., outside of crown copyright) must be stated as such, together with the item.
A general crown copyright statement is to be provided in the "Copyright" page or content section on the agency web sites within "About this Site", as required in standard 16.3 - Minimum content within "About this Site" on page 53.
Any web site under ownership of the agency that contains third party material, which in part or whole is copyright material, must have the permission from the copyright owner to use.
Source and copyright status of the material on the web site, such that there is no ambiguity as to which item(s) of material on the web site the copyright pertains.
A statement must also be made (on the agency web site) that permission to utilise such material cannot be given by the agency.
It is also acceptable to have a general copyright statement for all material covered in the site. However, in this case the onus is on the agency to ensure that no qualifying material on the site falls outside of the statement, or material that does fall outside of the general statement has its own custom copyright statement associated with it.
The agency is obliged to seek permission to use such material from the copyright owners in cases that qualify under this standard.
Such material on an agency's web site includes
that presented as content items sourced from a third party
downloadable items sourced from a third party
links to web sites outside the ownership of the agency
content "pulled-in" from web sites outside the ownership of the agency
If a general copyright statement is provided, it should be provided in the "Copyright" page or content section on the agency web sites within "About this Site", as required in standard 16.3 - Minimum content within "About this Site" on page 53.
Related Standard(s)
16.6 - Crown Copyright on page 56.
16.3 - Minimum content within "About this Site" on page 53.
Agencies are obliged by government mandate to disclaim copyright of material utilised by the agency, which has not been created by the agency nor under ownership of the agency.
Every page within a web site (including a home page) under ownership of the agency must link to a privacy notice. The text of the link includes the word 'privacy'.
A web site can supplement privacy information contained within a privacy notice with additional targeted privacy messages e.g. where the web site collects information by means of a form.
The agency is expected to have a principal privacy notice, as content or a link to a dedicated privacy page, within "About this Site" as required in standard 16.3 on page 53.
Related Standard(s)
8.3 - Compulsory links on every web page on page 38.
16.3 - Minimum content within "About this Site" on page 53.
A privacy notice must communicate information clearly and comprehensively about the handling of personal information. This standard provides a government mandate that agencies are obliged to provide a privacy notice, and assists with compliance with the The Privacy Act 1993 on page 137.
The web site of the Office of the Privacy Commissioner provides an example of a privacy notice - Privacy Notice (http://www.privacy.org.nz/home.php)
Consider a multi-layered privacy notice approach. As part of this, the initial notice that is presented is a condensed version, refer Effective Website Privacy Notices (http://www.privacy.org.nz/library/effective-website-privacy-notices) for further assistance.
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 online.
Related Standard(s)
6.1 - Agency sites provide publicly available reports on page 31.
6.2 - Agency sites provide consultation documents on page 32.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Any web site that is under ownership of the agency that is
a new web site, or
an existing web site, where the overall "look and feel" or functionality has been modified
must work satisfactorily in a minimum list of web browser types and respective versions prior to being released as a production web site.
The minimum list of web browser types and their corresponding version(s) combinations is derived by those that make up 1% or more of the total web browser types/versions that have been used by users accessing the homepage of the 'Main' agency web site of the agency over a specific 12 month period. Internet Explorer 7.x ((Windows, Mac)) and/or Firefox 2.x (Windows, Linux, Mac) must be included in this list, if not already present.
Notes:
'Main' agency web site and 'homepage' as defined in the Glossary of Key Concepts on page 136.
"work satisfactorily" is defined in the context of these standards and recommendations in the Glossary of Key Concepts on page 141.
The data for providing the total web browser types/versions/operating system platform combinations that have been used by users accessing the homepage of the 'Main' agency web site of the agency are obtainable from the web server(s) that the agency uses to host this homepage.
Agencies that do not have sufficient usage statistics to determine a minimum list for testing (strictly due to having no existing web site(s) that have been in production for longer than 12 months) can utilise the list of common browsers, versions and operating systems as stated in the associated guide to this standard.
The definition of 'homepage' for NZ government agency web sites is in the Glossary of Key Concepts, page 138.
The definition of 'Main' agency web site for NZ government agency web sites is in the Glossary of Key Concepts, page 138.
The list of web browser types and respective versions is considered the minimal list for testing/quality assurance purposes.
If and when an audit is to be undertaken on one or more web sites under ownership of the agency, the agency will be asked to provide the list of browser, version and operating system combinations they have used for their testing, and the 12 month period used to determine this list.
Associated Recommendation(s)
18.1.1 - Operating Systems and Device types for sites to work on page 89, which specifies specific operating systems recommended to test the browser/version list under.
A list of common browser, version and operating system combinations is as follows:-
Minimum
The list of browser/version combinations to make web sites accessible to about 96% of Internet users.
Internet Explorer 7.x
Internet Explorer 6.0
Mozilla Firefox 1.0+/2.x
Safari 1.2+
Extensive
Add the following to the Minimal list, to extend accessibility 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.5 (Windows 2000, Mac)
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 8.0+
Opera 7.0+ (Windows)
Konqueror 3.0+ (Linux)
Comprehensive
Add the following to the Minimal and Extensive lists, to extend accessibility to 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.
One of the principal foundations of the purpose for the New Zealand Web Standards is to provide economical and equitable access to information. This applies to all information the NZ government wishes to make available to the public. Correspondingly, it is important to minimise any reasons for excluding information from being accessible to all members of the public, as much as feasibly possible. This includes minimising the barriers to accessing information or to completing a transaction on a NZ government agency web site, caused by issues related to the browser and/or browser version a user chooses to have.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
This standard is in the context of the definition of Tracking Data in the Glossary of Key Concepts, page 140.
Agencies should not hold unnecessary information about individuals, and are requested to be transparent about the information they are holding/recording about individuals.
Web site owners should consider this standard when looking at methods available for tracking user activity on a web site.
Related Standard(s)
19.2 - Rules governing storage of tracking data on page 62.
19.3 - Client side personally identifiable data storage on page 63.
Data persisted on the device on which the user is hosting their browser (e.g. client machine) is in many cases not a secure medium. It is important not to compromise the privacy of personal identity, if such information is being stored on a client side medium.
Web site users express high levels of concern about the collection of information about their activities on the Internet. (Office of the Privacy Commissioner - Privacy Survey 2006). This standard limits the purpose and use of this data, and can protect the privacy of the individual user.
This standard is in the context of the definition of Tracking Data in the Glossary of Key Concepts, page 140.
Processes utilised to collect the data can be described by an easily understood statement (minimising technical jargon) of how your agency is initiating and establishing the data-recording process for the web site.
For example:
"A script to run in your browser, which creates a file on your computer (referred to in technical circles as a "cookie") that contains a randomly generated ID. The ID is used to track which pages on our web site you have visited, and also assists identifying you when returning to our web site. The file on your computer does not identify you by any personal information. No data in this file can be used to identify you in our agency, should this file be compromised by a third party."
Also include the any details associated with the specific reasoning for the recording of such data. For example, utilising a third-party organisation who provide analytical information to your agency via collection of tracking data on your agency's behalf;
"Information is recorded about the pages you view, and basic information about your computer, such as the type of browser you are using, your screen resolution and your computer's internet address (IP address). This information is shared with Acme-analytics, a company that our agency has employed to provide web site traffic analysis processes for us."
How the data will be stored can be described by an easily understood statement, minimising technical jargon. For example, in the case of data being recorded for traffic analysis purposes;
"The aggregate data collected is stored in a database managed by Acme-analytics on behalf of our agency (include your agency name). Only authorised staffs within our agency have access to the reports created by the analysis software. Acme-analytics operates and is bound to a strict privacy policy, which they have signed with our agency."
Related Standard(s)
19.1 - Data tracking is able to be disabled on page 61.
19.3 - Client side personally identifiable data storage on page 63.
Related Recommendation(s)
19.1.1 - Scope of collecting tracking data on page 90.
Because of the requirement to be able to disable the continued recording of tracking data, a site should not have its functionality dependent on this data. Information about the recording of tracking data and user choices supports the government value of transparency.
No directly readable personal information is to be persisted on the device on which the user is hosting their browser (e.g. client machine such as a user's personal computer).
'Directly readable personal information' refers to data that would be able to reveal identity of an individual (or individuals) solely via
reading the data without the need to decrypt the data, and/or
without combining with other (secure) data
For example, a user name that is encrypted, or a reference 'handle' (i.e., a session ID) that can link to more identifiable user details server-side are examples of data relating to personal details that does not reveal individual identity.
An example of information persisted on the device hosting a user's browser session is data persisted in a client-side cookie, in the case of a user hosting their browser session on a personal computer.
If personal information is to be persisted within tracking data using only encryption, it is expected that the cryptographic module specification meets an acceptable level of security (refer FIPS-140, http://csrc.nist.gov/publications/fips/fips140-2/fips1402.pdf as a guide). Refer also to NZ Government Information Technology Security Manual NZSIT 400, http://www.gcsb.govt.nz/publications/nzsit/nzsit-400.pdf; chapter 9, which details approved cryptographic algorithms.
Note: As per recommendation 19.1.2, page 62, if it is necessary to maintain 'state', server-side session management should be used in preference to client-side session management.
Related Standard(s)
19.1 - Data tracking is able to be disabled on page 61.
19.2 - Rules governing storage of tracking data on page 62.
19.4 - Encryption of personal information in tracking data on page 64.
Related Recommendation(s)
19.1.1 - Scope of collecting tracking data on page 90.
It is important not to inadvertently compromise the privacy of personal identity. Storage of personally identifiable information, for example in a cookie, can be insecure and is open to attack from malicious web sites and software, or can be read by other users who share use of a client device.
The web site privacy notice can include information about the storage of data by a server on a client device. It is worthwhile giving thought to what constitutes personal information when deciding to persist any item(s) of tracking data. The name of an individual is the most direct case of personal information, but items of information such as phone numbers, email addresses, company employee IDs and residential addresses can enable direct personal identification with minimal additional effort. When persisting tracking data, encryption of all data is recommended. For example, if an individual's name and email address are being persisted, the integrity of the security is weakened if the name is encrypted but the email address is not. Additionally, if data labels need to be persisted, these should also be encrypted if possible. For example, a persisted data block stating
If encryption of personal information is the sole method used to prevent the information revealing identity for personal information persisted within tracking data, as required in standard 19.3 on page 65, the cryptographic specification of the encryption must meet an acceptable level of security. This can be met by utilising an approved cryptographic algorithm.
It is not recommended that personal information be persisted in any nature within tracking data on the device on which the user is hosting their browser on (e.g. client machine such as a user's personal computer).
Related Standard(s)
19.2 - Rules governing storage of tracking data on page 62.
19.3 - Client side personally identifiable data storage on page 63.
Related Recommendation(s)
19.1.1 - Scope of collecting tracking data on page 90.
It is important not to inadvertently compromise the privacy of personal identity. Storage of personally identifiable information, for example in a cookie, can be insecure and is open to attack from malicious web sites and software, or can be read by other users who share use of a client device.
The web site privacy notice can include information about the storage of data by a server on a client device. It is worthwhile giving thought to what constitutes personal information when deciding to persist any item(s) of tracking data. The name of an individual is the most direct case of personal information, but items of information such as phone numbers, email addresses, company employee IDs and residential addresses can enable direct personal identification with minimal additional effort.
All instances of requests for users to authenticate themselves in a web site utilising either the Government Logon Service (GLS) and/or the Identity Verification Service (IVS) must comply with the standards for these services, as set by the All-of-government Authentication Programme unit of the SSC.
Supports the NZ Government Public Service values of Trust and Integrity.
When two-way transactions are taking place on NZ government agency web sites, agencies need to be confident of the identity of those with whom they are transacting, and the users of these services need to be confident that any pseudonymous details they submit about themselves are secure.
The NZ government recognises the importance and significance of identity and security, and does not wish to compromise in this area.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
For exchange of personal information between web site user and the environment hosting the agency web site(s), the hosting environment must as a minimum:
Encrypt personal information using Secure Sockets Layer (SSLv3) or Transport Layer Security (TLS),
Use certificates that have a trust chain that is available in commonly used browsers.
This standard recognises the importance that government places upon the security of personal information. Agencies are required to implement Security in the Government Sector (SIGS), which includes a set of minimum internet security standards. (Department of the Prime Minister and Cabinet on 1 July 2002). Privacy Principle 5, Privacy Act 1993, states the responsibility an agency has of ensuring that security safeguards protect personal information.
A government agency must be confident of the security of personal information exchanged between a client and an agency web site.
It is good practice to perform a Privacy Impact Assessment where personal information is exchanged between client and server over the Internet, as part of initial scoping and at key stages during design and implementation. For more information about PIAs, visit the Office of the Privacy Commissioner web page Privacy Impact Assessment Handbook http://www.privacy.org.nz/library/privacy-impact-assessment-handbook.
Refer to sub section On-line payments - Card Industry (PCI) Security Standards Council's Data Security Standards on page 125 for details on these standards.
Related Standard(s)
21.1 - Security requirements for internet exchange of personal information on page 66.
This standard recognises the importance that government places upon the security of personal information. Agencies are required to comply with standards of non-government organisations when services of those organisations are utilised within NZ government agency web sites.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
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
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
It is also important that agencies have a process in place to review and respond to any information that has been submitted online. Such information often goes straight into a data store (i.e., database) and is subsequently only reviewed when someone makes access to it.
Further Assistance
Sub section Corresponding with the users - Forms on page 114.
Sub section Corresponding with the users - Indicate response timeframe on page 115.
Users are re-assured that their information has been received. In addition, users have some proof of submission, if they subsequently make contact requesting feedback to the submitted information.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Advertising of web site tenders and opportunities on or over the threshold value as stated for purchases of goods and general services (refer government procurement site www.procurement.govt.nz) are notified to Government Electronic Tendering Service.
Note: This amount is the total calculated over the entire duration of the contract including the initial term and any provisions for additional terms.
There are a number of mandatory rules agencies must comply with for procurement. Advertising on GETS is just one component of the Rules. Agencies should refer to the government procurement site (www.procurement.govt.nz) for details of all procurement rules which include the GETS requirement.
Crown entities are encouraged to apply the government procurement Rules and make use of GETS.
If your web site development comes under classification as a "Major IT project", there are further requirements of your agency to be met.
International trade agreement commitments require New Zealand government departments' procurement requirements to be notified publicly and encourage the use of electronic means for this. Accordingly, the Mandatory Rules for Procurement by Departments require Public Service Departments, New Zealand Defence Force and New Zealand Police to use GETS.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
Supports the NZ Government Public Service values of Economy and Integrity.
To ensure that these standards and recommendations are made aware to any third parties upfront. This will also be of assistance if and when there is subsequent dispute with a delivered product to or on behalf of agencies, where it is believed one or more of the standards or recommendations have been overlooked.
Examples of good practice will be added, as they become available. If you would like to suggest additions for this section, please contact web.guidelines@ssc.govt.nz.
When contracting with a service provider, the contract must specify that the provider must not independently collect or reuse data gained in the course of providing the service, unless prior approval has been given by the agency.
This does not relieve the contractor of their obligations under the Privacy Act 1993.
An external service provider can have access to personal information about a service user; can gain information in the form of server or application logs, tracking, client data, HTTP header information that includes data from cookies, and click-stream data.
The contracting out of services, for example the hosting of a web site, can include a range of issues that are similar to those faced by a government agency when hosting services in-house.
It can be good practice to perform a Privacy Impact Assessment in these circumstances. For more information about PIAs, visit the Office of the Privacy Commissioner web page Privacy Impact Assessment Handbook at http://www.privacy.org.nz/library/privacy-impact-assessment-handbook.
This is not a guarantee of accessibility or usability.
Click here to jump to the start of the results.
