Let’s be honest. It isn’t often that a software designer can truly say they help people. We might say we’re helping people to use software more efficiently, but are we helping people in a humanitarian way? Not really. But, by making our software products accessible, we actually do have the opportunity to improve peoples’ lives directly.

Accessible software products allow people with disabilities to perform tasks that might otherwise be impossible. People with disabilities are enabled in both their personal and professional lives by products that help with daily life and tools that help with the rigors of work. Regardless of disability type, people are able to work alongside others and be active and productive. In fact, the person we enable may very well become the designer that leads our team to success in the future.

So why isn’t more software being built accessible? The problem isn’t a lack of desire but rather the challenge of building an accessible development framework. Creating a design thinking framework is tough enough — creating an accessible design thinking framework can be a herculean effort.

Integrate, don’t bolt on

While the best design thinking frameworks present a human-centered, iterative methodology and offer a collection of tools and exercises to help product teams reach desired outcomes, very few of these frameworks include a solution for releasing accessible, inclusive products. Even fewer attempt to mold a culture around accessible design and development.

The theory is that if products are designed accessible, they are built accessible.

Accessibility tasks must be woven throughout a user-centered design framework to create the foundation for a successful, scalable accessible software practice. Understanding what tasks need to be done when and by whom will take some extra time, but it pays dividends in the end by eliminating debt and opening up markets. Our Equal Access Toolkit was designed to work within a design thinking framework to timely integrate the appropriate tasks into a normal workflow.

Shift left

Historically, the majority of the accessibility work has been done by developers after planning and design. One saint on the team that takes it upon themselves to understand a very deep topic. So, understandably, the first version of our toolkit was aimed at developers who were coming to us for help.

But while breaking down the accessibility checklist into roles and phases, we realized that designers should be shouldering most of the weight. The most critical tasks involve careful attention to design for users with disabilities.

Developers obviously remain indispensable but should not be relied upon to make design decisions based on accessibility. A bigger issue is that it is more expensive to focus on accessibility work at the end of development and during testing.

By this time, a team is simply paying back debt created by a lack of accessibility planning and design. Teams need to start with a plan that relies on designers to create accessible designs. The theory is that if products are designed accessible, they are built accessible.

Prioritized list of tasks

As the primary source of accessibility enablement for IBM’s accessible software design, our team of helpful experts has noted a steady drumbeat of requests for lists of the top things teams can do quickly to improve their products’ accessibility.

Teams want to know “the most important thing” they can do in the moment without doing everything. But this request strikes a dissonant chord with accessibility experts: we don’t want to leave anyone out. Please don’t “just” do these things; do them all!

We’ve come to learn that this approach isn’t realistic in a fast-paced development environment. While prioritizing, we realized that we could break out tasks into three levels, delivering on a promise we had made to prioritize accessibility tasks by impact.

The first level of tasks satisfies user requests for a list of “most critical” items to do. This gives team members a list of tasks to tackle in a time crunch for their respective roles. The next two levels complete the WCAG checklist and, if done right, push a product to accessibility compliance. We are currently working on a fourth level that will go above and beyond compliance to deliver an even better experience for everyone.

For designers, prioritized tasks are broken first into phases or roles, depending on the team structure. Within each phase or role, the tasks are broken into major topics with three levels of prioritized tasks listed. The tasks are accompanied by examples along with further resources and reading. Most existing guides and resources follow checklists instead of breaking things into logical tasks in order of importance. Our toolkit will give team members specific things to do in context with current work.

Make it last

Building accessibility into the overall process is a major battle, but winning it won’t necessarily foster a lasting impression and culture. We’ve learned through our engagement with internal teams working on more than three thousand IBM tools, various client engagements, and the team’s years of accessibility experience that empathy is the most powerful tool we have.

Building empathy can be done with empathy exercises, but nothing compares to the direct exposure of stakeholders and team members to people with disabilities. Designers are empaths by profession, and just because we want to help people with disabilities doesn’t make it easier to do.

To really understand and serve a user group, we need to get to know them. For example, respondents mention that a demonstration of how software is used by a blind user has a deep effect. Usability testing, interviews, and direct discussions with people with disabilities always result in more responsible, usable designs.

One drop of dye

Whatever the design exercise may be, users with disabilities can be easily represented in the design process. At IBM, we have the luxury of working with many teams that we can iterate with on techniques for solving accessibility issues. We found out, for instance, that teams will end up doing accessibility for people with all different types of disabilities even if they only focus on one type of disability during design.

We asked teams to introduce a disability into their exercises. We didn’t limit their choices, but we did introduce several disabilities that are most impacted by accessible digital design (such as blindness and users unable to use a mouse). Expanding these exercises to include a particular disability type opened the door to more research and learning about accessible design. At the end of the projects, we found that each team had addressed a majority of accessibility tasks for all of the major disabilities, not just the one they assigned to their users.

Empathy is the most powerful tool we have.

Nothing beats exposure to actual users, but finding people with disabilities to provide feedback can be difficult. While anecdotal information is helpful, direct contact will not only expose accessibility issues but also reward the designers with priceless professional growth. The IBM Design studio in Austin, TX often works with local schools for the deaf and schools for the blind. If you look around, you’ll likely be rewarded with people willing to help. Designers who understand people with disabilities can better serve everyone.

If you need ammo

As an accessibility professional, I notice how few designers and developers are well-informed about accessibility and the impact that it has not only on users and clients but also the company’s bottom line. About 15% of the world’s population have a disability, and all of us will eventually have one of our own as our eyesight, cognition, and motor skills fail us.

Then tack on the myriad environmental and contextual disabilities we all deal with, especially while social distancing. Our clients understand these numbers and demand accessible products to reach all customers and users. The direct market demand for accessible products allows us to justify working even harder on creating a sustainable accessibility development culture.

Releasing accessible products also leads to positive sentiment about a company. Understanding this can help drive resources toward inclusive outcomes by fostering a culture of accessibility internally. The colors will bleed through organically and validate campaigns that reach the public where it matters. IBM proudly celebrates more than 100 years of inclusion, including a corporate requirement that all our products are accessible. It is possible to make accessibility a corporate mission.

If you want to make a change, you’ll have to convince the right people first. An effort of this magnitude requires people, time and commitment. The good thing is that there probably hasn’t been a better time culturally to make this change. Altruism, market value, and public sentiment are strong arguments and if a company of 400,000 can tackle it, you can too.

Go and grab the IBM Equal Access Toolkit, check out our tools, give it a shot, and give us feedback. We are all in this together.

Bo Campbell is a UX Designer at IBM based in Austin, TX.

The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.