Speech generation is on by default in MathJax 4 beta 6

[papile]

Issue Summary

The speech generation is on by default in MathJax 4 beta 6 resulting in very poor performance on math heavy pages

Steps to Reproduce:

Load a math heavy page with display equations using beta 6

The browser will hang for minutes and the stop slow script dialog will come up. The profiler indicates almost all execution time is spent in getSpeech invocations. We noticed this when upgrading from beta 4. It is a great a11y feature, but given the resources this takes, it should be default off.

Technical details:

• MathJax Version: 4.beta.6
• Client OS: Mac OS 14.4.1
• Browser: Firefox 125.0.3

I am using the following MathJax configuration:

MathJax = {}; //default config

and loading MathJax via

<script src="https://cdn.jsdelivr.net/npm/[email protected]/tex-mml-chtml.js"></script>

[dpvc]

Speech generation has been on for all v4 versions since the alpha.1 version, so that is not a change in beta.6. Braille generation is on by default in beta.6, which is new, and the speech-generation process occurs at a different time, and those may be affecting the results for you.

It is important that the accessibility tools be on by default for several reasons:

First, those with assistive needs may have more difficulty accessing the menu in order to turn on the tools in the first place, and may not know they even exist. Sighted users can more easily turn them off than the blind can turn them on.

Second, if a person has to turn on the assistive tools, that is a signal that they have a disability, and that information can be used by the website (and its owners) to identify that fact about them. Users in the assistive-needs community are very hesitant to provide that information, due to the discrimination that can be associated with that knowledge, and so asking them to turn on assistive tools is something they will justifiably resist.

So having the assistive tools on by default is really the only effective way to serve that community. Turning off those tools by default is simply a non-starter for us. You do, however, have the ability to set the configuration for MathJax to turn them off by default for your own website by setting the options.menuOptions.settings.enrich value to false in your configuration.

But there is probably a better solution for your situation: the lazy-typesetting extension. This only typesets the expressions that are currently visible, and then typesets more as you scroll to other locations on the page. This is probably the best choice for pages with lots of math, whether or not the assistive tools are active. I think that if you enable this, you will find that you don't need to disable those tools.

We are experimenting with additional changes that we hope will speed up the speech-generation process, but that is still in the future.

[papile]

Thanks for the reply! I agree that accessibility is extremely important. It is actually the reason why we are testing MathJax 4. I just saw the new menu item for speech to text and noticed in profiling that it is the most intensive thing by far in the package. If this is integral to accessibility then yes it should be on.

In beta 6 release vs beta 4 this portion became orders of magnitude slower. I will try out the lazy typesetting extension, thank you for that suggestion. We are rendering full-text HTML from MathML and loading it with typesetPromise

[dpvc]

In beta.6, the speech generation was reorganized. In the past, it was spread out over several different functions, but in beta.6, that was all collected into the getSpeech() function, so that may be on reason that that particular function has shown up in your profiling; it used to only take the speech from an attribute that had been attached in previous steps, but now the speech is actually being generated there. That does mean it will be much more costly than it used to be.

Since you are using MathML and not TeX as your input format, you might want to switch to the mml-html.js component rather than tex-mml-html.js, since you don't need any of the TReX-specific code. That is a smaller download (about 133K smaller).

[papile]

We do have other instances where we convert TeX but thank you for that advice! I turned on lazy loading and that avoided an immediate page crash and hang for a minute +, but still when scrolling down a bit not at reading speed it takes a very large amount of resources, and the page becomes non-responsive. This was not true in beta 4, I could render whole articles regardless of complexity with no slow down. It isn't just that the particular function is more costly, the entire feature is much more costly than in beta 4. This isn't for a particular page either it is across the board that it is taking much (10x+) longer to render math.

My original posting I suppose was a misconception because I thought something new was added. The release notes said an update to the speech-rule engine (SRE) that underlies MathJax's assistive support and I was wondering if we could disable whatever that update was because it makes the library unusably slow for us and we had to stick to beta 4. Perhaps that was the braille support I am not sure. We do not want to disable accessibility features at all if possible, it is the main reason we want to upgrade. But to balance that, we don't want to be crashing people's browsers either.

I could provide test cases and time differences from beta4 to beta6 if that would assist you. We are very excited about MathJax4 because equation breaking is now where we need it, and appreciate your work on this project.

[dpvc]

I could provide test cases and time differences from beta4 to beta6 if that would assist you.

Thank you for the offer, but I do have examples to work with, and am looking into it. I do see the issue you report with the lazy typesetting. My initial impression is the following: when you scroll to a new location on the page, perhaps skipping over sections of the page, any TeX-based mathematics that precedes that is converted to MathML at that point (but not converted to HTML), even in the skipped sections. This is because the TeX could include macro definitions that are needed in the later sections, or if equations are automatically numbered, the numbers from the previous sections are needed before the numbers for the newly revealed math can be determined, etc. In the past, the speech was generated in a separate step after that, which was not performed until those earlier expressions actually appear in the window's viewport, but some of the changes in beta.6 move that speech generation into the initial conversion to MathML (rather than reworking it later). That is because the speech is now being generated at the same time the semantic enrichment occurs, and the enrichment is during the TeX-to-MathML phase. Although you are just using MathML, there is a similar process there, as the MathML is enriched before it is converted to the final HTML.

In the past, the typesetting and enrichment was being done, but the speech generation was postponed until the math actually appeared. It turns out that that is no longer the case, and so that is slowing down the lazy typesetting so that it is no longer as responsive as it used to be.

I will need to look into how to address that and get back to you once I have more to suggest.

Thanks for working with us on this.