Video

Want to see the full-length video right now for free?

Sign In with GitHub for Free Access

Notes

Introduction

Accessibility is an important but oft-overlooked aspect of web design and development. Many think accessibility is only about supporting blind users with screen readers, but in fact it encompasses many different disabilities including:

  • Visual Impairments like colorblindness - can be impacted by low contrast design choices
  • Motor limitations - for some users, the mouse is difficult or impossible to use and they rely on keyboard navigation or similar techniques to interact with the web.
  • Cognitive Disabilities - Complex layouts, use of placeholder text rather than labels, and similar techniques can make it difficult to understand and interact with a web app.

Derek was first inspired to explore accessibility after seeing a RailsConf Talk about Accessibility by Chandra Carney.

Another great resource for diving into accessibility is the A11Y Project. They collect a ton of great documentation and articles around what exactly accessibility is, and how you can improve it in your own code.

Objections

Common objections against focusing time and effort on accessibility include "We don't have blind users." and "We don't have time for that right now." At the end of the day, Accessibility is Usability, and efforts to improve the accessibility of your app will almost certainly improve the experience for all users.

Twitteriffic recently shared a graphic displaying the relative sales numbers and of particular interest was that the largest spike in sales came when they were featured on the App Store for excellent accessibility. Clearly there is a large audience with an interest in apps with good accessibility.

Likewise, a slightly more extreme point is the example of Target recently settling a class action lawsuit for $6M over accessibility issues. While we shouldn't need to use the threat of legal action to inspire work towards better accessibility, this is none the less a good data point to have if you end up having to defend accessibility work.

How do I do it?

At its core, accessibility is about clean, semantic markup. Screen readers and other assistive technology do a great job of hooking into your existing markup, so long as that markup clearly defines your content. Some specific things to look out for:

  • Semantics. Clean, semantic markup is your base. Use <nav>, <article>, and other semantic elements over <div>s.
  • Alt attributes on images.
  • Proper table markup for tabular data (<thead>, <th>, <tbody>, etc).
  • Label tags on your forms! Placeholders are not labels.
  • Sparing use of animation and autoplaying video.
  • Excellent keyboard navigation via tab key: don't mess with tab order.
  • Allow "focus" to be properly styled, don't let CSS resets hide focus styling.

Tools and Code

tota11y

tot11y is an accessibility auditing tool made by Khan Academy. Available as a browser plugin or bookmarklet, it scans the current page and presents a menu summarizing various accessibility audits. It also offers recommendations on how to improve accessibility shortfalls within the page.

It scans for issues related to the headings / document outline, color contrast, link text, labels, and others. In all cases it summarizes the issue, but in some cases, e.g. color contrast, it can even dynamically make the change in the document so you can preview it live.

ARIA Labels

ARIA (Assistive Rich Internet Applications) is a set of attributes you can apply to your markup to further clarify its semantics. As much as possible we want to use the document structure to define semantics, but in some cases we may want to add hints for assistive technology. ARIA lets us do this.

For example, we can use ARIA roles to identify the "main" content of a page since there is no <main> element we can use:

<div role="main">
  <!-- main content here... -->
</div>

OS X VoiceOver

Screen readers are a tool that allow disabled users to have the contents of an application or web page read to them, and provide keyboard shortcuts to interact with a document. On OS X, VoiceOver is the builtin screen reader, although similar tools are available for all OSes.

To activate VoiceOver, press Command-F5. When you first turn it on it will offer to walk your through some of the other features. In addition, you can press Ctrl-Option-a to bring up the Landmark navigation menu to get a sense of how screen reader users will navigate your site. This is something all developers should try at least once to get a sense of how some of their users interact with the sites they are building.

Conclusion

Accessibility is something that many of us, Derek and I included, have generally overlooked. Luckily, it turns out that it doesn't take much effort to vastly improve and maintain the accessibility of our web apps. Hopefully this video has given you a sufficient introduction and enough pointers to get you aboard the accessibility train.

For inspiration, you can check out some recent accessibility work done by Derek and other thoughtbotters: