Most publishers now realize how important it is to make their publications accessible. The question is no longer the “why,” but the “how.” This presentation is designed to show you how. Originally presented during a webinar on April 4, noted expert Bill Kasdorf discusses practical advice for book and journal publishers to create "born accessible" publications. View the webinar here: http://apexcovantage.com/accessible-publishing-webinar/ Contact Apex: http://apexcovantage.com/contact/

1. Bill Kasdorf
Principal, Kasdorf &Associates, LLC
W3C Publishing WG, Business Group, EPUB 3 CG,
and PWGAccessibility Task Force
What You Need to Know
To Get Accessibility Right

2. Bill Kasdorf
Principal, Kasdorf &Associates, LLC
W3C Publishing WG, Business Group, EPUB 3 CG,
and PWGAccessibility Task Force
What You Need to Know
To Get Accessibility Right
You don’t necessarily need to DO
these things—but you need to know if
your vendors are getting them right.

3. Accessibility is way easier
than it used to be.

4. Accessibility is way easier
than it used to be.
It’s based on Web standards.
The Open Web Platform (OWP)
is fundamental.
WCAG (Web Content Accessibility Guidelines)
provides the foundation for accessibility.
WAI-ARIA (Web Accessibility Initiative
Accessible Rich Internet Applications)
provides semantics for assistive technology (AT).

5. Accessibility is way easier
than it used to be.
It’s based on Web standards.
The proper file formats are now
ones we already use anyway.
The DAISY Consortium now recommends EPUB 3
(and its constituent resources like
HTML audio and video, JavaScript, etc.)
as the proper format for interchange of
accessible publications.
EPUB 3 is based on the Open Web Platform.

6. Accessibility is way easier
than it used to be.
It’s based on Web standards.
The proper file formats are now
ones we already use anyway.
The DAISY Consortium now recommends EPUB 3
(and its constituent resources like
HTML audio and video, JavaScript, etc.)
as the proper format for interchange of
accessible publications.
EPUB 3 is based on the Open Web Platform.
EPUB Accessibility 1.0
is now the baseline specification
for accessible publications.
This presentation is focused on
how to meet that specification.

7. Accessibility is way easier
than it used to be.
It’s based on Web standards.
The proper file formats are now
ones we already use anyway.
The markup is no longer
a specialized, arcane syntax;
it’s tagging we already know how to do.
HTML 5 provides the structural semantic foundation;
WAI-ARIA augments it for web accessibility;
DPUB-ARIA adds publication-specific terms.

8. Accessibility is way easier
than it used to be.
It’s based on Web standards.
The proper file formats are now
ones we already use anyway.
The markup is no longer
a specialized, arcane syntax;
it’s tagging we already know how to do.
Requirements are more globally aligned.
E.g., the US Section 508 Refresh is aligned
with emerging EU accessibility requirements.

9. If accessibility has
gotten so much easier,
then why is it still
so darn hard?

10. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.

11. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.

12. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.
And what the heck is ARIA, anyway?

13. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.
And what the heck is ARIA, anyway?
We don’t know how to do good image descriptions.

14. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.
And what the heck is ARIA, anyway?
We don’t know how to do good image descriptions.
Math and tables are a pain!

15. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.
And what the heck is ARIA, anyway?
We don’t know how to do good image descriptions.
Math and tables are a pain!
We don’t know how to make media accessible.

16. Because our workflows
aren’t designed for accessibility.
We have to “remediate” print-based files.
We use HTML,
but we don’t always use it correctly.
And what the heck is ARIA, anyway?
We don’t know how to do good image descriptions.
Math and tables are a pain!
We don’t know how to make media accessible.
Accessibility metadata? What’s that?

17. But I thought
HTML 5 and EPUB 3
guaranteed
accessibility!

18. Nope.
HTML 5 and EPUB 3 guarantee
ACCESSIBILITYABILITY.
They guarantee
the ability to be accessible.
You have to use them properly.

19. This isn’t rocket science.
You (and your partners) can do it.
That’s why we’re here.

20. Markup
Start by getting the markup right.
Use HTML’s inherent structural semantics:
<section>s, <aside>s, <h1>–<h6>, etc.
Modify them withARIAand DPUB-ARIAattributes
to make distinctions that benefit accessibility.
Assistive technology (AT) depends on these
to properly deliver the content and enable the user
to navigate, skip, go back, etc. efficiently.

