Page |1

To help Web editors and Web content developers incorporate the basics of usability across all public sector websites. Please note: If you are developing content for Directgov, Businesslink.gov.uk or NHS Choices please refer to your internal guidelines in the first instance, they include the guidance in this toolkit.

Page |2

1 Page Layout
The basics of how to design and structure clear and effective page templates, and how to design the way your content appears within those templates so that it will be easy to read and act upon 1a Basic layout of page templates 1b Layout of contents in a page 1c Basic design/styling dos and donts

2 Navigation
Learn how to ensure your navigation bars provide people with the information they need to understand where they are and where they can go to, and so your links stand out and are understood. Shows basic design tips for the common navigational elements of breadcrumb trails, tabs and in-page contents list 2a Basics of usable navigation bars 2b Effective links 2c Usable designs for some common navigational elements

3 Writing Content
The essentials of writing content so that it is appropriate for the Web and can be read and understood quickly and easily by your audience 3a Structuring content for the Web 3b Basics of writing for the Web

4 Content Elements
How to provide images that are the correct format and that communicate your intended message quickly, clearly and with good accessibility. How to avoid misusing pop-up windows and pop-outs (tool tip type elements). Basic pointers on using and producing accessible PDFs 4a Effective use of images 4b When and how to use pop-ups and pop-outs 4c When and how to use PDFs

Page |3

5 Forms
How to design and layout basic forms so that they are easy to understand and fill out. How to minimise the potential errors entered by the people filling out your forms. When errors occur how to make fixing the errors as quick and easy as possible 5a Basics of form layout 5b Choosing and using the right form element 5c Minimising the errors entered by users of your forms 5d Handling errors and supporting input corrections

6 Search
Top level advice on how to implement simple and advanced search on your site, and the essentials of providing search results that can be readily understood and refined 6a Search form design 6b Search results design

7 QA & Standards
The key aspects of accessibility with pointers to the more specific COI guidelines in the vitally important area. Top level information on how to ensure the quality of your site with pointers to the more specific COI guidance on this topic 7a Basics of standards compliance and accessibility 7b Quality assurance and monitoring

8 Common Pages
The basic rules of how to produce a good homepage that people will readily understand and act upon. How to design and structure other commonly occurring pages such as the site map, site index and FAQ pages 8a Basics of homepage design 8b Site map design 8c FAQ design

Page |4

1 Page Layout
The basics of how to design and structure clear and effective page templates, and how to design the way your content appears within those templates so that it will be easy to read and act upon 1a Basic layout of page templates 1b Layout of contents in a page 1c Basic design/styling dos and donts

Page |5

1a Basic layout of page templates

Provide a consistent page layout with clear and recognisable sections. Place important links and elements consistently
Make it easy for your audience to predict where things are for each new page or section o Note: The homepage can be different but it is a good idea to set the basic style [see 8a] Use the following common main page sections (unless there is a good reason not to): o Header with clear logo (positioned on the left) o Navigation bars [see 2a] o Contents pane (clear and dominant) o Footer o Area for related links and information If available, use templates and defined layouts and conventions for your organisation o If applicable see specific guidelines for Directgov, Business Link and NHS Choices

Devote as much page space as possible to content rather than navigational elements (sometimes called page chrome)
When setting font size and column size, aim for between 12 and 15 words per line for quick and comfortable reading for most people

Optimise for 1024 width resolution

Design for a width of around 960 pixels to ensure there will be no need for horizontal scrolling at 1024 pixels width resolution Ensure that essential information is visible and usable at a width of around 760 pixels. This is the visible width at a resolution of 800 pixels width

Additional considerations: Put the most important content so that it is visible without the need for vertical scrolling (sometimes referred to as putting key content above the fold) but avoid cramming content into a short strip
Do not use Frames to lock content to a central portion Do permit vertical scrolling to appropriate contents rather than forcing content into inappropriately short pages [see 1b]

Notes and discussion points Fixed layout versus fluid layout or somewhere in between? 1024 x 768 is currently the most popular screen resolution (in early 2009). Ideally pages should be fluid so they can still be fully viewable and usable at a resolution of 800 x 600 (and also larger resolutions) but this is not always possible or desirable. If you are using a fixed width you should try to ensure that important content is viewable at 800 x 600 without the need for constant horizontal scrolling

Page |6

Your decision should be based on the contents of your site and knowledge about your audience (web analytics will show you the resolutions that your audience is using to view your site). For example, these guidelines contain many bullet points and fixed width images so we chose fixed width of 1024 to maintain side-by-side viewing and good line length for readability of the text. In addition, we know that the vast majority of the intended audience will be viewing at a resolution of 1024 x 768 or higher CSS versus tables for layout Ideally you should use CSS to control all layout and styling this is standards compliant and the most flexible and accessible method View references for basics of page layout

Page |7

Page |8

Page |9

P a g e | 10

1b Layout of contents in a page

Position the most important content at the top of the page so it is visible without vertical scrolling
For content this will often be in a middle of the page in a clearly recognisable contents pane

Use a clear page title and clear sub-headings to visually group sections and give contents a natural hierarchy Group related items together to create pages that look uncluttered and that have clear sections and subsections
Use white space liberally between items Place related items closer to each other than unrelated items Use different colours, backgrounds and borders to group related items together o ...but dont overdo it otherwise it can look busy and cluttered Use bullet points and numbered lists to create clear visual groupings

Use a single column contents pane for text documents and forms to create a clear reading path. This also avoids the need for upwards and downwards scrolling that a multi-column layout might require
Exceptions to this include: site maps, indexes, major landing or category pages, which all can work well in multi-column formats

