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

Just so I am following this accurately.

If a document does not have page numbers, headers or footers are we requiring that such are provided?  I don’t believe this would be wise.


If page numbers, headers or footers are provided it seems what we are discussing is the encoding based on how screen readers read the content, in linear sequence, or in another sequence at the preference of the user.

If we want user control of how such information is read it should be coded to allow such and let default reading sequence be at the selection of the screen reader or other product manufacturer and then provide the alternative options as part of the assistive technology.

Does this change the thinking in any way?



I fully understand the difference in preferences for this as a screen reader user, and the preference for me changes based on the type of material I am reading, so its not an all oor nothing kind of user preference.




Allen Hoffman
Deputy Executive Director
The Office of Accessible Systems & Technology
Department of Homeland Security
202-447-0503 (voice)
allen.hoffman@hq.dhs.gov<mailto:allen.hoffman@hq.dhs.gov>

DHS Accessibility Helpdesk
202-447-0440 (voice)
202-447-0582 (fax)
202-447-5857 (TTY)
accessibility@dhs.gov<mailto:accessibility@dhs.gov>

This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain sensitive and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited.  If you have received this message in error, please reply immediately to the sender and delete this message.  Thank you.

From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Thursday, June 11, 2015 7:23 AM
To: Jonathan Avila
Cc: Hoffman, Allen; Gregg Vanderheiden; GLWAI Guidelines WG org
Subject: Re: Should PDF documents have headers and footers on every page?

>>>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 pagination.
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:56:49 UTC