New regulations have recently come into force which mean from September this year, every new public sector website and app will need to meet certain accessibility standards and publish a statement saying they have been met. Existing websites will have until 2020 to comply.

The aim of the regulations is to ensure public sector websites and mobile apps are accessible to all users, especially those with disabilities.

The new regulations are calledThe Public Sector Bodies (Websites and Mobile Applications) (No.2) Accessibility Regulations 2018. They are now law in the UK and implement the EU Directive on the accessibility of public sector websites and mobile applications.

The important dates

You’ll need to comply with the regulations from 23 September 2019. This is when it will start applying to new websites (those published after 22 September 2018). They come into force in 3 stages (with deadline to comply with the regulations):

  • New public sector websites (published after 22 September 2018) – 22 September 2019
  • All other public sector websites – 22 September 2020
  • Public sector mobile applications – 22 June 2021

The requirements will apply to all public sector bodies, although certain organisations and types of content may be exempt.

PDF (problem document format)

Compared with HTML content, information published in a PDF is harder to find, use and maintain. More importantly, unless created with sufficient care PDFs can often be bad for accessibility and rarely comply with open standards.

Many government departments are doing great work to move away from them. For example, the Driver and Vehicle Standards Agency (DVSA) blogged about how it created and published its strategy in HTML and Public Health England has written about its work to move away from PDFs.

The default should be to create all content in HTML. If you can’t avoid publishing a PDF, ideally it should be in addition to an HTML version and the PDF must meet accessibility standards and archiving standards.

Problems with PDFs

They do not change size to fit the browser

On a responsive website like, content and page elements shift around to suit the size of the user’s device and browser. However, PDFs are not designed to be flexible in their layout. They generally require a lot of zooming in and out, and scrolling both vertically and horizontally. This is especially troublesome with long documents and on small devices like mobile phones.

They’re not designed for reading on screens

People read differently on the web, so it’s really important to create content that is clear, concise, structured appropriately and focused on meeting the user need. A PDF document that was created for offline use will not suit the context of the web and is likely to result in a poor user experience.

It’s harder to track their use

We cannot get as much information from analytics about how people are using PDFs. We can get data on how many times a PDF has been downloaded from a website, but we cannot measure views of the file offline.

In addition, we cannot get data about how users have interacted with a PDF – for example how long they’ve viewed it for or what links they’ve followed. This makes it harder to identify issues or find ways to make improvements.

They cause difficulties for navigation and orientation

Depending on the user’s device and browser, PDFs might open in a new browser window, new tab or a separate app. Sometimes they automatically download to the user’s device. Whatever happens, the user is taken away from the website when they open a PDF. This means they lose the context of the website and its navigation, making it harder for them to go back if they need to.

This is even more of an issue if the user goes directly to the PDF from a search engine. Without the context of the site the PDF is hosted on, they can’t easily browse to related content or search the website.

It’s also worth remembering that although many devices and browsers have PDF viewers built-in – and they are freely available to download – there are still users who do not have them, or cannot download them.

PDFs generally require a lot of zooming in and out and scrolling to read the content on a mobile phone.

They can be hard for some users to access

The accessibility of a PDF depends on how it was created. For example, it needs to have a logical structure based on tags and headings, meaningful document properties, readable body text, good colour contrast and text alternatives for images. It takes time to do this properly.

Even if this work is done according to best practice, there’s still no guarantee that PDF content will meet the accessibility needs of users and their technology. Operating systems, browsers and devices all work slightly differently and so do the wide variety of assistive technologies such as screen readers, magnifiers and literacy software.

Some users need to change browser settings such as colours and text size to make web content easier to read. It’s difficult to do this for content in PDFs. You can magnify the file, but the words might not wrap and the font might pixelate, making for a poor user experience. Locking content into a PDF limits the ability for people to make these kind of accessibility customisations.

It’s our responsibility to ensure that our users can access the information we publish. Plus, publishing content in HTML will also reduce the need to supply alternative formats on demand to users who can’t access a PDF.

They’re less likely to be kept up-to-date

Compared with HTML, it’s harder to update a PDF once it’s been created and published. PDFs are also less likely to be actively maintained, which can lead to broken links and users getting the wrong information. This can be especially problematic if a document has been published in multiple formats. Any changes need to be made to all the versions, meaning more work and more opportunities for error.

In addition, users are more likely to download a PDF and continue to refer to it and share it offline. They may not expect the content in the PDF to change and might not check the website to get the latest information. HTML documents encourage people to refer to the website for the latest version.

They’re hard to reuse

It can be very difficult to reuse content from a PDF by copy and pasting it. The design and layout of the PDF can produce unexpected results, particularly if it has multiple columns, hasn’t been structured correctly, or uses incompatible fonts.

Similarly, users cannot use browser extensions and add-ons such as Google translate on PDF content.

Making your advice accessible

AdviceAid SelfServ utilises the GOV.UK Design System (GDS), with an emphasis on accessibility for all users. We want to ensure your prevention advice is accessible by everyone, at all times.

Information is presented in HTML format, supporting a wide range of accessibility tools (such as text-to-voice). Users also have the option to print straight from their web browser, or email the advice to themselves or a friend.

Our Compose module provides Housing Advisors the tools to provide a huge wealth of written, quality advice and share with customers in a number of ways. You no longer need to rely on a collection of out-of-date and inaccessible PDF advice sheets.

With AdviceAid, ensure your advice offer is compliant, up-to-date and accessible to all of your customers.

Thomas Fowler is Co-Founder and COO of AdviceAid. He has an extensive history of designing services for vulnerable people both in the voluntary and public sector. Thomas was responsible for developing the UK’s first direct access hostel on a working farm. He is passionate about tech for the common good.

Connect with Thomas on LinkedIn and Twitter