Author here, I'm sorry to hear that it doesn't work well with a screen reader. I tested it with the reader mode of Firefox, which renders MathML perfectly, although I don't know how that would translate to a screen reader. Safari reader mode renders the math inline, like this:
I just define a new derivative operator, like so: dxđ f(x)≡2π1 ⋅dxd f(x). That’s all.
while Chrome's reader mode just fails to recognize the content entirely, even though it's the most basic <body><div id="content"><p> ... structure possible. I have basically zero web dev experience so I don't know how to fix this, maybe I need to tweak the KaTeX settings.
I think it's quite sad that math is so difficult on the web. While setting up the blog, I looked around and it seemed like FF is the only browser with proper MathML support, but I think that was also being phased out because it's apparently buggy and hard to maintain. IMO, the screen reader version should just basically be the LaTeX source, which is probably kind of awful when read out loud, but at least it would be unambiguous.
You used the Katex library for rendering math symbols, which currently emits code that supports MathML and falls back to an HTML rendering (this is my understanding after reading the HTML for a bit). The MathML content is marked up correctly such that browser should be able to construct the a11y tree correctly. I didn't check, but apparently other browsers like FF and Safari construct the a11y tree from the MathML markup correctly.
In short - you didn't do anything incorrect, and AFAIK any temporary fix to improve a11y for Chrome users would involve some heavy lifting in the Katex library.
I suggest interested parties to star the above bug report.
___
Other commenters mentioned the aria-hidden property being set. This is intentional, as without it Safari/FF/compliant screen readers with MathML support would double-read the content. I'm honestly not sure what the ideal markup would be to support both types of browsers - should a solution exist, it may involve using JavaScript to change the markup based on the user agent detected.
My first inclination was to simply run `say` on my Mac comamdn line and paste the line in. That read it correctly. The other commenter called out the `aria-hidden` attribute and I'd guess that's it. It's explicitly hidden.
Apparently this is all intentional as outlined in this bug report.
But note how right above this span there is the <span class="katex-mathml">, which is not aria-hidden, and which contains the MathML representation of the equations. I would have assumed that a screen reader would look at that, since it contains the semantical information.
This does seem like a bug/missing feature in Chrome's a11y tree, which you can see in the DevTools with an experimental feature enabled: https://i.imgur.com/ckWnrlL.png
I bet the "reading" modes of the browsers are just using the HTML that's visible on the page, but that's marked explicitly as hidden from screenreaders, using the aria-hidden attribute.
From what I can tell it's the opposite (on Firefox): the math is in the source HTML twice, once in <span class="katex-mathml">, which is hidden using CSS in the non-reader mode but is rendered in the reader mode, and <span class="katex-html" aria-hidden="true">, which is what FF displays normally, and it's missing from the source when I inspect it in reader mode. Having two spans like this comes directly from KaTeX, whose authors I'm sure have thought about accessibility. I imagined that MathML would be somewhat standard and screen readers would understand it.
Huh, you're right about what the Firefox reader mode does. I'm somewhat surprised it uses the MathML. I'd just assumed what was happening from the 2pi in the header becoming plain text but that header is probably a special case and just from the page title rather than the h1.
I think it's quite sad that math is so difficult on the web. While setting up the blog, I looked around and it seemed like FF is the only browser with proper MathML support, but I think that was also being phased out because it's apparently buggy and hard to maintain. IMO, the screen reader version should just basically be the LaTeX source, which is probably kind of awful when read out loud, but at least it would be unambiguous.