JAWS Reader Order of Acrobat Tables (header/data cells)

[yn]

I've run into a major issue with a document that we are working with. The client has provided a Word document with several tables included. We have applied compliance standards to the Word document before saving to a Tagged PDF. Then we have applied additional updates to the PDF document itself, based on tests using PAC 2/PAC 3.

Tables appear to be correctly tagged and structured using <TR><TH> and <TD> tags. Actually, the table reads as I would expect using the NVDA reader but no matter what I do we cannot get this to read the same through JAWS. The client apparently only uses JAWS so we seem to be stuck!

Basically what is expected is that the reader reads column header as a prefix to the table row data cells. As noted, NVDA does this, but JAWS reads the table cell-to-cell, ignoring the header reference text.

Is there something obvious that I'm missing? I've not found much documentation online at all other than a few other users a similar frustration. Thanks in advance for any help that you can provide.

- Noel

[Bevi Chagnon - PubCom.com · Accepted solution]

Your column and row headers <TH> must have their Scope set in order for JAWS to automatically voice them before the data for each cell. Without Scope, JAWS just voices the cell data without the header <TH> info.  NVDA, on the other hand, doesn't let Scope affect how it deals with <TH> header information.

To correct the problem:

1.     Open the PDF in Acrobat Pro.
2.     Enter Table Editor mode.
3.     Select the individual TH cells or the entire header column/row.
4.     Right-Click on a TH cell and select Table Cell Properties.
5.     Set the appropriate Scope from the drop-down menu.

While you're in Table Editor, might as well also set the Row/Column Span information, and add any Header Cell IDs, especially if they are complex headers (more than one col/row). These steps will improve the accessibility of the table.

[yn]

My apologies for the late reply to this.

Thank you for the reply above. The issue was rooted in a misunderstanding of what the client expected the screen reader to do with the table data. The table had column headers, but the client expected the table to read as if it had both column and row headers. With this context, the screen reader would read "column header title, row header title, table cell content." Like an (x, y) coordinate reference. Though technically the table did not have dedicated row headers, we were able to apply such tags through the table editor (basically as you described), but for both column and row headers. It was very awkward to connect the associative dots of what was expected to what  we were actually seeing in the context of the table provided. Design cues are important!

Additionally, there was also a table break between pages which created a compounded issue to troubleshoot.

Fun stuff, but we learned a lot.

Again, thank you for your reply.

[Bevi Chagnon - PubCom.com]

Your welcome, yn. Glad it helped you.

Now, if only InDesign would let us designate the row headers in INDD files, life would be nicer for those who do accessible PDFs!

Cast your vote for this feature at UserVoice https://indesign.uservoice.com/forums/601021-adobe-indesign-feature-requests/suggestions/31137361-im...​

RE: the table break across pages (and also columns if that's the case), here are some hints...

1. In InDesign, create the table as one table regardless of how many columns or pages it will reflow into. This creates one <Table> tag in the PDF.
2. Set your column header(s) to repeat. Table Options / Headers and Footers.
3. Luckily, InDesign doesn't allow a cell/row to break (or split) across frames, columns, or pages (unlike MS Word) so that shouldn't be a problem in the tagged PDF.
4. Make sure your copy of InDesign is up to date. Earlier versions didn't break tables correctly.

[yn]

Voted, and totally agree with artifacting table elements such as stroke and cell shading. Even the stroke intersections count as untagged elements in half of my tables. So frustrating that I cannot group-select at least but instead end up having to click each 5-pixel intersection of a 12-row, 8-column table.

Thanks for the references for IND table practices. This was unfortunately a Word Doc source direct from client with instructions not to modify as that was out of scope. This particular table was pretty evil as not only did the table break to the next page, the first column cells were visually designed as row headers AND were merged (partially) to span several additional rows. The table broke across the page well enough visually, but in Word where you option to have column headers repeat there was no option (that I'm aware of) to have row headers repeat as well. So what we had was a continuation of the table onto the next page supposedly inheriting the current row header but not actually doing that. PAC listed the table break as incorrect because there was  technically no data in the row header cell after the break. THAT was very confusing to trace, what with the layers of errors playing out from several different issues within this one table.

Huge lessons learned.

[Bevi Chagnon - PubCom.com]

yn  wrote

artifacting table elements such as stroke and cell shading. Even the stroke intersections count as untagged elements in half of my tables.

That's a recent "mistake" added since CC:2018 to PDFs exported from InDesign that Adobe has to clean up. They've been notified about the problem, but if you would, kindly request it at www.InDesign.uservoice.com so that it gets on their radar screen again.

At this time, we're inbetween standards. With the current PDF/UA-1, there is no <Artifact> tag. But that's changing with PDF/UA-2 which is still in development and not yet released. Right now, artifacts are "marked" as artifacts and shouldn't appear in the tag tree or with a gray identifier in the Order panel. They appear as untagged content, which is OK at this time. But that will change in the next couple of years as the <Artifact> tag comes into play and items become "tagged" with <Artifact>, authoring source programs like InDesign get retooled for the new tags/standards, and assistive technologies are updated to recognize and process the new items.

It's more complicated that I wish it was!