missing focus events when using InlineEditBox

[ptbrunet]

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.

[ptbrunet]

Status on 6/27:

• fixed first bug (wrapping <input>, no focus when cancel pressed)
• fixed second bug (wrapping <textarea>, no focus on edit text when box opens)
• fixed new third bug (<textarea>, tab out of textarea, move focus to button)
• more new bugs (<textarea>):
  • when on cancel button, tab/sh+tab to text
    • press tab, tab is entered into text area (keypress interceptor not fired)
    • press any letter, save button is not activated
  • sometimes yellow background missing in inline mode, i.e. when no edit box
  • when edit box first appears it has a horiz scroll bar
• Notes:
  • FF only problems, most likely due to use of iframe for FF
• Other todos:
  • make sure waiRoles are correctly set
  • test with Window-Eyes and JAWS

[ptbrunet]

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.

1. 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".
2. 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".
3. 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
• div
  • div
    • button
• 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.

[ptbrunet]

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:

1. 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.
2. 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:

1. 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?
2. 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.
3. 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?
4. 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:

1. Change the code to use just a native <textarea>.
2. Change the code to use a <textarea> but one that grows but doesn't shrink (FF has problems with shrinking).
3. Document the problem and wait for fixes in FF or Window-Eyes.

[ptbrunet]

Today I reworked Textarea.js to not cause a change in _FormWidget.js and sent Becky a new patch.

[ptbrunet]

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.

1. 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.
2. 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.

[bill]

(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)

[bill]

(In [9637]) Prevent strange error about "]". Removed the onClick(/*Event*/ evt) callback. (If we need a callback when editing is started should probably be called something different, and doesn't need to be passed the event object.) Refs #3482, #3648, #3655, and #3674.