Tables must contain the same number of columns in each row and rows in each column.
Ensure cells' row span and column span are appropriate. Ensure header cells' Scope is appropriate. To do this open TORU and click on the table's TORU displayed read order number. This makes the "Table Editor" button available. Click it. Right click select the 'outlined' cell and in the presented dialog click "Table Cell Properties".
While the Matterhorn Protocols will be a game changer the current "checkers" (Acrobat Full Check or others) get you to the stadium. Then it's sleeves up and into the structure tree.
Thanks very much for your reply.
The odd thing is that, if I remove the style 'Repeat Headers Rows' in Word and save as PDF, the rule does not fail. Besides, if I check the table structure I noticed that it is correct.
In this link I bring an example: https://dl.dropboxusercontent.com/u/50967656/dos%20tablas.pdf
In this file you can check that there are to identical structured tables, but the first one has set up the 'Repeat Rows Headers' Word property, and only in this table the rule fails.
I really don't know how to fix it.
Sorry, I am unable to verify your assessment of the table structure as correct. In both tables the Span property of each table cell that spans multiple columns is incorrect. The Scope property of the header cells also has not been set. CtDave wisely advised checking these very properties.
Both tables pass the Acrobat X accessibility check by the way. Just more evidence (if any were needed) that the Acrobat accessibility check is highly inadequate. The free PDF Accessibility Checker (PAC) from the Swiss foundation Access for All is far superior. The Span problems are immediately obvious in the PAC “Preview” view, and the PAC accessibility report reveals a number of additional accessibility errors that you will probably want to take care of. But, as CtDave also wisely points out, no automated checker can fully take the place of a knowledgeable inspection of the structure tree.
Hope this is helpful.
a ‘C’ student
Hi a 'C' student,
Thanks very much for your reply.
I would like to clarify some items.
First of all, as I said in the first post, I have tested the form with Adobe Acrobat Pro IX, while you have tested it with Adobe Acrobat Pro X.
Finally, I would like to repeat that this form is not accessible because of the headers table, as I said in my previous post. In order to show you that I add this image:
I do really need some help in order to find out what I am doing wrong.
Sorry to not be clear. Let me try again …
The Acrobat accessibility checker, regardless of version, is highly inadequate and never to be relied on for more than a quick first check. Your example of one of many where the Acrobat accessibility checker provides results that are curious, to put it politely. The PAC from Access for All is the best available automated PDF accessibility checker, and it is free (although the good people at the foundation appreciate donations). Google will find the free download easily. However, no automated checker can take the place of manually, knowledgeably checking the tag structure, table cell properties, etc.
To summarize what you are doing wrong:
(1) You are using an inadequate testing tool that is providing you with incorrect results
(2) You have not set the Column Span property of the cells that span multiple columns
(3) You have not set the Scope property of the header cells
(4) The PAC identifies ten instances of another error, which Acrobat misses completely - the inclusion of graphical table elements (the lines between rows and columns) in the table structure. These should be converted to background artifacts.
(5) While you are at it, spaces and return characters used for visual formatting do not add value in the document structure and as a best practice should be converted to background artifacts.
I took the liberty of repairing your example file but I will not be able to share it until this evening. I will post the link around 7:00 PM Pacific time.
I do really appreciate your replies, they were very helpful.
However, I really have to use PDF Accessibility Checker because the company I work for has bought this product licences in order to check document's accessibility. So, I cannot use another tool to check them, I can only use PDF Accessibility Checker.
Reading Acrobat's website I can find this: "Use Adobe® Acrobat® XI to help meet accessibility standards by creating files that make it easier for people with disabilities — such as blindness, low vision, or mobility impairments — to interact with your PDF documents and forms.". So, perhaps it is not the best tool, but it must work, isn't it?
I have downloaded the file you attached, I have run the accessibility checker but it still fails the Regularity rule.
I have checked the table's structure and as you said, it is correct, but it still shows this error. I really don't know what can I do.
Thanks very very much for your help!
Ah, your company has an "It must pass the Acrobat checker" rule. In that case you will have to deal with every quirk and foible the Acrobat checker throws at you. I downloaded the trial version of Acrobat XI to see what you are dealing with. In this case, the Acrobat checker is taking a very literal interpretation of the Regularity rule: "Tables must contain the same number of columns in each row and rows in each column". To be sure, that is a best practice for accessible tables, but I have not seen it before as a hard rule. The whole point of the Span property is to deal with irregular tables. With this strict interpretation, you cannot have columns that span multiple rows. One fix would be to go back to the Word documents and restructure the tables. If that is not practical and you need to "fix" the PDF to pass the checker, go into the Tags pane and add blank cells, <TH> in this case, to the first and third row, so that each row in your table has the same number of cells. If you took my previous advice and changed the Column Span property you will need to set it back to 1.
I have no idea why the Acrobat checker is using a different interpretation of the Regularity rule on tables that have headers and tables that do not - one of many quirks that you are likely to come across.
Here is the example table, configured to pass the Acrobat XI accessibility checker. It is less accessible than before, but if your employer has somehow mis-defined PDF accessibility to mean passing the Acrobat checker, you may just have to live with it.
Thanks very much a 'C' student!
The solution is a bit messy, but it works!
I was having the same issue with the Acrobat full-check. I tested it with a few files I'd previously done — some from InDesign, some from Word. One solution that seems to work (although I'm still not sure why) is to include <THead> and <TBody> tags in your table structure. This seems to pass both the Acrobat full-check and the PAC checker. This works with merged cells (with the appropriate column and row spans set). See the attached image. The other tag you may need to include is <TFoot> if your table has a footer.
Here's a sample tag that works:
Hope this helps!
Acrobat Full Check - PAC. 6 of 1, 1/2 dozen of the other. Use both. Both have flaws. Know 14.8 of 32K & PDF/UA-1 and you can steer your way around them.
"C's" table remediation - spot on - IDs & Header IDs are the critical attribute for tables of such a stripe.
<THead>, <TBody> ---read the discussion in ISO 32000-1; the explanation can be read there. (Source docs do trump eh)
I'm assuming you mean his first remediation, which is quite correct. The second file (and he mentions it) is a table that is much less accessible. My point was not to get around properly tagging a table but to get Soledad a solution that did that AND pass the Acrobat checker.
Do you have a link to the discussion you mentioned? Is that here on the Adobe site? Are there issues with the <THead> and <TBody> tags?
And do you have any idea why the Acrobat checker would fail the "Regularity" test in one case and not the other (that is with or without <THead>, <TBody> tags)? It's perplexing.
OK, I'm an idiot. Whet the heck is the Table TORU?
TORU stands for Touch Up Reading Order Touch Up Reading Order tool for PDFs (Adobe Acrobat Pro)
One of the accessibility tasks it is useful for is to fix the tagging of simple tables, and prepare complex tables for more advanced manipulation in the logical structure tree.
In addition, please note that even if the name suggests it is a 'reading order tool', the best way to fix the reading order is by using the Tags Panel. Find some more information about TURO and reading order at https://webaim.org/techniques/acrobat/acrobat