We Keep Coding

Preventing keyboard dismissal on form submit on mobile view of web app

I am creating a PHP Javascript chat application. Whenever I click on send button it simply slides down / dismisses the keyboard. If I need to send a new message I again have to tap on the textarea field to make the keyboard slide up / appear for typing. This unwanted keyboard dismissal after every send is annoying. I haven't included any code here as this is not a coding bug that is occurring from my script. This seems to be the default behavior of the web apps that dismisses the keyboard when the form's submit button is clicked.
The gif below shows what is happening. How can I prevent this default behavior?
https://gifyu.com/image/ABYn

The problem here is every time you click on the send button, the textarea loses focus. Once the textarea loses focus, the on screen keyboard has no reason to be visible. You can solve this by adding a javascript code to your click event so that the on screen keyboard remains there every time after the submit button is clicked.
You can use something like:
const form = document.querySelector(".typing-area"),
inputField = form.querySelector(".input-field"),
sendBtn = form.querySelector("button");
// PREVENT FORM SUBMISSION BY PAGE REFRESH (THE DEFAULT BEHAVIOUR)
form.onsubmit = (e)=> {
e.preventDefault();
}
// ADD FOCUS TO INPUT FIELD BY DEFAULT (ON PAGE LOAD)
inputField.focus();
// PREVENT INPUT FIELD FROM LOOSING FOCUS AFTER SEND BUTTON IS CLICKED
sendBtn.onclick = ()=> {
inputField.focus();
}

Focus disables mouse click

I have some text-areas in a web page and I have used the below code snippet to focus on textarea which was required as textarea was not allowing to enter text in itself. But using below code not allowing user to click and add text any where in between already entered text. User is only able to go through the arrow keys but not using the mouse. Do we have any hack to fix it?
$('textarea').on('click',
function () {
$(this).focus();
});

Could you only call focus if the textarea is empty?

Enter on IME menu in IE, triggers keyup event on input

I have an input on web page, which triggers search my hitting enter.
On GWT it looks like this
box.addKeyUpHandler(new KeyUpHandler() {
#Override
public void onKeyUp(KeyUpEvent keyUpEvent) {
if (keyUpEvent.getNativeKeyCode() == KeyCodes.KEY_ENTER) {
client.executeSearch();
}
}
});
When user from Japan uses IME:
He enters a word, hits space twice and sees a menu where he needs to chose the desired spelling.
Menu looks like this
In Chrome and FF it works fine, but in IE, when user hits enter on desired spelling, keyUp handler on input is triggered.
So what I need is to preserve IE from triggering this ENTER on IME menu.
Any suggestions?

I switched KeyUpHandler to KeyDownHandler.
As far as I understand, pop-up menu is hiding by KeyDown event, so KeyUp was triggered on text Input.

Hiding soft keyboards on mobile devices when using contenteditable divs

I am using contenteditable divs for a page to be viewed by mobile devices to get input for some stuff. I want the soft keyboard to hide when the user presses enter, instead of the normal action of enter in a div. My first attempt at getting it to work looks something like this:
if event.keyCode == 13 #enter
event.preventDefault() #to prevent the normal behaviour of enter
#$("#the_editable_div").blur()
However, it seems like this does not work as it would with an input. The div loses focus but the keyboard does not hide on either iOS or android.
I have also tried the solution at Closing keyboard on iPad in div contenteditable but found that it did not work. If I focus on another text field and blur on iOS stuff it still does not close the keyboard, and on android I have found that it changes the keyboard to one used for regular fields, where pressing enter again will close the keyboard, but that is not the expected behaviour of it closing immediately when enter is pressed in the contenteditable div field. This seems strange to me since if I were to tap on that input field myself and then blur it via javascript then the keyboard closes properly.
Is there a way to have a contenteditable div that closes the soft keyboards on android and iOS devices when enter is pressed when that div is focused?

