Re: PDF14 Running headers and footers

> You say: We will need to update WCAG PDF14 to ensure it is clear that headers and footers will become artifacts and that the information needs to be available through other means.

I disagree. IMHO, the right thing to do is simply to junk PDF14. It adds near-zero value, especially given that AT software (all of it, so far as I know) simply ignores artifacts. 

What’s more the “Procedure” given in PDF14 for testing doesn’t even reference artifacts one way or the other. Plus, in my view this Technique does not (as opposed to what’s claimed for it) service SC 3.2.3; headers/footers are not “navigational mechanisms” - they are merely content marked as artifact.

> PDF14 states: The objective of this technique is to help users locate themselves in a document by providing running headers and footers via pagination artifacts.

Since page headers/footers are programmatically generated to represent what is otherwise heading (H1, H2, etc.) information, they are (at best) duplicative of headings in terms of aiding users in locating themselves in the document.

> How would this technique accomplish this if the information in headers/footers that is marked as an artifact is invisible to screenreader users?

It would not.

> And what is your opinion about the fail in the eiii pdf checker (http://checkers.eiii.eu/en/pdfcheck/) ? How should one interpret this in the light of the above? Is it a real fail for PDF documents? And is it a problem if some text in the header/footer is marked as an artifact in InDesign but not as a header/footer subtype (assuming the important information in this text is also added to the main text on the front page).

As David correctly notes, page headers and footers are required to be artifacts by PDF/UA precisely to eliminate the (large) potential for confusion and complete un-readability if headers/footers are tagged.

That is the full extent of accessibility interest in page headers and footers. Given that headers/footers come from the document’s structure, and if the document structure has been provided in a programmatically-accessible way (per SC 1.3.1), then there’s really no argument (with respect to accessibility) for page headers/footers at all.

Right or wrongly, screen-readers ignore artifacts, so step 3 in the solution David suggests in his article (aligning page-numbers in headers/footers with “actual” page number) does nothing for screen-reader users. 

Better to ensure that the PDF’s page labels are aligned with the actual page-names intended by the author and (presumably) reflected in header/footer text. This is discussed in PDF17.

All the best,

Duff Johnson

Independent Consultant
ISO 32000 (PDF) Intl. Project Co-Leader & US Chair
ISO 14289 (PDF/UA) Intl. Project Leader & US Chair

p  +1.617.283.4226
e  duff@duff-johnson.com
w  http://duff-johnson.com
l  http://www.linkedin.com/in/duffjohnson/

Received on Friday, 7 April 2017 17:50:47 UTC