We recently welcomed 2 new accessibility testers to the Home Office – Stella Majcen and Yacoob Woozeer, who’ve joined James Buller to form the Access Needs team.
Together, they bring years of accessibility experience – making things usable for people with access needs due to disabilities or medical conditions. They’re passionate about improving the equality of access to government services.
The Access Needs team offers training, advice and feedback to development teams so they can make their product or service as inclusive as possible. We complement the work of user researchers, who should always speak and test with people with access needs.
Here, we explain how we work with colleagues designing internal and external services.
Our training programme for Digital, Data and Technology staff begins with the day-long access needs awareness introduction course and follows up with profession-specific modules. It’s a great way to introduce team members to the features, support and technology that people with access needs require when using digital services.
Accessibility and the development lifecycle
We want to work collaboratively with teams so they can understand what accessibility really means. So we developed a journey map that explains how we can work with teams at different stages of the development process.
It’s never too soon to get us involved. We’ll start with an informal consultation to understand your service and your team’s needs. Even if you haven’t started building anything, we can share good examples of accessibility, case studies and advice on procurement. It all works towards meeting GOV.UK’s Digital Service Standard and design principles.
One of our main ambitions is to share the insight gained by Home Office teams, learning across government and beyond. We want to be a guiding hand, rather than cracking a whip.
Talking to us as early as the first week of your discovery can save a lot of time and money by putting you on the path to building the right thing correctly. We can suggest suitable types of people with access needs to interview and how to recruit them, perhaps with the help of Research Services. Plus, we have tips such as our Do’s and Don’ts posters.
This is where we can sit with you to review your early designs and ideas for how your service might work, and spot potential accessibility problems.
We can advise on how to test prototypes with users with access needs, de-mystify the Web Content Accessibility Guidelines (WCAG) and how to exceed the mandatory AA standard.
We’ll also show you how all members of your team can look out for accessibility issues, backed up by continuous integration. You’ll need to follow through on all this to pass an alpha service assessment.
By now, we’d expect to have been talking to your team for some time and your product or service should be pretty good accessibility wise. Now’s the time to ask us to do an expert review – do this before you test it with users of assistive technologies that provide voice input/output and display enhancements.
We’ll test the service against the basic WCAG A checkpoints. We’ll also try to complete the user journey while using a screenreader that someone with a severe visual impairment may need to use.
Ideally, we’ll do this with members of your team, so they learn the test criteria and methods. You can collect the results yourselves in the format you need or we can write a report if necessary.
To pass a beta service assessment, you’ll need confirmation from the Access Needs team that your service has passed an accessibility audit (see below).
Public beta and live
We’re available for consultations on all the areas described above. Before your service has its assessment, we’ll audit any changes you’ve made since our last consultation, and give our views on the accessibility to the service assessment panel. We can also review changes during the live phase.
During an audit, we’ll check compliance with all the WCAG checkpoints. We’ll also use the service with an agreed set of operating systems, web browsers and assistive technologies that people with access needs commonly use. We’ll look for things that might stop, delay or confuse users.
As well as writing a report of findings, we’ll also go through your site with the development team, explaining why we’re picking up on certain things, what the guidelines are aiming for and how you can meet them.
They’ll then be an iterative process, during which we’ll retest resolved issues and review any other changes. By the time of your service assessment, we’ll be able to say how technically accessible your service is and whether it meets the Service Standard.
Talk to us
We’re always keen to get feedback and iterate how we work – so let us know how we’re doing and where we can improve.