WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF/UA Quandary 2 - Links inside References in TOC - Does this just cause screenreaders to hear duplicate Links?


From: Philip Kiff
Date: Jun 7, 2018 4:29PM

I'm following up on this post to report back to the list about a more
serious screen reader issue with the Table of Contents structure I
described in my initial post below.

While NVDA produces a minor burp by repeating the word Link twice when
reading the Table of Contents, when you use JAWS 2018 to read this table
of contents, JAWS not only repeats the entire TOC entry, but it also
functionally breaks the Links List that you can normally pull up using
Insert + F7. This is a fairly significant accessibility issue because it
renders all the links in the Table of Contents unusable to those screen
reader users who normally rely on using the Links List to navigate the
Table of Contents. Two (out of two) separate screen reader testers
reported back this issue to me.

This presents a quandary because I actually modelled my tagging of the
Table of Contents on the tagging used in the model Matterhorn Protocol
file available here:

When I tested the Matterhorn Protocol file using JAWS 2018, I likewise
discovered that the Table of Contents links in that file are also not
functional via the Links List.

In my testing, if you simply get rid of all the Reference tags and make
the Link tags direct children of TOCI tags, then both NVDA and JAWS read
the Table of Contents correctly, and both of their F7-activated Links
Lists function correctly.

Clearly, this is a bug in JAWS. However, because it is such a
significant bug, and because I suspect that older versions of JAWS
contain the same bug, and because the practical use of the Reference tag
remains unclear to me, and because the PAC 3 checker does not yet flag
an error for Link tags that are direct children of TOCI tags, I would
recommend that folks who are tagging Table of Contents seriously
consider not following what appears to be the correct and recommended
Table of Contents tagging model of the PDF/UA spec.


On 2018-05-29 12:48 PM, Philip Kiff wrote:
> PDF/UA Quandary 2: Links inside References in TOC
> I think that the correct way of tagging a typical Table of Contents in
> PDF/UA is to have each TOCI (Table of Contents Item) tag contain a
> Reference tag, and then to have a Link tag nested inside the
> Reference, so you end up with something like this:
> [TOC]
> - [TOCI]
> - - [Reference]
> - - - [Link]
> - - - - LinkObj
> - - - - Chapter Title
> - - - - Page number
> However, in my testing with NVDA, it seems that this causes the word
> "Link" to be read twice in a screen reader. The first "Link" word I
> guess is the way the screenreader indicates the "Reference" tag, and
> then it repeats the word when it encounters the "Link" tag.
> When I review the PDF/UA spec, it seems that a TOCI can have a
> Reference tag as a child, and the Reference tag can obviously have a
> Link as a child, but it doesn't seem like a Link tag is actually
> permitted as a child of the TOCI on its own. And if I look at how the
> TOC is tagged in the longer reference files provided as part of the
> Matterhorn reference suite of PDF/UA compliant documents, they employ
> the Reference tag with the Link tag nested in it.
> However, in the current state of screen reader software, I don't
> understand what value the Reference tag is adding to the document. Do
> I really need to identify elements in the Table of Contents as
> "References"? If I just remove all the Reference tags and make each
> TOCI entry into a single, simple Link tag, then there is no
> duplication of the word Link. And the resulting PDF will currently
> pass the PAC 3 automated checker as well.
> Maybe the updated PDF/UA specification will change the list of tags
> permitted for use as children of TOCI tags?
> Or, again, perhaps I've misunderstood the best practice for tagging here?
> I don't like the idea that by following a standard correctly, I'm
> actually somehow degrading the user experience.
> Thoughts?
> Philip Kiff
> D4K Communications