[Webkit-unassigned] [Bug 114354] [EFL][GTK] Adds an accessibility support to access a value of the color control element

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=114354





--- Comment #4 from Mario Sanchez Prada <mario at webkit.org>  2013-04-15 08:21:34 PST ---
(In reply to comment #3)
> (In reply to comment #2)
> > I think it would be more accurate to implement AtkValue interface [1] for this kind of input elements, instead of partly implementing AtkText, which seems a bit "forced" to me in this case.
> > 
> > API, joanie... what do you think?
> > 
> > [1] https://developer.gnome.org/atk/unstable/AtkValue.html
> 
> While AtkValue's docs suggest the Value can be whatever, AT-SPI2 seems to 
> expect [2] -- and provide [3] -- a double. So I would either go with AtkText
> or I would change the bridge and the AT-SPI2 API to accommodate string values
> first.

Ah, I see the problem now. However I'm still not convinced whether to expose it through AtkText will be the right thing to do because it will create more questions in my mind related to the implementation of other functions in AtkText (e.g. those related to the position of the caret).

I'm not saying I'm against this change, after all I will basically trust you Joanie way more than myself when it comes to define requirements for ATs, just trying to see the pros and the cons of each solution.

> As for whether or not it is "forced" to go with AtkText, with AtkValue [1]
> you also need to provide a minimum, a maximum, and increments. What will
> those be here? (For me, AtkValue is the more "forced" of the two.)

Yes, I already thought about that and there was no easy answer for those cases either, other than the obvious "let's use 0 as minimum, 2^64 as maximum and 1.0 as increment" :-)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.