I have a text input field on a website that people have found confusing. To use it you have to hit the enter key on your keyboard, but since the mobile keyboard shows a return button people think it means new line and not submit.
I noticed that flutter has textInputAction property that can be changed, I was hoping that there may be something similar in html, css, or js that has similar fine grained control.
The only thing I have found is that type="search" guarantees a button that won't be return. This is a possible solution as the button I see for search fields is a generic checkmark, but I'd like to avoid mislabeling my input type. As well I'd like to avoid a magnifying glass icon which I believe has been and may still be used for some devices.
Related
I'm used to pressing Enter inside any form control (except <textarea>) to submit the form. This even works on checkboxes.
When running NVDA or JAWS though, they both intercept Enter when focusing a checkbox to toggle them - something which usually is possible only with the Space bar on the keyboard!
I guess this is because neither NVDA nor JAWS enter focus mode when focusing (sic!) checkboxes, similar to links and buttons. But I think this is strange, as for example radio buttons do trigger focus mode! So I think that checkboxes should trigger focus mode, too, even though they do not offer any advanced interaction (eg. arrow keys).
I tested some other special keys, and obviously Up/Down/Left/Right are intercepted, as they are used for navigation (line by line or character by character). But for example, Esc is not intercepted. So just out of interest: are there any other peculiarities like this, namely keys that are used by screen readers in a way than in keyboard-only interaction?
Well, I don't think the Enter key behaviour will ever gonna change, and that's alright. But it's good to be aware of such edge cases and peculiarities. 🤔
I know that for JAWS, the Enter key is used to toggle Forms mode (i.e., the mode to interact with a form field). Forms mode will restrict movement of the virtual cursor using the arrow keys, whereas if the user is not in Forms mode then they are free to read the page with the virtual cursor without accidentally changing any form field values or interacting with components.
It's also worth considering that many screen reader users would not want to inadvertantly submit a form without having reviewed the information first, so JAWS intercepts the Enter key as a way of preventing this from happening.
You're right in that most form fields do automatically toggle Forms mode when the field receives focus, and that's default behaviour. But some users prefer to manually toggle Forms mode themselves by using the Enter key.
EDIT: this feat is impossible. since then I have given up. I shall not delete this question, but rather leave it up right here so future users can see a relevant result to their query on google regarding a similar thing
Goal: Either make a textarea bring up the virtual keyboard when focused(with js) OR make a input[type=text] have multiple lines AND bring the virtual keyboard
(I believe answered here but with unsatisfactory results.) (If anyone knows of fully compatible ways to multiple-line-ify an input[type=text] please tell me)
Expected results: virtual keyboard popup when focusing the input OR textarea fields (via javascript with no user trigger).
Real results: caret appears in text field but keyboard remains unseen.
Here's what I'm trying on a textarea:
document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent(click);
Please don't make irrelevant comments about my code organization
#WaisKamal can you show me your code since you said it works?
HTML(no CSS):
<textarea>textarea</textarea>
<input type="text" value="input" />
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
You can use inputmode to determine how a virtual keyboard behaves
<textarea>textarea</textarea>
<input type="text" value="input" inputmode='text'/>
<script>
//document.elementFromPoint(document.querySelector("textarea").getBoundingClientRect().x, document.querySelector("textarea").getBoundingClientRect().y).dispatchEvent("click");
document.querySelector("input").focus();
document.querySelector("input").click();
</script>
Edit
I'm still testing this out, it seem to give some mixed results in the jsfiddle that I'm currently testing right now, sometimes it works and sometimes it does not
*Edit 2 *
It seems to have the same results without specifying the inputmode It does not work the first time the page loads but if I click somewhere on the page, it works every time I click run.
I'm only speculating here but it seems like the keyboard does not pop up without the page receiving some user interaction first, maybe this is intentional for security reasons but I didn't find any docs saying so.
As for you other question you can give a div or other container element contenteditable to have multiple rows / any dimensions you want.
-
Here is another questions and some answers to the same problem though a bit old, Show virtual keyboard on mobile phones in javascript
-
All in all it does not seem possible so show a virtual keyboard without some user interaction.
Autocomplete="off" on textarea fields doesn't seem to work as it does with input fields. I couldn't find anything about this on Google. Is there a difference?
Specifically, I have a page that has half normal input fields, and the other half dynimically generated via javascript. When I navigate away from the page and then navigate back, the text that was in the dynamically generated fields overwrites that which is in the normal fields. This only happens when I navigate away and then click back. If I just refresh the page, it doesn't happen. Autocomplete="false" solved this problem for input fields, but it did not for textareas.
The autocomplete attribute or property is limited to input elements, both according to Microsoft description of the feature and according to the HTML5 draft description proposed to standardize the feature. So you should expect browsers to ignore it for other elements, including textarea.
Apparently, autocomplete is not the real question, just an assumed approach, which is a wrong one. But the real problem was not really described.
This is a 2 part question:
1)
click on one of the demo dropdowns on this page. when you tab over to the next input, the text is selected/highlighted in firefox. how can i prevent this from happening?
2) bonus: can you review my code that is hosted on google and tell me what i can improve?
Well, that is just default behavior on Firefox. A possible workaround is to have the input fields execute a JavaScript or jQuery function on select, have the function blur the field (which would deselect the text) and then refocus on the field. Very basic and I'm sure it'd need a couple extra hacks. Unfortunately without scripting, no there is nothing you can do to prevent that.
I honestly recommend that you leave it alone. That functionality was put in place so you wouldn't have to use your mouse when typing into forms, hitting tab would select all the text so you can easily retype it or hit the right arrow key to go to the end of the field. Removing the functionality will only irritate some of your visitors. If they're using the tab key to get to the next field, they probably want that functionality.
I have a site built using JQTouch and want to add the little cross
buttons within text input fields to clear out text on press.
I've tried emulating Google's technique from their google.com iPhone
site. Also I've read about that approach over here
little 'x' in textfield input on the iphone in mobileSafari?...
I have this partially working. But whether and when a press on the
cross button is registered seems unreliable.
I've created minimal code to test this:
with JQTouch -
http://hogtownconsulting.com/clearquery/index.html
without JQTouch (or any other JS libraries) -
http://hogtownconsulting.com/clearquery/index-no-js.html
I'm not certain that it's an interaction with the JQTouch library
that's causing these problems. But the version without JQTouch does seem more responsive to taps on the cross button. Any suggestions on how I can get this feature working
properly would be much appreciated. Thank you, Patrick
You get that little X automatically if you name your input type = search.
<input type=search name=s>
This article will help you plenty.
CSS Tricks for WebKit
If you don't want that input to be a type = search, then you will have to fake it out a bit.
1. create a div and round it using css.
2. put your input in there, and remove webkit decoration, shading etc.
3. put a SPAN with your X image in to the right of the input. add an onclick to that image which clears your field.
<div><input type="text" id="thing"/><span onclick="clrField();"><img src="x.gif"/></span></div>