GNOME Bugzilla – Bug 423198
[pending] Orca should not speak "text" repeatedly when moving around in a text entry area on a web page
Last modified: 2007-04-13 17:00:03 UTC
1. attempt to file a bug at bugzilla.gnome.org. 2. type several lines of text in the description 3. CTRL+right and left arrow between the words in this text. You will hear "text" after you hear each word. 4. Up and down between the lines in the text. You will hear "text" after each line. Because we have already been alerted that we have entered a text area upon entry we don't need to hear it over and over again. We should treat this text similar to the text in gedit.
*** Bug 423199 has been marked as a duplicate of this bug. ***
Created attachment 85788 [details] [review] patch to hopefully solve the problem This patch seems to get the job done: I used it to review this comment and didn't hear "text, text, text" <smile> I can think of one case we're not handling "perfectly" with this patch. In particular, the following must all be true: 1. Gecko is controlling the caret 2. We navigate by word or by line and happen across an entry (i.e. we're not *in* the entry, we didn't use Tab or structural navigation to get to the entry, but have merely stumbled across it), 3. That entry happens to have text in it. (Otherwise, we can't stumble across it in this fashion) Given the above circumstances, Orca will speak/braille the text but it won't actually say "text" to distinguish the content that's in the entry from the content that's not. Without the patch, Orca will say "text" in the above circumstances. Personally, I think the above is an "edge case." The question is: Is it an edge case worth handling?? In the meantime, Mike can you please give this patch a try? Thanks!!
The 'contents' stuff can be composed of a whole list of objects. As such, consider the following line that might be turned into 'contents': Blah <x> blah [blah] foo: __________ [diddy] Where <x> is a checkbox, [blah] and [diddy] are links, and ________ is an entry. I may be reading the patch wrong, but it seems as though it would also prevent all rolenames from being spoken when we are in the entry and we call sayLine. Is this correct?
If you are in the entry and that entry a text area, yes. I mention the text area bit because if you're in a single line entry and Up/Down Arrow, you'll leave the entry and move off of that line, in which case the scenario vanishes. I admittedly didn't consider the scenario you pointed out, so thanks for pointing it out! That said, let's imagine this scenario for a moment: You're in bugzilla happily writing your comment explaining why you didn't think of that scenario. As you review your excuse, you hear something like: blah blah foo my coffee maker is broken diddy plus I'm out of coffee Without my patch you'd hear blah checkbox not checked blah link foo my coffee maker is broken diddy link plus I'm out of coffee In either case, that's not a good user experience IMHO. I think it would be even worse if, due to some clever alignment on the part of a web page creator, you had multiple lines of text next to your text area. For instance what if the bugzilla label were not "description:" but rather: Description: <br /> (You should <br /> try to be as <br /> specific as <br /> possible because <br /> we'll ignore <br /> your bug <br /> if you aren't <br /> so there. <br /> In that instance wouldn't each of the lines we wrote in the text area be prefaced by that unfortunate label? Therefore I'm wondering if, as a separate issue, we want to cause sayLine to only speak the text within the entry as we move up and down within that entry. Thoughts?
I'm on the phone with Mike right now. :-) Mike thinks that: 1. if we are *inside* the entry navigation within the entry should only cause entry text to be spoken; surrounding objects on the same line which are *outside* of the entry should not be spoken. 2. If we are outside of the entry, all items on that line (i.e. surrounding objects as well as entry text) should be spoken. In light of this, my proposal is that we commit this patch as is and open a new bug related to only speaking text inside an entry. Will, what do you think?
> 1. if we are *inside* the entry navigation within the entry should only cause > entry text to be spoken; surrounding objects on the same line which are > *outside* of the entry should not be spoken. Sounds good. I'm guessing the only exception is if the text entry has a label for it. When you first tab/arrow into the text entry, you'll present the label. Furthermore, the braille context would also always contain the label (though it might be scrolled off the left of the display). > 2. If we are outside of the entry, all items on that line (i.e. surrounding > objects as well as entry text) should be spoken. Sounds good. Thanks!
Patch committed. As I proposed, I opened a new issue for only speaking entry text when Up/Down Arrowing within an entry (bug #426687) In addition, while working on this patch I discovered that Orca doesn't speak text in an entry when one uses Up/Down Arrow AND happens to be at the very end of the line. Mike subsequently pointed this out as well. As that issue is independent of this patch, it has been filed as bug #426684.
I think this one looks good now and is safe to close.