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 4:32PM

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