For the last couple years, I’ve been doing training in SUNY around Math Accessibility. Math accessibility, especially the accessibility of equations was a complicated and technical problem, and we needed people to really dig into the issues, find solutions, and be able to express them to other people.
In 2019, I was working as a consultant for SUNY OER Services and a typical project had me converting existing OER between multiple formats. Practical issues working on individual projects slowly taught me the complexity of the state of Math Accessibility in 2019. OpenStax used one system to encode their accessible math, storing it in MathML in the database, while WordPress-based solutions like Pressbooks stored the code in LaTeX. The iMathAS system stored math as AsciiMath. Converting a book between systems might mean rewriting every equation in a book.
Doing conversions and troubleshooting was my entry into the world of online math, but I also tried to learn about the way assistive technology interprets accessible math. The problems were numerous, but here were the top 3 in 2019.
Problem 1: The incomplete adoption of MathML across browsers
MathML is the official standard for accessible math on the web. Despite MathML being a W3C Recommendation since 1998, major browsers did not have MathML support. When I first started working on this problem in 2019, only Safari and Firefox supported the official standard for accessible math. Only when the data is structured with assistive MathML can assistive technology translate the mathematical markup to text, to braille, or other alternative formats.
It wasn’t that we didn’t have solutions. There were multiple alternatives that would translate math from one input, and output a visual that would work across browsers plus the Assistive MathML hidden as a sort of machine-readable alt text. The most popular solution was MathJax, a browser-based solution that had math rendering inside the browser, with an assistive menu to switch between multiple outputs such as HTML, SVG, and PNG with or without the assistive MathML. It was a solution that let many products implement a basic amount of accessibility, but at its core, it was still just complicated. It took people already fluent with screen readers to go deeper and understand what their settings should be.
Problem 2: Even when Math was correctly encoded, not all assistive technology could interpret MathML
The next step in accessibility is actually having it be useful to a student. Instead what we found was a confusing landscape where only certain assistive technology could interpret MathML. There was actually a Math Accessibility finder that would tell you what combinations of assistive technology actually work run by Benetech.
For example, you could tell the program that you are on a PC, and it would tell you that you have to use NVDA as your screenreader, but that you would have to install a helper tool called MathPlayer, and it would warn you that this combination only works if you emulate Internet Explorer 11. (Even in 2019, this Internet Explorer was long-gone from most computers, and a laughable situation.)
People who actually use assistive technology daily are likely to stick with the tools and browser combinations that they have found work for them. Students with an accommodation like tests being read out loud to them for processing aren’t likely to spend hours just to have their math tests read to them, and the LMSs and Homeworks Systems used by their institutions may have their own browser requirements. It breaks down further if the professors want to use a lockdown browser or other surveillance that puts extra stress on an already fragile and picky math ecosystem.
Problem 3: For Creators, many publishing platforms did not accept MathML
An example of this is WordPress, which could use MathML, but only on it’s own line, and couldn’t be used for inline text. A bug in the classic WordPress editor would automatically insert paragraph tags around any MathML equation. Practically, this meant that couldn’t reliably move math between authoring platforms.
All of my experience with conversions had convinced me that if there is an accessible standard, we should be doing what we can to make sure it’s stored in the database in the accessible format, not trying to do real-time conversions in the browser.
The incompatibility meant that even though there was an official standard for accessibility, the typical end users couldn’t use it reliably across all browsers, users that relied on assistive technology had major hurdles, and creators did not have reliable options.
2023 could be a major inflection point for Accessible Math
Solution 1: MathML support is added into Chromium for Chrome 109
Released January 9th, 2023, Chrome 109 has added support for rendering MathML. This is a giant breakthrough, especially because Microsoft Edge and the Opera Browsers are both also built on top of the open-source Chromium code. At the time of writing, Edge, and Opera both have MathML support as an experimental feature that can be turned on with a setting.
When Edge, Chrome, Firefox, and Safari all treat the WCAG 2.1 standard equally, it will be a major step forward, and that could all happen in 2023.
Solution 2: MathJax incorporates a Speech Rule System into core
The current version of MathJax, MathJax 3.2 now includes a speech rule system as part of its assistive menu. You can even select the speech rules you prefer, with a choice of MathSpeak, ClearSpeak, or ChromeVox rules.
It seems like more languages are supported with each coming release. It’s important to inspect the websites of vendors you use because many are still using MathJax 2.7 released in 2016. Although MathJax 3.2 was released in 2021, make 2023 the year you push your vendors to upgrade. If you notice that your vendors are still using an older version of MathJax, ask them what their upgrade plan is.
Utilizing the most modern version of MathJax means practically that more screen readers (even the lightweight ones we buy in higher ed like Read & Write) will be able to interpret math, because the hard work will be done by MathJax, and all the reader has to be able to do is interpret alternative text.
Solution 3: WordPress fixes bug in the classic editor to allow inline MathML
Slated for release in WordPress 6.2, Steel Wagstaff and I were able to convince the WordPress Accessibility Team that a 13-year-old trac ticket was worth their attention. Getting the Accessibility label and the Bug label in their backlog of issues helped bring this problem to the top of the to-do list. Joe Dolson, a premium WordPress Plugin Developer that donates 6 hours of time to the accessibility team per week took the lead on shepherding this ticket through the testing and making sure it makes it into the upcoming 6.2 release.
This should allow easier sharing between Pressbooks and other Open Publishers. With WordPress powering 43% of the web, this can be a major inflection point.
Feeling hopeful for 2023 and beyond
In the past, I considered myself a Math Accessibility Expert because I had done the research and knew a lot about the intricacies of accessibility on the web and how assistive technology uses it. With these three milestones, I’m looking forward to a day when that expertise isn’t needed, because things work more easily.
Leave a Reply