To my knowledge, read-only fields are used primarily by keyboard-only users so they can focus on the input and copy/paste containing value. But what about fields with no value? Should those be treated as disabled since they don't carry any information to the user and from that point of view, it's same like having a disabled button.
Edit:
Those fields are metadata from various sources and if they are empty, most likely it's not even important what they represent because it doesn't add any value to the context, if they can't be updated.
Short Answer
No they should be left as readonly.
Long Answer
You need to think about when to use each one:
readonly
readonly fields are to display information back to people.
If that field happens to be blank it should still be returned as people can see that the field exists and contains no information.
This is the same for people who use a screen reader, they get to the field, see it is readonly, get the field announced and that it is currently empty. All useful information.
This information will automatically be read out when the form is being read back as well which is useful.
disabled
disabled, however, implies that the field cannot be modified at this moment.
Some screen readers do not read these out by default unless you specifically focus the field with JS etc.
VoiceOver will skip disabled fields - this is not useful if you need the information to be accessible (for example if this is confirmation of previously entered information, skipping an entire field could cause confusion and cause people to go back to check they hadn't missed something on the form).
So which should you use for an empty field?
readonly if this is relaying information back to a user. They can still focus the field, hear the field label and that it is empty.
disabled if this control currently serves no purpose on the page (and is not likely to!) as it will be skipped entirely.
disabled should be used with caution due to the point I mentioned earlier that some screen readers (VoiceOver) will skip disabled fields..
Generally the rule is - does the user need to know that the field was left / is blank - use a readonly. Is this field not going to be used / not relevant while inputting information, use disabled.
If in doubt use readonly, it will cause less harm than an erroneous disabled attribute.
Related
I have an html input field, type text, that is not a password or any type of sensitive information. It is used frequently to put in dollar values. Autocomplete by a browser is annoying because it comes up every time, gets in the way (for some fields this system has its own autocomplete so that's crazy and I disable it there too, though not on this one). The field just requires typing in a dollar value which is different almost every time so autocomplete isn't very useful.
I used the autocomplete="off" on this field.
Then the users mentioned that now when they hit back in their browser, then forward, the value is cleared out. I traced it to this, that's indeed what it does. Other fields keep their values just fine as dictated by the browser's behavior.
Now how to I allow this saving of the value, but disallow the actual autocomplete? This change that came along with autocomplete is unwanted for me. I also don't see it mentioned at all on the w3schools page for autocomplete, but it does it in Firefox and Chrome.
Thanks for any suggestions. The simple thing would be to just allow autocomplete again so I might end up doing that :/
You could keep autocomplete off but create a local storage value that persists that particular fields last value, you could trigger when the value changes. When the page is loaded you would then have a function that checks to see if the value is in local storage and if so populate that field.
Here is an article on using local storage - http://www.thomashardy.me.uk/using-html5-localstorage-on-a-form
I find it intriguing and couldn't find any special reason as to why the cursor should not advance to the next form field when the field type is "drop-down selection" or "radio button". As in both cases logically there cannot be any additional input.
Is there any attribute which can be applied so that the cursor moves on to the next field.
Consider how many forms are filled daily worldwide and how much time being wasted if there is no special reason.
STOP! What you are trying to do will break keyboard users. In fact, any change you make will break somebody's workflow.
Auto-tab should not be used for any field, ever.
Who knows your field is going to auto tab? Nobody. Why? Because that's not what fields do on the web. So, I press tab out of habit to get to the next field, what did I do? Oh no, I've tabbed past the next field, thanks to an unexpected auto-tab. Now I'll just have to tab back.
I'm editing a field, there are enough characters in the field already, I want to overwrite some characters in the field, oh no! I'm being auto-tabbed out of it before I can finish!
I'm a keyboard user, I use the up and down arrows to change the value in a select or radio. These are triggering onchange events every time I press them, even though I haven't finished changing the value to the value I want.
When I want to tab to the next field, I'll jolly well press it myself thanks.
There is a very special reason not to autotab, and this doesn't really waste any time (unless you're developing something for somebody to use constantly for several hours at a time). The special reason is you're following the principle of least astonishment.
Start with attribute tabindex="-1"
JQuery style:
$('.something').each(function(){
this.tabIndex = -1;
});
Ok, I was asking for logic and it looks like I have found a reasonable answer to myself.
The cursor stays there and doesn't auto-tab to the next field as next field type may be a radio field or again a drop-down selection field, where auto-tab cannot take any action for example selecting an option from multiple radio options.
But I still feel that there should be an option of auto-tab depending on where it can be used or where it can be omitted.
Auto tab is an important and needed feature. Why, for example, should I have to press the tab key after entering in my area code before I can type in the next 3 numbers? From a user experience perspective, that's really annoying. I would think there would be an attribute built into HTML5 or CSS3 to accomplish this. I found this thread as I'm looking for it. If anyone has an update, please share.
I have a web application for tagging data and viewing data by tag, so my UI is a list of checkboxes for each tag, a list of checkboxes for each data item, a "Tag" button, which adds the checked tags to the checked data, and a "Filter" button, which ignores the checked data and just displays only the data items with the given tag.
My problem is that the former operation (tagging data) is "obviously" a POST operation, whereas the latter operation (viewing data according to a tag) is "obviously" a GET operation. But the method attribute is attached to the form, not the submit button, so I have to choose one or other for both buttons.
I don't want to make two forms, since as far as I can tell this would force me to duplicate the entire tag list. Is there any way I can choose my method based on the choice of submit button?
A JavaScript solution is permissible, but one without would be preferred.
(I am going to post an answer to this question, but I don't particularly like it, so I would welcome alternatives).
In principle, you could use the formmethod attribute in a submit button, as per HTML5. However, it is not recognized by IE, even in IE 9. The existence of the feature in HTML5 indirectly proves that previous versions of HTML lack a feature for this.
On the other hand, the POST method can be used even for simple viewing that does not cause any changes in the outside world, and in many situations it has to be used for technical reasons (e.g., too much data). So I think the method issue is not very relevant; just use POST.
I would honestly go with a javascript solution, in the onsubmit of the form fire a method which a) checks the submit button that was pressed and b) based on this changes the method of the form.
One possible solution would be to use POST, and then have the server give a 303 See Other header to change it into a GET request. This involves making two requests to serve the purpose of one, which is unfortunate, but at least means that the URL will change so people can link to a specific tag selection.
I agree with javascript solution, proposed by Jon Taylor, the problem is not if your form's method is GET or POST, but how do you filter/validate/sanitize user input. If your concern is related to the fact, that the user can manipulate the form's method, then you should implement solution to that matter on server side.
This might seem like a daft question but the sanitizing of user input continually confuses me, and i would like once and for all to get a definitive answer.
So heres the scenario
Customer fills in web form.
PHP checks that the mandatory fields have been filled in appropriately, if not it doesn't let the customer continue until they are.
If so then the user input is displayed on screen for confirmation, while the input data is also stored as hidden form elements.
Customer then confirms input, the hidden elements are then sent on for further processing.
Working with the principle that data shouldn't be escaped until the last minute, how would this apply to the data stored in the hidden elements at point 3. (Obviously the data printed on screen at this point i have applied htmlentities() too)
Should i use htmlentities on the hidden elements, however this is technically not the last stage as after part 4 i would then be using the variables again before sticking them into a DB or email.
I am fully aware that i might be doing this completely wrong, so any thoughts are very welcome. ^_^
If you're writing out the user's input to the page, it should ALWAYS be escaped. Otherwise there's nothing to stop people adding javascript etc to their input, or to try and escape out of your hidden fields and inject code onto the page. So yup, use htmlentities on the hidden fields too. Just because the user can't see them doesn't stop people from injecting code into them.
autocomplete="off" is not what I am after. Basically, on my registration form there are fields "phone" and "password" placed one above the other. (see screenshot)
The "phone" field gets, annoyingly, prepopulated with a username, as I guess what the browser is doing - the browser finds a field of type password and assumes the text input field just before it is a username field. The effect is this:
Why I am not interested in the non-standard autocomplete attribute for the phone field, is that I do want user to be able to fill this form as easily as possible and if they have previously entered their phone number on other sites (into fields called "phone") they could benefit from this showing up as they start typing into the field. That's why I don't want to turn autocomplete off altogether.
I was thinking more in the direction of reorganizing the fields somehow to avoid this behaviour. Or some way of telling the browser that the field above the password field has nothing to do with it, or that the password field is not used for authentication purposes. Somehow mark it as that. Or inject some invisible element inbetween these two fields?
Any ideas?
Markup used:
<input id="phone" name="phone" type="text" value="" maxlength="30">
<input id="newPassword" name="newPassword" type="password" value="" maxlength="20">
I am getting this behaviour on Chrome, FF, (not sure about IE, got an archaic version of that on my machine, don't even want to start worrying about IE yet.)
Most password managers will search the first password field, and the closest text field before it.
So all you have to do is add invisible text and password fields (display:none) above "new password".
Firefox tries to interpret 3 password fields as a "change password" action, so if you don't want that you should be safe adding yet another invisible password field.
I had a similar issue with the set password field. Try
<input type="password" autocomplete="new-password">
From MDN input documentation:
autocomplete
This attribute indicates whether the value of the control can be automatically completed by the browser.
Possible values are:
....new-password: A new password (e.g. when creating an account or changing a password)
For the phone number issue, I set this and it stopped autocompleting the username there.
<input type="tel">
A home number cannot be 30 characters, this is probably why the browser is assuming it could be a username or login email due to the size. Change it to something real and see what happens.
Also, consider having 3 field for phone number, area code, prefix, suffix. Once a certain number of digits are filled, you can auto focus using JavaScript the next phone segment field so it's easier for user.
Have you also tried changing positions of fields? What's happened?
Also, just to make sure, you can turn off auto complete on a particular item during registration without worrying that it will be off during login (cuz it won't) unless you turned it off for the login fields as well, and of course you have no need to.
Also, delete your unused saved form auto complete stuff, could just be a local issue with your version, you may have entered a bad value one day in one of the browsers, and then you installed the other browser (chrome or FF), and then the newly installed browser copied the rules exactly as they were from your original browser.... So, you end up thinking it's a global issue with your form, simply because of one bad entry and because your second installed browser copied and replicated the bad entry rule from your first browser, making it look like a real, universal problem to you, get me? So try the browsers InPrivate modes, or try the browsers from a different installation or a different computer, or from a virtualpc instance you may have.
Otherwise, export all your setting from your browsers and uninstall both browsers, then reinstall from scratch FF and chrome, then test your webpage, then feel free to import your exported settings back.
Also, test on IE even if it is for the insight it may give you, know what I mean?
Hope this helps, let me know how you get on, and if you have any other questions.
UPDATE:
Given the method you've chosen, what you should be able to do is, when rendering the phone field, add a value=" " attribute into the input tag, instead of using JavaScript. This should prevent the pre-filling from occuring without needing to use javascript. Now, if you want to go one step further, you can do this:
During the OnLoad Event of when page loads, check the phone field using JavaScript, and if the value equals one space (" ") then overwrite it with an empty string using JavaScript once onLoad is triggered. Or, if the browser is still prefilling (i doubt it will but if it is) you can delay this check by a few hundred milliseconds and run the javascript a few hundred milliseconds after the page has loaded, or tie it to all or some of the input fields onFocus events, so as soon as any of the fields gain focus, you do the "does phone.value equals one space character (" ") and if it does, overwrite it with and empty string, i'm even more certain the browser isn't going to jump in and hijack that field in this situation. Although, as mentioned, even if you do this onLoad, i doubt the browser will hijack your field, as the pages/javascript onload occurs AFTER the browsers internal onLoad (DocumentComplete) event occurs, and worst case scenario, you can do the few hundred millisecond lag or onFocus method, but i doubt you will need these.
Let me know how it goes.
I tried disabling the input fields type=text& type=password after loading of the DOM then enabled all the disabled fields after certain milliseconds lets say 100. It seems to be working for me.
Try :
$(document).ready(function()
{
$("input[type=text],input[type=password]").prop('disabled','disabled');
$("body").delay(10,function(){
$("input[type=text],input[type=password]").prop('disabled','');
});
});