E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 14 (In chronological order)

From: Chagnon | PubCom
Date: Mon, Jul 15 2013 1:32PM
Subject: Graphical heading & Alt-text
No previous message | Next message →

A question from a government client of ours prompted this post.

She designs a complex, highly-designed, visually-rich magazine for children
and she's using InDesign for layout, and then exporting to PDF. She's and
her agency are very committed to making accessible educational materials.

Here's the accessibility problem. There is a page that uses graphical text
for the page's main heading, what should be <H1> if it was live text. For
the visual appearance she wants, the text must be turned into a graphic to
produce the appearance, so she then puts Alt-text on the graphical text.

Questions:

1) Should it be Alt-text or Actual text on the graphic?

2) How can we let the reader know this acts as a <H1>? Because it's a
graphic, it's tagged as a <figure> tag, not an <H1> tag.

What are your thoughts?

This problem is just one of the many obstacles and software shortcomings
InDesign and Acrobat users face as they try to convert their layout designs
to either an accessible PDF or an accessible eBook.

-Bevi Chagnon



- PubCom.com - Trainers, Consultants, Designers, and Developers.

- Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

- It's our 32nd year!

From: Duff Johnson
Date: Mon, Jul 15 2013 1:57PM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Bevi,

> Here's the accessibility problem. There is a page that uses graphical text
> for the page's main heading, what should be <H1> if it was live text. For
> the visual appearance she wants, the text must be turned into a graphic to
> produce the appearance, so she then puts Alt-text on the graphical text.

Funny you should ask this - I got almost (but not quite) the exact same question earlier today from someone else!

> Questions:
>
> 1) Should it be Alt-text or Actual text on the graphic?

If one may assume that the visual appearance of the text isn't semantically significant then actual text is indicated.

If the visual appearance is significant (i.e., if there's some sort of concrete deliverable and relevant message in the typography itself, such as flames to indicate heat or snow-crystals to indicate cold) then alternative text would be indicated.

> 2) How can we let the reader know this acts as a <H1>? Because it's a
> graphic, it's tagged as a <figure> tag, not an <H1> tag.

Nest the <Figure> tag within an <H1> tag.

> This problem is just one of the many obstacles and software shortcomings
> InDesign and Acrobat users face as they try to convert their layout designs
> to either an accessible PDF or an accessible eBook.

These are very very hard questions for software. When does a change to visual styling "become" semantically significant? Whether the software helps you solve this problem or not, ultimately all software can do in such a case would be to bring the question to the attention of a human author: "what are you trying to say here?"

If the text used in the H1 is also used later on (say, within paragraph text), it's likely better to use actual text in those cases to preserve the word-flow when text is repurposed rather than bother the poor user with alternative text descriptions of the image each time it occurs.

Now, this last point is (largely) derivable from other general advice not to repeat information without purpose. But it's not going to be obvious (either way) to many many authors.

There are also - if we are to be honest - cases where it would be desirable to represent either actual or alternative text, depending. I believe (I could be wrong) that today's APIs and AT aren't set up to address such circumstances at this time.

Developing software that encourages authors to learn how to create accessible documents is profoundly challenging. I do not envy the UI developers, which is why my contributions are (necessarily) limited to standing on the sidelines throwing peanut shells.

Duff.

From: Shuttlesworth, Rachel
Date: Mon, Jul 15 2013 2:15PM
Subject: Re: Software that encourages accessible document creation WASGraphical heading & Alt-text
← Previous message | Next message →

Duff says:
"Developing software that encourages authors to learn how to create
accessible documents is profoundly challenging. I do not envy the UI
developers, which is why my contributions are (necessarily) limited to
standing on the sidelines throwing peanut shells."



What are some tools that actually do encourage accessible document
creation?



Rachel

Dr. Rachel S. Thompson
Director, Emerging Technology and Accessibility
Center for Instructional Technology
University of Alabama







On 07/15/13 2:57 PM, "Duff Johnson" < = EMAIL ADDRESS REMOVED = > wrote:

Bevi,

> Here's the accessibility problem. There is a page that uses graphical
>text
> for the page's main heading, what should be <H1> if it was live text. For
> the visual appearance she wants, the text must be turned into a graphic
>to
> produce the appearance, so she then puts Alt-text on the graphical text.

Funny you should ask this - I got almost (but not quite) the exact same
question earlier today from someone else!

> Questions:
>
> 1) Should it be Alt-text or Actual text on the graphic?

If one may assume that the visual appearance of the text isn't
semantically significant then actual text is indicated.

If the visual appearance is significant (i.e., if there's some sort of
concrete deliverable and relevant message in the typography itself, such
as flames to indicate heat or snow-crystals to indicate cold) then
alternative text would be indicated.

> 2) How can we let the reader know this acts as a <H1>? Because it's
>a
> graphic, it's tagged as a <figure> tag, not an <H1> tag.

Nest the <Figure> tag within an <H1> tag.

> This problem is just one of the many obstacles and software shortcomings
> InDesign and Acrobat users face as they try to convert their layout
>designs
> to either an accessible PDF or an accessible eBook.

These are very very hard questions for software. When does a change to
visual styling "become" semantically significant? Whether the software
helps you solve this problem or not, ultimately all software can do in
such a case would be to bring the question to the attention of a human
author: "what are you trying to say here?"

If the text used in the H1 is also used later on (say, within paragraph
text), it's likely better to use actual text in those cases to preserve
the word-flow when text is repurposed rather than bother the poor user
with alternative text descriptions of the image each time it occurs.

Now, this last point is (largely) derivable from other general advice not
to repeat information without purpose. But it's not going to be obvious
(either way) to many many authors.

There are also - if we are to be honest - cases where it would be
desirable to represent either actual or alternative text, depending. I
believe (I could be wrong) that today's APIs and AT aren't set up to
address such circumstances at this time.

Developing software that encourages authors to learn how to create
accessible documents is profoundly challenging. I do not envy the UI
developers, which is why my contributions are (necessarily) limited to
standing on the sidelines throwing peanut shells.

Duff.

From: Chagnon | PubCom
Date: Mon, Jul 15 2013 2:45PM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Thanks Duff for confirming my workaround.

Duff wrote: "These are very very hard questions for software. When does a
change to visual styling "become" semantically significant?
... I believe (I could be wrong) that today's APIs and AT aren't set up to
address such circumstances at this time."

I don't think this is a problem because most software, like MS Word and HTML
editors, gives the developer the tool to add either Alt-text or Actual text
to the graphic. The developer makes the decision, not the software. To me,
that's correct.

The bigger problem we have with Adobe InDesign is that it lacks the tool to
put Actual text on a graphic.

- It has a tool to pub alt-text on graphics, but not actual text.

- It has a really cool tool to automatically draw the graphic's XMP meta
data information and drop it into the Alt-text field, but not the actual
text metadata.

- It doesn't even have either Alt-text or Actual Text metadata XMP fields,
so the "title" or "description" XMP fields are borrowed. This is a huge
problem for government databases with millions of photos that have already
used the "title" and "description" fields for what they should be used for,
not accessible Alt-text and Actual text. In most cases, the description of a
photo is not the same as its Alt-text.

And with Acrobat, it's built-in accessibility checker will flag a graphic as
an error if it has only Actual text on it, not Alt-text. So expect to see
more PDFs with both Actual and Alt text on the graphics.

Now you know how they came to be! The developer needed to pass the Acrobat
accessibility checker in order to not be fired from his job.

Duff wrote: "... standing on the sidelines throwing peanut shells."
You must be a better person than me, Duff. Sometimes at the end of a long
day dealing with InDesign, Acrobat, and accessibility, I want to throw rocks
at the engineers because of all the hoops they make an ordinary graphic
designer go through in order to create an accessible PDF from a
print-layout. <grin>

-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 - www.Workshop.Pubcom.com