Additional considerations: Avoid scroll stoppers items of content that can make people think the page has ended when in fact there is still more content below that could be reached by scrolling down:
Often caused by content boxes or images which end neatly at the bottom of the browser window and so make the page look complete To avoid scroll stoppers: o Design pages so that items that would be just below the bottom of the browser window peep just above it and so indicate that there is more valuable content below o Be careful with large vertical blocks of white space in the contents o Test it with people: You should test designs to make sure they do not cause scroll stopping (particularly at 1024 x 768 resolution using popular browsers)

Notes and discussion points What if I just provide copy into a template or a Content Management System (CMS)? Hopefully your page templates should be set up so that they can style and layout content according to the above basic guidance (if not this should be fixed). It is important that you use the appropriate template markup (these are bits of code that tell the web browser how to style different content such as headings, sub-headings and lists). Different systems have different ways of applying markup and you should

P a g e | 11

seek advice on how to add content to your templates in the correct way. You should avoid applying your own visual styling (some content management systems let you do this) rather than using the built in template styles as this will lead to inconsistencies, make it difficult to apply changes and it removes intended meaning (semantic coding) that some of the styles may be intended to convey.

P a g e | 12

P a g e | 13

P a g e | 14

P a g e | 15

1c Basic design/styling dos and donts

Style text for readability
Always use left-aligned text for body text o Avoid centred or right-aligned text o Never use justified text Use readable and readily available fonts o Sans-Serif fonts like Verdana and Arial are readable and universally available o Be careful if using Serif fonts (like Times New Roman) for smaller size text because they can be difficult to read o Serif fonts can be used for large text, such as headings and titles Avoid ALL CAPS for body text all caps is slower and more difficult to read and it LOOKS LIKE SHOUTING o All caps is acceptable for short phrases and menus, but avoid if possible Never use blinking text or marquee text (text that scrolls horizontally across the screen) it is distracting and difficult to read Use underline only for links and nothing else [see 2b] underlined text is more difficult to read and will be frequently confused with links

Be careful with the use of colour:

Use high contrast between foreground and background Add colour to make information stand out more, but do not use colour alone to give information because some people cannot see colours (for example blind people using software to convert the information into speech) o Add another cue such as an icon or explicit words [see 5c] Avoid red/green combinations in both images and text these can be difficult to see for people who are colour-blind

Notes and discussion points Site specific style conventions Some sites are very specific about text style rules. For example, for Directgov:
All caps are not allowed even for short phrases or menus Italics are not used for any text Verdana is the default font (so the font family set within the style sheet is set to Verdana, Arial, Helvetica, Sans-Serif)

P a g e | 16

P a g e | 17

P a g e | 18

2 Navigation
Learn how to ensure your navigation bars provide people with the information they need to understand where they are and where they can go to, and so your links stand out and are understood. Shows basic design tips for the common navigational elements of breadcrumb trails, tabs and in-page contents list 2a Basics of usable navigation bars 2b Effective links 2c Usable designs for some common navigational elements

P a g e | 19

2a Basics of usable navigation bars

Make sure navigation bars stand out from the rest of the page contents
Style and place appropriately (at a consistent place at the top of the site or page) [see 1a]

Include a link to Home

The Home link does not necessarily have to be on the main navigation bar, but should be easy to find Make the logo link to the homepage

Highlight the current page or section on the navigation bars this indicates to people viewing the pages where they are .To do this, do one or more of the following:
Make a colour change to the label or its background (or both) Make a change to the label style (for example, Bold text) Add a visual marker or use tabs [see 2c] to make the current label stand out visually Disable the link if on the current page Show the current page via a hierarchical list

Carefully select the labels for your main navigation bars they should be:
Understandable and unambiguous o Use your audiences language and terms, not your internal organisational jargon and acronyms o Test it with people the simplest way is to ask people who are typical of your expected audience what type of content they think they would find if they clicked each of items in the navigation bar Mutually exclusive o Ideally there should be only one default place to look for an item Suitably broad in combination such that together they are likely to contain all content now and in the future

Show parent/child relationships clearly

Use bullet points and/or increase the space between items in lists of links to avoid confusion when a link wraps over more than one line Use indenting, size and formatting to clearly communicate hierarchy

Be careful with dropdown navigation menus:

Avoid multi-level cascades of menus: o These can be difficult to use, especially where fine control is required If using dropdown menus then: o Test with real people: Test with a range of people to ensure ease of use o Ensure the menus can be used with a keyboard o Make the top menu item a link to an overview page that presents the same links as in the cascading menu along with a short explanation of each link

P a g e | 20

Additional considerations: Provide extra information to support link text when useful
Provide supporting explanatory text (tooltip) which appears (in some browsers) when the mouse hovers over a link o CODE: use the title attribute to add the extra explanatory text [see 2b] o Avoid just repeating the link text only use if extra information is useful to give better understanding about the link destination (see examples) Show main categories on the homepage with an explanation and/or links to example contents [see 8a]

Notes and discussion points How should you select the ideal labels? The choice of labels and categories and the relationships between them (sometimes called information architecture) should be informed by knowledge and research about your target audience. A good information architecture maps features, functions and contents to the wants, needs and expectations of the target audience. During development this can be researched and validated using a variety of methods. One effective and simple method is known as card sorting. In one form of card sorting, individual page titles and features are written on index cards and target audience members are asked to sort the cards into groups that make sense to them. Then they are asked to give names to their groups. This helps validate whether your suggested groupings make sense and whether you have given them meaningful names Logo always a link to home? Typically the logo should always be a link to the home page, however within some processes, transactions or tools, this may not be appropriate What is wrong with drop-down menus? Many people have difficulty controlling and selecting the menus, and often it is better to have a simple page menu system

