Re: [www-math] <none>

> It would be quite informative for the group to understand why and where
these inconsistencies arise, and if different implementers have strong
reasons for their choices

This is easy to answer: because people have limited resources and they
implement what they can and based on their guess as to what is most
important and what they know. There are no rules or guides as to what to do
and the space of options is vast. There are thousands of Unicode characters
that might occur in STEM content. If you only have time to translate
200-300 of them, there is nothing out there at the moment that says "these
are the most common ones" or even more specifically, "in calculus, these
are the symbols that are used" (actually I do have a paper with some data
on calculus textbooks, but it is only based on a few calculus books).
Similarly, there is nothing out there saying "these are common notations".
People usually implement squared, cubed, square root, and cube root, but
commonality rapidly drops from there. There isn't anywhere that says "use
... from .. to  ... of ...' for large ops in an munderover, etc., so some
systems might miss that.

As for inviting implementers...

I more or less represent what NVDA does since I did MathPlayer, and now
MathCAT and those are what most people use with NVDA AFAIK -- there is also
Access8Math addon but I don't think it is widely used based on people I've
talked to.

The other screen readers are JAWS, VoiceOver, and ORCA (linux). I know a
contact at JAWS I can ask about joining a call. Based on past experience
where other W3C groups asked for someone to talk with them, there is only a
small chance that will happen. But if the group is interested (I'll poll
the group at the meeting next week), I'll ask.

I don't know anyone in the VoiceOver group. Apple does have a
representative in the ARIA group -- maybe he can suggest someone. It's a
long shot they will be willing to join for a call -- Apple tends to be very
tight-lipped/standard committee avoidant.

I've been trying to find someone to talk to in the ORCA community about
their math support. I know a previous developer, but she hasn't worked on
math in years and has moved up the W3C food chain and is extremely over
committed now and said she can't help me; again dubious she would want to
talk to a group given she doesn't work on math accessibility anymore.
AFAIK, no one has worked on math accessibility in ORCA in years.

In the group, both Steve and Sam have been in the AT community for years;
Sam is an AT developer. So we do have some pretty good expertise in the
group wrt to accessibility.


On Fri, Feb 10, 2023 at 12:37 PM Deyan Ginev <> wrote:

> Hi Neil,
> Would it be possible to invite multiple AT representatives from the
> systems in question to the group? Maybe not as permanent members (as that
> is a large admin burden) but at least for a small invited talk each?
> It would be quite informative for the group to understand why and where
> these inconsistencies arise, and if different implementers have strong
> reasons for their choices.
> Some would consider that as a prerequisite to standardizing one outcome
> over another, which is what a "Default" ruleset represents.
> It would also be helpful to get written testimonies of the affected AT
> users, so that we can get a clearer view of their pain points. Consider the
> way arXiv excerpted their user study as five "Themes" at the end of their
> accessibility report:
> It is easy to believe there is room for improvement, but hard to see the
> constructive actions our group could take without more thorough preparation.
> Greetings,
> Deyan
> On Fri, Feb 10, 2023 at 3:26 PM Neil Soiffer <> wrote:
>> I was part of a virtual STEM accessibility conference for the last two
>> days. In the wrap up, a few people complained that there isn't a lot of
>> consistency among AT. Some read one character ok (in MathML) and another
>> won't read it. I'm not sure whether anyone complained about inconsistency
>> with the speech other than dropping characters (JAWS seems to drop parens
>> in many cases where it shouldn't) or speaking something ambiguously. I
>> volunteered that our group was considering issuing some baseline guidance
>> to AT as to minimal support they should have and people felt that was a
>> good idea.
>> This relates back to defaults. Whether we add something to spec in an
>> appendix or produce a note, it seems like the AT users at least feel it
>> would be a good idea to have some minimal baseline all AT should support. I
>> suspect that it would also be helpful for AT developers so they know "this
>> is the important part" -- don't skip support for these notations and these
>> characters.
>>     Neil

Received on Friday, 10 February 2023 21:12:56 UTC