This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
This is a comment/bug report on [1]. Section 3 (HTML element to Accessibility API Role Mapping Matrix) contains a mapping of elements to accessibility roles. I see that both math and svg are missing from that "matrix". I don't know enough to suggest mappings for svg, but for math, the following entries are appropriate: HTML 4: no HTML 5: yes WAI-ARIA: math role MSAA: ROLE_SYSTEM_EQUATION I don't have direct knowledge of the other values, but most are found in section 5.4.1 in [2]. The children of the math element (eg, mrow, mfrac) should NOT be exposed to AT. Note that [3] mentions that for legacy content that use images for math, using role=math is appropriate. The alt should be TeX or MathML and the aria-describedby should be used to describe the math. I think this should be mentioned as part of the description of the img element mapping (section 5.6?) Neil Soiffer [speaking for myself -- I have not run this by the MathML WG] [1] http://www.w3.org/TR/2012/WD-html-aapi-20120329 [2] http://www.w3.org/WAI/PF/aria-implementation [3] http://www.w3.org/TR/wai-aria/roles#math
(In reply to comment #0) > This is a comment/bug report on [1]. > > Section 3 (HTML element to Accessibility API Role Mapping Matrix) contains a > mapping of elements to accessibility roles. I see that both math and svg are > missing from that "matrix". I don't know enough to suggest mappings for svg, > but for math, the following entries are appropriate: > > HTML 4: no > HTML 5: yes > WAI-ARIA: math role > MSAA: ROLE_SYSTEM_EQUATION > > I don't have direct knowledge of the other values, but most are found in > section 5.4.1 in [2]. The children of the math element (eg, mrow, mfrac) > should NOT be exposed to AT. Say I were extending an accessibility client to render mathematical notations to speech or nemeth. If the accessibility tree does not include a representation of the mathematical content, how would that transformation work? Is your recommendation that user agents should hand over access to the DOM using a specific interface that is *not* part of the the platform accessibility APIs? If so, can we spell out what that specific interface could be? What's the progress on representing mathematical content directly in all platform accessibility APIs? Is anyone working on that or is that dead in the water?
(In reply to comment #1) > > I don't have direct knowledge of the other values, but most are found in > > section 5.4.1 in [2]. The children of the math element (eg, mrow, mfrac) > > should NOT be exposed to AT. > > Say I were extending an accessibility client to render mathematical notations > to speech or nemeth. If the accessibility tree does not include a > representation of the mathematical content, how would that transformation work? > Is your recommendation that user agents should hand over access to the DOM > using a specific interface that is *not* part of the the platform accessibility > APIs? If so, can we spell out what that specific interface could be? When I wrote my comment about the children not being exposed, I was indeed thinking about the model where AT says to a third party app -- "you figure this out". In that case, you don't want AT plowing into the children. However, since the AT has a pointer to the accessibility tree, the obvious thing is to hand over a pointer to that tree and the helper app either can get a pointer back to the full DOM or the accessibility tree needs to expose the children of the math element. I'm willing to concede that my suggestion of the children not being part of the accessibility tree is potentially bad and withdraw it. > > What's the progress on representing mathematical content directly in all > platform accessibility APIs? Is anyone working on that or is that dead in the > water? My company has for years made math accessible in IE. We are working on a plan for math accessibility (mathml->speech text, sync highlighting, navigation, and math braille codes) that will work in all browsers. I discussed some options with several AT vendors at CSUN 2012 (give us a pointer to the node and the "type" of the tree/DOM), or give us the MathML string, or ...) and they were generally favorable pending seeing the details. I'm hopeful we'll have something working with at least one vendor by mid-summer as part of a grant we are jointly working on.
math and svg have been added to [1]. All but UIA mapping provided for math. Mappings for svg still required. Calling this fixed as elements now present in mapping matrix. Establishing final mappings and details is ongoing.
That is, math and svg have been added to http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html