La prima cosa da affermare chiaramente è che il lungo, lento dibattito sul fatto che i browser debbano o meno rendere la matematica in modo nativo è stato risolto. Firefox ha supportato MathML dall’inizio degli anni 2000; WebKit ha introdotto un’implementazione utilizzabile in Safari nel 2013; il ritardatario, Chromium, ha finalmente implementato MathML Core nella versione 109 nel gennaio 2023. Quella singola release ha sbloccato la piattaforma: a metà 2026 i principali motori browser su ogni desktop e quasi ogni telefono parlano MathML come linguaggio di primo livello. L’uscita di emergenza che il web ha standardizzato per quasi vent’anni — rendere la matematica come un’immagine con un attributo alt di cui l’utente di screen reader deve fidarsi — non è più il default responsabile.

Ciò che è cambiato nel 2023 è più ristretto di quanto il titolo suggerisca. Chromium non ha implementato l’intero MathML 3; ha implementato MathML Core, un sottoinsieme deliberatamente delimitato agli elementi che i browser possono rendere in modo affidabile e che le tecnologie assistive possono navigare. Il layout della matematica elementare (divisione in colonna, riporti, addizione in colonna) non è in Core. L’a capo all’interno di un’equazione lunga è in Core, ma le euristiche sono conservative. Alcuni operatori estensibili avanzati vengono ancora resi in modo incoerente tra i motori. Ma l’ossatura — frazioni, radicali, pedici e apici, matrici, integrali, sommatorie, il dizionario degli operatori — è ora in ogni motore che conta.

La conseguenza per l’accessibilità è diretta. Una pagina che emette MathML direttamente nel DOM distribuisce un’espressione semantica che uno screen reader può pronunciare, navigare e ripronunciare con un diverso livello di verbosità. Una pagina che emette un’immagine con un attributo alt distribuisce una singola frase che l’utente di screen reader non può approfondire, non può ripronunciare e non può copiare in una calcolatrice. Per dieci anni il compromesso era reale perché Chromium non poteva rendere MathML e il fallback alle immagini significava meno pagine rotte. Quel compromesso non vale più.

MathJax è stato il ponte che ha mantenuto la matematica sul web leggibile durante il lungo vuoto di Chromium. Dalla sua prima release nel 2010, MathJax prendeva LaTeX o MathML nel sorgente e produceva output HTML stilizzato o SVG che qualsiasi browser poteva rendere. Per la maggior parte della sua storia è stato il layer di rendering primario per i contenuti matematici sul web — Wikipedia, arXiv, MathOverflow, Stack Exchange e la grande maggioranza delle piattaforme di pubblicazione accademica distribuivano MathJax su ogni pagina.

Il ruolo che MathJax svolge nel 2026 è diverso. Con Chromium che supporta MathML in modo nativo, il lavoro di renderer di ultima istanza è terminato. Ciò che MathJax fa ora, e fa meglio di qualsiasi altro, è posizionarsi davanti a sorgenti LaTeX legacy e trasformarle in MathML pulito che il browser renderà direttamente. Le sue release v3 e v4 sono state riscritte con questo obiettivo: il parser LaTeX in input è maturo, l’output MathML è conforme agli standard e il runtime può essere configurato per emettere MathML e poi farsi da parte, lasciando che il browser si occupi del lavoro di layout. La libreria è più grande di quanto si vorrebbe su una pagina con percorso critico, ma è il convertitore LaTeX-in-MathML più affidabile sul web.

La maggior parte dei contenuti matematici sul web ha un sorgente LaTeX da qualche parte a monte. La questione è dove avviene la conversione LaTeX-in-MathML — al momento della build, a runtime, o mai. Il pattern che vince su ogni asse di accessibilità è la conversione al momento della build in MathML, con il MathML renderizzato emesso direttamente nell’HTML della pagina. Il pattern che perde su ogni asse è distribuire un’immagine di un rendering LaTeX con un attributo alt che parafrasa l’equazione.

