What would you do? Layout table issue.

[_Crockett_]

I have tables in my document used to lay out lists. Because the author refers to these lists as tables in his text, I thought that I should keep the table structure, but change the tagging of each cell to be its own row. For example, Element 9 would be row 9 instead of row 3, column 3. The title, Elements, stays as a header row, but the column span is not changed because the table is tagged as one column.

Is this a reasonable approach to the remediation?

Elements
Element 1	Element 4	Element 7
Element 2	Element 5	Element 8
Element 3	Element 6	Element 9

[Dave__M]

I am thinking that if you try to redefine the structure of a table, a screen reader will stumble hard on it, and someone required to hear the document read aloud will not easily grasp the structure concept.  I have had 508 coordinators reject anything that is not a standard, textbook-like table.  All that said, I will watch to see what others may think of this.

My best,

Dave

[_Crockett_]

Thank you for weighing in.

I wish I could send it back or at least find out why there are so many tables that do not seem to need to be tables. My guess is that it has something to do with the tables/lists being some sort of table in a database system and it is important to know that to work with the database.

I tested a retagged table with NVDA and it reads okay. Because it reports the number of rows, though, I can see it may be confusing for people who are listening and also looking at the document. Also, I had not considered how much row reorganization is needed to organize the rows so that they read down the first column before moving to the second column. Lists would still seem preferable because there would be a longer pause between items that would be beneficial and the tagging would be much more straightforward.

I was tempted to make the tables lists within a table to get the benefit of lists while staying with the table the text refers to, but stuck with my idea above because it was closer to the page's original intent.

Elements
Element 1 Element 2 Element 3 Element 4 Element 5 Element 6 Element 7 Element 8 Element 9

[a_C_student]

Hi Crockett, you are absolutely correct - non-table content (e.g. a layout table) should not be tagged as a table. Matterhorn Protocol

error condition 15-004 states "Content is tagged as a table for information that is not organized in rows and columns". It is perfectly OK to use a layout table to optimize the user experience of those who read the visual representation of the PDF. For AT users, the content should be tagged as it logically should be read. A list should be a list, a paragraph should be a paragraph, and so on - not artificially embedded in a table. PDF provides the wonderful advantage of separating the visual representation of the document from the presentation by the tags via AT. The reading experience can and should be optimized for all users.

[Dave__M]

Agreed.  I've seen tables in tables, un-ordered lists in tables, and all are generally rejected by agency 508 coordinators.  Although a reasonable layout technique for sighted consumption of a doc, using a table as a layout tool is generally not accepted in 508/Accessibility practice.

My best,

Dave

[a_C_student]

Hi Dave,

"Although a reasonable layout technique for sighted consumption of a doc, using a table as a layout tool is generally not accepted in 508/Accessibility practice."

Yep, and that's a shame. Based on good intentions but incomplete understanding. Accessibility should be about optimizing the reading experience for all users. The AT experience must be judged independently of the visual representation. ISO 14289 (PDF/UA) is a huge leap in the right direction. Conformance to a universal standard - not random misguided individual interpretation of 508 - is the key.