RESOLVED FIXED 139017
AX: [ATK] Meter and Option elements do not expose their id attribute
https://bugs.webkit.org/show_bug.cgi?id=139017
Summary AX: [ATK] Meter and Option elements do not expose their id attribute
Joanmarie Diggs
Reported 2014-11-23 13:18:11 PST
The meter and option elements are not exposing their id attribute via ATK object attributes. In the case of meter, it's because the RenderMeter is being exposed and the Meter element (which has the id attribute) is not. I've not yet dug into the option issue. Having said that, this is not an accessibility issue as much as it is a testing issue, with roles-exposed.html. The expected accessible objects are still exposed via ATK and still accessible via AT-SPI2. But because the roles-expected.html test relies upon matching the id attribute, the meter and option tests fail for our platform.
Attachments
Patch (8.10 KB, patch)
2014-11-24 15:00 PST, Joanmarie Diggs
no flags
Patch (8.23 KB, patch)
2014-11-24 17:33 PST, Joanmarie Diggs
no flags
Patch (8.19 KB, patch)
2014-11-27 06:23 PST, Joanmarie Diggs
no flags
Radar WebKit Bug Importer
Comment 1 2014-11-23 13:18:30 PST
Joanmarie Diggs
Comment 2 2014-11-24 15:00:36 PST
chris fleizach
Comment 3 2014-11-24 15:19:45 PST
Comment on attachment 242175 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=242175&action=review Looks ok with minor modification > Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:506 > Node* node = coreObject->node(); I believe there's an element() method on ax object you can use directly
Joanmarie Diggs
Comment 4 2014-11-24 16:15:08 PST
(In reply to comment #3) > Comment on attachment 242175 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=242175&action=review > > Looks ok with minor modification > > > Source/WebCore/accessibility/atk/WebKitAccessibleWrapperAtk.cpp:506 > > Node* node = coreObject->node(); > > I believe there's an element() method on ax object you can use directly Indeed there is. Missed that. Thanks! Thinking more about it, there's not an "action" associated with a meter or progress element.... Is there any reason why AccessibilityProgressIndicator should not override element()?
Joanmarie Diggs
Comment 5 2014-11-24 17:33:34 PST
Mario Sanchez Prada
Comment 6 2014-11-27 06:10:46 PST
Comment on attachment 242184 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=242184&action=review > Source/WebCore/accessibility/AccessibilityProgressIndicator.cpp:151 > + return nullptr; Shouldn't you fallback to AccessibilityObject::element() instead of just returning nullptr?
Joanmarie Diggs
Comment 7 2014-11-27 06:23:25 PST
Joanmarie Diggs
Comment 8 2014-11-27 07:38:25 PST
Comment on attachment 242252 [details] Patch (In reply to comment #6) > Comment on attachment 242184 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=242184&action=review > > > Source/WebCore/accessibility/AccessibilityProgressIndicator.cpp:151 > > + return nullptr; > > Shouldn't you fallback to AccessibilityObject::element() instead of just > returning nullptr? Done. Thanks!
Mario Sanchez Prada
Comment 9 2014-11-27 14:07:43 PST
Comment on attachment 242252 [details] Patch It seems to me that the EFL failure is completely unrelated
WebKit Commit Bot
Comment 10 2014-11-27 16:24:28 PST
Comment on attachment 242252 [details] Patch Clearing flags on attachment: 242252 Committed r176552: <http://trac.webkit.org/changeset/176552>
WebKit Commit Bot
Comment 11 2014-11-27 16:24:32 PST
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.