[ATK] Expose aria-valuetext as an object attribute.

• Component: Accessibility
• Status: UNCONFIRMED ---

[Krzysztof Czech]

Based on http://www.w3.org/TR/wai-aria-implementation/, aria-valuetext should be exposed  as an object attribute.

[Radar WebKit Bug Importer]

<rdar://problem/15007710>

[Krzysztof Czech]

Created attachment 211879 [details]
Patch

[Joanmarie Diggs]

(In reply to comment #0)
> Based on http://www.w3.org/TR/wai-aria-implementation/, aria-valuetext should be exposed  as an object attribute.

Right now, exposing the text which describes an AtkValue's value as an object attribute is not wrong per se; instead, it's a hack to deal with a current lack of API in ATK/AT-SPI2 to expose it properly. See https://bugzilla.gnome.org/show_bug.cgi?id=684576

I have just commented on that bug. If we get the correct API in place, will you please use that instead?

[Krzysztof Czech]

> Right now, exposing the text which describes an AtkValue's value as an object attribute is not wrong per se; instead, it's a hack to deal with a current lack of API in ATK/AT-SPI2 to expose it properly. See https://bugzilla.gnome.org/show_bug.cgi?id=684576
I already noticed that bug, I hope it'll be resolved soon.
> 
> I have just commented on that bug. If we get the correct API in place, will you please use that instead?
Yes sure, as soon as we get the correct ATK API, I will use it instead.

Thank you for your review.

[Krzysztof Czech]

Created attachment 211885 [details]
Patch

[Krzysztof Czech]

(In reply to comment #5)
> Created an attachment (id=211885) [details]
> Patch

Corrected tests' description

[Mario Sanchez Prada]

Comment on attachment 211885 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=211885&action=review

(In reply to comment #4)
> [...]
> > I have just commented on that bug. If we get the correct API in place, will you please use that instead?
> Yes sure, as soon as we get the correct ATK API, I will use it instead.
> 
I've just reviewed the patch and, besides the things I pointed out below, I think the implementation in the wrapper is ok if we compare it to what W3C says now. However, I agree with joanie that we will need to re-do this anyway in terms of the new API in AtkValue as soon as it gets there, but for the time being I'd personally go with this.

Do you agree, Joanie?

Btw, giving r- because of the thing about sharing the tests and the missing implementation for DRT

> LayoutTests/ChangeLog:17
> +        * platform/efl/accessibility/aria-valuetext-expected.txt: Added.
> +        * platform/efl/accessibility/aria-valuetext-on-native-slider-expected.txt: Added.
> +        * platform/efl/accessibility/aria-valuetext-on-native-slider.html: Added.
> +        * platform/efl/accessibility/aria-valuetext.html: Added.
> +        * platform/gtk/accessibility/aria-valuetext-expected.txt: Added.
> +        * platform/gtk/accessibility/aria-valuetext-on-native-slider-expected.txt: Added.
> +        * platform/gtk/accessibility/aria-valuetext-on-native-slider.html: Added.
> +        * platform/gtk/accessibility/aria-valuetext.html: Added.

It looks to me like these 2 tests could be shared as cross-platform ones. Why not reusing the ones from the mac by moving them and adapting DRT & WKTR to provide the same output?

> Tools/WebKitTestRunner/InjectedBundle/atk/AccessibilityUIElementAtk.cpp:808
> +    String attributeValue = getAttributeSetValueForId(ATK_OBJECT(m_element.get()), "valuetext");

Here it might be a good place to prepend the "AXValueDescription: " string, so we can share the tests.

Btw, I don't see the change for DRT in this patch