NOT a duplicate of HTML Form Button value is not posted in Safari and Chrome
I have a button that is used to submit a form when it is clicked.
<form method="post" action="<URL>" class="login_form" name="login_form" id"login_form">
... various inputs here ...
<button type="submit" name="signIn" class="cta">
<span class="arrow">Enter</span>
</button>
</form>
The button name is used server-side to determine what action is to be taken (value is not provided because it is not used by the server).
The problem is that sometimes the name is not posted to the server, while sometimes it is. The ratio is about 1miss/6hits.
Many other forms on my website have the same structure, but I found this behaviour only for this one.
It seems to happen only with Chrome.
I tried clicking the button right after the page is loaded and after having waited quite some time after the page is fully loaded. so it seems not to be tied to the rest of the page.
Is this a known bug or could this be caused by something else?
I encountered a similar issue and in my case it was due to a JavaScript that on Form-Submit disabled the Submit-Button (the intention of that is to prevent duplicate POSTs when users double-click).
Disabled form elements are not included in the formdata.
A better way to "disable" it for the intent of preventing double-clicks thus may be setting pointer-events: none or preventing the surplus submits in JS (preventDefault).
It may also explain that it worked "sometimes", as I imagine there is room for a race between gathering the formdata and the button becoming disabled.
In my experience, this kind of error occurs when there is a problem with the coding of the form itself, or some related javascript error. The fact that you have tracked this to a 1 per 6 chance of happening supports this reasoning. What I would suggest is to view your console output, turn on persistent logging, then submit your forms and test. If this is indeed the problem, there will be some sort of error message printed on the console, and you will be able to solve the problem from there.
Related
We have an existing web application with hundreds of input fields through different applications that has been installed at several sites. At this most recent site, however, we have started having an issue with the back button automatically filling in input fields. This is an issue because the only time we allow the back button is if an error occurred in processing. So the flow is as follows:
1) ask user to scan a barcode
2) an error occurs on the back-end and it directs them to an error page with only a back button
3) the user hits back and is directed to the input page, input form is now filled with the previously inputted data.
I know this is some form of caching or browser issue because when I hit the web app from my personal pc, it doesn't do it. But when they use their android scanning devices and if we load it up on the application server, it does.
I have fixed this on a couple of pages with autocomplete="off" on the input fields, but it just isn't feasible for us to change this on each of hundreds of input fields if we can avoid it. I'm looking for some browser or windows function to turn off to disable this.
I have tried turning off all of the chrome autocomplete fields, and I have tried disabling the cache in dev tools with no luck. Is there another way to disable this without using that autocomplete tag?
If inputs are inside form you can put it on form.
If not you've only one option to use a global script to add attribute on each input something like below but it'll put it on every input and I'm not sure if it'll have any side effects for your case:
field.setAttribute( "autocomplete", "new-password" );
Hope it helps.
I'm working on a client project which acts as a resource and support system for vulnerable people. Accessibility compliance has been touted as the absolute highest priority for this site because of the expected users, so we're currently working to meet WCAG 2.0 Level AA as closely as possible.
Currently the code for the login/registration links in the header looks like this:
<div class="profile-summary">
<a class="profile-summary__link" href="/login">Login</a>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
Another developer who is working on the user management system wants to change the login link to be a form containing a submit button. Something (hypothetically) like this:
<div class="profile-summary">
<form action="/login" method="get">
<button type="submit">Login</button>
</form>
or
<a class="profile-summary__link" href="/register">sign up</a>
</div>
This doesn't really sit well with me and it seems like something screenreaders and other assistive software will trip over (e.g. won't read the login option when summarising the page). To my knowledge some of these switch into a 'form mode' when they encounter a form, which would be jarring in this situation.
Are there any detrimental accessibility implications to using a form and button over a plain link in this context?
Thanks!
In this context, the link with href="#" is right out.
Adding a form can be more confusing than anything because it implies a different thing will happen between each of two otherwise similar controls. A form with no fields and only a button is even more confusing to many SR users. That may be a bigger problem than the links.
Remember that not all screen reader users are blind, so if these controls look the same but behave differently that is also an issue.
Without seeing what these two controls do, it is hard to offer specific advice about which element is the right choice.
Here is generally the way I approach this question...
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an <input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This had better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead. I tend to prefer <input type="submit"> as I find it runs into fewer conflicts (both mentally and stylistically) with developers.
Keyboard User Consideration
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I have a CodePen demo that shows this in action: http://s.codepen.io/aardrian/debug/PZQJyd
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
For reference: http://adrianroselli.com/2016/01/links-buttons-submits-and-divs-oh-hell.html
For accessibility purposes I need to make 'errors' that are displayed be read immediately after the page refreshes.
Currently I have role="alert" and tabindex="-1' on the div that contains the error. This works fine in Google Chrome, but it appears neither IE or Firefox support what I've done.
In Chrome the user is presented with a login page with both a username/password field. The user 'Submits' the form without filling out any information. The page refreshes with the error below and NVDA immediately reads the error. (I understand real time validation would be good, but that will be done at a later time)
<div id="notification_block">
<div class="alert alert-danger" role="alert" aria-labelledby="alertHeading" tabindex="-1">
<h2 id="alertHeading">Error: Login Failed</h2>
<div>Invalid username/password combination. Please verify that your information is correct.</div>
</div>
</div>
Any ideas how I can get this to work in IE and Firefox?
Instead of using role="alert", I would just set the focus to the div on page load. This will cause it to reliably be the first thing that will be read out and it's a pretty common solution to this.
Add the aria attribute aria-live="assertive" to the error throwing div. This way all screen readers will be able to read all dynamically appearing contents.
The only way you can get this to work is to essentially delay the insertion of the content into the alert role until all the announcements for the page have been completed. There is no way to determine programmatically when this happens, so you should:
wait for page load,
set a timeout (say 500 ms)
when timeout fires, insert the content into the alert
This will increase the likelihood that the content is announced
I currently have a form like so:
<form action="#">
<select {if $isPostRequest}disabled="disabled" {/if}size="1" name="locale"
onchange="location.href={if $languageToggleNoUser}'{$currentUrl|escape}{if strstr($currentUrl, '?')}&{else}?{/if}setLocale='+this.options[this.selectedIndex].value{else}('{url|escape:"javascript" page="user" op="setLocale" path="NEW_LOCALE" source=$smarty.server.REQUEST_URI}'.replace('NEW_LOCALE', this.options[this.selectedIndex].value)){/if}" class="selectMenu">{html_options options=$languageToggleLocales selected=$currentLocale}</select>
</form>
It currently causes a WCAG 2.0 error, as all forms need a submit button.
I'm wondering how I could change this code to include a submit button. The code for the onchange option is quite convoluted, and I don't understand it.
Thanks.
WCAG 2.0 does not require to have a submit button. What you link to is a technique, which is informative (not normative), and it’s only one of possibly many ways to achieve the guideline 3.2.2.
So it can be conforming to have no submit button, for example when
the user has been advised of the behavior before using the component
Related technique: G13: Describing what will happen before a change to a form control that causes a change of context to occur is made
The important thing to note here is that a change of content does not immediately mean a change of context.
From a 3.2.2 guideline perspective, your select box is highly likely to be perfectly fine.
A change of context means a really drastic change. Something like when the user selects an option in the select box, focus is shifted to a different section of the page. Also things like causing a full page refresh or opening a new tab will also fail this criterion.
WCAG "change of context" definition
major changes in the content of the Web page that, if made without user awareness, can disorient users who are not able to view the entire page simultaneously
Changes in context include changes of:
user agent;
viewport;
focus;
content that changes the meaning of the Web page.
Note: A change of content is not always a change of context. Changes in content, such as an expanding outline, dynamic menu, or a tab control do not necessarily change the context, unless they also change one of the above (e.g., focus).
Example: Opening a new window, moving focus to a different component, going to a new page (including anything that would look to a user as if they had moved to a new page) or significantly re-arranging the content of a page are examples of changes of context.
So if all you are doing is modifying some content elsewhere on the page and not messing around with the users focus point, you are doing everything just fine from a 3.2.2 guideline perspective.
You are currently failing in another way though
There is one thing that is causing your select box to fail accessibility. It is lacking a label. This is a fail against guideline 2.4.6 Headings and Labels. The lack of a label means that users will not know what the select box is for.
<form action="#">
<label for="unique-id">Label for select box</label>
<select id="unique-id" {... all that other junk ...}>
{...<option> elements...}
</select>
</form>
I have a form built in Joomla 2.5 and ChronoForms, the form validation been done using MooTools. However in Chrome browser when I click multiple times the submit button, that many number of records get saved. This is not the issue in Mozilla or IE.
Is it a Chrome specific issue??
How can i disable the submit button on success of the validation??
Any feedback or solution is appreciated.
Regards,
happy coding
I figured this by adding a JavaScript code, which disabled the submit button after it was clicked and there were no validation error.
I had to modify some of the files from chronoform library to do this because when i added a normal JavaScript code, it used to disable the button after the submit button click, it did not check if the validation was fired or not, So, if the validation was fired i was not able to correct the validation error because it disabled my submit button.
Maybe check this "Prevent Double Submit" thread on the ChronoEngine forums:
http://chronoengine.com/forums/viewtopic.php?f=2&t=22439