E-mail List Archives

Search E-mail List Archives for

Number of posts in this thread: 8 (In chronological order)

From: Alan Zaitchik
Date: Thu, Mar 16 2023 9:00AM
Subject: PDF Table column headers and scope attribute
No previous message | Next message →

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). This advice was based on Matterhorn 15-003. I also seem to recall the old PAC-3 flagging it as a failure if scope isn’t specified, although my memory might be wrong there.
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!
My questions are:
1. Can anyone point to a “significant AT product and PDF reader combination“ that does not implicitly assign correct scope when it is not explicitly coded?
2. Is the absence of the scoped attribute (when IDs and Header array mechanism is not used) a “formal failure” of PDF/UA accessibility? What is the normative status of the Matterhorn protocol?
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? 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.

All feedback welcome!

A
> On Mar 9, 2023, at 14:00, = EMAIL ADDRESS REMOVED = wrote:
>
> Send WebAIM-Forum mailing list submissions to
> = EMAIL ADDRESS REMOVED =
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> or, via email, send a message with subject or body 'help' to
> = EMAIL ADDRESS REMOVED =
>
> You can reach the person managing the list at
> = EMAIL ADDRESS REMOVED =
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WebAIM-Forum digest..."
> Today's Topics:
>
> 1. Incorrect reading behaviour by JAWS and NVDA for the same PPT
> slide. (Nibin Mathew (SO/OPM33-IN))
> 2. Re: Incorrect reading behaviour by JAWS and NVDA for the same
> PPT slide. (David Farough)
> <mime-attachment>
> <mime-attachment>
> > > >

From: Laura Roberts
Date: Thu, Mar 16 2023 9:07AM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →

I personally would still set scope.
In JAWS there's a command to say the contents of the cell. If the scope
isn't set, then JAWS will not read the header.
For example, without scope set, JAWS will just say the row and column
numbers. That doesn't tell the user anything useful.
With the scope set, JAWS will say the column header (of that cell) followed
by the row header (if scope is set for it) and then the cell contents...and
then the user knows exactly where they are without having to move around
the table.
I don't really care what the Matterhorn protocols say about this, only the
end user experience.


On Thu, Mar 16, 2023 at 11:01 AM Alan Zaitchik < = EMAIL ADDRESS REMOVED = >
wrote:

> 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). This advice was based on Matterhorn 15-003. I also
> seem to recall the old PAC-3 flagging it as a failure if scope isn’t
> specified, although my memory might be wrong there.
> 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!
> My questions are:
> 1. Can anyone point to a “significant AT product and PDF reader
> combination“ that does not implicitly assign correct scope when it is not
> explicitly coded?
> 2. Is the absence of the scoped attribute (when IDs and Header array
> mechanism is not used) a “formal failure” of PDF/UA accessibility? What is
> the normative status of the Matterhorn protocol?
> 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? 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.
>
> All feedback welcome!
>
> A
> > On Mar 9, 2023, at 14:00, = EMAIL ADDRESS REMOVED = wrote:
> >
> > Send WebAIM-Forum mailing list submissions to
> > = EMAIL ADDRESS REMOVED =
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > https://list.webaim.org/cgi-bin/mailman/listinfo/webaim-forum
> > or, via email, send a message with subject or body 'help' to
> > = EMAIL ADDRESS REMOVED =
> >
> > You can reach the person managing the list at
> > = EMAIL ADDRESS REMOVED =
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of WebAIM-Forum digest..."
> > Today's Topics:
> >
> > 1. Incorrect reading behaviour by JAWS and NVDA for the same PPT
> > slide. (Nibin Mathew (SO/OPM33-IN))
> > 2. Re: Incorrect reading behaviour by JAWS and NVDA for the same
> > PPT slide. (David Farough)
> > <mime-attachment>
> > <mime-attachment>
> > > > > > > > > > > > >


--
Best regards,
Laura Roberts
413-588-8422

From: Duff Johnson
Date: Thu, Mar 16 2023 9:30AM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →

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

