Quantcast

MathML Accessibility in Gecko

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

MathML Accessibility in Gecko

Jonathan Wei
Hi,

Based on the comments posted on
https://bugzilla.mozilla.org/show_bug.cgi?id=916419, I've drawn up a
fairly rough interface to expose MathML constructs as an accessible
tree.  This is located on the Mozilla Wiki at
https://wiki.mozilla.org/Accessibility/MathML.
The basic idea is to add an interface for the MathML elements that ATs
can use.  There will also be a corresponding interface for MathML
tables, similar to the existing interface for HTML tables.  A number of
new roles and relations will be used to denote the type of MathML
element as well as relationships between the parent element and its
child components.

Any comments or feedback on this proposed interface would be great.

Thanks,
Jon
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MathML Accessibility in Gecko

Trevor Saunders
On Wed, Mar 26, 2014 at 05:01:36PM -0400, Jonathan Wei wrote:
> Hi,
>
> Based on the comments posted on
> https://bugzilla.mozilla.org/show_bug.cgi?id=916419, I've drawn up a fairly
> rough interface to expose MathML constructs as an accessible tree.  This is
> located on the Mozilla Wiki at
> https://wiki.mozilla.org/Accessibility/MathML.
> The basic idea is to add an interface for the MathML elements that ATs can

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 == mathml, and if people want to expose
equations accessibly but don't start with mathml they'll have to fake it
somehow.

> use.  There will also be a corresponding interface for MathML tables,
> similar to the existing interface for HTML tables.  A number of new roles

Why do we need this? it seems like its the same exact interface as
nsIAccessibleTable with some stuff removed.

> and relations will be used to denote the type of MathML element as well as
> relationships between the parent element and its child components.

More roles seem fine, and relations might be good but I think your wiki
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?

> Any comments or feedback on this proposed interface would be great.

Sorry about the delay!

Trev

>
> Thanks,
> Jon
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MathML Accessibility in Gecko

Jonathan Wei
In reply to this post by Jonathan Wei
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 == 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 glyph.

> 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 added 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 wiki
>
> 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 relations aren't really needed, since MathML rigidly defines which child must represent 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 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=916419#c23).  I guess we could just have the backwards (e.g. numerator to fraction) relationships, 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MathML Accessibility in Gecko

Alexander Surkov
MathML token or MathML glyph could be exposed as object attributes I guess
if necessary.

I agree It's good idea if AccessibleTable interface is reused for MathML
tables. However if it's good to show the difference between tables if
exists.

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.


On Tue, Apr 1, 2014 at 4:38 PM, Jonathan Wei <[hidden email]> wrote:

> 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 == 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 glyph.
>
> > 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 added 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 wiki
> >
> > 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 relations
> aren't really needed, since MathML rigidly defines which child must
> represent 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 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=916419#c23).  I guess we
> could just have the backwards (e.g. numerator to fraction) relationships,
> 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility
>
_______________________________________________
dev-accessibility mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-accessibility
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MathML Accessibility in Gecko

Trevor Saunders
In reply to this post by Jonathan Wei
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:
>
> > 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 == 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.
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 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.

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 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 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
> >
> > 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 added 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.

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
> >
> > 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 relations aren't really needed, since MathML rigidly defines which child must represent 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 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=916419#c23).  I guess we could just have the backwards (e.g. numerator to fraction) relationships, but it seems unbalanced.  Maybe that 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 relationships going forwards and backwards to be able to give useful information 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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

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

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: MathML Accessibility in Gecko

Trevor Saunders
In reply to this post by Alexander Surkov
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

>
>
> On Tue, Apr 1, 2014 at 4:38 PM, Jonathan Wei <[hidden email]> wrote:
>
> > 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 == 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 glyph.
> >
> > > 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 added 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 wiki
> > >
> > > 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 relations
> > aren't really needed, since MathML rigidly defines which child must
> > represent 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 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=916419#c23).  I guess we
> > could just have the backwards (e.g. numerator to fraction) relationships,
> > 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
> > [hidden email]
> > https://lists.mozilla.org/listinfo/dev-accessibility
> >
> _______________________________________________
> dev-accessibility mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-accessibility

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

signature.asc (836 bytes) Download Attachment
Loading...