When tooltip dialog gets focus, focus needs to be on a component

[ptbrunet]

Using http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/test_Dialog.html move focus to the second button, the one with a downarrow. Press downarrow. Focus goes to the dialog but it needs to go to one of the widgets, e.g. the user input box. Screen readers ignore focus events coming from things that should not get focus so nothing is heard when focus goes to the dialog. Screen readers do this because so many apps fire focus on things that should not get focus so they filter out events from objects that have non UI behavior such as those of role DIALOG.

[becky]

focus was explicitly set to the tooltip dialog container so the screen reader would speak "dialog" and the associated title. Will the user still be informed that they are in a dialog if focus is set directly to the first element in the dialog? There is a similar issue with dialog - focus is set to the title bar so the screen reader will speak dialog and the title.

[ptbrunet]

JAWS 9, driver 289, is silent when the dialog gets focus. ATs typically will read the dialog title (and leading static text), and info for the focused widget when focus lands on the first widget. It does this via checking the acc. hierarcy. When using this test case with JAWS I notice the following:

• Pressing enter on that button, doesn't cause JAWS to enter forms mode. I had to use Ins+Z.
• After VPC cursor mode is off, when I open the dialog I hear nothing.
• If I then press tab I hear: Enter login information, dialog, edit, s to click, type in text
  • The "s to click" is because there is text bleeding through due to the transparency of the dialog. Apparently JAWS is not using MSAA for this.

Using W-E 6.1D gives the following behavior:

• Pressing enter on the button causes W-E to exit browse mode
• And it annouces the role of DIALOG when it gets focus (so they don't filter dialog events like JAWS does)
• Pressing tab to get to the first control you hear: scroll down to see, s to click, for testing positio, edit box

I don't know why W-E is not reading the acc. hierarcy, i.e. dialog and its title, when that first input box gets focus, perhaps something to do with getting the focus on the dialog and that causing a change in their logic. It does operate OK for standard Win dialogs.

In summary I see the following problems:

• dojo: focus should not be on the dialog object
• jaws: enter on push button didn't cause forms mode
• jaws: not using MSAA for the text input box
• w-e: not using MSAA for the text input box

[ptbrunet]

I reported the incorrect input box handling of Window-Eyes as their bug 4300, i.e. http://www.gwmicro.com/betacentral/bugs.php?bugFunction=showSpecific&bugNo=4300&thisBetaNumber=1188565584

[becky]

Moving to 1.1 since current solution is accessible. Would like to get into 1.0 if possible but need #4413 fixed first

[becky]

(In [12144]) fixes #4411, #5134 refs # 5133, #4025. Focus now goes to the first focusable item when a dialog or tooltip dialog is opened. If there is no focusable item, focus remains on the dialog or tooltip dialog container.