21. What not to do:
<div class="chaptitle">CHAPTER TITLE</div>
<div class="noindent1">First paragraph . . .</div>
<div class="indent">Second paragraph . . .</div> . . .
<div class="head1">First-level subhead</div>
<div class="noindent1">First paragraph after subhead . . .</div>
<div class="image">
<img src="images/p031-001.png" alt="Image" /></div>
<div class="caption" id="fig-1-1">Text of caption . . .</div>
<div class="indent1">Some other kind of paragraph . . . </div>
The tagging is real.
The text has been changed to protect the guilty.

22. What not to do:
<div class="chaptitle">CHAPTER TITLE></div>
<div class="noindent1">First paragraph . . .</div>
<div class="indent">Second paragraph . . .</div> . . .
<div class="head1">First-level subhead</div>
<div class="noindent1">First paragraph after subhead . . .</div>
<div class="image">
<img src="images/p031-001.png" alt="Image" /></div>
<div class="caption" id="fig-1-1">Text of caption . . .</div>
<div class="indent1">Some other kind of paragraph . . . </div>
The tagging is real.
The text has been changed to protect the guilty.
The structural
semantics
inherent in
HTML 5 —
which assistive
technology
depends on —
have been
completely
under mined.

23. What not to do:
<div class="chaptitle">CHAPTER TITLE</div>
<div class="noindent1">First paragraph . . .</div>
<div class="indent">Second paragraph . . .</div> . . .
<div class="head1">First-level subhead</div>
<div class="noindent1">First paragraph after subhead . . .</div>
<div class="image">
<img src="images/p031-001.png" alt="Image" /></div>
<div class="caption" id="fig-1-1">Text of caption . . .</div>
<div class="indent1">Some other kind of paragraph . . . </div>
The tagging is real.
The text has been changed to protect the guilty.
AARGH!!
This is
just plain
cheating!

24. Better—and just standard HTML:
<section>
<h1 class="chaptitle">CHAPTER TITLE</h1>
<p>First paragraph . . .</p>
<p>Second paragraph . . .</p> . . .
<section>
<h2 class="subhead1">First-level subhead</h2>
<p>First paragraph after subhead . . .</p>
<figure>
<img src="images/p031-001.png" alt="[description]" /></img>
<figcaption>Text of caption . . .</figcaption>
</figure>
. . .
</section>
</section>
Totally simple—and assistive technology
would handle this reasonably well.

25. WAI-ARIA
(WebAccessibility Initiative–Accessible Rich InternetApplications)
ARIAprovides additional structural semantics
to supplement the inherent semantics in HTML.
DPUB-ARIAadds publication-specific terms
like “doc-chapter” and “doc-footnote.”
These enable assistive technology (AT)
to properly deliver the content and enable the user
to understand the components of the publication
and interact with them appropriately.

26. Even better—with ARIA to guide AT:
<section role="doc-chapter" aria-labelledby="hd01">
<h1 class="chaptitle" id="hd01">CHAPTER TITLE</h1>
<p>First paragraph . . .</p>
<p>Second paragraph . . .</p> . . .
<section aria-labelledby="hd02">
<h2 class="subhead1" id="hd02">First-level subhead</h2>
<p>First paragraph after subhead . . .</p>
<figure>
<img src="images/p031-001.png" alt="[description]" /></img>
<figcaption>Text of caption . . .</figcaption>
</figure>
. . .
</section>
</section>
Don’t overdo it—keep in mind what the
user needs (and doesn’t need!)

27. Navigation
Publications can be hard to navigate.
HTML markup provides the logical reading order
within an HTML document (e.g., a chapter).
The EPUB Navigation Document provides navigation
between and within documents via <nav> elements:
the TOC <nav> (chapters & sections);
the Landmarks <nav> (important features);
the Page-List <nav> (corresponding print page breaks).

28. Navigation
Publications can be hard to navigate.
HTML markup provides logical reading order
within an HTML document (e.g., a chapter).
The EPUB Navigation Document provides navigation
between and within documents via <nav> elements:
the TOC <nav> (chapters & sections);
the Landmarks <nav> (important features);
the Page-List <nav> (corresponding print page breaks).
Standard EPUB 3 —You probably already do this.

