GNOME Bugzilla – Bug 525895
[blocked] Orca does not provide access to objects represented by Embedded Object Characters in OOo Writer documents
Last modified: 2018-02-08 12:49:46 UTC
Steps to reproduce: 1. In the Writer Options dialog, under Accessibility, check the "Use text selection cursor in read-only text documents" checkbox. 2. Open the sample document (to be attached). 3. Use the arrow keys to move line by line from the top of the document. Expected results: As you move to lines with form fields (represented by Embedded Object Characters), Orca would present the text (in the case of a label) or otherwise identify the object (in the case of a focusable field). Actual results: Orca says "ewwwww" (or something that sounds an awful lot like that, at least to my Geckoized ears) and displays a single character ("OBJ") in braille.
Created attachment 108520 [details] read-only version of the document
Created attachment 108522 [details] unprotected/not read-only version of the same document Doesn't seem to make a difference, but I had already created each for the YAOOB I filed so I might as well attach it just in case it's needed.
In light of the fact that EOCs can appear in Writer documents (who knows where else they lurk?), I'm wondering if the handling of these beasts is something that could be generalized (at least to a certain extent) and pulled out of Gecko.py. Thoughts?
Created attachment 108525 [details] Graphics examples It's not just forms. Here's a few with images. Note: 1. More ewwwwing and (obj)ing that we need to handle. 2. We're not always seeing the object the EOC represents (which I would expect to see as a child of the text object in which it's embedded). We don't just want to not say "ewwww" we want to give some indication in place of "ewwww" as to what's there -- which means we need to be told. YAOOB I assume (not yet filed).
Created attachment 108532 [details] Note objects are EOC's too Another EOC example where we're presenting the EOC as is (and the embedded object is not seen in the hierarchy). On another note (no pun intended), seems that Swift is the only one of my synths that is trying to pronounce the EOC. Espeak and Fonix DECtalk don't say anything for this character.
As discussed in team meeting today, I opened an issue for the EOC issue: http://www.openoffice.org/issues/show_bug.cgi?id=88070 We also talked about blocking this bug against that issue. I haven't yet done the this because I think that even with the current implementation: 1. We can still improve things (we shouldn't be passing the embedded object characters along to the synthesizers and braille displays as-is). 2. In the case of the form example, it appears that the embedded objects do have counterparts in the hierarchy. We might be able to make arrowing around that document work -- if nothing else, the act of attempting to do so might bring out other issues we'd like to tack on to issue 88070. I'll leave it to someone else to decide if this should be blocked or worked on.
the linked OO bug 88070 appears to be fixed as of june 2010 ing?
Closing blocked bugs because we need the issue fixed in the blocker.