This workaround works fine, at least with Android (I can't test on iPad) :
<input type="text" id="ghostInput" style="position:absolute;top:-50px" />
<div id="myDiv" contenteditable="true" style="width:100%;height:100px;background-color:yellow"></div>
<script>
var ghostInput = document.getElementById("ghostInput");
ghostInput.onfocus = function () {
ghostInput.blur();
}
document.getElementById("myDiv").onkeydown = function (e) {
if (e.keyCode == 13) ghostInput.focus();
}
</script>

Override default Tab Behavior to keep focus on browser form

I'm building my first application where I have to have compliance with keyboard navigation for accessibility reasons.
My problem has to do jquery-ui modal dialog boxes. If the user presses tab on the last control of the dialog (cancel button for this app), focus goes outside of the dialog box. Or presses shift-tab on the first control in the dialog box.
When the user does this, it isn't always possible to tab back into dialog box. IE8 and FF8 behave somewhat differently in this respect. I've tried to capture the tab key with the following event handler -
lastButton.keydown(function (e) {
if (e.which === TAB_KEY_CODE) {
e.stopPropagation();
$(this).focus();
}
});
But this doesn't work as it appears the browser processes the key press after jquery is done.
Two questions -
For Accessibility compliance, do I even have to worry about this? Although, for usability reasons, I think that I should.
Is there a way to make this work?

My problem has to do jquery-ui modal dialog boxes. If the user presses tab on the last control of the dialog (cancel button for this app), focus goes outside of the dialog box. Or presses shift-tab on the first control in the dialog box.
... and then tabbing occurs below the modal box, under a grey semi-transparent layer with scrollbar jumping from bottom to top after a few keypresses? Yes, this is a concern for sighted users who use the keyboard to browse and won't know how to go back to the modal box without pressing Tab a hundred times. Blind people won't even know the modal box is still displayed (they still can see/hear the entire DOM with their screen reader!) and that the page/script is waiting for a submit or cancel decision so it's also a concern for them.
An example done right is shown at http://hanshillen.github.com/jqtest/#goto_dialog (click on Dialog tab, direct link with anchor doesn't work :/ ). It'll tab forever inside the modal box till you click on Close or OK and will put you back on the focused element that triggered the modal box (I think it should focus the next focusable element after leaving the modal box but nevermind, this isn't the biggest accessibility problem here).
This serie of scripts is based on jQueryUI and are highly improved for keyboard and ARIA support and any accessibility problem that could exist in the original scripts. Highly recommended! (I tried to mix jQuery UI original scripts and these ones but didn't manage to get anything working, though you don't need to do so: these scripts work fine by themselves)

Maybe you should prevent the default action with preventDefault() instead of stopping the propagation and use keypress instead of keydown.
In this way there should be no need to regain focus.
Stopping the propagation doesn't work because it just prevent the event from bubbling up. You could think about using stopImmediatePropagation() but i think that changing input on the pression of the tab can't be stopped that way and preventDefault() is more correct.
lastButton.keypress(function (e) {
if (e.which === TAB_KEY_CODE) {
e.preventDefault();
}
});
fiddle here: http://jsfiddle.net/jfRzM/

Im a little late to the party, but I found I had to call preventDefault in the other keyboard events as well.
ex) I was setting the focus in the keyup event. But the browser was still doing its thing in either keydown or keypress. So I had something like this (I used JQuery/Typescript, but the idea should translate to about anything):
elem.keyup(this.onDialogKeyPress);
elem.keydown(this.onDialogPressPreventDefault);
elem.keypress(this.onDialogPressPreventDefault);
...
private onDialogPressPreventDefault = (e: KeyboardEvent) => {
const keys = [9, 27];
if (keys.includes(e.which)) {
e.preventDefault();
return false;
}
}
private onDialogKeyPress = (e: KeyboardEvent) => {
// Tab
if (e.which == 9) {
e.preventDefault();
// Do tab stuff
return false;
}
// Esc
else if (e.which == 27) {
e.preventDefault();
// Do Esc stuff
return false;
}
}