[coyotos-dev] OSDoc issue

[Jonathan S. Shapiro]

On Wed, 2008-03-12 at 21:01 +0100, Marcus Brinkmann wrote:
> At Wed, 12 Mar 2008 15:36:17 -0400,
> "Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> > Question: If the consequence of adopting MathML is giving up text
> > browsers, how big a problem is this?
> 
> Not sure what your particular concerns are.  I have friends working on
> accessibility, and their objective is to make sure that the same tools
> everybody elses use are accessible.  That means that, for example,
> although some blind people will use text browsers, many will use
> graphical browsers with a screen reader or braille terminal.  This is
> also important, for example, so that users with and without
> disabilities can share the same computer and work together on it.
> 
> Is this the kind of information you are looking for?

Yes and no. Basically, I'm worried that adopting MathML may have the
consequence that portions of our site will cease to be accessible to
users of elinks and other text-based browsers. I don't make a big deal
of it, but a surprising amount of energy went in to OSDoc to ensure that
our sites were browseable with elinks.

>From limited experiments, it appears to me that ELinks does something
rational when it is presented with MIME=application/xml or
MIME=application/xhtml+xml, at least with respect to the HTML portion of
the XHTML content -- even when it is pointed at XHTML pages containing
MathML content. This doesn't help get the MathML rendered for users of
elinks, but it at least means that any page which is currently a pure
HTML page will still be readable if it is converted to XHTML.

Does this seem reasonable to you?

Unfortunately, I do not know any way to get MathML rendered sensibly by
a text-based browser. We will be producing renderings in both online and
printable form just as we do now. This seems to be the state of the
practice, but if there is some way to do better for visually impaired
users I would very much like to know about it.

If nothing else, encoding these parts using MathML seems strongly
preferable to encoding using SVG, which is an argument in favor of
XHTML.