Re: [orca-list] some links from yelp not accessible

[Joanmarie Diggs <jdiggs igalia com>]

Hey Jarek.

On 03/27/2014 04:43 PM, Jarek Czekalski wrote:

> I tested that this problem is not due to orca. Accerciser does not see
> caret movements in suspected area either.

Thanks for doing that investigation! As you requested, I checked in
Fedora -- I happen to be using rawhide (which is about to become F21)
and can confirm the issue.

> I also prepared a simple webpage to test the issue:

Nice! Thanks!!

> Now, what do we do with the inaccessible parts of gnome help? If webkit

WebKit is fixable. And since the test case could probably be found in
web content that is not gnome help, that is where it needs to be fixed.
So if I could ask you to do one more thing....

Please file a bug at bugs.webkit.org. When you do so:

* Provide your test case as an attachable document so that it remains
  present even after you remove your temporary one.

* Create a stand-alone pyatspi accessible-event listener which
  demonstrates the problem. This is quite easy to do (see below) and
  eliminates the need for a would-be fixer to have to install and get
  to know Accerciser. Attach that listener to the bug.

* CC me at the address I am using to send this email.

An example bug (complete with pyatspi accessible-event listener) you can
follow is this one which I filed not too long ago:
https://bugs.webkit.org/show_bug.cgi?id=127287

Only difference is that you want to listen for object:text-caret-moved
rather than object:state-changed:focused. And you'll also want to
eliminate the "if not e.detail1" check. In the case of
object:state-changed events detail1 reflects a boolean and what is
no-longer focused (or showing or whatever) is often not of interest. In
the case of caret-moved events, detail1 is the new offset. We don't want
to filter out anything there.

Hope this makes sense. Please let me know if you have any questions. And
thanks again for digging into this one!!
--joanie