[Webkit-unassigned] [Bug 139581] AX: [ATK] Use ATK_RELATION_MEMBER_OF to implement linkedUIElements.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Wed Dec 17 05:59:03 PST 2014
https://bugs.webkit.org/show_bug.cgi?id=139581
--- Comment #8 from Andrzej Badowski <a.badowski at samsung.com> ---
(In reply to comment #7)
> (In reply to comment #3)
> > (In reply to comment #2)
> > > It looks to me like ATK_RELATION_MEMBER_OF is applicable for a group of
> > > radio buttons because those radio buttons are all a member of a group.
> > > However, I question (quite a bit) its applicability for an internal anchor
> > > connection.
> >
> > Thank you for your feedback. I understand your concerns about internal
> > anchor link, I had it as well. but:
> > 1. There is no other relationship ATK more appropriate to do so.
>
> First, as Joanmarie said, if you think that an appropiate relationship is
> missing, then the way to go is asking for a new ATK relation. Relationships
> has meaning, that different ATs use in order to know how to present
> information to the users. ATK_RELATION_MEMBER has a meaning, and it is not
> to include anchors.
>
> Second, I really don't think that a relationship is needed here. Relations,
> at least in ATK, are used to relate two (or more) different objects, because
> is a convenient way to get one based on the other. But for the case of
> links/anchors, that is not needed because ATK API for links already
> contemplate this:
>
> https://developer.gnome.org/atk/unstable/AtkHyperlink.html#atk-hyperlink-get-
> object
>
> So you can already get the anchors from an Hypertext document without a
> relationship.
>
> > 2. The linkedUIElements treats both objects together.
>
> I know that one of the objectives of the test is also detecting things that
> are still not implemented on the ports, but in this case, seems that is more
> like that the current test infrastructure is forcing a specific
> accessibility implementation, that is not one of the objectives. As I said,
> ATK hyperlink/hypertext API already provides to ATs the way to get the
> individual anchors, without the need of adding a relationship. Adding the
> relationship sounds like adding something that ATs doesn't need, so it is
> just complicating the implementation (imho).
Thank you for checking and tips on how to solve the problem.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20141217/2951222c/attachment-0002.html>
More information about the webkit-unassigned
mailing list