Accessibility Guidance Alpha
Table of contents
This is draft guidance for discussion. Please note this is not official guidance.

Accessibility Guidance

This guidance was last updated on 26 July 2018

Background

This document sets out the standard of accessibility required for public sector websites and mobile apps and contains practical guidance on how to achieve this.

‘Accessibility’ refers to principles and techniques to follow when you design, build, maintain and update websites and mobile apps in order to remove barriers to use, especially for people with disabilities.

The Public Sector Bodies (Websites and Mobile applications) Accessibility Regulations 2018 (known as ‘the Regulations’ in this document) requires public sector bodies to take the necessary measures to make their websites and mobile applications more accessible by making them perceivable, operable, understandable and robust, unless it would be disproportionate to do so.

The Regulations builds on existing UK legislation and commitments:

  • The Equality Act 2010 legally protects people from discrimination in the workplace and in wider society
  • The UK has approved the United Nations Convention on the Rights of Persons with Disabilities (UNCRPD) which requires measures to ensure access for persons with disabilities, on equal basis with others to information, communication technologies and the internet

Why Accessibility is important

In addition to the legal drivers, there are social, financial and technical incentives for accessibility.

Social factors

Public sector websites must address the needs of citizens across the country. An accessible website can provide access to information on a far wider scale than previously possible. Social incentives for accessibility include:

  • Disabled people have easier access to printed, audio or visual material
  • Citizens can access services and information, regardless of experience or ability
  • Everyone will find the website easier to use, improving their ability to successfully complete goals online.
  • People using all kinds of devices, from the oldest to the newest, will be able to use the website, helping to reduce the impact of the digital divide
  • Greater interaction between citizens and government is possible with a user friendly, accessible website

Financial factors

A user friendly and accessible website can reduce costs both directly and indirectly. Accessibility is viewed as an expensive afterthought, but it can provide many cost benefits. The key is to build in accessibility from the outset, making inclusive design a priority throughout the development lifecycle of the website. Financial incentives for inclusive design include:

  • Accessible web pages tend to be lighter (physically smaller) which reduces bandwidth costs and improves page response times - leading to improved customer experience
  • Increasingly, people will be able to access services and information online, representing a reduction in costs needed for support resources such as call centres
  • Ongoing maintenance and hosting costs can be significantly reduced
  • Providing one website supporting multiple audiences is more efficient than running multiple websites for multiple audiences

Technical factors

Technical concerns vary throughout the different levels of government. The resources and technical capabilities of a district council may differ from those of a central government body. Improving technical performance and delivering reliable digital services is important across the board. Technical incentives for inclusive design include:

  • Following recognised standards and guidelines for web accessibility can help ensure that future technologies will be able to access the site
  • Compatibility with more browsers and technologies such as mobile.
  • Access to a wide range of assistive technologies
  • Improved levels of traffic may be driven to the site through Search Engine Optimisation (SEO)

Accessibility Requirements

The regulations require public sector bodies to take the necessary measures to make their websites and mobile applications more accessible by making them perceivable, operable, understandable and robust.

Websites and mobile apps must meet this standard by the following dates:

  • New public sector websites published after 23 September 2018 by 23 September 2019.
  • Existing public sector websites by 23 September 2020
  • Mobile applications by 23 June 2021

Websites include intranets and extranets and non-web documents such as PDFs.

Public sector bodies will need to evaluate the accessibility of their websites and mobile applications. They will then be expected to fix any issues and provide detail of this in an accessibility statement hosted on their website. If there are areas of inaccessible content, the organisation responsible will have to explain the way in which the content is not accessible and the reason for it. They will also have to provide accessible alternatives where appropriate.

The Regulations applies to ‘public sector bodies’. The definition is the same used for EU procurement, so those bodies who are subject to the EU procurement rules will usually be subject to this Regulations. This covers central and local government among other publicly funded organisations.

There are some exceptions to this. For example, public service broadcasters and some types of published content are exempt, such as online maps and pre-recorded videos published before September 2020.

