Accessibility is no longer an option for public sector organisations. The Public Bodies (Website and Mobile Applications) Accessibility Regulations officially came into force in September 2018. The legislation set out the requirements for public sector organisations to be accessible across their digital services.
The legislation is based on the Web Content Accessibility Guidelines (WCAG). These are guidelines produced by the World Wide Web Consortium (W3C). There are three levels of compliance with WCAG, those are Level A (lowest), Level AA (mid range) and Level AAA (highest).
To be compliant with the legislation, a public sector digital service must meet a minimum of WCAG compliance level AA.
Important dates for new accessibility regulations
The legislation outlines the following dates for compliance:
- Websites and apps published after 23rd September 2018 must have been accessible by 23 September 2019.
- All other public sector websites published before 23rd September 2018 need to be accessible by 23 September 2020.
- Public sector mobile applications must be accessible by 23 June 2021
If you have a public sector website, no matter the date of publication, it needs to be accessible in less than two months.
Common accessibility failures in the public sector
We’ve been working with public sector organisations for many years, and surprisingly, the most common errors seen on digital services in the public sector are the least complex to resolve.
Here’s a list of the common accessibility errors we find on public sector websites, and how to fix them.
Poor heading structure
One of the most common issues on public sector websites is heading structure that is incorrect or heading levels that have been skipped.
Heading structure is used to organise information and splits web page content into manageable, digestible chunks. Good headings can make a web page easier to navigate for certain users too, such as:
- Screen reader users
- People with cognitive processing difficulties
- People with learning difficulties.
A common issue we see is heading levels being used incorrectly as a styling preference. Often through lack of training, content editors will use headings based on their looks, instead of thinking of them as important content milestones.
How to fix incorrect heading structure
Headings should always be used sequentially. For example, Heading 1 should always be the title of a page, Heading 2 should be subheadings underneath the title, Heading 3s should be subheadings within Heading 2s, and so on.
It should look something like:
If the heading structure is an issue within a content page, it may just be a case of going in and editing the page, ensuring the structure is correct. However, heading structure issues can sometimes stem from improper page layouts within the code of the website. This may need to be fixed by a developer.
If you are using headings incorrectly because they “look better”, ask a developer to change the style of the heading levels to better suit the look you want.
Insufficient colour contrast
The contrast between the background and text on a website must be 4.5 to 1 for small or medium-sized text. For larger text, it should be 3 to 1. These are the ratios outlined by WCAG.
Below is an example of good and bad colour contrast.
There are many groups of people who are affected by poor colour contrast on websites. Including people with:
- Low vision
- Colour vision deficiency (colour blindness)
- Low contrast sensitivity (common in elderly users)
More often than not, insufficient colour contrast is simply an oversight. Whilst the developer or designer may think something is easy to read on a certain background, that might not always be the case.
How to fix insufficient colour contrast
Quite simply, you can check the colours against each other using one of the many free tools that are universally accessible on the Internet. Tools such as WebAIM Contrast Checker are great for seeing how close your colours come to meeting the requirements.
From there, carrying out small amends to the website’s colour may help to make your colours compliant. Often, colours only need a small (almost unnoticeable) change to meet the guidelines. Other times though, you may need to reflect on the use of colour throughout the entire website.
Inadequate keyboard access
By default, many browsers display a visual outline around elements of a website that a keyboard user has focused on. Keyboard-only users navigate a website using the tab key, the action is often described as ‘tabbing’. The best example of this is if you go to GOV.UK and try going through the website with the tab key. You’ll see a very obvious yellow highlight, known as a focus border, indicating where the keyboard user is on the page.
Surprisingly though, there are some digital services that have had this option manually removed by adding “outline:0 or outline:none” into the code. This removes any default focus outline that the browser usually displays.
Removing access to keyboard users can be detrimental. Here are some users it may impact:
- People with motor impairments, who cannot physically use a mouse
- People with conditions such as Parkinson’s Disease, as hand tremors can make it difficult to use a mouse so may prefer to use a keyboard.
- Visually impaired users, who cannot see the mouse or clickable elements on a page.
- Those who prefer to use a keyboard, or cannot access the mouse for some reason.
How to fix inadequate keyboard access
As mentioned above, in the CSS code of a website, to have no outline appear when a website is tabbed through, it will usually be because of the condition outline: 0 or outline: none.
A developer can change this with ease and should do so. For increased accessibility, it’s recommended to further alter the outline effect (as has been done with GOV.UK) using CSS to make it even more clear. For example, adding a blue, or a yellow highlight may work well.
You can check if your own digital services have accessible keyboard focus by simply trying to navigate using the keyboard. If you get lost, or you are unsure of where you have tabbed to, this is an indication that you need to work on the focus border element.
Adding alt(ernative) text to images is one of the first and most important principles of web accessibility. However, it can be one of the hardest to get right.
Sometimes referred to as “alt descriptions”, or “alt tags”, alt-text is written copy embedded into the image which helps describe what the image is of, and the context of it. This can be helpful for a number of people, including:
- Blind screen reader users, as alt-text is read aloud in place of the image
- Visually impaired readers, who may use a text reader which will read the alt-text in place of the image
- Users with a slow internet connection who may find images cannot load, in which case the alt-text may display in place of the image.
There are a huge number of images on a vast range of digital services that have incorrect or poor alt-text. This means they’ll be difficult to understand for the users listed above. It’s especially important to get alt-text right if your image has significant contextual meaning within the page.
How to fix insufficient alt-text
In most content management systems (like WordPress, HubSpot, Umbraco and Joomla for example) there is an option when editing the image to add in an alt-text. The difficult part, however, is creating alt-text that is meaningful and makes sense in the context of the web page.
We recommend the following practices:
- Don’t start your alt-text with “picture of…” or “image of…” as screen readers will identify it as an image already. You just have to add the description.
- Keep alt-text short. It’s best practice to be specific and concise within your alt-text. No screen reader user wants to sit there for hours listening to an image description.
- Be accurate, but succinct. Describe what the image is accurately, and in the context of the webpage.
There are some places where an alt-text should be left blank on an image. This is when an image adds no contextual value, or additional meaning to a page. Leaving an image’s alt-text blank tells screen readers that it is a decorative image and will be skipped over.
You can also do this if the information in the image is communicated effectively elsewhere within the content.
Empty form labels
Forms are one of the most common website functions that users interact with. From a simple newsletter sign up, to a change of address form, forms have many different uses. They are also one of the most common accessibility errors found on websites.
In the public sector, forms are often essential, providing users with a method of contact to their local authority or a government agency. The most common issue with forms, though, is empty labels.
Form labels tell screen readers and their users what information the form requires. When not implemented effectively, these form fields may not have labels that screen readers can read. Making it challenging for users to understand what information to enter, and into which form field.
How to fix empty form labels
This is a job for a developer in most cases, but one that can be resolved quickly and easily if a person knows what they are doing. If a text label for a form field is visible, then ensure it has the <label> element. This element will help associate a text label with an input field of a form.
If the form label is not visible on the site, it can be labelled using ARIA code. If you don’t know anything about ARIA, there are some great tools available by Google Developers on the Introduction to ARIA. ARIA labels help identify features to screen readers.
Meaningless link text
WCAG states that link text should be unique within a page. It should be meaningful when read aloud and should help users understand something about its destination when clicking the link.
A common accessibility error we find is organisations including link text such as “Click here” or “Read more”. These fail to meet the criteria above and provide no information regarding the destination of the link.
- Screen reader users, who may generate a list of links and navigate through them alphabetically.
- People using speech recognition software who can select a link using a voice command such as “Click [Link name].
In both of the contexts above, having loads of “Click here” or “Read more” links on a page will not be useful. It’s impossible for a screen reader user to know where the link will take them. And, for a voice navigation user, they cannot specify a link to click on if there are numerous links that are the same.
How to fix meaningless link text
This can be an easy problem to fix when the link is a simple hyperlink within a piece of content. It can be edited in the content management system to be meaningful. Ensuring the destination is written within the hyperlink. If it’s a button on a website, it will need changing in the code.
In the public sector, we often see ambiguous links like “Pay” and “Report” being overused. Ask yourself, “What is the user paying for?” or “What is the user reporting?”
Instead of “Pay” consider using “Pay your council tax”. Instead of “Report” consider using “Report a missed bin collection” for example. This way, users will know exactly what page they will be sent to.
If the ‘Pay or ‘Report’ button makes sense visually, you can use ARIA framework to add additional content for screen readers. ARIA is a piece of code that gives screen reader users more information and context about the page.
For example, the Pay button could remain as it is, but have an aria-label or aria-labelled by attribute added to it with the text “Pay your council tax” for example. To non-screen reader users, this button would still say ‘Pay’ but to screen readers, it would be read as “Pay your council tax”.
How to write a legally compliant accessibility statement
This list of common failures is by no means exhaustive, there are plenty more errors that are found on public sector digital services. We’ve highlighted six of the most common issues found on public sector websites but there are many more that we can help you to find and fix.
Fixing the errors on your website is not the only thing you need to do to be legally compliant. Public sector organisations must, first and foremost, have a version-controlled accessibility statement on their website.
A legally compliant accessibility statement must:
- show the date of the most recent audit
- lists all of the faults found (that have not been fixed)
- provide a roadmap for change, giving key milestones for fixing issues
- outline how users can get accessible versions of the content
- provide a means to complain if your users aren’t happy with your organisation’s level of accessibility.
The most important thing about auditing for these errors is not necessarily to have them fixed by September. A key starting point is identifying the issues. From here you can create a roadmap for your organisation with a commitment to fix the faults, making your service more inclusive.
If you want to know more about compliance with the regulations or find out how accessible your own website is, HeX Productions offers web accessibility auditing services, as well as support with accessibility statements. You can also view some of the public sector clients HeX have worked with in the past.
Contribute an article
The Big Hack is an open community, and if you have an idea, or an article, about how to make the digital world more inclusive, we want to hear from you.Message us about a contribution