W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2015

Re: Should PDF documents have headers and footers on every page?

From: David MacDonald <david100@sympatico.ca>
Date: Thu, 11 Jun 2015 07:22:47 -0400
Message-ID: <BLU437-SMTP1398A42F00F082CC56AE15FEBC0@phx.gbl>
To: Jonathan Avila <jon.avila@ssbbartgroup.com>
CC: "Hoffman, Allen" <allen.hoffman@hq.dhs.gov>, Gregg Vanderheiden <gregg@raisingthefloor.org>, GLWAI Guidelines WG org <w3c-wai-gl@w3.org>
>>>Well, it could be a user agent option.  For example, there is a specific
artifact type for pagination – so there seems like the option to expose
this information on request since it already has to be properly coded as

David response:
There are a couple of ways to respond to that. The first is that I'm not
sure that would be so easy. If "user agent option" means the screen reader
could query for the pagination artifact and have a setting to speak it or
not, I don't think so. I don't think the Screen reader has access to the
code, it only has access to the tag tree. And from what I can see, there
does not appear to be a distinction between a pagination artifact and any
other sort of artifact.

If you mean that the PDF reader could expose it, that would be possible,
but it would have to sniff for that artifact in the code and then convert
it to some sort on other tag in the tag tree so that the screen reader
would recognize it, yet ignore other types of artifacts in the document.
Further, there is no distinction between pagination artifacts that are
changing from section ti section or page to page and other types of running
headers and footers which are also pagination artifacts. The PDF spec is
not that granular.

All this to say that I don't think this is a realistic expectation, and an
onerous demand upon user agents, and difficult to implement with the
current PDF standard.

The second way to answer this is that WCAG attempts to solve the
*practical* problem of inaccessible content now, rather than shoot for a
theoretical target. So our "accessibility supported" requirement wouldn't
make assumptions that in the future this or that user agent behaviour could
overcome a particular problem. The content fails now if it is not
accessibility supported now.

All this to say I'm in favour of Kerstin's failure suggestion,
"Failure of 1.3.1 due to information in the header or footer not being
available in main body of the document"
 and a reworking of PDF14 so it is consistent with itself.
Received on Thursday, 11 June 2015 11:23:20 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 16 January 2018 15:34:19 UTC