WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A case for artifacting bullets in unordered lists inPDFs

for

From: Chagnon | PubCom
Date: Jul 24, 2013 11:09AM

Olaf, I think you might have misunderstood what I was commenting on.

Olaf asked: "Why discard information that is there already?" In this
situation, nothing is being discarded. The question was whether anything had
to be added, such as Actual Text. The poster had asked, if he used a
different bullet character such as a right-pointing triangle, would he need
to put actual text on it.

Olaf asked: "Would you discard a symbolic characters in the middle of a
text?"
Of course not because that's a different editorial use of the character, not
what's being discussed here. Symbols in the middle of text have editorial
meaning and purpose.

In this case, the bullet character is just a character that doesn't give any
further information than that it signals a new item in a list, a "bullet."
The most critical information is the text content of the list itself, not
the visually decorative character used, such as a square or round bullet.

In fact, a few years back it was proposed on this list that bullet
characters should be artifacted because they are nonessential. And the idea
has resurrected (note the subject of this thread). In the professional
typesetting industry, these characters have been called "dingbats" for well
over a hundred years, so that should be a clue as to their editorial
importance.

There are times where the bullet character does have relevant meaning in the
list — such as the check mark and "x" ballot box characters, or a series of
nested bullets going from solid circle to hollow circle — but for nearly all
lists, the document designer chose a character for the bullet based solely
on visual appearance, not substantive meaning. That's decorative frou-frou,
not substance. Who knew so many people would use the white smiley face
U+263A or black heart U+2665 for bullet characters in professional
documents!

In a perfect world, it's as you described, Olaf:
1) the document (Word, Office, InDesign, PDF, etc.) will tag the list
appropriately.
2) the AT will voice the bullet character correctly, as well as the
structure of the list and list item.
3) the user can control voicing of the character.
4) the character has a valid Unicode code point.
5) the AT can interpret and voice the valid Unicode character.

But the Word document I just reviewed for a client proves that we are far
from utopia. 300+ page government document with "I lost count of how many
but it was over 1,000" bullets. They insist that it be in Word 2003 and that
Acrobat 7 be used for finishing the accessibility.

Documents of that size and nature are often written by several people and
the versions compiled into one final document. So everyone involved had used
a different bullet for "their" bullets: large circles, small circles,
squares, em-dashes, asterisk, and several that came is as white squares
meaning they were nonvalid Unicode characters, so I don't know what they
were supposed to be. This was government statistical data, so the actual
bullet character was irrelevant to the content.

Plus, several lists were incorrectly made with each bulleted item in its own
separate list.

I my staff have only 8-10 hours in a day to remediate documents for
accessibility, and our clients have limited money to pay us to do this work.

What should I spend that time and money doing? What's most beneficial for AT
users? Choose one below because our time and money is limited:

a) Ensure that the various bullet characters are voice correctly, even if
that means manually adding Actual Text one-by-one to non-standard nonvalid
Unicode characters, up to 1,000 times in the document.

b) Edit the document so that it makes logical sense, reduce the number of
lists and bullets into something that makes logical sense, tag the lists
correctly, standardize all the bullet lists so that only one generic round
bullet character is use throughout, and aim for getting a well-tagged PDF in
the end that is useful and easy on the ears for screen reader users.

Remember, this is not a perfect world: we have substantial technology holes
and gaps in the workflow so I won't have "perfect" bullets every time.

Where should my client invest the time and money, a) or b)?

— Bevi Chagnon
— PubCom.com — Trainers, Consultants, Designers, and Developers.
— Print, Web, Acrobat, XML, eBooks, and U.S. Federal Section 508
Accessibility.

-----Original Message-----
From: <EMAIL REMOVED>
[mailto: <EMAIL REMOVED> ] On Behalf Of Olaf Drümmer

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < <EMAIL REMOVED> >:

> AT users really just need to know it's a bullet.

why would that be? Why discard information that is there already? Would you
discard a symbolic characters in the middle of a text?

Am 24 Jul 2013 um 05:09 schrieb Ryan E. Benson < <EMAIL REMOVED> >:

> [REB]: What should be placed as the value of the actualText if a
> non-standard bullet (such as U+25B6 (right facing triangle))? Just bullet?

and

Am 24 Jul 2013 um 07:08 schrieb Chagnon | PubCom < <EMAIL REMOVED> >:

> If we spend too much time on this low-level stuff, we'll never have
> enough hours in a day for the major stuff, like writing a good
> document, designing it, writing informative alt-text, and tagging it for
accessibility.

if the label character has a valid Unicode code point (outside of the
private use area) - *** no action is required *** - the text is already
accessible. It is up to an AT with a text to speech function to read it out
loud accordingly. In this case it hopefully would read "right facing
triangle"; if an AT developer decides to give a user options, like "turn
this off for a while because I can't stand listening to "right facing
triangle" more than three times on a given day", that's fine, but that's not
anything to do with how the content / document has been prepared.

The easiest way to find whether a bullet has a suitable Unicode code point:
copy and paste it into a strictly text only / no formatting text editing
window or text field (the "Save as…" field of any application's user
interface will do) and look at the appearance of the pasted character: if it
still looks the same it has a reliable Unicode code point, if it has a
replacement character (empty square, or strange looking face mask, or
something like that) it does not have a Unicode code point that will work,
and some action should be taken (preferably ActualText, with a suitable
replacement text).

Olaf