AX: [ATK] Meter and Option elements do not expose their id attribute

• Component: Accessibility
• Status: RESOLVED FIXED

[Joanmarie Diggs]

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.

[Radar WebKit Bug Importer]

<rdar://problem/19069949>

[Joanmarie Diggs]

Created attachment 242175 [details]
Patch

[chris fleizach]

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]

(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]

Created attachment 242184 [details]
Patch

[Mario Sanchez Prada]

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]

Created attachment 242252 [details]
Patch

[Joanmarie Diggs]

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 on attachment 242252 [details]
Patch

It seems to me that the EFL failure is completely unrelated

[WebKit Commit Bot]

Comment on attachment 242252 [details]
Patch

Clearing flags on attachment: 242252

Committed r176552: <http://trac.webkit.org/changeset/176552>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.