Bugzilla – Bug 487859
Return HelpProvider's HelpString when querying an accessible's description
Last modified: 2009-05-06 20:30:25 UTC
PROBLEM STATEMENT Currently, HelpProviders really aren't that useful from an accessibility standpoint. In Linux the F1 key is pressed when a control is focused and a ToolTip pops up with the text in the HelpProvider's HelpString property. The problem is that the ToolTip isn't accessible like the normal ToolTips, which have their text returned when an accessible is queried for a description (see Bug 457830). Therefore, It would be nice if we returned the HelpProvider's HelpString text, if applicable, when querying an accessible's description. REPRO 1. Run Accerciser, click on the "Interface Viewer" tab, and expand the "Accessible" expander. 2. Run uia2atk/test/samples/helpprovider.py 3. Optionally, click inside the last TextBox on the helpprovider.py application and press F1 to see that a tooltip appears with the HelpString text. 4. In Accerciser's left pane, browse to and select the text accessible that represents the last TextBox on the helpprovider.py application. RESULTS In Accerciser's interface viewer, notice that there is no description for the accessible EXPECTED RESULTS It would be nice if we returned the HelpProvider's HelpString text, if applicable, when querying an accessible's description. COMMENTS Windows does not appear to do this, but it would be nice and would actually make HelpProvider useful from an accessibility perspective. Because Window's does not appear to have this functionality, I am logging this bug as an enhancement. I will attach an IRC discussion on the topic (between Mario and myself).
Created attachment 281260 [details] IRC discussion referenced in COMMENTS
Looking into this, I'm not really sure how we could make this happen. Controls don't have references to their HelpProvider, so when the Control's HelpText is queried, it can't know what to pull back. Mario, do you have any bright ideas?
I wrote something similar for SWF.ErrorProvider, there's a class (ErrorProviderListener) listening 4 internal SWF.Events, 2 are used to associate control & SWF.ErrorProvider: UIAErrorProviderHookUp and UIAErrorProviderUnhookUp, in order to keep track of those new warning-icons controls added when SWF.ErrorProvider.Show is called, anyway, basically the flow is the following: 1. UIAErrorProviderHookUp is raised, ErrorProviderListener associates Control+ErrorProvider and does magic to keep track of those new controls 2. UIAErrorProviderUnhookUp is raised, ErrorProviderListener removes association. So, writing something similar would help: 1. (new internal event) SWF.HelpProvider.UIAErrorProviderHookUp is raised when SWF.HelpProvider.SetHelpString("something") (in SWF.HelpProvider.HelperProperty.ctr), also seems that an internal event to raise changes on SWF.HelpProvider.HelperProperty.Text is going to be required, you know to actually raise an UIA NameProperty changed event when we replacing "something" with "something else", this event would be used by HelpProviderListener to keep a dictionary (control/help string). 2. (new internal event) SWF.HelpProvider.UIAErrorProviderUnhookUp is raised when SWF.HelpProvider.SetHelpString("null"), used by HelpProviderListener to remove key (control) 3. And, finally, in SimpleControlProvider we would need to call a new static method HelpProviderListener.GetErrorProvider(Control) to get the key value stored by HelpProviderListener on the dictionary. This would work.