Tagging repeating table header

[2econd]

Can anyone suggest how to tag repeating table header rows when the table spans over the several pages regarding the PDF/UA and/or WCAG requirements? Should they be marked as pagination artifacts or maybe included into THead tag?

 

When I convert MS Word document to PDF via PDFMaker it tags repeating rows as regular TR. I assume it is not quite good for accessibility.

[Bevi Chagnon - PubCom.com]

1. No matter how many pages a table is on, the PDF tag tree should show just one <Table> tag, and one set of <TR>/<TH> header rows.  So, the entire table is in one <Table> tag with one repeating row (or rows, for example a header made up of 2 rows)
2. There are 2 steps to designate the repeating header row(s) In MS Word:
   • Select the table and in the Table Design Ribbon at the top left, check the appropriate boxes for Header Row and First Column.
     
   • Select the table and right-click to bring up Table Properties. In the Row tab, UNcheck the option to split rows (that's an accessibility violation) and check to repeat the rows.
     

[2econd]

This is not quite the answer I wanted. Probably my question was not clear enough.

I do understand that table on two pages should be tagged with one <Table> tag. I do understand how to set up repeating header rows in MS Word. But I do not understand how to tag repeated header rows on second table page (third <TR> on my screen). And I did not found any recommendation on WCAG PDF Techiques pages and other resources.

[Bevi Chagnon @ PubCom · Accepted solution]

...I do not understand how to tag repeated header rows on second table page (third <TR> on my screen). And I did not found any recommendation on WCAG PDF Techiques pages and other resources.
By @2econd

Since you only want the headers to appear once in the <Table> tag, then every other instance shouldn't be tagged and, therefore, should be artifacted. Then entire <TR> and its cells and content should be artifacted.

I don't understand why people refer to WEB content accessibility guidelines when making accessible PDFs: they are 2 very different technologies. HTML is a markup language for content, while PDF is a programming language for a structured page-based visual document. The PDF info at WCAG is inaccurate and leaves out a great deal of what's needed for accessibility.

PDF asscessibility guidelines are published by the ISO (international standards organization, see ISO 14289 https://www.iso.org/standard/64599.html.  The PDF Association develops and maintains the standards for all types of PDF (archive, engineering, print, and more), including accessible PDFs, and you can find resources at their website. One to note: The PDF/UA Syntax Guide at https://www.pdfa.org/resource/tagged-pdf-best-practice-guide-syntax/

[2econd]

Thanks for the answer and for the reference to the PDF/UA Syntax Guide.

[Bevi Chagnon @ PubCom]

You're welcome!

[default6i0u6ss6wf59]

"Since you only want the headers to appear once in the <Table> tag, then every other instance shouldn't be tagged and, therefore, should be artifacted. Then entire <TR> and its cells and content should be artifacted"

How do I artifact that entire <TR>? I've been searching for an answer for hours and haven't come across how to artifact a table cell and/or row. My document is almost perfect and this is the only thing I have left to fix!

[Bevi Chagnon - PubCom.com]

How do I artifact that entire <TR>? I've been searching for an answer for hours and haven't come across how to artifact a table cell and/or row. My document is almost perfect and this is the only thing I have left to fix!

By @default6i0u6ss6wf59

Wow.

I'm amazed that your source software program didn't do this automatically for you when the PDF was exported.

Questions:

1. What was the source software program? Need version and platform, too.
2. What method did you use to create the PDF from it?
3. Was the content creator trained in how to make accessible tables in that program?

Why you couldn't find info:

• Maybe the powers that be don't know the answer.
• Or maybe they want you to buy their expensive magic wands that attempt to fix your PDF problems.

Now, on to fixing the hot mess or your table. <grin>

The Table Rules:

1. One <Table> tag for the entire table, no matter how long it is.
2. At least one <TR> table row must be designated as the column headers with <TH> tags instead of <TD> for the individual cells. These will automatically be picked up by the assistive technology and used throughout the table.
3. Table accessibility is mainly based on the table's tags and structure:
   — <Table>
   — <TR> rows that hold individual cells
   — <TH> and <TD> for the individual cells
4. Unlike the rest of the PDF, the content tags are less important because they generally are just body text <P> with an occassional <L> list.
5. No blank rows, and no blank columns.
6. Avoid blank cells in other places because they create an irregular table structure which confuses the he!! out of asssitive technology users. Put something there, even "n/a' or an en-dash or  "data not available."

How to Artifact the crud that's in your table.

Remember:

1. You can't just delete the <TR> tag or even a <TD> tag. That leaves untagged content in your file that will trigger failure in your checker. "Content" = the little yellow bankers boxes, not the tags. Tags only surround and label the content, but aren't content themselves.
2. You must artifact and then delete the entire row, not just one cell.
3. And you can't have more than one <Table> tag for that table. The entire table must be in one <Table>. (It's ok to have more than one separate, independent table.)
4. You must first Artifact the content in the tag. Once the tag is now empty, the tag can be deleted.

• Locate the first cell.
• Expand it so that its yellow content container box is  visible in the Tag Tree.
• Right-click on the content box, select Change Tag to Artifact/Create Artifact.
• At the next pop-up screen, select Page and ignore the stuff on the right. Your content is page content, not page headers/footers/page numbers, nor layout.
• Once the content is artifacted, you'll now see an empty <P> or other tag in the tree which can be safely deleted. Right-click, select Delete Empty Tag.
• Delete the resulting empty <TD> tag.
• Repeat for the remaining <TD> cells in that row.
• Once all the <TD> cells have been artifacted and deleted, then delete the table row <TR>.

It's a process: you're drilling down to the core of each <TD> cell, artifacting the content, and then artifacting the next outer layer. If we use the onion theory, we're starting at the center of the onion and removing the layers from inside to outside.

You might need to do one more task: I can't see your file, but if each page has a <Table> tag that holds its portion of the table, they'll need to be deleted, too, and the rows merged into the main <Table> tag. The steps:

• Select the <TR> rows in the second portion of the table and drag them into the first <Table>. (Be mindful about the reading order.)
• You'll then have an empty <Table> tag which you can delete.

[default6i0u6ss6wf59]

1. Source software is inDesign 2022.

2. It was exported PDF interactive.

3. Yes I've been trained, but my training neglected to mention what to do when a table continues onto a second pages with the header repeating. I did apply the appropriate header tags to the columns and rows. Right now, my table has table header tags sitting at the beginning at the table and repeated again in the middle of the tags. I tried exporting it again to be sure I didn't mistankingly apply the TH to that second page, but if it only gives the option to be TH or TD what option is there when it shouldn't be anything. I'll try your onion approach.

[Bevi Chagnon - PubCom.com]

The repeated Header rows in tables that span 2 or more pages/columns is an error that started around InDesign 2019. The duplicate headers are voiced by screen readers (in our testing) which is very annoying and confusing to some users.

Have no idea what Adobe was thinking when they created this error: they head up the ISO committees that create the PDF standards, including PDF/UA. Plus their engineers are members of the PDF Association's working groups that dream up the accessibility standards and co-author the PDF/UA Best Practices and Syntax Guide (available free at https://www.pdfa.org/resource/tagged-pdf-best-practice-guide-syntax/)

Per 4.2.6.2 of the Syntax Guide (quoted):

Tables spanning multiple pages are structured as a single table.

<TH> cells in repeated header rows or columns (e.g., in the case of tables that span multiple pages) are marked as artifacts.

Two suggestions:

1. Log this bug at www.InDesign.UserVoice.com. Let us know about your bug so we can vote for it. (Such a silly system: we have to vote for bugs to get them fixed!)
    
2. Try the Made To Tag plug-in from Axaio Software. It does a better job of tagging PDFs from InDesign, especially for items like tables, footnotes, and TOCs. https://www.axaio.com/doku.php/en:products:madetotag

[CCPDF]

I experience the same error using Word 365 and saving as PDF to Adobe Pro. It creates a lot of rework when it seems easy enough for Word to fix it. It comes about when tables span multiple pages and the top row is marked to repeat as a header row on each page. Any way to fix this upstream so it doesn't have to be fixed in the PDF tag structure (other than avoid spanning multiple pages)?

[CCPDF]

Please disregard. I was confusing this with a different error. Still learning.

[default6i0u6ss6wf59]

This worked perfectly and didn't take too long either. Thank you for the quick reply.

[Bevi Chagnon - PubCom.com]

You're welcome.

Best of luck to you!

[Beverly337902905zx4]

As long as there are repeated TD or TH tags, a PDF that I'm working on will draw a Regularity Error.  I've had to go in and remove tags that are associated with rows or columns that are repeated across pages.  Only then will it pass accessibility checker.

[Bevi Chagnon - PubCom.com]

I've had to go in and remove tags that are associated with rows or columns that are repeated across pages.  Only then will it pass accessibility checker.

By @Beverly337902905zx4

That doesn't make sense.

Regularity Errors usually happen when the number of columns varies from row to row. This happens when cells inside the table (not header cells) are merged and proper scope and span settings aren't in those cells.

Can you post a screen capture of the table so we can see how it is constructed?