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>

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: <mlongdivision> <mdivisor> <mrow> <mdigit>4</mdigit> <mdigit>0</mdigit> <mdigit>0</mdigit> </mrow> </mdivisor> <mdividend> <mrow> <mdigit>1</mdigit> <mdigit>9</mdigit> </mrow> </mdividend> <mquotient> <mrow> <mdigit>2</mdigit> <mdigit>1</mdigit> </mrow> </mquotient> <mremainder> <mrow> <mdigit>1</mdigit> </mrow> </mremainder> <mdivprocess> <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> </mdivprocess> </mlongdivision> 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. Cheers! Chris Weaver Program Coordinator Mathematics Accessible to Visually Impaired Students (MAVIS) New Mexico State University (505)-646-2664 chrweave@nmsu.eduReceived 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
*