6 ms·
I assumed that if ctrl-F works, then screen readers also work. Can you share a bit of information about what tends to go wrong, and/or how document authors can
by marvy 6y ago
I assumed that if ctrl-F works, then screen readers also work. Can you share a bit of information about what tends to go wrong, and/or how document authors can fix it?
- j-pb 6y agoAlmost no documents properly support ctrl-F. You'll get at best single word search, but you won't find coherent sentences. There are arbitrary line-breaks caused by various styling and layout packages (most columns are broken). There are even publishers that purposefully put garbage into the PDF's text layer as a braindead form of "piracy protection". PDF and TeX are broken beyond repair in terms of accessibility. The former because it allows the text and image to be split, and very few people care about text as long as it looks alright. And the latter because it's entire document representation model is based around computation. Knuth purposefully made it Turing complete in a misguided attempt at timelessness (no need for a replacement if it's infinitely extensible right?), which means there is no proper way to view a TeX document as "just text data". I've worked in a library digitising documents, and whenever we encountered PDFs we'd just OCR the damn thing. We need to throw the thing out, swallow the bitter pill of sub optimal kerning, and replace it with HTML asap.
- solinent 6y ago> PDF and TeX are broken beyond repair in terms of accessibility. All that needs to be done is to have a accessible text section of the PDF--then Tex can just include the source of the document minus the Tex commands into the PDF, and PDF readers can have the screen reader work. The text could also just be stored per page, if the blind require to communicate where they found a particular item to a sighted person.
- j-pb 6y agoAs I already wrote. PDF already has exactly that. They separate they have a view layer and a text layer. But it simply doesn't work, because people can't be bothered to get the text right, once the view layer is acceptable. Also TeX minus the tags, is not the final text in any way, because it's not markup, it's code.
- solinent 6y ago> But it simply doesn't work, because people can't be bothered to get the text right, That's hardly "it's broken beyond compare." I think with accessibility formats which represent fully typeset written documents (as opposed to pre-typesetting, like Latex), it's always going to be an issue because they're mainly produced for people who are sighted initially. We should simply start shaming programs which export to PDF wrongly, it's not really a difficult thing to get right.
- j-pb 6y ago"The way a tool is used is the way that is encouraged by the tool." Knuth is one of the most perfectionist computer scientists out there, and he still got it wrong. The market economics are simply not in the favour of people doing extra work, and no amount of shaming will get that to change. The alternative needs to be designed with accessibility builtin, and with decidability/markup as a conscious design choice. We have such a format, HTML. The chances to get academics to use HTML with the coming open access wave are much better than getting them to rewrite all of their TeX templates.
- solinent 6y agoI disagree, I mean HTML would be even worse for text-flow if you rendered a PDF directly to HTML. The text-flow of HTML is not guaranteed, in the same way that the PDF text section is not guaranteed to be correct. It's more about the social economics --but if you can find me a tool that supports the PDF export wrongly, I'll fix it myself. > The market economics are simply not in the favour of people doing extra work, Most of the tools are open-source. Does Word or any of the closed source tools do a bad job of this? That would be the main stopping point I guess. It's still super trivial for them to implement, and shaming them will get their PR team evaluating the risk of not implementing such a feature. You just have to be successful at shaming them. An HTML file also doesn't represent a document on paper, most people writing papers wouldn't switch to a electronic-only format at the moment--each page is carefully typeset and designed, HTML is not at this level even today.
- CJefferson 6y agoMinus the tex commands doesnt work for maths and tables, they are almost all tex commands.
- marvy 6y agoLet's take an example: https://arxiv.org/pdf/1606.06389.pdf https://arxiv.org/pdf/1606.06389.pdf A cursory inspection seems to indicate ctrl-F is fine here? Or am I missing something?
- j-pb 6y agoSingle column layouts often work semi-acceptably for text only, when not purposefully tampered with. However if you try to select the text on page 2, you'll see that the layout engine didn't actually place the formula into its own section. Not only is it broken, with the sum signs missing, it is also jumbled up with the text below it, resulting in weird - text broken formula - text - broken formula - mumbo jumbo. This would make it extremely hard if not impossible to properly follow the paper with a screen reader. The figures on page 6 also produce weird artefacts on the text layer. In HTML for example you'd simply present the alt-text to the person with the screen reader, but TeX doesn't have such a feature in most vector drawing libs afaik. The table on page 8 is also not correct in terms of the text layer. If you select it you can see that you get the top half of the leftmost column followed by the rightmost column, followed by the rest in some order. If I may also direct your attention to this gem on page 9: "Then at least half of allnodeshaveh ̄=lgn =lgn−1(seethepaperforthedefinitionofh ̄),and 2√ thus a potential of Ω( lg n). Therefore, the total heap potential would be lg n). Conjecture: the same construction works for the fancy potential √ √ function, which would give a bound of Θ(n · 4 lg lg n)." Shall I go on ^^?
- marvy 6y agoNo need to go on, that's already more than I bargained for, thank you so much for taking the time to respond :) I suspect we're using different PDF viewers; I'm using the one that comes with my browser. The results are somewhat less disastrous than you describe, but still bad. (I'm seeing maybe half the problems you mentioned.) I'm a bit curious which viewer you're using. I can describe what happens when I copy/paste the stuff you mentioned on pages 2/8/etc., and if you're interested I will, but if you're not interested let me ask a slightly different question: Rather than try to get the screen reader to make sense of the final PDF, would it be easier to just download the original page source from arxiv and let the screen reader deal with that?