WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Captions and Alt-text

for

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.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
Sent: Friday, March 01, 2013 10:03 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Captions and Alt-text

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

messages to = EMAIL ADDRESS REMOVED =

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


> -----Original Message-----
> From: = EMAIL ADDRESS REMOVED = [mailto:webaim-forum-
> = EMAIL ADDRESS REMOVED = ] On Behalf Of Chagnon | PubCom
> Sent: Friday, March 01, 2013 10:59 AM
> To: 'WebAIM Discussion List'
> Subject: Re: [WebAIM] Captions and Alt-text
>
> 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 ADDRESS REMOVED =
> [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Duff Johnson
> Sent: Friday, March 01, 2013 10:03 AM
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Captions and Alt-text
>
> 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
>
> > > messages to = EMAIL ADDRESS REMOVED =
>
> > > messages to = EMAIL ADDRESS REMOVED =

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.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED =
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Becher, Jed
(MNIT)
Sent: Monday, March 04, 2013 11:28 AM
To: = EMAIL ADDRESS 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 ADDRESS 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 ADDRESS 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 ADDRESS REMOVED =
> http://duff-johnson.com
>
> > > list messages to = EMAIL ADDRESS REMOVED =
>
> > > list messages to = EMAIL ADDRESS REMOVED =


messages to = EMAIL ADDRESS REMOVED =

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.

-----Original Message-----
From: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
[mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Becher, Jed
(MNIT)
Sent: Monday, March 04, 2013 11:28 AM
To: = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS 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 ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
http://duff-johnson.com
list messages to = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
list messages to = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >


messages to = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >