There are some elements that are not showing up properly in the ATK hierarchy, so we need to investigate why and fix those that should actually show up: * <canvas>X</canvas> * <cite>X</cite> * <code>X</code> * <img> * <img alt=""> * <img src="foo.png"> * <div role="rowgroup"> * <div role="group">
Some more: * <audio> * <video>
And more: * <tr> * <meter> * <option> * <svg>
<rdar://problem/15710134>
In some of the cases below, I think it's correct that they are not showing up. Example: <img alt=""> In some of the cases below, it depends on the actual contents. For instance, given a proper audio or video element complete with stuff in it (as opposed to the roles-exposed test), the elements do show up properly in the ATK hierarchy. We already have tests for that (which illustrate their showing up). In some of the cases below, the issue seems to be a combination of how the roles-exposed test works and differing hierarchies between the Mac and ATK. For example, given a meter element: Mac hierarchy: -> AXGroup (This is the media element, and the thing with the id attr) -> AXProgressIndicator (This is the RenderMeter, has the value stuff) The ATK hierarchy is just: -> AXProgressIndicator (This is the RenderMeter, has the value stuff) So in ATK we are exposing the bit the user cares about. But the fact that the we're not also exposing the element (AXGroup == ATK_ROLE_PANEL) means that the roles-exposed test fails because the way it finds elements is by id. I'm honestly not sure what to do about the meter-like failures: From an actual accessibility point of view, we're exposing the correct stuff. Should we expose the element/panel just to make the ID-dependent tests pass? Adding extra stuff in the hierarchy consumed by ATs to accommodate our test harness seems like a bad idea. Should we fold all the RenderMeter stuff into the parent element and then expose the parent element instead of the RenderMeter? That seems like a way to accommodate the test harness without impacting the ATs and user experience, but that seems like more work than should be needed. Should we add some sort of hack to the html-id object attribute? That's also a sad solution, but seems like the easiest. BUT, when an element with an id attribute is ignored, it could be that it's exposed through the parent (in the case of text), but it could be that it's exposed through the child (in the case of the meter). So all options seem pretty sucktastic to me. Suggestions?
(In reply to comment #4) > [...] So all options seem pretty sucktastic to me. Suggestions? What about splitting those cases that are too Mac/ATK specific into separate platform-specific testcases? The downside of that approach is that is harder to maintain than a cross-platform test, but perhaps that's the least bad option in this sucktastic scenario...
(In reply to comment #0) > There are some elements that are not showing up properly in the ATK > hierarchy, so we need to investigate why and fix those that should actually > show up: > > * <canvas>X</canvas> Results are the same as on the Mac. If there is no fallback element, neither platform expose it. If there is a fallback element, both platforms expose it. We should add a new test case to roles-exposed.html. But this is not an ATK issue. > * <cite>X</cite> > * <code>X</code> Results are the same as on the Mac insofar as the roles-exposed.html test is concerned. It's the same as with tags like i and b. Thus not an ATK issue. > * <img> > * <img alt=""> > * <img src="foo.png"> Results are the same as on the Mac. It's just another flavor of canvas without fallback: Useless images are not exposed on either platform. Thus not an ATK issue. > * <div role="rowgroup"> Results are the same as on the Mac, at least as far as the roles-exposed.html test is concerned. Thus not an ATK issue. > * <div role="group"> Interestingly enough, the Mac isn't exposing this -- at least according to the expectations of roles-exposed.html. My guess (I've not dug into it) is that on the Mac, there is an AXGroup being exposed, but it's associated with a RenderObject child of the actual element. As a result, the thing which contains the ID attribute is not in the tree, but there's an object with the same role that is serving the same purpose. Thus the test results suggest it's not exposed, when functionally it is exposed. <insert shrug here> Regardless, ATK is actually exposing that actual element. So it's not only not an ATK issue, it's also not a case of it not showing up in the ATK hierarchy. (In reply to comment #1) > Some more: > > * <audio> Regarding the roles-exposed.html test, our results are the same as on the Mac. This is another flavor of the canvas one. If you add a controls attribute to the audio element, then both the Mac and ATK have it in their hierarchy. We should add this condition to roles-exposed.html, but it's not an ATK issue. > * <video> Not even in roles-exposed.html. But when I added it, both the Mac and ATK expose it as expected if it has a controls attribute. Unlike the audio element, both the Mac and ATK expose video even if it doesn't have the controls element. But, again, this is not an ATK issue and video elements do show up in the ATK hierarchy. (In reply to comment #2) > And more: > > * <tr> And <caption> which, for some reason, was marked as "not to be exposed." Which is wrong. Captions should be exposed. Filed as bug 139005. > * <meter> > * <option> As I mentioned in comment 4, this is indeed an ATK thing, but a testing one; not an accessibility one. The objects show up.... I just opened bug 139017 for it. > * <svg> Same results as on the Mac. Not dug into it yet, but my guess is that it's like the useless images and canvas without fallback. Not an ATK issue. Finally, what going through all of these things (and more) has taught me is: We really need to stop skipping stuff for ATK. :) That's bug 139016. I'll make this bug a dup of that one because that covers what you reported in the opening report. *** This bug has been marked as a duplicate of bug 139016 ***