How we display fees
Use this pattern to display a list of fees for a service.
Where possible, use the term 'fees' rather than 'costs' or 'charges'. When we use consistent language across the website, we can make it easier for users to understand what they are reading.
Consider whether you need a page dedicated to showing a service's fees or if they can just be published on any page that has a fee. This will usually be preferably to duplicating content.
Example
When to use this pattern
This pattern works when users need:
- to choose from a list of options
- to pay different fees depending on their preference or circumstances
- help to work out which fees they need to pay
How it works
This pattern uses the table component within a page template. It can be used within any content template, but is often used within an information page or inline index child page.
Your page should include:
- a page title that describes what the page is about, such as 'Activity fees for short breaks funded by the council'
- any information that the users need to help them work out which fee or charge is relevant to them
- information about how they can pay the fee or charge
- date that the table was published, if users might expect the fees to change
You can use the 'highlight' component to highlight important information, such as an extra fees that are not detailed in the table.
Good practice when using tables
Only use tables as a way of presenting data. Do not use tables as a way of formatting text. Most screen readers used by visually impaired people struggle to read tables, which makes the information difficult to understand. Tables should be straightforward and uncluttered. If your table is complicated, present the information in a different way.
If you need to explain something about the fees in your table, do this in the body copy.
Add columns to include extra detail. Try not to use more than 3 columns and keep the information in each column brief. If you need to add explanations or guidance, write these in the body copy rather than the table.
Give your table a title
Give your table a title that helps the user find the fees that are relevant them. Your title should work on its own, regardless of what context it is in.
Good example: Activity fees: targeted short breaks
Bad example: Fees
Use more than one table if you need to
You can use more than one table in one page. If you have a long list of fees, you can use headings and additional tables to help the user find the information they need.
Consider using separate tables with a header above each one if you can group your fees, for example by:
- different user groups (when different fees apply to different age groups)
- areas or location
- type of service
- period that the fee covers
Make sure every row is complete
Don't list several items under one fee. Make sure every row contains information, even if you are repeating the same fee against different items. Blank spaces in tables can be confusing for people using screen readers.
Formatting your text
Always follow our style guide when writing content for the website.
When displaying fees:
- use the £ symbol: £75
- do not use decimals unless pence are included: £75.50 but not £75.00
- do not use ‘£0.xx million’ for amounts less than £1 million.
- write out pence in full: calls will cost 4 pence per minute from a landline.
- show currencies in lower case
Avoid using bold text in tables as this can be hard to read for users of assistive technology.
Give your columns clear headers and avoid unnecessary words. The table title should explain what the table is about. Column headers should describe the item in each column, for example, 'fees', 'term' or 'type of activity'.
Help with this pattern
Contact the webteam via ServiceNow if you need to:
- ask a question
- get help with this pattern
- get help with writing content
- make a suggestion for something we need to include in this guidance
You can find more guidance on writing content in the content design resources in the GOV.UK Service Manual.
We are still researching these patterns. If you have any research or suggestions that could help us improve this pattern, please tell the Web Team.