From: Jonathan Metz
Date: Mon, Jul 15 2013 3:05PM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Hi Bevi,

Just in case I totally misunderstand you I thoroughly apologize. I was up
really late last night on my new computer playing Batman:Arkham City.


>
>The bigger problem we have with Adobe InDesign is that it lacks the tool
>to
>put Actual text on a graphic.
>
>- It has a tool to pub alt-text on graphics, but not actual text.
>
>- It has a really cool tool to automatically draw the graphic's XMP meta
>data information and drop it into the Alt-text field, but not the actual
>text metadata.

In the Object Export Dialog box of CS5.5 to current, under the tab ³Tagged
PDF² Actual Text Source can choose from XMP:Title, XMP:Description, and
XMP:Headline, as well as any other XMP Property.

>
>- It doesn't even have either Alt-text or Actual Text metadata XMP fields,
>so the "title" or "description" XMP fields are borrowed. This is a huge
>problem for government databases with millions of photos that have already
>used the "title" and "description" fields for what they should be used
>for,
>not accessible Alt-text and Actual text. In most cases, the description
>of a
>photo is not the same as its Alt-text.

So make them. I haven¹t actually done this, but it looks pretty cool:
http://gunar.wordpress.com/2010/05/19/create-custom-metadata-panels-in-cs5-
with-xml/

>
>And with Acrobat, it's built-in accessibility checker will flag a graphic
>as
>an error if it has only Actual text on it, not Alt-text. So expect to see
>more PDFs with both Actual and Alt text on the graphics.

Based on a question I posed a while ago about Actual Text and Alternate
Text, Andrew Kirkpatrick had an awesome explanation (Thanks Andrew, if
you¹re reading this!):

"The primary distinction is that when a figure has actual text that figure
isn't reported as a figure to the accessibility API, so the assistive
technology won't read it as a figure. When alternative text is used, it is
reported as a figure so a screen reader will say "graphic" or similar to
indicate the role. If you use both, it is regarded as a figure.²


So I don¹t think that¹s such a big deal in the end.


>
>
>Now you know how they came to be! The developer needed to pass the Acrobat
>accessibility checker in order to not be fired from his job.
>
>Duff wrote: "... standing on the sidelines throwing peanut shells."
>You must be a better person than me, Duff. Sometimes at the end of a long
>day dealing with InDesign, Acrobat, and accessibility, I want to throw
>rocks
>at the engineers because of all the hoops they make an ordinary graphic
>designer go through in order to create an accessible PDF from a
>print-layout. <grin>

Sometimes I want to be the one passing you those rocks. Mostly when it
comes to EchoSign (I couldn¹t resist, sorry! :D )

Jonathan


>
>-Bevi Chagnon
>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
>-
>- - - - - - - - - - - - - - -
>www.PubCom.com - Trainers, Consultants, Designers, Developers.
>Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
>Accessibility.
>New Sec. 508 Workshop & EPUBs Tour in 2013 - www.Workshop.Pubcom.com
>
>

From: Chagnon | PubCom
Date: Mon, Jul 15 2013 6:49PM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Jonathan wrote:
"In the Object Export Dialog box of CS5.5 to current, under the tab ³Tagged
PDF² Actual Text Source can choose from XMP:Title, XMP:Description, and
XMP:Headline, as well as any other XMP Property. ... So make them."

That's correct, Jonathan, a designer can access custom metadata fields in
InDesign and that feature continued into InDesign versions CS6 and CC.

The problem is that there aren't any defined fields for either Alt-text or
Actual Text so what will the designer choose? And, yes, it's possible to
define your own XMP metadata field, but that makes the problem worse. Will
the designer or IT technician name that field (list of 6 with various
spellings):
Alt-text
Alt-Text
Alt text
ALT Text
Alternative Text
Blue Jujubees

InDesign doesn't have any ability to apply Actual Text to a graphic at all,
so how will its export utility know to put Actual Text on the <FIGURE> tag
and produce a compliant PDF?

What about the other software programs that tap into XMP metadata on graphic
files? How will they understand these custom fields and how to process them?