The Web Content Accessibility Guidelines

The principles of perceivable, operable, understandable and robust are set out in the Web Content Accessibility Guidelines.

Perceivable

‘Perceivable’ means that information and user interface components must be presented to users in ways they can perceive in some way - it can’t be invisible to all of their senses.

  • Images have appropriate alternative text
  • Videos have captions and audio descriptions
  • The web page or document include headings, lists and other semantic elements to communicate document structure
  • The tab order and read order are logical and intuitive
  • Form fields have appropriately coded labels and prompts
  • You avoided using visual characteristics to communicate information
  • Content is available if you can’t distinguish colors
  • The interface have sufficient contrast between text color and background color
  • Text can be resized without losing information

Operable

‘Operable’ means that any person must be able to use interface components (such as buttons and forms) and navigation. These can’t require interaction that a user can’t perform.

  • Everything on the page be operated by keyboard alone
  • The web page include a visible focus indicator
  • Pages that have time limits include mechanisms for adjusting those limits
  • The web page or document have a title that describes its topic or purpose
  • Mechanisms in place that allow users to bypass blocks of content
  • Link text is meaningful, independent of context

Understandable

‘Understandable’ means users must be able to understand any information presented, as well as being able to operate the interface (the content or operation cannot be beyond their understanding)

  • The language of the content has been defined
  • You avoided links, controls, or form fields that automatically trigger a change in context
  • Navigation is consistent
  • Forms provide helpful, accessible error and verification messages

Robust

‘Robust’ means that the content must be capable of being interpreted reliably by a wide variety of user agents, including assistive technologies such as screen readers. It also means users must be able to access the content as technology changes over time

  • The web page is coded using valid HTML (or at least well formed and correctly nested HTML)
  • Dynamic interfaces are coded correctly

For pragmatic help on meeting WCAG you can refer to:

The Web Content Accessibility Guidelines (known as WCAG 2.0) are an internationally recognised set of recommendations, created by the World Wide Web Consortium (W3C), for improving web accessibility.

They explain how to make digital services accessible to everyone, including users with impairments to their:

  • sight - blind, partially sighted or colour blind people
  • hearing - people who are deaf or hard of hearing
  • mobility - like those who find it difficult to use a mouse or keyboard
  • thinking and understanding - people with dyslexia, autism or other learning difficulties

The EN 301 549 Accessibility Standard

EN 301 549 is a standard which specifies a broad range of accessibility requirements applicable to ICT products and services (including web pages, non-web documents and software).

If you meet this standard you will be deemed to meet the requirements of the regulations.

EN 301 549 leverages WCAG for websites, non-html documents and software.

The standard has two main sections. The first outlines the accessibility needs of different user groups. The second has detailed requirements on how user’s need must be met for different products and services.

Accessibility needs

The standard has a series of functional performance statements which describe the accessibility needs that need to be met:

  • usage without vision
  • usage with limited vision
  • usage without perception of colour
  • usage without hearing
  • usage with limited hearing
  • usage without vocal capability
  • usage with limited manipulation or strength
  • usage with limited reach
  • minimize photosensitive seizure triggers
  • usage with limited cognition

Accessibility requirements

The standard also has a list of functional accessibility requirements for different types of products and services, each of which need to be met in order to satisfy the procurement guidelines. Requirements focus on the way that information can be presented, viewed, or interacted with.

Accessibility requirements for websites and web content leverage the Web Content Accessibility Guidelines, explicitly stating WCAG 2.0 Level AA (including Level A) as the benchmark. Where it’s appropriate, relevant WCAG criteria have been applied to other technologies, such as non-web documents and software.

Accessibility statements

You are required to publish an accessibility statement.

It must:

  • be in an accessible format
  • be updated frequently
  • use the model accessibility statement framework adopted by the European Commission (this will be provided by Dec 2018)