P a g e | 21

P a g e | 22

P a g e | 23

2b Effective links
Make sure links stand out clearly from all other content
Blue underlined text is the most common way to show links. If you use another style: o Use the link style consistently o Test with people: Test that people that have not seen the design before can instantly spot all the links o Limit the number of link styles you use (ideally use only one)

Make links that have been visited look different from those that have not been visited
By default, most browsers show a visited link as red/purple underlined text, but you can set to another colour as long as the meaning is clear

Use links that are descriptive and meaningful when read out by themselves without any surrounding text
The text of each link should clearly indicate its destination or function Do not use just 'click here', 'more', 'full information', PDF', 'file' and so on Make each link text distinct from others in the page

Make links concise but descriptive

Do not link whole paragraphs, but do use the most important trigger words for the link

Avoid unnecessary words:

Adding words, such as 'link to...' and 'click to...', is usually unnecessary

Provide useful information about the link:

Adding words, such as 'link to...' and 'click to...', is usually unnecessary Sometimes, to assist with reading of the links, it may be more sensible to include useful information next to the link rather than within the link itself

CODE: Use the link title attribute to add extra information to links to help communicate the destination more clearly
Add text that aids clarification, for example, describe the destination site of a link (the site name, type of site), describe the scope of the page or section contents Avoid just repeating the link (this is not useful extra information) The information in the title attribute appears as a 'tooltip (a description that appears when the mouse hovers over the link) in some browsers, and can be read out by screen readers used by blind people

P a g e | 24

Place in-page links where they are needed for action :

Do not force people to hunt for a link elsewhere if it makes sense to place it right where it is needed in-page - make them fall over it! Dont rely on your audience finding the appropriate links in the navigation bars put the links where they are needed most dont make them think!

Be careful not to overdo the number of links in body text

Rather than pepper a passage with many links, consider a separate section at the end that lists related links o By doing this, you can provide better labels and more information for the links rather than compromising your original passage

Additional considerations: Ideally place links at the beginning or the end of sentences or bullet lists it makes them easier to read If you can, try to avoid wrapping links over multiple lines (particularly when embedded in body text) Notes and discussion points What about the cross reference links used on this site? They are just numbers that do not make sense out of context why have your used them?
We originally had longer descriptive links that contained the title of the destination page such that they were fully meaningful out of context (for example, instead of '[see 1b]' a link would be '[see 1b effective layout of page contents]'). When we tested this we found that: The length of the links actually upset the flow of the information presented in some of the bullet points The long links could be confusing when they wrapped over two lines The shorter links (such as we use now) were well understood and readily recognised as cross references

To assist with recognition of each link, we included the full title of each link in the title attribute such that it appears when the mouse hovers over the link in some browsers (such as, Internet Explorer)

P a g e | 25

P a g e | 26

P a g e | 27

P a g e | 28

2c Usable designs for some common navigational elements

Breadcrumb trail
Use as a navigation aid to show people where they are in a hierarchical site structure, and provide them with a way to go up in the hierarchy o Often used in sites with a deep structure Use arrows or chevrons to visually indicate hierarchy by communicating a sense of moving along from left to right Disable the link for the current page to further help explain to users where they are within the site structure o If the current page title is directly under the breadcrumb, the title can be left off the breadcrumb itself It is optional to use a You are here: prefix before the top (home) link in the hierarchy

Tabs:
Use as a navigation aid to show people where they are in a hierarchical site structure, and provide them with a way to go up in the hierarchy Tabs should look like real-world tabs: o Make sure the current tab looks like it is in the front and all the other tabs look like they are behind o Ensure a clear visual connection/ continuity between the current tab and current page Stick to a single row of tabs multiple rows of tabs can become very confusing

In-page contents list (for navigating within a page) [see 8c for an example used for an FAQ page]:
Use for long structured pages to help the reader see an outline of the page contents and navigate directly to different sections further down the page [see 3a] Place the contents list directly under the page title, or just under a short summary passage Put a clear title before the list to clearly communicate that the links are within page, such as On this page Use a bullet or ordered list of in-page links to the main section headings Use the same titles as the headings o Indent to show any hierarchy of subsections

Notes and discussion points Horizontal tabs? The same rules apply, that is, make them look like real tabs. However, try to avoid use of text on its side or orientated vertically as this is hard to read Back to top links for long pages? These can be useful for getting back to the in-page contents list

P a g e | 29

P a g e | 30

P a g e | 31

3 Writing Content
The essentials of writing content so that it is appropriate for the Web and can be read and understood quickly and easily by your audience 3a Structuring content for the Web 3b Basics of writing for the Web

P a g e | 32

3a Structuring content for the Web

Use headings to group content into appropriate sections this improves readability, scanning and page navigation
Using HTML heading levels <h1>, <h2>,<h3> and so on o Try to avoid skipping levels if possible Note: If using Microsoft Word or a similar word processor to provide content, use inbuilt heading/outline levels to give this structure [also see 1b]

Provide a clear main page title on every page

Use<h1>

Use bullet and numbered lists rather than long comma separated lists to give more structure and aid quick reading (visually scanning of the page) Provide summaries and in-page contents lists particularly for long pages [see 2c] Ensure consistency across content pages [see 1b]
Use templates for similar content types Coordinate content provision so that all content providers are aware of, and use, the same templates and formats

