Thanks for the feedback. That looks like a bug in asciimathml. The 'to' in `phantom' is interpreted as the standard "to" macro, breaking the phantom macro. I've filed an issue on the asciimath repo
https://github.com/mathjax/asciimathml/issues/28.
> All the content has to be Accessibility-friendly [...]
For accessibility, generally speaking you should deliver MathML which is the standard format that math accessibility tools understand (ChromeVox, VoiceOver, NVDA, MathPlayer-driven tools likes Texthelp, JAWS). You can additionally create speech text by pre-processing with MathJax-node which includes Volker Sorge's speech-rule-engine (an isolated and expanded ChromeVox engine).
> and we are allowing the user to have a great deal of customization. [...]
MathJax can extend any input on the fly. But TeX has more built-in functionality that a user can use on the fly (\newcommand etc).
> Our system is fully responsive (adapts itself to whatever screen size/device the user has) [...]
Check out our linebreaking options.
> I was wondering if you could help me understand why someone might choose AsciiMath over Tex?
AsciiMath is designed to be simpler, styled after the input of graphing calculators and other traditions of ascii notation. It was created by Peter Jipsen to match the needs of US college students. By design, asciimath is more limited than MathJax's TeX/LaTeX input (let alone real TeX/LaTeX).
Which one is more suitable is really a question of balance and content strategy. For school-level math, I would guess that asciimath should be sufficient but you already ran into trouble so clearly some things are not in scope.
There is also a more complicated underlying problem when it comes to the specific problem of aligning at decimals. MathML provides constructions that fit via the so-called Elementary Math elements. However, MathJax does not yet support these on the output end (and therefore there are no input macros that would help create them). Implementing these is relatively high up in our backlog but it's a question of resources.
> is one more efficient than the other with rendering? [...]
There should be virtually no difference in rendering speed between any of the inputs because MathJax is modular: input is converted to MathML and output generated from MathML. The input conversion is very simple and fast, the output is the bottleneck.
> Render times with a large volume of users is a big concern to us [...]
I'm not sure I understand this concern. MathJax rendering happens client-side so it should be independent of the number of users (but will naturally depend on the number of equations). How do you see the number of users affecting client-side rendering speed?
Regards,
Peter.