I have an HTML form I'm custom coding that integrates with a drip (email platform) form. And I'm trying to get it to show a "success" message (e.g. "thank you for signing up to our newsletter".
What would be the best/cleanest way be to adapt the HTML to allow that message after a submit action?
Here's my code so far:
<form class="subscribe-form" form action="https://www.getdrip.com/forms/0123456789/submissions" method="post" data-drip-embedded-form="0123456789">
<div style="width:25vw">
<input class="subscribe-form__input" type="email" id="drip-email" name="fields[email]" placeholder="Email" value="" >
</div>
<button class="subscribe-form__submit" type="submit" data-drip-attribute="sign-up-button">Sign Up</button>
</form>
Thanks!
Start off by creating the message and styling it properly. Maybe something like this...
<form class="subscribe-form" form action="https://www.getdrip.com/forms/0123456789/submissions" method="post" data-drip-embedded-form="0123456789">
<div style="width:25vw">
<input class="subscribe-form__input" type="email" id="drip-email" name="fields[email]" placeholder="Email" value="" >
</div>
<button class="subscribe-form__submit" type="submit" data-drip-attribute="sign-up-button">Sign Up</button>
</form>
<p class="subscribe-form__thanks">Thanks for subscribing!</p>
You could even wrap the thank you in a div if you would like and add a "thumbs up" icon to fill the space.
Once you're happy with your design, add this to you CSS (if you're using SASS/SCSS, you can add it nested within the element):
hide {
display: none;
}
and add that class to your "Thank You" message, like this:
<p class="subscribe-form__thanks hide">Thanks for subscribing!</p>
Now that that's all set up, you simply need to use JavaScript to remove the hide class from the "Thank You" message, and add it to the form, which will reveal the message and hide the form.
I'll use JQuery for brevity, but Vanilla JS will work great too!
$(".subscribe-form__submit").onClick(()=>{
$(".subscribe-form").addClass("hide");
$(".subscribe-form__thanks").removeClass("show");
});
That should all be working as desired - the form should disappear and the message should appear! The animation could be a little jarring, so have a play around with fading then hiding, and matching the height of the two divs to avoid the page having to change size.
This will hide the form, even if the fields are incorrect/incomplete, so you could look into validate.js to improve your usability if you're interested.
NOTE: This method of using the onClick() JQuery selector doesn't guarantee that the user is actually subscribed to the mailing list - your Drip API request could be incorrect, or their API could fail/be offline.
You can look into the Drip API's callback function (https://developer.drip.com/) if you're interested in making sure the user is properly subscribed, however there's no guarantee they will reply in a timely fashion, and so you'd most likely be over complicating things.
Hope this helped!!
Does anybody know how to hint to the Dashlane browser plug-in to leave an <input> text field alone?
For most browser password managers, setting the auto-complete property to off works, Eg: <input type='text' autocomplete='off' />.
For LastPass, this additional attribute is recommended: data-lpignore="true".
I have no idea what this might be for Dashlane. I have noticed that the attributes data-kwimpalastatus="alive" and data-kwimpalaid="xxxx-x" (where xxxx-x is an auto-generated identifier) are added to my page, so this looks like a sensible place to start, but I've not had much joy figuring out the magic incantation...
In case anyone asks, the only other browser extensions I'm using are DuckDuckGo and Google Docs offline, so it's a reasonably safe bet that the datakwimpala* attributes are down to Dashlane.
Does anyone have any ideas??
Thanks!
Dashlane is using the attribute data-form-type to know what type of value it should use to prefill the input.
If you set this attribute with a value "other", it will stop Dashlane from prepopulating your input fields.
See example below :
<input type="text" autocomplete="off" data-lpignore="true" data-form-type="other" />
Note 1: There is also the attribute "data-lpignore" for lastpass, and also "autocomplete" for the rest.
Note 2 : The "data-form-type" attribute can be used to tell Dashlane how to pre-fill as well. There are other values you can use for this attribute like : billing, change_password, contact, forgot_password, identity, login, newsletter, other, payment, register search, shopping_basket, shipping
Daniel from Dashlane here. We recently switched our analysis engine to ML and we have a solution for you. Just add the data-form-type attribute with value "other" to any field you want us to ignore.
For more information, we released a public spec available here.
tl;dr disabling autofill on specific input fields is not supported and not currently on their roadmap.
I spoke to Dashlane's Support just now, here is a shortened summary:
ME: I'm looking for information on how to disable Dashlane
autocomplete for specific form fields, but couldn't find anything at
https://support.dashlane.com/. I've created an example here to
demonstrate and would welcome any help.
DASHLANE: Right now we can only stop Dashlane for a specific page or
website never for specific fields
ME: do you know if there are any plans to allow Developers to disable
autofill for specific fields? My real example is a postcode/zip code
field which has its own autocomplete which lists addresses which match
the postcode you entered - and the dashlane autofill dialog appearing
over the top of it presents a problem to users of our sites.
DASHLANE: I understand how this may affect your Users I'm so sorry,
for now, we don't have it on our roadmap, But I will be sharing your
feedback with our Product Team, who are always looking to integrate
our users' input into their plans for upcoming updates to Dashlane.
ME: Are there any JavaScript variables or other
changes to the webpage we can look for, so that we could disable our
own autocomplete feature for dashlane users? so they're not presented
with 2 which clash? We'd use that information to turn ours off, so the
only one in use would be Dashlane's, which can't be disabled.
DASHLANE: We don't have a "blueprint" of the code in order to provide
any JavaScript code
ME: If some kind of attribute (ideally
autocomplete="off" which seems to be the standard) could be supported
it would be a huge help, this is a cause of abandonment in our
checkout process and I'm sure it must affect other websites as well as
ours. Thanks for your time.
DASHLANE: Let's hope this can be a reality in the future
The example I mentioned is reproduced here:
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8" />
<meta name="viewport" content="width=device-width" />
<title>Disabling Dashlane Form AutoComplete?</title>
</head>
<body>
<h1>Disabling Dashlane Form AutoComplete?</h1>
<p>
As a web developer, how can I instruct Dashlane not to display a prompt to
autocomplete a particular form field?
</p>
<p>
In this example, the Last Name field has
<code>autocomplete="off"</code> but DashLane still displays an autofill
dialog when you focus on that element.
</p>
<p>
Thanks
</p>
<fieldset>
<legend>Example Form</legend>
<form action="https://output.jsbin.com/setopoyawi" method="GET">
<ul>
<li>
<label>
First Name
<input name="first-name" type="text" autocomplete="given-name" />
</label>
</li>
<li>
<label>
Last Name
<input name="last-name" type="text" autocomplete="off" />
</label>
</li>
<li>
<label>
Password
<input
name="password"
type="password"
autocomplete="new-password"
/>
</label>
</li>
</ul>
<button type="submit">Submit</button>
</form>
</fieldset>
<h2>References</h2>
<ul>
<li>
<a
href="https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete"
>https://developer.mozilla.org/en-US/docs/Web/HTML/Attributes/autocomplete</a
>
</li>
<li>
<a
href="https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion"
>https://developer.mozilla.org/en-US/docs/Web/Security/Securing_your_site/Turning_off_form_autocompletion</a
>
</li>
</ul>
</body>
</html>
You don't really provide the code you are working on, so I don't know for sure if this is you are looking for, but when I tried the following code, Dashlane didn't display its icon in the fields, and was therefore no longer able to autofill them.
I just changed the <label>contents: 'Name' becomes 'Enter Name', and 'Address' becomes 'Enter Address'.
I tried successfully it in Chrome, Firefox and Safari.
Let us know if this was helpful for you.
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>Index</title>
</head>
<body>
<form action="#" method="POST">
<label>Enter Name: </label><input type="text" name="name">
<label>Enter Address: </label><input type="text" name="address">
<input type="submit" value="OK">
</form>
</body>
</html>
Had the same problem with a searchable react-select component which stalled (!) the browser when leaving the field. I could only get rid of the grey Dashlane icon in the input field by moving the following button to the left of the input field (it was in the same row right of the input field before). It seems that they identify relevant input fields by checking if there is a button to the right in the same row. I observed that if the button is not to the right of the input field but in the next row, the Dashlane icon also does not appear.
It looks like dashlane tracks the name and the placeholder property of the input, but not the label as far as i know.
Changing the name of the input to something Dashlane would not be able to recognize helped. So instead of "country" i changed it to "cnt", which solved the problem.
Although, if you need to really add these keywords in the placeholder, you might need to get creative.
Making a custom input where placeholder is empty and add a "fake placeholder" on top could be the way?
Facing a strange problem with aria-live="polite", if the loaded content has form controls, like radio buttons or checkbox.
NVDA just reads the text of radio buttons, but doesn't announce anything about which one is selected or checked.
<a aria-label="Click Me" href="#">Click Me</a>
<div id="myForm" aria-live="polite"></div>
Here is the plunker.
Sorry you haven't gotten a good answer yet. Welcome to the world of accessibility.
Your issue isn't with aria-live=“polite” -- it's just the way that NVDA works. So I guess the good news is you did it right. For the following example I changed the default option to "Two Day" so I could confirm what was being read wasn't just the first option.
With your code, I hear:
Click me link
I then press SPACE to activate the link, and I hear:
Choose a shipping method:
Overnight
Two day <-- You want this to say "selected/checked/etc"
Ground
If I tab into the group, I hear:
Choose a shipping method:
radio button not checked Two day
To get your desired behavior I updated your HTML to generate an invisible <span> that contains the text Default is "Two day". Now what I hear is:
Click me link
I then press SPACE to activate the link, and I hear:
Choose a shipping method default is Two Day:
Overnight
Two day
Ground
This is what it looks like (Note the span inside the legend):
<fieldset role="radiogroup" aria-labelledby="shipMethod" id="myFieldSet">
<legend id="shipMethod">Choose a shipping method<span style="display:none;"> Default is "Two day"</span>:</legend>
<input name="shipping" id="overnight" type="radio" value="overnight">
<label for="overnight">Overnight</label>
<br>
<input name="shipping" id="twoday" type="radio" value="twoday" checked="checked">
<label for="twoday">Two day</label>
<br>
<input name="shipping" id="ground" type="radio" value="ground">
<label for="ground">Ground</label>
</fieldset>
You can also get a similar affect by messing around with changing the control focus, but that's a bit un-cool to the user with a screen reader.
This isn't hard to implement and in a way is a kind of elegant in that the users that need the extra help get it without changing it for other users.
Is the title attribute ok to use for accesibility when it comes to 508 compliance?
For example:
<style>
#date_box{width:250px; border:2px solid #AAA;}
input{width:100px;}
</style>
<div id="date_box">
<input title="to" type="text" id="to" name="to" />
<label for="from">from</label>
<input type="text" id="from" name="from" />
</div>
Or is it best to do a hidden label with an absolute position and a negative margin?
When a visual label on a control is redundant it is OK to use a title attribute. The accessible name calculation for form controls includes the title attribute content, so it is now it has been in the past and will continue to be a robust method to provide an accessible name for a control in the limted circimstances where a visible label is not required. There is a WCAG 2.0 technqiue that covers this. This article provides test results and discussion on this technique: Title Attributes as Form Control Labels
The Section 508 rule about forms is rather abstract: “(n) When electronic forms are designed to be completed on-line, the form shall allow people using assistive technology to access the information, field elements, and functionality required for completion and submission of the form, including all directions and cues.”
So the questions here are: If you use a form field without a label, can you ensure that any assistive software gives the user access to the text that is logically a label but placed e.g. into the field as default content and/or in a title attribute? And if you use a label but hide it with CSS, is it sure that any assistive software can still make it available to the user.
I don’t think that anyone can guarantee that for all current and future programs, so it is clearly safest to use a normal label and normal label markup.
I have a page that is rendered through xulrunner service. There is a form and a button under the form.
For accessibility requirement, I forced the focus on the text field within the form when the user navigates to this page. However, sometimes JAWS always reads the Post Comment button label. Sometimes, JAWS reads the aria-label “Enter Comments”.
Here is the code:
<body onLoad="document.addcommentform.comment.focus()">
<input type="textarea" aria-label="Enter Comments" title="{$enterComment}" name="comment" />
<input class="Button" type="submit" value="{$postComment}" />
I also tried to put a visible label on the UI like this. I did more testing and found out the behavior is pretty the same.
<label for="addcommentform">Please enter comment
<form method="get" action="{$self}" name="addcommentform">
<textarea title="{$enterComment}" name="comment" class="commentarea" </textarea>
<input class="Button" type="submit" value="{$postComment}" />
</form>
</label>
I think it is related to this known bug https://bugzilla.mozilla.org/show_bug.cgi?id=133771
But does anybody known any workaround to this issue?
I'm a Jaws user and don't know of a way around this. Since Jaws tends to create it's own model of pages in a virtual buffer things can behave slightly differently then you would expect. To confirm or disprove weather it's a Jaws specific bug I would suggest trying out NVDA an open source and quite good Windows screen reader.