E-mail List Archives
Thread: Captions and Alt-text
Number of posts in this thread: 6 (In chronological order)
From: Chagnon | PubCom
Date: Thu, Feb 28 2013 2:06PM
Subject: Captions and Alt-text
No previous message | Next message →
We've discussed Captions versus Alt-text before on the list and generally I
agree that the 2 should be different. Captions can say anything that the
author wants to say and not necessarily describe the action in or purpose of
the graphic itself. Alt-text describes the action depicted in the graphic.
We have a client's 500+ page reference guide with 300+ photos of specimens.
Their formal captions are technical and describe each specimen.
Normally we would have very simple Alt-text like "Photo, ABC specimen." And
let the caption do its job of describing the details.
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.
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.
Thanks for your ideas?
-Bevi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com <http://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.
From: Duff Johnson
Date: Fri, Mar 01 2013 8:03AM
Subject: Re: Captions and Alt-text
← Previous message | Next message →
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 ADDRESS REMOVED =
http://duff-johnson.com
From: Chagnon | PubCom
Date: Fri, Mar 01 2013 9:58AM
Subject: Re: Captions and Alt-text
← Previous message | Next message →
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.
From: Becher, Jed (MNIT)
Date: Mon, Mar 04 2013 9:27AM
Subject: Re: Captions and Alt-text
← Previous message | Next message →
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
>
From: Chagnon | PubCom
Date: Mon, Mar 04 2013 12:03PM
Subject: Re: Captions and Alt-text
← Previous message | Next message →
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.
From: Jonathan Metz
Date: Tue, Mar 05 2013 8:13AM
Subject: Re: Captions and Alt-text
← Previous message | No next message
Hi,
I replicated your problem and I think I found a workaround that seems to be a usable solution. I'll list everything I did to get to that workaround, but note that I only worked on a single page document.
I created the alt tags in Bridge first, manually changing the text in the Description area.
I added a text box, an H1 and an H2 with some basic paragraph style for P. I mapped all those out in the Export Tagging section.
In InDesign, I selected the Object Export Options, under Alt Text I chose from Alt Text Source "From XMP:Description". Tagged PDF tab options were "Based on Object, From Structure"
I added a image of an illustration. The Object Export Options shows the Alt text. I add a separate text box for the Caption.
Here's where I tried your methods and had the same results as you did. What I eventually ended up with was to anchor the image in the text (In my case, I put it in the H2 so I could find it easier). Then I took the separate Caption text box and anchored it in the same spot. I exported the PDF.
The result is that it now shows the following:
<Document>
<Article>Article 1
<Story>
<H1>
<H2>
H2 text
<Figure>
Image (74):w264 h:266
<Story>
The Impulsive Paradigm <-------------This was what I chose for the caption text.
<NormalParagraphStyle>
<NormalParagraphStyle>
<NormalParagraphStyle>
Etc
This fixed the issue of the document with two separate Articles, one with all the document tags and one with all the figure tags.
And the alt text is preserved.
Does this Help?
Jonathan Metz
Web Specialist
Altarum Institute
From: Chagnon | PubCom < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
Reply-To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
Date: Monday, March 4, 2013 2:03 PM
To: 'WebAIM Discussion List' < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >>
Subject: Re: [WebAIM] Captions and Alt-text
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.