Notes and discussion points

Good structure is essential to enhance readability and accessibility a good way to check is to turn off the styles in your browser and just view it raw. If it still looks structured, makes sense and is easy to read the likelihood is that it is well structured

P a g e | 33

P a g e | 34

3b Basics of writing for the Web

Use an inverted pyramid style of writing:
Start with a headline which summarises the information Follow with a few sentences which present the most significant details which support the summary headline End with the less important facts

Put the most important information first in links, titles, and phrases
This will emphasise the uniqueness of the item and aid quick comprehension

Remove excess words and avoid big words where smaller more everyday words would do the same job, for example:
'Come into possession of becomes 'Get' 'Unostentatious' becomes 'Simple'

Use specialist language and jargon only when it is well known by your audience:
Modify the internal language used by your organisation into everyday language Unemployment benefit becomes dole Community engagement becomes getting people involved stakeholder engagement becomes talking to people benchmarking becomes measuring Test with people: Where possible, test the language you are using for everyday understanding with the people who need to read it

Use the active rather than the passive voice

The active voice is less wordy, more direct and easier to understand (see notes below and the references for more on this)

Use an appropriate style of writing to match the content and the audience
In some cases an informal, friendly, personal style may be more effective than formal language

Use short sentences and short focused paragraphs:

Try to keep sentences below 21 words Try to keep paragraphs below 6 sentences and focused on a single topic

Make liberal use of bullet lists and numbered lists to aid quick visual scanning of content
Change long comma separated lists into bullet points

P a g e | 35

Add relevant tables and diagrams to break up blocks of text Emphasise key words and phrases
Do not make large passages bold or italic, as: o It is more difficult to read o It loses the emphasis if overused CODE:Use <strong>and <em> rather than <B> and <i> or CSS <span> to add semantic meaning

Do not use ALL CAPS, underlining, right, centre or justified alignment for body text [see 1c] Notes and discussion points Writing in the active voice Most books about writing or grammar have full explanations of writing in the active voice. There are also many good resources on the Internet, for example, search for copy grammar active voice Tip: Word processors that have grammar checkers also highlight where you have used the passive voice. You can use these to help you (though ideally you should use a sub-editor / experienced copywriter too)

P a g e | 36

P a g e | 37

4 Content Elements
How to provide images that are the correct format and that communicate your intended message quickly, clearly and with good accessibility. How to avoid misusing pop-up windows and pop-outs (tool tip type elements). Basic pointers on using and producing accessible PDFs 4a Effective use of images 4b When and how to use pop-ups and pop-outs 4c When and how to use PDFs

P a g e | 38

4a Effective use of images

Use the correct image format for the job not doing this reduces the quality of the image and can increase the file size
Use JPEG for photographsJPEG for photographs, or where there is a strong colour gradient Use GIF or PNG for line art, cartoons or where there are solid blocks of colour

Optimise each image for file size:

Balance the file size and quality of JPEGs using image processing/design software Scale each image to the exact dimensions that you want to use on the page o CODE:specify the exact pixel dimensions when you specify the image using the width and height attributes of the img element

Avoid gratuitous use of images

Use images to decorate, inform and break up large blocks of text, but do not overdo it Use icons to help communicate the meaning of important links ...but avoid using icons alone for links and menu items - very few icons are universally understood o pictures might paint a thousand words but unfortunately they are frequently the wrong ones

Add click-ability cues to images that are links

dd small arrows, appropriate words and so on Make images that are links look like buttons (and therefore look like they can be pressed) Test with people.Test to ensure your image links are easily recognised as links

Avoid images of text they increase download times, cannot be scaled, and can appear fuzzy when magnified
There are exceptions: o Logos o Important special text effects o Illustrations/annotations (such as in these guidelines)

Use animations only when the sequence is meaningful and helpful for providing information avoid unnecessary use as they can be distracting and annoying
Cycle animations no more than twice when the page opens Provide a way to repeat the cycle

Supply alternative text for all images so that equivalent information is provided to those who cannot see the image

P a g e | 39 In the absence of the image, the text should allow the audience to fully understand why the image is there: o Keep the description concise, meaningful and functional o Avoid literal description of an image if the description does not help communicate the reason for the image being on the page If the image is just text, ensure the same text is part of the description CODE:Use the HTML alt attribute to hold the descriptive alternative text For longer descriptions, add a page and link this to the image o CODE:You can also use longdesc attribute for this For decorative images, use a null description o You can also use longdesc attribute for this CODE:alt= (no space between 2 double quotation marks)

Additional considerations: Take care that images only give the message you intend
Test with people. Test with a typical audience and assess understanding of the meaning of your images inferred meaning Avoid just repeating the link text only use if extra information is useful to give better understanding about the link destination (see examples)

Notes and discussion points Can I use flash, silverlight? etc.? Check the specific guidelines relating to your site as to whether you can use these or other technologies. They can offer a rich and engaging experience and be made accessible and usable but their use should be carefully considered. It is usually a bad idea for the whole site to be made in flash but components can benefit from its use.

P a g e | 40

P a g e | 41

P a g e | 42

P a g e | 43

4b When and how to use pop-ups and pop-outs

Pop-ups (pages which launch in a new window or a new browser tab):
Generally avoid using pop-ups unless absolutely necessary: Acceptable usage: o Use pop-ups for links to help information about the underlying page, for example, on forms o May be used for launching a site survey If using: o Provide a warning on the link that a pop-up will result via text or the title attribute [see 2b] o Always provide an explicit 'close' button on the pop-up windowMay be used for launching a site survey o Make the pop-up window smaller to ensure that it does not obscure the original page o Try to avoid multiple pop-ups filling up the screen

