I’ve spent more than twenty years developing applications and websites. That’s a lot of time spent sitting in a cubicle, head down, coding, and racing toward deadlines to make the business stakeholders happy. It took me twenty years to realize I should have kept my head up and taken time to understand my customers better.
What did I know about my customers twenty years later? I knew they were the people who visit and use my websites. What I didn’t know was that my customers had varying levels of ability. I just never gave that much thought. Not only do I want my customers to visit my websites, I want them to return to them. What I missed while sitting in that cubicle and plopping down code like an automobile production line was the undeniable fact that some of my customers need certain accommodations when visiting and using websites that I had developed.
They needed accessibility.
I needed to look at my career from a broader perspective. I knew I wanted to head down that accessibility path, but as often happens when one changes direction, the path wasn’t clearly defined. Getting started was the hardest part. At first it was like hacking a trail through a dense forest with a dull machete. But once I got in a few swipes, the machete sharpened with every swing. I began to feel a unique kind of momentum. Let’s call it a strong wind of accessibility at my back.
I decided on my approach and broke it down into three distinct areas: become educated on accessibility standards, learn proper accessible coding techniques, and revisit my customers to really get to know them – not just as customers, but as people. Since I’ve always considered myself a people person, I chose the human side of my education as my first step.
I went to work at a center for the blind where they help people who had become blind or suffered vision loss lead independent lives. That was pretty amazing in itself. Then I sat down with some of the staff who were blind and watched them as they worked at their computers.
A blind person using a computer? You bet! Most of them could get to where they needed to go and do what they needed to do faster than I could. It was simply amazing. Then one person volunteered to show me the downside of being a blind computer user. He navigated to an online grocery store and selected a few products, but couldn’t figure out how to add them to his shopping cart. He then went to an online florist to order a bouquet of flowers for his wife but was unable to find a way to submit his order. Next, it was a visit to an online public transportation schedule but it was impossible to figure out which bus would be at which stop and when.
These three tasks, which are easily carried out by sighted people, weren’t accessible to someone using assistive technology — three seemingly simple things, one very frustrated person. Now I was frustrated, too. He should be able to do those things just like anyone else. There should be a law! Well there is a law, and now it was time to take my next step down the path to accessibility.
From a developer’s standpoint, I found the best place to begin learning the technical side of accessibility was the ADA (Americans with Disabilities Act). It is a primer for Section 508 where the standards for web accessibility become more defined. Next, it was time to get into the meat and potatoes of programming for accessibility, the WCAG 2.0 standards. Here is the great thing about the WCAG 2.0 standards: they don’t just show me the what, where, and why. They also show me the how. A lot of what I found in those standards is common sense programming techniques that I had somehow either forgotten or simply abandoned while I had my head down in that cubicle. In short, coding for accessibility is not rocket science. It is proper semantics, best practices, and plain common sense!
There are so many benefits for everyone when <a href=”https://www.tpgi.com/inclusive-design-principles/”>inclusive design</a> and solid, fundamental programming techniques (the building blocks of accessibility) are incorporated into the code base. You’ll find that writing code for accessibility is easier than you’ve thought in the past, and get this: it will make you a better developer. You’ll write better semantic code, and you will learn that when including the standards into the design phase of your work you’ll save yourself a lot of time (and corporate dollars) down the road. In addition, you’ll feel better about what you do and how you do it. And yes, you’ll find yourself wanting to spread the word about accessibility to your associates and to others!
Most importantly, you will attract visitors to your site and everyone will be able to use it, and that means they will come back to your site again and again. Isn’t that the foundation of what the web is really about?
Accessibility isn’t a movement, it is a standard. The seeds of the standard can grow anywhere, and it simply makes sense for developers to find a spot they’re comfortable with, plant that accessibility seed, and watch it grow into something truly special for everyone. One website at a time is all it takes and eventually that seed will turn the Internet landscape into a lush place with equal access for all. If you think about it, the real job of a web developer is customer service. Let’s get started – carve your path and help pave the way toward web accessibility!