Opened 13 years ago
Closed 13 years ago
#4411 closed defect (fixed)
When tooltip dialog gets focus, focus needs to be on a component
Reported by: | ptbrunet | Owned by: | Becky Gibson |
---|---|---|---|
Priority: | high | Milestone: | 1.1 |
Component: | Accessibility | Version: | 0.9 |
Keywords: | Cc: | [email protected]… | |
Blocked By: | Blocking: |
Description
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.
Change History (7)
comment:1 Changed 13 years ago by
Summary: | When dialog gets focus, focus needs to be on a widget → When tooltip dialog gets focus, focus needs to be on a component |
---|
comment:2 Changed 13 years ago by
Component: | Dijit → Accessibility |
---|---|
Owner: | set to Becky Gibson |
comment:3 Changed 13 years ago by
comment:4 Changed 13 years ago by
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
comment:5 Changed 13 years ago by
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
comment:6 Changed 13 years ago by
Milestone: | 1.0 → 1.1 |
---|
Moving to 1.1 since current solution is accessible. Would like to get into 1.0 if possible but need #4413 fixed first
comment:7 Changed 13 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
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.