E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 6 (In chronological order)

From: Philip Kiff
Date: Tue, May 29 2018 10:21AM
Subject: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
No previous message | Next message →

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.

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.

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

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? Or perhaps the pausing
is needed when dealing with certain ordered lists where the Label value
may actually carry some meaningful content?

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.

Thoughts?

Philip Kiff
D4K Communications

From: Duff Johnson
Date: Tue, May 29 2018 11:15AM
Subject: Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
← Previous message | Next message →

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

From: Philip Kiff
Date: Tue, May 29 2018 12:55PM
Subject: Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
← Previous message | Next message →

On 2018-05-29 1:15 PM, Duff Johnson wrote:
>> 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.
Fair enough. And the same argument would hold for my "Quandary 2" about
Links and References in the TOC as well.

I haven't been in the habit of reviewing bugs or posting feature
requests to Freedom Scientific or the NVDA team, since I'm not always
confident that my periodic screen reader testing as a sighted PDF
remediator matches the needs or experiences of daily users.

But I guess I should start if I want my (hopefully) standards-compliant
PDF work to be properly appreciated!

Phil.

From: Duff Johnson
Date: Tue, May 29 2018 3:42PM
Subject: Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
← Previous message | Next message →

> On 2018-05-29 1:15 PM, Duff Johnson wrote:
>>> 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.
> Fair enough. And the same argument would hold for my "Quandary 2" about Links and References in the TOC as well.
>
> I haven't been in the habit of reviewing bugs or posting feature requests to Freedom Scientific or the NVDA team, since I'm not always confident that my periodic screen reader testing as a sighted PDF remediator matches the needs or experiences of daily users.

Doesn't stop you from posing the question… the more precise the better, and you know how to do that.

> But I guess I should start if I want my (hopefully) standards-compliant PDF work to be properly appreciated!

Exactly! The worst thing is to "fix" your file to "conform" with a reader software's bug, only to have the bug get fixed. No-one should accept such a world! Insist on standards-compliance up-front! There's even a requirements spec for AT in PDF/UA, should the vendors choose to look…

Duff.

From: chagnon
Date: Tue, May 29 2018 3:57PM
Subject: Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
← Previous message | Next message →

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 ADDRESS REMOVED =
— — —
PubCom: Technologists for Accessible Design + Publishing
consulting ' training ' development ' design ' sec. 508 services
Upcoming classes at www.PubCom.com/classes
— — —

From: Duff Johnson
Date: Tue, May 29 2018 4:32PM
Subject: Re: PDF/UA Quandary 1 - Bullets in LBL tags - Does this interrupt current expected screenreader flow of text?
← Previous message | No next message

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

Yep. Nothing forcing them to do it this way; it's simply their choice in their implementation.

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

The NVDA folks have done a pretty good job compared to some others. But it's not just the AT! Adobe is also responsible for improving their accessibility API (still by far the most important such in the industry), Microsoft is also responsible for ensuring they generate high-quality tagged PDF, Apple is responsible for ignoring tagged PDF in their viewer and in iOS, and so on.

People say they "support PDF" - well… do they support *tagged* PDF? That's the accessibility question.

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

No, the behavior is up to them; the spec does not tell them how to implement lists in their UI. The spec simply makes it possible for the developer to choose what to do about Lbl tags when they are encountered. You are describing a case where the developer chose to simply regard <Lbl> as "some tag" and not consider that it's actually (semantically) labeling the content in the corresponding <LBody> structure element. Had they done so, they might have made a different decision on the experience they would provide to the end-user.

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

It takes a village; true that.

> 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 PDF Association exists to promote awareness of these specifications, and we've published documents (Matterhorn Protocol, PDF/UA Reference Suite, etc.) specifically to assist developers (such as AT developers) understand what to do. The PDF Association's PDF/UA TWG is presently working on its Tagged PDF Implementation Guide, which I hope will be finished by the fall - it'll be >50 pages of solid implementation advice on authoring and processing tagged PDF.

Our publications are always free. The door's always open for interested developers, but we can't make ‘em show up...

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

All true!

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

Could not agree more!

Duff.