epubjs
Version:
Render ePub documents in the browser, across many devices
50 lines (46 loc) • 3.87 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" /><link rel="prev" href="./ch03s05_5.html" /><link rel="next" href="./ch03s05_7.html" /></head><body>
<h3 class="title" id="_live_regions" data-origPath="/html/body/section/section[3]/h3">Live Regions</h3>
<p data-origPath="/html/body/section/section[3]/p[1]">Although manipulating the prose in your ebook by script is forbidden, it doesn’t
mean you can’t dynamically insert or modify any text. Automatically displaying
the result of a quiz or displaying the result of a calculation are a just a
couple of examples of cases where dynamic prose updates would legitimately be
useful for readers. You may also want to provide informative updates, such as
the number of characters remaining in an entry field.</p>
<p data-origPath="/html/body/section/section[3]/p[2]">The problem with these kinds of dynamic updates is how they’re made available to
readers using accessible technologies. When you update the main document by
re-writing the inner text or html of an element, how that change gets reported
to the accessible technology, if at all, is out of your control in plain old
HTML.</p>
<p data-origPath="/html/body/section/section[3]/p[3]">The update could force the reader to lose their place and listen to the changed
region every time, or it could be ignored entirely. ARIA has solved this problem
with the introduction of live regions, however.</p>
<p data-origPath="/html/body/section/section[3]/p[4]">If you’re going to use an element to insert dynamic text, you mark this purpose
by attaching an <code class="literal">aria-live</code> attribute to it. The
value of this attribute also tells an assistive technology how to present the
update to the reader. If you set the value <code class="literal">polite</code>,
for example, the assistive technology will wait until an idle period before
announcing the change (e.g., after the user is done typing for character
counts). If you set it to <code class="literal">assertive</code>, the reading
system will announce the change immediately (e.g., for results that the reader
is waiting on).</p>
<p data-origPath="/html/body/section/section[3]/p[5]">You could set up a simple element to write results to with no more code than
follows:</p>
<pre class="screen" data-origPath="/html/body/section/section[3]/pre[1]"><div id="result" aria-live="assertive"/></pre>
<p data-origPath="/html/body/section/section[3]/p[6]">Now when you write using the <code class="literal">innerHTML</code> property, the
new text will be read out immediately. Be careful when using the <code class="literal">assertive</code> setting, however. You can annoy your
readers if their system blurts out every inconsequential change you might happen
to write as it happens.</p>
<p data-origPath="/html/body/section/section[3]/p[7]">If you write out results a bit at a time, or need to update different elements
within the region, the <code class="literal">aria-busy</code> attribute should
be set to <code class="literal">true</code> before the first write to indicate
to the reading system that the update is in progress. If you don’t, the reading
system will announce the changes as you write them. So long as the state is
marked as busy (<code class="literal">true</code>), however, the reading system
will wait for the state to be changed backed to <code class="literal">false</code> before making any announcement.</p>
</body>
</html>