The best solution is for Adobe to add these 2 fields to the basic XMP
metadata choices (in other words, make them standards) and then:
1. Build their usage into InDesign, too.
2. Build them into the PDF export utility from InDesign so that a correctly
tagged graphic ends up in the PDF.

Because these metadata fields are used by Adobe's software to create and tag
PDFs, the user can't make up their own field names and end up with an
accessible PDF. Nor are they likely to be used by other software.

— Bevi Chagnon
— PubCom.com — Trainers, Consultants, Designers, and Developers.
— Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
— It's our 32nd year!

From: Duff Johnson
Date: Mon, Jul 15 2013 11:25PM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

> I don't think this is a problem because most software, like MS Word and HTML
> editors, gives the developer the tool to add either Alt-text or Actual text
> to the graphic. The developer makes the decision, not the software. To me,
> that's correct.

I meant the software developer, but I take your point - there's certainly a lot more that software could do to make the richness of PDF accessibility available; I didn't mean to suggest otherwise.

> The bigger problem we have with Adobe InDesign is that it lacks the tool to
> put Actual text on a graphic.

Ouch! I didn't actually know that about ID! BIG bummer!!

> - It doesn't even have either Alt-text or Actual Text metadata XMP fields,
> so the "title" or "description" XMP fields are borrowed. This is a huge
> problem for government databases with millions of photos that have already
> used the "title" and "description" fields for what they should be used for,
> not accessible Alt-text and Actual text. In most cases, the description of a
> photo is not the same as its Alt-text.

Ugh! And it's even worse because XMP has so much promise as a metadata model… and yet Adobe (who invented it) hasn't bothered to implement it properly themselves in a key instance in which people might like to do so!

> And with Acrobat, it's built-in accessibility checker will flag a graphic as
> an error if it has only Actual text on it, not Alt-text. So expect to see
> more PDFs with both Actual and Alt text on the graphics.

That's a bug in Acrobat, pure and simple.

> Now you know how they came to be! The developer needed to pass the Acrobat
> accessibility checker in order to not be fired from his job.

I've served as an expert witness to help a legal defense against this sort of idiocy, and I would do so again.

Once software that fully implements PDF/UA becomes generally available this sort of problem will go away. It won't happen overnight, but the first PDF/UA checker will arrive into the marketplace soon.

Duff.

From: Chagnon | PubCom
Date: Tue, Jul 16 2013 12:25AM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Duff wrote:
"... the first PDF/UA checker will arrive into the marketplace soon."

Great news!
-Bevi Chagnon
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com - Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 - www.Workshop.Pubcom.com

From: Olaf Drümmer
Date: Tue, Jul 16 2013 3:29AM
Subject: Re: Software that encourages accessible document creation WASGraphical heading & Alt-text
← Previous message | Next message →

Hi Rachel,

Am 15 Jul 2013 um 22:15 schrieb "Shuttlesworth, Rachel" < = EMAIL ADDRESS REMOVED = >:

> What are some tools that actually do encourage accessible document
> creation?

