TL;DR

I leveraged my passion for inclusive design into a movement within the organization at RealPage to bring accessibility into the product development process.

I trained the UX team on accessibility, created a copy style guide for UI designers to follow, and developed an initiative bringing together tech, development/QA, product owners, design, legal, and marketing.

The Problem Space

Accessibility is a nebulous, opaque concept, and comes off as something that companies should do, but it rarely becomes a priority for the organization…until the organization meets legal challenges. Then accessibility becomes just another government-mandated hassle that’s grudgingly implemented. WCAG’s “compliance levels” and “requirements” definitely do not sound fun.

Personally, I view “accessibility” as a subset of inclusive design, and view inclusive design as a way to reach more customers. The problem was to change the perspectives of those who didn’t see it that way.

From a design perspective, many believe that accessibility somehow makes a website ugly, and undesirable, which may be a function of how accessibility is usually implemented in organizations - as an afterthought. As the image at the top of this post shows, accessibility (in the form of a ramp instead of stairs), doesn’t have to be ugly, and can in fact be quite beautiful. By demystifying accessibility, and helping designers see it as a valid design standard, I hoped to get a measure of accessibility into the organization’s product DNA.

Since I was not technically a manager of the team, just a research and IA lead, and in charge of running the weekly team meetings, I walked a fine line. I had to be persuasive, but not demanding. Lead but not force. I didn’t want this initiative to get killed because it “took too much time” or “we don’t have the resources”. I couldn’t approach this like I did my students at the university that year.

Accessibility Everyday

A design team’s environment is important to their motivation and inspiration. I needed to add UX advocacy and accessibility advocacy to the environment, but in interesting and motivational ways.

I’d already printed out the included User Experience Culture Cards from Paul Boag’s User Experience Revolution and posting them around the design team’s huddle areas. Each card has “a practical step you can take to begin shifting the culture of your workplace. Steps that will help others understand how important it is to be user centric.”

I also began to create my own “environmental influence” posters, like my poster for the UX team that showed the WCAG 2.0 guidelines with examples in an eye-catching, conceptual way. This poster is not enough, though, to help designers who don’t know (or care) what WCAG is.

I also developed a basic WCAG education presentation for the design team that I presented in one of my team meetings. Running the team meetings allowed me latitude in content, and I planned to take full advantage of the opportunity. Until I got the opportunity to get funding for further training, that would have to do.

We also studied Microsoft’s Inclusive Design methodology; I had the them review the toolkit and provided time during team meetings to watch the stellar videos that team produces.

In addition to emphasizing the differences between accessibility and Inclusive design, it has excellent points about “disability”, including a demonstration of how we can all benefit from accessible technology. This is key to getting buy-in from stakeholders and generating empathy. As Richard Saul Wurman said, “You can only understand something relative to something you already understand.” As anyone knows who has sustained a foot injury and had to tool around the office on a knee scooter, or dealt with their own body aging, temporary or situational disabilities can happen to anyone, or evolve from the normal course of life.

I also wanted to test the design team’s understanding, but without “failure” - enter my UX Jeopardy game. Modeled after the TV show, the powerpoint I found on a teacher resources site would be PERFECT for this. In addition to other categories like Design Principles, Acronyms, and User Research, I had a category for Inclusive Design.

Gaining Buy-In

Having accessibility embedded in the design team’s work would not be enough. In order to get funding for training, not just for the design team, but for anybody at RealPage who touched the software, I would need executives to see it as a valid investment. Woo-woo empathy and people-first doesn’t motivate them, for the most part - their compensation is based on profit, not “accommodation”.

RealPage’s customers are property management companies. Their turnover in positions where people use this software can be very very high in positions like maintenance, front desk personnel, and support staff. A cynic could say that if the staff can’t use the software, it’s the PMC’s responsibility to make accommodations, not the software company’s. From a practical point of view, that perspective leaves one open to charges of discrimination.

This wasn’t a new concept to several departments in the organization.

• When I got to meet with the legal department, they mentioned that accessibility was certainly a problem in terms of risk, but that they didn’t know how to resolve the issue.

• Some of the developers on staff wanted to know more about accessibility, but didn’t know where to start. They can often be in the position of receiving design from the product/design team, and implementing, not co-creating, so they would need the product team to deliver accessible designs.

• In order for those designs to be successfully tested, QA must be educated about accessibility and include it in their testing documents.

• We discovered that one of RP’s own employees (and likely many more) were unable to use certain of our own software packages because of the inaccessible design.

• Marketing and Customer Experience would have a new bullet point to include in sales materials about the software if it were fully-compliant, an industry first and competitive advantage

• Litigation around accessible websites and SaaS is increasing exponentially and many companies are completely unaware of the massive costs of not having accessible products when they inevitably lose one of these challenges.

Persuasion

Taking all of this into account, I developed a presentation I gave first to the department’s internal champion, the CTO. In terms of content sections, I included the following:

• Charts and statistics that are shocking in their impact, and also have the added advantage of being something we should legitimately be concerned about

• Facts about the population, and definitions of terms we would be using

• Secondary source research on current and previous litigation on this matter

• A few demos of our own products to illustrate that, no, we’re not doing fine at this right now

• A few selling points about the advantages of this program outside of the fear and liability

• A roadmap and next steps, including the names of people I’d already gotten enthusiastic volunteering from

• First steps I would be taking

• Next steps I would need executive sponsorship to implement.

This presentation, demonstration, and game plan got the go-ahead from upper management to proceed with investigations into costs, training options, and internal outreach.