6 Delivering content
6.1 About this section
This section covers both the standards-based approach to delivering government website content in an accessible way and how to apply those standards in practice to deliver equitably.
Business and website managers, communications and IT support teams, and vendors should read this section.
6.2 Web content accessibility
Public sector organisations are not like those in the private sector. Each has a monopoly in the service area it administers. As such public sector organisations must deliver services in a way that is accessible to the people it serves.
Digital delivery has the potential for significantly greater accessibility to government information and services. Visually impaired people, for example, who have until recently been poorly served by print and proprietary electronic media can now read web content as Braille or hear it with voice browsers.
There is some truth in the saying that "100% of people use the browser they prefer." Visually impaired people may prefer a voice browser, people with older computers may have older browsers, some may have up-to-date browsers but prefer a black and white screen, and others may prefer not to buy a computer that can run the latest software.
In other words public sector organisations must design websites in a way that is flexible and adaptable, rather than for one or two leading brand browsers. This is all the more so now that there are more browsers, alternative platforms and different devices to choose from. This trend is likely to continue.
Designing adaptable sites supports the principle of equity. It also supports the principle of economy. Adaptable sites are simpler to maintain, less likely to conflict with newly introduced browsers, require less support from site managers when users have trouble using your site, and are easier and therefore less expensive to build in the first place.
Requirements
You must
- Design sites to be adaptable from the outset.
- Not design specifically for one type of browser.
- Consider the needs of people with impairments from the beginning and throughout the design process.
6.3 A standards-based approach
The application of Internet standards, such as the HTML 4.01 specification, will not in itself ensure a site is accessible. There are many ways in which the standards can be applied that hinder rather than aid accessibility.
The standards-based approach makes it more likely that your site will render useably across an increasingly diverse range of browsers. Inevitably there will be some incompatibility between the site's design and one browser or another. The approach advocated by these Guidelines is to follow the standards, and apply any necessary work-arounds that remedy the short-comings of individual browsers.
The importance of thorough testing across browsers and platforms cannot be stressed enough (see section 6.5).
6.3.1 Role of the World Wide Web Consortium (W3C)
The World Wide Web Consortium (W3C) sets Internet standards by making Recommendations. W3C recommendations are reviewed to ensure that accessibility is considered at an early design phase. The recommendations are developed in an open process of consensus building.
Use of W3C recommendations provides government organisations with a stable, common point of reference. It also supports the development of the W3C recommendations, on which much of the potential of the Internet and e-government relies.
The recommendations of the W3C aim to "lead the web to its full potential". While paying close attention to the consortium's recommendations, the principles of equitable access and economy must also be applied. The Custodian of these Guidelines will regularly review the recommendations of the W3C and their impact on equitable and economic access to public sector websites for future revisions.
6.3.2 Web Content Accessibility Guidelines 1.0
Most of the recommendations of the W3C are technical. The W3C Web Content Accessibility Guidelines 1.0 or WAI (Web Accessibility Initiative) guidelines, as they are sometimes called, are different.
They recognise that what matters is that people are not impeded in their use of content on the web. Each of the WAI guidelines (there are 14 altogether) has a number of checkpoints. Each checkpoint has a priority level: 1, 2 or 3.
Requirements
Content on New Zealand government websites must be developed and presented in accordance with the WAI guidelines. Content developers
- must satisfy priority 1 checkpoints (see exemption below)
- should satisfy priority 2 checkpoints
- may satisfy priority 3 checkpoints
of the Web Content Accessibility Guidelines 1.0.
Exemption: The WAI requirement to identify changes in natural language with the lang attribute (http://www.w3c.org/TR/WCAG10/#gl-abbreviated-and-foreign) does not extend to the Māori language in these Guidelines while support for correct rendering in screen readers does not extend to the Māori language.
Recommendation
Since a number of the priority 2 and 3 checkpoints are not especially onerous to implement, agencies should aim to go beyond the requirements of priority 1 where this can be done economically.
Resources
WAI Web Content Accessibility Guidelines 1.0: http://www.w3.org/TR/WCAG10/
Web Accessibility In Mind (WebAIM) is a useful collection of resources about online accessibility: http://www.webaim.org/ .
Bobby (http://webxact.watchfire.com/) is one of several tools that can help you assess your site's accessibility.
Viewing your site in a text-only browser like Lynx (http://lynx.isc.org/release) may also highlight accessibility issues for you. Impaired users are best able to tell you where the difficulties may lie. Lynx-me shows web documents as Lynx 2.7.1 sees them: http://ugweb.cs.ualberta.ca/~gerald/lynx-me.cgi?url=URL
6.3.3 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.
Requirements
The primary format for all content available on government websites must be HTML. The HTML must validate to the HTML 4.01 Transitional specification or earlier HTML specifications. Other formats may be provided to supplement content in HTML.
Agencies wishing to adopt XHTML in favour of HTML must seek an exemption from this requirement from the E-government Unit.
Recommendations
You should use HTML primarily to mark-up the document's structure, not merely to control the visual appearance of the document.
Although deprecated tags are part of the HTML 4.01 specification and therefore will not make a web document invalid HTML, you should avoid their use in favour of newer methods of achieving the same thing. The tags deprecated in the HTML 4.01 specification are <applet>, <basefont>, <center>, <dir>, <font>, <isindex>, <menu>, <s>, <strike>, <u>. You must not use proprietary tags like <layer> and <comment>.
Valid code is not a guarantee of problem-free rendering in all browser types. You should check how adaptable your code is in different browsers on different platforms and various devices (see section 6.5).
Resources
HTML 4.01 specification: http://www.w3.org/TR/html401/
W3C HTML validator: http://validator.w3.org/
XHTML 1.0 specification: http://www.w3.org/TR/xhtml1/
See section 6.4.2 also.
6.3.4 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 HTML 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.
Requirements
You must not use style sheet techniques that are poorly supported in browsers. You must test thoroughly in a variety of browsers.
Recommendation
You should use style sheets to define the visual appearance of pages. You should not rely on custom styles to denote document structure. You should use HTML structural tags (<h1> to <h6>, <ol>, <ul> etc) instead, so that people are not disadvantaged using non-visual browsers or browsers that ignore style sheets.
You may use selectors, properties and values that are defined in CSS2, but only where you are sure they will degrade gracefully in browsers that don't correctly interpret CSS2 or do so poorly.
Resources
Cascading Style Sheets, Level 1 (http://www.w3.org/TR/REC-CSS1)
Cascading Style Sheets, Level 2 (http://www.w3.org/TR/REC-CSS2)
CSS Validator: http://jigsaw.w3.org/css-validator/validator-uri.html
6.3.5 Scripting
Scripting languages are generally easier and faster to code in than precompiled languages like Java. They can enable pages to offer interactive content and sophisticated presentation and navigation. They carry a risk, however, of reducing accessibility in certain circumstances, and should be used judiciously and with much testing (see section 6.4). 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.
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.
Requirements
Websites using scripting must degrade gracefully, so that the site remains fully functional if scripting is ignored. All information and services on a government website must be available whether or not scripting is available to the user.
Recommendation
You should use scripting languages only where required and ensure text-based alternatives are available.
Where active scripting is used, it should conform to the ECMAScript standard, rather than a proprietary standard, and should use the W3C Document Object Model (DOM), which is a platform- and language-neutral interface that will allow programs and scripts to dynamically access and update the content, structure and style of documents.
Resources
ECMAScript ( http://www.ecma-international.org/publications/standards/Ecma-262.htm)
W3C Document Object Model (http://www.w3.org/DOM/)
6.3.6 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 Guidelines are available, at a discovery level, from the permanent URL http://www.e-government.govt.nz/web-guidelines/. 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.
The capabilities of web servers to remap URLs should be used to provide succinct permanent discovery-level URLs when a content management system (CMS) is employed.
Designing URLs
Discovery-level URLs should reflect a general hierarchy and grouping of documents relevant to the agency's business function. For example, http://servername/services/info/ or http://servername/policy/reports/2002/ or http://servername/contacts/auckland/.
File naming
A few simple rules for file names (and URLs) will help web teams manage links within your sites:
- Use lowercase a-z only, rather than mixed case
- Use a hyphen, rather than a space or an underscore, as the only form of punctuation. Underscores get lost in underlining.
- Keep names short (no more than 50 characters) yet descriptive.
- Where a file extension is used, use it be consistently throughout the site (always using .html in preference to .htm, for example).
Requirement
You must not change the URL of discovery-level documents. Discovery-level documents include 'home pages', indexes for collections of documents, like media releases or reports, and the delivery point of online services.
Recommendations
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.
Authors should always refer to the nearest stable discovery-level URL, rather than using a 'deep' link that may change.
6.3.7 Metadata
New Zealand Government Locator Service (NZGLS) metadata standard is the official New Zealand Government standard for creating discovery-level metadata. The metadata is held in a central repository called Metalogue, and may also be stored in agency databases and in web documents.
Metalogue stores discovery-level metadata. In other words, it does not describe every document on government web sites, but rather describes collections of documents (like a collection of media releases or consultation documents). It also stores metadata describing resources that are not available online, like printed pamphlets.
Although the NZGLS standard describes ways to express NZGLS metadata in HTML metatags, there is no requirement for agencies to add NZGLS metatag blocks to web pages. If it is desirable for your agency to store metadata, either in web documents or a separate searchable database, the NZGLS standard should be used. If the standard does not meet your specific needs, you may add elements to extend the scope of the metadata.
Metadata stored in web documents must be identical, element for element, with metadata stored in Metalogue for a given URL. It is therefore important that your agency establish information management processes to keep the two sources of metadata in synch.
Recommendations
You should use the NZGLS standard for metatag blocks only where there is a business need to store metadata in web documents. You should add metatags such as keywords where this might be useful (see section 6.4.3).
Resources
NZGLS Metadata standard (http://www.e.govt.nz/standards/nzgls)
6.3.8 Unicode
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 the case earlier. Its use is recommended in these Guidelines.
To reliably render Unicode-encoded documents in browsers, web documents have to correctly specify the encoding that the browser should use to interpret the steam 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. Authors should 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:
- Ā Ā
- ā ā
- Ē Ē
- ē ē
- Ī Ī
- ī ī
- Ō Ō
- ō ō
- Ū Ū
- ū ū
Note: the trailing ";" is required.
Requirements
You must encode Māori long vowels using Unicode and declare UTF-8 in the HTTP header or the charset parameter of the content-type declaration. You must provide a way to view the site without macrons for those who cannot see the macron rendered correctly.
Resources
Macronisation of Web Content report (http://www.tpk.govt.nz/using/macron.asp)
Unicode (http://www.unicode.org/)
6.4 Delivery in practice
Adopting common Internet standards makes content more accessible, but standards do not cover everything. Providing content equitably to New Zealanders means taking account of the full range of conditions in which people access that content.
Fast connections to the Internet are not yet the norm. Therefore sites must be designed to be fair and reasonable to those who cannot quickly download documents. It should be remembered that for many people in rural areas, large web pages time-out and remain completely inaccessible. Many people access the Internet in public access points like libraries, colleges and Internet cafes. They may not so easily be able to save or print information. Therefore it is only fair and reasonable to make information easier to read and digest on screen. When people choose to print information, be fair and reasonable by providing a print-friendly version that doesn't needlessly consume ink in banners and backgrounds.
6.4.1 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 must not assume that dependent files, like images, have been cached.
Recommendations
- 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, may be up to 300KB, but the link should indicate document size and the purpose in providing it. In some cases it may be necessary to break a very large document into several large printable pages to meet this requirement.
6.4.2 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 should have some warning when they are about to be presented with a special-purpose file, such as the format and file size. 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.
Requirements
Content intended for anything other than a specialist audience must be provided primarily in HTML 4.01. Where another format is provided, it must be clear to all users that this is provided for the benefit of a specialist audience and may require special software to make use of it.
You must use the earliest compatible version of the format, unless there is good reason to provide a later one.
You must show the format and file size as part of the link to the alternative formats, e.g. PDF [250KB]. You should compress large files or collections of smaller files, and provide a link to a suitable decompression utility. You should use the Zip 2.3 (http://www.info-zip.org/) format.
Site managers and developers must refer to the e-Government Interoperability Framework (e-GIF) for technical standards for e-government not covered in these Guidelines. Where the required format is not covered in these Guidelines or the e-GIF, an open rather than proprietary format must be adopted. Consult with the Manager, Moderation and Web Standards if you are unsure - web.guidelines@ssc.govt.nz .
Use of PDF alone for long documents or documents with specific, complex formatting intended for specialist audiences is strongly discouraged. However, if no HTML version is provided, the Acrobat Accessibility Guidelines must be followed (see http://www.adobe.com/products/acrobat/access_booklet.html).
6.4.3 Code design
There are any number of ways that web documents can be coded within the scope of the W3C recommendation. Poorly coded documents may affect the overall integrity of the site, because they are difficult to keep consistent or difficult to archive. Some code designs make documents more adaptable and therefore more equitably accessed than others. Some designs encourage trust in the organisation and the information it provides. Some are more economical to create and maintain.
This section provides requirements and recommendations for web document code design that support the principles of equity, integrity, trust and economy.
Coding correctly
Most current browsers display web documents that are not coded precisely to the HTML specification. This may not always be the case. For a web document to be accessible as an archival record of what government made publicly available on the web, documents must as a minimum be valid HTML. Careful consistent document coding will make them easier to maintain in the short term.
Document type declaration
A document type declaration says how the document tags are to be interpreted. It does this by referring to a document type definition (DTD) and may point to where the DTD can be found. The declaration may be important for future retrieval of archived documents. It can easily be added to global templates for web sites.
You must use the 'transitional' HTML DTD unless all deprecated HTML 4.01 tags have been avoided, e.g.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
Document title
You must provide a document title in the <head> section of the document. The meaning of the title, and therefore the content of the document, should be clear out of context. For example a document listing contact details for the Department of Public Administration, should be titled "Contacts - Department of Public Administration" rather than just "Contacts". You should keep the same syntax consistently throughout the site.
You should keep titles brief: no more than 60 characters, but preferably around 30. Overlong titles are truncated in browsers and make for unwieldy bookmarks.
Correct tagging
You should use elements as they were intended. Mark up the structure of the document, rather than just alter the appearance of text. You should close elements properly. You should write element attributes in a consistent order.
Correct tagging will save time and effort in the long run.
Templates and code layout
You should use templates to apply common document elements, like the header and footer. You should lay out tags and content consistently, using HTML Tidy (see http://www.w3.org/People/Raggett/tidy/) if need be. Consistency makes documents easier to maintain.
Commenting
Commenting helps those maintaining web documents. You must not use commenting to credit individuals or companies. Comments should be few and short, adding little to the size of the web document.
Metatagging
Metatagging keywords and document descriptions has less relevance now than some time ago. Internet search sites have largely abandoned metatags as a way of ranking relevance because of widespread abuse. However, search engines within your site may still use metatags. Keywords in particular can be used as a mini thesaurus, providing alternative terms to broaden searches. For example, listing "e-government, e government, egovernment" or "Maori, Māori, Mäori, Maaori" may help find the document, regardless of how a person uses the search term.
See section 6.3.6 also.
6.4.4 Navigation
Home pages
Simply put, websites 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 the home page.
The home page clearly plays a crucial role in making the web site what it is. It is the document that is served when, without any knowledge of the structure or content of a website, an initial request is made of the web server, usually at http://www.domainname/.
The home page must show the main parts of collection, how to reach them and why the collection is there in the first place. Home pages are often called on to serve other purposes (like showing important news stories) because they play such a central role, but typically the home page should have little content of its own.
Typically documents linked from the homepage will have more content and fewer links, although for portal sites the opposite may be true. Documents linked from the homepage will usually have a common set of navigation links repeated on each page.
Requirements
- The home page must be served when http://www.domainname/ is requested. The request should not depend on a file type being specified (as in http://www.domainname/index.html).
- The main sections of the site must be linked directly from the homepage, therefore homepages must not be merely 'splash' screens.
- Every document (except the homepage) must link to the homepage. Making the organisation logo a link to the homepage is the usual way.
- The home page must link to govt.nz - the New Zealand government web portal at http://www.govt.nz/ . Instructions for linking and logos are available from http://www.govt.nz/linking/.
Frames
It is tempting to contain common navigation links in separate frames, which need only be downloaded once. There are several reasons why frames must not be used.
Well-designed navigation should not greatly increase the size of a document. If you are considering frames to reduce download time, you should probably be using more economic ways to do the same thing.
Frames are containers, not documents. From both an historical and a legal point of view it is important that a URL refer to a web document, complete in and of itself, rather than a container for web documents that may no longer exist.
Putting content and navigation in separate documents is the antithesis of what a web document should be. Unless the frameset document travels with the navigation document and the frameset and navigation documents travel with the content document, in the long term no one will have a complete picture of what was presented or why. In the short term, frames make it difficult for people to say where a document is by referring to an easily identifiable URL.
Requirement
Frames must not be used on publicly available government websites.
Common navigation elements
Most web documents start with a block of global navigation that links to the site home page 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 for 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 must be given 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 made 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. 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.
Javascript menus 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 javascript 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
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. A text alternative should also be provided. The image map should be client-side, unless the areas are complex non-geometric shapes.
Access keys
Access keys are potential useful for people who have difficulty using a mouse. They are less widely used than they might be because each site has a different set that the user must learn. This is the recommended allocation for government websites:
0 list of access keys
1 home
2 site map
3 search
4 to 8 agency defined
9 contact us
[ beginning of main content
/ go to govt.nz
Their use, which normally involves a simple change to a global template, is required on government websites.
Requirements
You must
- design all navigation to be adaptable, accessible and economical
- provide text-based navigation (even when javascript menus are used)
- provide access keys globally
- not require a user to download a plug-in in order to navigate the site
- consider accessible navigation design early in the development cycle.
6.4.5 Text
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 malleability of a web document makes it easier to use than traditional printed documents. Good typography for a web page is typography that is amenable to changes in font size and colour to make it more legible to people with poor vision, while retaining the visual relationships between elements.
Fonts
Fonts should be specified in style sheets rather than the deprecated <font> tag. 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.
Fonts should be specified as 'families' of alternatives in order of preference (Arial, Helvetica, sans-serif, for example). The principal font must have in its character set glyphs for the UTF-8 encoding of the long vowels of Māori. It must also be commonly available. If text must be in a particular font, say, for reasons of branding, you should use an image and provide the same as alt text.
Government agencies should not ask people to download fonts or software to view text. 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
Font size must be expressed in such a way that users can change it to meet their needs. You should use size names (xx-small, x-small, small, medium, large, x-large, xx-large), which are most consistently rendered across browsers. Other relative units such as em height (em) and percentage (%) are not fully compatible across all browsers.
Font colour
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.
White text should be used with caution because it may not print if background colours are ignored.
Font colour alone must not be relied on to impart meaning. For example, red text 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 "*".
Other font attributes
Text must be static. Blink and marquee tags are browser-specific and have no place in government web sites.
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 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://psychology.wichita.edu/surl/usabilitynews/41/onlinetext.htm
6.4.6 Images
Formats
Recommended image formats are GIF and JPEG. The Portable Network Graphic (PNG) and Scalable Vector Graphic (SVG) file formats are not yet readily supported and should not be used, except as alternatives.
You should use the GIF format for images with only a few colours and with areas of solid colour. You should use colours that are web-safe. Web-safe colours are the 216 colours 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.
You should use JPEG for images with more than 256 colours, such as ones with textures or colour gradients.
Animated GIFs are not recommended but, if used, must cycle no more than four times before stopping. Animated GIFs must not be used for logos or other core brand elements. Animated GIFs should not exceed 30 KB.
Size
Single images should wherever possible be under 30 KB. Large images should not be used on homepages. Both GIF and JPEG formats should be compressed to reduce file size without unduly affecting the quality of the image. Links to larger images should indicate the file size. A thumbnail may also be useful.
Text in images
Images should not generally be used to display text, except where a specific font or foreign language character set is required. Identical alt text must be provided, unless this can't be represented in that language.
Anti-alias large type (larger than 9pt) to improve its legibility by making its edges smoother. The converse is true of type smaller than 9pt.
Text equivalents
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 question 'Why is this image on this web page?'. Alt text should be no longer than 100 characters and should end with a full point and a space, so that it can be heard without blurring into the next piece of text.
Many images on websites convey information than 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 in the guidelines (see section 6.4.4). However, if they are used, the alt text must be the same as the text in the image. Where a logo links back to the home page, the alt text should be '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)
Other attributes
Both height and width attributes must be specified in the <img> tag. This can significantly improve the time 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 stylesheet techniques for providing white space around images.
Web bug images
'Web bug' images are generally invisible images fetched from remote sites to monitor site activity. They must not be used on government sites.
6.4.7 Colour
Colours used for text, backgrounds, hyperlinks and solid-colour graphics should be from the 216-colour web-safe palette to avoid dithering on 256-colour displays. Background colours must contrast with text colours, bearing in mind the high levels of red-green colour blindness in New Zealand. 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.
6.4.8 Visual identity
For many people, the visual design of a site provides confirmation that they are dealing with an agency that may already be familiar. A logo and colour scheme that matches what they have seen in printed material, advertising in other media and signage in branch offices, is reassurance that the site is consistent with these other communication channels.
The value and values of agency and government 'brands' should be protected as carefully in electronic media as they are in print media. The visual design of sites should draw on agency documentation that sets the rules for use of core brand elements in the online world. What works at 300 dpi on paper may well not work at 72 dpi on screen.
Site content is branded content. It should support the values the brand carries. Spelling mistakes, cloudy language and out of date information commonly undermine these values in printed material. In the online world, the same applies with download time, poor navigation, inaccessible sites and badly rendered logos as additional factors to be aware of.
Layout
The web is a flexible medium. It responds best to fluid designs. Documents with fluid designs respond to the user's needs, resizing columns and rewrapping text when the size of the browser window is changed. They continue to work well visually when text is enlarged. They allow users to strip away design elements like background colours if they want to.
Some degree of control over the position of elements of web document is desirable to make them usable for visual users. 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.
Fluid design means defining element attributes (size, position, width) relatively rather than absolutely.
Requirements
You must
- Use tables for layout only sparingly.
- Use as few columns as possible.
- Nest tables only where there is no alternative and check across a range of browsers. Content in nested tables should be checked for accessibility in screen readers and other assistive technology.
- If fixed-width tables are used they must be less than 535 pixels so that the page can be printed on a standard sheet of paper.
6.5 Testing
Real world testing is an essential part of the development cycle for any IT system, including websites. Websites must be fully functional for as many people as possible and, as such, must work across a wide range of browsers and operating systems.
Government is different, with different presentation requirements from some parts of the private sector. Testing should focus on ensuring services and information available on government websites can be delivered equitably regardless of the particular browser and operating system the user employs, rather than on the precise control of presentation and browser compatibility issues that have a purely aesthetic effect.
Web pages will not display identically in all browsers. This is a fact of life on the web and should not be of too much concern to developers of government websites. It is more important that government websites work with assistive technologies, such as screen readers or Braille readers, or provide an alternative text-based method of providing the same information. When testing government websites you cannot make assumptions about the levels of technology that your audience may be using.
Website testing is not without problems owing to the multitude of browsers, browser versions and operating systems (and their versions) in (almost) infinite combinations. Clearly the Guidelines cannot be specific about the requirements for each individual combination. Instead, we provide guidelines based on W3C specifications, which is what the browser community is now doing.
With this in mind, there are three streams of testing that must be undertaken:
- Technical testing: Test to ensure code is valid according to the HTML, CSS and JavaScript specifications. The development team must perform this testing before any code is released.
- Accessibility testing: Websites must be available to a range of assistive technologies, such as Braille and screen readers. While some agencies and development companies can perform this testing in-house, it may be more cost-effective to outsource this work to expert companies. The e-government website lists some companies who perform this work.
- Usability testing: This stream of testing ensures that people can use your site in a way that meets its objectives. This is different from accessibility testing and should again be conducted by professional testers. Your developer may have a relationship with a company that performs this testing for them. Again, the e-government website lists some companies who specialize in this work.
Usability testing with a controlled audience must be conducted early enough in the development cycle that changes to the site design can be made economically. A variety of browsers, operating systems and computer types must be used including different speed connections, at least down to 9600bps, to reflect the current reality of rural telecommunications.
[ Previous | Next ]
