Accessibility – the perfect procurement process

Dig inclusion were invited to a fantastic event recently – a huge UK purchaser wanted to engage with SME’s and invited them in to showcase their services but also talk about the hurdles SME’s have when completing tenders for projects,

It was an open, and honest conversation which helped us identify a common problem that other purchasers may well be facing. We thought a lot about what an ideal process might be for delivering inclusive products and we want to share some of that with you.

So to begin with, a procurement team knows they need a product, be it software, website or app to be built. They know the end goal, know what it needs to do and they put this piece of work out. Ideally they will have read our blog post on ensuring accessibility is built in at the procurement stage and they request anything built, is also built to accessibility guidelines.

Great stuff.

However, there are some key steps missing in 95% of project tenders that include accessibility as a requirement.

A typical product tender and delivery

A contract goes out and a successful development company with all the best intentions in the world wins the work. Towards sign-off someone notices that accessibility is a requirement and figures an audit is the best next step. They phone us, with budget already spent seeing what they may get for a button and a bit of pocket fluff!

man with empty pockets

The conversation then gets a little tricky.

  1. We find issues, but at the same time the development company really need to deliver to meet the go live date. It’s too late in the process to go back and re-do lots of development work. At this point they will realise that there are some significant knowledge gaps.
  2. We’re between a rock and a hard place. We know that product needs to go live, but it isn’t ready. If it’s not accessible, it’s not meeting all of the customer needs and presents a very real legal and reputational risk. As well as being a sub-optimal product, it’s not meeting the original requirements in the brief or tender. We have to deliver the news.
  3. For the first time the development team realise that there are some significant short-comings and identify that most of the issues should have been identified during the early development stages, but the key content has already been delivered and signed off by the customer. At this point it’s nobody’s yet everybody’s problem. Accessibility was always part of the requirement, Everybody wanted it, but nobody checked to make sure that it was getting done.

In summary, accessibility becomes a delivery bottleneck. That’s no fun for us or anyone else. It’s a headache, new budgets need to be found; resulting in delays, disappointment and extra unnecessary re-development expense or worse, the product goes live with known accessibility issues. Neither of these are desirable scenarios, and both are easily avoided.

A perfect tender

The ideal process would be the development company has help and support from an accessibility expert from start to finish. From design to wireframes to templates and finally to content population. An element of staff training and on-site support ensures that the development team are confident that they have the right set of skills needed to deliver on the customer requirements.

Accessibility milestone checks and reports are completed and sent to the purchaser – so they know accessibility is being considered throughout, leaving everyone confident that the end result is going to be good.

Following this more complete process, the final audit is essentially rubber stamping, giving a great big thumbs up and saying the deliverable is accessible. Expensive re-development costs are eliminated, and the product is more usable and accessible, and optimised to work for more people on a wider range of devices.

The importance of third-party validation

If we can draw some comparisons with security testing for a moment, it’s generally not a good idea to ask your developers to do their own security validation in-house. There is a clear conflict of interest, and as a customer you have no certificate of conformance from an independent tester. This is particularly true if the developers aren’t recognised security experts. And so it is with accessibility testing. While most development teams understand both accessibility and security needs, neither services should be tested in-house. Third-party validation is crucial to the successful delivery of secure and accessible digital services.

How to approach accessibility in procurement

Here’s our tips for getting things right based on working with organisations who are already following this pattern.

Use third-party validation

Don’t expect the developers to thoroughly test and manage their own accessibility performance. It’s like marking your own homework. It’s too much to ask in a hectic delivery environment. Most agencies don’t have an accessibility expert on-site, and even if they do it’s a conflict of interest to rely on their internal validation.

Build accessibility in to the process

A good accessibility organisation will pride themselves on their ability to integrate with the development team. At Dig Inclusion for example, we want the development agencies that we work with to feel like we are part of their team working to deliver a successful project, and that’s how it should feel. For this to work, early introduction to the product development is key including involvement at the design and wireframes stages, prototype builds, key delivery milestones and final delivery. This approach not only delivers better results for all users, but saves time and money.

Be clear about what you are asking for

“The product needs to meet W3C accessibility standards” might seem like a clear request, but precise guidelines (typically Web Content Accessibility Guidelines (WCAG)) and the version (1.0, 2.0, 2.1) also needs to be made clear.

Consider also whether there are any exceptions to the delivery criterion. Think about third-party tools such as calendars, booking forms, graph generators etc, as well as video content which will need captions and audio description and a player or process that supports both. Do you have the internal infrastructure to make sure that all content can be made accessible or are you anticipating some concessions? Have you thought about your PDF or other non-HTML documents? What about existing tools that are part of the content workflow? Does the CMS deliver accessible content? Make it clear what the expectations are and minimise the risk of finding barriers to delivery later in the project.