Making your product more accessible "Product people - Product managers, product designers, UX designers, UX researchers, Business analysts, developers, makers & entrepreneurs May 05 2022 False accessibility, diverse teams, Diversity, Product Design, Mind the Product Mind the Product Ltd 1426 Making your product more accessible Product Management 5.704

Making your product more accessible

BY ON

You may be aware that today, Thursday 19th May, is Global Accessibility Awareness Day.

But why should Product Managers care about accessibility?

I’ll tell you a quick story, as a fellow Product Manager, and the tips I learned…

Most products rely on third parties for their success

A few years ago, I was working with an exciting start-up providing video-based sports coaching.

Like all products, we wanted it to appeal to a wide community of users.

The UK Disability charity, Scope, estimates that 19% of working-age adults have a disability, and one in 7 of the UK population is estimated to be neurodiverse, and have conditions like ADHD or Dyslexia. Diversity in product: Are we nearly there?

So, to maximise the size of our community, we wanted it to be accessible to all, even to older people who might also be athletes.

The challenge was how the app evolved. Our original thinking was it was just ‘an app’. However soon it required video components, a payment gateway, an associated web landing page, a gift voucher system and much more.

And, like most apps and websites, for its development to be a success, we required a mix of off-the-shelf products, contractors, and vendors to build the solution.

Suddenly, making the app accessible to all meant more than making the app meet the WCAG accessibility standards. It required thinking of the whole customer journey and ensuring that every 3rd party component we used to accelerate its development delivered accessibility too.

But the rewards were better customer reach, engagement, and impact.

So how did we manage accessibility across the parts of our product’s journeys that we didn’t create, but bought in? Not great. Bringing on-board 3rd parties is a challenge. And knowing what to look for, is essential to deliver an accessible product, both for launch, and all the version post-launch.

I wish I knew then what I know now, having worked at Hassell Inclusion as Chief Product Officer for the last couple of years…

Here are my 5 tips for getting accessibility from 3rd parties, whether you’re selecting technology to be part of your product, or getting a 3rd party to create the whole thing for you…

Can I trust your product or service’s accessibility now?

Say you’re wanting to use a website builder to create the landing page for marketing your product – how do you know if it’s accessible?

  • Does it have any accessibility documentation? Or, even better, a VPAT (Voluntary Product Accessibility Template) that describes the current level of accessibility in the product or service? If so, that’s useful. But did the vendor create it themselves or get an external expert to write it for them? An independent expert view is likely to be more robust.
  • If the level of accessibility is not great, it’s not necessarily “game over”. Ask the vendor, “What’s your roadmap to improve your product or service’s accessibility?” If they fail to give you a good answer, look elsewhere. Or, if you’re a huge corporate company with a lot of influence, like some of our clients at Hassell Inclusion, you could offer to support them to improve the accessibility of their service, so you get the accessibility you need, and so do all their other potential clients.

Can I trust you in the future?

But is a product being accessible now enough? Say you’re selecting a 3rd party tool to base your product’s development on. If so, you need to ask an additional question:

  • How are you going to keep the library/tool accessible going forwards?

Too often we see that accessibility drops when the staff at a vendor change. For one survey tool, we educated the support and sales team in accessibility, to get them good enough to use for the launch of our product. But, come the next release, all the accessibility improvements were gone and had to be redone. The developers need to make it part of their DNA, not a fault to fix in each release.

What if they say they’ll keep things good? Should you believe them, or ask…

  • What proof do I have that you’ll do that?

Look for them saying that they are working towards ISO 30071-1, the international standard on digital accessibility maturity. If so, that will require them to embed it in their policies, processes, and governance. Ask them about where accessibility fits in their product lifecycle and look for examples of accessibility features in their previous release notes. For a product or a development partner, it is also key to listen to how they deal with staff turnover and new staff to your product. Get all that, and you can sleep easier.

What happens if you fail?

You know that stuff happens that sometimes you can’t control. That may happen for your 3rd party, so ask them for transparency, not perfection…

  • If you cannot deliver accessibility in a release, what will you do to make that okay for us and our users?
  • Will you provide workarounds for users who are affected?

Accessibility can often be delivered by having two paths such as a snazzy video and a transcript, or graphics and alt-text. Those are official accessibility workarounds in WCAG, but they aren’t the only ones. If your chatbot vendor fails on accessibility, can they give you a call-centre workaround while they sort the issue? Listen out for how your vendor will provide alternatives if things go wrong.