29. Navigation
Publications can be hard to navigate.
HTML markup provides logical reading order
within an HTML document (e.g., a chapter).
The EPUB Navigation Document provides navigation
between and within documents via <nav> elements:
the TOC <nav> (chapters & sections);
the Landmarks <nav> (important features);
the Page-List <nav> (corresponding print page breaks).
Only if needed —You may not have such features.

30. Navigation
Publications can be hard to navigate.
HTML markup provides logical reading order
within an HTML document (e.g., a chapter).
The EPUB Navigation Document provides navigation
between and within documents via <nav> elements:
the TOC <nav> (chapters & sections);
the Landmarks <nav> (important features);
the Page-List <nav> (corresponding print page breaks).
Users of AT really want this!

31. Page breaks?
You gotta be kidding!
That’s so 20th Century!

32. Yes, page breaks.
When there’s a corresponding print version,
users of AT really want page break markers.
Think cross-references, citations, indexes.
Print-disabled students need page breaks.
“Class, turn to page 52.”
“Today’s assignment: Chapter 3, pages 48–64.”
“See diagram on page 183.”
Pagebreak markers are just empty elements:
<span id="pg14" role="doc-pagebreak" title="4"/>
. . . referenced by the <nav role="doc-pagelist">

33. You need to make links accessible too.
Don’t just do this or here.
Make sure the content of the link
tells what’s being linked to.
“The baseline standard is EPUB Accessibility 1.0.”
Instead of “See a full explanation here,”
do “See this full explanation.”

34. Okay, so far so good.
None of that sounds hard.
But what about
math and tables?

35. Math and Tables
Math and tables are hard.
But you may be closer
to having something useful
than you realize.

36. Math should be MathML.
Virtually all equations in STM publications
are MathML at some stage of
the editorial and production workflow.
Prepress vendors almost all use MathML
as the master equation format in their workflows.
The MathML doesn’t get into EPUBs
because Reading Systems mess it up.
Don’t throw away that MathML!
Provide it for accessibility!
(Work is underway to develop a best practice.)

37. And here’s a little-realized secret:
MS Word equations are MathML
under the hood.
The Word Equation Editor
actually produces fairly good MathML
in recent versions of Word.

38. MS Word equations are MathML
under the hood.
InDesign workflows can use MathType
which can generate MathML.
These may not be perfect MathML,
but don’t let the perfect
be the enemy of the good.

39. The Benetech DIAGRAM Center’s
MathML Cloud
converts AsciiMath, MathML, and LaTeX
and creates .png and .svg images
and textual descriptions of equations.
It’s free and open source,
interactive or batch.

40. Tables should be HTML tables
with headers on both rows and columns.
Use <th scope="row"> and <th scope="col">.
Assistive technology reads tables
left-to-right and top-to-bottom
and can navigate by Row + Column > Cell.
Avoid merged cells and blank cells.
Because published tables often have these features,
remediation for AT has to fix them by hand.
Think about how your table will be read
to somebody who can’t see it!

41. Image Descriptions
And now for the fun part:
image descriptions!

42. And now for the fun part:
image descriptions!
Looking at this image,
you’re probably thinking
“good luck describing that!”

43. And now for the fun part:
image descriptions!
Looking at this image,
you’re probably thinking
“good luck describing that!”
Here’s the proper alt text:
alt=""

44. And now for the fun part:
image descriptions!
Looking at this image,
you’re probably thinking
“good luck describing that!”
Here’s the proper alt text:
alt=""
<img src="graphics/proposal.jpg" role="presentation" alt=""/>

45. Knowing when not to do alt text is key.
When the image is merely decorative.
When the caption sufficiently describes it.
When the surrounding text sufficiently describes it.

46. Most images do need alt text.
Common bad practices:
alt="" or alt="image" just to be “legal HTML.”
alt="[filename]" or alt="[figure number]".
alt="[the text of the caption]".
alt="bar chart".
Remember: the alt text is going to be
read to the user! It’s supposed to be helpful!
And don’t forget text provided as an image
(e.g., title pages, part and chapter titles).

