WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Graphical heading & Alt-text

for

From: Jonathan Metz
Date: Jul 15, 2013 3:05PM

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
>
>-----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.
>
>>>