Minutes: MathML intent meeting, 16 Sept

Apologies for the very late minutes -- I thought I had posted them

Attendees:

   - David Carlisle
   - Sam Dooley
   - Brian Kardell
   - David Farmer
   - Deyan Ginev
   - Patrick Ion
   - Mohannad Khasawneh
   - Paul Libbrecht
   - Louis Maher
   - Bruce Miller
   - Murray Sargent
   - Neil Soiffer
   - Daniel O'Mahony
   - Steve Noble
   - Charles LaPierre
   - Cary Supalo

Regrets:

   - Moritz Schubotz
   - Laurence Zaysser

Announcements/updates

NS: Is considering scheduling a breakout session during the TPAC.

NS: During TPAC, is there interest in having a four-hour meeting to write
the MathML spec four from the MathML spec 3?

LM: Can this be done outside of TPAC? Perhaps before TPAC?

NS: During this meeting, if we have a fork and branch, will it show up on
Github?

DC: says it can be done.

BK: Many systems integrate previews.

NS: says it is more effective when everyone works together.

NS: TPAC spans October 18-29.

The breakout meeting would occur during the second week.

NS: Content MathML will not change much in spec 4.

We decided not to have a writing meeting during TPAC.

DC: Unicode 14 was released.

NS: This might change the math variants.

NS: The operator dictionary will not change.

DC: There are extra script characters.

MUS: Mostly, people do not care what math style they get.
Gap Analysis Doc

The document is at (
https://docs.google.com/document/d/1Pzsf2dqTkbYXFmoKCLzvtrNERNmtF2MHX1WtugB3PfA/edit#heading=h.k21427jotzf1
).

NS: I've done some work on the gap analysis document. In this meeting, I
want to focus on:
a) a new topic suggested by Brian -- what the browser accessibility tree
looks like now for math and what it should look like. [see section I wrote
as a first draft]

NS: AT normally deals with a web page by reading an accessibility tree.
This tree is parallel to the DOM except that it is simplified.

If there are low-level system APIs that AT reads, like MSAA and UIA in
Windows , and ATK in Linux, that is what the AT gets. New roles have been
introduced by Apple. There is a MathML interface.

Under Linux ATK new roles have been introduced. Perhaps only two or three
new roles. This is not enough for MathML.

MUS: If the AT runs into a MathML zone, the UIA returns math speech.

UIA was not changed.

UIA extends to 18 languages.

There is an xml that can be used by speech.

NS: What do we want to be in the accessibility tree?

BK: We need to get the experts in these accessibility trees to say what
should go in them.

NS: If we can't put MathML in the accessibility tree, then the AT must
leave the tree and go back to the dom.

NS: Added a paragraph on SVG. SVG relies on ARIA for accessibility. Most
things in SVG are not exposed to the accessibility tree.

NS: Invites comments on his new accessibility tree section.
b) ARIA section

NS: rewrote the ARIA section. In summary: he suggests putting an aria label
on MathML. It would be plain text. The long "A" has the short "A" sound.

NS: You will not have any Braille code coming out of ARIA. This could be
changed with a spec change. Screen readers to not look at ARIA labels. The
spec could be changed to fix this. The ARIA label needs to be everywhere
where the default reading is not what you want. MathJax tries to do this.

Previously DG: suggested using the Aria-label-by attribute. DG: suggested
using a hack to use mrows to add more information where necessary for
accessibility. This would provide content that ARIA did not have.

BK: Many of the problems that we have are web wide. We will have to have an
argument that says that these issues need to be solved now for math
accessibility.

NS: DG: showed that you could use describe-by attributes to help some
cases. We would like to have text with ID in the ARIA label.

NS: The CSS section needs to be written. NS: does not feel qualified to do
that.

BK: does not feel qualified to write it either.

BK: In different sections we talk about ways to express relationships. We
have two ways to do this: by direct link relationships, and selectors.
Selectors are the platform way to do things. We may need a means of
selection.

BK: Anything involving annotations effects the entire web. What are the
needs of the accessibility tree? How can we handle these needs?

**ACTION* BK: will expand the bullets that are already in the document. BK:
wants this section to be short.

*ACTION* SD: will work on the parallel section to resolve all the comments.