The browser, not the screenreader, does the rendering, figuring out what's visible, etc. The results, an "accessibility tree" which is sort of a subset of the D

The browser, not the screenreader, does the rendering, figuring out what's visible, etc. The results, an "accessibility tree" which is sort of a subset of the DOM, are then presented through an accessibility API to screenreader software. Screenreader software is pretty naive, there might be some that initially assume a table is being used for presentation, not data, if it lacks good semantic structure (e.g. no <th> header elements). Case by case, it's hard to tell in which way the author is bad at their job, using a table for presentation or poorly marking up a table for data. The stakes are much lower for Readability-esque algorithms, when they fuck up the user can just go back to the site's native presentation; screenreader users don't have that choice.