Many people ask me how a developer who was working on the back-end for websites got involved in accessibility. After all, it wasn’t technically a part of my job description. It wasn’t going to make our sites faster (though I later found out it could have that side affect). I didn’t have a disability, nor did I seem to be closely associated with the disabled.

The truth of the matter: I stumbled into it. I was working on a contract at NASA, and we were required to make our sites 508 compliant in order to get them deployed. A separate group was responsible for assessing our sites then sending us exact fixes. Our websites kept failing and we found ourselves falling behind schedule again and again.

We often asked the testers to explain why something had failed, but they, like everyone else on the contract, were too busy to take time to educate a handful of developers. They gave us a checklist, which we read and were baffled by. Tables need scopes? What are scopes? Why do they need them? What’s wrong with the designer’s color scheme? What do you mean the contrast is no good? Why was our alt text rejected?

At the time, the resources on the Internet focused on more on policy makers and lawyers than developers. Though we found many tips about creating an accessible application, few included why these added tags made our sites easier for the disabled to use. This made it increasingly difficult to make websites that were new and innovative without wondering if we were inadvertently shutting someone out.