Accessible documents (attachments)

We are reducing the use of PDFs on our website. PDFs are hard to use on mobile, often fail accessibility standards, and are difficult to keep up to date. 

PDFs are popular because they are quick to create and share. Many organisations, including ours, have become over reliant on them. They were designed to share documents like Word and Excel files in a consistent fixed format (equivalent to a printed page).

PDFs offer a poor user experience online

• Poor mobile experience: Most users access our site on mobile. PDFs are hard to read and require zooming and scrolling. They were designed for print, not for digital display on a wide range of devices and screen sizes.
• Accessibility issues: Many PDFs do not work well with screen readers or allow users to adjust text size, colours, or language. This can prevent people from accessing our services and may not meet legal requirements.
• Better search and insight: Webpages (HTML) help us track how people use our site. They are easier to find in search engines and work better with AI tools.
• Hard to maintain: PDFs files are harder to check with online quality assurance tools for things like broken links or outdated contacts. Due to fixed publishing, they may need replacing when edits have been made. Old versions of the document may remain on the the user's devices.
• Slower and less usable: PDFs can be large files and slow to open, especially on poor internet connections.
• In correct format: Making an online user move to offline process - for example PDFs with a paper based form. Or a marketing poster - that is not required if the user is on the webpage the poster promotes.

The official Government guidance outlines that PDFs should be viewed as a 'last resort' and should generally be replaced or accompanied by an HTML equivalent. For further insights on this shift, you can read the GOV.UK blog on HTML vs. PDF.

The good news is there is an alternative to enable the publishing of 'documents'. This involves presenting the content in HTML.

The primary reasons to move to HTML formatted documents:

• Superior accessibility: HTML can be read by screen readers and easily adapted to suit a user's needs (e.g. resizing text, changing colours, flexible layouts - in any language).
• Mobile-friendly: HTML pages automatically adjust to fit any screen size (phones, tablets, and desktops).
• Easier to find: Search engines (like Google and internal site search) can crawl and index the text of an HTML page directly. This ensures users get accurate, deep-linked results.
• Up-to-date and maintainable: When guidance or policies change, HTML pages can be updated instantly. A PDF requires a new file to be created, uploaded, and re-linked, often with a new URL, making it harder for users to know if they are looking at the latest version.
• Performance and analytics: Webpages use less data to load, aiding users with limited internet connectivity. HTML also allows us to track analytics, helping teams improve pages based on how users interact with them.

New template

We have created specific template to support lengthy and complex documents. It will be treated like a supplied document (PDF), but presented using HTML formatting, rather than being displayed with Adobe Reader. The main content page will still be the landing page for the user, with a secondary action (link) to access the HTML document.

Although our main webpages will follow our website writing guide - the html document format can be more reflective of the original tone.

There will be a conversion process - adapting a supplied document and repopulating into a HTML template with the look and feel of our website style and formatting. In the first phase this is likely to be a manual conversion, but with continual development we hope to automate more elements and gain efficiencies.

The approach is based on GOV.UK - like this example document.

This is an example of a complex statement of accounts

We are also considering additional components to support the Easy Read format in later phases.

We are reducing the number of PDFs on our website. We have cut them by around 50% since April 2025, but more work is required for the several hundred remaining.

So far, we have focused on merging small or basic PDFs into existing webpages. We have also removed PDFs that duplicated content, were out of date, or rarely used. We will now continue to work with page owners and service managers to review the more complex PDFs on the website, and convert them to HTML format (maintaining document approach), or merge them into relevant content pages. 

We will be reviewing all existing PDFs and replacing them where possible in discussion with owners. We will not upload PDFs to the website for all new requests that are not exempt from 1 Jan 2027. 

This is a council-wide change and will take time. Not all areas of the website will update at the same pace. We have also strengthened governance that supports this work and principle to reduce our use of PDFs. It is also an aspiration of Local Government Reorganisation that the new local authority website will not have PDF attachments. 

Moving to HTML still has challenges, even though the benefits are clear

