This video is only a short sample, but you can access the full version and all our other great content by subscribing.Subscribe Now
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:
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.
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.
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:
<article>, and other semantic elements over
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 (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>
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
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: