skip to main content
 Logo

Accessibility Standards

The Public Sector Bodies (Websites and Mobile Applications) (No. 2) Accessibility Regulations 2018 (‘the accessibility regulations’) came into force for public sector bodies on 23 September 2018. They state local authorities must make their websites or mobile applications (apps) more accessible by making them ‘perceivable, operable, understandable and robust’. All public sector bodies have to meet the requirements, unless they are exempt.

The local authority is therefore legally responsible for ensuring its website meets accessibility requirements, even if it has outsourced its website to a supplier.

To meet government accessibility requirements, digital services must:

Government guidance states that most public sector websites and mobile apps do not currently meet accessibility requirements. For example, a study by the Society for Innovation, Technology and Modernisation found that four in 10 local council homepages failed basic tests for accessibility.

Common problems include websites that are not easy to use on a mobile or cannot be navigated using a keyboard, inaccessible PDF forms that cannot be read out on screen readers, and poor colour contrast that makes text difficult to read – especially for visually impaired people.

The local authority may be breaking the law if its public sector website or mobile app does not meet accessibility requirements.

Government advice is to publish in HTML format (web enabled pages) wherever possible. It can be difficult to make other formats easier to read. For example, PDF documents:

Problems Arising when using PDFs in Websites

The Government Digital Service sets out the following problems with PDFs.

They do not change size to fit the browser:

On a responsive website, 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 are not designed for reading on screens:

People read differently on the web, so it is 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 is harder to track their use:

Site usage analytics does not provide much information about how people are using PDFs.

For example, data cannot reveal how users have interacted with a PDF, such as how long they have viewed it for or what links they have 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 separate app. Sometimes they automatically download to the user’s device. These take the user away from the web browser, meaning they lose the context of the website and its navigation.

Also, 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.

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 is 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 is difficult to do this for content in PDFs. The file can be magnified, 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 kinds of accessibility customisations.

They are less likely to be kept up to date:

Compared with HTML, it is harder to update a PDF once it has 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 are 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, has not been structured correctly or uses incompatible fonts.

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

Government advice on publishing accessible documents is that creating a new document as PDF is a last resort and should be avoided unless there is a specific business need. An HTML version should always be provided too.

Our Offer

At Policy Partners Project we provide accessible websites for our policy and procedures sites, compliant with the Web Content Accessibility Guidelines version 2.2 AA standard. We work with our customers to minimise the use of PDFs and replace legacy documents.

We want as many people as possible to be able to use our procedures websites. For example, that means users should be able to:

  • change colours and font sizes via our accessibility stylesheets;
  • zoom in up to 300% without the text spilling off the screen;
  • view all video content with subtitles on by default;
  • navigate most of the website using just a keyboard;
  • navigate most of the website using speech recognition software;
  • listen to most of the website using a screen reader (including the most recent versions of JAWS, NVDA and VoiceOver).

 

More information:

      LinkedIn