• Creating web content is very different from using Word. We do not expect staff to be familiar with HTML code. But a well structured document will convert to HTML with less issues and closer to the original intent.
• We may need to change how we design/create documents so they align better with how content appears online - a change around expectations and approach. We need to change how we think about design. Fixed layouts may look good, but they will not meet all user needs and don't work online.
• Fixed designs still have a role in print and marketing, but are not an online format. This is not about replacing the need for hard copy materials - but ensuring the right format is used in the right place.
• Converting Word documents to HTML will change how content looks. Your Word document will not match the final web based HTML document, but content and messaging will be retained.
• Publishing HTML content may take more time - no longer a case of just publishing a supplied PDF. However, this extra effort will improve quality, accessibility, and user experience. Service may need to allow more time for publishing, 3-5 working days.
• Establishing a framework / process to ensure 'policy' documents are checked and updated regularly, ownership of the source content remains with them, and there is clarity on how and where to access the HTML document online.

In most instances, the content of a supplied document can be integrated into our website content pages, or our structured HTML document format.

However, there are a few exceptions when you can publish an accessible PDF or other document type on the website. These exceptions include:

• Architect drawings, technical drawings (preserved format)
• Sealed notices and orders (preserved format)
• Scanned documents (preserved format)
• Structured data, for example a working spreadsheet or CSV file
• Where specified in legislation (statutory requirement)
• Material that is intended for print, distribution, physical display, or to be used as a template for you to download, store and complete on your own device
• Heritage collections like scanned manuscripts
• Third party content that’s under someone else’s control (link to third party website ideally)

If a document is from an external source and published elsewhere, we will hyperlink to it, rather than host it on our own website.

We may also upload a PDF temporarily for a maximum of two weeks, while reviewing options, or creating the final HTML version - where not doing so would be in breach of a legal/statutory publishing deadline.

Legal/statutory requirements

Does it explicitly say that the information must be published or made available in a PDF or office file format such as Excel or Word? Does it state it must be in an exact preserved format? Often this is not the case and publishing in HTML is suitable. With sealed orders, can the content be published online and an image attached showing the seal, and made available on request, especially if views of the document have been low in the past.

Branding

You can still commission visually appealing reports or other documents for your project or service, especially for print or direct distribution. But if you want this information to go on one of the council digital channels like peterborough.gov.uk, it can’t be a PDF or Microsoft Office document. We make a distinction between the user needs offline and the user needs online, when considering the purpose of the design. 

People who use a screen reader, or those who are unable to use a mouse, need to be able to navigate a document using keyboard shortcuts or tabbing. Clear relevant headings also help a user to decide if they want to read the following text.

Break up your document to make it more readable. Use meaningful headings and subheadings, also use bullet points, numbered steps. Use the icons for bullet lists (Home tab). That way, a screen reader will recognise the formatting and read out the content correctly. A heading should summarise all the content underneath it. Do not add content under a heading which is unrelated to it, as screen reader users may not be able to find it.

Headings

A good heading structure is often the most important accessibility consideration in Word documents - especially as it requires human processing to set up and check.

Screen reader users can navigate Word documents by headings. For example, access a list of all headings in the document, jump from heading to heading, or even navigate by heading levels. However, this only works if Word's heading styles are used. Unfortunately, it is a common practice to create a 'heading' by highlighting the text and applying a different font, a larger font size, bold formatting, etc. using Word's Font styles. These Font styles will provide visual headings but not the document structure needed for navigation by assistive technology.

Heading levels should represent the structure of the document

• A Heading 1 is for the cover title / first heading depending on the design of the materials, only use one H1 in your document
• A Heading 2 should identify the core subject area or concepts.
• A Heading 3 is a sub-section of the Heading 2. Use this to break up the information still related to previous heading 2.
• A Heading 4 is a sub-section of the Heading 3, and so on.

You should not skip heading levels, such as using a Heading 4 after a Heading 2. Return back to Heading 1 or 2 for each new content group.

Note: Word supports Headings 1-9, but webpages and PDF files only support 6 levels of headings. For this reason, we recommend limiting yourself to Headings 1-6, although 4 headings is often more than enough.

Using heading styles

1. Select the text you want to turn into a heading

2. On the Home tab (In the ribbon), select a heading style (Styles selector). For example, Heading 1 or Heading 2.

