[Blindmath] What does "support braille math in a screenreader" mean technically?

Mon Feb 21 02:02:49 UTC 2011

As a deaf-blind user and programmer, a completely tactile system is not 
just a thought. It is a necessity. That is one reason I am working on 
BrailleBlaster, which will produce braille math and also tactile 
graphics. Part of this work is with liblouis and liblouisutdml. These 
are C libraries and could be used in screenreaders to convert MathML 
into various Braille mathematics codes.

John

On Sun, Feb 20, 2011 at 07:29:03PM -0600, qubit wrote:
> Hi Mike --
> I want to remind those not directly affected, but many of the users of 
> braille displays are deaf-blind and therefore can't hear sound.  For this 
> reason I think that the goal needs to be something that could, at least 
> optionally, be completely tactile.
> This doesn't mean no work should be directed toward representations in 
> sound, just that a completely tactile system should always be an 
> alternative.
> Just a thought.
> --le
> ----- Original Message ----- 
> From: "Michael Whapples" <mwhapples at aim.com>
> To: "Blind Math list for those interested in mathematics" 
> <blindmath at nfbnet.org>
> Sent: Sunday, February 20, 2011 3:39 PM
> Subject: Re: [Blindmath] What does "support braille math in a screenreader" 
> mean technically?
> 
> 
> Hello,
> Susan, your first comment is something I have been thinking about for
> some time, Braille translation, particularly for maths, up to now has
> really not been perfected in quite a number of years of people working
> at it. Therefore, is the call simply for Braille support a "dead end",
> will it ever be perfected?
> 
> There probably is a place for Braille, but I am more thinking of when
> using a screen reader where interaction with the computer is possible
> then might there be better, more interactive ways of accessing the
> maths? Also might more interactive ways of exploring the maths be a
> simpler problem to solve?
> 
> While I haven't got a full idea together yet for what this more
> interactive reading would be, knowing how people process equations would
> be useful (any links), here are some thoughts which may help understand
> what I mean.
> 
> MathPlayer, while being good in accessing the mathml, I think we can all
> agree really does not use the computer to its full to give the best user
> experience (some of the limitations are external to design science and
> there is nothing which they can do without help from other companies).
> One area where MathPlayer is weak, is easy navigation of the equation,
> currently you must wade through the words of what the equation is. There
> may be times where you don't need fine details of the equation but the
> general form of the equation. May be parts of the equation could be
> presented to the user in a more concise form (an example might be the
> systm shown in the presentation "Spoken Mathematics Using Prosody:
> Earcons and Spearcons" as presented at ICCHP 2010). May be certain
> elements (eg. fractions) could be container objects (like voiceover on
> the Mac handling tables, or NVDA's object navigation), so you can either
> skip over the fraction should it be of little interest at that time but
> should you need more detail then you could descend into the fraction to
> look at detail.
> 
> Also by using a computer there might be a more natural way of
> communicating the mathematics (speech is one example) and so it probably
> will be relevant to more people, therefore it would have a higher value
> to the screen reader vendors, so having a greater chance of being
> implemented.
> 
> Michael Whapples
> On -10/01/37 20:59, Susan Jolly wrote:
> > Despite the Nemeth code having been a US standard for something like
> > 40 years, there is no transcribing software that can currently convert
> > print math fully accurately to Nemeth.  (By print math I mean
> > electronic math represented as either LaTeX or presentation MathML.)
> > This problem persists despite there having been a significant amount
> > of work addressing this issue. The same is true for other math codes
> > but since I know more details about Nemeth I will stick mainly to that
> > code here. So it seems to me that it is more than a bit unlikely that
> > screenreader developers would have the resources to accomplish
> > something that many others have not succeeded at.
> >
> > I know there is currently a French project attempting to put support
> > for several math codes, including Nemeth, into OpenOffice.  I don't
> > know how that is progressing.
> >
> > Please remember that the Nemeth code is a complete code; it has rules
> > for both text and math.  The rules for text are quite similar to the
> > rules for EBAE (English Braille American Edition) but have minor
> > changes as necessary for compatibility with the representation of
> > math.  The reason this fact is significant to this discussion is that
> > it is my understanding that screenreaders or display drivers that
> > convert to braille text in real time use the EBAE rules for text, not
> > the Nemeth rules.
> >
> > Officially here in the US, materials transcribed according to the
> > Nemeth code must consistently follow all the rules of that code.
> > However, my guess is that many Nemeth readers would be quite happy if
> > the text portions of an HTML document were to be transcribed according
> > to EBAE while MathML islands were transcribed  according to the Nemeth
> > rules for math.  I just noticed that the latest version of DBT
> > (Duxbury's software) has something similar in that it allows for
> > Nemeth math to be used with various non-English choices for text.
> >
> > There are others on this list who understand the details of MathType
> > and of screenreaders so this next may be a bit simplistic.  But it
> > seems to me that the minimum you'd want is for a screenreader to
> > simply recognize MathML islands and to at least have the capability to
> > pass their contents through a user-supplied filter on the way to the
> > display.
> >
> > Finally let me point out that there are some serious formatting issues
> > to be addressed when targetting braille math to a braille display. I'm
> > referring to both simple issues such as where to break a line and more
> > complex issues involving planar layouts.
> >
> > I'm hoping for feedback here.
> >
> > SusanJ
> >
> >
> >
> 
> 
> _______________________________________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://www.nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> To unsubscribe, change your list options or get your account info for 
> Blindmath:
> http://www.nfbnet.org/mailman/options/blindmath_nfbnet.org/lauraeaves%40yahoo.com 
> 
> 
> _______________________________________________
> Blindmath mailing list
> Blindmath at nfbnet.org
> http://www.nfbnet.org/mailman/listinfo/blindmath_nfbnet.org
> To unsubscribe, change your list options or get your account info for Blindmath:
> http://www.nfbnet.org/mailman/options/blindmath_nfbnet.org/john.boyer%40abilitiessoft.com

-- 
John J. Boyer; President, Chief Software Developer
Abilitiessoft, Inc.
http://www.abilitiessoft.com
Madison, Wisconsin USA
Developing software for people with disabilities