A faculty member that uses a screen reader to browse our catalog alerted me that the use of nested tables in the OPAC search results cause navigation problems for him. As well as other users of screen readers. I suspect that this issue has existed since we switched to TPAC from JSPAC, but that is only a guess.
After executing a search in the OPAC the URL changes to the URL "/eg/opac/results." In the displayed results page, each item displayed belongs to a cell of an HTML table. Then inside each result item's cell, there is another table with the HTML title of "Record Holdings Summary." This nested table summary holdings content can be quite hard for patrons using screen readers to access. The difficulty arises in being able to navigate inside or escape out of this inner holdings summary table. This is because it becomes extremely hard for the screen reader software figure out if you, for example, want to navigate to the next table row in the inner table or the outer table. So navigation inside the inner table can be really dificult.
The problem gets much worse when the OPAC is displaying the "Show More Details" version of the holdings summary nested table. In that version of the results page, you end up with additional columns and rows inside the nested table, and the additional rows and column make it even harder for screener eager using patrons to navigate successfully.
When working with this faculty member, we tested the EG catalog using JAWS and the OS X's Voiceover to replicate the navigation bug.
My basic understanding of accessibility best practices tells me that we might either want to switch the inner holdings table to use div's instead of tables. Alternatively we can switch the main outer table to use div's instead of a table, and we could keep using a table for the inner holdings summery information. In theory we may want to consider abandoning the use of tables in the results sections altogether. Though the information typically displayed in the summary holdings is the usual textbook use of HTML tables.
I wonder what others think? Can others replicate the issue?
Thanks.
I agree that we should move away from tables, or at least make it clearer that these tables are layout tables, not data tables. This would consist, at the very least, of removing the <thead> elements that are currently present. This article is a very good read about the accessibility implications of layout vs. data tables: https:/
I think that our colleagues in the Blacklight Community have a pretty good solution to this in their search pages, btw. They use divs, and for key/value metadata pairs in the individual search results, they use defined lists: http://