Minutes: MathML General Meeting, 15 July


   - Bert Bos
   - David Carlisle
   - Christopher Comninel
   - Sam Dooley
   - David Farmer
   - Deyan Ginev
   - Brian Kardell
   - Charles LaPierre
   - Paul Libbrecht
   - Louis Maher
   - Bruce Miller
   - Murray Sargent
   - Cary Supalo
   - Neil Soiffer
   - Moritz Schubotz
   - Laurence Zaysser

Regrets:Announcements/updatesFPWD status

DK will be out for the nextg three weeks.

DK: says the FPWD is ready to go out. Bert will send it out.
Action Item followup

NS: created a wiki page whith the tasks that people volunteered to do. It
is at https://github.com/w3c/mathml/wiki/Charter-Work-Assignments
Anything elseBraille and needs for intent -- see mail archive thread. Any
further follow up?

MS: has a hot key which will show a default expression, or will give more
detail about the expression.

NS: put intent, for Braille, in the MathML.

NS: how do you know when a colon is used for punctuation or a ratio. Must
have an intent attribute to tell you this.

NS: asks SD: to look for cases that can be interpreted different ways.

If you are looking at sin x, is the next thing you read part of the sin's
argument, or is it outside of the sin function. Your hot key could tell you
this. It would show you where the sin argument ends. This information is in
Microsoft word, but the Braille display may not show the end of the
argument by default.

The hot key will give you more information about the expression.

DG: for the colon character, the hot key will tell you which mathematical
operation the colon stands for. DG gave ten things the colon could be used
for in his emails.
Deyan Presentation on latest idea of using ARIA

DG: Three examples using ARIA over MathML to successfully narrate English
via Screen Reader in Chrome.

   - binomial coefficient; point with coordinates; French notation for open

DG: Tab navigation is possible via tabindex.

DG: aria-label with aria-labelledby allow to encode our explicit intent
expressions such as binom($1,$2) as aria-labelledby="binom arg1 arg2".

DG: Literal values can not be mixed in with the lists of IDs, which is a
handicap compared to our intent syntax. One can work around it if using
"phantom" elements that only hold attributes ("id" and "aria-label"), such
as an empty mrow element.

DG: ARIA allows for encoding the second type of information we had
encountered in our old examples, such as the "Ackermann-function" written
with a simple capital "A". Rather than have it always spoken via
aria-label, one can use aria-describedby, to host arbitrary auxiliary
information, which is only narrated to the reader if requested. E.g. in
Screen Reader, one needs to click twice on a MathML element to hear its
description, after the main content is narrated. There is a change of
pitch, which is helpful.

DG: Things get more artificial when thinking of adding connectives, such as
"from", "to", "and" to the narrations, which would also require their own
phantom nodes. But that is decidedly too low-level, almost akin to
reinventing an AT tool inside the document markup.

DG: Instead, the big win would be if we can recommend using our Level 1
list of intent values as standard values to aria-label. In that scenario,
the AT tool would encounter say "binom" and recognize it as a standard key
in the dictionary. Then the AT tool can insert all connective words,
prepare appropriate Braille, localize to a specific non-English language,

DG: And we can still keep the open-endedness of Level 3, as reading
verbatim a name from that list continues to sound like acceptable English,
so they are reasonable values of aria-label attributes.

DG: While an ARIA demo can be made to work, it is not exactly "production
ready". The main math element has hardcoded behaviour and can't be used
directly. Luckily, mrow's have ARIA enabled, so anchoring the annotation at
the highest mrow was a successful workaround.

[ group discussion follows with small clarifying questions from most
attendees, not fully minuted ]

-- end of demo --

NS: ARIA is not used by screen readers when speaking/brailling MathML.
Using ARIA is problematic because it overrides braille and so would mess up
braille math code generation. ARIA has a draft that includes braille
labels, so that could help.

DC: continue with intent then maybe come back to ARIA.

LZ: use ARIA attributes that already exist is a very healthy proposal from
the publisher perspective. It would be a large investment to support a new
syntax, much easier to implement relying on an existing one.

CLP: We should not abandon intent, as the ARIA approach has technical
drawbacks that may be awkward for certain toolchains, and we need to
evaluate further. In particular, in documents with thousands of formulas,
managing global ids on every MathML node would be prohibitive for certain

Moritz: Maybe look at Frédéric's examples on
for how systems speak math.

BM: does anyone have contacts with the ARIA group?

NS: we can file github issues with them. Or we can have a proposal for tpac
for the ARIA group.

NS: continue discussion on what we should do with ARIA labels and what
needs to get produced. Get a discussion going with email.

DG will work with Neil to get a proposal describing what they want to do

ACTION: NS will try DG's method with JAWS and NVDA.

Received on Thursday, 22 July 2021 04:53:39 UTC