WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Table column headers and scope attribute

for

From: Duff Johnson
Date: Mar 16, 2023 9:30AM

Hi Alan,

> I’ve told PDF developers for years that data table column header TH cells require scope set to “column” (unless IDs and the headers array are used to create associations).

You are correct.

> What I'm now finding, however, is that for simple (regular) tables even when scope is not specified JAWS and NVDA consistently and correctly read the table headers; they correctly figure out that the TH cells have a column scope. Not only that, PAC 2021 and Acrobat A11y Checker don't report a failure. (Haven't yet checked with CommonLook or Crawford tools or others.) SO I'm wondering if this requirement makes a difference for these simple cases and whether it's even a formal PDF/UA requirement!

It is a formal PDF/UA requirement…

ISO 14289-1:2014 (PDF/UA-1) says:

"Structure elements of type TH should have a Scope attribute. If the table's structure is not determinable via Headers and IDs, then structure elements of type TH shall have a Scope attribute."

(emphasis added)

> 2. Is the absence of the scoped attribute (when IDs and Header array mechanism is not used) a “formal failure” of PDF/UA accessibility?

As PDF/UA-1 says, if Headers and IDs are not present, then yep, you SHALL have a Scope.

> What is the normative status of the Matterhorn protocol?

The Matterhorn Protocol was developed as an industry collaboration by the members of the PDF Association's PDF/UA Technical Working Group as a freely-available representation of the requirements (“shall statements”) in PDF/UA-1. It is not normative but informative. If PDF/UA-1 and Matterhorn conflict, PDF/UA-1 rules.

But it was written to be very very tight to PDF/UA-1.

Matterhorn is undergoing a redevelopment phase right now.

> 3. Even if this is deemed a failure, might the priority of fixing this failure anyway be considered very low given my observations about JAWS and NVDA (and PAC 2021) not caring?

My view: even if software can “figure it out” that doesn't mean that all software will “figure it out” the SAME way. What about a table that has a single merged cell on row 43, on the 2nd page of the table?

The combination of sloppy authoring and reliance on maybe-smart-enough software is exactly what led to the need for PDF/UA in the first place.

Deterministic outcomes are kind of…. the whole point of standardization.

> Note again that I am NOT talking about complex tables, just simple regular tables on a single PDF page, no merged cells with colspan>1 or rowspan>1, etc., etc.

Assuming that authors and remediators (and indeed, software) will make these same distinctions and recognize “simple” and “complex” the same way is…. fraught.

Better, IMO, to provide simple, clear rules… as PDF/UA-1 attempted to do.

FWIW, PDF/UA-2, currently in DIS, and to be published later this year, takes a consistent, but somewhat different approach to this normative requirement.

Duff Johnson
PDF Association
pdfa.org