GNOME Bugzilla – Bug 538046
Orca should indicate when editing is enabled/disabled for Impress placeholders
Last modified: 2008-06-27 16:45:42 UTC
Steps to reproduce: 1. Launch Impress and create a new presentation. 2. Create a slide with title and text placeholders 3. Press F6 until you get to the scroll pane. 4. Tab to the first placeholder and press Enter to start editing. Expected results: Orca would speak a message to let the user know that they are now editing text. Actual results: Orca says "blank" or "paragraph 0" or nothing. 5. Press Escape to stop editing. Expected results: Orca would speak a message to let the user know that they are no longer editing text. Actual results: Orca speaks the name of the placeholder. When Mike and I discussed this on the phone, we came up with "editing text" and "not editing text" as the messages. As I'm writing this up, I'm wondering if "editing on" and "editing off" might be better.
Created attachment 112671 [details] Orca debug log generated whilst testing this problem.
I agree with Joanie's comment in bug #538064. With the patches to bug #538064 and bug #538053 applied, I think enough state in now given to know whether you are editing the placeholder or just focused on it.
Created attachment 112930 [details] test case Try tabbing to each of the title placeholders in the attached and press enter. Sometimes we say "paragraph 0" and then the text that's there. Sometimes we say nothing.
I've adjusted the latest patch on bug #538064: http://bugzilla.gnome.org/attachment.cgi?id=113006 to hopefully address the problem mentioned in comment #3. There was code in the onStateChanged() method in the soffice script.py file that tried to work around a bogusity in presentations of oowriter paragraphs due to an extra event. Unfortunately it was also getting triggered for ooimpress paragraphs as well. I've adjusted the tests to look for a specific roles hierarchy that hopefully is only found in oowriter. It sure would be nice if we could just write different scripts for each of the OOo applications, instead of having to jump through hoops and get them all working nicely in one script. I'm sure there's going to be other things like this that are going to bug us. Anyhoo, please test the patch over on bug #538064: http://bugzilla.gnome.org/attachment.cgi?id=113006 w.r.t. hopefully having this problem fixed.
The latest patch to bug #538064 has just been checked in. This improves what is spoken/brailled when you are in on on a placeholder. As Joanie says: I also think that the feedback we get from this patch makes it worth reconsidering if it is necessary and desirable to speak additional messages indicating when we have started and/or stopped editing. * With this patch, we now indicate when focus is *on* a placeholder (i.e. we're not editing) by stating the type of placeholder we're on and reading its contents. We do this both when tabbing among placeholders and when escape is pressed after editing a placeholder's contents. * With this patch, now indicate when focus is *in* a placeholder (i.e. we've started editing), by indicating the text object we are within that placeholder (e.g. "paragraph 2") and then reading the text on the line with the caret. In both cases, we need to provide this information so that the user knows exactly where he/she is. And the information is distinct enough to identify if we are editing or not. If we tack on editing/not editing messages, that seems like an awful lot for us to be saying.... It didn't at the time Mike and I were talking about this issue, but back then Orca was saying jack so it was hard to know.... :-) I too believe this now gives enough context. Mike, could you try it out please and let us know if this works for you? Thanks.
Sorry I forgot to comment on this one. I believe that the provided context is plenty and no other changes are needed for this one.
Thanks Mike.