Rendere la matematica è metà del lavoro. L’altra metà è la navigazione: un’equazione lunga non può essere linearizzata in una singola frase pronunciata senza che il lettore perda il filo. Ogni screen reader principale ora include una «modalità matematica» che permette all’utente di entrare in una frazione, percorrere il numeratore, scendere in un pedice, tornare all’espressione padre e ripronunciare la sotto-espressione corrente con un diverso livello di verbosità. Le implementazioni differiscono per maturità, tasti di scelta rapida e, soprattutto, per la libreria di regole vocali che condividono.

Dietro quasi ogni moderna esperienza di pronuncia matematica sul web c’è un progetto di cui la maggior parte dei professionisti non ha mai sentito parlare: lo Speech Rule Engine, o SRE. SRE è nato all’interno del team ChromeVox di Google a metà degli anni 2010 ed è ora una libreria open source mantenuta principalmente da Volker Sorge. Prende MathML in input e emette una forma parlata strutturata in output — in più lingue, più livelli di verbosità e più set di regole (MathSpeak, ClearSpeak, ChromeVox-classic). È anche il motore che alimenta il comportamento di navigazione matematica che MathJax espone nel proprio output renderizzato, ed è referenziato sia da MathCAT che da diversi esperimenti di accessibilità lato browser.

Il motivo per cui SRE è importante come infrastruttura è che senza una libreria di pronuncia canonica, ogni screen reader inventerebbre il proprio modo di dire x al quadrato più y al quadrato uguale r al quadrato. Con SRE, le principali implementazioni stanno convergendo su un piccolo insieme di set di regole sanciti, il che significa che un insegnante che scrive un’equazione in uno strumento di authoring di libri di testo può prevedere approssimativamente come uno studente che usa NVDA, JAWS o ChromeVox la sentirà. La convergenza non è completa — VoiceOver è l’eccezione — ma è reale e in crescita.

Il principio generale — distribuire MathML, convertire da LaTeX al momento della build quando possibile, appoggiarsi a SRE per il parlato — si applica a ogni tipo di documento. I dettagli variano con la superficie. Di seguito sono riportate raccomandazioni concrete per le quattro classi di documenti che la maggior parte dei team di accessibilità distribuisce.

L’accessibilità matematica sul web è stata la più lenta delle grandi frontiere dell’accessibilità a maturare. Gli standard erano pronti nel 1998. Gli screen reader erano pronti, in modo elementare, a metà degli anni 2000. I motori browser hanno atteso fino al 2023. L’integrazione tra quei tre layer — markup, rendering, parlato — si è veramente sincronizzata nell’arco della seconda metà di quell’anno, quando MathCAT ha sostituito MathPlayer all’interno di NVDA, quando JAWS ha adottato lo stesso back-end, e quando ChromeVox e MathJax hanno convergito sullo stesso Speech Rule Engine sottostante.

Il lavoro che resta è ai margini. La notazione matematica elementare non è in MathML Core, e le piattaforme che insegnano l’aritmetica dei primi anni di scuola devono ancora ricadere sulle estensioni MathML 3 o sulle immagini. La navigazione matematica di VoiceOver è utilizzabile ma meno granulare di quella disponibile per gli utenti Windows. L’a capo del browser all’interno di equazioni molto lunghe è conservativo, e alcuni operatori estensibili vengono ancora resi in modo non uniforme tra i motori. Questi sono problemi reali e che vale la pena risolvere. Non sono lo stesso tipo di problema di «Chromium non riesce a rendere la matematica del tutto» per il decennio prima del 2023.

Per un team di ingegneria che distribuisce nel 2026 una nuova superficie di prodotto con contenuto matematico, il default difendibile è: emettere MathML, generarlo da LaTeX al momento della build quando il sorgente lo consente, ricadere su MathJax v4 per il LaTeX legacy che non è possibile pre-elaborare, e fidarsi dello stack di screen reader — NVDA con MathCAT, JAWS con MathCAT, ChromeVox con SRE, VoiceOver in modo nativo — per gestire il layer del parlato. Il lungo percorso non è finito. Ma per la prima volta, porta da qualche parte di leggibile.