- axesPDF by xyMedia (still in beta, beta freely available) makes it substantially easier to create accessible PDF from within Microsoft Word (2007, 2010, and probably also 2013, but I haven't checked out the latter myself); cf. http://www.axespdf.com

- CommonLook Office by NetCentric Technologies, (I have checked it out for Word and PowerPoint 2010) makes it substantially easier to create accessible in these applications; cf. http://www.commonlook.com/CommonLook-office

- axaio MadeToTag for Adobe InDesign by axaio software (CS 5.5, CS 6 and CC, Mac and Windows) makes it substantially easier to create accessible PDF from INDesign documents (Disclaimer; MadeToTag is a tool developed by my company, axaio software);cf. http://www.axaio.com/doku.php/en:products:madetotag

Please note that some basic implementation in support of accessible document creation has been available for both Microsoft Office (2007 and onward) and Adobe InDesign (CS 5.5 and onward), as well as for OpenOffice/LibreOffice, for a while. For most users though these programs remain a challenge due to less than perfect user interface and sometimes serious technical limitations if not bugs. The add-ons listed above fill most of the severe gaps (both in user interface and regarding technical issues), and turn painful work into productive work, yielding much better results than otherwise feasible.

Olaf

From: Olaf Drümmer
Date: Tue, Jul 16 2013 3:39AM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

I have to disagree here:

while the way Adobe implemented the user interface for this is - let's say.. - interesting ... the feature as such is there:

in the Object Export Options dialogs you have

- "Alternate text": this is about associating Alt text with the image frame

- "PDF with Tags": this is about associating ActualText with the image frame

- EPUB and HTML": not relevant here


I am wild agreement with anybody stating that this is not the smartest way a user interface can be designed...


Olaf



Am 16 Jul 2013 um 07:25 schrieb Duff Johnson < = EMAIL ADDRESS REMOVED = >:

>> The bigger problem we have with Adobe InDesign is that it lacks the tool to
>> put Actual text on a graphic.
>
> Ouch! I didn't actually know that about ID! BIG bummer!!

From: Olaf Drümmer
Date: Tue, Jul 16 2013 3:55AM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

Again, I somehow disagree - the features are there.. (but admittedly they have been implemented in a way that is the opposite of being user friendly).


- first, XMP metadata schemas can be defined by anyone in the world, and most that are widely used have been defined by organisations other than Adobe - Dublin Core comes to mind, or IPTC, or EXIF, or…; I am not aware of any such established metadata schema (XMP or otherwise) that has a field for actual text;

- there are fields in some schemas that can serve as a source Alt text, but for good reasons there is not the one and only Alt text metadata field; in the world of news article and photos from news agencies, based on IPTC, there are a few fields that are relevant here; one will contain a short text, more like a title, another field will contain an extensive, even narrative explanation of the image; then you have Dublin Core title or description; that's already four fields…

- if the accessibility community believes there should be metadata fields providing certain information right away - like 'suggested Alt text when used as an image in a document' or 'suggested ActualText when used not as an image but more like a piece of text' - this community is free to develop an XMP metadata schema for this, and promote its adoption (which usually never takes longer than five or ten years)

- BTW - XMP itself is an ISO standard (ISO 16684-1) since February 2012.

- I would't blame Adobe for the somehow chaotic situation when it comes to predefined metadata fields for something like alternate text - while Adobe has invented and published XMP as an architecture for metadata, they very wisely stayed out of how certain communities and industries put XMP to work. They often helped interested communities migrate their metadata concepts to XMP, but Adobe did't tell them which fields to use for what etc.

- in the object export options dialog you can retrieve any metadata field you want (if you can figure out how to do it right… - some more user friendly support in the user interface and some documentation would have been nice)

- one of the obstacles overall: everybody believes metadata (and actually using them) should be cool and there should be a standard for it etc. - as long as that standard is exactly what a given user thinks it should be; there is very little readiness in the market to accept something that is a standard but does not meet exactly a user's taste or preferences.

Olaf


Am 16 Jul 2013 um 07:25 schrieb Duff Johnson < = EMAIL ADDRESS REMOVED = >:

> Ugh! And it's even worse because XMP has so much promise as a metadata model… and yet Adobe (who invented it) hasn't bothered to implement it properly themselves in a key instance in which people might like to do so!

From: Dave Merrill
Date: Tue, Jul 16 2013 4:51AM
Subject: Re: Software that encourages accessible document creation WASGraphical heading & Alt-text
← Previous message | Next message →

Are talking specifically about PDFs? Other desktop documents? Web pages?

Dave Merrill


On Mon, Jul 15, 2013 at 4:15 PM, Shuttlesworth, Rachel
< = EMAIL ADDRESS REMOVED = >wrote:

> Duff says:
> "Developing software that encourages authors to learn how to create
> accessible documents is profoundly challenging. I do not envy the UI
> developers, which is why my contributions are (necessarily) limited to
> standing on the sidelines throwing peanut shells."
>
>
>
> What are some tools that actually do encourage accessible document
> creation?
>
>
>
> Rachel
>
> Dr. Rachel S. Thompson
> Director, Emerging Technology and Accessibility
> Center for Instructional Technology
> University of Alabama
>
>
>
>
>
>
>
> On 07/15/13 2:57 PM, "Duff Johnson" < = EMAIL ADDRESS REMOVED = > wrote:
>
> Bevi,
>
> > Here's the accessibility problem. There is a page that uses graphical
> >text
> > for the page's main heading, what should be <H1> if it was live text. For
> > the visual appearance she wants, the text must be turned into a graphic
> >to
> > produce the appearance, so she then puts Alt-text on the graphical text.
>
> Funny you should ask this - I got almost (but not quite) the exact same
> question earlier today from someone else!
>
> > Questions:
> >
> > 1) Should it be Alt-text or Actual text on the graphic?
>
> If one may assume that the visual appearance of the text isn't
> semantically significant then actual text is indicated.
>
> If the visual appearance is significant (i.e., if there's some sort of
> concrete deliverable and relevant message in the typography itself, such
> as flames to indicate heat or snow-crystals to indicate cold) then
> alternative text would be indicated.
>
> > 2) How can we let the reader know this acts as a <H1>? Because it's
> >a
> > graphic, it's tagged as a <figure> tag, not an <H1> tag.
>
> Nest the <Figure> tag within an <H1> tag.
>
> > This problem is just one of the many obstacles and software shortcomings
> > InDesign and Acrobat users face as they try to convert their layout
> >designs
> > to either an accessible PDF or an accessible eBook.
>
> These are very very hard questions for software. When does a change to
> visual styling "become" semantically significant? Whether the software
> helps you solve this problem or not, ultimately all software can do in
> such a case would be to bring the question to the attention of a human
> author: "what are you trying to say here?"
>
> If the text used in the H1 is also used later on (say, within paragraph
> text), it's likely better to use actual text in those cases to preserve
> the word-flow when text is repurposed rather than bother the poor user
> with alternative text descriptions of the image each time it occurs.
>
> Now, this last point is (largely) derivable from other general advice not
> to repeat information without purpose. But it's not going to be obvious
> (either way) to many many authors.
>
> There are also - if we are to be honest - cases where it would be
> desirable to represent either actual or alternative text, depending. I
> believe (I could be wrong) that today's APIs and AT aren't set up to
> address such circumstances at this time.
>
> Developing software that encourages authors to learn how to create
> accessible documents is profoundly challenging. I do not envy the UI
> developers, which is why my contributions are (necessarily) limited to
> standing on the sidelines throwing peanut shells.
>
> Duff.
> > > >
> > > >