It must include:

  • a list of any parts of the website or app that aren’t accessible, an explanation of why, and links to accessible alternatives
  • a feedback mechanism that can be used by any person to tell you about content in the website or app that doesn’t meet the accessibility requirements, and to request information they are excluded from. This information could include content that is excluded from the scope of the Regulations such as documents, pre-recorded time-based media or the content of archived websites.In response to a legitimate and reasonable request, you should provide information within a reasonable period of time.
  • a link to the UK government’s enforcement procedure which people can use in the event of an unsatisfactory response to the use of the feedback mechanism above

Information about how the accessibility of apps must be either on the public sector bodies website or on the appropriate App store.

Measuring accessibility

You must review the accessibility of you website and mobile applications.

You should consider technical accessibility and usable accessibility when reviewing accessibility.

Technical accessibility determines whether the site meets WCAG 2.0 and will work with a range of assistive technologies. Usable accessibility determines whether the site will be usable by disabled people.

You should develop an accessibility test plan to ensure you meet accessibility requirements. When developing your accessibility test plan, you should consider using an appropriate mixture of tools and techniques. For example, you may wish to use expert reviews early on in the development cycle, user testing on later designs and automated testing at regular intervals. Please note that this approach may not be appropriate in specific cases. It serves to highlight that different methods for evaluating accessibility which may be more or less appropriate at different stages of the development cycle.

Your accessibility test plan should include methods for testing both technical and usable accessibility.

How to test for technical accessibility

Approaches for determining technical accessibility include:

  • Automated testing to determine whether the website upholds some of the checkpoints of the Web Content Accessibility Guidelines (WCAG);
  • Manual testing to find issues that can not be found using an automated testing tool;
  • Assistive technology testing to determine whether the website can be accessed using the tools commonly used by disabled users.
  • Conformance evaluation to determine the Web Content Accessibility Guidelines (WCAG) conformance level for the website or check that it meets a specified WCAG conformance level;

Automated testing

There are a number of free and commercially available automated testing tools that provide a way to measure conformance to some of the W3C guidelines. Website developers and testers should be aware of the capabilities and limitations of the tool being used. Although these tools check for a relatively small proportion of the W3C guidelines, they can be useful for analysing an entire site for technical accessibility. Validation testing should also be undertaken by website developers to ensure that their mark-up conforms to W3C guidelines and specifications. The W3C Markup Validation Service should be used to validate HTML. This is an important exercise as assistive technologies may rely on mark-up meeting these specifications.

Manual testing

Many accessibility issues can not be found using an automated testing tool and require a manual check such as checking keyboard access or if the alternative text provided for an image is appropriate. You can use the accessibility checklist created by 18F (the US government’s digital agency) to help you identify potential accessibility issues.

Assistive technology testing

Assistive technology tool testing is how to check the tools commonly used by disabled users can read and interact with the web content and controls can be activated. If a website conforms to the W3C guidelines, assistive technologies should work with the site. Assistive technology tool tests can provide a quick way for a tester with specialist knowledge of the tools to assess the website’s technical accessibility.

Conformance evaluation

A conformance evaluation is a systematic manual review of each web page against the W3C guidelines as specified, which typically follows a validation test and involves reviewing each piece of content and control on a page. Conformance inspections provide a single method for determining whether a website upholds WCAG. However, they are time consuming and require an expert in accessibility, usability and website design.

Because of the amount of effort spent inspecting a page, a useful technique is to test a representative sample of the total web pages. This sample may be pages with high usage or involve critical functions such as form filling.

For more information refer to the W3C’s Conformance Evaluation Overview

How to test for usable accessibility

Methods for determining usable accessibility include:

  • Expert reviews, involving specialists in usability and accessibility, to evaluate the website in order to find potential problems;
  • User testing to identify any usability and accessibility problems real-world users may have.

Expert review

There are different types of structured expert review methods, including:

  • Heuristic evaluation, where an interface is inspected against a set of heuristics or guidelines
  • Cognitive walk-through, where evaluators step through a series of actions with a goal of completing a typical user task

