Government Digital Service
Writing accessible documents
Follow these steps when you write a document. If you have questions, contact your website publishing team.
1. Think about format
Doing this will help your document support as many users as possible and can future-proof your information.
Publish in HTML format wherever possible so that your documents use your users custom browser settings. It can be difficult to make other formats easier to read. For example, PDF documents:
- can make your content harder to find, use and maintain
- do not work well with assistive technologies like screen readers a lot of the time
If your documents do not meet accessibility standards you could be breaking the Equality Act 2010.
Contact the team responsible for your website to find out more about how to publish in HTML.
2. Keep the language simple
Use clear and simple language.
Simple language makes your document accessible to people with cognitive impairments and learning disabilities.
Research shows that most users prefers simple language, including specialist audiences. This helps users to understand and process information quickly.
Where you need to use technical terms, abbreviations or acronyms, explain what they mean the first time you use them.
3. Keep the document structure simple
Give the document a meaningful title.
Keep sentences and paragraphs short. Aim for around 25 words or less per sentence.
Use a sans serif font like Arial or Helvetica. Use a minimum size of 12 points.
Use sentence case. Avoid all caps text and italics.
Make sure the text is left aligned, not justified.
Avoid underlining, except for links.
Make sure link text clearly describes where the link goes. It should also be understandable on its own, even if read out of context. This is because some screen reader users list links on a page to find what they need quickly.
Documents with single continuous columns of text are easier to make accessible than documents with a complex layout.
Only use tables for data. Keep tables simple: avoid splitting or merging cells.
Do not use things like colour or shape alone to show meaning. Instructions like click the big green button rely on the user to see the page and someone who is colour blind may not see the green button.
If youre using images or charts, think about how youll make the content accessible to people with a visual impairment. Two options are:
- make the same point in the text of the document (so people with visual impairments get the information they need - the image or chart is there as an extra for people who are able to see it)
- give the person converting or uploading the document for you alt text (alternative text) for the image or chart
Do not use images containing text, as its not possible to resize the text in the image and screen readers cannot read text which is part of an image.
Avoid footnotes where possible. Provide explanations inline instead.
4. Give the document a structure
Break up your document to make it more readable. Use bullet points, numbered steps and meaningful subheadings.
Do not use bold to mark up subheadings. Use styles to create a hierarchy of headings: heading 1, heading 2 and so on.
Use styles for tables and bullet lists. That way, a screen reader will recognise the formatting and read out the content correctly.
Ask your website publishing team if youre not sure how to do this.
Follow the guidance on structuring and tagging your document in an accessible way if youre using:
5. Forms, complex documents and other office formats
Build forms in HTML where possible or build digital services using components from GOV.UK design system.
Publish forms in OpenDocument (.odt) if you cannot use HTML.
If youre creating another type of office document (for example a spreadsheet or presentation), theres guidance on how to make it accessible on the Accessible Digital Office Document Project website.
Making non-HTML documents accessible
HTML documents are best for accessibility and you should always consider publishing your document in HTML. If this is not possible and you are creating a document in Word or PDF, apply the same guidelines as when creating an HTML document.
Make sure you:
- use headings instead of bold text
- do not skip heading levels
- use table headers
- use meaningful link text
- run an accessibility check in the document
Avoid using:
- short link text
- decorative images, including those used for layout purposes such as horizontal line separators
Forms
If you need to publish a form, follow the form guidance.
Spreadsheets
If you are creating a spreadsheet, follow the making analytical publications accessible guidance.
Run an accessibility check
Most software comes with a basic accessibility checker. Use this feature to make sure your document is accessible before uploading it to GOV.UK.
If you are not sure how to do this, search run an accessibility check [name of software] in your search engine.
PDFs on GOV.UK
Turn existing PDFs into:
- HTML if it is to be viewed
- an OpenDocument if it is to be edited, such as a form
Read more about which open format to publish your document in.
If you need to keep the PDF, you must publish an accessible version with it. If you do not, you may be breaking the law.
Its simpler to create HTML from an OpenDocument or Word Document than it is to try to make a PDF accessible for all users.
To help you with Govspeak Markdown (which is used on GOV.UK), you can use:
- Markdown guidance
- the Govspeak converter to change formatted text into Govspeak
PDFs on Other government websites
Turn existing PDFs into HTML to improve accessibility and to reach as many users as possible. You need the source document to create an HTML webpage.
Creating a new document as PDF is a last resort and should be avoided unless there is a specific business need. You should always provide an HTML version too.
Make sure your source document is accessible before you convert to PDF. You can find tutorials on how to improve PDF accessibility on office suites.
Once you convert it into a PDF and use an accessibility checker to check for issues you may have missed.
Make sure you meet government accessibility requirements and WCAG 2.1 standards.