Re: MathML Accessibility in Gecko

--===============8377691318725119890==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="oC1+HKm2/end4ao3"
Content-Disposition: inline


--oC1+HKm2/end4ao3
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 01, 2014 at 01:38:03PM -0700, Jonathan Wei wrote:
> On Tuesday, April 1, 2014 12:13:00 PM UTC-4, Trevor Saunders wrote:
>=20
> > do we really want to add another interface? It'll take time before we
> >=20
> > can assume its available everywhere, and more importantly it runs the
> >=20
> > risk of baking equation =3D=3D mathml, and if people want to expose
> >=20
> > equations accessibly but don't start with mathml they'll have to fake it
> >=20
> > somehow.
>=20
> Currently, it doesn't appear we use the equation role for anything other =
than the <math> tag, so if people want to write equations in HTML or someth=
ing else, they can do so anyway.

I'm more concerned about the platform API here, and it seems pretty
reasonable to me that say a spread sheet appwould want to provide
equations that don't come from math ml.

> With regards to the addition of another interface, I'm not sure why it wo=
uld matter if it's not immediately available everywhere, apart from mainten=
ance of an implementation that no one is using yet - unless that was your p=
oint, as you've mentioned before in the meta-bug.

no, suppose we ask to add an interface and they do it, then we still
have to deal with that atk interface not existing everywhere for a long
time.

> I think most of the useful functionality can be exposed solely through ro=
les and relations, so it's possible we don't need a dedicated public interf=
ace.  The only thing in the interface right now is the tokenValue attribute=
 for obtaining the value of a MathML token element or MathML glyph.

istm that should just be the accessible's text, and as I said earlier
I'd rather not have something math ml specific in any interface we do
need.

> > Why do we need this? it seems like its the same exact interface as
> >=20
> > nsIAccessibleTable with some stuff removed.
>=20
> It is indeed basically the same, to the point that the implementation bor=
rows quite a bit of code from the HTML table implementation.  I added it be=
cause I thought it might be useful to have a like interface to nsIAccessibl=
eTable that allows you to iterate over the table returning objects implemen=
ting the MathML accessible interface.  The single differentiating method to=
 get the row label relies on a MathML feature that isn't supported in Gecko=
 yet anyway, so the MathML table interface could probably be scrapped and t=
he regular nsIAccessibleTable interface used if necessary.

I'm not sure I understand the iterating idea, but of course I'd rather
not add code that doesn't do something new.

> > More roles seem fine, and relations might be good but I think your wiki
> >=20
> > page may be adding too many, e.g. do we really need all the fraction st=
uff? or
> >=20
> > can we just say for an accessiblewith ROLE_FRACTION child[0] is the
> >=20
> > numerator and child[1] is the denominator and that's it?
>=20
> For the simple structures like fractions, I agree that half the relations=
 aren't really needed, since MathML rigidly defines which child must repres=
ent what part of the structure.  My general idea with the relations was to =
have them be a fairly comprehensive set for the structures, with both forwa=
rd and backwards relationships.  This was addressing a point brought up off=
hand by Jamie in comment 23 on the meta bug (https://bugzilla.mozilla.org/s=
how_bug.cgi?id=3D916419#c23).  I guess we could just have the backwards (e.=
g. numerator to fraction) relationships, but it seems unbalanced.  Maybe th=
at doesn't really matter, though.

so, if you even need the numerator / denominator to relations to get
what Jamie wants there is unclear to me, I think it depends on exactly
how else you represent things.

For example if you represent (1 + 3) / (2 + 4)
as an accessible with role fraction whose children are accessibles with
role grouping then you need to walk the tree to find out your in a
fraction (which should be faster than checking if the relations are
there I think)

On the other hand if the representation is an accessible with role
fraction whose kids have role numerator and denominator then you escape
needing to crawl the tree or use relations but might be forced into have
more or less useless accessibles.

btw I sort of think Jamie is just wrong there, checking for relations is
btw I sort of think Jamie is wrong here, crawling the tree is probably
faster, and the relations would just do that internally anyway.

> For more complicated structures like <mmultiscripts>, we'll still need re=
lationships going forwards and backwards to be able to give useful informat=
ion about the structures.

 I'm not exactly sure how that works, but trying to stuff it into
 accessible text is kind of appealing especially considering you can do
 sub scripts and super scripts in html / css.

Trev

> _______________________________________________
> dev-accessibility mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-accessibility

--oC1+HKm2/end4ao3
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJTOzO1AAoJEB+OKtVG4HCUzpwQALSxUngt+NPQnx52KYa4xmyh
O/okw8zJxpQ5hBRN9En80XNB8S9vnyRcBWhUkkmYQvKQNr2vZeZ1q4wItqIC7x73
b7UyTsqNhK1m6iSSoFxDaFeE5SHr82LYgr0jYDXPXC1C/4Bu+QMeLNJgSGt2E2AK
jt5KIYLMSSxwzqBnXlkpk/R+FSQiwwC2jpTHqCEG61dOZ8jL7ZTSLdCQ8kOE5PPj
u0z2gX61hv/cQxpl25K5PXUM+HoVCT6r8QzFyTFgxR23x+9SSB+n6taP90x+3qMU
vl5I88lL/VHjTXTezyesfmTCUtZqlC5E73LxjtWG4R85Tl3bnhN2hIGWSmLOFxHF
WQIBOzZk/0cBdK58h5odXnQmKb1KNRhGFUJkpG3JyE8Fq0LmG5ryy6C4JAWHdJBv
8EDoRPMt7ECv8hz0VkrL3PY7USxJWlqoE0Stjf5BAD+GxZ04uwtE2KoCnRlIyz+Z
1G0Y+VpjZB2ypIfDyV7tOQFO8aoHb0fir+xzNSt94Cz5Pgab4ZvTUeYpJ1YI5vUT
HeAFX8nVGICmfv/ZLODl93EhcOjEd9Cq6bde0lJCkQKAHgNb1y4XqzNMtbNF0pLn
6D0RhIzZu27CeYfD4p1st1Smb/Nlz5AFjyl0bvpcTthTAqxpPBxE1Kl/3lIhdtbG
iNg34QZkDr6riywD2/N0
=z+Sb
-----END PGP SIGNATURE-----

--oC1+HKm2/end4ao3--

--===============8377691318725119890==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
dev-accessibility mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-accessibility

--===============8377691318725119890==--