Accessibility for everyone — making public service websites inclusive has become a legal requirement
It is now the law to be accessible
On 23 September 2019 the web accessibility regulations (“Public Sector Bodies (Websites and Mobile Applications) (№2) Accessibility Regulations 2018.”) come into effect (https://accessibility.campaign.gov.uk). These regulations were created to guide and enforce organisations within the public sector to make sure their services are available to the widest possible public audience, including those living with disabilities, especially those using assistive technology to access online services. They came into force on 23 September 2018, and they say that all public sector websites or mobile applications (apps) must:
- meet WCAG 2.1 AA web accessibility standards
- publish an accessibility statement on their website
Who will directly benefit from a more accessible digital public space?
According to the most recent data (2017 UK Government Family Resources Survey) there are 13.9 million (one in five people) UK residents living with a form of limiting long-term illness, or disability:
Many people living with a disability use digital services with some form of assistive technology such as, screen readers, screen magnifiers, speech recognition software, or simply a keyboard.
The new legislation was put in place to ensure that accessibility best practices are followed when a new public service website is published. It also helps with guidance on how to improve accessibility of existing online services.
The new guidance acts as a framework for public services to help them meet their legal obligations:
- Make a decision on how you are going to test your website or app for accessibility issues
- Make a plan how you are going to fix the issues you detected (and are not identified as disproportionate burden to fix right now)
- Publish an accessibility statement
- Any new feature that gets released in the future must be accessible
The effective date of compliance depends on what date the public service has gone (or will go) live:
- Public sector websites published on or after 23 September 2018 must be compliant by 23 September 2019
- Any websites due to be published after this date must be compliant before going live
- Public sector websites published before 23 September 2018 must be compliant by 23 September 2020
- Apps need to meet the regulations by 23 June 2021
How better accessibility improves the user experience
Content is King™️: Reading cryptic or lengthy sentences is a huge cognitive load to many users who will feel frustrated very quickly. Some guidelines to follow include:
- Use short sentences, use simple language, avoid special words and abbreviations
- Do not repeat yourself
- Use concise hierarchy in content blocks (titles, headings, paragraphs, lists), use descriptive alternate (ALT) tags on images
- Use descriptive link labels, for example: click for more information about the new accessibility law rather than click here
Reflow and Zoom: Some users living with visual impairments will increase the text size of a website directly in their browser, some will use assistive software such as ZoomText. There are tools and techniques web designers and developers can use, such as relative units, responsive grid layouts and breakpoint-controlled font-sizing. These techniques will serve visually impaired users as well as help any website work device (mobile, tablet and desktop) independently.
Images: Use descriptive ALT text on images, that represent or support the content. There are simple techniques to expose images that are important to the page narrative and hide non-informative images from people using screen reading technology. Another good thing about ALT text is that in case the images don’t load on a page the text will still be there to describe to every user what they’re missing.
TAB TAB TAB: Make sure the interactive elements on the page offer full keyboard access. It is not just about designing for mouse, stylus or touch interactions. Having a linear flow for keyboard tabulation in web forms, or “Skip to main content” link being the very first element receiving tab focus on the website is crucial for those, who rely on keyboard-only interaction.
Colour contrast: Strong colour contrast is really important, but not just for visually impaired users. If you have ever been out and about on a sunny day trying to read something on your phone, you will appreciate adequate colour contrast for better readability.
Portable Document Format file (PDF): If possible, use HTML alternatives to replace them. Although there are ways to create accessible PDFs, they are notoriously inaccessible for screen readers. A couple of issues with PDF documents (which are solved by HTML documents):
- PDFs don’t resize or reflow their content based on screen size and orientation.
- Depending on the user’s setup, opening a PDF from a HTML page can open in 3rd party application, which takes the user out of their flow and complicate their journey.
- If the text in the PDF file was broken into outlines (typical for print-ready documents published online), the user will not be able to search the document for content.
Back to the basics: If CSS (Cascading Style Sheets) and Javascript is switched off on the website altogether, the user should still be able to perceive the content (whether they are seeing it on a screen or using a screen reader). If the website looks basic (white background, black Times New Roman text with blue links), and the content still makes sense and is easy to navigate and interact with, you’re winning!
Use form labels: Perceivable labels are a must for form inputs. If they are not visible, they have to be visually hidden, but still present for assistive tech to pick up. Without accessible labels assistive tech users are not able to complete the tasks they need to. Please use form labels.
Transcripts and close captions: Providing transcripts and close captions will ensure that users with hearing or visual impairment can get the information they need from multimedia files such as pre-recorded audio and video. A great kickback of HTML transcripts is improved SEO — users can find the audio or video content online using their search engine.
Provide immediate user feedback: Providing clear feedback to users will help them to gain confidence in their interaction and will reduce frustration. Examples of good user feedback are showing well distinguishable error messages that identify precisely where and what is wrong with the user input (“Please enter a valid email address” — next to the email input field > “There was an error” — On the top of the page, far away from the field); Make audible announcements about a task completed (“Files uploaded successfully!”) to screen readers.
Accessibility is not an afterthought: Make sure accessibility is considered from the outset and part of your ‘Definition of Done’.
How everyone benefits from web accessibility
Web accessibility is all about how clearly and concisely your website communicates to its users, and how easy users find interaction with the website.
Accessibility isn’t just for people living with disabilities.
We all benefit from web accessibility in various different ways. And that’s just another great reason why it should come first, not as an after though. Here are some additional “benefits” accessibility brings to the table for everyone:
- Accessible front-end code starts with simple, well structured, semantic HTML, therefore it’s machine readable and will perform well in web searches, which is obviously good for SEO.
- Strong colour contrast ratio will help not just those living with low vision, but everyone else who are trying to read the text on their small phone screen on a sunny day.
- The techniques that help developers in building responsive websites also help visually impaired users, so that they can consume the content easier when zoomed in, without breaking the website’s layout.
Testing, testing, testing
There are multiple ways of testing for accessibility, these are
- Automated testing
- Manual testing
- Testing with real users
And they all should be done throughout the project the best possible result.
Automated and manual testing can be done in-house — often by the developers and automated testers themselves, but it is vitally important to test with real users, who use assistive technology, because no matter how much experience a development team has, the final product will be used by users who have real accessibility needs, and their feedback is incredibly valuable for the product’s success.
Before testing with real users, the team should make sure that the most basic accessibility issues are ironed out. Here are a couple of tools, which used as part of the development and automated testing phase can help identifying the most obvious issues:
Automated testing
- Command line tools, such as Pa11y-CI
- Browser extensions such as WAVE and Axe
- Command line reporting tools can also be made part of a continuous integration pipeline
Manual testing
- Using various devices (mobile, tablet, laptop, desktop),
- Using keyboard only, and assistive tech such as JAWS or Nuance Dragon
User testing
- Conduct moderated and unmoderated testing sessions with users living with different types and levels of disabilities
- If possible, let the user use their own device and assistive technology
One of the most valuable lessons for us at Valtech is to listen to our users and learn how they use their device and software. If they hit a barrier on the service they test, we listen carefully what they recommend to us as an alternative solution.
Publishing an accessibility statement
Public service websites now have to publish an accessibility statement, and similarly to a Cookie policy, a link to the new statement should be present on every page.
This statement is meant to state the level of compliance of the website against the WCAG2.1 AA specification, and highlight any parts of the website, that could potentially act as barriers for those using assistive technology.
This is a great initiative, because besides actively working on compliance, public services now have the facilities to show to their users that they care about accessibility, and they have the right tools and a plan in place to continually make their services better and more inclusive.
Here is an example statement on the Blue Badge service website: https://apply-blue-badge.service.gov.uk/accessibility-statement
Resources and tools
GDS has been beating the drums for the last couple of years about the coming regulations, and thanks to their incredibly hard work, public sector web teams have large amounts of tools, resources and support channels available to them to make sure that they can make their service meet the regulations in due course.
On top of the surveys, research papers and blog posts, the GDS team has published in the last couple of years, we also found the following tools and resources invaluable:
- Accessibility DO’s and DON’Ts posters:
https://accessibility.blog.gov.uk/2016/09/02/dos-and-donts-on-designing-for-accessibility - GOVUK prototype tool:
https://github.com/alphagov/govuk-prototype-kit - GOVUK Front-end toolkit:
https://github.com/alphagov/govuk-frontend - GOVUK Design system:
https://design-system.service.gov.uk - GovUK Slack Channel
At Valtech we have been truly thankful to GDS for creating a culture of research, learning, sharing and improving which we have been proud to be a part of. This culture has spawned these great tools and practices.
The icons used for the graphics in this article were created by Vectors Point (auditory), mikicon (a11y logo), David (brain), Gregor Cesnar (hand), UNiCORN (wheelchair user), Chanut is Industries (visual) from the Noun Project.