--
Dave Merrill

From: Chagnon | PubCom
Date: Tue, Jul 16 2013 6:38AM
Subject: Re: Graphical heading & Alt-text
← Previous message | Next message →

I stand corrected. Thanks Olaf.
(Oh how I hate the new dark interface in InDesign. And yes, I know I can
change it but it doesn't always stick.)
—Bevi
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - - - - - - - - - - - - - -
www.PubCom.com — Trainers, Consultants, Designers, Developers.
Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
New Sec. 508 Workshop & EPUBs Tour in 2013 — www.Workshop.Pubcom.com

From: Chagnon | PubCom
Date: Tue, Jul 16 2013 7:46AM
Subject: Re: Graphical heading & Alt-text
← Previous message | No next message

Olaf wrote:
"- there are fields in some schemas that can serve as a source Alt text, but
for good reasons there is not the one and only Alt text metadata field; in
the world of news article and photos from news agencies, based on IPTC,
there are a few fields that are relevant here; one will contain a short
text, more like a title, another field will contain an extensive, even
narrative explanation of the image; then you have Dublin Core title or
description; that's already four fields."

Yes, they can be used for Alt-text, but they really are various forms of
captions. Captions aren't Alt-text and in many photos shouldn't be confused
as one and the same.

Large organizations, such as news media and government agencies with photo
libraries, have already assigned these fields to other specific tasks,
especially for dynamically-generated websites and mobile content as Olaf
described, so we can't go and "borrow" them for our purpose.

If you want to automate applying Alt-text to 100 photos in a publication (a
project we're automating for a client right now), here are the steps that
need to be done:

1) An editor writes Alt-text using software that reads and writes metadata.
He decides to use the "Description" field because there isn't a standardized
Alt-text field.

2) He gets to photo #50 and discovers that this photo has already used
"Description" for a caption and the caption isn't appropriate for Alt-text.
Since this photo is from a large photo database, he can't remove what's
already there and put in his own Alt-text because someone else in the
organization uses this field for a process (likely the web team for
automated population of photo captions). So he has to make a choice: either
he goes back and changes all the other Alt-texts to some other field, like
"Title", or he makes a note to tell the production designer not to use
"description" for photo #50, but instead use "Title."

