epubjs
Version:
Render ePub documents in the browser, across many devices
58 lines (55 loc) • 4.08 kB
HTML
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>A Little Help: WAI-ARIA</title>
<link rel="stylesheet" type="text/css" href="css/epub.css" />
<meta name="dat-origPath" value="/html/body/section/section[1]" /><link rel="prev" href="./ch03s05_1.html" /><link rel="next" href="./ch03s05_3.html" /></head><body>
<aside class="note" title="Note" data-origPath="/html/body/section/section[1]/aside[3]">
<h3 class="title">Note</h3>
<p>To see which properties and states are supported by the type of control
you’re creating, refer to the <a class="ulink" href="http://www.w3.org/TR/wai-aria/roles#role_definitions" target="_top">role definitions</a> in the specification. Knowing what
you can apply is helpful in narrowing down what you need to apply.</p>
</aside>
<p data-origPath="/html/body/section/section[1]/p[15]">If you don’t set the states and properties, or set them incorrectly, it follows
that you’ll impair the ability of the reader to access your content.
Implementing them badly can be just as frustrating for a reader as not
implementing them at all, too. You could, for example, leave the reader unable
to start your audio clip, unable to stop it, stuck with volume controls that
only go louder or softer, etc. Their only recourse will be shutting down their
ebook and starting over.</p>
<p data-origPath="/html/body/section/section[1]/p[16]">These are the accessibility pitfalls you have to be aware of when you roll your
own solutions. Some will be obvious, like a button failing to initiate playback,
but others will be more subtle and not caught without extensive testing, which
is also why you should engage the accessibility community in checking your
content.</p>
<p data-origPath="/html/body/section/section[1]/p[17]">But let’s take a look at some of the possible issues involved in maintaining
states. Have a look at the following much-reduced example of list items used to
control volume:</p>
<pre class="screen" data-origPath="/html/body/section/section[1]/pre[2]"><ul>
<li role="button"
tabindex="0"
onclick="increaseVolume('audio01')">Louder</li>
<li role="button"
tabindex="0"
onclick="decreaseVolume('audio01')">Softer</li>
</ul></pre>
<p data-origPath="/html/body/section/section[1]/p[18]">This setup looks simple, as it omits any states or properties at the outset, but
now let’s consider it in the context of a real-world usage scenario. As the
reader increases the volume, you’ll naturally be checking whether the peak has
been reached in order to disable the control. With a standard button, when the
reader reached the maximum volume you’d just set the button to be disabled with
a line of JavaScript; the button gets grayed out for readers and is marked as
disabled for the accessibility API. Nice and simple.</p>
<p data-origPath="/html/body/section/section[1]/p[19]">List items can’t be natively disabled, however (it just doesn’t make any sense,
since they aren’t expected to be active in the first place). You instead have to
set the <code class="literal">aria-disabled</code> attribute on the list item to
identify the change to the accessibility API, remove the event that calls the
JavaScript (as anyone could still activate and fire the referenced code if you
don’t), and give sighted readers a visual effect to indicate that the button is
no longer active.</p>
<p data-origPath="/html/body/section/section[1]/p[20]">Likewise, when the reader decreases the volume from the max setting, you need to
re-enable the control, re-add the <code class="literal">onclick</code> event,
and re-style the option as active. The same scenario plays out when the reader
hits the bottom of the range for the volume decrease button.</p>
</body>
</html>