 My name is Mark Sadecki, and I'm the web accessibility engineer at edX. To be completely honest, I was actually shamed into accessibility. Back in the year 2000, I was working as a subcontractor for MIT's open coursework project, writing HTML templates. I was invited to campus to test some of my work in their usability lab, which is where I got my first experience with assistive technology. I watched an MIT assistive technology specialist and web developer, Richard Gallaghero, who I still get to work with to this day, attempt to use the template I had designed with Jaws, his screen reader. And I was completely embarrassed at how hard it was for him to accomplish simple tasks, although hoops he had to jump through and the hacks he had to use. So I went back to the office and tried to figure out what I did wrong, and the conclusion I came to was all I had to do was follow the rules. At that point, I still didn't really know what the rules were. The web standards movement was just starting to gain momentum. Jeffrey Zeldman's book, Designing with Web Standards, wasn't going to come up for a few more years yet. More importantly, I didn't understand why there were such rules or standards. I soon learned that you have web browsers over here, you have assistive technology like screen readers and magnifiers, voice input, and you have hardware devices like keyboards and mice. And if you want all these things to work nicely together on your web page, they need a reasonably limited set of parameters and rules that they can follow, that they can expect, and web standards. So knowing all the rules was a great start, but it wasn't until I started to understand the how and the why of web accessibility before I could consider myself any sort of specialist. How is knowing how assistive technology interacts with those other layers in the stack? Understanding the role of the accessibility API, accessible names, how various role states and properties are conveyed and interpreted by assistive technology, and how they're conveyed by the browser. The why is really just understanding the human impact that good or bad code has on end users who rely on assistive technology to use your app or to consume your content. I had the benefit of working for almost 10 years at the Carroll Center for the Blind in Newt, Massachusetts, building apps for a primarily disabled audience. Working directly with disabled users and seeing the joy in their faces when an app behaved and responded exactly how they expected it to, was enough to motivate me to never compromise and to always build great interfaces that everyone can use. I realize that not everyone out there has an opportunity to experience that firsthand, but I just want all the developers out there to know that the interfaces they design are not just used by abled-bodied mouse clickers, and that thoughtful interfaces and code can make a big difference for an audience that's often not even considered and who probably appreciates it the most.