Interface Design for Serious Adult Mathematics: Rendering, Input, and the Adult/Expert Theme

Findings

1. Math typesetting: KaTeX vs MathJax

KaTeX’s homepage frames its value around speed: “Lightning-fast, even on pages with hundreds of expressions,” from synchronous rendering that “doesn’t need to reflow the page,” unlike engines that do [2]. It has no external dependencies, renders identically server-side via Node.js (pre-render to plain HTML, zero client JS cost for static content), and benchmarks its typographic quality against Knuth’s TeX as “the gold standard for math typesetting” [2]. MIT-licensed, maintained by Khan Academy and contributors [1]. Its documented weakness: a narrower LaTeX command surface than MathJax (its support table lists 1000+ functions but flags unsupported ones rather than silently degrading) [1], and no first-party accessibility/speech layer — KaTeX accessibility is typically bolted on via third-party ARIA post-processing.

MathJax positions itself as “beautiful and accessible math in all browsers,” run by a non-profit (501(c)(3)) backed by the American Mathematical Society and IEEE [3]. It supports three output modes — CommonHTML/CHTML, SVG, and native MathML — accepting TeX, MathML, and AsciiMath as input, with browser and Node.js rendering [3]. Its accessibility extensions decide any “serious, professional” claim: version 4’s Explorer/Speech modules generate speech strings per (sub)expression via user-selectable rule sets and ARIA attributes, working regardless of whether the screen reader understands MathML, with Nemeth/Euro Braille output — validated across 13 browser/OS/screen-reader combinations (NVDA needs “Combine with Speech” for correct Braille; JAWS works with defaults) [6].

Practical read: KaTeX for the fast path (problem statements, live feedback — most content, most of the time); MathJax loaded selectively behind an accessibility toggle or wherever a proof needs the fuller LaTeX surface. Loading both permanently is unnecessary bloat.

2. MathML Core and the accessibility gap

MathML Core is the browser-focused subset of the original spec — the semantic subset was never implemented in browsers and the presentation subset produced inconsistent early implementations, so Core was defined “tailored to work seamlessly with HTML, CSS, DOM, and JavaScript” using LaTeX and OpenType Math conventions as reference [4]. MDN records it as “Baseline Widely Available… since January 2023” — native in Chrome, Firefox, Safari, Edge [4]. Legacy pre-Core features may still appear in older content; the Math Working Group maintains polyfills for the gap [4].

The gap that matters: native rendering support says nothing about whether a screen reader announces content usefully. That is solved by explicit speech-rule engines (MathJax’s Explorer, MathSpeak-derived rule sets), not MathML support alone [3][4][6]. A page shipping MathML markup with zero ARIA/speech annotation is technically standards-compliant and still inaccessible in practice — the most common quality gap in math-heavy sites claiming accessibility compliance.

3. Math input: typing, virtual keyboards, handwriting

MathLive (MIT license, arnog/mathlive, published as web components <math-field>, <math-span>, <math-div>) is the most complete open option for keyboard/touch math entry: direct LaTeX typing with 800+ built-in commands, a mobile-ready virtual math keyboard plus physical-keyboard shortcuts, and round-trip export/import across LaTeX, MathML, ASCIIMath, Typst, and MathJSON [5][7]. Accessibility is first-party, not an add-on: “screen-reader friendly” behavior with auto-generated, speech-optimized ARIA labels and math-to-speech output [7]. This makes it the strongest single choice for desktop and tablet keyboard-based entry.

Handwriting recognition is architecturally separate. MyScript Math is a commercial, AI-driven (not OCR) handwriting-to-digital engine: it interprets handwritten equations live, solves them, and supports a “scratch-out” gesture for correction; it ships as consumer apps (iOS/Android) and, more relevantly, as an SDK plus REST APIs (developer.myscript.com) for embedding in custom applications [7]. It targets stylus input (Apple Pencil-class hardware), not touch or mouse. Apple’s Scribble and Windows Ink are OS-level handwriting layers with less domain-specific math parsing — lower-friction (on-device, no SDK) but weaker at structured notation (fractions, exponents, matrices) than a purpose-built math recognizer.

4. Notebook-style interfaces and what reads as “professional”

Across Jupyter, Desmos, GeoGebra, and Wolfram Alpha, the shared vocabulary that signals “serious tool” rather than “toy app” includes: persistent, addressable state (a notebook cell, a saved graph, a re-runnable expression) rather than a single ephemeral question-answer loop; keyboard-first interaction with visible, learnable shortcuts instead of exclusively pointer-driven menus; dense but organized information layout (multiple panels, no single oversized “next” button); and typeset — not image-rendered — mathematics that can be selected, copied, and re-edited. GeoGebra targets breadth across “geometry, algebra, spreadsheets, graphing, statistics and calculus in one engine” for “all levels of education,” K-12 through university, balancing ease-of-use against power rather than defaulting to either extreme [10]. This is the opposite design pressure from a gamified elementary product: fewer decorative elements, more direct manipulation of the mathematical object itself.