Your Styles may only include heading 1 and heading 2 initially on new documents - after using Heading 2, Heading 3 will be added to the Styles selector for use. Don't worry about what the headings look like. You can modify the look of these headings.

Modify heading styles

Right click on each type of heading, select “Modify” and then change the font, colour, size, space after and space before.

Note: Although not as essential for accessibility, making good use of styles is a huge timesaver, and good for consistency. Consider setting up styles for various body text styles, captions, pull quotes etc. When you create a document that uses style sheets, you can modify the style and this will change all the instances of that style on your document - useful to make final changes such as a colour change.

Check document structure

1. On the View tab (In the ribbon), select Navigation Pane (in 'show' section).
2. You will now see a pane on the left of your screen - select 'Headings' to view your content as a hierarchical tree of headings - this should also read logically, similar to scan reading a document.

Further information and video (headings)

Improve heading accessibility (Microsoft)

Version issues

You need to save your documents in the latest version of Microsoft Word (Office 365 docx), as older compatibility versions such as '1997-2003' can create issues with accessibility checkers and conversion to PDF.

The 'save as PDF' function or 'export as PDF' function in Microsoft software can create issues during conversion. When supplying documents, please supply the original as these additional conversion issues can then be avoided.

Document title

It may look like you have a title for your document - the file name - but you also need to check the 'document title' in the document metadata and add your title here.

Click File > Info > then in the right column enter your document title.

Document language

The language must be defined. Most of the time this happens automatically, but may be missing on older documents or documents you have not created yourself. The language must be defined correctly for screen readers.

Click File > More > options > Language (in pop-up window) > and check the appropriate default language is set.

Further information and video (document setup)

Create accessible file names and set up document properties (Microsoft)

People who are blind, have low vision or are colour blind might miss out on the meaning conveyed by colours alone so use other distinguishing factors such as labels, patterns or text alternatives.

Use sufficient contrast for text and background colours

The Word accessibility checker will analyse the document and find insufficient colour contrast. The tool checks the documents for text colour against page colour, table cell backgrounds, highlight, textbox fill colour, paragraph shading, shape and SmartArt fills, headers and footers, and links.

However, if you have any doubts, or using combinations of colours you haven't before, manually check your document. Double check any text that may be hard to read or distinguish from a background colour, or background artefact (such as watermark or pattern).

• Company logos do not need to meet WCAG 2.1 accessibility criterion ("Text that is part of a logo or brand name has no contrast requirement"). However, if you have flexibility with the logo design and can make it pass contrast guidelines, that's a great thing to do. As the logo is an image, it will require alt text.
• Hyperlinks should be underlined to define them (not just colour) this is also why you should not use underline for any other design/style purpose.

The WebAim website provides a colour contrast checker. You can choose the font and background colours using the RGB codes and then see if they are accessible for normal and large size text. You can adjust the shades until you find a colour combination that is accessible. Make sure it passes WCAG AA standard.

Alternative text is a textual substitute for non-text content. When a screen reader arrives at an image or object in a document, it will read out the contents of the alt text field to the user to describe it.

The 'Accessibility Checker' will highlight where alt text has been missed, but human processing is required to identify what description is required.

Alt text function in Word documents:

You can add "alt text" text to Pictures, Shapes, Charts, and SmartArt. To add alt text in a Word document, right-click on the image or object, select 'Edit alt text' and then fill in the description field, or if 'decorative' select the checkbox.

Alternative text 'description' should be:

• Accurate and informative – present the content as the image does - e.g. "A chart showing the team structure" would not be correct for a team structure chart. In this situation, you should describe in alt text exactly what you can see in the chart, names, positions and direct reports.
• Succinct – a few words are usually enough; and shouldn’t be longer than a short sentence or two.

Alternative text 'descriptions' should not:

• Contain duplicate information that is in the surrounding text or caption.
• Use phrases such as 'image of' or 'graphic of' - screen readers identify images and objects so the user may hear "image image of an apple.
• Be included where the image, or object is purely to enhance the design of the document. These need to be marked up as 'decorative' instead of using alt text. See below.

Decorative images and objects

