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

We have no power over User Agents, and there is nothing available currently
that an author can do to make headers and footers optionally turn on and
off.

See a full explanation here:
 https://lists.w3.org/Archives/Public/w3c-wai-gl/2015AprJun/0243.html

that is why I think Kerstin's failure proposal is the best way forward. for
reasons I propose here:
https://lists.w3.org/Archives/Public/w3c-wai-gl/2015AprJun/0246.html


Cheers,

David MacDonald



*Can**Adapt* *Solutions Inc.*

Tel:  613.235.4902

LinkedIn <http://www.linkedin.com/in/davidmacdonald100>

www.Can-Adapt.com



*  Adapting the web to all users*
*            Including those with disabilities*

If you are not the intended recipient, please review our privacy policy
<http://www.davidmacd.com/disclaimer.html>

On Thu, Jun 11, 2015 at 7:55 AM, Hoffman, Allen <allen.hoffman@hq.dhs.gov>
wrote:

>  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
>
>
>
> DHS Accessibility Helpdesk
>
> 202-447-0440 (voice)
>
> 202-447-0582 (fax)
>
> 202-447-5857 (TTY)
>
> 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.
>