Pop-outs(content that launches in a box or container that obscures some of the current page contents):
Use pop-outs to: o Add small amounts of extra information (essentially help, tips and hints) o Perform small localised tasks that must be performed before continuing Inappropriate use: o Do not present a lot of detailed information in pop-outs o Do not use pop-outs to present complex processes or sequences of actions o Do not use pop-outs when there is a high likelihood of a user wanting to go back to a previous state of the pop-out If using pop-outs: o Use an explicit close label or button to provide a simple way to close the pop-out and return to the pre-pop-out state o Ensure that it opens where it does not obscure useful underlying information o Ensure the pop-out opens in the visible part of the page and avoids popping out off the visible page or scrolling to see its contents

Notes and discussion points What is so wrong with pop-ups? They cause an unnecessary break in the typical page based flow of information, and also:
Cause disorientation Disrupt the history of visited pages Break the 'back' button Are often blocked by pop-up blockers

What are the issues with pop-outs? One of the main issues is that pop-outs break the back button (the most regularly used button on the Internet). This can lead to confusion when people are performing

P a g e | 44

processes within pop-outs (they go to the previous page rather than the previous state)

P a g e | 45

P a g e | 46

4c When and how to use PDFs

Ideally provide documents in accessible HTML form unless totally unpractical to do so:
The most appropriate uses of PDF are: o When the PDF is in addition to HTML o Long documents that are intended for printing for which there is a HTML summary/abstract o Legally restricted documents o Foreign language publications (particularly if they use an alternative character set) o Claim and application forms for downloading and printing o Documents designed specifically for print, such as brochures, which require fine control over printing (although you could use print CSS on HTML for many print-friendly versions)

If using PDFs:
Create an HTML summary/abstract whenever possible Use a table of contents for long PDF documents this provides appropriate overview of the contents and navigation directly to different main sections Add appropriate metadata / document properties Warn in (or next to) the link that the document will be a PDF and state its size in Kb Provide a link to download Adobe Reader Ensure the source document and PDF has been made accessible o Add structure and alt text in the source document creation application (for example, use headings and add alternative text from within Microsoft Word) o Test and fix tags using Acrobat Professional o Save as PDF do not use print as PDF to generate the PDF or structure is lost

Notes and discussion points What is the issue with PDFs? The main issue used to be (and to an extent still is) to do with accessibility. Although PDFs can now be made accessible, it tends to be harder work than producing accessible HTML. If there is the option to do so, use HTML instead PDFs can break the usual flow of browsing by changing some of the available controls but this is becoming less of an issue If the PDFs are well constructed, there should be little issue with providing PDFs What about when there are lots of old PDFs? It may be not practical to make HTML summaries of old or legacy PDFs, or make these accessible. If this is the case:
Prioritise very important and/or high traffic PDFs for making accessible Ensure all new PDFs are provided with HTML summaries and are accessible

P a g e | 47

More information about accessibility and PDFs?

Visit the Webaim training materials for PDF for PDF conversion, structuring appropriate documents using Microsoft Word (and other word processors) and a whole host of other accessibility tips Visit the Adobe access site for step-by-step information for step-by-steps guides on creating accessible PDFs

P a g e | 48

P a g e | 49

P a g e | 50

P a g e | 51

5 Forms
How to design and layout basic forms so that they are easy to understand and fill out. How to minimise the potential errors entered by the people filling out your forms. When errors occur how to make fixing the errors as quick and easy as possible 5a Basics of form layout 5b Choosing and using the right form element 5c Minimising the errors entered by users of your forms 5d Handling errors and supporting input corrections

P a g e | 52

5a Basics of form layout

Create a clear path through the form:
Avoid multi-column forms unless absolutely necessary Avoid creating a 'jagged', misaligned appearance

Group similar items together, and order logically:

Give each group a title and make distinctive: o Use borders, spacing or colour etc. o CODE:Use headings <h1>, <h2> and so on o CODE:Use <fieldset> and <legend> to code these and style with CSS

Provide a label for every single form item (sometimes called form fields) Position form labels close to the input elements
For short labels, consider right-aligning next to the input element For longer labels, consider placing directly above the input element

Put help and prompts near to the input elements and mark required input clearly and unambiguously [see 5c] Notes and discussion points What about really long forms? Consider splitting very long forms into separate logical pages
Test with people: Test to make sure splitting up the form makes form filling easier

If splitting the form:

Indicate how many steps there are and the current position, for example: o Page 2 of 4 o or by using a progress bar Provide a means to go back to earlier pages via a link and/or a progress bar

P a g e | 53

P a g e | 54

P a g e | 55

P a g e | 56

5b Choosing and using the right form element

Ask for only the information you require exclude unnecessary information to make the form as short as possible Text Boxes:
Minimise the requirement for free text entry to help reduce errors o Use drop-downs, checkboxes, radio buttons instead where you know the full set of choices Fill in text boxes with default values when possible Match the text box length to the amount of data expected this provides the users with an insight as to what is required o Where input length is variable, use a consistent length that has enough room for likely answers

Radio buttons:
Use to select one from a small number of options Place the label to the right of the radio button Make the label text self explanatory where possible, for example: o 'Yes, I have read the terms and conditions' ...rather than just Yes' Select one of the options by default where appropriate CODE:Use <label> to make the label activate the radio button when clicked this creates a bigger, easier to hit target

Drop-down menus:
Use to select only one from a larger number of options o ...or where there is not enough space to fit radio buttons