In all cases, experts can use assistive technology as part of the expert review process. However, specialist training is often required to make sure that how technologies are used closely matches how a disabled person would use them.

Expert reviews can be conducted on early designs and finished code and are relatively quick and inexpensive to perform. They can identify quality and consistency issues not typically identified during user testing. However, they do not find the same type or number of problems as user testing and in some cases can identify problems that real users would not experience. It should also be noted that the quality of the findings is directly related to the skill and experience of the experts.

User testing

User testing involves recruiting a set of representative users and asking them to attempt to use a website to achieve a set of representative tasks. User testing should include users with a range of disabilities and preferences, including a mix of beginners and experienced web users using a range of assistive technologies.

It is recommended that user testing is included in all website development projects as it provides the best evidence that a website will be usable by disabled people.

The main categories of impairment to consider

There are four main categories of impairment to consider. These are vision impairment; motor difficulties; cognitive and learning; and deaf and hard of hearing.

Vision impairment

Users with severe vision impairment, e.g. users of screen reader software. Screen reader users typically have issues with poorly labelled images, or links which don’t make sense when read out of context.

Users with medium vision impairment, e.g. users of magnification software. Magnification users are hindered by images of text (which become pixelated at high resolutions).

Users with mild vision impairment, e.g. users who might enlarge text in the browser with high contrast and use colour preferences.

Motor difficulties

Users with severe motor difficulties, e.g. users who are quadriplegic who might use speech recognition software, switch access or eye-gaze technology as an alternative to the keyboard or mouse.

Users with medium motor difficulties or upper limb disorder, e.g. users who might only use a keyboard, a mouse being too difficult to use. Keyboard users have issues with navigation or forms that don’t have a logical tab order.

Users with mild motor difficulties, e.g. users who might use a mouse or equivalent adaptive technology but who might have fine mouse control difficulties. Link size is an important issue for this group of users.

Cognitive and learning

Users with medium dyslexia, e.g. users who might change site colours or text formatting, and who might supplement this with text to speech software for reading sections of text.

Users with mild to medium learning or cognitive disabilities, e.g. users who might use a symbol browser to convert web pages to symbols or have no special access methodologies and rely on someone else assisting them.

Deaf and hard of hearing

British Sign Language (BSL) users who might experience problems with multimedia content or complex language.

Non-signing deaf or hard of hearing, e.g. users who might benefit from captions or transcripts of audio content.

The above categorisation is purely for illustrative purposes. In reality, users may have a combination of impairments. For example, older users may have a combination of reduced vision, restricted mobility and decline in memory.

Older users

Older people can suffer from physical disabilities, such as a restricted ability to move their arms or hands. They might experience difficulty using a mouse.

The performance of the eye diminishes with age and can lead to decreased visual acuity, contrast or colour sensitivity, reduced field of vision, or an increased sensitivity to glare. Older people that have such visual impairments tend to find it difficult to point to specific objects on the screen and click on small icons with the mouse.

Older people that suffer from a reduced spatial ability and a decline in memory might find it difficult to navigate deep hierarchies of a website.

For more information to help you understand the range of human capability, the barriers that people with disabilities face on the web and how to remove them:

Assistive technology

Assistive technologies are any item, piece of equipment, software or hardware system that helps a person with disabilities to interact with computers. The following page describes some of the more common examples.

Screen readers

Screen readers are software applications that read the text on a web page. Most screen readers can also read alternative (alt) text for images. If a web page includes accessibility features, a screen reader can usually provide the user with more information about the page - for example, by announcing heading levels or by reading all the links on the page.

Braille displays

These are hardware devices that provide tactile outputs that are generally set up to output from screen reader software, but instead of outputting through a speech synthesiser they output to a refreshable retractable Braille display or a fixed single line display. Braille displays are unable to output multimedia or graphics content and totally rely on the provision of appropriate text and text alternatives.

