#3482 closed defect (fixed)
missing focus events when using InlineEditBox
Reported by: | ptbrunet | Owned by: | ptbrunet |
---|---|---|---|
Priority: | high | Milestone: | 0.9 |
Component: | Accessibility | Version: | 0.9 |
Keywords: | Cc: | ||
Blocked By: | Blocking: |
Description (last modified by )
Open an InlineEditBox which wraps an <input>. Activate the Cancel button. No focus event is fired.
Open an InlineEditBox which wraps a <textarea>. There is a focus event missing when the textarea opens up. Also, if you click on the text area to give it focus, the focus is not on the text area but on a pane two levels above the textarea.
Change History (11)
comment:1 Changed 14 years ago by
Component: | Dijit → Accessibility |
---|
comment:2 Changed 14 years ago by
Owner: | changed from pbbrunet to ptbrunet |
---|
comment:3 Changed 14 years ago by
Description: | modified (diff) |
---|
comment:4 Changed 14 years ago by
comment:5 Changed 14 years ago by
Milestone: | 0.9beta → 0.9 |
---|
comment:6 Changed 14 years ago by
I think there are bugs in FF related to dojo textareas.
The problems are:
- When the fieldset is open there are two tab-able objects associated with the text. When one (object A) has focus it shows the caret and any keyboard input, but doesn't fire a focus event (firebug doesn't see it but W-E sees focused fired on a PANE object). When the other (object B) has focus it fires a focus event (which firebug sees and which W-E sees as a TEXT object) but there is no caret, and keyboard entry is not displayed.
- It takes two tabs to get through the text when going forward, object A then object B.
- It takes one tab when going backward. It's object A (keyboard feedback but no focus event).
The behavior I see are covered by three cases. All Window-Eyes behavior is with browse mode off.
- Press enter on the inline text object to open it. The dojo code calls focus() on the iframe. (Firing focus on nodes below it doesn't work.)
- Object B gets control. There is no visible caret. Window-Eyes reads: (no acc name), full contents, "edit box".
- When the fieldset is already open, tab into it from the control above.
- Object A gets control. There is a visible caret. W-E reads: acc name (wyciwyg://45/http://localhost/dijit/tests/form/test_InlineEditBox.html), first line, (no role)
- Press tab again, no movement out of the text. Object B has control. W-E reads: acc name (as above), full contents, "edit box".
- When the fieldset is already open, shift tab into the text from the save or cancel button.
- Object A gets control. Same behavior as listed above.
Using Firebug I watched events related to when focus was moving into, out of, or within the text area and at three different nodes, the top level html node, the iframe, and the html node inside the iframe. These notes were taken with the fieldset open. I also watched for events at the body and div, both below the html node and saw no events.
- events on html node at top
- no focus event is logged moving into or out of the text (but there are blurs from the adjacent controls)
- events on the iframe
- When tabbing backward with shift tab into and then out of the text I see nothing fired. When going forward with tab into and out of the text it takes two tabs to get through the text area. I see a caret and can enter text after pressing the first tab (but there are no events). After pressing tab again (am still in the text) the caret disappears and but now I am seeing the keyboard events but not the focus event. These keyboard events are probably bubbling up from the html node (see next bullet).
- events on the html node inside iframe
- When tabbing backward with shift tab into and then out of the text I see keystrokes but no focus. When going forward with tab into and out of the text it takes two tabs to get through the text area. I see a caret and can enter text after pressing the first tab. I also see keystroke events, but no focus event. After pressing tab again (am still in the text) the caret disappears and but now I am seeing all the events (focus, all key presses, and blur when tabbing out).
I have a tabindex and waiRole="textarea" on the iframe.
Here is the DOM layout:
- fieldset
- div
- fieldset
- iframe #document html head body div #text br
- textarea
- fieldset
- div
- div
- div
- button
- div
- div
- div *button
This patch for this bug fixes the following problems:
- InlineEditBox.js: When save or cancel is pressed put focus back on the InlineEditBox
- Textarea.js:
- Cleanup setting of waiRole="textarea" and tabindex.
- When the fieldset is opened put focus on the text area (as best can do considering the FF problems listed above)
I think these are the only problems remaining:
- 3576 - save button gets focus when it's disabled
- The FF double object problem and related side effects.
comment:7 Changed 14 years ago by
Status as of 7/3:
I sent a patch to Becky. I think I've gotten dojo Textareas about as far as we are going to get them for now. I think further progress with need fixes in either FF and/or Window-Eyes and/or an architecture fix (more below). The patch will fix the following problems:
- InlineEditBox.js: When save or cancel is pressed put focus back on the InlineEditBox
- Textarea.js:
- Cleanup setting of waiRole="textarea" and tabindex.
- When the fieldset is opened put focus on the text area.
Notes:
- I had to change setValue in _FormWidget.js from using focusNode to editNode. Textarea for FF needs to use a focusNode that is iframe.contentWindow. Using editNode works OK. For FF, editNode is the div in the iframe. And in any case it seems like using editNode would be the right thing to be setting the valuenow attribute on.
- I removed tabindex from the <textarea> tab in the last branch of the template in Textarea.js. Don't textarea's already have a tabindex?
These problems remain:
- The DOM structure for the textarea widget looks like this:
...fieldset iframe #document html body div #text
When you tab into the widget, FF fires focus from the document object. I can see this by adding JavaScript event listeners. The problem is that I can't put a waiRole on a document object so Window-Eyes can't announce that the document object has a waiRole of textarea.
The user experience is that they will come to a button (the inline text), activate it, and hear the first portion of the text they heard when they encountered the button. They don't hear the role because the role is PANE and ATs typically don't announce roles of PANE. Without the role information, I think most users will be lost at that point.
I think this issue has enough severity that we should try to fix it. We could either allow waiRoles on document objects or have the ATs look for a waiRole on the html tag. Are either of those two options feasible, or is there some other option? - When in browse mode the text area widget is invisible. Is this because it has role PANE? I think this is serious enough that it should be fixed.
- In order to allow the user to tab out of the textarea widget we have keypress handler on the iframe document. In order to move focus to the next widget that handler then fires focus on something higher in the tree, currently the iframe. A second tab is then needed to move focus to the next widget. I've tried all sorts of combinations of firing focus on various objects and putting the tabindexes of various objects into various states with no improvement. This a fairly minor bug, but it would be nice to fix. Any thoughts?
- If the user tabs into the text widget after the first time you hear the acc name of wyciwyg://13/http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_InlineEditBox.html It would be nice to have Firefox use something more user friendly. This is a minor issue, but again would be nice to fix.
I think the first two are severe enough that we need a plan. As we talked about last night, the options are:
- Change the code to use just a native <textarea>.
- Change the code to use a <textarea> but one that grows but doesn't shrink (FF has problems with shrinking).
- Document the problem and wait for fixes in FF or Window-Eyes.
comment:8 Changed 14 years ago by
Today I reworked Textarea.js to not cause a change in _FormWidget.js and sent Becky a new patch.
comment:9 Changed 14 years ago by
Status on 7/6
I discovered something today that allowed me to get the Textarea code to a point where I think it's accessible enough to be usable. I gave the iframe's document a title (in the head section), the name of which is similar to a role name, i.e. "edit box". (Window-Eyes uses role names of "edit box", JAWS uses "edit".) The document's title is used as the document's accessible name. Since FF fires focus from the document, and we can't put a waiRole on a document, the AT will not speak the role (because the role is PANE) but it will speak the accessible name (plus the text contents). The accessible name of "edit box" will give the user enough of a clue that they will not be lost. This also fixes a second problem. The accessible name was set by FF by default to a cryptic name, e.g. wyciwyg://13/http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_InlineEditBox.html Hearing "edit box" is going to be a lot nicer than hearing that.
This workaround adds a work item to the i18n team because "edit box" needs to be translated. Is there a dojo coding practice that I should use to separate out the string?
The attached patch also includes one more fix. I added editNode to the dojoAttachPoint in the last branch of the template. When experimenting with using a native textarea in place of the iframe code, the code crashed because there was no editNode.
I sent a patch to Becky. It includes these fixes:
- InlineEditBox.js: When save or cancel is pressed put focus back on the InlineEditBox
- Textarea.js:
- Various cleanup of the setting of waiRole="textarea" and tabindex.
- When the fieldset is opened put focus on the text area.
- Removed tabindex from the <textarea> tab in the last branch of the template. Don't textarea's already have a tabindex?
- Added missing dojoAttachPoint=editNode to the last branch of the template.
- Added title of "edit box" to head section of the iframe.
- The title is used as the accessbile name and this compensates for the missing waiRole.
- This title also overrides the cryptic name provided by Firefox.
These problems remain, but are now lower priority.
- We need to be able to put a waiRole on a document object. If that is not possible we need to put it on a lower level node and document what the ATs need to do to find it. However, there is a workaround as mentioned above.
- In order to allow the user to tab out of the textarea widget we have keypress handler on the iframe document. In order to move focus to the next widget that handler then fires focus on something higher in the tree, currently the iframe. A second tab is then needed to move focus to the next widget. I've tried all sorts of combinations of firing focus on various objects and putting the tabindexes of various objects into various states with no improvement. This a fairly minor bug, but it would be nice to fix.
comment:10 Changed 14 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
(In [9636]) Bunch of fixes for keyboard support in InlineEditBox?.
Fixes #3482: missing focus events when using InlineEditBox? Accessibility Fixes #3648: Regression in [9508]: no cancelling if autoSave=true (added support for the Esc key.) Fixes #3655: Open inline edit box, don't make change, tab out, edit box stays open Fixes #3674: pressing tab on an open autosave widget should move focus to next widget
Patch from Pete Brunet (IBM, CCLA on file)
Status on 6/27: