The first thing to say plainly is that the long, slow argument about whether browsers should render mathematics natively has been settled. Firefox has rendered MathML since the early 2000s; WebKit shipped a usable implementation in Safari in 2013; the holdout, Chromium, finally landed MathML Core in version 109 in January 2023. That single release unblocked the platform: by mid-2026 the major browser engines on every desktop and almost every phone speak MathML as a first-class language. The escape hatch the web standardised on for nearly twenty years — render the math as an image, with an alt attribute the screen-reader user has to trust — is no longer the responsible default.

What changed in 2023 is narrower than the headline suggests. Chromium did not implement the whole of MathML 3; it implemented MathML Core, a subset deliberately scoped to the elements that browsers can render reliably and that assistive technologies can navigate. Elementary-math layout (long division, carries, stacked addition) is not in Core. Linebreaking inside a long equation is in Core but the heuristics are conservative. Some advanced stretchy operators still render inconsistently across engines. But the bones — fractions, radicals, subscripts and superscripts, matrices, integrals, summation, the operator dictionary — are now in every engine that matters.

The accessibility consequence is direct. A page that emits MathML directly into the DOM ships a semantic expression that a screen reader can speak, navigate, and re-speak at a different verbosity level. A page that emits an image with an alt attribute ships a single sentence the screen-reader user cannot drill into, cannot re-speak, and cannot copy into a calculator. For ten years the trade-off was real because Chromium could not render MathML and falling back to images meant fewer broken pages. That trade-off no longer holds.

MathJax was the bridge that kept math on the web legible during the long Chromium gap. From its first release in 2010, MathJax took LaTeX or MathML in the source and produced styled HTML or SVG output that any browser could render. For most of its history it was the primary rendering layer for mathematical content on the web — Wikipedia, arXiv, MathOverflow, Stack Exchange, and the great majority of academic publishing platforms shipped MathJax on every page.

The role MathJax plays in 2026 is different. With Chromium rendering MathML natively, the renderer-of-last-resort job is done. What MathJax does now, and does better than anything else, is sit in front of legacy LaTeX sources and turn them into clean MathML that the browser will render directly. Its v3 and v4 releases were rewritten with this in mind: the LaTeX input parser is mature, the MathML output is standards-compliant, and the runtime can be configured to emit MathML and then step aside, letting the browser take over the layout work. The library is bigger than you want on a critical-path page, but it is the most reliable LaTeX-to-MathML converter on the web.

Most mathematical content on the web has a LaTeX source somewhere upstream. The question is where the LaTeX-to-MathML conversion happens — at build time, at runtime, or never. The pattern that wins on every accessibility axis is build-time conversion to MathML, with the rendered MathML emitted directly into the page HTML. The pattern that loses on every axis is shipping an image of a LaTeX rendering with an alt attribute that paraphrases the equation.

Rendering the math is half the job. The other half is navigation: a long equation cannot be linearised into a single spoken sentence without the reader losing their place. Every major screen reader now ships a “math mode” that lets the user step into a fraction, walk along its numerator, drop into a subscript, jump out to the parent expression, and re-speak the current sub-expression at a different verbosity. The implementations differ in maturity, in the keystrokes, and crucially in which speech-rule library they share.

Behind almost every modern math-speech experience on the web is a project most engineers have never heard of: the Speech Rule Engine, or SRE. SRE started inside Google’s ChromeVox team in the mid-2010s and is now an open-source library maintained primarily by Volker Sorge. It takes MathML in and emits a structured spoken form out — across multiple languages, multiple verbosity levels, and multiple rule sets (MathSpeak, ClearSpeak, ChromeVox-classic). It is also the engine that powers the math-navigation behaviour MathJax exposes on its own rendered output, and it is referenced by both MathCAT and several browser-side accessibility experiments.

The reason SRE matters as infrastructure is that without a canonical pronunciation library, every screen reader would invent its own way to say x squared plus y squared equals r squared. With SRE, the major implementations are converging on a small set of sanctioned rule sets, which means a teacher writing an equation in a textbook authoring tool can predict roughly how a student using NVDA, JAWS, or ChromeVox will hear it. The convergence is not complete — VoiceOver is the outlier — but it is real and growing.

The general principle — ship MathML, convert from LaTeX at build time when possible, lean on SRE for speech — applies to every document type. The specifics shift with the surface. Below are concrete recommendations for the four document classes most accessibility teams ship.

Math accessibility on the web has been the slowest of the major accessibility frontiers to mature. The standards were ready in 1998. The screen readers were ready, in a basic way, in the mid-2000s. The browser engines took until 2023. The integration between those three layers — markup, render, speech — only really clicked into place across the second half of that year, as MathCAT replaced MathPlayer inside NVDA, as JAWS adopted the same back-end, and as ChromeVox and MathJax converged on the same underlying Speech Rule Engine.

The work that remains is at the edges. Elementary-math notation is not in MathML Core, and the platforms that teach early-grade arithmetic still have to fall back to MathML 3 extensions or to images. VoiceOver’s math navigation is usable but less granular than what Windows users get. Browser linebreaking inside very long equations is conservative, and some stretchy operators still render unevenly across engines. These are real problems and worth fixing. They are not the same kind of problem as “Chromium cannot render math at all” was for the decade before 2023.

For an engineering team shipping a new product surface in 2026 with mathematical content on it, the defensible default is: emit MathML, generate it from LaTeX at build time when the source allows, fall back to MathJax v4 for legacy LaTeX you cannot pre-process, and trust the screen-reader stack — NVDA plus MathCAT, JAWS plus MathCAT, ChromeVox plus SRE, VoiceOver natively — to handle the speech layer. The long road is not over. But for the first time, it leads somewhere readable.