3) As the editor goes through the photos, he finds a few more that already
use Description and Title for other purposes, so he has to use another field
for the Alt-text and remember to tell the production designer.

If you've ever worked on a large group project, you can sense that we're in
dangerous territory: something is going to get lost in the translation.

4) Move now to InDesign desktop publishing, and the designer is adding
Alt-text to the 100 photos in the layout. Click a photo, select
Object/Export Options, and select get Alt-Text from the metadata's
Description field. Click the next photo in the layout, select get Alt-text
from the metadata's Description field. And the next photo, and the next.

5) Wait: which photo did the editor say to use Title, not Description? Was
that #49? No, wait, wait, #62 uses ...which field for Alt-text? Where's
that email the editor sent!

I can automate the work in InDesign with a script that will find each photo
and get the Description field from the metadata. But what about photo #50?
The automated script is going to put in the wrong field for Alt-text, so by
hand the designer has to remember and change the Alt-text on #50. And the
editor has to check or proof that this was indeed done.

Without a standardized XMP metadata field for Alt-text (and Actual text),
this important task for accessibility is difficult to do.

Olaf's right, a designer or editor can make a custom XMP field for Alt-text,
and the InDesign user can pull from any XMP metadata field, but we're
talking about real-world editors and designers, and the majority I've worked
with and taught have mediocre computer skills. In fact, most designers are
computer-phobic. (Note, it's changing slowly as an older generation retires
and a younger more-computer-savvy generation takes over.)

If you want the process to fail, then tell designers they have to create
their own metadata field and populate it by hand.

If you want it to get done, then provide an easy-to-deploy way for them to
do so, a way that anyone will understand how to use.

Olaf wrote:
"one of the obstacles overall: everybody believes metadata (and actually
using them) should be cool and there should be a standard for it etc. - as
long as that standard is exactly what a given user thinks it should be;
there is very little readiness in the market to accept something that is a
standard but does not meet exactly a user's taste or preferences."

I don't consider metadata cool. Been using it for several decades of
programming and I think it's incredibly practical and useful, but not cool.
My new pair of boots are cool, but not metadata <grin>.

I can't think of better names for proposed standardized fields than
"Alt-Text" and "Actual Text." I think the only thing up for discussion is
whether "Alt" is capitalized or not, and whether it gets a hyphen or not. I
like to K.I.S. (Keep it simple).

Adobe should lead on this because they 1) created XMP, 2) create InDesign
and many other creative software programs that should be setting Alt-text,
and 3) create the export-to-PDF engines in these programs, as well as
Acrobat itself. They are the logical choice.

And I think the accessibility community should encourage Adobe (I'd like to
say push, but...) to do this throughout its entire line of tools. They are
the major player in publishing - graphic design, traditional publishing, web
publishing, web technologies and analytics, you name it.

Hopefully list member Andrew Kirkpatrick of Adobe can comment on this.

-Bevi Chagnon

- PubCom.com - Trainers, Consultants, Designers, and Developers.
- Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.
- It's our 32nd year!