Screen magnifiers

Magnifiers or enlargers work by increasing the size of the image displayed on a screen. Navigation can be a problem as the user may only see a portion of the original screen at any one moment.

Speech recognition

These applications allow a user to give commands and enter data by talking to their computer - so the input device is a microphone rather than a keyboard. Such software contains a vocabulary and users need to train the software to recognise their individual voices.

Adaptive hardware and input devices

Users with a physical disability are more likely to struggle using the standard keyboard or mouse and may find it easier using ergonomic or specialised devices. Specialised keyboard and mouse designs are often referred to as assistive technology. Common technologies employed by physically disabled users are: alternative keyboards, on-screen keyboard emulators, mice, switches and pointing devices.

Speech enablement

This falls into two categories: first - applications that enable browsing of web content in audio. Combining text-to-speech technology they are generally limited to web browsing. This technology does not cope with multimedia or graphical content and therefore relies on the provision of appropriate text and alternative texts. Second - there is speech enablement as a channel, either client-based or served-based, intended as an option for users who have difficulties reading a website. This is a text-to-speech method that offers enhanced legibility for users with dyslexia, learning difficulties or with English as a second language.

Accessibility basics

This section suggests possible design solutions to problems that might be faced by people using your website. This is not an exhaustive list of web accessibility guidelines; it illustrates some of the techniques that may be used to make your website more usable by a wider population. Wherever possible, the impact for different user profiles is explained.

Language and text

Keep the content simple

Avoid the use of jargon and complex words. This can be helpful for users with cognitive impairments, and benefits all users.

Justified text

Text shouldn’t be justified as users with dyslexia find this more difficult to read than left aligned text.

Graphical text

The use of images of text is undesirable for a number of reasons.

Users who have low vision may prefer different fonts or colour combinations, may need to increase the text using browser options, or use magnification software to enlarge the text beyond the maximum size the browser can offer.

Images of text cannot have their appearance altered by the user - they cannot be enlarged in most browsers, cannot have their colours altered to a higher contrast combination (e.g. white on black) and cannot have their font changed to one preferred by the user.

Unlike normal text, images of text become pixelated when enlarged by magnification software (particularly at higher levels), so users reliant upon this method of access can have significant difficulty in reading the information.

Images of text should be limited to logos and not used for items such as headings or navigation.

Ensure that text size can be changed

Ensure that text sizes are not fixed and can be resized. Some people need to change the text size to make it more legible. Users with motor control difficulties may need to increase the text size to make it easier to select links.

Make a big clickable area

Ensure that links and images are a good size and not too close together. Ensure that the ‘Go’ button on a ‘Search form’ is large enough for users who have poor motor control to be able to select the button easily.

Link text should give the user a clear idea of the destination and make sense when read out of context. Avoid the use of 'click here’, for example. This is very important for screen reader users who may use a list of links to navigate the page.

Keyboard shortcuts

Providing a 'skip to content’ link enhances the accessibility for users accessing the website via the keyboard, particularly if they have to tab through a large number of navigational links to get to the main content.

Highlighting 'skip to content’ links as they are activated may be useful for keyboard-only users with vision (e.g. motor impaired) as this may be the only cue to their existence.

Ensure that all functionality is available through the keyboard as well as the mouse

This can be checked by tabbing through links and forms using the keyboard to ensure they can be accessed in a sensible order. This is important because users with visual impairments will not have good hand-eye coordination and are more likely to interact with the website solely through the use of their keyboard.

Images

Images and icons

Images and other media used to enhance textual content can often aid in the understanding of the information. This can be helpful users with cognitive impairments.

Alternative (alt) text

Ensure that all meaningful images have meaningful alt text. This alt text is read out by the screen reader so that the user understands what is being shown on the screen. This is important for users with severe vision impairments.

One of the most common alt text mistakes is to use “Image (or picture or photo) of x”. A screen reader will tell the user that an image is present - they don’t need this information twice. Do not start alt text with “Image, picture or photo of… ”

