WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Captions and Alt-text

for

From: Chagnon | PubCom
Date: Mar 4, 2013 12:03PM

I've had a few responses to this problem directly from some list members, so
let me describe the problem with more detail for everyone.

Short demonstration:
The document has 2 paragraphs of body text, with a sidebar (boxed text in a
separate frame) anchored in between the 2 body text paragraphs.

Note that I'm using "sidebar" as the example here, but this applies to
anything in InDesign that requires a separate text frame, such as a small
photo caption, a long caption on a complex statistical graphic, pull quotes,
accessory text, or anything else that's not part of the full body text
story.

The final good code should look like this (I'm leaving out closing tags for
simplicity):
<root>
<sect>
<p>This is the first paragraph of body text.
<sect>
<h2>This is the heading of the sidebar.
<p>This is the sidebar text.

<p>This is the second paragraph of body text.

Instead, here's what is generated from InDesign:
<root>
<sect>
<p>This is the first paragraph of body text.
<sect>PathThis is the heading of the sidebar.This is
the sidebar text.

<p>This is the second paragraph of body text.

Essentially, everything inside the anchored sidebar is jumbled together
inside a <sect>/<section> tag and the individual tags for <h2> and <p> are
lost, as well as the concept of individual paragraphs of text that a user
would need to navigate the content.

In a PDF, the portion you see above in the demo - <sect>PathThis is the
heading of the sidebar.This is the sidebar text. - usually can't be accessed
by AT, so many AT users won't even know it exists.

Plus, <sect> tags are parent-level tags for organizing the content, not
intended to hold the actual live content. So this is a misuse of <sect>
tags.

For those using InDesign, this affects versions CS 5.5 and CS 6 (earlier
versions of InDesign do not have the tools needed to create accessible
documents).

We were told that Adobe's InDesign engineers would be addressing this
problem, but that was 1.5 to 2 years ago and still nothing.

This is not a small issue for graphic designers, and is preventing many
publications from being fully Section 508 compliant and accessible.

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New schedule for classes and workshops coming in 2013.

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Becher, Jed
(MNIT)
Sent: Monday, March 04, 2013 11:28 AM
To: <EMAIL REMOVED>
Subject: [WebAIM] Captions and Alt-text

Which version of InDesign was this for? CS6 or CS5?
So I'm to understand there is no good way to deal with this 300 page monster
other than the two options below and then a massive amount of fix it work in
Acrobat?
So which method is the lesser of two evils as far as document remediation
goes in Acrobat? #1 or #2
Still learning all the ins and outs of these processes.

Thank you.
Jed Becher
Minnesota DNR

> -----Original Message-----
> From: <EMAIL REMOVED> [mailto:webaim-forum-
> Unless you are proficient in InDesign, especially with long documents,
> it is difficult to see what happens when the PDF is exported from
InDesign.
> It's entirely based on how InDesign was programmed to convert the
> pieces that create the laid out page into structured tags in the PDF.
> Let me try to describe what happens.
>
> This is a 300 page book. The body text is one continuous 300-page long
> story. A photo and a caption will be on each page, and each one is a
> separate computer object.
>
> Therefore each page of the book will hold a portion of the body text
> story and its related photo and caption.
>
> InDesign Method #1: Anchored photos and caption boxes.
>
> InDesign has a new tool that lets designers anchor the photo and
> caption box into the main body text. The theory is that this tool
> would drop the correct figure tag and caption tag where they belong in
> the main body text tag structure.
> That would be nice if it worked. But it doesn't, not completely. Here
> is what you get in the exported PDF:
> 1. Photo alone = good, creates the figure tag and places it where it

> belongs in the structure.
> 2. Text box alone = broken, creates a gibberish tag that's not
readable.
> 3. Photo and text together in a box = broken, creates a gibberish
tag.
> 4. Grouped items = broken, creates a gibberish tag.
>
> InDesign Method #2: Don't anchor the photos and caption boxes.
>
> With this method, the photos and caption boxes are still placed on
> each page but are not anchored into the text. They export with the
> correct tags in the PDF, but they are ganged at the end of the main
> story. With this 300 page book, that means the AT user will see the
content in this order:
> 1. Page 1's body text.
> 2. Page 2's body text.
> Etc. to 300. Page 300's body text.
> 301. Page 1's figure tag.
> 302. Page 1's caption tag.
> 303. Page 2's figure tag.
> And so on.
>
> They, by hand in Acrobat, we would move each photo and caption from
> the end of the tag structure to where it belongs up front on its
> related page. Do that for
> 300 individual photos and 300 individual captions.
>
> The labor - and cost to the federal government and its taxpayers - is
> mind blowing.
>
> Those of you who have had the thrilling experience of moving tags in a
> PDF file to correct the tag structure can image how much my team here
> is looking forward to this project.
>
> If only Adobe could fix the export of anchored and grouped objects
> from InDesign to a tagged PDF we'd be much happier. Gee, all of us
> taxpayers would be happier, too!
>
> -Bevi
> - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
> www.PubCom.com - Trainers, Consultants, Designers, Developers.
> Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
> New schedule for classes and workshops coming in 2013.
>
> -----Original Message-----
> From: <EMAIL REMOVED>
>
> Bevi,
>
> > But this project was laid out in Adobe InDesign, which has a tragic
> > shortcoming: items that are placed inside separate text frames (like
> > captions) do not get tagged correctly in the exported PDF, so we end
> > up fixing the tags by hand in Acrobat.
>
> One of many many many shortcomings. yes. You'd think that InDesign
> would do a good job given that it's developed by the same company that
> invented PDF, but...
>
> > Doing this for 300+ photos would be several days' worth of work.
> >
> > So I'm wondering if this workaround would really work for AT users:
> >
> > 1) Copy the caption text into the Alt-Text tag, and
> >
> > 2) Artifact the caption itself so that AT-users don't voice it
twice.
>
> This approach isn't great because some kinds of AT won't handle such a
> workaround very well - magnifiers (that use tags) won't see the
> caption, for example.
>
> Do the captions not follow directly after the photos in the structure
tree?
> If they do, then why wouldn't your originally proposed approach be
acceptable?
>
> Duff Johnson
>
> Independent Consultant
> ISO 32000 Intl. Project Co-Leader, US Chairman ISO 14289 US Chairman
> PDF Association Vice-Chairman
>
> +1 617 283 4226
> <EMAIL REMOVED>
> http://duff-johnson.com
>
> > > list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>


messages to <EMAIL REMOVED>