Website accessibility compliance for parish & town councils explained
Website W3C & WCAG 2.1 accessibility compliance for public body websites
– What it means and what you need to do.
The aim of this article is set out what you need to do and how to do it.
Content index
1. Background – why are we here?
2. What do those organisations affected need to do?
3. What is meant by accessibility?
4. W3C and WCAG – what’s the difference?
5. Disproportionate burden
6. Key dates for compliance
7. Who does the work?
8. How will the accessibility regulations be monitored & enforced?
9. WCAG 2.1 A, AA & AAA ratings. Mobile friendliness – suitability for all device sizes
10. PDFs & non-compliant content – how to handle historical & new content
11. What do I need to do?
12. The WCAG 2.1 compliance accessibility checklist
13. Ongoing compliance
14. W3C & WCAG 2.1 AA rating website packages for parish & town councils
Background – why are we here?
The Public Sector Bodies (Websites & Mobile Applications (No.2)) Accessibility Regulations 2018 came into force on 23 September 2018. WCAG – or Web Content Accessibility Guidelines is part of this regulation created by the W3C – Worldwide Web Consortium, a non-profit global body that sets the standards in terms of best practice guidelines for website accessibility.
Its aim is to ensure public sector websites and mobile apps are accessible to all users, especially those with disabilities.
All new public sector websites will need to meet accessibility standards and publish an accessibility statement according to the level of the standard they have met.
Some organisations might not have to fully meet the regulations if doing so would be a ‘disproportionate burden’ – we’ll cover what that means later on. Depending on their resources, these organisations may take some steps towards meeting parts of the requirements now, with a view to making further changes in time and as resources become available.
Public sector bodies include:
- central government and local government organisations
- some charities and other non-government organisations
This means that all UK service providers have a legal obligation to make reasonable adjustments under the Equality Act 2010 or the Disability Discrimination Act 1995 (in Northern Ireland) to ensure they comply.
But the following types of organisation are exempt from the 2018 regulations:
- non-government organisations like charities – unless they are mostly financed by public funding, provide services that are essential to the public or aimed at people with a disability.
- schools or nurseries – except for the content people need in order to use their services, such as a form for a parent or guardian to make a child’s school meal preferences.
- public sector broadcasters and their subsidiaries
You can read the official statement here on the Government’s GDAS website: https://www.gov.uk/guidance/accessibility-requirements-for-public-sector-websites-and-apps
What do those organisations affected need to do?
- Create a compliant accessibility statement that directly relates to the website or app
- Ensure the organisation’s website or app to meet the minimum standard of compliance – known as WCAG 2.1 AA.
Let’s deal with the thing that’s needed first – The accessibility statement:
All organisations that need to comply must make clear the level of accessibility across their website or app and where there are any barriers which must be set out in an accessibility statement informing users of alternative routes to access the content.
The statement needs to comply to a standard format template – an example can be found here: https://www.gov.uk/government/publications/sample-accessibility-statement
The statement must also provide suitable other methods to enable users to contact the website owner if they identify issues not identified.
Any website published since September 2018 will need an accessibility statement by 30 September 2019, while older websites have until 2020 to comply.
Many public sector bodies already publish accessibility information on their website. The new regulations mean this information will have to be presented in a consistent way and based on a model statement so that accessibility standards and terms used to describe things are consistent to help users better understand the scope of the regulations.
The accessibility statement should:
- list any inaccessible parts of the website (or app)
- show how people with access needs can get alternatives to content that’s not accessible
- provide details on who to contact to report accessibility issues
- provide information on the appeal procedure if people are not happy with the response
- be published in a fully accessible form
- follow a consistent format
The statement will also need to be updated annually.
NEXT – Making the website itself compliant and better accessible. This is addressed by looking at what changes might be needed in order to make it compliant and ultimately more accessible to those with disabilities. The first place to start is with the accessibility of a website and what it means.
What is meant by accessibility?
Making a website or mobile app ‘accessible’ means making sure it can be used by as many people as possible regardless of their abilities or disabilities. At least 1 in 5 people in the UK have a long-term illness, impairment or disability. Many more have a temporary disability.
This includes those with:
- impaired vision
- motor difficulties
- cognitive impairments or learning disabilities
- deafness or impaired hearing
The regulation has been introduced to provide those users with the same rights of access as those that do not have any difficulties.
Accessibility means more than putting things online. It means making your content and design clear and simple enough so that most people can use it without needing to adapt it, while supporting those who do need to adapt things.
For example, someone with impaired vision might use a screen reader (software that lets a user navigate a website and ‘read out’ the content), braille display or screen magnifier. Or someone with motor difficulties might use a special mouse, speech recognition software or on-screen keyboard emulator.
The website or app needs to take these things into consideration and provide access to the content, whether through changes to the website’s interface, or through the provision of the content by another means on request if it is not possible to deliver it through the website.
W3C and WCAG – what’s the difference?
W3C accessibility compliance is an international standard by which websites are measured and demonstrate how well they have been coded and, as a result of that, how accessible the content is likely to be from a technical perspective.
WCAG (2.1) compliance adds to this the additional requirements that focus less on how the site is built and more on the content of the pages, its legibility, visibility and usability.
Disproportionate burden
Some organisations are not exempt but still do not need to fully meet accessibility standards. This is the case if the impact of fully meeting the requirements is too much for an organisation to reasonably cope with. The 2018 regulations call this a ‘disproportionate burden’.
If you want to declare that making your website fully accessible is a disproportionate burden to your organisation, you’re legally required to carry out an assessment. In your assessment you should consider:
- the burden that making those things accessible places on your organisation
- the benefits of making those things accessible
When making your assessment, you need to think about:
- your organisation’s size and resources
- the nature of your organisation (e.g. do you have services aimed at people who are likely to have a disability?)
- how much making things accessible would cost and the impact that would have on your organisation
- how much users with a disability would benefit from you making things accessible
Your organisation might judge that the benefits of making some things accessible would not justify the impact on your organisation. In that case, you can claim it would not be reasonable for you to make those things accessible because it’s a disproportionate burden whether that be as a result of available resources or cost.
You cannot use the arguments such as a lack of time or knowledge in your assessment as a reason not to comply – or argue that making things accessible is a disproportionate burden because it is not a priority for you, the organisation.
Example 1
You might be able to argue it’s a disproportionate burden to meet all the requirements if doing so would use up most of your organisation’s budget for the year and leave you unable to do any of your other work or meet other requirements – and the changes would not vastly improve things for users with a disability.
Example 2
A simple, low cost code change that improves your website or app’s colour contrast would improve things for those with sight impairments. It is unlikely you could argue that changing this is a disproportionate burden.
You’re less likely to be able to claim disproportionate burden for a website (or areas of it) that cover services that:
- are specifically aimed at people with disabilities, such as ‘applying for a blue badge’
- enable people to participate in society, like ‘register to vote’ or ‘find a job’ or interact with core Council services that all people in the community use, such as refuse collection services, benefits & social care.
You will need to perform a full and thorough assessment of the website to establish what meets the regulations and what doesn’t and set out a plan as to what you can achieve now and what can be addressed in the future.
If you decide that fixing something would be a disproportionate burden, you’ll need to say so in the accessibility statement you publish on your website or mobile app.
Reasonable adjustments
Even if you’re exempt from the 2018 regulations, or judge that meeting them would be a disproportionate burden, under the Equality Act 2010 or the Disability Discrimination Act 1995 (in Northern Ireland) you’re still legally required to make reasonable adjustments for people with disabilities when they’re needed – for example, by providing the information they need in another, more accessible format – which you can declare on your accessibility statement and highlight it on the page affected.
Key dates for compliance
- All public sector websites must have a compliant accessibility statement in the standard format (as previously mentioned) by 23 September 2019
- All organisations must regularly review the website and your accessibility statement to make sure that it is up to date and that the things you claim are compliant, still are and the things you have said are not compliant have a clear solution to address or an alternative method of accessing the information.
- All public sector websites must comply with the 2019 regulations by September 2020.
Who does the work?
If you’ve outsourced some or all of your website to a supplier/local website developer or digital agency, you’ll need to work together to make sure your website meets the 2018 regulations by September 2020.
Start by asking:
- How much it would cost to make the changes needed to make your website or app accessible. You might find that fixing everything at once would put a disproportionate burden on your organisation. Work together with your supplier to agree what it’s reasonable to fix now, and when you’ll make the remaining changes.
- State what your plans are in your accessibility statement to make things as clear as possible for people using your website or app. Make sure that your organisation diarise a regular review and update the statement when changes occur.When you renew your contract or enter a new one, you should:
- Follow government guidance on procuring technology – awarding contracts that are not too long and using open standards, for example, makes it easier to take advantage of technical advances that can improve accessibility.
- Use web technologies rather than native mobile apps – because it’s easier to update web technologies and means the technology is not limited to a proprietary service, such as using Apple iOS.
- Make meeting accessibility standards in procurement part of the request for quotation (RFQ).
- Consider building regular accessibility reviews into the contract.
- Include accessibility as part of the contract evaluation.
The European Commission has published guidance in its Accessible ICT Procurement Toolkit – here. It is fair to say that, whilst authoritative, it is not for someone with little or no I.T knowledge and the documentation very technical.
Mobile apps
Accessibility requirements apply in the same way as websites for new, existing or outsourced apps, but the deadline for meeting them is 23 June 2021 given the reliance on native & proprietary language limitations.
How will the accessibility regulations be monitored & enforced?
From January 2020, the Government Digital Service (GDS) will monitor public sector bodies’ compliance on behalf of the Minister for the Cabinet Office. GDS will do this by examining a sample of public sector websites every year. GDS can request access to intranets, extranets or any public sector website.
As we have stated already, public sector bodies must also publish an accessibility statement and review it regularly.
If GDS decides that a public sector body has failed to publish an accessibility statement or that the accessibility statement is incorrect, it will publish the name of the organisation and a copy of the decision. Although at this stage, no information is available on what enforcement penalties will be levied but will be driven by the severity and level of complaint.
From June 2021, GDS will also check mobile applications published by public sector bodies.
WCAG 2.1 A, AA & AAA ratings
There are three levels of WCAG 2.1 compliance – A, AA & AAA rating. All ratings meet the minimum required standard under the regulation but which level you choose to meet will be largely driven by your assessment of whether you feel you need to deliver your online services to a particularly affected group, such as those identified user groups with disabilities or the reach of the website – such as a national or governmental website.
The larger and wider the potential user group, the more likely you are to need to meet an AA or AAA rating to fully comply.
The rating of a website and to what level it complies can be displayed by using one of the W3C (Worldwide Web Consortium’s rating badges, such as those below. It is important to stress that you must ensure that the website meets W3C & WCAG validation tests before adding the badge to your organisation’s website.
Who does the testing?
To a large degree, it is the organisation’s responsibility to perform the testing but you may wish to do this in consultation with your web team who can run a series of validation tests against the WCAG 2.1 benchmarks to make sure it passes.
There are a range of free online tools to check most aspects of W3C and WCAG 2.1 compliance. The W3C website has a few listed here: https://www.w3.org/WAI/ER/tools/
Mobile friendliness – suitability for all device sizes
One significant aspect that hardly appears in the Regulation is how mobile friendly an organisation’s website has to be. Mobile friendly (or responsive as often referred) refers to how well the website behaves when it is viewed on a small mobile phone or tablet and whether the content expands or contracts to fit. It is not surprising as the Regulations will have been written by policy makers rather than technical people – although no doubt in consultation with some.
We know, from years in development, a website that has good mobile friendly code will meet many of the requirements of W3C and WCAG 2.1 compliance – and so, by default, if you have a well-constructed site that has planned out with mobile viewing in mind, the amount of work required to bring the site up to full WCAG 2.1 compliant will be a lot less than one that is not mobile friendly.
Afterall, analytical data each year from Ofcom tells us that the number of people using the internet from their phone before a laptop or desktop is increasing and currently approaching 70% of all online searching.
PDFs and non-HTML online content
PDFs and other formats such as MSWord, Excel and suchlike are going to be the hardest things to tackle for most website administrators. A PDF is not natively compliant when it is made from the original source document – usually a MSWord format or similar. Images need alt tags, and colours, font sizes and many other formatting attributes are often non-compliant.
A public body must publish not only an accessibility statement that sets out its policy in regard to accessible use of its website but must also publish an ‘accessible documents policy’. This page is for the website owner to set out what content is compliant and what isn’t and what a user should do if they want to access something that is not compliant. One of the hardest formats will be PDfs as many public bodies make PDFs available. In most cases, the text part of a PDF will be readable by assistive readers but images, tables and text that has been turned into an image won’t be readable. It is the responsibility of the public body to ensure that all new documents that are available to download from the website are accessible and in the case of older, historical documents that cannot be converted, set out a mechanism for the user to contact the Body to obtain the information in another readable format.
To a large degree, this will mean almost every organisation changing its administrative processes to ensure that every PDF made and added to its website is produced in a different way and one that complies.
What do I need to do?
You may have little or no technical knowledge of where to start and it may also be likely that your web developer or digital team are not fully aware of the detail as to what is required of your website. The Government’s Digital Service (GDS) has provided the following document setting out a Q&A process for those undertaking the accessibility review. That complete checklist can be found here.
Here’s how to get started:
Begin with….
-
- Making a list of all your website domain names for which you are responsible – you have your main council website in addition to one that might be for one of your venues, halls or sports locations.
- Run a free W3C check on all domains – This will tell what’s wrong with the site. List download this list and sort into an order of things you can do and things you need your web team to address for you.You can do that here>: https://validator.w3.org/nu/ Be sure to check all the box options (source, outline, image report)
- Run a free WCAG 2.1 AA check on all websites for which you are responsible – Using the free WCAG 2.1 AA validator tool, download the CSV report and sort in the order of things you can do yourself and the things you need your web team to manage.You can do that test check here>: https://www.w3cag.org/WCAG2-AA-validator
- Identify from both reports what you can change yourself and what you need help with – this will form some background information when it comes to creating your accessibility statement.
- Provide the list to your web team/web contractor and ask for a quotation that includes:
– how long will it take
– how much will it cost and to include a retest once the work is done
– what points, if any, can you attempt yourselfYou may identify that the cost of undertaking all the work is prohibitive in one go so agree what can be done now and the budget (and timescale) in the future when funds and/or resources allow. - Complete your Accessibility Statement & publish it on your website – download the Government’s Accessibility Statement template and complete in accordance with your website’s current status. For the points that you know are not compliant but will be addressed, make sure this is identified and provide an alternative solution for the user to access the information.You can download the sample template accessibility statement here>: https://www.gov.uk/government/publications/sample-accessibility-statement. You’ll also need to review any non-compliant formats of content on the site and create an Accessible Documents Policy of what you know to be accessible, what you know is not and how you provide access to that content. The GDS provide a template here>: https://www.gov.uk/government/publications/sample-accessible-document-policy/sample-accessible-documents-policy
- Set a timeline & budget for compliance – set priorities against tasks, targets, diarise regular reviews of the website and its accessibility status. You may need to set out a schedule that spans two financial years so factor in the budget in your precept.
- Define future best practice methods – Set out a guidance document for all those who manage content on your website some best practice guidelines so that the website remains compliant.
- Making sure you check the website with the validation tools regularly to ensure continued compliance – and ensuring the accessibility statement is up to date with any changes you make.
The WCAG 2.1 compliance accessibility checklist
To meet WCAG 2.1 to level AA you must be able to answer YES or Not Applicable to all of the following questions.
Answering NO means that you are not meeting WCAG and your content will have barriers that will prevent some users, especially disabled users and older people from accessing it. These barriers may form part of changes you are going to make immediately to the website or may need to be scheduled so your accessibility statement needs to identify those areas and, if they currently fall short, how the user can access the information in an alternative way.
The accessibility checklist is broken down into FOUR categories:
Perceivable
Do all images have an appropriate text equivalent? Is essential visual information also available as text?
Do all audio files have a transcript? Is essential audio information available as text?
Do all videos have captions that are synchronised with the audio?
Does video that includes important visual information have an audio description?
Is all content structure that is communicated visually available to assistive technologies?
If styling is removed is the content in a logical order?
Have you avoided using visual characteristics to communicate information?
Have you avoided using colour as the only way to convey some information?
Can users stop audio that auto plays?
Does all text have sufficient contrast against the background colour?
Is the content fully usable when text is enlarged up to 200%?
Have you avoided using images of text?
Can users flip the content horizontally and vertically?
Have you added HTML autocomplete tokens to any forms collecting information about the user?
Does the page content resize to a single column with no horizontal and vertical scrolling?
Do all important graphical objects, interface components, and states have a colour contrast of 3:1?
Can line height, spacing between paragraphs and letter and word spacing be changed without breaking anything?
Where extra content is shown or hidden on focus, can it be dismissed, interacted with (and not disappear when the user moves to it) and will stay visible until dismissed by the user?
Operable
Can all menus, links, buttons, and other controls be operated by keyboard?
Do pages that have time limits include mechanisms for adjusting those limits?
Can any content that moves or auto updates be stopped?
Have you avoided using content that flashes or flickers?
Can blocks of links and other interactive elements be bypassed by keyboard users?
Does each page have a unique title that indicates its purpose and context?
When using a keyboard to move through a page does the order make sense?
Is the purpose of every link clear from its link text?
Does the website have two or more ways of finding content, such as a navigation menu, search feature, or site map?
Are headings and labels clear and descriptive?
When using a keyboard to move through a page can you tell where you are?
Do you have shortcuts triggered by only one letter or character? If so, can they be turned off or remapped by the user?
Does some of your site functionality need several fingers or complex gestures to operate it? If so, can the same functionality be used with just single taps or clicks?
Does some of your site functionality work using a single point (e.g fingertip)? If so, have you ensured it doesn’t get triggered the moment it is touched?
On forms and other components is the accessible name or label the same as any on-screen text?
Does your site respond to motion or movement? If so, can responding to motion or movement be disabled, and your site still be fully usable?
Understandable
Has the language of the web page or document (or individual parts of a multilingual document) been defined?
Have you avoided links, controls, or form fields that automatically trigger a change in context?
Does the website include consistent navigation?
Are features with the same functionality labelled consistently?
Do forms provide helpful, understandable error and verification messages?
Robust
Is the web page coded using valid HTML?
Do all interactive components have an accessible name and role, and when required state? Has the correct ARIA markup been used and does it validate?
Are status messages and updates given appropriate roles that can be understood by AT, without receiving focus?
Ongoing compliance
Moving forward, best practice guidance includes making sure those who manage a website follow:
- ensuring any new PDFs or other documents they create are accessible
- writing good link text
- structuring content well
- publishing accessible images and videos
- making sure new features work on assistive technologies
Further support
If you are a city, town or parish council clerk or responsible for the organisation’s website and need further help or guidance, why not take a look at our WCAG 2.1 compliant packages here or call us on 01525 373020.