On 09-Jun-26 22:46, Carsten Bormann wrote:
On Jun 9, 2026, at 11:59, Martin J. Dürst <[email protected]> wrote:
I agree with the fact that we cannot resolve this precisely in a policy document.
However, I think that the boundary the document is trying to set forces too much to be
"Math" when simple text would do the job without any problems.
I have the same impression.
Is "x > y" illustrative in plain text? From a quick test, a screen reader is very likely
to read it as "x y". Are we going to require MathML for such a case?
If a screen reader reads "x > y" as "x y" rather than as "x greater than y" (or at least something
that not just drops the ">", such as "x greater-than sign y"), then I think this is the screen reader's fault,
not the author's.
The document may fail to distinguish “mark as Math/formal expression/code” from
“use MathML”.
Marking up math/code in running text is currently not very well supported.
The document says "That guidance should include updates to style guides to provide
advice on how to decide when math forms are to be preferred over ASCII or Unicode
workarounds that have been historically used in the series.".
It would be my reading that "x > y" is NOT an ASCII workaround, it's just using
ASCII because the formula is within the ASCII repertoire. The same might be said for "α + β
+ γ = 180°”,
Well, that is not ASCII…
The point is not about ASCII, but plain text.
Yes. And Martin is correct that a screen reader should get ">" right (the one I used is freeware and not very
good). But according to RFC 20, "-" is either a hyphen or a minus sign. A screen reader cannot tell them apart,
so what is "α - β"? Similarly, "." might be a decimal point or a full stop (a.k.a. period). It seems
to me that if you want to be sure that even trivial math always works, you need markup for guaranteed accessibility.
Brian
(Plain text as opposed to the 2D text (“ASCII art”) tricks we have been playing
(see Figure 1 of https://www.rfc-editor.org/rfc/rfc9100.txt for an example),
which indeed should no longer be used once we have workable math in RFCXML.)
Where I would start to see workarounds is using Unicode superscripts and
subscripts, and other tricks for more complex formulæ.
<sub>/</sup> are not tricks, they are markup.
They mix well with plain text.
(I don’t think using "2<sup>64</sup>" is “math”, and neither is “B<sup>ε</sup>
tree”.)
… skipping more useful comments from Martin…
Grüße, Carsten
--
rswg mailing list -- [email protected]
To unsubscribe send an email to [email protected]
