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?


From: chagnon@pubcom.com
Date: May 29, 2018 3:57PM

We run into the same situation not just with screen readers, but with any AT that uses tabs (or similar keys) to navigate the document.

This problem ends up forcing the user to tap twice for each bullet or numbered list element.
Tap. Bullet.
Tap. Body text of the bullet.
Tap. Bullet
Tap. Body text of the next bullet.

I'm venturing that all of our AT haven't completely addressed this.

So the question is: Why haven't the AT manufacturers fixed this? Do they know it's a problem? Is there anything in the PDF and/or PDF/UA spec that tells them not to have their technology have a lag at the LBL tag or force a double-tap?

I agree, AT users and others in the community should post their bugs to the manufacturers.

Where the request will fall on deaf ears. Manufacturers go by numbers and Joe or Mary's individual request gets round-filed very quickly.

One person filing a bug report has little chance of getting the error fixed...by any of our software manufacturers.

Isn't this something that the PDF Association should help with? The association would have a much better chance of being heard, and the manufacturer might even appreciate some guidance on the finer nuances of making the PDF and PDF/UA specs work for their products and their customers.

The committees that create the ISO standards (which are called "machine" specifications) are only one part of what's needed. Guides for those who program the machines are also needed. And guides for content creators who must build content that meets the specs are needed, too.

If we don't take time to educate all the stakeholders in our entire community, we end up with annoying half-baked quassi-assistive technology that forces users to double-tap through lists. And worse.

— — —
Bevi Chagnon, founder/CEO | <EMAIL REMOVED>
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting • training • development • design • sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Duff Johnson
Sent: Tuesday, May 29, 2018 1:15 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?

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