GNOME Bugzilla – Bug 538064
Orca should speak placeholder contents when that placeholder is given focus on an Impress slide
Last modified: 2008-06-27 16:46:14 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 among the placeholders. Expected results: Orca would speak the text displayed for that placeholder Actual results: Orca speaks the name(?) of the placeholder (e.g. ImpressTitle 1, ImpressOutliner 2). This means that the user has to get into (and likely out of) editing mode just to see what's there.
Created attachment 112708 [details] Orca debug log generated whilst testing this problem.
Created attachment 112880 [details] [review] Revision #1. Tested with OOo 3.0beta_20080429 on Ubuntu Hardy. Make sure you are patching against a clean SVN trunk checkout (i.e. you haven't previously applied the patch to bug #538056).
Rich this is near perfect, thanks! There's still a case or two where the contents are not spoken when you tab to them. But that seems to be the exception rather than the rule. I need to pin it down further so that I can give you more info/reproducible steps. Given that it's nearly 3 AM and that I'm fading fast, I'm adding my name to the bug as a prompt to myself that I still need to do something. Hope you don't mind. As a side note, this fix has implications for bug #538046, namely if I press Escape to stop editing and Orca behaves as if the place holder just (re)gained focus, that clues me in to the fact that I'm no longer in editing mode. In which case, a message that editing mode has been disabled might not be necessary....
Created attachment 112919 [details] [review] Revision #2. Revised version again SVN trunk, now that the fix for bug #538056 has been checked in.
Created attachment 112929 [details] test case 1. Open the attached presentation 2. Page Down to slide 2 3. (Use the mouse to) change the layout to "Title, 2 Text Blocks". This is the 4th item in my list of layouts and looks like it has three placeholders: A title and 2 bulleted lists. Having done so, the original bulleted list will occupy the left half and a new bulleted list will appear on the right half. The new placeholder will contain the text "click to add an outline". 4. Press F6 until you get back to the Normal page of the scroll pane. For me this is two presses. 5. Tab amongst the placeholders. Results: The first two are read in their entirety. The third placeholder's type/name is announced, but the contents are not. 6. Press Page Up to go to slide 1 then Page Down to return to slide 2. 7 Tab amongst the placeholders. Results: All three are read in their entirety. Other than this (admittedly) edge case, your patch works quite nicely.
Created attachment 112949 [details] Orca debug log generated whilst testing the problem reported in comment #5 It's YAOOB. I added some debug statements to my new code and it's clear that when focus is on one of those two lower place holders (say ImpressOutliner3 at line 772) and we find it's the desired accessible component hierarchy (at line 795), and we then go to speak each of the children, we find that the child count is zero (line 845). I'm going to separate this out into another bug, file the OOB and block that new bug against it.
Bug #538869 have been opened against the problem in comment #5.
Created attachment 113006 [details] [review] Revision #3. This patch is actually to fix the problem mentioned in comment #3 of bug #538046: http://bugzilla.gnome.org/show_bug.cgi?id=538046#c3 but I've just adjusted this patch to we don't need to apply multiple patches.
Created attachment 113132 [details] [review] Revision #4. With the previous patch, when we press Enter over a multi- paragraph placeholder, due to the "fix" for bug #538835, we were bogusly speaking the last word of the previous paragraph to hold focus. Joanie came up with a nice solution to prevent this, for this situation, but still allow the original fix to work correctly (thanks!). I've just adjusted the patch here, so that there is only one patch that needs to be applied to test Orca with simpress.
Rich, this works quite nicely. It would be better still if we could get the OOo guys to number their paragraphs starting from 1 rather than 0. ;-) ;-) Regardless, I think this is worth checking in as it greatly improves the situation. 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.... :-)
Thanks Joanie. Patch committed to SVN trunk. W.r.t. whether we should speak editing/not editing messages: I'll comment on that in bug #538046. Moving this one to "[pending]".