- From: Steve Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 11 Jun 2012 09:57:55 +0100
- To: "Davide P. Cervone" <dpvc@union.edu>
- Cc: Cameron McCormack <cam@mcc.id.au>, Dirk Schulze <dschulze@adobe.com>, Vincent Hardy <vhardy@adobe.com>, W3C WAI-XTECH <wai-xtech@w3.org>, Peter Krautzberger <p.krautzberger@googlemail.com>
- Message-ID: <CA+ri+V=5HO9uOC6jgJsRT8DtyGE9DE0YmweZ+OqWTFOJcUyOzw@mail.gmail.com>
Hi Davide, you wrote: "Certainly MathJax could be made to produce the content of the <details> tag that you have specified." The inportant point being that MathJax could produce the content, the way in which it is displayed/structured on the page could be left up to the developer to implement as appropriate. you wrote: "I do have a couple of concerns about your suggestion. I'm not sure <figure> is the right tag for this, since the documentation at http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element ... I'm not sure that most displayed equations satisfy the condition that they could be removed (or moved to an appendix) without affecting the flow of the document." How it is specified *currently* is not of any practical affect, it is more useful; to look at how the semantics are implemented in browsers. For example, Firefox implements the <figure> element with a 'group' role [1] [2] and <figcaption> as IA2 caption role [3]. there is nothing in the semantics of these roles that implies the rather unwieldy semantics as you descibed. you wrote: "Also this would only work for displayed equations, so would not be an appropriate form for in-line equations. You are probably not worried about in-line math, but I need to be concerned about both forms. " I agree, the example I provided was for an non -inline equation. you wrote: "As for the <details> issue, my understanding is that <details> isn't implemented in all browsers yet, so I guess you are planning to use a javascript helper script to handle that. " Yes, you can see an example of this in action in the HTML to Platform Accessibility APIs Implementation Guide [4]. As used it provided the behaviour via scripting, and semanticsvia ARIA. "One thing I don't understand, however, is how this will prevent screen readers from trying to read the MathML itself (or MathJax's HTML rendering of it) in addition to reading both the prose version of the math in the <summary> in addition to the MathJax-generated text intended for the screen readers." It won't: scenarios: 1. non AT User who can read the equation and understand its meaning doesn't need the prose version. 2. non AT User who cannot read the equation and understand its meaning needs the prose version. 3 AT user who can read the equation using their AT/browser combination and understand its meaning, doesn't need the prose version. 4. AT user who could read the equation and understand its meaning but their AT/browser combination does not provide access to the meaning, needs the prose version. 4. AT User who cannot read the equation and understand its meaning needs the prose version. there are most probably others, but in all scenarios without querying the user it is not possible to know what the user requires, so providing both with the prose version available via the user clicking a button, seems like a reasonable solution. you wrote: "Finally, it seems to me that a screen reader should NOT read the contents of the <details> tag other than the <summary> when it is closed, and would read the contents only when it is opened, so this doesn't seem to me to be the right way to get a version to AT software. " Why not, we are not talking about all AT users, we are talking about a subset, anyway a solution woul be to provide the facility to expand all details sections at once. Ane example of this (exapnd/collapse buttons) is available at [4] you wrote: "Although screen readers don't currently handle <details> that way, I expect that in the future they will, and I wouldn't want your documents to break at that point." some browsers (chrome/webkit) have implemented the behaviour but not the semantics or keyboard support [5]. It is only worthwhile and appropriate to use details/summary if it works for all users as expected, so the semantics and beahviour have to be added for cross user agent support. regards SteveF [1] http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#el-44 [2] https://developer.mozilla.org/en/Accessibility/AT-APIs/Gecko/Roles/ROLE_GROUPING [3] https://developer.mozilla.org/en/Accessibility/AT-APIs/IA2/Roles [4] http://dvcs.w3.org/hg/html-api-map/raw-file/tip/Overview.html#api-role [5] http://www.html5accessibility.com/ On 10 June 2012 21:04, Davide P. Cervone <dpvc@union.edu> wrote: > Thanks for the additional information. Certainly MathJax could be made to > produce the content of the <details> tag that you have specified. > > But I do have a couple of concerns about your suggestion. I'm not sure > <figure> is the right tag for this, since the documentation at > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-figure-element > > suggests that "The element can thus be used to annotate illustrations, > diagrams, photos, code listings, etc, that are referred to from the main > content of the document, but that could, without affecting the flow of the > document, be moved away from that primary content, e.g. to the side of the > page, to dedicated pages, or to an appendix." I'm not sure that most > displayed equations satisfy the condition that they could be removed (or > moved to an appendix) without affecting the flow of the document. > > Also this would only work for displayed equations, so would not be an > appropriate form for in-line equations. You are probably not worried about > in-line math, but I need to be concerned about both forms. > > As for the <details> issue, my understanding is that <details> isn't > implemented in all browsers yet, so I guess you are planning to use a > javascript helper script to handle that. One thing I don't understand, > however, is how this will prevent screen readers from trying to read the > MathML itself (or MathJax's HTML rendering of it) in addition to reading > both the prose version of the math in the <summary> in addition to the > MathJax-generated text intended for the screen readers. Finally, it seems > to me that a screen reader should NOT read the contents of the <details> > tag other than the <summary> when it is closed, and would read the contents > only when it is opened, so this doesn't seem to me to be the right way to > get a version to AT software. Although screen readers don't currently > handle <details> that way, I expect that in the future they will, and I > wouldn't want your documents to break at that point. > > Just my two cent's worth. > > Davide > > > On Jun 6, 2012, at 8:18 AM, Steve Faulkner wrote: > > Hi Davide, > I usually test with JAWS/Orca/NVDA/VoiceOver. > > I am unsure about the suitability of aria relationship attributes in this > case as I mentioned in my reply to Cameron. > I am looking at methods to provide the prose form of the equations, I > think it is something that should be available to all users, but not > displayed by default. > I am considereing the use of the HTML5 figure element for the math > container and the details element to provide a container for the prose > form, will provide more details later, but this is an example: > > <figure> > <figcaption>caption for math</figcaption> > <math> > <mrow> > <mi>x</mi> > <mo>=</mo> > <mfrac> > <mrow> > <mo>-</mo> > <mi>b</mi> > <mo>±</mo> > <msqrt> > <mrow> > <msup> > <mi>b</mi> > <mn>2</mn> > </msup> > <mo>-</mo> > <mn>4</mn> > <mi>a</mi> > <mi>c</mi> > </mrow> > </msqrt> > </mrow> > <mrow> > <mn>2</mn> > <mi>a</mi> > </mrow> > </mfrac> > </mrow> > </math> > > <details><summary>prose version of math</summary> > <p>(dummy text -hopefully content can be dynamically supplied via MathJax) > square root of, 1 + square root of, 1 minus x cubed, end root, end root</p? > </details> > </figure> > > If you are unfamiliar with the details element you can see how it works > here: http://mathiasbynens.be/demo/html5-details-jquery > > > regards > steve > > On 5 June 2012 20:31, Davide P. Cervone <dpvc@union.edu> wrote: > >> Steve: >> >> Can you say what readers you have experimented with? I have used JAWS, >> Read&Write Gold, and Apple's VoiceOver. VoiceOver has pretty good support >> for ARIA tags, JAWS seems to have some, an R&WG seems to ignore them >> entirely. This is part of the reason for my original claim that screen >> readers vary widely in their implementation of the standards. It is also >> part of the reason that it will be difficult to have a single static >> solution that works for all users, and why dynamic production of the markup >> by something like MathJax may be the best alternative in the short term >> (until there is better uniformity among AT software). >> >> Davide >> >> >> On May 30, 2012, at 2:21 AM, Steve Faulkner wrote: >> >> Hi Cameron, >> >> There is MathSpeak http://www.gh-mathspeak.com/examples/grammar-rules/ >> >> >> in regards to adding ARIA to MathML, from limited testing I have >> conducted it does not work currently. >> I am guessing you are talking about adding it to the <math> element? >> >> >> regards >> Steve >> >> On 30 May 2012 01:48, Cameron McCormack <cam@mcc.id.au> wrote: >> >>> Hi Steve, >>> >>> Do you know of any standards for the reading of math as a linear stream >>> of words? In the meantime, before Peter's MathJax extension is ready, I >>> would like to just add some aria-label="" attributes manually to the MathML >>> in the SVG spec. I could take a guess at what is an appropriate reading >>> for the formulae, but if there's a standard or guide for producing this I'd >>> like to follow it. >>> >>> Thanks, >>> >>> Cameron >>> >> >> >> >> >> > > > -- > with regards > > Steve Faulkner > Technical Director - TPG > > www.paciellogroup.com | www.HTML5accessibility.com | > www.twitter.com/stevefaulkner > HTML5: Techniques for providing useful text alternatives - > dev.w3.org/html5/alt-techniques/ > Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html > > > > -- with regards Steve Faulkner Technical Director - TPG www.paciellogroup.com | www.HTML5accessibility.com | www.twitter.com/stevefaulkner HTML5: Techniques for providing useful text alternatives - dev.w3.org/html5/alt-techniques/ Web Accessibility Toolbar - www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 11 June 2012 08:59:07 UTC