Can I trust your proposal will deliver accessibility?

If you’re trusting your whole product’s delivery to a digital agency, you need to see evidence of their accessibility competence before they’ve even started to prototype. So, before signing that contract, tell them to:

  1. Give you an example of where and how your team have delivered accessibility for another client?
  2. Show you how your development process will actually deliver accessibility?

This helps you understand where they’ll design for accessibility, code it, and test for it. It also helps to discover if they have budgeted properly for this. If you really want to separate those who really get accessibility then also ask this…What is the most challenging part of my product to make it accessible?

This helps you hear if they really understand accessibility in the context of the needs of your product. Or, for a software component, it will help you understand how their accessibility connects with other parts of your existing solution.

Will you support me beyond launch?

After launch, you’ll be adding new features, sure. But you’ll more often be adding more content. You’ll probably use a Content Management System (CMS) to do this. So ask…Are you building in mechanisms to help me keep my product’s accessibility after launch?

For a vendor who is building your solutions, you will need to know what support they have designed (say a CMS which doesn’t allow you to add an image without alt-text), and what responsibilities you have (such as getting heading order on a page right).

Accessibility success comes from embedding this in the procurement process

In 2021, the UK Crown Commercial Service created a step-change in thinking in the advertising, marketing and digital agency sectors. They made the ISO 30071-1 standard a requirement in their selection of marketing comms agencies to work with, just like ISO 27001 security standard before that. That one simple requirement made all the agencies re-evaluate how they delivered accessibility in their campaigns. Over time millions of citizens will benefit, and also the agencies’ other clients.

Perhaps you have the ability to request the same from your suppliers.

A good place to start is to work with your procurement team, and ensure they have accessibility requirements included in your RFPs for digital products, and in the selection and contracts for software, technical services, marketing services, and contractor/freelancers. At Hassell Inclusion we often run workshops with procurement to build up understanding in the team, and then explore with them where to inject accessibility into the procurement process and legal documents.

Product Managers have the opportunity to drive seismic change in delivering accessible products, that benefit both users and the profitability of your products.

I hope this helps you drive that change! And, if you need help, please don’t hesitate to get in touch: www.hassellinclusion.com

Access further resources on Product Accessibility

 

You may be aware that today, Thursday 19th May, is Global Accessibility Awareness Day. But why should Product Managers care about accessibility? I’ll tell you a quick story, as a fellow Product Manager, and the tips I learned…

Most products rely on third parties for their success

A few years ago, I was working with an exciting start-up providing video-based sports coaching. Like all products, we wanted it to appeal to a wide community of users. The UK Disability charity, Scope, estimates that 19% of working-age adults have a disability, and one in 7 of the UK population is estimated to be neurodiverse, and have conditions like ADHD or Dyslexia. Diversity in product: Are we nearly there? So, to maximise the size of our community, we wanted it to be accessible to all, even to older people who might also be athletes. The challenge was how the app evolved. Our original thinking was it was just ‘an app’. However soon it required video components, a payment gateway, an associated web landing page, a gift voucher system and much more. And, like most apps and websites, for its development to be a success, we required a mix of off-the-shelf products, contractors, and vendors to build the solution. Suddenly, making the app accessible to all meant more than making the app meet the WCAG accessibility standards. It required thinking of the whole customer journey and ensuring that every 3rd party component we used to accelerate its development delivered accessibility too. But the rewards were better customer reach, engagement, and impact. So how did we manage accessibility across the parts of our product’s journeys that we didn’t create, but bought in? Not great. Bringing on-board 3rd parties is a challenge. And knowing what to look for, is essential to deliver an accessible product, both for launch, and all the version post-launch. I wish I knew then what I know now, having worked at Hassell Inclusion as Chief Product Officer for the last couple of years… Here are my 5 tips for getting accessibility from 3rd parties, whether you’re selecting technology to be part of your product, or getting a 3rd party to create the whole thing for you…

Can I trust your product or service’s accessibility now?

