[Webkit-unassigned] [Bug 128420] AX: [GTK] Implement computedRoleString in AccessibilityUIElement

[bugzilla-daemon at webkit.org]

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





--- Comment #6 from Diego Pino <dpino at igalia.com>  2014-03-19 06:03:31 PST ---
(In reply to comment #5)

> So, IMHO, this function should either remain unimplemented in ATK based ports or it should be implemented, as an exception, by breaking the encapsulation and getting the information directly from the wrapped WebCore::AccessibilityObject.

Thanks for the long explanation, now everything is much clearer.

So, it seems there's no good solution for this. I don't like the solution of breaking encapsulation either. 

Now the inspector includes an Accessibility tab (in the Node panel) that helps examining the aria information of a DOM element (for instance it prints out aria related information of a node (role, aria-required, aria-ignored, aria-checked, etc)). Without computedRoleString implemented it prints out "No exact ARIA role match". How much valuable is that information, I don't know. Is it worth to break encapsulation to get the role printed? And even in that case, it would be the Mac role, as you explained, which maybe useless for GTK.

In case of breaking encapsulation and relying on the computedRoleString function of WebCore I would append a label in the GTK port stating that the role is the role of MAC. Something like "Role: [MAC] link", for instance.

On the other hand, I think it would be good to differentiate the case of "No exact ARIA role match" from the case of not computing the role string. When the role is the empty string or "unknown" the inspector prints "No exact ARIA role match". I would print a "Not supported" string if computedRoleString returns is not implemented (it would simply return the empty string in that case). But that may be another bug.

--- Comment #7 from Mario Sanchez Prada <mario at webkit.org>  2014-03-26 04:05:17 PST ---
(In reply to comment #6)
> (In reply to comment #5)
> 
> > So, IMHO, this function should either remain unimplemented in ATK based ports or it should be implemented, as an exception, by breaking the encapsulation and getting the information directly from the wrapped WebCore::AccessibilityObject.
> 
> Thanks for the long explanation, now everything is much clearer.
> 

You're welcome

> So, it seems there's no good solution for this. I don't like the solution of breaking encapsulation either. 
> 
> Now the inspector includes an Accessibility tab (in the Node panel) that 
> helps examining the aria information of a DOM element (for instance it prints 
> out aria related information of a node (role, aria-required, aria-ignored, 
> aria-checked, etc)). Without computedRoleString implemented it prints out "No 
> exact ARIA role match". How much valuable is that information, I don't know. 
> Is it worth to break encapsulation to get the role printed? And even in that 
> case, it would be the Mac role, as you explained, which maybe useless for 
> GTK.
> 
Exactly. I'm not sure either about how useful that would be for GTK other than for easily inspecting the accessibility role given by WebCore to the a11y object wrapping a given element in the DOM. I guess this specific use case might be useful for debugging purposes: with Accerciser you could see the ATK role, but with the inspector you could see the WebCore accessibility role, which might be useful sometimes when you don't want to use gdb/printfs just to know the role that is being mapped.

But the thing is that, if the only interesting use case is this one (debugging purposes in ATK platforms), then it would probably be better to just give up on trying to match the computed role strings that are output in the Mac platform and just print the associated role names for the AtkRole of the object exposed.

In other words, just call atk_role_get_name(role) in WKTR's computeRoleString() and return either the output of it (when not null) or a hardcoded string saying "Not supported", "No exact role match" or the like.

Of course, you would need to add platform specific expectations for that test, but I think this would be cleaner than the previous approach, and maybe useful for debugging purposes as well (it would avoid devs to have to open Accerciser just to know the ATK role of an element)

> In case of breaking encapsulation and relying on the computedRoleString 
> function of WebCore I would append a label in the GTK port stating that the 
> role is the role of MAC. Something like "Role: [MAC] link", for instance.
> 
Honestly, I would not append anything and would just have the WebCore role showing up there, if any. But I finally don't think breaking encapsulation is worth it. If any, I would go for printing the name of the AtkRole and providing platform specific expectations (see above).

> On the other hand, I think it would be good to differentiate the case of "No
> exact ARIA role match" from the case of not computing the role string. When 
> the role is the empty string or "unknown" the inspector prints "No exact ARIA 
> role match". I would print a "Not supported" string if computedRoleString 
> returns is not implemented (it would simply return the empty string in that 
> case). But that may be another bug.

That's a good idea, but I think it could be integrated in this patch without much trouble, tbh.

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