WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Accessible GIS coordinates

for

From: Jonathan Metz
Date: Oct 31, 2013 1:28PM

Sorry Bevi,

I thought you were ending with PDF as the final format, not leaving them
as Word or InDesign. In Acrobat, you would create a span tag, select it,
then select the character in question, then right-click and choose ¡°Create
tag from selection¡±. In the Span tag properties you can change the Actual
Text there.

This is similar to what I do when I have images as bullets in Lists in
PowerPoint or just getting the bullet characters in Word to end up under a
Label tag since Word and PowerPoint assembles the contents of lists in the
LBody tag.

Jon



On 10/31/13 2:42 PM, "Chagnon | PubCom" < <EMAIL REMOVED> > wrote:

>Jonathan Metz wrote:
>"Couldn©öt this be solved by using ActualText, since they are unambiguous
>as
>Olaf points out."
>
>If only we could do that, Jonathan!
>
>Neither MS Word nor Adobe InDesign allow designers to select one text
>character, such as the prime glyph or any other dingbat character or
>symbol,
>and set Actual Text for it.
>
>In Word, Actual Text can only be applied to graphic objects. The utility
>is
>actually on the Format Picture command.
>
>In InDesign, Actual Text can only be applied to frames, that is to the
>entire text or graphic frame not to just one character.
>
>As an example, a normal publication layout in InDesign would have an
>entire
>column of text in one frame and the glyph, like the prime or any other
>non-standard glyph, is just a text character somewhere in the frame with
>the
>rest of the regular text.
>
>So, we can't apply Actual Text to the entire column's text frame.
>We also can't select just one glyph and apply Actual Text to it.
>
>We can, however, convert the glyph to a graphic, anchor the graphic into
>the
>body text at the appropriate place, and put Actual Text on the graphic.
>But
>that requires a ridiculous amount of time, especially over the 100+ pages
>of
>a tour book with probably close to 1,000 of these glyphs. And then, when
>editors do what they do ¡ª edit ¡ª this becomes a very messy layout to
>change.
>In this tour book we're working on, this process would add several days of
>production time just to make the GIS minutes and seconds glyphs
>accessible.
>
>Therefore it's not going to happen and this book won't be as accessible as
>it should be.
>
>InDesign does a decent job of exporting anchored graphics into the correct
>reading order/tag order when the layout is exported to PDF, but with Word,
>we're always surprised by where it decides to place anchored graphics in
>the
>exported PDF. They can end up anywhere in the PDF's tag tree/reading
>order.
>And they require a ridiculous amount of time to correct in Acrobat.
>
>The best solution is 2-fold:
>1) Screen Reader manufacturers pick up the glyph's name/description from
>the
>font information and voice it.
>2) Adobe and Microsoft develop tools to let Actual Text be applied to
>individual glyphs. Sort of like the <ABBR> tag in HTML (which isn't
>available in Word, InDesign or PDF).
>
>Someone has to figure out a solution to this.
>
>Those of us producing professional publications run into the problem
>daily.
>There are countless times we're using font glyphs as visual shortcuts of
>communication, like the end-of-story box at the end of the story.
>
>In this tour book, a character on the Wingdings font is used to visually
>flag key scenic points. I have no practical way to convey that visual
>information to a screen reader user.
>
>Will the final PDF file be accessible? Yes.
>Will it convey all the information to screen reader users? No. I don't
>have
>the tools to do that.
>
>¡ª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
>
>
>>>