Web Site Design and Operation

About this section

This section is to provide assistance for agencies in the design and day-to-day operations of their web sites, in the context of the NZ government agency web site standards and recommendations. It attempts to draw attention to the standards and recommendations, and to their respective considerations where applicable as part of their web site design and operation. Though there are a number of suggestions in this section, nothing is mandated nor strongly encouraged in this section. There are links into this section from individual standards and recommendations, but these are for example purposes only.

For those that are starting out with a web site from scratch and/or have little knowledge of what’s involved (i.e., “where do I start?”), there is a separate document created for assistance – refer to Getting started on your web site.

For those agencies that host or intend to host their web site(s) with a third party (i.e., where the agency is not hosting a web site in-house), there is a separate document NZ Government web site Outsourcing guidelines, created specifically for third party hosting situations. Staff of agencies where third-party hosting of their web sites applies are encouraged to access and read this document.

Design

Content

Content Objectives

Typically, content will flow from all sections of your organisation to your web site.

Once a year, the senior management team will want the annual report published. Research or policy teams will have reports they want disseminated every so often. There will be regular newsletters from the communications team and some vacancies to post from human resources. Projects come and go and most want to consult with stakeholders beyond your organisation through the web site.

For some users of your web site, this matters very little. They have never visited your site before and just want to know the street address of the department. The most neglected, mundane content on your site can be the most useful for some people.

Comprehensiveness of content is important for key audiences. Periodically review the site for gaps in content coverage, by means of user feedback, help desk calls (‘I couldn’t find this on your web site’) and evaluation of search results.

Audiences

Begin any consideration of content by identifying and understanding the needs of the core and non-core audiences for your agency’s site. The audience groups and their needs should be regularly reassessed, since both may change over time. Feedback from well-chosen focus groups using your site can be invaluable, for example.

Clear and simple language

This is recommendation ( 5.1.1) of the standards and recommendations, and would be a standard if not for the acknowledgement that there is a degree of subjectivity as to what constitutes ‘clear and simple’ language. A good guide is to simply review potential content and ask “can this be made simpler and clearer?”. At the point of determining that it has been made as simple and clear as can be, have one or more others review it from their perspective and further refine as required.

Acronyms and abbreviations should have their full meaning/descriptions provided – do not assume the audience automatically recognises them and understands what they mean.

Written content(i.e. English is considered the natural language for NZ Government agency web sites) within the web site should be clear and consise and free of jargon. Complex or sophisticated language should be avoided when simple language (i.e. plain English) will do.

The “fog” index can be used to give a measurable scale of readibility of text.

For further detail see:

• http://www.sharedlearning.org.uk/fog_index.htm
• http://www.usingenglish.com/glossary/fog-index.html

Expectations of web site content

Web site content should be:

• easy to understand by the intended audience
• well written
• clear and concise
• in accordance with NZ government public service value of integrity:
• • complete and free from interference
  • Authoritative.
  • Consistency of style (refer to Structuring documents)
• In accordance with NZ government public service value of economy:
• • Economical easy to digest on screen.
• In accordance with NZ government public service value of trust:
• • Trustworthy (refer to Expectations of Web Content for further detail)
  • Up to date (refer to Expectations of web site content for further detail)

Trustworthy

The content of the web site is trustworthy - free from error and clear about how errors have been corrected. Any errors identified should be corrected as soon as possible. Where the errors identified are errors of fact, it needs to be clear internally in the agency how such errors have been corrected, and clear to web site users how the fact was previously incorrectly conveyed and now corrected. Make an exception for law that is replicated on your web site. Errors in legislation cannot be corrected, as it is Law.

By continually keeping an agency's web site trustworthy, the agency is supporting the NZ Government's commitment to the Human Rights Act 1993. Supports the NZ Govt Public Service value of Trust.

Up to date

Effort should be made to keep the content of a web site up to date. Pages should show the date last reviewed/updated. Resource considerations need to be considered upfront, as part of the operational management for a web site. For management and responsibility of web site content, such resource would be expected to:

• author and/or approve new content added to a web site
• review existing pages on a web site on a regular basis to ensure all pages are up to date and make necessary changes where applicable

Typical areas to look at are content with an associated action date such as submissions, job applications and upcoming events. These add frustration to users and degrade the integrity of a site when content is relevant to a date now passed.

Many organisations (including NZ Government agencies) have this particular area of web site management as a business function (as opposed to technical) such as a communications group within an organisation.

Attention is drawn to standard 17.1, regarding preserving the context of documents and the necessity for agencies to adhere to the Public Records Act 2005, and have a record-keeping strategy when documents and/or content is superseded, obsolete and/or withdrawn from a web site.

Content change management

Immediately after making changes to any source document, the agency should then lock and store it as an official record. Refer to Record-keeping strategy.

Changes to content on a production web site should not be the sole responsibility of a single person.

A migratory process is recommended, whereby new content is 'filtered up' through testing/pre-production systems, requiring the approval of appropriate individuals before being released into the live production version of a web site. This "content change management" functionality is often incorporated into a CMS.

Publishing processes

Web site staff must have a clear understanding of how the agency publishes online and printed information.

Those staff members who are responsible for releasing and approving web content should know their roles and responsibilities in this capacity. Extending beyond this, other staff in the agency should know who to contact, either individuals of the relevant department for requesting content to be added, deleted or altered on the agency's web site(s).

The web strategy should outline the process for your agency's publishing process. It should include a review point with the printers during the proofing process, to ensure that the original master word doc is updated when the final PDF is received.

Preparing documents for publication

The agency should have clear guidelines for preparing documents for publication.