Decorative objects add visual interest but aren't informative (for example, stylistic borders or lines). People using screen readers will hear these are decorative so they know they aren't missing any information. All elements on a page must have alt text set, but do not have to have an 'alt text description' if the 'decorative image' checkbox is selected.

Complex diagrams or maps

If there is too much information to be succinct, or the image information is critical to the main content, the information should be explained in the surrounding text. Avoid using images that have lots of text within them. This information should be presented as text within the document rather than in an image.

Further information and video

Improve accessibility with alt text (Microsoft)

Hyperlinks (URLs) can be used by users to navigate through content on a document or on a webpage. They work best when written in a descriptive way. Hyperlinks need to be easily identified by the screen reader so should be given a clear and accurate title that informs the user where they will be directed to.

Type your descriptive text - e.g. 'Apply for a secondary school place'. Then highlight this text, right click and select Link. Enter the URL into the address field.

If the overall document is explaining the Peterborough City Council school admissions process, then the above link description would be a suitable. However, if it takes you to another website, then this should need to be explained. E.g. - 'View the schools ratings on the Ofsted website'.

Considerations for hyperlinks

• A document may need to be a 'standalone print document' - so you might want to limit the hyperlinks in the document, and add just one to your associated webpage where applicable.
• If there are lots of hyperlinks required in your document, it may be better as web content.
• Screen reader users may skim a document by navigating from link to link. Avoid ambiguous link text that is difficult to understand out of context (e.g., "click here").
• Link text should contain no more than 70 characters
• Don't use the same hyperlink in a document with two different descriptive texts
• All links should be visible and not hidden in images
• Link text should be underlined

Short URLs

If you want to promote a certain page, or where you are doing print campaigns, you may want to consider a short URL. The Web Team can provide these after a quick look at the requirements and usage check.

• www.peterborough.gov.uk/bins-waste-and-recycling/household-waste/household-recycling-centre
• www.peterborough.gov.uk/hrc

This is preferable to an encoded/anonymous short URL such as bitly links.

Further information and video

Create accessible hyperlink (Microsoft)

When creating a document for publishing online, the information in our writing style guide and Plain English guidance applies to documents also. All information published online should be in Plain English and have a reading age between 9-13 years old.

Visually a user could scan a table to make associations between data in the table and their appropriate row and/or column headers. Screen reader can make these same associations if the tables are structured correctly. The tools for creating accessible tables in documents are limited, so keep tables simple, or break up complex tables into multiple tables.

Only use tables for displaying 'data' and not an alternative way of laying out information in a grid or for design reasons. Consider whether your data really needs to be in a table. Could you display it as a list or content sectioned by subheadings.

Table properties

A screen reader will announce the table format to the user, along with the number of rows and columns and the table description text. This allows the user to get an insight into the table structure and to skip the table if not relevant to them).

You must include a table description that explains briefly the content/purpose of the table. You can add a title here, but this is not supported by PDF, so we recommend you add a title before the table using an appropriate Header style.

From any cell in the table Right click, select table properties, go to Alt Text tab.

Table header row and cells

Screen readers keep track of their location in a table by counting table cells. If a table is nested within another table or if a cell is merged or split, the screen reader loses count and can’t provide helpful information about the table after that point. Blank cells in a table could also mislead someone using a screen reader into thinking that there is nothing more in the table. Screen readers use header information to identify rows and columns and make the association to relevant data.

• Always create a table using Word’s built-in functionality
• Make sure each header corresponds to the data it relates to
• Split long or complex tables into shorter ones
• Make sure you don’t use merged or split cells in your table
• Avoid using colour as the only way to convey information in a table
• Keep all the lines visible on the table for columns and rows
• Gaps in your data must be identified with text - a screen reader will not announce punctuation, dashes or spaces aloud

Insert table using the Insert tab on the ribbon and select size of the table.

To choose a row as a header:

1. Select the row you want to change
2. Right-click and choose 'Table Properties'
3. Select the Row tab and check ’Repeat as header row’
4. Optional, but recommended - uncheck, ‘Allow row to break across pages’.

It is recommended to style your table using the defined styles (Table design tab in ribbon when table selected). Tick the Header Row checkbox to allow the style to visually display the header row style.

Further information and video

Create accessible tables (Microsoft)