GNOME Bugzilla – Bug 462883
[will] ARIA tooltips/alerts are not being output
Last modified: 2008-07-22 19:33:33 UTC
ARIA tooltips/alerts are not being output. It is known that the dojo tooltips use wairole:alert see http://trac.dojotoolkit.org/ticket/3957 and the other test case uses wairole:tooltip (I believe). There also has been double output on JAWS see https://bugzilla.mozilla.org/show_bug.cgi?id=390673 and I have seen an excessive amount of at-spi events when the alert appears. Test cases * HTML tooltip link at http://developer.mozilla.org/en/docs/Accessible_DHTML#Supported_roles * Dojo tooltip example at http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tooltip.html
Created attachment 93053 [details] [review] first version of ARIA tooltips/alerts are not being output This patch suffers from the Mozilla bug listed in the opening comment (double announcements), but seems to perform good on the test cases. Notes and questions: 1) The object pointed to by the object:children-changed:add event is not always the alert/tooltip, sometimes the tooltip is a child of this object. 2) Should we stylize the output? It is an alert. 3) Is braille handled properly? 4) Is monitoring object:children-changed events too costly?
(In reply to comment #1) > This patch suffers from the Mozilla bug listed in the opening comment (double > announcements), but seems to perform good on the test cases. Seems to work OK for me! I don't get the double announcements from the tooltips on http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tooltip.html. I did notice this stack trace, though: Traceback (most recent call last):
+ Trace 153823
s.processObjectEvent(event)
self.listeners[key](event)
for attr in obj.attributes:
> Notes and questions: > 1) The object pointed to by the object:children-changed:add event is not always > the alert/tooltip, sometimes the tooltip is a child of this object. Bummer. This can make processing children-changed events expensive if we get lots and lots of children-changed events. I see lots of name-changed events for the tooltips in the Dojo example, many of which seem redundant for some odd reason. I wonder if we can use those? If not, I guess we can try to figure out some optimization scheme for ignoring children-changed events in some cases (e.g., the page is loading). > 2) Should we stylize the output? It is an alert. > 3) Is braille handled properly? It looks like the current tooltip handling code for GTK+ just presents the tooltip text with no other information. Mike, should we be presenting rolename information? > 4) Is monitoring object:children-changed events too costly? It might be, but if there's no other way, we'll need to cope. :-( By the way, is there a keyboard mechanism for Gecko to pop up a tooltip? In GTK+ it is Ctrl+F1. I've only been able to pop up tooltips in Gecko via mouse-overs :-(. Note also that there is a setting to ignore tooltips popped up by mouse overs: settings.presentTooltips. If it is False, tooltips popped up by mouse overs should be ignored.
> AttributeError: 'NoneType' object has no attribute 'attributes' For reference, this being addressed as part of bug 469686.
Created attachment 98572 [details] [review] second version of ARIA tooltips/alerts First version post-pyatspi migration. The any_data field for object-children:changed:add:system events is now None for tooltips/alerts. I will consult with Aaron about this problem. What is strange is that the any_data field is now correct for live region events but None for these types of events, both of which are object-children:changed:add:system events.
Mozilla bug that tracks the any_data problem https://bugzilla.mozilla.org/show_bug.cgi?id=402597 . Highlights: Accessibility::Event.any_data is correct if you change the 'span' to a 'p' for the tooltip in http://www.mozilla.org/access/dhtml/new/tooltip . Please fix span issue (tough one I'm sure) or change the example, possibly mentioning <span> unsupported. The UIUC examples seen here http://test.cita.uiuc.edu/aria/tooltip/view_xhtml.php?title=Tooltip%20Example%201&ginc=includes/tooltip1_xhtml.inc&gcss=css/tooltip1_xhtml.css&gjs=js/tooltip1_xhtml.js,../js/widgets_xhtml.js,../js/globals.js and http://test.cita.uiuc.edu/aria/tooltip/view_html.php?title=Tooltip%20Example%201&ginc=includes/tooltip1.inc&gcss=css/tooltip1.css&gjs=js/tooltip1.js,../js/widgets.js,../js/globals.js do not trigger any AT-SPI events during the tooltip showing sequence. The dojo example seen here http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Tooltip.html also uses a span for the tooltip. However, changing it to a <p> did not fix the problem. I tried several markup changes to the surrounding tooltip markup, all with no luck. The event.any_data field is always None for object:children-changed:add:system events. Also of note is that the object:text-changed:inserted:system events appear to be of little worth to Orca for tooltip announcements.
Created attachment 98667 [details] working test case This is a working test case. Most test cases are currently unsupported due to the any_data issue for children-changed events. This test case is an adaptation of the Mozilla example, where <span> is replaced with <p> for the tooltip.
Created attachment 98670 [details] [review] third version of ARIA tooltips/alerts Patch that works well on the attached test case. It should also work with other alerts/tooltips as long as the object:children-changed:add:system events has a good any_data field and has proper ARIA 'xml-roles' markup.
This looks good from a code perspective -- the changes are relatively isolated and safe. Mike, what are your thoughts from a user interface perspective?
With the limited number of test cases currently available I think this functionality is OK.
(In reply to comment #8) > This looks good from a code perspective I'm wondering if I should put more safeguards against container objects. Probably won't happen with a tooltip, but you never know. > the changes are relatively isolated and safe. Famous last words :) The changes are not so isolated. It introduces a listener for object:children-changed events into Gecko.py. I think the performance ding might be noticeable, especially on page loads.
(In reply to comment #10) > (In reply to comment #8) > > This looks good from a code perspective > > I'm wondering if I should put more safeguards against container objects. > Probably won't happen with a tooltip, but you never know. If you think it's necessary, then feel free. :-) > > the changes are relatively isolated and safe. > > Famous last words :) The changes are not so isolated. It introduces a > listener for object:children-changed events into Gecko.py. I think the > performance ding might be noticeable, especially on page loads. Well...the self.noOp listener was already doing this, so it shouldn't introduce too much overhead, except for the string compare to "object:children-changed:add:system".
Committed to trunk with no additional changes as discussed in comment #10.
Created attachment 100131 [details] [review] fourth version of ARIA tooltips/alerts Added sanity check for event.any_data.
sanity check committed into trunk.
Created attachment 104061 [details] [review] first version post live regions commit This version treats all tooltip/alerts as a live region. The following things need to be done to accomplish this: 1) Use STATE_SELECTABLE instead of STATE_FOCUSABLE. This allowed me to look at the target object (any_data) state for children-changed events in handleAsLiveRegion(). Looking at the target object and not the source object fixes some tooltip types and seems to be the correct thing to do here. 2) In liveregions._getMessage(), I took a closer look at how I was getting content for certain event types with and without ARIA markup and with atomic='true' and atomic='false'. I think what I have now more accurately honors the atomic property. Objects that do not have ARIA markup are treated like atomic='false'. 3) In liveregions._getMessage(), I changed the find(embed char) to a count(embed char). We will get a children-changed event if we see an embed character. The find() was just plain wrong. The fix allows Orca to work on all tooltip examples (UIUC example will be updated soon), the finance sites and the live region test sets. I also checked the bugzilla combobox horror. Everything seems to work fine.
Changed target milestone to 2.21.91
The latest patch fails badly on the Mozilla ARIA alert example http://www.mozilla.org/access/dhtml/alert . The problem is due to no ':system' on some of the object:children-changed:insert events. As a result of this, these are immediately being rejected as not live regions in the first test in handleAsLiveRegion(). I'm not really sure what the best course of action is yet. Is this a Firefox bug?
Scott, can you check whether this is also true with a build prior to January 24? On January 24 builds, fix for Mozilla bug 407359 landed, which also had some changes to the way Alerts work, to prevent screen readers on Windows double-speaking or even triple-speaking them. I could imagine that this had an affect on the way Orca needs to handle such alerts like the "Do you want to remember this password" one.
I would expect no :system on those events actually. I'm not sure you understand the purpose of :system. If :system is not present, it means the user caused the change by clicking on something or pressing a key. That means it is probably *more* likely they want to hear whatever it is, since they made it happen and its not random. Sort of like when you tab or hit a key you want to hear the results of that. As opposed to something like a change in a stock quote, which is called :system because the user did not cause the update to happen via any input they provided. Those kinds of changes are a bit more disorienting.
The problem is some of those alerts trigger events with :system and others do not. I would expect no :system for all of them. Have we found an edge case where "*more* likely" doesn't hold?
Any children-changed or text-changed event that is the result of a click or key should not have :system. It's a bug when that's not true.
Created attachment 104112 [details] [review] second version post live region commit This version builds on the last patch to include support for ARIA alerts. Now, both ARIA alerts and tooltips are handled by the live region manager. In addition to juggling the event.types and filter conditions, I added another filter in handleAsLiveRegion(). This filter looks at a new timestamp taken when we get a window:active event. The filter prevents live region events that have occurred within 2 seconds of the document being 'loaded'. This was required because I came across several pages that build dynamically after the page is loaded. This dynamic building triggers events that mimic a live region change. The new filter simply allows the page to be built before live regions are acted upon.
I should have said this yesterday: In the specific case of an alert I would not worry about whether it is :system or not. It should basically be treated as assertive or rude no matter what. The idea of an alert is it is something the user really needs to know. It could be a severe weather alert or "servers going down in 10 minutes" type of thing that isn't necessarily generated by user input. We still need to fix the bug on the Firefox side obviously. The :system indicator is still important for all non-alert changes.
Joanie helped give me a quick sanity check via IM. This patch seems OK. The only question is if the tooltip stuff respects the settings.presentToolTips setting. If not, it's probably still OK to check this patch in and then open a separate bug to make sure the setting is honored. The presentToolTips setting, btw, is hackily handled in focus_tracking_presenter.py right now. The main notion is this: 1) If the user forced a tooltip to appear via a keyboard action (Ctrl+F1), then present the tooltip regardless of the setting. 2) If the tooltip appeared because of some non-keyboard action (e.g., mouse over), then present the tooltip only if the setting is true.
committed to trunk. Changed Target Milestone to 2.21.92.