W3C home > Mailing lists > Public > www-math@w3.org > May 2000


From: Christopher A Weaver <chrweave@NMSU.Edu>
Date: Tue, 30 May 2000 12:23:03 -0600 (MDT)
To: www-math@w3.org
Message-ID: <Pine.SOL.4.02.10005241729060.12626-100000@emmy>
Greetings MathML working group menmbers

One of the difficulties that developers of accessibility software face is
the inability to recognise the logical structures that are required to
accurately render the material acording to the rules of a particular
accessible medium.  This is painfully true in regard to North American
braille mathematics (Nemeth Code).  In addition to the logical elements of
text structure one has to worry about the logical elements of mathematical
expressions.  Sadly, most current texts and web documents do not present
mathematics in a usable, logically structures manner.

However, MathML 2.0 is a step in the right direction, If Texts were marked
up up with MathML this burden would be greatly reduced.  The presentation
markup is exquisitely explicit in it structuring of most mathematical
expressions.  In fact, All post secondary mathematics that is marked up in
XHTML1.0 and MathML2.0 can be automatically transcribed, provided that
there is a standard representation of all glyphs used in the text
(Non-standard glyphs require a transcriber's interpretation).

I am quite fond of the clarity of the exposition in sections three and
four.  I find them readable and intuitive. Section 3 in particualr
provides enough presentation hooks to effectively transcribe post
secondary mathematics. Sections one and two are a good introduction to
sectionss three and four.  I find section five less clear. I assume that
this is due to the authors leaving it as an open suggestion rather than a
clear standard.  However, some clear standards may be useful in some
circumstances. The rest of the sections and apendecies serve as useful
implementation tables and references.

There are two issues that I think need to be resolved before I would
consider MathML completely accessible.  First, I believe that some sort of
mnemonic glyph references should be kept around to ensure that MathML is
human readable.  This is a minor requirement, but we can assume that
humans, in particular blind ones, will be reading MathML source at some
point. And naturally, blind people do not have the same visual
associations for unicode characters that sighted people do.  Of course the
mnemonics for the standard glyphs need to be extensible.

The second issue that I think needs to be adressed is the presentation
markup for spatial mathematics.  As it stands, the presentation markup
consists of <mtable> and children.  This is not specific enough to allow
automatic generation of grade school level Nemeth Code.  Specifically, it
is difficult to tell what kind of elementary mathematical construction is
to be translated, and thus it is difficult to make construction specific
decisions in the translation process.  

Perhaps this is an activity that is more appropriate for a future edition
fo MathML, but the comittee should devise a presentation markup for
spatial mathematics that declares the overall structure and all relevant
substructures in a mnemonic, abstract way. I have been told that this can
be accomplished by means of including content markup with the presentation
markup, but I would like to have the presentation markup stand alone int
he regard because I don't trust authoring tools to add content markup
where it is needed. Moreover, such an abstract markup fr the presentation
will allow renderings other than those specified by an alignment table.

For example consider the following long division problem:

      <mdigit>4</mdigit> <mdigit>0</mdigit> <mdigit>0</mdigit>
    <mrow> <mdigit>1</mdigit> <mdigit>9</mdigit> </mrow>
    <mrow> <mdigit>2</mdigit> <mdigit>1</mdigit> </mrow>
    <mrow> <mdigit>1</mdigit> </mrow>  
    <mrow> <mdigit>4</mdigit> <mdigit>0</mdigit> </mrow>
    <msubtractrow> <mdigit>3</mdigit> <mdigit>8</mdigit> </msubtractrow>
    <mrow> <mdigit>2</mdigit> <mdigit>0</mdigit> </mrow>
    <msubtractrow> <mdigit>1</mdigit> <mdigit>9</mdigit> </msubtractrow>
    <mrow> <mdigit>1</mdigit> </mrow>

Granted that this has much work to be done in terms of definitions, but
assuming that things were defined adequately, this presentation spells out
all of the necessary parts to reconstruct the division of 400 by 19 via
the usual division algorithm.  The final physical presentation is the
responsibility of the renderer.  This, I believe is consistent with the
principal of mnemonic abstractions that drives the current presentation
markup specification, and should therefore be included with it.

As a final thought, the principal of mnemonic abstractions is what makes
the presentation markup usable.  At some level, all mathematics notation
is merely a collection of glyphs, sized and positioned approproiately.
For example, one half would be a 12-point 1 over a lne over a 12-point 2. 
This approach to mathematics presentaiton is being used by graphic design
software, and it is totally inadequate for automatic filtration.  As
advocates in the disability community have said over and over again, we
need hooks! MathML2.0 by and large provides these hooks in the
presentation markup, and I encourage the comittee to keep this philosophy
and add more hooks inthe domain of spatial mathematics.


Chris Weaver

Program Coordinator
Mathematics Accessible to Visually Impaired Students (MAVIS)
New Mexico State University
Received on Tuesday, 30 May 2000 14:24:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:27:30 UTC