WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?

for

From: Duff Johnson
Date: May 29, 2018 11:15AM

> As my understanding of the PDF/UA specification increases, I'm starting to run into some small-detail technical quandaries where following the spec to the letter seems to slightly degrade the experience of an actual screen reader.

Let's be specific: it's the shortcomings of the screen-reader, not the PDF, that's degrading the experience.

> I have two examples that I am currently wondering about. I'll start a separate thread to discuss my second example. Here's the first one.
>
> Quandary 1: Bullets in LBL tags
>
> When I correctly follow the PDF/UA requirement to tag bullets with LBL (Label) tags, I have received feedback from an actual screen reader who complained that the tagging causes a pause after the bullet. In my testing, I think this is by design. When using the cursor down key to listen to the text supposedly "line-by-line" in both NVDA and JAWS, the reading stream will pause after reading a bullet in an LBL tag. But if instead you just leave the bullet inside the LBody (List Item Body) tag and don't add the LBL tag at all, then the bullet is still read at the start of the List Item without requiring the screen reader to press the cursor key twice. Note that this latter, less obtrusive behaviour is actually what you get by default if you use Microsoft Word to produce your PDF since MS Word doesn't currently insert LBL tags at all.

HTML's concept of list-labels is very constrained as compared with PDF's. <Lbl> structure-elements, although they do not have a direct equivalent in HTML. This fact has historically confused some developers.

That a screen-reader doesn't handle <Lbl> elements effectively is a reason to file a bug-report / feature request, just like one might with any other request for an improvement in the software.

> It seems to me then that when I properly follow the PDF/UA spec, I am actually producing a degraded user experience for some users, making it more of a hassle for them to listen to the document.

Again, to be specific… the screen-reader is producing the experience; you are merely tagging the document. If you tag it correctly, it remains for the screen-reader to represent it effectively. If it does not… it's the screen-reader's problem.

> To make matters worse, since the vast majority of PDFs are produced by Word, if I "fix" those documents by adding LBL tags, then I end up actually getting negative flack from our screen reader assessor for not matching their expectations.

Many users confuse the performance of a given version of a given piece of software with the structure of a document. That's really not how software works. The whole point of having a specification for the document is to make it possible for different software vendors to achieve agreement on what to do. If the standard becomes "how my software behaves" instead, then consistency become impossible.

> Is this an accurate assessment of the current state of things, or am I doing something wrong?
> Do any of the screenreaders have plans to improve the way lists are handled in order to deal with this pausing issue?

I have no idea. I hope so. Did you file a feature-request on this point? Please do.

> Or perhaps the pausing is needed when dealing with certain ordered lists where the Label value may actually carry some meaningful content?

As ever, the screen-reader developers will improve their PDF handling if people demand it, and not before then.

> It crossed my mind that it would be possible to surround both LBL bullets and LBody content with spans and thereby eliminate the pauses by simulating in-line text. But that seems crazy and inefficient, when there are already correct tags in place.

I understand the frustration that breeds these sorts of work-arounds. This is exactly why one has to refer to standards, and not to the (buggy) performance of X, Y or Z software.

Never chase the bugs; report ‘em instead, loudly and often.

Duff.