Unifying WCAG and PDF/UA for PDF Footers

In a constant effort to seek unified advice to content authors, I've been comparing PDF/UA Section 7.8 on headers and footers, and WCAG techniques PDF14 (headers/footers) and PDF17 (page numbers) to provide a unified advice to authors.

What does the PDF/UA say about headers/footers?

"7.8 Running headers and footers shall be identified as Pagination artifacts and shall be classified as either Header or Footer subtypes as per ISO 32000-1:2008, 14.8.2.2.2, Table 330."

The reason for this is headers and footers can interrupt screen reader user who hear the repeated in the middle of the main content. Making them up as artifacts causes the screen reader to ignore them.

On the WCAG list, Jonathan of SSB raised concerns about an approach that unilaterally marks headers and footers as artifacts. Important information such as copyright, classified information, form numbers etc. should not be ignored. SSB Bart's webinar interprets the PDF/UA language of "running headers and footers" as distinct from page numbers etc, which change on each page.

"A: PDF/UA indicates that running headers and footers should be made artifacts. Generally speaking, the first occurrence of identical headers or footers should be tagged but the others not, as they interfere with reading. However, many documents have unique headers and footers and may contain different section or page numbers that do not match the actual page numbers. In these cases this information is a “must-have” for users and should be tagged and included in the appropriate location in the reading order. In some cases it may make sense to have footer information read at the top of a form such as the form number of a tax form."

This is reasonable advice, and it would ensure screen reader users get the page numbers etc. However, I didn't interpret the PDF/UA as distinguishing "running headers and footers" from headers/footers that have new sections and pages. Almost every PDF document has page numbers, so it would be odd if the PDF/UA intended 7.8 ONLY for documents that didn't have page numbers. The other problem is that if page numbers were tagged and read by screen readers they could repeatedly interupt a screen reader who might hear something like:

"The Mississippi River is teaming with 32 fish..."
(where 32 is the number of the page not the number of fish)

To be fair, their advice about tagging page numbers is intended for PDFs where header/footer page numbers do not match the actual page numbers.

What does the PDF/UA document do about Headers and Footers?

I think the best way to get clarity on the PDF/UA committee's interpretation of "running headers and footers" is to check the PDF/UA document itself to see how they tagged the page numbers, which are in their footers.

The PDF/UA has tagged the page numbers as artifacts, so I don't think we can interpret 7.8 to say page numbers should be NOT marked as artifacts.

The PDF/UA document follows WCAG Technique PDF17 to provide page information to screen reader users. The page numbers in the page thumbnail panel are in sync with the artifact footer pages numbers.

What do MS Word and Adobe PDFMaker do?

By default, PDFMaker for Microsoft Word and MS Word's native PDF Save As feature mark page numbers as Artifacts which is what is required by the PDF/UA.

What does WCAG Success Criteria 1.3.1 require?

1.3.1 Info and Relationships: Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text. (Level A)

Page numbers in the footer are part of the visual "presentation" and should be "programmatically determinable" (or provided another way).

What should authors consider?

1. WCAG 1.3.1 requires a programmatic way to perceive the information in the header/footer or provide the information in another way.
2. PDF/UA requires authors mark headers and footers as artifacts (so screen readers do not interrupt and repeat headers/footers on every page).
3. Screen reader users need to know what page they are on and to know any other information in the header/footer.
4. The solution should meet the requirements of WCAG and the PDF/UA.

Proposed Solution

1. Mark up headers and footers as artifacts as required by the PDF/UA (this is done automatically if exported from Word)
2. Provide header/ footer information in a prominent place in the main body document. For example:
• Title Page that contains author, date, copyright, classified information, form numbers etc...
• Introduce any information that is changed in the Header/Footer in a prominent place in the main body. (e.g., proper Section Headings)
3. Sync page numbers in the footers with the Page Thumbnail view using WCAG Technique PDF17 so screen reader users can determine the page they are on.

Notes for WCAG members

Note 1: 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 (as in #1-3 above).

Note 2: The WCAG2ICT maps each PDF Document to a single unit rather than a number of pages. It says:

replacing “on a Web page” with “in a non-web document or software”

This means that the document is the unit of measurement for WCAG conformance. It does not affect this discussion about making important information available to screen reader users.

Note 3:

It was proposed that links cannot be marked up as artifacts. MS Word does this if the link is in the footer.

Feel free to comment on Twitter @davidmacd

Author information:

David MacDonald is a veteran WCAG member, co-editor of Using WAI ARIA in HTML5 and HTML5 Accessibility Task Force Member. Opinions are my own.