5. Dark mode, dense layout, and long-session ergonomics

Long-session technical tools (IDEs, LaTeX editors, Jupyter, scientific computing environments) converge on dark-by-default or dark-first theming, high information density per screen (multiple panes, minimal whitespace compared to consumer apps), monospace or semi-monospace numerals for table/matrix alignment, and muted, low-saturation accent colors reserved for state (error, active, selected) rather than decoration. This is a distinct visual grammar from a bright, high-contrast, large-hit-target children’s UI — the two must not share a component library’s default spacing/color tokens if the adult band is to read as a different, credible register rather than a reskinned kids’ app.

6. Andragogy: how adult motivation differs

Knowles’s six adult-learning assumptions: (1) self-concept — adults require input into and control over their own learning path rather than being directed; (2) experience — prior experience, including prior error, is itself a learning resource; (3) readiness — adults engage with material that has immediate applicability, not material sequenced for a curriculum’s own logic; (4) orientation — learning is problem-centered, not subject-centered; (5) motivation — internal drivers (mastery, self-actualization) matter more than external ones (grades); (6) need to know — adults want the “why” before the “how” [8]. Knowles later softened the theory to a pedagogy-andragogy continuum rather than a hard split, and critics note his own practice undercut the “full self-direction” claim, and that the principles may just be good teaching generally [8]. The actionable takeaway: give adult-track users visible control (skip, jump to topic, choose difficulty) and a visible “why this problem” rationale — withholding both is the failure mode most tied to disengagement.

7. Why adults abandon MOOCs

The most-cited figure: Harvard/MIT MOOCs averaged 22% completion in 2012 [9]. Stanford research categorized participants into auditors (watch without assessment), completers, disengaged learners (quick abandonment), and samplers (occasional engagement) — a taxonomy that maps onto how an adult math app’s users will actually behave, arguing against designing only for “completers” [9]. Completion varied sharply by prior credential: only 8% among undergraduate-level participants completed versus 27% among high-school-level participants — suggesting credentialed adults sample more and commit less, likely from more competing, already-validated uses of their time [9]. The dominant explanation for dropout is absence of interpersonal interaction and support, not content difficulty — one cited comparison found 32% of students failed or withdrew from online courses versus 19% in in-person equivalents, attributed to high autonomy requirements without compensating structure [9]. For a solo-use math app with no cohort or instructor, this is the sharpest risk: the product must supply structure (visible progression, spaced return prompts, an instructor-equivalent voice) to substitute for the social scaffolding a MOOC lacks and a classroom has.

Rendering & input stack recommendation

Option	Role	Bundle size (approx., per official docs)	License	Accessibility	Pick for Math Challenge
KaTeX	Primary renderer for problem/answer typesetting	Self-contained, no runtime deps; documented as the fastest of the two engines because it renders synchronously without page reflow [1][2]	MIT	No first-party speech/Braille layer; relies on markup/ARIA added around it	Yes — default renderer for all standard problem and feedback rendering
MathJax (v4, CHTML/SVG output)	Fallback renderer when accessibility mode is on, or for content needing MathML/Braille output	Larger and slower to first-render than KaTeX per its own comparison framing [2][3]; modular, loadable in parts	Apache-2.0 (mathjax.org states open-source, non-profit-maintained) [3]	Explorer + Speech extensions: on-the-fly speech text, Nemeth/Euro Braille, validated across 13 browser/OS/screen-reader combos [6]	Yes — load lazily behind an “accessible math” toggle, not by default
MathML Core (native browser markup)	Underlying semantic markup target, output format from both engines	N/A (browser-native, no library)	W3C spec, browser-implemented	Baseline Widely Available since Jan 2023 (Chrome, Firefox, Safari, Edge) for rendering; speech is not automatic [4]	Use as the output target where possible (via MathJax’s MathML mode) so assistive tech has a real semantic tree to hook into
MathLive	Math input: typed LaTeX + virtual keyboard, desktop and touch	MIT-licensed web component; 800+ built-in LaTeX commands; exports LaTeX/MathML/AsciiMath/Typst/MathJSON [5][7]	MIT	Auto-generated ARIA labels, math-to-speech built in [7]	Yes — default input widget for desktop, tablet-without-pencil, and any typed-entry path
MyScript Math SDK	Handwriting input for stylus-equipped tablets	Commercial SDK + REST API (developer.myscript.com); size not published in the fetched docs — verify before committing	Commercial, per-integration	Not a distinct feature; recognition accuracy, not screen-reader output, is the product’s focus	Conditional — only if pencil/tablet is prioritized; adds a paid dependency, gate behind owner decision
OS-native handwriting (Scribble / Windows Ink)	Fallback handwriting without an added SDK	Zero added bundle (OS-level)	N/A (platform feature)	Inherits OS accessibility, not math-specific	Use only as a cheap fallback if MyScript is rejected; expect weaker parsing of fractions/exponents/matrices

