GNOME Bugzilla – Bug 468633
No output when tabbing to ARIA slider
Last modified: 2007-09-26 13:03:51 UTC
The ARIA slider test cases are not outputting any announcement when tabbing to them. The problems lies in speechgenerator._getSpeechForObjectName(). This method first uses getDisplayedText(). If this fails to find the obj's name the obj.description is used. The problem with ARIA sliders is that getDisplayedText() often returns only embed character(s). A similar issue was seen previouly here http://bugzilla.gnome.org/show_bug.cgi?id=340559 . I propose that we first look for obj.name then use getDisplayedText(). Test cases: http://www.mozilla.org/access/dhtml/simple-slider http://www.mozilla.org/access/dhtml/pretty-slider.htm http://test.cita.uiuc.edu/aria/slider/html.php?title=Slider%20Example%201&ginc=includes/slider1.inc&gcss=css/slider1.css&gjs=../js/globals.js,../js/enable.js,js/slider1.js http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_Slider.html
Created attachment 94013 [details] [review] first version of No output when tabbing to ARIA slider This simple patch will solve many of the problems. Dojo sliders are still an issue.
> The ARIA slider test cases are not outputting any announcement when tabbing to > them. The problems lies in speechgenerator._getSpeechForObjectName(). This > method first uses getDisplayedText(). If this fails to find the obj's name the > obj.description is used. The problem with ARIA sliders is that > getDisplayedText() often returns only embed character(s). A similar issue was > seen previouly here http://bugzilla.gnome.org/show_bug.cgi?id=340559 . I > propose that we first look for obj.name then use getDisplayedText(). The problem we're facing here is that getDisplayedText was designed for a toolkit like GTK+: it is intended to get the text being displayed by a somewhat smallish and atomic object. If I understand it correctly, in Gecko-land we're dealing with potentially unbounded objects: the slider could be presenting text and the text could be links with more stuff, etc., etc. I'm somewhat opposed to using obj.name before getDisplayedText() for the mere fact that we're trying to be a screen reader here and we can run into situations where the text being displayed by an object can be different from its name. I think we should generally try to look at getDisplayedText() first to avoid this confusion. Now, for how to work around this...I'm not sure. I was going to start poking around, but I'm currently dealing with that nasty Firefox "page tabs are invisible" problem, so I'm afraid to leave this tab. I might never get back to it. So, if I have a good idea, I will reply in a new comment.
I think the sliders with strings on them are indeed a case we don't support very well. These strings don't represent the current state, and they really don't represent the name of the slider, either. For example, in looking at http://www.mozilla.org/access/dhtml/simple-slider, I see a simple unlabelled horizontal slider with the string "0" on the left side, "100" on the right side and an ASCII slider representation in the middle, where a "|" is used to represent the current value: 0 (------|------) 100 When one tabs to this unnamed slider, I'm assuming we should present just the value and role (e.g., "slider 50%") and not attempt to present the "0" or "100". This would match the decision we made in bug 340559. Mike, is this correct? When we come across a labelled slider, however, we should definitely try to present the label, which is what I believe we already do. For example, assume the text "Happiness level:" is the label for the slider: Happiness level: 0 (------|------) 100 We should present the label, value, and role when the slider first gets focus (e.g., "Happiness level: slider 50%"). Then, if/when the slider value changes while it has focus, we just present the new value. Mike, does that seem correct?
Created attachment 94056 [details] [review] second version of No output when tabbing to ARIA slider ARIA sliders seem to deviate from GTK+ sliders enough to warrant moving _getSpeechForSlider() over to gecko.py. The new version of the method does not attempt to output the displayed text due to the problems listed above. It only outputs the label, role, value and availability (only value when already focused). Note: A change was done in gecko.getDisplayedLabel() where getText(0,-1) is used instead of obj.name. The Mozilla guys have fixed the whitespace bug so this should be safe. It will also be consistent with our theme of displaying what is on the screen.
> ARIA sliders seem to deviate from GTK+ sliders enough to warrant moving > _getSpeechForSlider() over to gecko.py. The new version of the method does not > attempt to output the displayed text due to the problems listed above. It only > outputs the label, role, value and availability (only value when already > focused). In looking at this, is the main difference just avoiding adding the name? That is, eliminating this section of code: # Ignore the text on the slider. See bug 340559 # (http://bugzilla.gnome.org/show_bug.cgi?id=340559): the # implementors of the slider support decided to put in a # Unicode left-to-right character as part of the text, # even though that is not painted on the screen. # # In Java, however, there are sliders without a label. In # this case, we'll add to presentation the slider name if # it exists and we haven't found anything yet. # if not utterances: utterances.extend(self._getSpeechForObjectName(obj)) If so, I think we need to revisit the Java case and potentially come up with something different if we can. > Note: A change was done in gecko.getDisplayedLabel() where getText(0,-1) is > used instead of obj.name. The Mozilla guys have fixed the whitespace bug so > this should be safe. It will also be consistent with our theme of displaying > what is on the screen. This seems cool to me. Joanie, what do you think?
Created attachment 94062 [details] test case > > Note: A change was done in gecko.getDisplayedLabel() where getText(0,-1) is > > used instead of obj.name. The Mozilla guys have fixed the whitespace bug so > > this should be safe. It will also be consistent with our theme of displaying > > what is on the screen. > > This seems cool to me. Joanie, what do you think? > I think that as long as the label doesn't contain any embedded object characters in it, you will be fine. However, when the label *does* contain EOC's, getText(0,-1) will return the EOC's; obj.name will return the text being displayed. Try tabbing into the Name entry pre-patch and post-patch. Pre-patch Orca says "Name: text" when focus is moved into that entry. Post-patch it says "ewwww text" (or something like that. It's trying to pronounce the EOC).
> I think that as long as the label doesn't contain any embedded object > characters in it, you will be fine. However, when the label *does* contain > EOC's, getText(0,-1) will return the EOC's; obj.name will return the text being > displayed. I knew there was a reason for asking you. :-) I keep forgetting about those wonderful EOC's. Would you recommend going with self.expandEOCs(label) or sticking with label.name?
> I knew there was a reason for asking you. :-) I keep forgetting about those > wonderful EOC's. Would you recommend going with self.expandEOCs(label) or > sticking with label.name? > Well, expandEOCs() was added to deal with these very sorts of problems. When there are not EOCs, it returns text.getText(start, end) where start and end default to 0 and -1 respectively. So a) if there aren't EOC's it's really the same call that Scott is proposing and b) if there are (as with my test case), it solves the problem. So.... Yeah, I'd recommend dumping label.name if that makes sense to Scott.
Created attachment 94063 [details] [review] third version of No output when tabbing to ARIA slider This version changes label.name in getDisplayedLabel() to expandEOCs(label). It works great for the sliders as well as the attached test case.
Created attachment 94066 [details] [review] third version of No output when tabbing to ARIA slider Ooops! Created patch from wrong directory last time. Here is the right one.
This version works for me. (Those sliders are cool btw :-) )
(In reply to comment #10) > Created an attachment (id=94066) [edit] > third version of No output when tabbing to ARIA slider > > Ooops! Created patch from wrong directory last time. Here is the right one. > Looks cool. Thanks! I'm still curious about the other question I asked in comment #5. Is the main difference in _getSpeechForSlider just avoiding adding the name? If so, I think we need to revisit the problem that had us put the name in there in the first place. It seems to be a Java thing, and I wonder if we can handle it differently. In addition, I notice the braille stuff doesn't have the same logic. Very odd -- we may need to bring Lynn in on this one.
Will, Yes, removing the name, which calls getDisplayedText() is the only difference between the two _getSpeechForSlider() methods. A web developer would have to explicitly create a 'labeledby' relation. The other bug (340559) does not mention Java at all. It only mentions the slider within the Orca configuration GUI. Do you know a Java test case? Will I be able to test a Java widget?
(In reply to comment #13) > Will, > Yes, removing the name, which calls getDisplayedText() is the only difference > between the two _getSpeechForSlider() methods. A web developer would have to > explicitly create a 'labeledby' relation. > > The other bug (340559) does not mention Java at all. It only mentions the > slider within the Orca configuration GUI. Do you know a Java test case? Will > I be able to test a Java widget? I think the two comments cover separate issues. The Java portion was added as a result of this change: http://svn.gnome.org/viewcvs/orca?view=revision&revision=1178 http://svn.gnome.org/viewcvs/orca/trunk/src/orca/speechgenerator.py?r1=1176&r2=1178 Lynn, can you experiment with Java sliders to see if removing these lines from speechgenerator.py:_getSpeechForSlider has an adverse effect on Java sliders? I'm curious if the patch from Oana was a bad patch -- it may not be giving us what we expected. if not utterances: utterances.extend(self._getSpeechForObjectName(obj))
I didn't find any problems after removing these lines, but shouldn't Java-specific code like this be in J2SE-access-bridge.py? Maybe the safest thing to do is add a _getSpeechForSlider and _getBrailleRegionsForSlider to J2SE-access-bridge.
(In reply to comment #15) > I didn't find any problems after removing these lines, but shouldn't > Java-specific code like this be in J2SE-access-bridge.py? Maybe the safest > thing to do is add a _getSpeechForSlider and _getBrailleRegionsForSlider to > J2SE-access-bridge. Agreed that it should be moved to J2SE-access-bridge.py if the special case code is necessary. Based upon the results of your experiments (thanks!), however, I think it might be safe just to rip it out of speechgenerator.py and not even put it in J2SE-access-bridge.py until we find a real use case. This is just for trunk, BTW. We're not going to do this for gnome-2-20. Thoughts?
Created attachment 94428 [details] [review] fourth version of No output when tabbing to ARIA slider This version follows the discussion in respect to the java bridge. As a result, this version rips out the following code from _getSpeechForSlider(): if not utterances: utterances.extend(self._getSpeechForObjectName(obj)) and expands the embedded characters for the labels.
Based upon Lynn's experiments, this seems like a patch we should consider for GNOME 2.20. Mike, please test for this coming Monday's release.
committed to trunk. Waiting on Mike's approval before it is committed to gnome-2-20.
(In reply to comment #18) > Based upon Lynn's experiments, this seems like a patch we should consider for > GNOME 2.20. Mike, please test for this coming Monday's release. Mike, have you had a chance to test this?
I notice when I am on the slider at: http://www.mozilla.org/access/dhtml/simple-slider that left arrow moves me completely out of the slider. I am testing with orca from trunk on latest firefox.
(In reply to comment #21) > I notice when I am on the slider at: > http://www.mozilla.org/access/dhtml/simple-slider that left arrow moves me > completely out of the slider. I am testing with orca from trunk on latest > firefox. > I believe this is due to a poorly constructed widget because I see this problem without Orca. Although I have seen this problem in one of the UIUC examples, most of the other slider examples seem fine. The UIUC examples were modeled after the Mozilla examples so the problem may have been repeated. I will try to fix the widget that is having the problem.
The simple slider has problems when Firefox caret mode is on, but not when it is off. The problem might be caused by the slider being constructed of text elements and pressing the left arrow causes the caret to walk out of the slider.
I spoke with Mike about this today. The issues he was seeing were not related to this patch and this patch fixes the issues in question. Please commit this patch for trunk and gnome-2-20, and Mike will file separate bugs for the other problems.
Committed to trunk on 2007-08-31 Committed to gnome-2-20 now.
> this version rips out the following code from _getSpeechForSlider(): > > if not utterances: > utterances.extend(self._getSpeechForObjectName(obj)) We're no longer identifying the sliders by name in the Volume Control window. When I put those lines back, we do.
The Volume Control can be obtained by right clicking on the speaker icon in the panel. When I look at the "PC Speaker" slider on the far right of my window, I see that the slider has no label and the "PC Speaker" label doesn't label the slider. The slider itself has a name of "Track PC Speaker". I'm guessing "Track PC Speaker" the name that used to be presented. As a possible fix for this, do you think we could just do something like add the lines back in with the following additional expression on the "if"? if not utterances and <<<we're not dealing with Gecko>>>: utterances.extend(self._getSpeechForObjectName(obj))
(In reply to comment #27) > if not utterances and <<<we're not dealing with Gecko>>>: > utterances.extend(self._getSpeechForObjectName(obj)) Or, just put the lines back in speechgenerator.py and override the _getSpeechForSlider method in a SpeechGenerator subclass in Gecko.py (thanks Joanie!)
(In reply to comment #28) > (In reply to comment #27) > > if not utterances and <<<we're not dealing with Gecko>>>: > > utterances.extend(self._getSpeechForObjectName(obj)) > > Or, just put the lines back in speechgenerator.py and override the > _getSpeechForSlider method in a SpeechGenerator subclass in Gecko.py (thanks > Joanie!) Scott - can you work on this and create a patch please?
Created attachment 95981 [details] [review] fifth version of No output when tabbing to ARIA slider I needed to create a _getSpeechForSlider() method in the SpeechGenerator for Gecko.py because of the textual slider seen here http://www.mozilla.org/access/dhtml/simple-slider . See above comments for details. The patch seems to work fine for both ARIA and GTK+ sliders now. Note: the slider seen here http://test.cita.uiuc.edu/aria/slider/html.php?title=Slider%20Example%202&ginc=includes/slider2.inc&gcss=css/slider2.css&gjs=../js/globals.js,../js/enable.js,js/slider1.js is the only ARIA slider example that is labelled and it is broken. However, it works well enough to test this functionality.
I've just tested this patch with both the volume control and the orca prefs. Everything seems to now be working correctly.
(In reply to comment #30) > Created an attachment (id=95981) [edit] > fifth version of No output when tabbing to ARIA slider > > > I needed to create a _getSpeechForSlider() method in the SpeechGenerator for > Gecko.py because of the textual slider seen here > http://www.mozilla.org/access/dhtml/simple-slider . See above comments for > details. The patch seems to work fine for both ARIA and GTK+ sliders now. > > Note: the slider seen here > http://test.cita.uiuc.edu/aria/slider/html.php?title=Slider%20Example%202&ginc=includes/slider2.inc&gcss=css/slider2.css&gjs=../js/globals.js,../js/enable.js,js/slider1.js > is the only ARIA slider example that is labelled and it is broken. However, it > works well enough to test this functionality. Looking much better. Thanks! I'm curious if it might be possible to tighten the scope of this patch even further so that the special code is only done for ARIA widgets? For example, putting something like the following a the top of the new method in Gecko: # Treat non-ARIA widgets like default.py widgets # if not self._script.isAriaWidget(obj): sg = speechgenerator.SpeechGenerator return sg._getSpeechForSlider(self, obj, already_focused) Or, do XUL sliders also need special treatment?
An isAriaWidget() test was included at the top of Gecko._getSpeechForSlider() as described in above comment. Committed to trunk.
This now seems to be working correctly. thanks
(In reply to comment #34) > This now seems to be working correctly. thanks > Thanks Mike! Scott -- thanks for the hard work on this one. Please also check it into the gnome-2-20 branch for inclusion into GNOME 2.20.1.
committed to gnome-2-20 branch and marked FIXED