Use empty alt text if normal text already conveys the information provided by the image. For example, if you use a document thumbnail to illustrate a text link to a PDF, and the text link includes the title of the document, use empty alt text for the image (a pair of double quotes with no space between them). Using alt text that repeats the title of the document is pointless and distracting for users of screen readers.

Use empty alt text for any images that are purely decorative.

Colour

Allow for flexibility

Some dyslexic users find it more comfortable to read text on a beige background. Ensure that colours can be changed in the browser and that they have not been forced by the web developer. You could also consider offering a different stylesheet.

Do not rely on colour alone to convey information

Blind users may not be able to get information about colour definitions from their screen reading software and using colour also presents difficulties for colour blind users.

Use good contrasting colours

Consider using a tool such as The Paciello Group’s Colour Contrast Analyser to help you measure colour contrast and determine the best combinations.

Layout

Consistent design

This can be helpful users with cognitive impairments, and benefits all users.

White space

Separating page elements using white space makes it easier for users with cognitive difficulties to read web pages.

Forms

Associating labels with form fields is important for screen reader users so that they can identify which label describes each form field. For more information on creating accessible forms, please refer to WebAIM.

It is important to allow sufficient space in form fields to allow users to enter the correct information.

CAPTCHAS

A CAPTCHA (Completely Automated Public Turing Tests to Tell Computers and Humans Apart) is a feature/tool to ensure that user input has not been generated by a computer. The problem with CAPTCHAs is that they are not accessible to all types of users, which mean that some users will not be able to complete the form on the website. For example, an image-based CAPTCHA can be very difficult or impossible to complete for users who are blind or have low-vision.

Many of the risks that CAPTCHAs are aimed at reducing can be addressed in other ways. For more information on using CAPTCHAS, please refer to the GOV.UK Service Manual.

Tables

Associate data cells with their headers for data tables

Using table headers for data tables helps a screen reader user to associate the content of a data cell with the row or column it’s in. For more information on creating accessible tables, please refer to WebAIM.

Animation

Ensure animation can be paused or switched off

Animation can be a distraction and seriously compromise the ability of people with learning disabilities to read content on a page. If you provide moving content ensure there is a way to disable the movement.

Audio and video content

Captions and transcripts

Audio and video content can be inaccessible to deaf and hard of hearing users. Providing a text equivalent is important for these users but also beneficial to others for example, users in a noisy environment.

Text equivalents for a movie

Text equivalents should be provided for an entire movie in cases where the movie can be conveyed using a single text equivalent. Examples include movies that show a simple animation, banner adverts or complex multi-media that cannot otherwise be made accessible.

Provide accessible controls

When providing audio or video on a website, it is important to provide accessible controls to allow users (including keyboard and screen reader users) to interact with the video playback controls.

Non-HTML Documents

The presentation of lengthy non-HTML documents on the Web should generally be avoided in favour of web pages. However, there may be instances where documents will need to remain in their original form e.g. for legal reasons. For these documents, there are a basic set of guidelines which should be adhered to:

  • Ensure the text is sans serif (e.g. Arial, Helvetica), with a minimum font size of 12 points.
  • Ensure the text is left aligned, not justified as justified text leads to 'rivers of white text’ being distracting to the reader.
  • White space can be just as useful as the text. Over cluttering and complicating the page reduces readability.
  • Avoid excessive use of capitalised, underlined or italicised text, consider bold for emphasis.
  • Avoid underlining, except for links.
  • Hyperlinks should be spelt out (e.g. in a footnote or endnote) because users may only have access to the printed version.

Styles and Headings

Use heading styles for headings - not simply bigger or bolder text. Heading styles ensure consistency; make a document easier to navigate for sighted users (and easier to maintain); and enable automatic tables of contents. They normally provide the document with a built-in structure that is accessible to screen readers - when a Word document is converted to PDF, for example.