Design implications for Math Challenge

1. Ship KaTeX as the default renderer for every ADULT/UNIVERSITY/EXPERT screen — problem statements, answer fields, worked-solution steps — since it is faster and reflow-free, which matters when rendering many expressions per screen (proof steps, sub-parts) [2].
2. Load MathJax only behind an explicit “Accessible math” setting, not globally — its Explorer/Speech/Braille accessibility is materially stronger than KaTeX’s, but its extra weight isn’t worth paying by default [2][3][6].
3. Emit MathML as the semantic backing format wherever the accessibility path is active — the one representation both engines and screen readers standardize on, Baseline since 2023 [4].
4. Use MathLive as the single input widget on desktop and tablet-without-pencil, keyboard-first with a docked virtual math keyboard, since it already ships ARIA labels and math-to-speech [5][7].
5. On tablet + pencil (iPad/Surface), offer handwriting as an alternate input mode, not the only one — gate MyScript’s commercial SDK cost vs. the OS-native (Scribble/Ink) fallback behind an explicit owner decision; MyScript parses structured notation (fractions, exponents, matrices) materially better [7].
6. On phone, default to virtual-keyboard-only input; treat handwriting as out of scope for v1 — a phone screen is too small for a stylus workflow to feel serious, and MathLive’s keyboard is already mobile-first [5].
7. Adopt a dark-first theme for ADULT/EXPERT, distinct from the bright theming used in younger bands, mirroring long-session technical tools (IDEs, Jupyter) rather than consumer edtech [§5].
8. Increase information density relative to child/teen bands: multiple visible panels (problem, scratch/work area, attempt history) rather than one oversized single-focus card, matching Jupyter/Desmos/GeoGebra’s layout pattern [10].
9. Give every adult-track problem a one-line, dismissible “why this problem” rationale (e.g., “reinforces the substitution rule you missed twice”) — answering Knowles’s “need to know” assumption directly, the andragogical lever most tied to engagement [8].
10. Expose explicit learner control over path: visible skip/reorder/jump-to-topic on the adult/expert band, honoring the self-concept assumption that adults disengage when the system controls sequencing [8].
11. Build structure that substitutes for the social scaffolding MOOCs lack: visible streaks/progression tied to skill mastery (not session count), and periodic recap prompts as a stand-in “instructor voice,” since absent interpersonal support is the literature’s dominant dropout cause [9].
12. Design for MOOC-style user segmentation from day one: expect “auditor” and “sampler” personas (browse without completing) to be common, so the UI must surface value on a single visit rather than assume multi-week usage [9].
13. Keep KaTeX/MathML output selectable and copyable as plain LaTeX/MathML, matching the professional-tool expectation that a rendered expression is a re-usable object, not a locked image.
14. Reserve color for state, not decoration, in the adult/expert theme (muted error/active/success at low saturation) — the opposite bias from a child theme’s decorative color use — to keep the register serious rather than gamified.

Open questions for the project owner

1. Should MyScript’s commercial SDK be licensed for the tablet+pencil path, or should Math Challenge ship OS-native handwriting (Scribble/Ink) only, accepting weaker parsing of structured notation, at least for v1?
2. Should the “Accessible math” toggle (KaTeX → MathJax/MathML/speech) be a persistent user setting, or auto-detected from active screen-reader/assistive-tech signals in the browser?
3. How much visible learner control (skip/reorder/jump) is appropriate before it undermines the app’s own mastery-gating logic used in other grade bands — does ADULT/EXPERT get an explicitly different progression contract than younger bands?
4. Is a dark-first (not just dark-mode-available) default acceptable for the adult/expert theme even though the rest of Math Challenge is presumably light-first, and does that require separate theming infrastructure beyond a simple dark-mode toggle?
5. What is the minimum session-one value the adult/expert experience must deliver, given MOOC research suggesting many adult users will sample once and not return — is there a designed “single-session win” for this band?