Say you’re wanting to use a website builder to create the landing page for marketing your product – how do you know if it's accessible?
  • Does it have any accessibility documentation? Or, even better, a VPAT (Voluntary Product Accessibility Template) that describes the current level of accessibility in the product or service? If so, that’s useful. But did the vendor create it themselves or get an external expert to write it for them? An independent expert view is likely to be more robust.
  • If the level of accessibility is not great, it’s not necessarily “game over”. Ask the vendor, “What’s your roadmap to improve your product or service’s accessibility?” If they fail to give you a good answer, look elsewhere. Or, if you’re a huge corporate company with a lot of influence, like some of our clients at Hassell Inclusion, you could offer to support them to improve the accessibility of their service, so you get the accessibility you need, and so do all their other potential clients.

Can I trust you in the future?

But is a product being accessible now enough? Say you’re selecting a 3rd party tool to base your product’s development on. If so, you need to ask an additional question:
  • How are you going to keep the library/tool accessible going forwards?
Too often we see that accessibility drops when the staff at a vendor change. For one survey tool, we educated the support and sales team in accessibility, to get them good enough to use for the launch of our product. But, come the next release, all the accessibility improvements were gone and had to be redone. The developers need to make it part of their DNA, not a fault to fix in each release. What if they say they’ll keep things good? Should you believe them, or ask…
  • What proof do I have that you’ll do that?
Look for them saying that they are working towards ISO 30071-1, the international standard on digital accessibility maturity. If so, that will require them to embed it in their policies, processes, and governance. Ask them about where accessibility fits in their product lifecycle and look for examples of accessibility features in their previous release notes. For a product or a development partner, it is also key to listen to how they deal with staff turnover and new staff to your product. Get all that, and you can sleep easier.

What happens if you fail?

You know that stuff happens that sometimes you can’t control. That may happen for your 3rd party, so ask them for transparency, not perfection…
  • If you cannot deliver accessibility in a release, what will you do to make that okay for us and our users?
  • Will you provide workarounds for users who are affected?
Accessibility can often be delivered by having two paths such as a snazzy video and a transcript, or graphics and alt-text. Those are official accessibility workarounds in WCAG, but they aren’t the only ones. If your chatbot vendor fails on accessibility, can they give you a call-centre workaround while they sort the issue? Listen out for how your vendor will provide alternatives if things go wrong.

Can I trust your proposal will deliver accessibility?

If you’re trusting your whole product’s delivery to a digital agency, you need to see evidence of their accessibility competence before they’ve even started to prototype. So, before signing that contract, tell them to:
  1. Give you an example of where and how your team have delivered accessibility for another client?
  2. Show you how your development process will actually deliver accessibility?
This helps you understand where they’ll design for accessibility, code it, and test for it. It also helps to discover if they have budgeted properly for this. If you really want to separate those who really get accessibility then also ask this…What is the most challenging part of my product to make it accessible? This helps you hear if they really understand accessibility in the context of the needs of your product. Or, for a software component, it will help you understand how their accessibility connects with other parts of your existing solution.

Will you support me beyond launch?

After launch, you’ll be adding new features, sure. But you’ll more often be adding more content. You’ll probably use a Content Management System (CMS) to do this. So ask...Are you building in mechanisms to help me keep my product’s accessibility after launch? For a vendor who is building your solutions, you will need to know what support they have designed (say a CMS which doesn’t allow you to add an image without alt-text), and what responsibilities you have (such as getting heading order on a page right).

Accessibility success comes from embedding this in the procurement process

In 2021, the UK Crown Commercial Service created a step-change in thinking in the advertising, marketing and digital agency sectors. They made the ISO 30071-1 standard a requirement in their selection of marketing comms agencies to work with, just like ISO 27001 security standard before that. That one simple requirement made all the agencies re-evaluate how they delivered accessibility in their campaigns. Over time millions of citizens will benefit, and also the agencies’ other clients. Perhaps you have the ability to request the same from your suppliers. A good place to start is to work with your procurement team, and ensure they have accessibility requirements included in your RFPs for digital products, and in the selection and contracts for software, technical services, marketing services, and contractor/freelancers. At Hassell Inclusion we often run workshops with procurement to build up understanding in the team, and then explore with them where to inject accessibility into the procurement process and legal documents. Product Managers have the opportunity to drive seismic change in delivering accessible products, that benefit both users and the profitability of your products. I hope this helps you drive that change! And, if you need help, please don’t hesitate to get in touch: www.hassellinclusion.com

Access further resources on Product Accessibility