Braille on elevator buttons.
Crosswalks with audible warning tones.
Railings in bathrooms.
I have long been aware of these tools for accessibility in the physical world, and I also notice when these accommodations are missing – a curb with no ramp, a building with no elevator.
But what about digital accessibility?
I admit, until 18 months ago, I hadn’t given much thought to what accessibility really means when it comes to technology. At the time, I was working on the Microsoft IT workforce transformation team, and was asked to help assess, and deploy some accessibility training for our organization.
Being new to accessibility, I began by talking to colleagues on our Microsoft Accessibility team, who told me the topic is both simple and complicated. The simple part is why to make technology accessible. Microsoft has a mission to empower every person and every organization on the planet to do more and achieve more, which means technology should reflect the diversity of those who use it. The more complicated part is how to make technology accessible. At this point I started to feel like I was learning a new language. There are 75-plus Microsoft Accessibility Standards (MAS) based on Web Content Accessibility Guidelines, Section 508, and EN 301 549, and more. How would I make sense of all of this? How does anyone?
Early on in my journey, I watched a demo by Microsoft employee Anne Taylor, who is blind. I was blown away to see the extensive lengths Anne had to go just to make simple interactions with software, apps, and websites. Anne is a whiz at using Job Access with Speech (JAWS), a popular screen reader, yet even for Anne I saw how many steps it took for her to perform the same tasks that as a sighted person I find simple. This began to make me realize that accessibility, at its core, wasn’t about all those technical requirements. It was about an experience. If we start by thinking about the experience, it’s easier to consider the ramifications of how we build that experience. To me, this kind of thinking is critical to making sure our culture is both diverse and inclusive and customer obsessed.
After this I really started to dig into understanding accessibility standards in more detail, and how they translated to the practical changes we needed to make to improve our technology. I’m not a developer, so the deep technical detail in accessibility standards wasn’t going to help me. Besides, accessibility is a mindset, not a checklist. Compliance is not culture change.
My colleagues and I have now been working for nearly two years to make Microsoft more accessible. We’ve conducted assessments and audits, and begun training our teams in support of getting over 100 applications and websites to be accessible (MAS compliant). We’ve managed assessments and audits for over 350 applications, and sites. We’ve trained over 400 people in the basics of accessibility. We’ve become well-versed in accessibility standards, but also in the kind of work it will take to inspire true culture change. In many ways, our journey has just begun.
Editor’s note: This is the first in an ongoing series from Microsoft Core Services Engineering to discuss our efforts to make enterprise applications more accessible and to highlight the need to make accessibility an integral part of the engineering and development process.