Re: Minutes: MathML general meeting, 23 July

Hi Neil,

Why did you say that "unicode has too many characters already" ?


              -- Bill
From: Neil Soiffer <>
Sent: Sunday, July 25, 2021 3:23 PM
To: <>
Subject: Minutes: MathML general meeting, 23 July


  *   Bert Bos
  *   Christopher Comninel
  *   Sam Dooley
  *   David Farmer
  *   Deyan Ginev
  *   Patrick Ion
  *   Brian Kardell
  *   Charles LaPierre
  *   Paul Libbrecht
  *   Louis Maher
  *   Bruce Miller
  *   Murray Sargent
  *   Cary Supalo
  *   Neil Soiffer
  *   Stephen Watt
  *   Laurence Zaysser


  *   David Carlisle
  *   Steve Noble


CS: Reminder to Bert to send Cary the W3C Template mentioned in the last week's meeting.

Action Item followup

NS: No consistent support for ARIA on MathML in alternative AT engines, see email on the mailing list for details.

LZ: Is aria-description handling similar to footnotes in that they don't happen by default?

NS: Tried alternative keys as well, but no meaningful behavior was produced for Neil's specific keyboard setup.

Using ARIA for intent
Follow up on Deyan Presentation last week on his idea of using ARIA
Where do we go from here/how do we make progress?

NS: If the aria behavior is currently not well-defined, this could be a place for the Math WG to provide that meaningful definition, going forward. Especially in order to avoid problematic AT results with Braille.

ACTION ITEM: NS: Will begin to write a report on where we are, and where we want to go. We will use Google Docs for our report.

MathML in the wild -- see mail archive thread

DF: three categories

  1.  tools that do the best they can to meet the spec that we come up with
  2.  all the stuff in arXiv and elsewhere. That won't be improved. Should be spoken character-by-character
  3.  remediated math. Someone can add info such as "number theory paper" to my writings.

LZ: You would have to come up with standards for the separate subject catagories.

SW: There is a difference on how you would want to pronounce things, depending on area. For example, in probability E be read as "expectation", but in some areas of physics as "energy". Would we have defaults or have to tag every instance in a section?

NS: Anything we do for math has to be contained within math. Math is one topic no matter what kind of document we are processing.

MS: Two kinds of math speech: coarse-grained or fine-grained. Most people talk about coarse-grained. If you are reading a p in math, you want to call it p and not probability in fine-grained navigation.

PI: We could have a in which we could specify the local type of math. But that's not going to happen. So one could have settings on a math element that persisted until another math element turned them off. But that's demanding technically. So the math elements would have to have repeated values of such intents. Is that the only way we have? Does each object have to have its own math setting?

PL: It's difficult to specify all fields of mathematics. Accessibility tools read the DOM and can have intent injected with JavaScript.

NS: The accessibility tree is ignored by the AT. The AT looks at the DOM. MathML lives beyond the browsers, MathML is used for many types of documents besides web pages.

DG: We need to develop a list of tools where we want to be able to specify the document forms we should be able to process.

NS: The core work is browser related, but MathML lives in a bigger world that has other formats than browsers. WCAG is an example of a group that goes beyond the browser in their rec. They basically specify the aspirational goals of accessibility and have different documents on how to obtain that in HTML, PDF, etc.

LZ: Their specification separates the stable from the unstable practices, which is great.

BK: ARIA is similar in that they talk about OS-specific accessibility and how to map HTML to that.

DF: 1. perfectly constructed MathML as per spec. 2. the MathML that is out there now and unaware of what we are doing. 3. the current MathML which tries to follow some of the rules we have specified.

NS: We have constructs like overbar, but what character represents this as part of mover? Is it "-", "_", some other Unicode char? Which one will trigger "x bar" as speech? In general, should the spec say what character should be used for common situations. MathML 3 says this for primes and degree.

NS: Going back to a comment Deyan made on the mailing list, if you type a colon, does it mean an actual colon or does it stand for a ratio. You would have to have an intent attribute to make this clear.

LZ: We must be able to deal with characters that look like one another using intents.

DG: Unless we receive an offer from Unicode to include at least another couple of thousand characters, (that look like existing glyphs, but have dedicated mathematical intent), we don't have enough characters to rely on Unicode as a primary solution.

NS: Unicode had too many characters already.

SW: discussed using style sheets to give the meaning of symbols for different subjects. This may be beyond our scope.

NS: If the document is in english, then the math will be expected to be in english.

BM: The emails discussed different levels of accessibility. The bottom level has no interpretation. Higher layers may be topic specific. Should we break down our specifications into layers?

NS: there is nothing we need to do to read out the raw form without interpretation. People would like to have semantic interpretation. There have not been formal studies on this topic so maybe people just think they want a semantic interpretation.

[]<>     Virus-free.<>

Received on Monday, 26 July 2021 21:01:26 UTC