Introduction
Part II of this series will aim at answering where to start with accessibility. Perhaps you’ve not built a digital product yet and want to consider accessibility at the start - great. Perhaps you do have a digital product built, but you did not consider accessibility when building it - great. Or perhaps you do have a digital product built, you did consider accessibility when building it, but you did not consider formally documenting it (e.g. QMS, for sales, certifications) - great. For all of these situations, I’ll be upfront - you’ll need to make a commitment, you’ll need to make decisions, you’ll need to pull up your sleeves for the documentation ahead, and you’ll need to prepare for tough learnings & challenges.
Making a commitment
Building a product takes time and is complex. Add on-top of this, to also build the product to be compliant with accessibility standards. It will have an impact on roadmaps, product development lead times, design effort, and the organisation as a whole. This means that in order to be successful in implementing an accessible product, there needs to be commitment from the management team and the product teams. Specifically, you’ll need to make an informed decision, support the organisation in embracing the requirements, and follow through with it. What you don’t want to have is that accessibility becomes a nice-to-have, that accessibility becomes an exception when teams need to shorten timelines, and a product that is “somewhat” accessible. Meeting accessibility standards is a binary yes or no (even though you might have a different definition in-house), as well as being an infinite game.
So how do you do this: In an ideal world, all digital solutions offered should be accessible per design. However, myself being a pragmatic person and experienced product manager, I know from experience that simply putting up a commitment without proper thought-work will not work.
Firstly, below are some key aspects to explore in order to make an informed decision about accessibility. There may of course be further considerations to account for:
- What are the values of your company & product? Is inclusion and accessibility currently not a core company or product value? If not, should it be? If it shouldn’t be, why not?
- Who are your users? Are you targeting an indication where the prevalence of disabilities are higher? What is the age distribution of your user base (current or expected)? Is there data available on disabilities in the community or region you cater to?
- Who pays for your solutions? If municipalities purchase your solution, do they have particular expectations on accessibility and inclusion? If insurance companies, do they have expectations on accessibility and inclusion? What does the competition look like - how do they fulfil accessibility?
This information, combined with anything I perhaps did not list above, will help you drive a better decision on what accessibility you strive for. In your decision, lay out the following:
- What do we need to make accessible? All the products? Only a single product? A part of our product?
- For whom should we make our product accessible? Do we account for all disabilities? Dexterity? Vision?
- How accessible do we make the product? Looking at WCAG (the most widely followed standard), there are 3 levels of accessibility (A, AA, AAA).
Beyond this, you could also consider “inclusion” in your decision making - are we to support caregivers? Are we to support children?
You, the reader, know your business, product, customers, and users the best. If you anticipate not being able to ever provide a decent solution to blind people because of a limitation out of your control (e.g. your offering is tied to a third-party physical product that is not accessible), it is my recommendation to then to not include this in your decision. On the contrary, it is worth mentioning that accessibility tends to not only benefit a particular disability, or disabilities as a whole, but often benefit your whole user base. As an example, speech to text started out as an accessibility concept, but benefits so many more individuals today. The point here is to make the decision based on your knowledge of your business, product, customers, and users.
By now, you have defined what you are to make accessible, for whom you are making it accessible for (e.g. people with visual impairments, people with dexterity impairments, etc.).
Requirements
In my experience, accessibility standards often refer to the Web Content Accessibility Guidelines (WCAG) developed by W3C. This is also what you will most likely see being referred to by payor’s (e.g. tenders).
Through WCAG, you’ll find the requirements to meet in order to be considered accessible. More specifically, it’s structured by principles, then guidelines, then success criteria, and techniques. You can read more about this here. It is the success criteria that you are to meet when aiming to make your solution accessible. It’s also the success criteria that provides guidance on the level of conformance according to A, AA, and AAA.
Based on your decision made from the previous section, you’ll need to meet all of the success criteria or a part of them. To ensure clarity, I’d recommend supplementing the decision documentation with which principles, guidelines, and success criteria, you are striving for as an organisation. This also makes it clear as a reference point for the teams (product managers, engineers, designers, risk management, regulatory, commercial functions) what to look at and for when working with accessibility. It could be as simple as a table laying out ‘Yes’ or ‘No’ for each success criteria that applies to you or not. Consider making this a non-functional requirement for your product as well (especially being a medical device).
How to actually meet the success criteria
You’ve now defined what accessibility means to you and your users. But what is the approach for then putting in the effort to meet the requirements? This answer will depend on whether you have a product out already or not.
If you do not have a product out yet, it’s pretty simple - ensure that the success criterias are met and accounted for in any product development you initiate. This means wireframes, prototypes, proof of concept, production-ready product. Similarly to how we account for data security, or privacy, or branding, in building a product - consider the accessibility success criteria as an acceptance criteria.
If you already have a product out, consider the above to apply in any new or future product development. This will ensure that any future built code meets the accessibility success criteria from the start. For the already-existing product or features, there needs to be an approach of prioritise, assess, decide, improve (i.e. build, test, release, learn).
In general, accessibility starts with your designer(s). Make sure that your designer(s) are involved in the decision layed out previously and in the implementation effort early on. The majority of the success criterias are met through the interface design of your product. As the designer(s) is responsible for, amongst other things, laying out the designs of the product - it is important that the designers consider the success criteria in creating new components, re-using components, designing a new UI screen, and much more. In addition, it is best practise that a design process includes stages of reviews (e.g. peer-to-peer, within team, etc.). Consider accessibility to be an acceptance criteria in these reviews.
Ensure that accessibility is tackled with a multi-disciplinary approach. As the WCAG’s success criteria can be met through different solutions, it is important that the solution chosen also considers medical risk management, technology (e.g. latest iOS or Android capabilities, tech limitations), previous learnings (e.g. user studies, industry knowledge), and more. It is my recommendation that the designer(s) drive the work while utilising their product teams (developers, product managers, risk managers, and more).
Lastly, perform a review before labelling yourself as accessible. As mentioned in the beginning, you cannot simply call yourself accessible with half the product meeting the definition and the other half not meeting the definition. It could be as simple as adding a column for “is the acceptance criteria met or not”. Depending on the specific context, you might need to do this in compliance with regulation as well as minding audits (medical device) or requests for evidence (e.g. tenders). Also remember that building an accessible product is an infinite game - a one-time review doesn’t mean you are accessible for the foreseeable future. You need to ensure to continuously meet the requirements.
Ending note
So this was part II and you hopefully got some further insights. Beyond understanding what accessibility means and how it may benefit you, you now know where to start and what it takes.
- Define your ambition level
- Define the scope for accessibility
- Make changes iteratively on the already live product while already accounting for the new requirements in any new development
As a final note;
- Stay pragmatic. Accessibility does not have to be difficult or viewed as an annoyance in product development. Make conscious decisions on where your ambition level is as well as how you chose to implement accessibility.
- Make decisions with your users in mind. Even though you might have high standards to follow, make it work for your users who ultimately this is about at the end of the day.
Hoping for an accessible and inclusive healthcare 2.0,
Robert
