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.
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:
The UK Government expects all public services to meet the WCAG 2.1 AA accessibility standard, both for citizens and staff users.
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.
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.
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.
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.
Featured image – Daniel Ali on Unsplash
Illustration – Sherm for Disabled And Here
When something’s not right on your street, and you’ve gone out of your way to report it to the local council, the last thing you want is to get bogged down in a complex log-in procedure.
That’s why FixMyStreet has always put the log-in step after the reporting step, and has always allowed you to report a problem without needing an account or password at all.
But we know we can always do better, and in the 11 years that FixMyStreet has been around, new design patterns have emerged across the web, shifting user expectations around how we prove our identities and manage our data on websites and online services.
Over the years, we’d made small changes, informed by user feedback and A/B testing. But earlier this year, we decided to take a more holistic look at the entire log-in/sign-up process on FixMyStreet, and see whether some more fundamental changes could not only reduce the friction our users were experiencing, but help FixMyStreet actively exceed the average 2018 web user’s expectations and experiences around logging in and signing up to websites.
Previously, FixMyStreet tried to do clever things with multi-purpose forms that could either log you in or create an account or change your password. This was a smart way to reduce the number of pages a user had to load. But now, with the vast majority of our UK users accessing FixMyStreet over high speed internet connections, our unusual combined log-in/sign-up forms simply served to break established web conventions and make parts of FixMyStreet feel strange and unfamiliar.
In 2014 we added dedicated links to a “My account” page, and the “Change your password” form, but it still didn’t prevent a steady trickle of support emails from users understandably confused over whether they needed an account, whether they were already logged in, and how they could sign up.
So this year, we took some of the advice we usually give to our partners and clients: do one thing per screen, and do it well. In early November, we launched dramatically simplified login and signup pages across the entire FixMyStreet network – including all of the sites we run for councils and public authorities who use FixMyStreet Pro.
Along the way, we took careful steps—as we always do—to ensure that assistive devices are treated as first class citizens. That means everything from maintaining a sensible tab order for keyboard users, and following best practices for accessible, semantic markup for visually impaired users, to also making sure our login forms work with all the top password managers.
The simplified log-in page was a great step forward, but we knew the majority of FixMyStreet users never used it. Instead, they would sign up or log in during the process of reporting their problem.
So, we needed to take some of the simplicity of our new log-in pages, and apply it to the reporting form itself.
For a few years now, the FixMyStreet reporting form has been split into two sections – “Public details” about the problem (which are published online for all to see) followed by “Private details” about you, the reporter (which aren’t published, but are sent to the authority along with your report, so they can respond to you). This year, we decided to make the split much clearer, by dividing the form across two screens.
Now the private details section has space to shine. Reorganised, with the email and password inputs next to each other (another convention that’s become solidified over the last five or ten years), and the “privacy level” of the inputs increasing as you proceed further down the page, the form makes much more sense.
But to make sure you don’t feel like your report has been thrown away when it disappears off-screen, we use subtle animation, and a small “summary” of the report title and description near the top of the log-in form, to reassure you of your progress through the reporting process. The summary also acts as a logical place to return to your report’s public details, in case you want to add or amend them before you send.
As I’ve mentioned, because FixMyStreet is an open source project, these improvements will soon be available for other FixMyStreet sites all over the UK and indeed the world. We’ve already updated FixMyStreet.com and our council partners’ sites to benefit from them, and we’ll soon be officially releasing the changes as part of FixMyStreet version 2.5, before the end of the year.
We’re not finished yet though! We’re always working on improving FixMyStreet, and we’ll be keeping a keen eye on user feedback after these changes, so we can inform future improvements to FixMyStreet.com and the FixMyStreet Platform.