WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Graphical heading & Alt-text

for

From: Chagnon | PubCom
Date: Jul 15, 2013 2:45PM

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

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Duff Johnson
Sent: Monday, July 15, 2013 3:57 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Graphical heading & Alt-text

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.