1425639 - Using tab inside textarea element sets focus on Reset button

Status: RESOLVED FIXED

(Developer Documentation Graveyard :: General, defect)

Description

[yk3b.bw.ggxwkimobz]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
Build ID: 20171206182557

Steps to reproduce:

1. Open a JavaScript learning page e.g.: https://developer.mozilla.org/en-US/docs/Learn/JavaScript/First_steps/Arrays
2. Find first <textarea> box; a text box with "Reset" and "Show solution" buttons under it.
3. Click with your mouse inside the box until text cursor starts flashing in there.
4. Press Tab.


Actual results:

Pressing Tab sets focus on Reset button under the text box.


Expected results:

Tab should have inserted a tab inside the text box.

Comment 1

[Chris Mills [:cmills]]

Hi there!

I have updated the code of the example found in

https://developer.mozilla.org/en-US/docs/Learn/JavaScript/First_steps/Arrays#Active_learning_Printing_those_products!

to:

1. Hide the JSFiddle/Codepen buttons, as they really aren't needed and didn't work very well when they were there.
2. Make it so that pressing the Tab key while inside the textarea creates a Tab rather than tabbing to the reset button. I am not sure about this one — it fixes the problem but also creates an accessibility trap, as keyboard-only users can't then escape from the textarea. I'm not sure what would be best to do here. Any thoughts?
3. Make it so that the Show solution button now toggles between show/hide solution. Any changes made to the user code or solution have their state saved independently, until Reset is pressed, when both are reset to their initial states. Does that behaviour work for you?

Let me know if there was anything else you were expecting here, or if you had any more suggestions. Once this is worked out, I can roll it out across the other interactive examples.

Comment 2

[yk3b.bw.ggxwkimobz]

1. Fair enough.
2. Yeah, it works. For accessibility could simply bind a special keyboard combination for jumping out from the edit field. And ofc, let the end user know of the keyboard combo's presence. The question is, what exactly to implement; what should the keyboard combination be capable of doing; should it work as substitute to Tab, including Tab+Shift, or should it do something else... w3school's Tryit Editor doesn't seem to have any specific solution for that disability either...
3. Great!

The updates work for me.
Although I finished studying JS on MDN, few suggestions still haunt in my mind, but for other areas in MDN.

Comment 3

[Chris Mills [:cmills]]

(In reply to yk3b.bw.ggxwkimobz from comment #2)
> 1. Fair enough.
> 2. Yeah, it works. For accessibility could simply bind a special keyboard
> combination for jumping out from the edit field. And ofc, let the end user
> know of the keyboard combo's presence. The question is, what exactly to
> implement; what should the keyboard combination be capable of doing; should
> it work as substitute to Tab, including Tab+Shift, or should it do something
> else... w3school's Tryit Editor doesn't seem to have any specific solution
> for that disability either...

OK, I've added an option to remove focus from the textarea by pressing the Esc key - seemed like a logical choice to me. I have also added a short paragraph to tell them about it. I am pretty happy with this now.

> 3. Great!
> 
> The updates work for me.
> Although I finished studying JS on MDN, few suggestions still haunt in my
> mind, but for other areas in MDN.

Please share your ideas - we are always happy to receive useful feedback.