WebAIM - Web Accessibility In Mind

E-mail List Archives

More problems with tables, PDF, and screen readers

for

From: Alan Zaitchik
Date: Apr 3, 2018 4:37PM

Some time ago I asked about table cells that span page boundaries and what people do to make it possible for screen readers to handle them. I thought I was implementing the advice I received, but apparently this has not resulted in success. I would greatly appreciate more advice!

The tables are generated from a Word document, and the header rows are marked as repeating on every page, while other rows are not. All rows are allowed to span page boundaries (because otherwise the document looks atrocious, with tremendous extents of white space). In the PDF I retagged as needed so that a cell does indeed include all the contents it should. That is, if the Word-to-PDF conversion screwed up in some way I manually fixed the situation. (Or I think I did.) I have passed all the PDFs through CommonLook PDF Global Access and they pass with no Failures in any of the multiple standards it tests against. Same for Acrobat Accessibility Checker. I set Acrobat to allow scrolling rather than 1 page view.

BUT what I find is that both JAWS and NVDA do not see the "continuation" of the table onto the next page. Instead they hit the edge of the table on the first page and announce they are at the bottom of the column and the end of the table. If I manually move to the next page JAWS sees a "new" table. Since quite often only one of the cells from the previous page is continuing onto the next page, this "new" table is not really correct in the information it imparts to the listener. The user loses the connection between what is inside the cell that is continuing and the information in the cells that are not continuing (and which exist only on the previous page).
I have tried this with repeating the headers and with not repeating the headers from the first page onto the next. No good either way.

Is this a known limitation of screen readers in general? What do users dependent on screen readers need to be able to handle this situation? My ability to restructure and redesign the tables is very limited, basically none at all! So I guess I am hoping to hear that there is some "header indexing" trick I might use or some magical setting in Acrobat reader which I have neglected or that AT-dependent users are familiar with this situation and work around it. Or that there is nothing I can do but apologize to the client that this is the way it is...

A