If you intend to publish Microsoft Word documents, it is important to consider their accessibility and usability. When a document has been created using the styles and headings features specified above, those reading the document (and also those creating them) can use various inbuilt navigation systems. For mouse users the Document Map is available (View > Document Map). By clicking headings displayed in the Document Map this expands or collapses headings in the tree and allows users to jump instantly to that heading in the main document. Screen reader users can use the Outline view (View > Outline) to achieve much the same effect or alternatively use the navigation features built into their screen reader software such as 'Headings list’.

More detailed information to make your Word documents accessible is available on the Microsoft website.

PDF (Portable Document Format)

The portable document format (PDF) can be accessible if authors follow established best practices to include appropriate structure and equivalents for users with disabilities. It is important for PDF authors to incorporate within their PDF authoring workflows those steps that result in the creation of accessible PDF files.

PDF is a destination format, that is to say PDF files begin in other applications, such as desktop publishing and word processing programs or as another file type, typically as a TIFF file in the case of scanned documents. Measures should be taken to maximise the accessibility in the source in order to enhance the accessibility of the resulting PDF file when converted.

The basic guidelines for non-HTML documents should always be followed.

In addition to the basic guidelines for non-HTML documents, publishers of PDF files should:

  • Use tools and techniques that will result in the production of accessible PDF documents.
  • Use the facilities (if available) in the word processing or authoring application to add meaningful alternative text to any graphics that appear in the document.
  • Use features inbuilt into the word processor or design package to correctly specify heading levels and other styles to identify document elements such as Titles and Headings.
  • Document authors using the source document should avoid character formatting techniques such as bolding text and modifying the font and size of text to create the visual appearance of heading levels and other structural elements.
  • For tabular information, use the word processor or design package’s inbuilt table editor (if available).
  • If possible, select products that provide authors with the option to export tagged accessible PDF. This will reduce the amount of time verifying structure after the PDF is produced.
  • If you intend to create a PDF by scanning a paper document, submit the content to Optical Character Recognition (OCR) and add the necessary accessibility components prior to distributing the PDF file (see section on PDF accessibility repair below).
  • If you intend to use the PDF as an interactive document or form, add form fields and other controls with appropriate short descriptions for the form elements and controls.

Repairing or improving the accessibility of an existing PDF file

If a PDF file is created without following the above guidelines, it may require additional enhancements to improve its accessibility. To optimise the accessibility of existing or legacy PDF files, use the following process to determine that the PDF file:

  • was created by scanning a printed page. Perform optical character recognition (OCR) on documents that were created as a result of scanning a document to create a PDF image of the scanned page.
  • is intended to be used as an interactive document or form. If so, add form fields and other controls with appropriate short descriptions for the form elements and controls.
  • has been given structure or “tagged”. If it has not been tagged, add tags to the file. Tags specify the logical read order of the PDF file and provide hooks for other accessibility elements such as alternative text descriptions for graphics.

When the PDF file has been tagged, add alternative text to graphics in the document and short descriptions to any form fields and interactive controls that form part of the document.

Verify that the tagging is correct by evaluating its read order and ensuring all necessary alternate text elements are present for graphics and multimedia elements. If the document is a form or features interactive navigation, verify that short description labels are provided for form fields and interactive controls.

For more detailed information refer to the AcceDe PDF Project which provides detailed guidance on Making PDF documents accessible with Adobe Acrobat Pro (PDF, 5.8Mb).

The Web Content Accessibility Guidelines can be applied to non-HTML document. Please refer to Chapter 10: Non-web documents of EN 301 549 for an adapted version of WCAG.

Mobile Applications

Mobile applications are software applications designed to run on mobile devices such as smartphones and tablets. Mobile applications can be divided into three types, native apps, web apps and hybrid apps. Differences among them are as follows -

  • A native app is a downloadable software application which is platform specific and can be used offline, in most circumstances. Native apps need to be downloaded from the market places and installed on a mobile device before running.
  • A web app is an Internet-based application which has to be launched by a mobile device’s browser. As the source files are stored on a server, Internet connection is required but downloading or installation is not necessary.
  • A hybrid app is a combination of native app and web app. It is built using open web standards such as HTML5, CSS and JavaScript. Like native apps, hybrid apps are required to be downloaded and installed on the mobile devices.