Check boxes:
Use to select one or more from a number of options Place the label to the right of the checkbox Make the label text self explanatory where possible CODE:Use <label> to make the label activate the checkbox when clicked this creates a bigger, easier to hit target

Use two radio buttons instead of a single checkbox when there is a choice between just two options - especially when it is not absolutely clear what the unchecked form of the checkbox would mean. For example:
Use 'o male o female' instead of '[] male'

Submit buttons:
Label with clear indication of what will happen o If possible, avoid just OK or submit Make your buttons look and behave like buttons such that:

P a g e | 57 They have a 3D appearance They press in when clicked if possible Avoid use of a reset/clear button it is very rarely (almost never) necessary, and liable to be selected by mistake
o o

Additional considerations: Order and group the items within drop-down menus according to your audiences needs
Put the most frequently selected options at the top Group and indent using spacing and characters to show hierarchy CODE:consider using <optgroup> to show groupings

Notes and discussion points Required to make a default selection from a set of radio buttons? Some guidelines state that you must select a default selection when providing radio buttons. In practice, you should not select a default when you want to ensure that the person filling out the form has made a definite choice (rather than risk them submitting the inappropriate default) and where a default choice is impractical, impossible or potentially offensive (for example, it would rarely be appropriate to assume the gender of the person filling out a form) Multiple selections for drop-downs? It is unlikely that many of your audience will know how to select multiple options in a drop-down. It is also very fiddly and the multiple choices can only be seen when it is expanded use checkboxes instead What about list boxes? (If you dont know what list boxes are dont worry, just ignore them!). These can be problematic and are rarely used on the Web and, unless unavoidable, use one of the simpler elements

P a g e | 58

P a g e | 59

P a g e | 60

P a g e | 61

5c Minimising the errors entered by users of your forms

Provide required information indicators
Use images with the alternative text set to required or required information o ...or use characters, such as '*' (asterisk) o ...or use real words, such as required For accessibility reasons, do not indicate the required information by using only a colour change by itself. You can use colour though to make it stand out more o Avoid using database jargon such as 'field', such as 'required field' - to most people a field is where cows graze!

Provide clear and concise instructions at the start of the form, information such as:
The purpose of form The number of pages and the potential time it should take Advance notice about information that might be needed for successful completion. For example o National Insurance numbers o account numbers o reference codes Advance notice about any time limitations or timeouts

Provide required format instructions and/or examples to clarify and explain input requirements:
Place near to the input o Ideally before the input, and ... o CODE:... ideally within the <label> tab o CODE:If not possible, use the title attribute as well as a visible format example

Provide help where it is needed

Ideally with text displayed on the form itself... ... if not, use an info or help link to a pop-out or pop-up [see 4c] Additional considerations:

Be careful with timeouts:

Ideally avoid timeouts and time limitations completely Where there are time limitations and timeouts, ensure that there is the possibility to request more time If a timeout occurs, try to ensure that people can rejoin the process without losing the data they have entered

P a g e | 62

Notes and discussion points Are required information indicators always required? What about optional indicators? If the majority of the form needs to be filled in, it makes sense to only highlight those elements that are not required. Do this using obvious text such as the word optional. Do not mix form types, either use forms with required indicators or optional indicators but not both. What about in-page validation? [see 5d] for more on in-page validation

P a g e | 63

P a g e | 64

5d Handling errors and supporting input corrections

Provide meaningful and useful error messages
Position the message at the top of the page itself not in a pop-up, dialog box or separate page Clearly distinguish the message from the rest of the page In the message, use plain English to: o Explain the problem... o ...and how to fix the problem o Do not use technical jargon or codes

Indicate the location of errors on the form itself

Highlight at the location o Graphics and colour together work well for accessibility reasons, do not rely on colour alone If possible, provide more information about the error at the site of the error: o For example, the number of the problem 'error 2 of 4' o Even a repeat how to fix the problem

Notes and discussion points What about client site validation? If you have client-side validation check for errors as the user leaves each element:
But do not prevent the user from navigating around the form because of an error in one of the form elements Consider greying out the submit button while the form is incomplete or there are errors on the page

P a g e | 65

P a g e | 66

6 Search
Top level advice on how to implement simple and advanced search on your site, and the essentials of providing search results that can be readily understood and refined 6a Search form design 6b Search results design

P a g e | 67

6a Search form design

Simple search
Make simple search available from every page (a simple search form or a link to a search page see note below) Provide an obvious and appropriate label (or hint in the text box) that provides the scope of the search o For example, search this site For a simple search form use a single text entry box Provide an obvious button to submit the search Place the search consistently across the site Only provide extra options (such as extra filters) if these are likely to be used frequently and your site is big enough that it is likely to produce enough results to warrant it o If using extra filters, ensure the default is set appropriately in case it goes unnoticed o Choose the most simple form elements for the filter a radio button, check boxe or a drop-down menu [see 5c]

Advanced search
Include an advanced search to assist people if they need to perform complex searches, such as: o Combinations of search terms using AND/OR (known as boolean logic) o Searching in a certain area or for a certain category of output only (sometimes called faceted search) If it is likely to be often needed, include a link to an advanced search next to the simple search form o Otherwise make the advanced search option available once an initial search has been made to allow the user to refine the results In the advanced search form: o Use appropriate form elements to assist people to construct more complex searches without them needing to understand Boolean logic o Provide the most useful filters

Additional considerations: If possible implement a search algorithm that performs fuzzy rather than exact matching so results will be returned for:
Plurals and fragments of words Misspellings Related words and concepts

