WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: PDF Table column headers and scope attribute

for

From: Karen McCall
Date: Mar 21, 2023 6:42AM

Just to clarify, I meant the large batch processing remediation services, not the smaller ones depending on Acrobat, Foxit or other tools. The smaller remediation services tend to go down the Tags Tree instead of defining an accessible PDF as a "clean X report".

Cheers, Karen

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Karen McCall
Sent: Tuesday, March 21, 2023 6:10 AM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] PDF Table column headers and scope attribute

+1

I use adaptive technology and seldom use any of the automated tools except for the on-board accessibility check in Acrobat to ensure that I didn't miss anything in terms of syntax when going down the Tags Tree.

I agree that the automated tools are buggy and depending on the automated tool, you get different results on the same PDF which is frustrating. I recommend that if an organization is going to use an automated tool, they stick to one tool and don't even consider others.

I'm also finding the remediation services are creating their own automated tools that resemble the look and feel of PAC so you never know whether the results are accurate or not. I've also seen PDFs from remediation services that pass all their checkers but are all <P> tags where the document has headings and lists.

Cheers, Karen

-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Steve Green
Sent: Monday, March 20, 2023 9:52 PM
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] PDF Table column headers and scope attribute

This is exactly why you need to be very wary when using assistive technologies as testing tools. They are buggier than proper testing tools, none of them fully support HTML5 and ARIA, and they often use heuristics to improve the user experience when the coding is wrong.

I don't even trust "proper" testing tools, so I do the majority of my WCAG conformance testing by code inspection, whether it's a website or a PDF. If I use any kind of tool or assistive technology, I do it after the code inspection and I verify the results by inspecting the code.

We have recently been comparing Axe and ARC extensions for Chrome, and it's surprising how often they give different results, given that they are essentially the same type of tool. Likewise for PAC2021 and Commonlook PDF Validator when testing PDFs.

All this is not to say that we shouldn't test with assistive technologies. It's just that it's a completely different activity than a WCAG audit.

Steve Green
Managing Director
Test Partners Ltd


-----Original Message-----
From: WebAIM-Forum < <EMAIL REMOVED> > On Behalf Of Alan Zaitchik
Sent: 21 March 2023 01:34
To: WebAIM Discussion List < <EMAIL REMOVED> >
Subject: Re: [WebAIM] PDF Table column headers and scope attribute


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