47. And what does “describes it” mean?
It’s more about the purpose, not the appearance.
Yes, you need to describe what it’s an image of,
but most important is what matters about it,
what that image is there to convey.
This can involve more than one person.
The author or a subject matter expert.
An editor or copyeditor.
Somebody who understands
the needs of a print disabled person.
Which is why this can get messy, and loopy.

48. This is ultimately a workflow issue.
A lot depends on the kind of image—
photo, graph, diagram, flow chart, map, etc.—
and the kind of publication it’s in.
For scholarly/STM content, start with the author.
She knows why she included that image,
and the audience is mostly scholars like her.
Trade book authors often don’t specify the images.
An editor will be the best person to describe them.
In education, the images have a pedagogical purpose.
And they always need to be copyedited!

49. Metadata
Accessibility metadata is easy.
It’s how you document
the accessibility of a publication.
It goes in the publication file
and online as well, as schema.org.

50. It documents the nature of the accessibility.
accessMode (textual, visual, auditory, tactile).
accessibilityFeature (what features does it have).
accessibilityHazard (e.g., flashing can cause seizures).
accessibilitySummary (human-readable explanation).
accessModeSufficient (e.g. text + alt text = textual).
It documents categories of compliance.
“Discovery-Enabled”: Just the above metadata,
even if it doesn’t meet EPUB Accessibility 1.0.
“Accessible”: MD + WCAG 2.0 + EPUB requirements.
“Optimized”: Metadata + specific features.

51. Media
EPUBs can include audiovisual content.
The focus in this presentation
is on the publication.
But remember that the media player itself
should be accessible!

52. Media
Audio
Use HTML <audio> and include a transcript.
EPUB provides “Media Overlays”
to synchronize text and audio (e.g., “read aloud”).
Video
Use HTML <video> and include captioning.
Also include an audio description
that describes what is being shown on the screen.

53. Testing
After all this,
how do you know if you’ve got it right?
The two key, authoritative services:
Ace by DAISY
Benetech Global Certified Accessible

54. How do you know if you’ve got it right?
Ace by DAISY
A free, open source, automated, lightning-fast
EPUB accessibility checking tool.
Produces a highly detailed report of how well
a host of features conform to EPUB Accessibility 1.0,
along with locations and snippets for each issue
and links to the DAISY Knowledge Base
for clear explanations of the relevant
specifications and best practices.
Subjective evaluation still needs to be done!

55. How do you know if you’re doing it right?
Benetech Global Certified Accessible
Expert, authoritative, in-depth analysis of
representative EPUBs from a publisher’s workflow.
Produces a detailed report and recommendations
and reviews results after the workflow is updated.
A subscription-based service with two aspects:
accreditation of the workflow, which grants the publisher
a one-year renewable license to certify the publications.
The goal: preference or requirement
by purchasers and procurement offices.

56. STANDARDS AND RECOMMENDATIONS
HTML: https://www.w3.org/TR/html/
WCAG 2.1: https://www.w3.org/TR/WCAG21/
WAI-ARIA 1.1: https://www.w3.org/TR/wai-aria-1.1/
DPUB-ARIA 1.0: https://www.w3.org/TR/2017/REC-dpub-aria-1.0-20171214/
ARIA in HTML: https://www.w3.org/TR/html-aria/
EPUB Accessibility 1.0: https://www.w3.org/Submission/2017/SUBM-epub-a11y-20170125/
RESOURCES
DAISY Knowledge Base: http://kb.daisy.org/publishing/
BISG Guide: https://bisg.site-ym.com/store/ViewProduct.aspx?id=6972996
Inclusive Publishing: https://inclusivepublishing.org/
Benetech DIAGRAM Center: http://diagramcenter.org/
MathML Cloud: https://mathmlcloud.org/
Image description resources: http://diagramcenter.org/making-images-accessible.html
Metadata: https://www.w3.org/Submission/2017/SUBM-epub-a11y-20170125/#sec-disc-package
TESTING AND CERTIFICATION
DAISYAce Checking Tool: https://inclusivepublishing.org/toolbox/accessibility-checker/
Benetech Certified Accessible: https://benetech.org/our-work/born-accessible/certification/
Resources

57. Thanks!
Bill Kasdorf
kasdorf.bill@gmail.com
+1 734 904 6252
@BillKasdorf