If possible, provide the ability for expert searchers to construct boolean and other more complex queries by typing directly into the simple search box, rather than having to fill out the advanced search

P a g e | 68

Notes and discussion points Should it just be a link to basic search on every page instead of a simple form? If search is going to be used a lot on your site, put a form directly on each page that will enable a simple search to be executed otherwise you might consider just a link to an appropriate search form

P a g e | 69

P a g e | 70

6b Search results design

On the results page, provide visible feedback about the search performed and provide the ability to easily modify or refine the search
A good way to do both of the above together is by : o Providing a text box that contains the full search query in it so it can be modified by typing directly o Associating the text box clearly with the results displayed

Provide the most appropriate default order for the results and permit people to change the sort order to match their needs
Provide sort by controls or obviously clickable table headers Ensure the current sort in operation is clearly indicated

Indicate how many results were returned by the search Provide appropriate pagination controls to go beyond the first screen of results Present a clear title for each individual result and make the title a link that is easily recognisable as a link to the page or item Present supporting information to assist people to make better choices between the returned results this may be a combination of the following:
A description of each returned item An extract from each item that contains the searched for terms o Ideally the search terms are emphasised visually in the extract Information about important facets or attributes of each item, for example: o The category or section to which it belongs o The date o The author o Subject tags or keywords associated with the item

Notes and discussion points Limited by the algorithm? Ultimately the results you are capable of displaying are limited by the algorithm your search system uses but most of the above should be achievable

P a g e | 71

P a g e | 72

7 QA & Standards
The key aspects of accessibility with pointers to the more specific COI guidelines in the vitally important area. Top level information on how to ensure the quality of your site with pointers to the more specific COI guidance on this topic 7a Basics of standards compliance and accessibility 7b Quality assurance and monitoring

P a g e | 73

7a Basics of standards compliance and accessibility

Your site must be accessible to a at least WCAG 1.0 level double-A (the minimum standard set by the COI for all public sector sites see notes section below for more details), this includes (but is not limited to) the following requirements:
Provide appropriate alternative text for all images [see 4a] Structure each page such that they are still readable and usable if no styles or visual layout is applied [see 1b] Use explicit labels for all form elements [see 5a] Code tables properly Ensure the contrast of text and informational images is sufficiently high Ensure all information is communicated without relying on colour Ensure all of the sites features, functions and content are available via the keyboard (without relying on the mouse) Ensure that pages do not flash or flicker Provide transcripts and captions for multimedia Ensure all PDFs are accessible [see 8a]

Accessibility is a more complex topic that can be covered here, Delivering Inclusive websites (COI guidance produced June 2008) provides more information about accessibility and the steps you are required to take Your site must use valid markup and CSS (or other Web technology) code
Include a doctype statement at the start of each page to indicate which standard you are using Use all markup/tags for the intended purpose Do not use deprecated tags Check HTML and XML via the W3C Markup Validation service Check CSS style sheets via the W3C CSS Validation Service

Test the site using the popular browsers

Firefox: must test to version 3.0,.x should test to version 2.0.x Internet Explorer: must test to version 6 and 7, should test for version 5.5 Safari: must test to version 3.x, should test to version 5.5 Chrome: must test to version 0.2.x Opera: must test to version 9.x, should test to version 8

Notes and discussion points Why is accessibility important? Accessibility is a vitally important component of all websites. The Disability Discrimination Act 2005 amended the Disability Discrimination Act 1995 (DDA) and placed an additional duty on the public sector to promote disability equality in the full range of public sector activity including delivery of information and services via the Web. Only if your website is accessible will it meet your legal obligations.

P a g e | 74

As well as meeting your obligations an accessible site has additional benefits including:
It reaches a wider audience (regardless of ability or disability) by working on a wider variety of browser and device combinations (such as mobile phones and handheld computers) It will tend to appear higher in search engine rankings It is easier to update, maintain and repurpose for other formats

What level of accessibility do I need to reach? The minimum standard of accessibility for all public sector websites is Level DoubleA of the W3C Web Content Accessibility Guidelines version 1.0 (WCAG 1.0). All new websites must conform to these guidelines from the point of publication Version 2.0 of the Web Content accessibility guidelines became a W3C Recommendation in December 2008. Consideration is currently being given to the adoption of version 2.0 as the minimum standard for public sector websites.

P a g e | 75

P a g e | 76

7b Quality assurance and monitoring

COI has recently developed guidance for assessing the quality and value of government Websites (currently in draft) The guidance for reporting website quality provides a directive and a method to measure the success of a website in terms of:
User satisfaction Usability Standards compliance Editorial quality Success in delivering site objectives

In particular you should measure user satisfaction using an online survey

A minimum of once per year With figures reported annually using the COI standardised report template

In addition where possible you should:

Provide easy access to new information Allow users to subscribe to changes which might affect them Remove out-of-date material promptly o If you are using a content management system (CMS) then set an expiry date to ensure automatic removal Monitor the site regularly o Look for patterns of usage in the live site and repond accordingly (for example: promoting important and popular content, fixing issues) Respond promptly to any enquiries o Acknowledge the users contact and set an expected response time o Analyse the questions frequently submitted and if appropriate create a Frequently Asked Questions (FAQ) section with anonymous versions of questions and your responses [see 8c]

P a g e | 77

P a g e | 78

8 Common Pages
The basic rules of how to produce a good homepage that people will readily understand and act upon. How to design and structure other commonly occurring pages such as the site map, site index and FAQ pages 8a Basics of homepage design 8b Site map design 8c FAQ design

P a g e | 79

8a Basics of homepage design