Mobile applications are usually referred to native apps or hybrid apps which require downloading and installation on a mobile device.

The Web Content Accessibility Guidelines can be applied to mobile applications. Please refer to Chapter 11: Software of EN 301 549 fo an adapted version of WCAG.

For practical help for creating and testing accessible mobile applications refer to the Mobile Accessibility Testing Guide for Android and iOS (PDF, 2.5Mb) by The Paciello Group.

Procurement

Fixing an inaccessible website or mobile app after it has been completed can be difficult and costly and may not succeed in providing effective access. The best way to create an accessible website is to ensure that accessibility criteria are included throughout the project life cycle, starting with procurement or commissioning.

To help in the process of procuring accessible websites, the European Commission has developed the Accessible ICT Procurement Toolkit which includes the following guidance:

  1. Writing a Call for Tenders provides practical advice and samples of text describing accessibility requirements and criteria that can be cut and pasted into your Call for Tenders. These can be used when developing Mandatory Requirements and Award Criteria. They can also be used in a second competition following a framework agreement.
  2. Evaluating Tenders contains guidelines to validate the supplier’s capacity in ICT accessibility. You will find guidance on declarations and other types of statements on conformity to request from the suppliers.
  3. Evaluating Deliverables provides guidance on how to ensure that deliverables fulfil the specified accessibility requirements.
  4. Managing Contracts provides guidance on how you could ensure that the accessibility of the delivered product or service is maintained, or even improved, during the course of the contract. In the context of procurement, follow-up of the supplier’s performance of the contract is often known as (part of) contract management.

When you do not need to meet the rules

The new requirements will apply to public sector bodies.

Some organisations and types of content do not need to meet the new Regulations. However, the requirements of the Equality Act 2010 still remain and require services provided by Public Sector Bodies excluded from these regulations to not discriminate against people with disabilities.

If the requirements place a disproportionate burden

You’ll need to assess what steps you need to take to make your website or app meet the new standards, if it does not already.

Your organisation will not need to meet the new standards if doing so would create a disproportionate burden.

To work out what’s proportionate, consider things like:

  • the benefits to users with disabilities of meeting the standards
  • the cost of compliance
  • the size of your organisation
  • your audience

You won’t be exempt based on a lack of priority, time or knowledge.

If your assessment shows that the changes you’d need to make would place a disproportionate burden on your organisation, you must:

  • explain this in your accessibility statement
  • include an explanation of what parts of the requirements you could not comply with
  • what accessible alternatives you provide, if any

Special rules for schools, nurseries, NGOs and broadcasters

There are special rules for:

  • schools, nursery kindergartens or nurseries - only content relating to essential online administrative functions needs to meet the new rules
  • non-governmental organisations (NGOs) - you only need to meet the rules if you provide services essential to the public, or services that specifically address the needs of persons with disabilities

Public sector broadcasters, and their subsidiaries, are exempt.

Types of content that are exempt

The new requirements will not apply to:

  • documents that are not intended primarily for use on the web and that are included in web pages (such as PDFs, MS Office documents or equivalent) published before 23 September 2018
  • pre-recorded media, such as videos and podcasts, published before 23 September 2020
  • live video
  • online maps and mapping services, as long as essential information is provided in an accessible digital manner for maps intended for navigational use
  • third party content that is not under the control of the public sector body concerned
  • reproductions of items in heritage collections, such as scanned manuscripts
  • content of intranets and extranets published before 23 September 2019, until those websites undergo a substantial revision
  • content of websites and mobile applications qualifying as archives, meaning that they only contain content that is not needed for active administrative processes or updated or edited after 23 September 2019