Eliminating barriers: Sharing lessons learned from Microsoft’s journey towards accessibility

Feb 28, 2018   |  

“Empowering every person…” means every person and that includes Microsoft employees and customers who have or are impacted by a disability. My team is on the journey to bring this meaningful mission to life and as excited and willing as we were to get started, we were also a bit anxious (to say the least) at the considerable challenge we knew was ahead of us.

As a global organization, Microsoft has several thousand applications and sites—very few of which were considered accessible at the time the Microsoft Core Services Engineering (CSE, formerly Microsoft IT) accessibility program was launched. When my team gathered to carefully study the environment and what was needed to begin breaking down barriers, the answer was obvious, but daunting: a really good strategy…and a whole lot of coffee.

Questions flooded the first few brainstorming sessions. Instead of newfound ideas on becoming more accessible and inclusive, we’d usually walk out with more concerns to discuss. Do we review every page in a website? How do we get our development teams prepared to address this strategic initiative? What can we put in place to jumpstart the effort? Our goal was to design and launch a process that would yield as much impact as fast as possible without getting too overwhelmed. Looking back, I’d say the latter was a bit ambitious.

It was important to eliminate the barriers—one by one—by order of amplitude, so we began by targeting the most impactful set of web applications and arming our program managers and engineers with skills, and knowledge so we could bring them along with us on the journey.

As a first step, my team decided to set boundaries and scope to maintain control of the operation, and not lose sight of priorities. I had been schooled on the frustrations my colleague Anne encountered in trying to do her job as a blind employee, so knew one of the first things to address were the sites and applications our own Microsoft employees are required to use. The ability to independently use performance systems, internal job postings, and time and absence reporting was problematic for her, so those needed to be high on the list. Equally important were high traffic apps and sites accessed by users external to Microsoft. These sites are the face of Microsoft, and we needed to make sure we didn’t impede anyone’s ability to do business with us, get critical information, or apply for a job. With those two categories, we had our starting inventory.

Next, we established consistent and repeatable guidance for our program managers and engineers. While Microsoft has defined clear standards that align to industry regulations and guidelines, we quickly determined there were several key decisions we needed to make to have confidence in our results. For example, we defined a set of standard platforms to test for compliance, including OS, browser, and assistive technology combinations. Reducing platform variability allowed teams to focus and get test results faster. Another example was to set up a centralized assessment service which included standard test cases and bug documentation. By using the centralized service model, we could quickly provide teams with a set of issues mapped to those standards, so engineers could address problems and track their progress. The bug information also gave the program team line of sight into problem areas, so we could target training or follow up for the teams that had challenges with fixes.

Lastly, it was imperative that our program managers and engineers could start their journey to get skilled up in accessibility. Again, the scale of our organization meant that we had to develop a multiprong approach. For the teams supporting the highest priority applications, we developed in-person classroom training sessions that allowed for hands on practice in finding and fixing issues. These sessions were made into videos that other teams could access on demand. We obtained an online training library that was available broadly across the organization. Additionally, we created an Accessibility Hub to house content including best practices, examples of good and bad coding practice, and a code snippet library for our engineers to use.

Lessons learned

We’ve only just laid the foundation and, in the process, have learned some important lessons that you may find useful in your own journey to accessibility. The program is now two years in and continues to mature as more tools and resources are built to support the goal. It’s satisfying to look back on the progress. Today, Anne can independently contribute to her performance review, apply for another position, and log her time and absences—this is good news. But the mission to build the capabilities so all released code is accessible is very much still underway.

Prioritize. The time and effort we took to set the initial prioritization of apps and sites was well worth it because it not only allowed us to make real progress on what was most impactful but to also identify sites that were no longer needed and could be retired.

Train. Retrain. Train again. We continue to refine how we build the skills in our resources. We know that meeting accessibility requirements takes a lot of time and practice, but to do it right, a good measure of empathy on the part of program managers and engineers is also required. Understanding the “why” is as important as the “what”, so training must reinforce that accessibility should always be a priority in the development phase.

Keep track. Using a central assessment service was an effective method to jumpstart the effort and accelerate progress, but we learned that this model could easily become a crutch for the collaborating teams involved. People can become so dependent that they do not take accountability for building their skillset and embedding accessibility into the engineering process and governance. We’re now setting metrics and targets, so we can begin to understand the teams’ progress in getting self-sufficient.

An inclusive culture at Microsoft means that everyone, regardless of ability, has access to our technologies so they can reach their full potential. As we continue to share how Microsoft is helping build this culture, we hope that you will join us in the journey and learn as much as we have so far.

Learn more about Microsoft’s commitment to accessibility and inclusion in action and explore developer tools and information you can use to create the next generation of accessible technology.

Tags: ,