⚗️ Bring inclusiveness and accessibility to your pipeline

In this module

This module gives guidelines and advice on how to incorporate inclusiveness into your organization's workflows.

⛳️ Section: A. What is accessibility?

👥 Audience: Everyone, especially managers

⏱️ ️Duration: 15'

📚 Prerequisites: None

Incorporating inclusiveness into your workflows

The structure of your workflows shape the application you are delivering. By explicitly incorporating accessibility and inclusiveness throughout your design and development pipeline, you are making sure that you and your team are actively working towards an application that will be usable and welcoming to everyone.

Accessibility and inclusiveness are complex topics that can be tricky to incorporate into your structure's habits and processes, especially with varying team compositions and scales. As small structures have less time and lighter processes, heavy accessibility workflows as used at industrial scale are likely not to be compatible with your structure if you are a small team building FOSS (Free and Open Source Software).

But this agility can be used at your advantage by picking and choosing some practices that might fit the way your work. In this module, we'll cover some practices you can adopt and brainstorm together on the ways we could incorporate inclusiveness into your workflows.

Accessibility and inclusiveness essentials

In this section, we'll cover essential steps towards an inclusive app.

1. Have inclusiveness in mind since the ideation

When coming up with a new feature for your app, ask yourself: what are some possible accessibility and inclusiveness challenges for that user experience? Are there elements we can anticipate from the design?

2. Make it a goal for your designs

Good design is inclusive. And good design benefits everyone. To get concrete insights about what's an inclusive design, check out the 🎨 Inclusive design 101 module.

3. Iterate on implementation

Inclusiveness is a process. You will probably not get it right the first time. Testing and tweaking the experience until you reach a result you are satisfied with can take time.

We provide some detailed implementation advice in 👩‍💻 Inclusive code 101.

4. Test

Testing is a crucial part in the process of making a feature inclusive. Refer to the 🤺 Developer stance & user collaboration module for considerations on how to get feedback from testers.

5. Get user feedback

Getting user feedback is essential, especially when it comes to accessibility and inclusiveness. This can be done by actively requesting community feedback. Additionally, we highly recommend creating an issue template for accessibility, and encouraging users and developers to create them when encountering an issue. This will nudge the whole team to regularly pick up those issues, once they're in the backlog.

Having an inclusiveness/accessibility coach

With this in mind, how do we make sure that these steps are taken? While there are many ways, one is given in the Agile Accessibility Handbook.

The author suggests that every team has their accessibility coach. This person should be especially knowledgeable and empathetic regarding accessibility, but is not required to be an expert nor to work full-time on the subject. They will not be doing all of the accessibility work. Rather, they are the ones who monitor with other developers the progress of the current accessibility roadmap. Even if your structure has a product manager who is willing to do this job, the accessibility coaches can also have a great impact by bringing knowledge on how to architecture accessibility on their platform. They are the one responsible of making sure that accessibility is a constant thought through every step of development within their team.

The coaches of every team can meet regularly with the product manager (if there is one) to coordinate and update the accessibility roadmap of the application. They also can organize monthly meetings with all of their teams to report on the improvements, blockers and perspectives. The main goal is to normalize accessibility and inclusiveness as routine parts of development.

Building empathy

Empathy is an absolute requirement for your team to get involved in the process of making your application inclusive. As stated in 🤺 Developer stance & user collaboration, we all have a singular, partial perspective of the world. These comes with biases but also insights and experiences. It's likely that most persons working in your structure will have limited living experiences of disability. This can lead to an "empathy gap" (as called in Barrell's book) where accessibility and inclusiveness feel like remote and niche preoccupations. Therefore, it's crucial to build empathy by helping workers to embrace diversity.

This can be done by discussing with diverse users and experts, regularly communicating internally on the subject (for example, by sharing stories of users who took advantage of the inclusiveness of your app) or by hosting events where team members can try and use your app with assistive technologies or simulated disabilities, and reflect on what could be improved.

Wrapping up

At the end of the day, incorporating inclusive practices to your workflows really comes down to trying what works best for your team, picking and choosing some ideas that organizations use daily.

If you want to learn further on this topic, the Agile Accessibility Handbook mentioned previously is a very solid starting point, tackling big picture transformation processes as well as small-scale team practices.

Sources

Barrell, Dylan. Agile Accessibility Handbook. Amplify Publishing, 2020.