Our mission here at SocietyWorks is to help local authorities and other public sector organisations better serve citizens through effective and intuitive digital solutions. That’s a big remit, and a vast user base with a wide range of accessibility requirements. So how do we accommodate everyone? Bekki Leaver, our Head of Product, wrote this blog post to explain.
–
Being suppliers of public services we have a responsibility to ensure our tools and solutions are accessible to the broadest audiences possible. This is both a legal and moral obligation, and something we take seriously.
As Head of Product, it’s my job to ensure our tools are built to meet, if not exceed the Web Content Accessibility Guidelines (WCAG) AA standards. Here’s what this means in practice, and some advice for local authorities and any other public sector bodies who provide public-facing digital services.
What is WCAG?
WCAG is the international standard for web accessibility created by the World Wide Web Consortium (W3C). Within WCAG there are four principles for web accessibility. Each of these has conditions that need to be met to achieve a particular standard. These very sensible principles are:
- Perceivable; making sure content is available to all. Any images have alternative text and descriptions, captioning on audio and video. Ensuring content is accessible to assistive technologies.
- Operable; let people use the thing. Avoiding distracting or flashing animations, let people interact with the website using keys or other technology.
- Understandable; things should make sense and be readable. Being able to change font sizes or zoom in on content. Allow people to correct their mistakes.
- Robust; works with the tools a user wants. Browser and device combinations.
The UK Government expects all public services to meet the WCAG 2.1 AA accessibility standard, both for citizens and staff users.
Our process
SocietyWorks is heavily influenced by the GOV.UK Service Manual when it comes to designing or improving our tools and products. If you’re familiar with this, you’ll know that this means everything starts with needs: both user needs and the service needs.
We also consider the context of use: where, when and how will the service be accessed? In addition to considering any permanent physical impairments that may impact the way a service needs to be used, we think about situational and temporary impairments too.
For example, making button targets larger for people using a service one handed due to holding a baby, having a broken arm or having bad arthritis, or improving the contrast for use of a service in poor lighting environments or by users suffering with an eye injury or partial blindness.
Our developers use semantic HTML – that’s using HTML elements for their intended purposes to build the front end of our tools. This lets browsers know what the element is and how it should behave, which makes it easier for keyboard navigation and for other assistive technologies to correctly render a website for their users.
When we’ve got something designed and built, we test it. We use a combination of automated and manual testing to make sure the technology meets the WCAG standards, which includes, for example, checking we can tab through elements and that screen readers behave as expected.
Our biggest challenge
Knowing that no two councils or public authorities are the same, we build our digital solutions to be flexible enough to adapt to each of our clients’ individual needs. This is a great strength, but it can occasionally pose a challenge when those needs have an impact on the accessibility of the solution.
For example, we are sometimes asked to apply brand colours which have a poor contrast ratio or adjust forms to match a third party integration’s workflow in a way that makes them more difficult to use for users with certain needs.
Advice for councils and other public sector bodies
When these instances occur, we do our best to help mitigate any negative effects on the accessibility of the services we provide. Here are some of the top tips I offer to clients when it comes to accessibility.
Firstly, I would always highly recommend commissioning an accessibility audit with a reputable auditor, such as RNIB, but you can find other providers through the Digital Marketplace. This will give you complete peace of mind that everything is working as it should for everyone who needs to use the service.
Secondly, consider your brand colours. Colour is a regular issue with accessibility, usually caused by text and background colours not having a high enough contrast.
Lastly, ensure the language you’re using is appropriate. Whether you’re writing form field labels or creating explanatory text, use language your users will understand. For example, avoid using system-related terminology that residents may not understand, but do consider using the local names for things. You can check the readability of your content using online tools like readable.com.
Final thoughts
Creating and maintaining an accessible and inclusive service is an ongoing task. Criteria and expectations change. Keeping these goals in mind from the beginning certainly helps, as does remembering that designing services to be inclusive makes them better for everyone.
If you’re interested in learning more, check out these resources:
Or, if you have any questions about making digital services accessible to everyone, get in touch with us here.
–
Images
Featured image – Daniel Ali on Unsplash
Illustration – Sherm for Disabled And Here