epubjs
Version:
Render ePub documents in the browser, across many devices
67 lines (63 loc) • 5.35 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" /><link rel="prev" href="./ch03s04_1.html" /><link rel="next" href="./ch03s05_1.html" /></head><body>
<h2 class="title" id="_a_little_help_wai_aria" data-origPath="/html/body/section/h2">A Little Help: WAI-ARIA</h2>
<p data-origPath="/html/body/section/p[1]">Although fallbacks are useful when scripting is not available, you should still aim
to make your scripted content accessible to all readers. Enter the W3C Web
Accessibility Initiative’s (WAI) <a class="ulink" href="http://www.w3.org/TR/wai-aria/" target="_top">Accessible Rich Internet
Application</a> (ARIA) specification.</p>
<p data-origPath="/html/body/section/p[2]">The technology defined in this specification can be used in many situations to
improve content accessibility. We’ve already encountered the <code class="literal">aria-describedby</code> attribute in looking at how to add descriptions and
summaries, for example.</p>
<p data-origPath="/html/body/section/p[3]">I’m now going to pick out three common cases for scripting to further explore how
ARIA can enhance the accessibility of EPUBs: custom controls, forms, and live
regions.</p>
<h3 class="title" id="_custom_controls" data-origPath="/html/body/section/section[1]/h3">Custom Controls</h3>
<p data-origPath="/html/body/section/section[1]/p[1]">Custom controls are not standard form elements that you stylize to suit your
needs, just to be clear. Those are the good kinds of custom controls—if you want
to call them custom—as they retain their inherent accessibility traits whatever
you style them to look like. Readers will not have problems interacting with
these controls as they natively map to the underlying accessibility APIs, and so
will work regardless of the scripting capabilities any reading system has built
in.</p>
<p data-origPath="/html/body/section/section[1]/p[2]">A custom control is the product of taking an HTML element and enhancing it with
script to emulate a standard control, or building up a number of elements for
the same purpose. Using images to simulate buttons is one of the more common
examples, as custom toolbars are often created in this way. There is typically
no native way for a reader using an accessible device to interact with these
kinds of custom controls, however, as they are presented to them as whatever
HTML element was used in their creation (e.g., just another <code class="literal">img</code> element in the case of image buttons).</p>
<p data-origPath="/html/body/section/section[1]/p[3]">It would be ideal if no one used custom controls, and you should try to avoid
them unless you have no other choice, but the existence of ARIA reflects the
reality that these controls are also ubiquitous. The increase in native control
types in HTML5 holds out hope for a reduction in their use, but it would be
neglectful not to cover some of the basics of their accessible creation. Before
launching out on your own, it’s good to know what you’re getting into.</p>
<aside class="note" title="Note" data-origPath="/html/body/section/section[1]/aside[1]">
<h3 class="title">Note</h3>
<p>There are widely available toolkits, like <a class="ulink" href="http://jquery.com/" target="_top">jQuery</a>, that bake ARIA
accessibility into many of the custom widgets they allow you to create. You
should consider using these if you don’t have a background in creating
accessible controls.</p>
</aside>
<p data-origPath="/html/body/section/section[1]/p[4]">If you aren’t familiar with ARIA, a very quick, high-level introduction for
custom controls is that it provides a map between the new control and the
standard behaviors of the one being emulated (e.g., allowing your
otherwise-inaccessible image to function identically to the <code class="literal">button</code> element as far as the reader is concerned).
This mapping is critical, as it’s what allows the reader to interact with your
controls through the underlying accessibility API. (The ARIA specification
includes a <a class="ulink" href="http://www.w3.org/TR/wai-aria/introduction#contractmodel" target="_top">graphical depiction</a> that can help visualize this
process.)</p>
<p data-origPath="/html/body/section/section[1]/p[5]">Or, put differently, ARIA is what allows the HTML element you use as a control to
be identified as what it represents (button) instead of what it is (image). It
also provides a set of attributes that can be set and controlled by script to
make interaction with the control accessible to all. As the reader manipulates
your now-identifiable control, the changes you make to these attributes in
response get passed back to the underlying accessibility API. That in turn
allows the reading system or assistive technology to relay the new state on to
the reader, completing the cycle of interaction.</p>
</body>
</html>