Achieving buy-in for accessibility, from your team or business can be a long and difficult task. Partly because there are a number of stereotypes around accessibility, especially around it being expensive in terms of time, money and effort. But there is so much value to be had incorporating accessibility into your products and services. So, here are four steps to get buy-in from both the business and your teams.
Conversations around accessibility are challenging and at times can be complicated. A lot of people think accessibility is difficult and expensive to include as part of the process, and the legalities of accessibility can often lead to making it feeling scary to tackle. When we fight for accessibility, often we fight for having accessibility as a consideration in the company or on the team, which can lead to the term being used too vaguely. Quickly you can find yourself in the position of asking “Can we please consider accessibility!” to then being told “Well, just make it accessible. Oh and you have a deadline of 2 months.”.
Accessibility does not work like that.
The first way to get the attention of business is to speak the business’s language. Showcase how accessibility can help achieve business goals. Whether it’s engagement or revenue, accessibility has evidence and statistics to support many goals and arguments. Present what competitors are doing in regards to accessibility. When it comes to laws, sometimes customers don’t have a choice - they have to choose the compliant company. Use this as a driving force behind why the business should invest in accessibility.
How you do this is by using dedicated times like Friday briefings, company showcases or lunch and learns, where the business is involved to present your case. Make the most of these situations where the business already dedicates their time to hear about what is going on, and you’re not asking for more of their time. Their time is difficult to get a hold of regardless of the topic, so really look for times where they are open to discussions and updates.
The next stage is to propose the actions you and the business need to take. Once you have the attention of business you need to put things in place for them to take the next steps, both from a higher and lower level of detail.
An absolute must-have as part of the strategy is to simplify where necessary the complications of accessibility for both yourself, your team and the business. For example, look where you can introduce checklists of accessibility, like how GDS designed their posters for designers.
Another example is defining what you support. Like browsers, there are many versions of assistive technologies, both software and hardware. When we say “making it accessible” it can often feel like it’s implying that your team has to support every assistive technology out there. Look at common statistics of assistive technologies and the platforms and browsers that they are being used with, then define what you will and will not support. It’s near on impossible to support everything out there, but it’s the lack of defining and narrowing down what you will support that can make accessibility feel daunting.
The priority of this stage is to put into writing exactly what you need from the business to action accessibility. We need to move away from the basic questions like “have we thought about accessibility?” or “Can we start to include accessibility?”. You and the business need to know the steps to do so.
Once you have the proposal or strategy break it down into two parts. The first part should provide short steps of what needs to be done, in what order and who is or should be involved. The second part is the lower level details of the plan. Include details of training that people need, including the different courses designed for different roles in the company and domain. Create a list of agencies which offer services related to business requirements, like accessibility user research/testing, audits and VPATs. Then add details like the costs of each aspect and the timeframes of how long each course or service would take. This helps define the lead time you need to deliver accessibility.
Accessibility is not just a one person role. In many places, it is a full-time role which sits alongside full-time researchers and designers. Rightly so given its legalities, complexity and levels of detail. Start by rounding up colleagues around you who are also passionate and care for the cause. Depending on the structure of your company, recruit across roles, disciplines, seniorities, teams and products etc. to ensure accessibility is discussed at every point.
What defines an smbassador though, is not the passion but the depth of knowledge. Ambassadors should be trained in accessibility, with training relevant to their role and domain. The ambassadors should be thought of as a team, regularly coming together to discuss best practice and solutions. Regularly meeting to knowledge share will reduce efforts and costs, and help to create design patterns across teams and products. Proposing this strategy also helps sell the idea to the business.
You have the attention of business, you have your strategy in place and your ambassadors by your side. Now you need your wider team also invested in accessibility. The ambassadors are there to raise the questions and have the in-depth knowledge but your team are still the ones who have to design, build and test accessibility.
Start by demystifying the term ‘accessibility’. The term itself is too vague but when looking into accessibility, it can be an overwhelming experience and feel like a daunting task. Agree with the team on how to approach accessibility and have clear actions on what needs to be done as part of the team process. Documentation of solutions should break down the accessibility requirements to deliver the design. For example, every icon in the design should be accompanied with the ARIA details, e.g. role and label, and the keyboard interactions of using the new feature should be mapped out. Sometimes it’s difficult to define the behaviours or interactions without understanding the final implementation. If there is ever an argument for why a UX designer should code, it is accessibility because of how much the implementation affects the experience. It is an absolute asset to be able to pair with a developer to build in accessibility as the feature is being built. Just ensure developers are aware that there are accessibility requirements and the feature may not be signed off until these are done.
Watch the full presentation of this post on UXPA’s YouTube channel.
Previous post: 5 Tips for Interviewing Users