WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: A case for artifacting bullets in unordered lists inPDFs

for

From: Andrew Kirkpatrick
Date: Jul 24, 2013 1:03PM

Responses inline.

> [AWK] Lbl is optional, per the ISO 32000 and ISO 14289 specs.

they are only optional insofar as if there is no bullet character or other kind of label in the page content, then that's fine, and no Lbl has to be present in the tagging structure for the list. But if there is page content that would be considered a bullet character or other kind of label in front of a list item, then PDF/UA clearly mandates that - for labels in list items as much as any other content - the right tag shall be used - and that would be the Lbl tag. No exceptions.

[AWK] You're right, regarding PDF/UA, I stand corrected. That said, it is an unfortunate requirement given the difficulty in making this type of repair. Tools like acrobat will need to make this easier, but I suspect that it will always be one of the more challenging types of repair.

> [AWK] .... As far as how the information is conveyed to AT if you use Lbl and Lbody, just Lbody, or even just put the text inside the LI directly - it is the same. The only difference with JAWS is that when you use Lbl the bullet is being read as if it is on its own line, which in my mind isn't a great way of announcing the bullet item.

The way you write a statement like this is possibly (as I might be reading too much into it) flawed in two ways:
- it silently equates AT to screenreaders
- it silently equates screenreaders to JAWS [I do know that you are writing it this way with only the best intentions, but...]

[AWK] You may be reading that into my words but that is not intended. I mentioned JAWS because others had related to this point, but I'm well aware of other tools, including for users other than those who need a screen reader. If anything, what it silently equates is way reader on Windows exposes list information to AT with the way that list information is exposed by PDF readers in general.

Envision AT that helps a dyslexic user do two things:
- make reading easier (or possible at all)
- help improve reading skills
There are a couple of ways to do this, for example by enlarging the page view, centering the current content in the document window, highlighting every piece of the content let's say word by word, while dimming everything around it (to reduce distraction by immediate context), speak out loud the word, additionally provide an alternate rendition of the word in a special font, then go on to the next word, etc.. If a person with dyslexia (many of them young people still learning the written language, and some of them overcoming their problems over time by working and learning very hard) never encounters a list label, he/she will not become familiar with the concept of 'list item labels'. Not good.

I could think of various other types of AT where not getting list labels right is just not the right thing to do. If it's there and is content (as opposed to decoration or some pagination side effect not conveying any meaning) - tag it! When tagging, always use the right tag (from the set of standard tags in PDF 1.7)! Not more, not less. Skipping or mis-tagging is bad, even if some groups of users wouldn't mind. At least that's the message of PDF/UA.

[AWK] I'd be interested in hearing about the other benefits of using lbl/lbody that you are thinking about. I'm not convinced that it is worth it given that user agents could do at least the things that you mentioned in the dyslexia example either way.