epubjs
Version:
Render ePub documents in the browser, across many devices
56 lines (53 loc) • 4.2 kB
HTML
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
<title>Chapter 2. Building a Better EPUB: Fundamental Accessibility</title>
<link rel="stylesheet" type="text/css" href="css/epub.css" />
<meta name="dat-origPath" value="/html/body/section/section" /><link rel="prev" href="./ch02_8.html" /><link rel="next" href="./ch02_10.html" /></head><body>
<h3 class="title" id="_tables" data-origPath="/html/body/section/section/section[9]/h3">Tables</h3>
<p data-origPath="/html/body/section/section/section[9]/p[1]">The reflowable, paginated nature of ebook reading has fortunately kept tables
from being used for presentational purposes in ebooks. In theory, this
should have been a good thing. The complex nature of tables relative to
limited rendering area of typical reading systems has led to the worse
practice of excluding the data in favor of images of the table, however. How
helpful is a picture of data to someone who cannot see it?</p>
<p data-origPath="/html/body/section/section/section[9]/p[2]">The motivating hope behind this practice seems to be that images will take
away rendering issues on small screens, but don’t fall into this trap. Not
only are you taking the content away from readers who can’t see the table,
but even if you can see the images they often get scaled down to
illegibility and/or burst out the side of the reading area on the devices
that this technique is presumably meant to enhance the tables on (notably
eInk readers that have no zooming functionality).</p>
<p data-origPath="/html/body/section/section/section[9]/p[3]">Consider also what you’re doing when you add a picture: you’re trying to
address a situational disability (the inability to view an entire table at
once) by creating another disability (only limited visual access to the
content). If you properly mark up your data, readers can find ways to
navigate it, whether via synthetic speech or other accessible navigation
mechanisms. Obsessing about appearance is natural, but ask yourself how
realistic a concern it should be when people read on cellphone screens? Give
your readers credit to understand the limitations their devices impose, and
give them the flexibility to find other ways to read.</p>
<p data-origPath="/html/body/section/section/section[9]/p[4]">When it comes to marking up tables, the fundamental advice for making them
accessible from web iterations past remains true:</p>
<ul class="itemizedlist" data-origPath="/html/body/section/section/section[9]/ul">
<li class="listitem"><p> Always use <code class="literal">th</code> elements
for header cells. </p></li>
<li class="listitem"><p> Wrap your header in a <code class="literal">thead</code>, in particular when including multi-row headings.
</p></li>
<li class="listitem"><p> Use the <code class="literal">th</code>
<code class="literal">scope</code> attribute to give the
applicability of the heading (e.g., whether to the row or column).
This attribute is not necessary for simple tables where the first
row of <code class="literal">th</code> elements, or a <code class="literal">th</code> cell at the start of each row, defines
the header(s), however. </p></li>
<li class="listitem"><p> If the header for a cell cannot be easily
determined by its context, and especially when multiple cells in a
multi-row header apply, add the <code class="literal">headers</code>
attribute and point to the appropriate <code class="literal">th</code> element(s). </p></li>
</ul>
<p data-origPath="/html/body/section/section/section[9]/p[5]">These heading requirements allow a person navigating your table to quickly
determine what they’re reading at any given point in it, which is the
biggest challenge that tables pose outside of perhaps escaping from them.
It’s easy to get lost in a sea of numbers, otherwise.</p>
</body>
</html>