> On a related note: is mathML more accessible than an AI generated text of how a human would read the mathematical or chemical formula?
Yes, screen readers would typically allow you to navigate the formulas in ways that are more sophisticated than text (not to mention the issues with translating to Braille, which I don't claim to understand, at all). In fact alternative text is a poor substitute for structured information about the formula, which is what you get with MathML.
Plus, the MathML + screen reader combo is deterministic and debuggable, as opposed to OCR'ing an image.
> There is katex-rs[0] that outputs html and mathML. I'd assume the two could work together and the mathML would be fed to whatever the screen reader receives instead of the image?
Maybe! You are parsing the input twice, but it could be a pragmatic solution. I don't know myself how native apps are supposed to expose MathML to screen readers (or if it is even possible without an embedded browser!).
True, my knee jerk reaction came from seeing this run in the browser... but that does not change the question. RaTeX advertises itself as a renderer for native apps, but how are those apps supposed to implement accessible controls? Does RaTeX offer anything towards that?
I suppose somebody has to ask (and most likely complain) about this: what does RaTeX do for accessibility? I gather that it produces images. I checked the demo, and there's not even an alternative text or an ARIA label, so this seems completely invisible to anybody relying on a screen reader. This is quite a step backwards compared to modern LaTeX, which can now tag equations with MathML within the PDF, or using MathJax, or any other serious tool targeting HTML, like pandoc or LaTeXML.
Is accessibility anywhere on the roadmap for RaTeX?
I believe dginev's Docker image https://github.com/dginev/ar5ivist is very close to what runs on arXiv and can be run locally. It uses a recent LaTeXML snapshot from September.
> The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.
Even after properly tagging your PDF and using Acrobat Reader to reflow the text, you cannot achieve this level of flexibility: https://forallx.openlogicproject.org/html/
Note how Richard's book adapts to any screen size, can change fonts and color schemes, system settings such as 'high contrast' will affect the rendering of the page, and you could even use browser extensions to restyle the page to e.g. use a more dyslexic friendly font of your choice.
This kind of functionality is not afforded by Adobe Reader. Even the official Adobe's example of reflowing that was posted in another thread is quite bad:
https://helpx.adobe.com/uk/acrobat/using/reading-pdfs-reflow...
The reflowed PDF is just stacking all text and removing all non-text visual cues. For example, pairs of name/role are separated by whitespace in the PDF, but after reflowing they are undisguishable from each other (who would be the senior VP, Sunny or Daniel?). In HTML, reflowing would preserve semantically relevant whitespace out of the box.
or dvisvgm, which will produce scalable images. However, images are even worse than PDF in terms of accessibility, which is what the article is talking about.
> Just like a lecturer won't suddenly switch to a German accent when saying words like "schadenfreude" or names like "Friedrich Nietzsche"
Is there a middle ground? Whenever I check my content with a screen reader, uncommon foreign names are often mispronounced in ways that are sometimes almost irrecognisable. Even my name comes out wrong, although it would be understandable (typically, the stress ends up on the wrong syllable).
The article talks about converting LaTeX to HTML, which is feasible today, if only buggy and fragile. This is the textbook the author talks about, which is written in LaTeX (but compiled with LaTeXML instead of pdflatex): https://forallx.openlogicproject.org/html/
The accessibility and reflowability of HTML content, not to mention the ability to customize color schemes, fonts, line spacing, and similar are not possible with PDF, even using Adobe software. Even using the latest PDF 2.0 standard, you are ultimately expected to convert it to HTML if you need all that flexibility (such as via https://ngpdf.com/).
> A 50-page PDF loads a lot faster and shows a lot smoother than an HTML of equal textual length.
Very true! Although they are now comparable, if you rely on the browser native MathML instead of MathJax/LaTeX.
(You can test this on long arXiv HTML papers, e.g. https://ar5iv.labs.arxiv.org/html/1710.07304 is more than 60 pages as PDF. Mind you, the ar5iv default CSS is not great. I would use Latin Modern for formulas, at the very least.)
> I've never seen any modern tools that turn TeX into multifile HTML (one per section).
I believe all of them can do it out of the box now. I know for sure that LaTeXML, tex4ht and lwarp can split by chapter or section.
The tagging work is still highly experimental. A major missing element is equation tagging: for now, you need to produce an 'associated MathML' file externally, for instance using LaTeXML. Even then, PDF readers do not support the MathML tags yet! If anything, I am sure that the LaTeX3 team would appreciate you posting minimal examples of mistagged PDFs.
If you want to produce accessible documents from LaTeX, you should convert to HTML. ATs such as screen readers just work miles better than with PDFs, and given the resources put in developing browsers compared to PDF readers, I don't think this will change any time soon. Luckily conversion from LaTeX to HTML is very feasible today, as proved by arXiv. (Shameless plug: I maintain BookML specifically to help lecturers with the LaTeX to HTML work)
Yes, screen readers would typically allow you to navigate the formulas in ways that are more sophisticated than text (not to mention the issues with translating to Braille, which I don't claim to understand, at all). In fact alternative text is a poor substitute for structured information about the formula, which is what you get with MathML.
Plus, the MathML + screen reader combo is deterministic and debuggable, as opposed to OCR'ing an image.
> There is katex-rs[0] that outputs html and mathML. I'd assume the two could work together and the mathML would be fed to whatever the screen reader receives instead of the image?
Maybe! You are parsing the input twice, but it could be a pragmatic solution. I don't know myself how native apps are supposed to expose MathML to screen readers (or if it is even possible without an embedded browser!).