Challenges in production of accessible Math
While best practices for accessible mathematics suggest comprehensive MathML markup for all mathematical content, their implementation presents significant practical challenges for publishers, typesetters and production workflows.
The best practices suggest that including simple expressions like "4 − 1 = 3" or single Greek letters, should be marked up with MathML. This is challenging with established typesetting practices for print books where inline mathematical expressions are traditionally handled as italic text using standard typography and UTF-8 characters.
Inline mathematical expressions are formulas that appear within the flow of text, embedded directly in paragraphs rather than displayed as separate mathematical blocks. These expressions are typically constrained to a single line (no fractions) to maintain text flow and readability.
Examples of inline math include:
- Simple arithmetic: "The equation x + 3 = 7 has a solution of x = 4"
- Basic algebraic expressions: "When a = 2 and b = 5, the value of a² + b is 9"
- Variables and parameters: "The coefficient β₁ represents the slope"
- Simple inequalities: "We know that x > 0 in this context"
- Units with exponents: "The acceleration was measured at 9.8 m/s²"
In contrast to math blocks, which are:
- Displayed as separate elements (usually centered)
- Can span multiple lines
- May contain complex structures like fractions, matrices, or large operators
- Are visually distinct from the surrounding text
Inline math expressions are designed to integrate seamlessly with text flow, maintaining consistent line height and spacing while providing mathematical meaning within sentences.
When inline math expressions are converted into MathML, several rendering problems emerge. As MathML elements are rendered as inline-block (these are often vector images used for print production, which are exported as MathML for digital export.), they can cause:
- Inconsistent baseline alignment with surrounding text
- Increased line height that disrupts paragraph spacing
These issues can be resolved, but they require manual intervention for each expression, which is difficult to industrialize.
Note: latest versions of InDesign have introduced the ability to generate mathematical formulas in MathML natively within the software. This feature looks promising for inline expressions, but it will take time for it to become professional-grade and widely adopted.
Most born accessible publishing workflows begin with print production using professional desktop publishing software (InDesign, QuarkXPress, etc.) where inline mathematical expressions are naturally handled as UTF-8 styled text (typically italic) to maintain consistent typography and avoid layout disruptions.
In this scenario implementing MathML for inline formulas requires additional steps in post-production, including:
- Identification of all mathematical expressions in the text
- Manual or semi-automated conversion to MathML markup
There may be potential semi-automatic solutions to improve workflow. If editorial team consistently use specific character styles for inline mathematical expressions, scripts could potentially:
- Identify text with mathematical styling
- Convert it to appropriate MathML markup
However, these automated systems have limitations, especially with regard to semantic ambiguity in automatic conversion. In particular with:
- Context-dependent mathematical meaning
- Distinction between mathematical and non-mathematical uses of symbols
- Complex expressions requiring structural analysis
In any case at the moment, there are no open source tools available that support this automation.
Stacked equation formats are typically tagged as table elements for any Math Engine (MathML, LaTeX, MathJax, etc)
If this format must be used for pedagogical reasons, an alt text might be a more appropriate solution.
Answer Key illustrations like this are common in Math Learning materials, however, as they are represented as stacked equations, Math Engines will render these as table elements. The larger concern is that there is no Math code solution for answer key illustrations.
As with Stacked Equations, an alt text may be a less confusing solution.
Interactive math content can be problematic. In the first example above, the input fields are being used to construct a fraction, however, the input fields will remain so and therefore screen readers will not convert them into a fraction, meaning, the answer will still be read as whole numbers inside a text input field - e.g. "text edit 3. text edit 4"
In the second example, placing LaTeX/MathML code inside a container, such as a combobox, can render the math code inactive and so screen readers can read the options as whole numbers instead of fractions. e.g. "36" instead of "fraction 3 over 6".
Math HTML Engines don't always work well insdide containers, so more vigilant unit testing should be carried out or alternative simplified design should be utilized.
Complex fraction equations like this one, tend to generate inconsistent scren reader support depending on the Math engine used, the screen reader used and, in some cases, even the browser used.
For these types of equations, it is recommended to perform some exploritory testing to ascertain the best engine/screen reader combination works best and design with this crietia.
Math HTML is not a one size fits all. You may find that MathML works best for certain equation types, but LaTeX works better for another type. There are limitations however, so in some cases, alternate text descriptions may wind up being a less confusing option for the end user.