We’ve been working hard to improve accessibility across Co-op products and services and as our Head of Digital Products, Adam, has said, “having accessible services shouldn’t be a question for Co-op, it’s what we should and must do.”
Last month we published our accessibility policy.
Publishing the policy is a public statement of intent – it shows our commitment to further improving our level of inclusivity.
Why we need an accessibility policy
We have people with good accessibility knowledge within Co-op Digital and ideally, each product or service team will have at least one of those people. However, teams frequently change shape which means that sometimes accessibility isn’t as prominent in conversations as it should be.
We needed to change that.
The policy makes accessibility standards more tangible because colleagues can see what their responsibilities include.
Saying it out loud gives it more weight
Nobody intentionally ignores accessibility problems but they do sometimes lack awareness. Both the policy and this post aim to raise awareness of our commitment and invite colleagues, customers and members to hold everyone working in Co-op product and service development accountable to the standards we’ve set ourselves.
How we’ll implement the policy
To do this we need accountability at all stages of product and service development. We’ve identified 8 stages and have worked alongside experts from each discipline to create the policy. Now those 8 people are responsible for implementing it and supporting their communities and teams to uphold the standards.
8 stages of development and the representatives:
- Procurement – Jack Warburton
- Research – Eva Petrova
- Design – Nathan Langley
- Front-end – Matt Tyas
- Content – Hannah Horton
- Quality assurance – Gemma Cameron
- Automated testing of live products and services – Andy Longshaw
- Annual accessibility audits – Dave Cunningham
Adam Warburton has overall accountability.
The process behind the policy
We know many organisations have set themselves standards. For teams that haven’t but would like to, here are the things we considered that might be helpful.
- We looked at how teams work currently by mapping out projects so we could fit the policy around their processes. We felt teams would be more likely to support a policy that echoed the way they already work because adopting it would be easier.
- Improving or monitoring accessibility across a product or service can be a massive task. To make things more manageable, we looked at how we could break things down. We identified the 8 ‘stages’ of accessibility we’ve mentioned earlier on in the post.
- We worked alongside subject matter experts (SMEs) from each of the stages we identified to create the part of the policy they would eventually lead on and be accountable for.
- Drafts of the policy went backwards and forwards between me, the SMEs and the senior management team. It was essential to share, take in feedback and collaborate wherever we could because adoption of the policy depends on these people supporting and agreeing with it.
Where do we go from here?
It’s nice to have a policy on a page on the internet but it must never become a virtuous-but-otherwise-empty promise. We know that if we don’t read it, keep it in mind and revisit it, it is just a vanity project.
We’d like you to read it and keep it in mind too. And if you spot something you don’t feel is accessible, email me firstname.lastname@example.org
We can’t promise we’ll be able to improve it straight away but we will add it to the backlog.
Thanks in advance for helping us make things better.