Clearly establish your organisations identity
Use the official logo and branding Provide an appropriate tag line that shows the key mission of the organisation/site Provide brief about us information o And a link to more about us

Clearly establish the purpose of the site and provide clear calls to action to the main sections within the page
Provide content examples that demonstrate the key sections, information types and functions, and provide clear calls to action from those. o Do not rely solely on global navigation bars put the most important items in prominent locations on the homepage If the content examples do not adequately explain the purpose, use concise and highly factual text to describe the purpose and what is available

Put the most important items high up on the page but do not be frightened of creating a page that requires vertical scrolling if you have valuable content to put on there
Avoid scroll blockers [see 1b] and structure the page to advertise that value is to be had by scrolling further down

Provide dynamic up-to-date information to reinforce trust and give access to the newest items, for example:
Dated news or articles This weeks most popular

Ensure that the homepage downloads quickly

Avoid unnecessary large imagery, animations, and plug-ins

Make sure your homepage presents immediately useful and relevant information
Avoid splash pages or animated introductions

Disable the links to the homepage on the homepage itself

For example, on the homepage the logo and the home link should not be active

Make the majority of the page about your target audience rather than about you and your organisation
Facilitate their needs Demonstrate the benefits to them of the site or service Use their language

P a g e | 80

Additional considerations: If appropriate, provide cookie based customisation

Allowing the site to remember preferences and deliver the most appropriate content Test with people. Be sure to research and test this thoroughly to ensure it is delivering what people want

Notes and discussion points Should the homepage be the same format as the rest of the site? The homepage is a special page that can look and feel slightly different to the rest of the site, although aspects of the quality and brand, and the basic navigation should be established What should the main heading title of the homepage be? The homepage should still be as structured as possible [see 1b] potentially use the logo as the <h1> header if there is no obvious in-page title (only do this on the homepage though other pages should have in-page titles) Homepages should not be created without due consideration of:
Audience behaviours and characteristics The audiences goals and tasks

This should be considered throughout the site development process as part of a user centred design process

P a g e | 81

P a g e | 82

P a g e | 83

8b Site map design

Provide access to all the features on the site via the site map
Keep it up-to-date to reflect the present site structure and contents Include the major categories, sections and subsections you should not include every link!

Organise according to your audiences needs

Not necessarily directly reflecting the Web directory structure o Although, if you have good audience centric information architecture, they should be the same Clearly communicate hierarchies and relationships using titles and indented lists

Display as much information as possible at the top of the page

A grid structure will do this better than a simple long list of links Get rid of adverts, related links and so on

Link to the site map from every page

Apart from the site map itself

Ensure the visited links status is displayed

Differentiate from visited and un-visited links to aid navigation [see 2b]

Notes and discussion points Site map or site index? For some sites it is more logical to have a site index arranged alphabetically. Use a site index where your audience is likely to know what they are looking for and you have clear and well known titles for your contents. Provide in-page alphabet menu (a through to z) so that people can jump to items starting with a particular letter. In a site index you can also include synonyms to cross reference the actual titles you are using with those that are also likely to be searched for.

P a g e | 84

P a g e | 85

8c FAQ design
Research the questions with your audience
Make them actual Frequently Asked Questions and not just a repository for information you cannot fit anywhere else

Create a clear list of questions at the top of the page and organise the list logically
Order according to priority (and frequency of the query) but also logically (that is, basic information first before the complex information) Group questions together (particularly if there are more than 20 questions), for example: o Group by popularity (such as the top 10 asked questions) o Group by topic

If there are only a few questions, list all questions and their answers on the same page
Maintain the order that was established in the list of questions at the top Repeat the question right next to the answer Structure and style so the question is clearly differentiated from the answer For long pages, consider using a back to top link

Link to the FAQ page from all pages

Apart from the FAQ page itself

Number the questions if the order that makes logical sense otherwise just list Notes and discussion points Do I need an FAQ page? No but they can be useful for some types of site

P a g e | 86

P a g e | 87

About this toolkit

In July 2008 The Power of Information Taskforce commissioned research from the user experience agency Bunnyfoot to identify good and bad aspects of government websites. The review found that some government websites are failing to get the basics right, for example:
Not helping people to navigate the site easily Not helping search engines like Google to find the site Not speaking the language of the user

The Cabinet Office asked COI to develop usability guidelines for web developers and web content editors across government covering the basics of usability in a way that is engaging and interactive. The aim is to raise awareness of usability issues across government and to improve the quality of government websites. The guidelines cover 8 broad themes:
Layout and design Navigation Writing content Content elements Forms Search QA and standards Common pages (e.g. homepage)

The guidelines contain a total of 21 individual guidance modules ranging from Basics of page layout to When and how to use PDFs. Each module has been written to be consumed and understood in just 5-10 minutes and is illustrated with examples of good and poor practice. In addition there are self assessment tests, tracking of progress through the guidelines, and toolkits for downloading.

P a g e | 88

Acknowledgements
The primary author of the guidance was Dr Jon Dodd (MD Bunyfoot Ltd.) with contributions from the following people:
Adam Bailin (Digital policy manager COI) Jon Dixon (Bunnyfoot Ltd.) Dipesh Mistry (Bunnyfoot Ltd.) Dave Roberts (Independent user-centred-design consultant) Nick Pattman (3Chillies Ltd.) Bryan Archer (3Chillies Ltd.)

Many thanks to reviewers of early drafts and participants in usability (and comprehensibility) testing sessions. They came from the following organisations:
Directgov Business Link NHS Choices COI DEFRA BERR