From: Alan Zaitchik
Date: Mon, Mar 20 2023 7:34PM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →


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 ADDRESS 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

From: Steve Green
Date: Mon, Mar 20 2023 7:52PM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Alan Zaitchik
Sent: 21 March 2023 01:34
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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

From: Karen McCall
Date: Tue, Mar 21 2023 4:09AM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →

+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 ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 20, 2023 9:52 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Alan Zaitchik
Sent: 21 March 2023 01:34
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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

From: Karen McCall
Date: Tue, Mar 21 2023 6:42AM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | Next message →

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 ADDRESS REMOVED = > On Behalf Of Karen McCall
Sent: Tuesday, March 21, 2023 6:10 AM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Steve Green
Sent: Monday, March 20, 2023 9:52 PM
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS REMOVED = > On Behalf Of Alan Zaitchik
Sent: 21 March 2023 01:34
To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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

From: Duff Johnson
Date: Tue, Mar 21 2023 9:44AM
Subject: Re: PDF Table column headers and scope attribute
← Previous message | No next message

> 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 ?

It’s not a simple story.

In essence, PDF 2.0, on which PDF/UA-2 is based, changed some definitions in ISO 32000, the “core” PDF specification. PDF/UA then leverages the updated language in PDF 2.0…

For now, until there’s a more succinct overview, it’s probably simplest to quote from them both (may ISO forgive me…):

ISO 32000-2, 14.8.4.8.3:

If the Headers attribute (see 14.8.5, "Standard structure attributes") is not specified, any cell in a table may have multiple headers associated with it. These headers are defined either explicitly by the Headers attribute, or implicitly, by the following algorithm:

To find headers for any data or header cell, begin from the current cell position and use the current value of WritingMode to search towards the first cell in the appropriate horizontal/vertical direction. The search terminates when any of these conditions is reached:

the edge of the table is reached
a data cell is found after a header cell
a header cell has the Headers attribute set — the headers that are specified are appended to the row/ column list that is being built

When a header cell is found in the search and the (implicit or explicit) Scope attribute of the header cell is either Both or Row/Column, the header cell is appended to the end of the list of row/column headers, resulting in a list of headers ordered from most specific to most general.

NOTE This algorithm works for languages with different intrinsic directionality of the script (such as right-to-left) because the structure always reflects the logical content order of the table.

To the above, PDF/UA-2 will add, in 8.3.4.26:

Tables shall be regular.

NOTE 1 Tables are regular when the number of logical cells is equal in each row after accounting for RowSpan and ColSpan attributes.

Row groupings formed by THead, TBody and TFoot structure elements shall be regular.

NOTE 2 Row groups are regular when the number of logical cells is equal in each row after accounting for RowSpan and ColSpan attributes and where cells do not span row groups.

When a table contains header cells, that table shall provide sufficient semantic information to allow accurate determination of which of its table header cells (structure element TH) pertain to other cells (see ISO 32000-2, 14.8.5.7).

ISO 32000-2, 14.8.4.8.3 describes an algorithm to determine header cells for a cell in the table. If the algorithim results in default values for Scope (see ISO 32000-2, Table 384) that are insufficient to describe the relationship between the header cell and other cells, then the Scope attribute shall be specified.

If the algorithim results in a header cell with an implicit or explicit Scope that cannot describe the header/cell relationships for all of the cells in the table, then the Headers attribute shall be present for all cells to which a header applies (see B.4).

NOTE 3 This means that once the Headers attribute is used it is required for all cells that have headers in the table regardless of whether Scope describes their relationships.

As noted in ISO 32000-2, Annex L, Table rows (TR) may include both TH and TD cells.

NOTE 4 The use of Headers does not negate the need for Scope.

Examples of table-specific attributes are provided in Annex B.4.

NOTE 5 End user reliance on assistive technology implies a need for as much information as possible about the structure of tables. Table header cells play a key role in providing structural information.

NOTE 6 Tables can contain column header cells, row header cells, both, or none.

Duff.