It is expected that agencies have a process made easily accessible to agency staff (for example, on the agency's intranet) for preparing content intended to be published on the agency's web site(s). Although much advice can be provided in written format in the shape of guidelines, FAQs and examples, there should also be contacts included to internal personnel for advice.

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

Procedures for correcting errors

The agency should have procedures for correcting errors, so that readers are aware that incorrect information has changed.

Attention is drawn to standard 6.5, stating the need to make clear on a web site material that is superseded.

Text and Fonts

HTML is primarily a text mark-up standard. It has a rich set of text-handling features, some of which are rarely used; others abused. Properly applied, HTML can mark-up the semantics of the document (the hierarchy of headings and lists), as well as the semantics of passages (e.g. citation) and even individual words (e.g. emphasis).

A properly structured document is more likely to make sense in an increasingly wide range of browsers than one that ignores this basic aspect of HTML in favour of purely visual effect.

Type in a web document is not "set" in the same way as a printed page. While some of the rules of traditional typography can usefully be borrowed in web document design (such as making headings stand out), attempts to constrain type on the web are likely to fail or, worse still, make the document less accessible. For many people with visual impairments, the flexibility of a web document makes it easier to use than traditional printed documents. Good typography for a web page can manage changes in font size and colour, to make it more legible to people with poor vision, while retaining the visual relationships between elements.

Fonts

The choice of sans-serif or serif does not have a great bearing on accessibility or usability. People with a strong preference for one or the other should be able to substitute your style sheet for theirs.

Families of Alternatives

Fonts are specified as 'families' of alternatives in order of preference. For example: Arial, Helvetica, sans-serif.

Principal Font

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

The principal font should also be commonly available.

Fonts and Branding

Text that must be in a particular font, say, for reasons of branding, should use an image and provide the same as alt text.

Font Downloading

The site should not ask people to download fonts or software to view text unless solely for the purposes of supporting another language, in which case the terms of use for the altered font is clear to the user and fonts are provided for different platforms.

Apart from the inconvenience and technical know-how required to install a font, fonts are usually licensed in the same way as software - to individuals or organisations. Redistribution of a font, even one altered to incorporate macronised vowels, is not acceptable unless the copyright holder explicitly grants permission. The terms of use for the altered font must be clear to the user and you should provide fonts for different platforms.

Font size

It is important that users can change font size to meet their needs. This can be achieved by adhering to standard 3.4, which requests the use of relative rather than absolute units in mark-up language, and accordingly provides assistance on expressing relative font sizes.

Font colour

Ensure that there is sufficient colour contrasting when using foreground and background colour combinations (refer to standard 2.2), and avoid utilising colour, or colour alone, for emphasis (refer to standard 2.1). Not all users have full colour recognition abilities and not all browsers handle colour.

Other font attributes

Fonts should not blink or flash, as specified under standard 10.2.

All-caps and italics (using <em> in preference to <i>) should be used sparingly: neither aids legibility in big blocks.

You should not s p a c e l e t t e r s for effect, especially in titles, which are indexed by search engines.

Underlining is not used for any items making up text and headings, as specified in standard 5.6.

Underlining should not be used for emphasis or in headings. It is too easily confused with a link.

Resources

Research on font usability can be found at http://www.stcsig.org/usability/topics/readability.html#fonts

Images

Formats

Recommended image formats are GIF and JPEG. When to use which format can be determined by:

• GIF - for images with few colours and with areas of solid colour.
• JPEG - for images with colour shading and more than 256 colours.

Portable Network Graphic (PNG) and Scalable Vector Graphic (SVG) file formats are discouraged from use, except as alternatives. Although these are W3C-endorsed formats, there is still a lack of support for them by browser manufacturers.

An alternative image format could be TIFF, as this type of image is used for topographical and hydrographical images. An HTML summary must be present when this alternative is used.

Animated GIFs are not recommended but, if used, attention is drawn to standard 10.2, regarding restrictions on blinking or flashing on a web page.

Size

Single images should be kept under 30 KB, where possible. If bigger, use thumbnails and provide links to larger versions.

Attention is drawn to standard 4.1, requesting that web documents indicate the document size and type as minimum, as this will apply also to any images referenced via a link.

The use of large images (i.e., over 30KB) should be avoided on a homepage. A homepage will be the most likely or first page visited in a web site. Usability and accessibility of a site is enhanced for a wider group of users, the more efficiently a homepage is rendered. This also assists users to make a decision to remain at the site.

The definition of ‘homepage’ for NZ government agency web sites is in the Glossary of Key Concepts.

Text in images

Reference is made to Fonts, as this applies equally here.

Using anti-alias large type (larger than 9pt) will improve the type's legibility, by making its edges smoother. The converse is true of type smaller than 9pt.

Text equivalents

It is mandatory for agencies to provide a text equivalent for every non-text element, as specified in standard 1.1.

Text equivalents (in the form of 'alt text') must be provided for all images (including each area of an image map). For people who can't see images, because they are blind or because they choose not to load them over a slow connection, alt text is essential.

Good alt text will answer the questions:

• 'Why is this image on this web page?'.
• 'What important information is contained within the image?’

Alt text within 100 chars

Aim to contain the alt text to within 100 characters. If this cannot be achieved, provide a text link adjacent to the image that leads to a separate page, which provides a longer description.

Many images on web sites convey information that cannot adequately be represented by 100 characters of alt text alone. In this case, you should provide a separate page with longer descriptions, which should be linked using text link adjacent to the image (e.g. 'Full description of Graph 1.3'). The link text should make sense out of context.

The alt text for a purely decorative image should be "" (with no space between the quotes). An example of a purely decorative image is a spacer image or a textured border.

Images displaying text for navigation are not recommended. However, if they are used, the alt text should be the same as the text in the image. Where a logo links back to the home page, the alt text should be (something like) 'Go to home page - Department Name.'

Where images are used for bulleted lists, choose between alt="" and alt="bullet". The former may be better for short lists or for a list of links; the latter for longer lists (see http://www.jimthatcher.com/webcourse2.htm).

Image attributes

Height and width attributes must be specified in the <img> element, as specified in standard 5.5.

This can significantly improve the time that browsers take to render the text part of a page, allowing people on slow connections to start reading the page before the images are delivered.

The hspace and vspace image attributes are deprecated in HTML 4.01 in favour of style sheet techniques for providing white space around images.

Colour

Colours used for text, backgrounds, hyperlinks and solid-colour graphics are suggested to be from the 216-colour web-safe palette.

These colours are common to the Windows and Macintosh 256-colour palette. Colours that are not web-safe will be dithered on a display set to 256 colours, which may affect legibility. This is also a consideration if your agency wishes to extend web-based functionality to other web enabled devices such as hand-held.

Do not refer to colours by name, e.g. "The red fields are mandatory".

Resources

See http://www.lynda.com/hex.html for more discussion on web-safe colours.

See also Text and Fonts - Font Colour, regarding text colour usages.

Video

All video should be encoded using the simplest/most widely available codec. For example, MPEG-1 is a good choice, because it is an older standard that is widely implemented and understood. Almost all media players should be able to play MPEG-1 video and audio.

There are two types video to consider - Streaming and Non-Streaming.

Multimedia standards that should be considered:

Non-Streaming

• MPEG-1 Video
• MPEG-1 Layer 3 Audio (Better known as MP3)
• AVI with Cinepak video codec, uncompressed PCM audio
• AVI with Cinepak video codec, MP3 audio
• Flash (SWF) Video/Audio

Streaming

• MPEG-4 Video (Progressive video, hinted for streaming)
• MPEG-1 Layer 3 Audio (See above)

Attention is drawn to standard 1.3, stating the requirement for a text description assisting the visual track of a multimedia presentation.

Further information

http://www.chiariglione.org/mpeg/

http://www.archive.org/about/faqs.php#146

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

Information management

Information collections

A recommended concept for structuring content material on a web site is that of "information collections".

At a high level, recommendation 16.1.1 assists in achieving this, stating "Divide large blocks of information into more manageable groups where natural and appropriate"

Not all information behaves like a single document. Documents don't exist in isolation - all documents are usually structured in some sort of context. With conventional printed matter such as books and magazines, content is broken down into related structural groups, or collections. The information collections are usually prefixed by appropriately worded headings; for example chapters, paragraphs, sentences etc. This structuring has stood the test of time and is widely accepted. Likewise, web site content is seen as no different from conventional media for employing a similar structural convention.

As with conventional media, the benefits are similar:

• It assists navigation of content. Users are familiar with such structuring.
• It assists users "skimming" over volumes of information to identify areas of interest they are searching for.
• It also gives benefits to users who rely on assistive technologies, as such structuring is also likely to enable a web site to be better understood by assistive technologies.

Information should be structured into context-related information collections, rather than documents existing solely alone. For example, you can say what the key document collections are, who owns them, and they have documented life cycles.

Providing information about document collections ( recommendation 16.1.2) and using the clearest and simplest language appropriate for a site’s content ( recommendation 5.1.1) are recommendations relevant here.

Roles and responsibilities

Agencies should have established roles and/or workgroups to take responsibility for all items of information provided directly or via a link in their web site. Such roles/workgroups should be made available (i.e. via own intranet/internal communications/awareness mechanism(s)) to all personnel in the agency.

Structuring documents

Documents prepared by government agencies are increasingly being made available on the web. Before you start writing, make a structure for the information that will work well online (or rather on-screen). Each part of the document should be more or less self-contained without being too repetitive. Although parts of the document may be linked together online much like the pages of a book, you cannot assume people will read the 'book' from cover to cover. Nor can you assume people will always start at the beginning. Search sites often take people to what looks like the middle of a 'document'.

Use plenty of headings. Headings that read like headlines often work well on screen, but it is a hard craft to master. Headlines are more than just labels. They are signposts that should tell you what you will find before you get there.

Styles and templates

The agency establishes structure with styles or templates so that the structure has meaning.

If you are using a word processor, always use heading styles, rather than simply change the appearance of words to make them look like headings. Use only a few basic styles. When pasting material from other documents, leave their styles behind (paste unformatted) and apply your own. This will save time in the long run.

Use outline views, if your word processor has them. They only work if you have used styles, and will help you organise the collection hierarchically.

It is suggested that you use templates to apply common document sections.

Presentation of dates

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

On-screen writing

Generally, what works well on screen, works well in print; but not vice-versa. A common rule of thumb is to use fewer than half the number of words appropriate for a printed document.

Consider using a larger font while you are writing. (If you are using styles, it is easy to change back to the corporate look.) A larger font gives you a better idea of how much people see online before they have to scroll. Aim to get the main points across on the first screen, putting detail further down or somewhere else entirely. Headings help here.

Provide an "executive summary" at the beginning of each web page. Executive summaries have been a part of printed documents for a long time. Online we are all "executives". Each web page we visit offers numerous choices. Each choice offers more possibilities, demanding more decisions and more of our time.

The structure of content is almost as important as the content itself. Online users expect to be able to quickly scan web content to see whether they are in the right place. Chunking of text into manageable pieces that are linked together, highlighting of key phrases and linking from summaries are all good means to improve scan ability.

Keep sentences and paragraphs brief.

Ask reviewers to read your work on screen rather than print it out. They'll quickly tell you if it doesn't work on screen (and you'll save some trees too).

Consider linking to a glossary of terms and abbreviations, rather than explaining them each time.

As mandated by standard 2.2, ensure that foreground and background colour combinations provide sufficient contrast for navigation, text and informational elements.

Write for the screen

Write for the screen not paper.

Be conscious upfront that you are writing online, web page content. This encompasses all the items highlighted as part of the Components of a Web Strategy, many of which are pertinent to web pages but not necessarily to paper based writing.

Concise writing

Sentences and paragraphs should be concise. The focus here should be on pages written specifically for the web site. Published documents that have been converted to HTML do not need to be rewritten.

Plain English

Sentences use plain and inclusive language free from jargon. This applies to web specific content. The wording considers the audience for which the content is intended.

Spelling and grammar

Spelling and grammar has been checked manually, not relying solely on computers.

Information architecture

Information architecture can be thought of as the arrangement and inter-relationships of information collections according to some defined principles. A principle might be "policy documents will be kept with the related service area of the site, rather than collected together."

There are many ways to express information architectures. Diagrams and short descriptions or definitions are often used. However it is expressed, the information architecture becomes a blueprint for your organisation's site that is ultimately expressed in its navigation and visual design.

Content management systems can provide opportunities to easily develop sophisticated information architectures that meet the needs of a variety of different audiences.

Changes

The agency only changes its web site architecture when the current architecture has no future.

A well-designed architecture should outlast changes to the visual design, and accommodate new material easily, even when the organisation itself changes.

User impact

The agency consults widely about architecture changes and tests assumptions with users.

What the agency considers an improvement to one or more of their sites from an assumed user perspective may not necessarily be considered an enhancement by true users. Agency staff members are likely to be more familiar with the agency's business than general users and will have a bias over their perspective of the agency's web site(s). It is worthwhile attempting getting a sample group of users who do not have agency 'influence' to test the effectiveness of intended changes.

Changes in URLs

The agency considers the consequences of major changes and tries to ensure that URLs are preserved whenever possible.

Changing the information architecture of a site typically may mean moving information from one URL to another. It should not be undertaken lightly. See the section Uniform Resource Locators (URLs) for further details on URLs.

Disaster recovery

This is an area that is often overlooked. However, like having house insurance, it only becomes relevant when an undesirable event happens. If and when such an event takes place, the outcome is likely to be critical if no prior allowances have been made for it. Agencies are thus strongly recommended to have a disaster recovery plan.

The following are pointers for managing disaster recovery:

• A comprehensive disaster recovery plan is set out whether the site is hosted in-house or hosted externally, in which case this should constitute part of the contract – recommendation 31.1.1.
• The disaster recovery plan covers the host’s routine backup procedures and sets a maximum time for recovery from failure.
• If the web site(s) is hosted by a third party, the agency should keep separate backups of documents and data from those held by the host.

Web site required items

Different types of sites have different requirements for content. The focus of this section is on single-agency public web sites. Sites for agency business units or sites hosting links to multi-agency sites will have different requirements.

Web Site Types

It is important to first understand the distinction between the two types of web site that NZ government agencies are expected to have. These are:

• "Main" agency web sites. For the official definition, refer to the Glossary of Key Concepts.
• "Other" agency web sites. For the official definition, refer to the Glossary of Key Concepts.

Web Site "Home" Pages

There are minimum requirements for agency homepages of web sites.

Homepage

Any web site under ownership of a NZ Government agency will have one page deemed as the "homepage" as defined in the Glossary of Key Concepts.

Simply put, web sites are collections of web documents, associated with a domain, that are interlinked in such as way that any part of the collection can be reached by following a series of links starting from a home page.

Homepages are often called on to serve other purposes (like showing important news stories) because they play such a central role, but typically a homepage should have little content of its own.

Documents linked from a homepage will usually have a common set of navigation links repeated on each page

A homepage is displayed when http://www.domainname/ is requested for the agency or its respective Business Unit. The request should not depend on a file type being specified (as in http://www.domainname/index.html).

Homepage requirements

Standard 16.2 describes the minimum requirements of a homepage on any NZ government agency web site.

Refer also to Standard 16.1, for information about linking to Main agency homepage.

If Search facilities are offered on an agency's site, then:

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

Identity of site

A homepage for a site that has cross-agency links reflects the identity of the site, rather than the lead or host agency. Users should still be able to distinguish between the agencies participating in a cross-agency site and the agency responsible for the site itself.

Contact information

Multi-agency sites make it clear whom people should contact about which parts of the site.

Cross-agency links

NZ Government agency sites should, as a matter of course, cross-link together where discussion within the agency(s) has concluded that this would add accessibility benefits to users. Cross-agency linking should not be put in place for the mere sake of it.

Links from homepage

The main sections of the site are linked directly from the homepage; homepages are not merely 'splash' screens.

New information

The user can clearly identify where to find the site's new information. If the agency has continual new content, the agency may wish to present details of new content in a "What's New" page.

Corresponding with the users

It is important that the agency be seen as approachable from all potential users. For many agencies, most of their key audiences will be the general public.

A mandatory requirement of a homepage is the requirement for “Contact Us”, as stated within Standard 16.2. This may be a header and underlying content section, or a link to a dedicated "Contact Us" page.

"Contact Us"

The "Contact Us" section or web page should contain all necessary contact details for any user who wishes to make contact with any part of the agency, including feedback to the agency regarding the web site(s). This includes for the main and any branch offices:

• phone and fax numbers,
• physical/postal addres(es)
• email address(es). See also standard 6.4, regarding mandatory email addresses.

For generic email addresses, there should also be equivalent physical and postal addresses on the web site. This applies to cases of all email addresses within the web site.

The site uses role-based, rather than personal email addresses on web sites. For example, librarian@natlib.govt.nz.

If there are specific areas that the agency prefers people to contact for business relating to those areas, make it clear on this page or break the section down into the business areas and the respective contact details for those areas.

It should be noted that these contact details constitute an important part of accessibility (for alternative contacts) for those users who cannot utilise (for whatever reasons) any online form-based feedback and/or application facilities that the agency may offer.

Feedback

As part of "Contact us" is the expectation that details are provided for feedback. It is preferable to have an on-line form for users to submit their comments. It is important that agency personnel do frequently review feedback submitted.

A complaints procedure should be in place for people wishing to make a complaint about the agency and/or the agency's web site(s).

Postal, Phone and Fax

These traditional contact methods (and medium) are still the foremost methods used for contact. Some users are often comfortable only with the oldest of these methods - postal.

It is imperative that details of these contact methods be present wherever contact details are provided on the web site.

Email

The use of email has become a fairly standard means of communicating and contact. It is as much an expectation as phone and fax numbers. It also lends itself well to web applications.

It is expected there will be one or more email addresses in the "Contact Us" and potentially likely in the "Feedback" page.

There are also mandatory email addresses that must exist, whether published or not, in association with an agency's web site. See standard 6.4 for more information.

When utilising email addresses for correspondence purposes anywhere in the web site:

• For generic email addresses, also include equivalent physical and postal addresses.
• Use role-based, rather than personal email addresses on web sites. For example, librarian@natlib.govt.nz.

Online Transactions

Online transactions collect personal information, and often create additional records that include transaction logs and tracking data. It is good practice to perform a Privacy Impact Assessment (PIA) 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 at http://www.privacy.org.nz/library/privacy-impact-assessment-handbook.

Online Payments

Online payments in NZ are via credit card. As of Jan 2007, EFTPOS will also be available.

If your site is to take online payments, all pages relevant to the payments process must be secure, as defined in standard 21.1.

You should contact the bank that your agency utilises for its general banking, for assistance regarding incorporation of online payments facilities in the agency's web site(s).

Full details of customer's credit cards should not be persisted. The agency needs to consider the risk (and the need) of doing so. Generally, the first 4 and last 4 digits of the credit card number are recorded, if there is need to record them at all, such as if there is any post-transaction customer dispute regarding billing.

Any persisting of payment card details should have the details made clear that this is taking place, what specifically is being persisted and why, in a web location pertinent to the payments process and/or in the disclaimer page.

Forms

Traditional printed forms are now available electronically on most government web sites. They are either electronic replicas of the printed form (e.g. PDFs), designed to be downloaded and printed, or forms that are completed on-screen and submitted online.

Online forms

Accessibility concerns are addressed by providing a form designed for online submission.

A form designed to be completed online will be more accessible than one that can only be printed.

Forms designed to be completed on-screen and submitted online are in HTML or XHTML. This is a qualification of Standard 3.1.

Brief help notes for online forms can be provided in a logical association with the controls on the online form. More comprehensive help should be placed in the "Help" page, with navigation link to the Help page suitably placed on the online form.

Confirmation of forms submitted

Reference is made to standard 22.3 requiring users to receive online confirmation that the information they have submitted has been received.

Online Forums

Forums (also referred to as bulletin boards) are usually a form (or forms) provided as part of a web site, to enable general opinion and comments to be captured by people who have access to the site. Likewise, they allow people who have access to the web site to be able to view the opinions and comments of others. The audience of those users may or may not be restricted (and likewise authenticated). In many cases, the forum is open to public free-form opinion/comment and public viewing (of such opinions and comments).

Considerations if hosting

Considerations if an agency chooses to host an open forum(s) are:

1. Seeking legal advice. A particular area of consideration is an appropriate disclaimmer.
2. Forum moderation. Users can add to the forum, but the content is not immediately reflected back on the forum for general view. It is queued for moderation (by a "real" person). Such content is either not released at all, or modified accordingly to satisfy the agency's own terms and conditions for open forum content. Agencies should state on the forum that the agency has the right to modify any content received, and the right to not publish it at all.
3. Defamation. Key areas to consider are:
   • that the opinion on an open forum does not necessarily reflect the opinion of the agency
   • that the language used in an open forum can potentially be classified "offensive"
4. Privacy:
   • There may be issues that should be assessed for compliance with the Privacy Act 1993 when operating a web site forum e.g. disclosure by a forum user of personal information about another.
   • The web site privacy notice should inform users about personal information and the forum.
5. Authentication. Constrain writing to the forum to individuals who have authenticated themselves as a prerequisite. If user registration is done online, users with malicious intent can still register and subsequently add undesirable content. However, users (via registration details) can be “locked out” from writing further content, if found abusing their privileges with writing to the forum.
6. 'Captcha's. An increasing trend to be aware of is “bot attacks”, where auto registration of user registration (where facilitated on sites) is attempted. The subsequent purpose is essentially for “hacking” into such sites. Implementing 'Captcha's is a common way (though not entirely foolproof) of preventing this.
   For further details, refer to the following sites:
   • http://www.captcha.net/
   • http://en.wikipedia.org/wiki/Captcha

Attention is drawn to recommendation 31.1.2, recommending that agencies choosing to host a forum to (as a minimum):

• seek legal advice, and
• moderate the content that is written to the forum and/or authenticate users prior to writing content.

Printed forms

All forms intended to be printed print correctly in black and white on A4 paper.

Any forms intended for printing do not contain:

• background colours, and/or
• shading, and/or
• blocks of colour

that will be expensive for people to print from their computer. It may be worth noting that “forms” also includes downloadable documents and web pages.

Indicate response timeframe

If there are further steps the agency will take in response to a form submission (for example, replying to a question), this should be clear and a timeframe provided to show how long it is likely to take.

Items of Public Information

The following lists elemental items, some of which must be on a NZ Government agency web site, others that are expected if and when they apply to an agency. It is at the discretion of the agency as to where these items are on the site, the only proviso being that it should be clear, either by navigation from a homepage and/or a search facility as to location of the material.

Reference is made to standard 6.1, which states that agency sites provide any publicly available reports, standard 6.2 requiring agencies to provide consultation documents and standard 6.3 requiring agencies to provide press notices from the agency and links to press notices from the minister. Recommendations 6.1.2, paper based forms provided by an agency are made available on its web site, and 6.1.3, agency sites provide contact details for specific policy or services, are also recommended for consideration.

Examples of agency public information

Bearing in mind the intent of the Official Information Act that agencies make information available unless there is a valid reason to withhold it, single-agency sites should provide:

• Legislation or regulations for which the organisation has the lead responsibility, or a link to a site that contains the legislation or regulation in full.
• Membership and terms of reference of any advisory groups.
• Agency purchase agreements and similar defining documents.
• Links to other primary sources of information relevant to the organisation's functions
• Agency sites provide research reports and statistical information. (Be mindful of accessibility of data tables, graphs. Variety of formats if possible, e.g. CSV, Excel. Some models e.g. Treasury's long term fiscal model - should be considered special purpose documents, because modelling can only be done using Excel.)
• Agency annual reports
• Strategic plans
• Statement(s) of Intent

Navigation within the web site

Common navigation elements

Most web documents start with a block of global navigation that links to a home page in the site and to the main sections of the site. This block may also link to important pages that describe the purpose of the site, who to contact in the organisation and a search page.

There is then a block of navigation specific to the section of the site. Following this is the content itself (sometimes mixed with navigation).

Finally, there is a block of general navigation linking to pages that describe privacy and security, contact information, other related sites and the site's home page.

Not all sites are like this, but most are.

Various techniques are used to lay these elements out as an aid for visual users of mainstream browsers, such as placing the links on the left and the content on the right in a table. Similar consideration is given to users of screen readers and Braillers, or users of browsers (on hand-held devices) that ignore tables so that the links and content are presented in a sensible order.

Designing accessible navigation

Traffic lights are a tool of navigation that everyone has to use in their everyday life. For pedestrians with sight, there are lights. For pedestrians that can hear but not see, there are sounds. For pedestrians that can neither see nor hear, there is a vibrating pin below the button you press when you want to cross. In other words, traffic lights adapt to the needs of a variety of users.

The web was designed to be adaptable too, but design for the web often overlooks this.

Text is the most efficient way of creating navigation labels. As text, a word like "Contacts" takes 8 bytes. As an image, it will be at least 50 times as large and the text will have to be provided in any case, as alt text.

Text is accessible. Text can be read or spoken. Properly designed, users with poor vision or motor control can make it bigger or change its colour. You can't do that with an image. Underlined text, usually coloured blue, is universally recognised by visual users as a link.

Navigation blocks are usually lists of links. It is important that the list is properly punctuated.

Attention is drawn to standards 8.1, requesting the target of each link be clearly identified and everything that is a link is obvious as a link, and 7.3, requesting the inclusion of non-link, printable characters between adjacent links.

The WAI Accessibility Guidelines recommend putting a printing character like a " | " between adjacent links. This can help users of older screen readers, as well as people with motor impairments. A tab index for link lists can also help people who have difficulty controlling a mouse to tab through to the link they want in a predictable order.

Client side scripted menus (see Scripting) can obscure the destination of a link, be ignored by users (that can't or don't want to run scripts) or blocked by firewalls, be difficult to use if you have trouble controlling a mouse, add considerably to the size of a document and lead occasionally to fatal errors in older browsers. Careful assessment of the needs of users and the benefits of client-side script should be made before adopting this approach. Adding accessibility features to global templates is not onerous.

One kind of image-based link aids accessibility for non-visual users and should be added to the beginning of every web document. A single-pixel "invisible" image that links to an anchor at the start of the main content of the page. Visual users don't see it, but non-visual users hear it at the start of the page so they can avoid hearing the global navigation block yet again.

Image maps

Unless the areas are complex non-geometric shapes, for greater potential (over server-side) for making accessible, image maps should preferably be client-side.

Reference is made to standard 1.2, which requests to provide redundant text links for each active region of an image map, and to use client-side image maps over server-side image maps.

Image map navigation

Image map navigation should only be used when the spatial relationship between parts of the image are important in determining the destination of the image map links. For example in a map of New Zealand divided into regions.

Standard 1.1 is also relevant here, requesting that a text alternative be provided.

Access keys

Access keys are particularly useful for people who have difficulty using a mouse. Their use, which normally involves a simple change to a global template, is required on government web sites.

Provide the NZ Government web site Navigation Access keys globally throughout the web site, as mandated in standard 8.4. Help details describing the Navigation Access keys should be in the “Accessibility” page or content section. Refer to standard 16.3, regarding minimum content within “About this Site” for detail of the compulsory “Accessibility” page.

Further Pointers for Navigation Assistance

These are predominantly standards that are required for navigation within NZ Government web sites:

• provide text-based navigation (even when client side script menus are used)
• Create a logical tab order through links, form controls, and objects - Standard 7.2.
• Use elements to convey document structure, and mark up lists properly - Standard 3.2
• Do not use mark-up to redirect pages automatically - Standard 14.2.
• The web site should not require a user to download a plug-in, in order to navigate the site.
• Provide a way for the user to detect and skip over lists of unwanted links - Standard 15.4.
• Provide a means of going directly to content if desired by the user. Some assistive technologies will read everything. This can be cumbersome and frustrating for users of such technology, if they have to persevere with and cannot "jump over" content items they have no interest in. Utilising skip links (standardised labels) is one way of addressing this.
• Provide keyboard shortcuts to important links - Standard 15.3.
• Provide information about the general layout of a site (e.g. a site map or table of contents) - Recommendation 16.1.2.
• Use navigation mechanisms in a consistent manner - Recommendation 8.1.1.
• Provide information about document collections (i.e. documents comprising multiple pages.) - Recommendation 16.1.4.

External Links

For many commercial organisations, it is desirable to keep people on their site and not distract a potential customer with links to other sites. Government sites, however, should as a matter of course link together where this would be helpful for people. Linking sites in this way is a useful first step toward a more integrated view of online government services. It may also avoid having information in more than one place and the consequent problems of maintenance and conflicting advice.

External Link Pointers

External links are valid (refer standard 8.2). A link has no use to the user if it takes them nowhere, brings up an error, or takes them to a valid web page but not the page intended by the link.

External links are to the nearest URL, such as http://domainname/news/2002/October/, that will not be affected by changes to the site, not just to the site home page.(Also need to consider the value to the user of providing the link in the first place. Sometimes a very specific link can be useful, but this must be balanced against maintenance.

External links make the destination of the link clear. Linked text should describe the subject matter of the destination. For example, '...read the report on MED web site' or 'read the MED report (external link)' rather than, '-read this report' - does not indicate to the user that they are leaving the site. Text is not needed if it is clear by the context e.g. if the link is in a 'Links' section of the web site.

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

Be open to requests for you to link to other government web sites. Though this isn't necessarily an item to consider for your agency's web site's URL naming, it is a pointer that other agencies may well wish to link into your site(s) and include your URLs in theirs too!

Web Document Mark-Up

The web was founded on Hypertext Mark-up Language (HTML) and HTTP, the protocol for its transport. Early browsers only loosely adopted earlier versions of the W3C HTML recommendations, notably version 3.2. This led the W3C to revise the recommendation and encourage browser manufacturers to follow more closely the new specification, version 4.01.

HTML 4.01 reinstated HTML as primarily a structural document mark-up language based on SGML, by "deprecating" some display mark-up tags (notably the <font> tag) and encouraging the use of style sheets for presentation.

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 now.

The NZ Government uses the W3C endorsements of protocols and their respective versions as a basis for NZ Govt agency protocols and versions. These are considered as "formal published grammars". A web site is considered "valid" in the context of these endorsed protocols and versions thereof if they adhere, or "validate", to these formal published grammars.

Specifics of such protocols and their versions for use by NZ Government agencies for their web sites are stated in standard 3.1, mandating the formal grammars to which all documents are expected to validate.

Use of Mark-up protocols

The mark-up protocols should be used primarily to mark-up the document structure, not merely to control the visual appearance of the document.

Proprietary elements should be avoided, in particular elements such as LAYER and COMMENT.

Style sheets

Style sheets are text files that some browsers can interpret to change the way web documents are rendered. Style sheets separate formatting from the content of a web page, permitting different views of the same information for different purposes without duplicating the content. The W3C recommendation, Cascading Style Sheets (CSS) , has two levels. CSS1 is widely supported by mainstream browsers, and CSS2 , which extended the standard, is achieving more support from the leading browsers. Sites designed with CSS are generally more adaptable, and therefore more accessible. People can ignore your style sheet in favour of their own, if they need to. They are also adaptable in the sense that a single change to a style sheet can affect documents site-wide.

Support for style sheets is not universal, even for more recent browsers, and will have no effect on non-visual browsers. It is therefore important that style sheets are used in conjunction with proper structural mark-up in the allowable NZ Government mark-up protocols (stated in standard 3.1, “Validation to published formal grammars for NZ Government web sites”) and are used conservatively. In other words, make sure text is properly marked up to signify document semantics (headings, lists, emphasis, etc), rather than use styles to change appearance alone.

Attention is drawn to standard 9.2, requesting the use style sheets to control layout and presentation of page and elements, and standard 9.1, stating that (given the request of standard 9.2 to use style sheets), a site should not rely and/or be dependent on style sheets.

Scripting

It is important to distinguish between Server and Client side scripting languages. Server side such as such as PHP, JSP, Perl, etc. still render a web page in HTML, which conforms to NZ Govt web standards. Client side scripting, the most popular of these being Javascript (Jscript for Microsoft web browsers), are generally easier and faster to code in than precompiled languages, but they also have issues.

A web browser user generally has full control over any client side scripting. As a result scripting should not be used for any authentication-related processes nor any processing of information that, back on the server side, is to be taken verbatim. For example, a calculation to determine a final price of a product or rebate due to a user should not be performed via client side scripting - a clever user can easily go in and manipulate the calculations!

Scripting also poses issues in some cases with accessibility. Some assistive technologies can become confused with the client side manipulation of the web page dynamically.

Most web browsers do have the ability to "turn off" (i.e. ignore) client side scripting.

Because of issues that can arise with scripting, some organisations disable it altogether (overriding the user's preferences) for the browsers supported in their organisations.

Attention is drawn to standard 13.1,stating that pages are required to be usable when scripts are turned off or not supported. If this is not possible, provide equivalent information on an alternative accessible page.

Unicode and Macrons

Te Taura Whiri i te Reo Māori (Māori Language Commission) recommends use of the macron to mark long Māori vowels. The reliable rendering of the macronised Māori vowels in browsers has been problematic for some time. The problem stems from a combination of character encoding, operating system support, the availability of fonts and browser behaviour.

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.

To reliably render Unicode-encoded documents in browsers, web documents have to correctly specify the encoding that the browser should use to interpret the stream of bytes it receives after the document is requested. This is best done by configuring the web server to modify the HTTP header, but can also be done with the "charset" parameter in the content-type declaration at the beginning of the document, e.g.

<META http-equiv="Content-Type" content="text/html; charset=UTF-8">

Most browsers will attempt to render a document even if the declaration is missing. Often this will mean empty or unintelligible characters appearing in the user's browser, especially when the characters do not belong to the earlier, much smaller character sets, like ACSII and ISO-8859-1, which some browsers may assume when the intended character set is not declared.

UTF-8 is an encoding that references a subset of the full Unicode character set that must be specified in the content-type declaration. UTF-8 encodes the Māori macronised vowels.

A document with Māori words that is declared as charset=UTF-8 can be prepared in one of two ways:

• Using a font in a UTF-8 compliant authoring tool, which makes the encoded characters visible, so non-technical authors can see the macron. This is the preferred method.
  Note however, as stipulated in standard 5.4, that authors do not use altered fonts that substitute umlauted vowels for macronised vowels.
• Using HTML numerical character references (NCRs), which allow authors to use authoring tools that are not UTF-8-compliant. NCRs are sequences of plain ASCII characters that together encode a single UTF-8 character. This method is marginally less reliable across a range of browsers.

The numerical character references for the Māori long vowels are:

• Ā &#256;
• ā &#257;
• Ē &#274;
• ē &#275;
• Ī &#298;
• ī &#299;
• Ō &#332;
• ō &#333;
• Ū &#362;
• ū &#363;

Note: the trailing ";" is required.

A way is provided to view the site without macrons, for those who cannot see the macron rendered correctly.

Resources

Macronisation of Web Content report

Unicode

Web Document size

It is neither fair nor reasonable to have to wait long for a large web document to load before you can assess whether it is relevant or useful. Load time depends on many factors - server response, connection quality, modem speed, caching, PC specification and the efficiency of the browser – factors that are well beyond the control of content providers.

Document size, however, can be controlled. The size of a web document is the combined file size of the HTML document, any external script files or server-side includes, and images.

In ideal conditions, a 55KB homepage (including graphics) will take 46 seconds at 9.6kbps; 30 seconds at 14.4kbps; 15 seconds at 28.8kbps and 8 seconds at 56kbps. Many rural users in New Zealand are currently only able to connect at the equivalent of 9.6kbps or less. You should not assume that dependent files, like images, have been cached.

The following are further pointers for managing documents size:

• Web documents primarily concerned with navigation, particularly homepages, should not exceed 55KB including graphics, scripts, etc
• Web documents primarily delivering content should not exceed 100KB
• Web documents provided for special purposes such as printing a complete report, should not exceed 300KB.
• Links to web documents indicate as a minimum the document size and type which must either be included in the link itself and/or in the TITLE tag. Standard 4.1.
• A version of the document type is provided where applicable. Recommendation 4.1.2.
• Comments should be few and short, adding little to the size of the web document.

Special-purpose documents

HTML documents are not always suitable for printing, calculation, editing or the needs of specialist audiences (e.g. geospatial data). Web documents may link to files in alternative formats that meet specific needs like these. However, basic content and services provided by the agency responsible for the website must be as accessible as possible.

Users need to have some warning when they are about to be presented with a special-purpose file, such as the format and file size (refer standard 4.1). An appropriate way to do this is to use an intermediary HTML page that carries an abstract or description of the file, including a description of its format and size, and the purpose in providing it. Search tools more easily index intermediary pages like this, but simply including the file size in the linking text is also acceptable.

Special software

It is clear to all users that file formats other than HTML may require special software to make use of it. Links to sources of free software to read those formats should be provided if available.

Refer to standard 4.2, which states what to do if you cannot publish a document that validates to the approved formal grammars (i.e., HTML) and standard 4.3, which states the minimum requirements if you must publish a PDF file. Reference is also made to recommendation 4.1.3, recommending large files or collections of small files to be made available in both compressed and uncompressed versions (and with an associated link to a suitable decompression utility).

Uniform Resource Locators (URLs)

The similarities and differences between the filing system of a desktop PC and a web server's URLs have probably caused more problems than any other since the web became an essential tool of government, business and communities alike.

Web servers are designed to separate the file structure of their operating system from the URL scheme in the domain they serve. In other words, once you have assigned a URL to a document, there is no reason to change it, provided you have chosen it well.

For example, the Web Standards and Recommendations are available, at a discovery level, from the permanent URL http://www.e.govt.nz/web-guidelines/web-standards-v1.0. The resource available from this location is currently a document called index.asp. In time, it might become index.php or index.xml. The file itself might be moved in the operating system file structure, perhaps because a future content management system stores documents in a /docs/ directory.

When it does, the URL will not change, provided the web server is properly configured and URL requests are directed to the correct file, wherever it might be. This is best done by remapping URLs to files, but can also be done by leaving a file in the original location and redirecting the request to the true location of the document assigned to this URL.

Designing URLs

Discovery-level URLs reflect a general hierarchy and grouping of documents relevant to their function. For example, a user may not want to understand the internal workings and structure of a Government Agency. They may simply want access to the service or information. This grouping is also an accessibility factor for search engines.

URLs should be carefully chosen, succinct and meaningful.

They should not, where possible, refer to the specific technology used to deliver the information, since this is likely to change eventually.

Succinct permanent discovery-level URLs should be used.

If a content management system (CMS) is employed, a CMS that doesn't enable the use of succinct permanent discovery-level URLs that show up in the address bar should be avoided.

The URL of discovery-level documents should not change. For example, if a site has a '/news/' or a '/docs/' section, these should continue to work, even if the site has been changed.

URL and File Naming

A few simple rules for file names (and URLs) will help web teams manage links within your sites:

• Use lower-case only and do not use mixed case. This will aid a seamless migration from a non-case-sensitive web server platform to a case-sensitive platform, if and when such a migration ever takes place. If however you are confident such a migration will never occur for your site(s), then this suggestion has little relevance.
• Avoid the usage of underscores in URLs. Underscores get 'lost' in underlining - recommendation 6.1.5.
• Discovery level URLs use descriptive and less than 50 characters long - recommendation 6.1.6.
• File extensions in URLs are used consistently. This should apply throughout the site (always using .html in preference to .htm, for example).

If appropriate, authors should always refer to the nearest stable discovery-level URL, rather than using a 'deep' link that may change. Sometimes a deep link is necessary (e.g. in the case of news items, we would want to link to a specific news item with a deep link, rather than to a general news page), but agencies are encouraged to limit the use of deep links to the highest levels (e.g. http://www.agencyname.govt.nz/taxes/company/).