Re: MathML Accessibility in Gecko

--===============7305000260782524097==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="ghzN8eJ9Qlbqn3iT"
Content-Disposition: inline


--ghzN8eJ9Qlbqn3iT
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, Apr 01, 2014 at 05:01:36PM -0400, Alexander Surkov wrote:
> MathML token or MathML glyph could be exposed as object attributes I guess
> if necessary.

why shouldn't it be the accessible's text or maybe its name?

> Having relations might be nicer since it's not MathML tree dependent. Say
> if ARIA got math extension and author starts to not follow MathML tree
> conventions.

the answer to aria extensions for math should just be "no" and the
answer to people who want to use aria on math ml content should be the
same unless they have a very compeling use case which I'm pretty sure
they don't.

Trev

>=20
>=20
> On Tue, Apr 1, 2014 at 4:38 PM, Jonathan Wei <[email protected]> wrote:
>=20
> > On Tuesday, April 1, 2014 12:13:00 PM UTC-4, Trevor Saunders wrote:
> >
> > > do we really want to add another interface? It'll take time before we
> > >
> > > can assume its available everywhere, and more importantly it runs the
> > >
> > > risk of baking equation =3D=3D mathml, and if people want to expose
> > >
> > > equations accessibly but don't start with mathml they'll have to fake=
 it
> > >
> > > somehow.
> >
> > 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
> > something else, they can do so anyway.
> >
> > With regards to the addition of another interface, I'm not sure why it
> > would matter if it's not immediately available everywhere, apart from
> > maintenance of an implementation that no one is using yet - unless that=
 was
> > your point, as you've mentioned before in the meta-bug.
> >
> > I think most of the useful functionality can be exposed solely through
> > roles and relations, so it's possible we don't need a dedicated public
> > interface.  The only thing in the interface right now is the tokenValue
> > attribute for obtaining the value of a MathML token element or MathML g=
lyph.
> >
> > > Why do we need this? it seems like its the same exact interface as
> > >
> > > nsIAccessibleTable with some stuff removed.
> >
> > It is indeed basically the same, to the point that the implementation
> > borrows quite a bit of code from the HTML table implementation.  I adde=
d it
> > because I thought it might be useful to have a like interface to
> > nsIAccessibleTable that allows you to iterate over the table returning
> > objects implementing 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 the regular nsIAccessibleTable interface used =
if
> > necessary.
> >
> > > More roles seem fine, and relations might be good but I think your wi=
ki
> > >
> > > page may be adding too many, e.g. do we really need all the fraction
> > stuff? or
> > >
> > > can we just say for an accessiblewith ROLE_FRACTION child[0] is the
> > >
> > > numerator and child[1] is the denominator and that's it?
> >
> > For the simple structures like fractions, I agree that half the relatio=
ns
> > aren't really needed, since MathML rigidly defines which child must
> > represent what part of the structure.  My general idea with the relatio=
ns
> > was to have them be a fairly comprehensive set for the structures, with
> > both forward and backwards relationships.  This was addressing a point
> > brought up offhand by Jamie in comment 23 on the meta bug (
> > https://bugzilla.mozilla.org/show_bug.cgi?id=3D916419#c23).  I guess we
> > could just have the backwards (e.g. numerator to fraction) relationship=
s,
> > but it seems unbalanced.  Maybe that doesn't really matter, though.
> >
> > For more complicated structures like <mmultiscripts>, we'll still need
> > relationships going forwards and backwards to be able to give useful
> > information about the structures.
> > _______________________________________________
> > dev-accessibility mailing list
> > [email protected]
> > https://lists.mozilla.org/listinfo/dev-accessibility
> >
> _______________________________________________
> dev-accessibility mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-accessibility

--ghzN8eJ9Qlbqn3iT
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

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

iQIcBAEBAgAGBQJTOzVUAAoJEB+OKtVG4HCUNiMQAJkpywqi/Ar3AybgzhrqP7Mu
MHW9MXOhIRv8bNNlCpFzHXCEF7zzFVOLxdZX7iu+BC29+0QlPezkVSL4mYvWFrFR
+mXSz5jpCGAybu4XMt3aws1qAFOsJEjgfV5086HVLhx6ZqObL/44ZUnsiJH2DDQU
Qo2SE02/snYs5cNU7yUKqmYbvLi1zx73Mrpn1nDAoxEELOWG4iEiExAl93fxNIeZ
gLNWZwcX9ClMeIY5VFnh8IxTUmaERIEMnOaNe/yVoGVJNNfAuhOniNWPbyRyWjIQ
TH4jVjRp/lhZgOSs2+ThWrl243KkodtYqZFGYD5F4Bdy6V6Nr9IjiqOQ5HAFZA4g
NkjwnTzpNZc1IIZH2xdlo6P2JWGoXw88EQWzrjChPEAfnKJ31BuSRJC8k+6PRtFs
7dLySDX4Vw9szFCnNWemk41ptBbTRpdV4iBHlmE34o4O2bp4GABco020tRajl/gF
mEScbnfwXxiq84ePy2xC1HLxaFzbJE8AKuLAITt6hUhHqoxQ+1BeHs+Xwl71e3xz
Y3yZgAad98U62goZGmk0eGlGizA7mzQ5wdWccy9oipY1aHApymmPbmkrhf8/XT+e
X+kAGNrNM6jniZDeLN1wMRpeOqwT/N2CgiXBS5ojJhroBxIMfed3jCJnh2ziZQXj
I9aB2TqQPEoKHqwLhJuZ
=h9Ic
-----END PGP SIGNATURE-----

--ghzN8eJ9Qlbqn3iT--

--===============7305000260782524097==
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

--===============7305000260782524097==--