3 ms·
I understand and agree with the general argument, but is it actually true that screen readers for the web are that naive? I would expect them to render a page (
by baddox 12y ago
I understand and agree with the general argument, but is it actually true that screen readers for the web are that naive? I would expect them to render a page (like with WebKit) and try to figure out the layout of the page, which things are actually visible, etc., or at least use heuristics to figure out what is and isn't content (in the same way that Readability-esque algorithms presumably do).
- Figs 12y ago> Readability-esque algorithms presumably do They look for the div with the most text/paragraphs in it and assume that's the article. At least, that's what the open source ones I looked at a while back do -- the proprietary ones that force you to go through their own server could use other tricks.
- extra88 12y agoThe 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.