Support for MathML links was added in bug 85733. After the MathML article on the Safari blog we got feedback about accessibility of MathML links (see the demo https://webkit.org/demos/mathml/demo2016/#hyperlinks). I'm not sure exactly what is required, but it seems that we should somewhat expose the MathML links to the accessibility tree so that ATs can understand it.
Created attachment 286711 [details] WIP Patch This is an experimental patch adding role Link to MathML elements with a href attribute.
<rdar://problem/27983220>
Comment on attachment 286711 [details] WIP Patch View in context: https://bugs.webkit.org/attachment.cgi?id=286711&action=review > Source/WebCore/accessibility/AccessibilityMathMLElement.cpp:62 > + if (node && node->isLink()) I don't know if we want to change the math role away from what it is to a link. if you put the href on a <mfrac> then that might mess up the math tree that's created it seems like either we should a) expand the concept of roles so that an object can have more than one role b) make being a link an attribute as well as a role (probably the easiest path) c) make a fake element representing the link that becomes the parent of the object
(In reply to comment #3) > Comment on attachment 286711 [details] > WIP Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=286711&action=review > > > Source/WebCore/accessibility/AccessibilityMathMLElement.cpp:62 > > + if (node && node->isLink()) > > I don't know if we want to change the math role away from what it is to a > link. > if you put the href on a <mfrac> then that might mess up the math tree > that's created (In reply to comment #3) > I don't know if we want to change the math role away from what it is to a > link. > if you put the href on a <mfrac> then that might mess up the math tree > that's created We definitely do not want to have the role overridden (although that's maybe not too much a trouble if href is only used on mrow). That's why I did not ask review for this patch ;-) > it seems like either we should > a) expand the concept of roles so that an object can have more than one role > b) make being a link an attribute as well as a role (probably the easiest > path) > c) make a fake element representing the link that becomes the parent of the > object I believe we should get feedback from AT developers but my guess would be that on their side: c) won't need any effort , b) will need a minor effort and a) will be more complex. Actually I'm curious about c), since that might help to remove anonymous nodes for mfenced if we decide to rewrite its renderer class (bug 160509).
(In reply to comment #4) > (In reply to comment #3) > > Comment on attachment 286711 [details] > > WIP Patch > > > > View in context: > > https://bugs.webkit.org/attachment.cgi?id=286711&action=review > > > > > Source/WebCore/accessibility/AccessibilityMathMLElement.cpp:62 > > > + if (node && node->isLink()) > > > > I don't know if we want to change the math role away from what it is to a > > link. > > if you put the href on a <mfrac> then that might mess up the math tree > > that's created > > (In reply to comment #3) > > I don't know if we want to change the math role away from what it is to a > > link. > > if you put the href on a <mfrac> then that might mess up the math tree > > that's created > > We definitely do not want to have the role overridden (although that's maybe > not too much a trouble if href is only used on mrow). That's why I did not > ask review for this patch ;-) > > > it seems like either we should > > a) expand the concept of roles so that an object can have more than one role > > b) make being a link an attribute as well as a role (probably the easiest > > path) > > c) make a fake element representing the link that becomes the parent of the > > object > > I believe we should get feedback from AT developers but my guess would be > that on their side: c) won't need any effort , b) will need a minor effort > and a) will be more complex. > > Actually I'm curious about c), since that might help to remove anonymous > nodes for mfenced if we decide to rewrite its renderer class (bug 160509). i’m concerned C) might have adverse affects too. if you put this on a node within a math term, it might also change the expected hierarchy and break something. i think b) might be the easiest although we’ll need to change ATs for mac. iOS should be able to easily adopt this since a link is already an attribute
Comment on attachment 286711 [details] WIP Patch Attachment 286711 [details] did not pass mac-ews (mac): Output: http://webkit-queues.webkit.org/results/1934903 New failing tests: accessibility/math-links.html
Created attachment 286858 [details] Archive of layout-test-results from ews103 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-ews. Bot: ews103 Port: mac-yosemite Platform: Mac OS X 10.10.5
Comment on attachment 286711 [details] WIP Patch Attachment 286711 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.webkit.org/results/1934911 New failing tests: accessibility/math-links.html
Created attachment 286859 [details] Archive of layout-test-results from ews105 for mac-yosemite-wk2 The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews. Bot: ews105 Port: mac-yosemite-wk2 Platform: Mac OS X 10.10.5
Comment on attachment 286711 [details] WIP Patch Attachment 286711 [details] did not pass mac-debug-ews (mac): Output: http://webkit-queues.webkit.org/results/1934923 New failing tests: accessibility/math-links.html
Created attachment 286860 [details] Archive of layout-test-results from ews117 for mac-yosemite The attached test failures were seen while running run-webkit-tests on the mac-debug-ews. Bot: ews117 Port: mac-yosemite Platform: Mac OS X 10.10.5