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.
<button>instead of making
<spans>look like buttons.
- Use headings
<h6>to help provide both structure and context to screen readers.
- 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?”
- Use WAI-ARIA to help provide additional semantics to describe role, state, and properties.
- 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?
- Make sure form fields have a
<label>. It is OK to hide labels with CSS:
<legend>to group related form elements.
- Provide descriptive
altattributes on images:
<img alt="A hen Mallard landing on a pond">vs
- 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.
- Make sure call to actions have labels that can be read by a screen reader.
- 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.5for normal text and
4) Make everything usable on a keyboard, mouse, and touch screen
- Make sure you can use the
arrowkeys to navigate a web page.
- Give users the option to skip around a page.
- Complex components such as sliders or modals should be tested with
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.
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.
- MDN – Learning accessibility
- WebAIM – Training, assistance, certification, and testing
- WordPress Accessibility Code Standards – The WordPress A11y Team
- Accessibility APIs – A key to web accessibility
Also published on Medium.