How Thinking About Accessibility Can Lead to Success

Just over two years ago, I wrote a blog post about accessibility basics, where I introduced readers to accessibility APIs from a 30,000 foot view. Near the end, I proclaimed that WebDevStudios is “committed to building accessible websites.” Internally, an effort to make our starter theme, wd_s, pass both Section 508 and WCAG 2.0AA standards began.

Since then, WebDevStudios has kept that promise. When we ship a website to a client, it passes all sorts of accessibility tests, as well as HTML and CSS validation. When a potential client asks us to provide examples of accessible websites that we have built, it’s easy to oblige. More often than not, that leads to a sale.

While impressing clients and acquiring a new project are good reasons to build an accessible website, the reality is that over 285 million people worldwide have visual impairments… which is almost the population of the United States! Thinking about accessibility is just the right thing to do.

Four Basic Principles

Make no mistake, accessibility is hard. So where should you start? To keep from getting overwhelmed, take a cue from Foundation by Zurb and follow four basic principles:

1) Structure your document properly

Modern web browsers can do a lot of the heavy lifting… if you write semantic HTML.

1. Use <button> instead of making <a>, <div> and <spans> look like buttons.
2. Use headings <h1> – <h6> to help provide both structure and context to screen readers.
3. Steer clear of “enhanced” form field plugins. Ask yourself, “Is it really worth having a pretty dropdown, when it is completely unusable by 285 million people?”
4. Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
5. Read more about “How Writing Semantic HTML Can Help Accessibility” by Jeffrey de Wit.

2) <label> everything

For 285 million people, a screen reader is the only way to “view” a website. When it’s read back to them… does your website makes sense?

1. Make sure form fields have a <label>. It is OK to hide labels with CSS: <label class="sr-only">
2. Using <fieldset> and <legend> to group related form elements.
3. Provide descriptive alt attributes on images: <img alt="A hen Mallard landing on a pond"> vs <img alt="mallard_duck-1.jpg">
4. Read more about “Labeling Controls” from w3.org.

3) Don’t rely on purely visual cues

If a page is being read to a user by a screen reader, it may not be obvious what the user is supposed to do next.

1. Make sure call to actions have labels that can be read by a screen reader.
2. Do call to actions meet a minimum contrast ratio? Meaning, can this person actually see/read it? Make sure the contrast ratio (on everything from text to buttons) is at least 1:4.5 for normal text and 3:1 for headings.

4) Make everything usable on a keyboard, mouse, and touch screen

1. Make sure you can use the tab, spacebar, and arrow keys to navigate a web page.
2. Give users the option to skip around a page.
3. Complex components such as sliders or modals should be tested with arrow and esc keys.

Tools Can Help

These accessibility testing tools can help, by pointing out areas of your web page that need work.

• Tenon.io – Will check your website against Section 508 and WCAG 2.0, and provide recommended fixes.
• WAVE – Similarly, WAVE can test your website against accessibility standards and even display contrast issues.
• Total Validator – Available for Windows and MacOS, this tool can test entire websites against a wide range of validation tests.

Conclusion

By thinking about and ultimately acting on these principles during the entire life cycle of a project, from scoping to design, development, and QA, not only will you be making your website usable by those with disabilities, you will be doing the right thing. This will come with many other benefits including: long-term maintainable code, SEO juice, and that feeling deep down when you do something nice for someone else. In my book, it doesn’t get more successful than that.

Further Reading