Copy link to clipboard
Copied
Hello,
I have data tables in which several rows are merged. The headers are appropriately tagged, the col and row span reflects the merged cells, but the reading order is off because the merged cell is only read in-line with the first row in which it appears. For example, I have 3 columns and 6 rows of data and the first three rows have a common data point (apples) in the last column so I merged the three cells within that column to reflect (and highlight) the common data point. I am trying to figure out a way in which that merged cell is tagged so that the reader reads it three times instead of once with the first appearance. Currently, the reader would would apples with 2005 and "data", but not with 2006 and 2008.
Any help is greatly appreciated.
Header 1 | Header 2 | Header 3 |
---|---|---|
2005 | data | apples |
2006 | data | |
2007 | data | |
2008 | data | oranges |
2009 | data | bananas |
2010 | data | strawberries |
Copy link to clipboard
Copied
Any chance you could rearrange your columns? Maybe place your third column as first? Then apply Table Header tags and Span sets as Row Headers? I could be totally wrong, but I think if the Apples cell was defined first, and made a Row Header with the appropriate span, then "Apple, 2005, data;" Apple, 2006, data; etc., might play out. Worth a test, at least.
Copy link to clipboard
Copied
Thanks for you response. Yes, that could potentially work for some of our tables but unfortunately some have merged rows in difference columns which complicates things.
Copy link to clipboard
Copied
Simple, regular, tables are much easier for AT to read. So, ideally, the 'apples' row should be three rows, each reading 'apples'. This should be done in the source document. If it can't be done in the source document, it could still be done in the PDF tag structure using a bit of creative span tags and actual text.
If that isn't practical - if for some reason the table must be complex - tag it correctly using the span property in accordance with ISO-14289/The Matterhorn Protocol. If the table is properly tagged and 'the reader' (you don't specify what reader - is it Adobe Read Out Loud, or NVDA, or JAWS, or ??) does not read it properly then the reader is broken and the maker of the reader needs to fix it.
Without a consistent standard (ISO 14289), trying to get an arbitrary document to be read correctly by an arbitrary reader, is a wild goose chase. If all PDFs and all readers follow ISO 14289, then all documents will be read properly by all readers.
Copy link to clipboard
Copied
We're using NVDA for now and have considered testing out different readers. I'm wondering though, would a different reader really make a difference if the tag order doesn't reflect the merged cell accurately?
Copy link to clipboard
Copied
This is not a real fix, but I can suggest a cheat while trying to solving the same problem.
I have been creating the table as a simple (one header, one column) table with no merged cells (using InDesign), and coloring the data that needs to be screen read white, same for the cell borders that need to be 'invisible'. The screen reader can read the text, but visually it is not repeated.
Find more inspiration, events, and resources on the new Adobe Community
Explore Now