WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Table column headers and scope attribute

for

From: Alan Zaitchik
Date: Mar 20, 2023 7:34PM


Thank you, Laura and Duff! Those are actually the responses I hoped for since they proved me “right” in my earlier stubborn directions to developers. :)
It’s often hard to urge recoding when harried and hurried developers argue “but we tested with screen readers and it was ok!” I confess I’ve never tested with the “read cell” command, so thank you Laura for pointing that out.
Duff, you’ve got me curious now. How will PDF/UA 2 approach these issues? Do you mean table related requirements in particular or standards-AT relationships in general ?
By the way, for anyone interested, I found that VoiceOver assumed the TH-TD association desired even without explicit scope. And CommonLook validator did flag a failure in this case. So truly the AT and various testing tools are inconsistent.

A

> On Mar 16, 2023, at 11:30, Duff Johnson < <EMAIL REMOVED> > wrote:
> 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