⚗️ 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: B. From accessibility to inclusiveness?
👥 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.
One good story to start building empathy can be the one of Jill, told by her friend Ashley Shew.
Ashley Shew, Against Technoableism, Rethinking Who Needs Improvement
When I was in grad school, before I was disabled, I made great friends with my fellow student Jill. I didn’t think of myself as disabled, and it would be another ten years before I would be diagnosed as having Crohn’s disease, but I was already having intermittent issues with inflammation and flares of symptoms that didn’t really make sense together yet. She was a paraplegic wheelchair user. She passed away over a decade ago now, but back then, we hung out with a larger group from our cohort, and Jill and I got along especially well. We had classes together, occasionally shopped together, and she’d invite us all to her apartment for group hangs. She was originally from New Jersey but had moved to New Mexico, where the climate was better for her. She loved New Mexico. She was just away to earn a master’s degree: two years in our program in Virginia, then she planned to return home to New Mexico to teach. She was full of jokes, and it was easy to be with her.
On our campus, disability accessibility was . . . shitty, to say the least. And she was the first physically disabled person whose experience I could really see clearly every day, since we were in so many activities together. I remember the long routes we had to take to avoid stairs. I was lucky to be in a ground-floor apartment, so she could occasionally visit where I lived, though the bathroom door was too narrow, so visits weren’t terribly long. Her own home wasn’t ideal either. She had very little choice over what apartment she could move into—so many fewer options than I had. And the apartment she ended up in wasn’t even truly accessible. It had a bathroom with an appropriate sink and toilet, but the shower wasn’t great, and the kitchen was just the same standard kitchen that was in all the apartments in the complex, so she had to be creative. The apartment complex itself was kind of a dump—filled with undergraduate students and close to campus. The parking lot was always overfilled on football game days. On one of those days, we were going to hang out, and then she was going to go over to the library for an event. I drove over, found a parking spot way out in some grass, and trekked over to her apartment.
Jill was on the phone when I got there. Someone had parked next to her giant white van in the yellow-slashed area that is the open zone next to her disability parking spot. She could neither get to the side of her van to get in nor open the door to allow the van’s wheelchair lift to fold out. The van was set up for her, with no seat on the driver’s side since she’d be in her wheelchair, so I couldn’t simply back it out for her to get in. (It was set up for someone like her, but not her, actually. She considered herself very lucky to get a secondhand wheelchair-accessible van like this; it had been set up and driven by a different person with a similar disability. A new van would have been way out of a reasonable range of cost, and the secondhand van was still pricey.) She had already called the apartment complex once that day. Although the complex had signs all around the lot saying that it would tow away non-resident cars (which this one was!), it was game day, so they didn’t want to call a tow company. They said they couldn’t do anything and told her to call the police. She called the non-emergency police line, and they said it was the domain of her apartment complex. And it was game day after all, so the police were busy too. She was shuttled back and forth like a tennis ball. No one was going to do anything.
I was outraged. Why should my friend be kept home all day because someone decided to park where they shouldn’t? What if there had been an emergency of some sort for which she’d needed her van? Didn’t they know that disabled people had places to go?
Jill wasn’t pleased either, of course, but this wasn’t her first time hitting walls with access. I was naïve to be so mad. She encouraged me to let the air out of the car’s tires. I regret that I was too much of a wuss at age twenty-three to actually do it. We already knew the police weren’t going to come about the car, so why didn’t I? Often, past me disappoints my currently disabled self.
I think of all the infrastructure that failed here—that was really built to fail, because it was never built to consider disabled people. It did the bare minimum: the physical complex (and administrators, and the police) met a few legally required standards, but they did not actually enforce the civil-rights law that is the Americans with Disabilities Act (ADA). Few complexes met even the lowest bar, so her housing options were limited—she was glad to even get that dumpy, inconvenient apartment. The systems in place supposedly to give her equal access—including her leasing office and the police—were indifferent to actually ensuring that she had it. Jill missed the event she said she’d help with at our library. Turned out she was accustomed to these system failures. At least that day wasn’t a failure with life-or-death stakes, like the ones that would delay her access to gynecological care and ultimately lead to her death less than two years later.
Info
If you have examples of (whether success or failure) stories related to the app the trained team is building, it can be added to complement Jill's story and start extending this empathy to software development. If you have stories you would like to share publicly, feel free to contribute.
Reflect on this story with the trainees.
- What should and could have been done differently by the institutions and engineers implicated?
- How does that translate to software accessibility? What can be the impact of poor accessibility and inclusiveness on your own users?
- What does that tell about the stance to adopt as an app builder?
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.