Download and install the add-on
An ActiveCampaign account
Setup
Log into your WordPress admin dashboard.
On the left side navigation menu, hover over Forms and click on Settings.
From this page, click the ActiveCampaign tab.
Enter your API URL and API Key. These are obtained from ActiveCampaign on your Account Settings page.
Click Update Settings. If you’ve entered your account information correctly, you will be notified by a green check mark beside each box. If you do not see green check marks next to the credentials, please double check this information and try again.
Once you have entered your API keys, you’re ready to begin creating a feed for the ActiveCampaign Add-On.
ActiveCampaign Add-On Hooks
The ActiveCampaign Add-On provides hooks that can be used to modify the default functionality or extend it. For more information, review the ActiveCampaign Add-On Hooks.
Add-on Framework Hooks
Because the ActiveCampaign Add-On is built using the Add-On Framework it also inherits any hooks available in the framework methods it uses such as:
gform_short_slug_field_value for changing a field value before it is passed to ActiveCampaign.
To begin using the Campaign Monitor Add-On for Gravity Forms, you will first need to add your API key. In this article, we will show you how to retrieve your Campaign Monitor API key.
Log into your Campaign Monitor account.
Click on Account settings at the top of the page.
Click on the API Keys link on the right side of the page to view your API Keys.
SummaryWhere do I log in?How do I log in?Account SectionsYour LicensesYour DownloadsYour Profile
Summary
You Gravity Forms account, hosted on www.gravityforms.com, is the hub for your Gravity Forms licenses, user profile, billing and related resources such as plugin downloads. This article gives a quick overview of the Account section of our website. For more detail on specific actions you can take within each section, check out the articles that are linked below.
A Gravity Forms account is created for you automatically when you purchase, or alternatively you can register one without making a purchase also. Refer to this help guide for more on account creation.
Where do I log in?
From any of our site pages, click the login link at the far right of the top nav.
On a smaller screen or mobile device, the menu may be hidden under the “stack” or “hamburger” icon on the left side of the top of the page.
How do I log in?
In order to access your My Account section, you will need to log in with your account email address (as used when you purchased) and password. If you purchased a new license, you will have had an account created for you automatically. See this article for information on how to create an account.
If you have forgotten your password, you can reset it using the instructions listed in the Resetting Your Password article.
The Remember Me checkbox will save your login information to your computer via a cookie.
If you are already logged in, you will see a blue My Account button next to logout, and that will take you to your account section. Additionally, the top of page will show a welcome message and your name.
Account Sections
Once you are logged in, you will have access to the three major sections of the My Account area within the navigation tabs.
Your Licenses
This area holds information for all your licenses and allows many activities related to your licenses, such as changing payment methods, viewing your receipts, seeing what sites your license is in use on, and much more.
See the Managing Your Licenses area of our documentation website for help with the various actions of the licenses area.
Your Downloads
This area provides access to the latest updates of all our plug-ins and any pre-release betas we have made available, as determined by your Gravity Forms license type. Access to files is available to only active Gravity Forms licenses. If you have multiple active licenses in your account, you will receive access to all the add-ons available to each of those license levels.
See this page for a list of add-ons and the license level they are available with.
Your Profile
Here you can view and manage profile information such as name, account email, and password.
Check out the other articles in our Managing Your Account documentation area for help with the various account area functions.
Logout is a quick link to log out of your Gravity Forms account.
IntroductionLabels and PlaceholdersGuidelinesWhy?ExamplesResourcesGrouping of elementsGuidelinesWhy?ExamplesResourcesTabindexGuidelinesWhy?Color ContrastGuidelinesWhy?ResourcesUse of ColorGuidelinesWhy?AutocompleteGuidelinesWhy?ExamplesDiscussionResourcesKeep Non-Form Information Out of a FormBest PracticeWhy?About aria-describedbyShow Essential Information by DefaultGood PracticeWhy?Announce Dynamic ChangesGuidelinesWhy?Examples of aria-live and role=”alert”ResourcesTime Limits on a Form SubmissionGuidelinesWhy?Form ValidationGuidelinesWhy?Custom Styling for Select, Radio Buttons, and CheckboxesGuidelinesWhy?The ProblemThe SolutionWho is Responsible for the Web Accessibility of a Website?What to Do if you Find an Accessibility IssueValidation and TestingTools For TestingYour KeyboardThe W3C Validation ServiceaXe Developer ToolsOther Automated CheckersJavaScript CheckersAccessibility Checklists and Quick ReferencesResources and Pattern LibrariesLast Takeaway
Introduction
How to create a form that is usable and accessible for most people?How to develop so that your forms comply to the global Web Content Accessibility Guidelines (currently WCAG 2.1 AA)?How to keep your forms accessible while adding CSS and Javascript for special styling of form controls and interaction?What is important to structure your form elements? How to display and announce errors and notifications for everyone?
These are all questions you may have and that we’ve all had about form or web accessibility in general.
The web is accessible by nature. If you use valid HTML5 for your forms; interfaces like a keyboard, a mouse, a screen reader, and voice recognition software already have good access to the functionality of your forms. But HTML5 may not be enough for your application needs and accessibility requirements.
This documentation gives you an overview of what is important to maintain form accessibility and how to validate and test your output. This document will also cover where to find good documentation on components, best practices, and form accessibility.
Please also check our documentation geared towards content managers.
The World Wide Web Consortium (henceforth in this documented referred to as W3C) also provides good information in their Web Accessibility Tutorials on form accessibility in Forms Concepts.
As Gravity Forms extends its accessibility, more and more of the guidelines and good practices will be implemented, so keep an eye on the accessibility mentions in the changelog with each plugin update.
Labels and Placeholders
Guidelines
Every form control needs a visible label and that label needs to be attached to the corresponding form control by a for/id construction.
A label is for text only. Don’t add links, buttons, tooltips or other non-text elements inside a label element. Doing so makes it difficult for people to activate the form input associated with the label with assistive technology. See Accessibility concerns on the MDN page about labels.
A label is not the same as a placeholder. According to the HTML specifications on placeholders: the placeholder attribute is a string that provides a brief hint to the user as to what kind of information is expected in the field. It should be a word or short phrase that demonstrates the expected type of data, rather than an explanatory message.
Place labels and sub labels above or next to the input fields. This is the natural order people read and will prevent confusion.
Why?
When the label is always visible, people don’t forget what they have to fill out when they are typing.When the form inputs are filled with autocomplete, the users can better check if the input is added to the right input field when the label stays visible.If the label is connected to the form control, screen readers will announce the label with the input field, so blind users know what to fill out.If the label is connected to the form control the click target will get larger, because you can click on the label and then the input field will get focus too.The placeholder is used as suggestion on how to fill out an input field. When a user starts typing it disappears, so if it is used as the only label, the user can get confused on what to fill out.
Note: the construction where you visually place the label inside the input with CSS, and move it above the input on focus, is perfectly fine.
Examples
12345678
Make sure HTML IDs are always unique to the page. This is important for assistive technology, so they can target a specific element by its (related) id.
Resources
MDN on labelsMDN on form inputsMDN Learn about forms
Grouping of elements
Guidelines
Group elements that belong together with a fieldset and a legend. This is useful for groups of radio buttons, checkboxes, and related fields for a name or address. A fieldset is a container for the grouped elements, a legend is the description (name) of the group.
Why?
By adding a fieldset and a legend, you add semantic meaning to the elements inside, they belong to each other.Screen readers announce that it’s a group and announce the legend, so blind users understand the context of what they need to fill out or check on the form.
Examples
123456789101112131415161718
Resources
MDN on fieldsets
Tabindex
Guidelines
Avoid using a positive tabindex on form controls. Keep the natural tab order intact.
Why?
Some users can’t use a mouse, this could be because they are blind or their motor skills may be impaired. Users like this can use the keyboard to navigate a website. If you use the tab key you can jump from focusable element to focusable element (like a link, button or a form element).
If you add a positive tabindex to a form element, that element will be the first that gets focus on a page. By doing this you are hijacking the natural focus order of the page, this can be very annoying and frustrating for someone who is navigating the site with a keyboard and just wants to access the main menu and not subscribe to your newsletter on every single page.
Give the user control and don’t decide for them.
Color Contrast
Guidelines
The contrast between text and its background has a luminosity contrast ratio of:
4.5 : 1 for normal text up to 24 pixels3 : 1 for bold text of 19px and larger3 : 1 for normal text of 24px and larger
This contrast rule does not apply to text in existing brand logos, but it does apply for other images with text. Don’t worry, there are numerous color contrast checkers, online, offline and integrated into many design applications.
Since WCAG 2.1 AA the contrast between active user interface components, like borders of an input field and its background has a luminosity contrast ratio of 3 : 1. “Active user interface components” are for example the borders of input fields and textareas.
Note: If you style the CSS for the placeholder text, please keep in mind that some browsers add opacity by default. So with the placeholder CSS also add opacity: 1; to be sure the color is consistent in all browsers.
The placeholder also needs to have a colour contrast ratio of 4.5:1 against its background.
Why?
Not everybody has perfect eyesight. By giving text and borders a good color contrast against its background, you are assuring most people can find and read the text, even with an iPad in the sun.
Resources
Web Axe list of color contrast checkersCSS Tricks Color contrast accessibility toolsMeeting WCAG Color Contrast Guideline 1.4.3: Are You Doing It Right?Understanding Success Criterion 1.4.11: Non-text Contrast
Use of Color
Guidelines
Don’t give meaning to color. Examples of this include only using a red border to indicate a field is required and still needs to be filled out, or refer to a green button in your site copy.
Why?
8% Of all men and 0.4% of all women are color blind, these people could miss the change in color or the meaning it has.
Color also doesn’t mean the same in every culture, for example red is a warning color in Europe but a color of happiness in Japan. Don’t expect and assume people to perceive and interpret color the way you do. It’s ok if you want to add color, just don’t make it the only way to indicate something. For example also add text for an error warning explaining what the error is and how to fix it.
Autocomplete
Note: The autocomplete rules are added in WCAG 2.1 AA: Success Criterion 1.3.5 Identify Input Purpose. If your site needs to comply to WCAG 2.0 AA only, this rule does not need to be met.
Guidelines
Identify the input purpose by adding an attribute with the purpose of the field to the form control. The W3C published a list of input control purposes that serves as a good resource for this.
Note: This is meant only for the own personal information of the person filling out the form.
Why?
This rule is added to help people with a cognitive disability. It can be very useful to have a regulated form of autocomplete so people don’t have to type all of their information again and again for very form. If all forms use the same autocomplete values, it make it easier for browsers to autofill these fields correctly and consistently.
Also this attribute can be useful in the future for assistive technology. For example a specific icon can be added to a label, so it’s more clear what to fill out for people who can not read that well.
Examples
1234
Discussion
Consider carefully which fields you give an autocomplete attribute and which fields you do not. Some fields, like credit card data can be too sensitive to autocomplete and some fields may be too private to share on a public computer.
As this is a new rule, the implementation and way of reviewing are still in its early stages. Autocomplete values are very United States focused in general, the structure of names in Europe may be different than the options provided by the W3C.
Resources
WCAG Understanding Success Criterion 1.3.5: Identify Input PurposeMDN on autocompleteW3C on autocomplete
Keep Non-Form Information Out of a Form
Best Practice
Keep headings, HTML blocks, standalone paragraphs, and other non-form related information outside of a form.
Why?
Assistive technology like screen readers jump into “form mode” when they enter a form. This means that they only target focusable elements. This is done to enable the user to type characters inside input fields (instead of using them for shortcodes and navigation).
The disadvantage of this is that the screen reader doesn’t announce content that is not associated to form controls, so a heading or pieces of other HTML inside a form are not announced.
About aria-describedby
You can associate separated content to an input field with aria-describedby.
Descriptions you add to a form control with the Gravity Forms admin interface are connected to a form control with an aria-describedby construction. This makes for a description that is announced with the form control.
Note: The first rule of ARIA is: don’t use ARIA. Use it only if you don’t have another option available with HTML5.
Example:
The text that needs to be announced with the input field is put in a separate element, with a unique id.With the input field that element is connected with an aria-describedby attribute referring to that unique id.
123
Please fill out your favorite color
Show Essential Information by Default
Good Practice
Show essential information by default and don’t hide it behind a toggle or tooltip.
Why?
Toggles, dropdowns, and tooltips are extra hurdles people need to jump through to get information, these add to the cognitive load. There is a risk people won’t get the pattern of hiding you had in mind. If information is essential to fill out a form, best not to hide it by default. You want people to fill out your form as easy as possible.
Announce Dynamic Changes
Guidelines
If important content changes dynamically without a page reload, announce it by using aria-live on the element that contains the change. Or use role=”alert” on a newly created element with the change.
Why?
If information changes dynamically on a page, for example the sum of a calculation, a blind visitor may miss that information. Someone who is blind can not see the content. If the content of the change is a lot of text, like a list of form errors, then you don’t have to announce everything. You can just announced for example: The form could not be sent, there are form errors, listed above the form. Then the screen reader user knows there are errors and where to find them.
Examples of aria-live and role=”alert”
Use aria-live for changes inside an element that is already in the DOM, the total price for example.
The screen reader listens to the content inside an element with the attribute aria-live, and announces any change in content.
aria-live=”polite” announces the change after the users stops interacting with the webpage.aria-live=”assertive” announces the change immediately.
1234
Use role=”alert” on an element that is newly created in the DOM:
1
There was a problem with your submission. Errors have been indicated below.
Resources
aria-live on MDNrole=”alert” on MDNIntroduction on ARIA: “Who’s afraid of ARIA?” by Rian Rietveld at WordCamp US 2018.
Time Limits on a Form Submission
Guidelines
If you set a time limit on a form submission, inform the user about this and give them an option to extend the limit before the time expires.
Why?
People with anxiety could have difficulties reacting to a sudden expiration warning. People who have a hard time filling out the form may need more time than has been given.
To help you can inform users beforehand that:
There is a limited time to fill out a form.Why there is a lime limit (for example for security reasons).And mention there is the option to extend the time if needed.
Form Validation
Guidelines
Help your users to avoid errors and if they occur, guide them to fix the errors.
Test your forms thoroughly, for various scenarios. User test if you have the resources to do so.Write clear warning and error messages to guide your users.Write messages in plain text that is understandable by non tech persons.Add the list of the form submission errors above the form (not inside the form) and also add with each form control what went wrong.If a field requires a specific format or requirement (like a date or password), provide the user with the rules, a pattern or example in the description, so they don’t have to find this via trial and error.
The W3C website published a great tutorial on how to set up notifications.
Why?
Not all your users are as web savvy as you are, don’t expect a users to understand how a form is set up. Guide them through the errors and warnings and don’t blame them for not getting it right away. Be polite and understanding. And test!
Custom Styling for Select, Radio Buttons, and Checkboxes
Guidelines
All functionality must work with a keyboard and must be properly announced by a screen reader. As we mentioned earlier in this documentation:
“The web is accessible by nature. If you use valid HTML5 for your forms, then interfaces like a keyboard, a mouse, a screen reader and voice recognition software have access to the functionality.”
Why?
Users with assistive technology, like a screen reader or a keyboard only, must be able to fill out a form too. But the code also must be robust, ready for new and future technology.
The Problem
You want to make it pretty using CSS and Javascript. You can do that and keep the controls accessible, but you have to make sure you don’t disable keyboard and screen reader accessibility.
A popular library with styling for select form controls is Select2. At the moment Select2 is not accessible for screen readers. The selected options are not announced, so a screen reader user has no idea what to select. There is a long standing open accessibility issue on the Select2 repository in GitHub for this.
Some patterns to create custom radio buttons that put a CSS display:none property on the input field, which makes it impossible for a keyboard user to access and select it.
The Solution
There are good patterns to create custom styled select, radio buttons and checkboxes. But at the moment of writing this it’s impossible to style option elements in an accessible way with CSS only. There are requests to browser vendors to change this. Your endorsement for this is very welcome.
Good pattern libraries for styling form controls:
The Accessibility of Styled Form Controls
Discussion about styling selects
The Current State of Styling Selects in 2019Can we please style the select control?!
As we are waiting for browsers to permit styling to the select options, please keep this rule in mind:
Make it work before you make it nice.
A form control must work, that’s its main purpose. Making it nice is an extra.
Who is Responsible for the Web Accessibility of a Website?
As a theme or plugin developer you need to to give the content managers the best tools to create an accessible form. So, not only deliver a good product, but also instruct the content manager on how to keep a form accessible. For example by instructing them not hide or omit form labels. Point them to our accessibility documentation geared towards content managers specifically. But in the end the site owner is responsible for the accessibility of their site.
What to Do if you Find an Accessibility Issue
Did you find an accessibility issue in the Gravity Forms plugin code? Please contact us, and we’ll be happy to help you and try to solve the issue.
If you have a Gravity Forms license, you can login and report the issue via our support channels.Otherwise you can contact us using our Contact Us form.
If you had your website audited for accessibility guidelines and there were issues reported with a form made with Gravity Forms, please let us know, so we can help you and see if the issues can be addressed by you or need changes from our side.
Validation and Testing
How do you test the accessibility of your form?
There are 3 important things to keep in mind:
The HTML must be valid and error freeAll functionality must work with a keyboard onlyRun accessibility test tools.
You should always check all three. Automated testing can not catch everything. The test tools improve but, at this moment you still have to test with a keyboard manually.
You best test against the WCAG 2.1 AA guidelines. These are (or will be) the accessibility guidelines in most countries. When in doubt about which rules to follow, check the W3C website about Web Accessibility Laws & Policies and check with your government.
The usual automated testing for PHP and Javascript test the codebase itself. Like the tests done for the WordPress coding standards. This is a good start, but testing for accessibility also requires that you test the generated DOM, so you have to test in the browser or in the case of automated testing use a generated instance of the DOM.
Make accessibility testing part of your test routine during development. It improves the quality of your code and it also makes you a better developer.
Tools For Testing
Your Keyboard
Use your own keyboard to test if every essential functionality works with a keyboard only. On WebAIM there is a great manual on how to do this: Keyboard Accessibility
The W3C Validation Service
Is your HTML valid and error free? On the W3C Markup Validation Service you can validate your generated code by URI, File Upload and by Direct Input. To also check your CSS there is the W3C CSS Validation Service.
aXe Developer Tools
aXe Developer Tools are developed by Deque Systems, based on axe-core. At the moment this is the best and recommended accessibility check tool for developers and can easily be used during development.
aXe for Web is a browser extension by Deque for Chrome and Firefox that adds a tab to your inspector. You can analyze the current webpage for violations and best practices.axe-cli provides a command line interface for axe-core to run accessibility tests.
Other Automated Checkers
HTML_CodeSniffer adds a bookmarklet that displays a popup with the errors and warnings.Wave is a browser addon developed by WebAIM for FireFox and Chrome.Lighthouse performs accessibility checks on a web page. Lighthouse uses axe-core as engine for the checks.
JavaScript Checkers
eslint-plugin-jsx-a11y: by Ethan Cohen. Static AST checker for a11y rules on JSX elements.react-a11y by ReactJs. Warns about potential accessibility issues with your React elements.
Accessibility Checklists and Quick References
How to Meet WCAG (Quick Reference)The a11y project ChecklistAccessibility Checklists by Davidson
Resources and Pattern Libraries
Recommended reads on (form) accessibility, usability, and good practice in general.
Form Design Patterns (book) by Adam SilverW3C Web Accessibility Tutorials on Form ConceptsW3C Wiki on FormsCaroline Jarret on How to Design a Better Form (video) by DigitalGovWordPress Accessibility HandbookDeque University ResourcesWordPress Accessibility Coding StandardsAccessibility Testing by Human MadeAutomated Accessibility Testing During Development by Human MadeOverview of accessibility training and courses by Mike Gifford
Last Takeaway
One “rule” for web development and accessibility is :
If something is very hard to develop and to make accessible, it’s probably also too complicated for all users to understand.
Always keep your users in mind, you are not your user. Keep a form as intuitive as possible to fill out.
Don’t reinvent the wheel, stick to form design conventions. People are used to these conventions and don’t want to have to think about how to use a control they’re not familiar with. Complex constructions often have a higher learning curve to understand.
You want something from your visitors: information, an order, a subscription; So make the process for them easy as possible. This doesn’t mean your forms have to look plain and ugly, it just gives you an opportunity to really think about functional design, usability, workflow, and simplicity to use. Knowing Web Accessibility will make you a better UX-er, designer, developer and content writer.
IntroUse a visible labelThe order of elementsColour contrast of form controlsDesign clear hover and focus statesMake it easily clickable!Custom styled controls can be hardFont sizeAdditional Resources:
Intro
Design a beautiful form and and make it accessible for all users, that’s what we all want. What do you need to take into account? On this page we list some of the most important topics where design, accessibility and good UX meet.
We suggest you first read the document for Accessibility for Content Providers, as a lot of that information is also relevant to designers.
Use a visible label
As highlighted in the documentation for content providers, it is worth emphasizing again here: a visible label is required for an accessible website.
It reminds the user about what to fill out.
If the form is filled with values via autofill, the user can check easily if the information is filled out correctly.
Give the user all the help you can offer to fill out a form.
The order of elements
Visitors, and especially people using a screen reader, read from the top down. So the order of the information must be logical if you read it from the top down. For example information placed below the submit button could stay unnoticed. Place the label above or next to the form control, not below it. A label below an input field can confuse users about which label belongs to which input field.
Colour contrast of form controls
A form control, like an input field should be recognisable. Don’t make your visitor guess where an input fields is. People are used to conventions, so no need to reinvent the wheel for an important element such as a form field, as to many breaks from generally understood conventions may introduce difficulties for some of your customers.
Give a form control like an input field clear borders, with a colour contrast of 3:1 between the control and the background.
Design clear hover and focus states
Let users clearly see the on hover or on focus states for focusable elements like buttons, input fields and links. Keyboard only users need to know when an element has focus, or else they can be easily lost on a page. Make sure the state change is not just based on a color change, as color blind people may miss that change.
Make it easily clickable!
Very small buttons are harder to target with a mouse or a finger. Make focusable elements like buttons or selects, stand out. Give them room, and make them large enough to be easily clicked.
Custom styled controls can be hard
Consult your developer when you apply complex custom styling to select fields and your options, checkboxes and radio buttons. Some styling is very hard to make accessible, and a compromise may be the best way to go.
Font size
Avoid small font sizes: stick with 16px or larger wherever possible, then everyone can read the text comfortably.
Additional Resources:
Jesse Hausler: 7 Things Every Designer Needs to Know about Accessibility
Tyler Hawkins: Designing accessible forms: the 10 foundational rules
Human Made: Accessible Design: A Process
WebAIM: Creating Accessible Forms – General Form Accessibility
IntroductionWhy should you make your form accessible? And what is Web Accessibility?About Guidelines and Legal ImplicationsSettings for Optimal AccessibilityGeneral SettingsForm SettingsAdding Form Block to a PageLabels, Placeholders and DescriptionsWhy?ExamplesTabindexUse of ColorHTML Blocks and Section BreaksAbout NamingGive Users an Idea About What to ExpectreCAPTCHAsForm ValidationWhat is Required?Custom Validation MessagesRecommended Resources
Introduction
With Gravity Forms you have a great tool to create accessible web forms. In this documentation we want to help you:
Set up a form with accessibility in mind.
What to look out for to safeguard the accessibility of your forms.
To help you make your forms work for as many people as possible, we give you guidelines and best practices on this page. Please read our Accessibility Checklist for Gravity Forms.
Why should you make your form accessible? And what is Web Accessibility?
With form accessibility we mean that a form is usable by as many people as possible, on as many different devices as possible.
Like:
A web developer who uses a desktop computer, keyboard and a mouse.
A blind woman who uses a desktop computer, keyboard and a screen reader.
A blind and deaf user, who uses a desktop computer, keyboard, a screen reader and a braille display.
A traveler who uses a smartphone in the train with slow WiFi.
An elderly person, who uses an iPad in bright sunlight.
A child that broke her arm and uses only the keyboard.
You can come up with a lot of ways to use the internet. The W3C listed a few user personas.
As for disabled people: the estimate is that approximately 20% of all people have some sort of disability. That’s 20% of your form users. And as the population is growing older, this number will increase.
We are all different and situations differ too. It’s not only disabled people that use the web differently than you may expect. If you make your forms accessible, all users will benefit.
To help you make your forms work for as many people as possible, we give you guidelines and best practices on this page.
If you are a theme or plugin developer, please also check the Developers Documentation on Form Accessibility.
About Guidelines and Legal Implications
For Gravity Forms we follow the global guidelines for web accessibility: the Web Content Accessibility Guidelines, version 2.1, level AA (WCAG 2.1 AA). Some countries have WCAG 2.0 AA as legal requirement or have a special set of guidelines. If you want to know which guidelines and legal regulations apply for your country and for your type of website, please consult with your government. The W3C maintains a list of regulations per country: Web Accessibility Laws & Policies.
Settings for Optimal Accessibility
General Settings
After installing go to the Forms > Settings page and set:
Output HTML5: “On”.
Output Default CSS: “On”.
Form Settings
After creating a new form, go to the Settings, Form Settings and set:
Label Placement: “Top aligned
Sub-Label Placement: “Above Inputs”.
Validation Summary: “On”.
Required Field Indicator: Do not remove the option to show a required field indicator.
Form Button > Input Type: Choose “Text”.
Form Button > Button Text: Use descriptive text (see “About Naming”).
Form Button > Conditional Logic: Do not enable conditional logic.
Form Options > Enable Legacy Markup: “Off”.
Adding Form Block to a Page
When you add the block for a form to a page, under the Block Settings set:
Form settings: Enable the Form Title.
Advanced settings: Do not set a positive tabindex. Keep the tabindex value -1. This means that no tabindex will be set.
Labels, Placeholders and Descriptions
A label tells the user what they need to fill out and must always be visible.
Place the label above or next to the input.
Keep a label about the input fields only, don’t put links or other HTML inside them.
The placeholder is used for a suggestion on how to fill out an input field.
The description can be used to give extra information about the input field.
The label should always be meaningful and visible. The placeholder and description are optional.
Why?
When the label is always visible, people don’t forget what they have to fill out.
When the form inputs are filled with autocomplete, the users can better check if the input is added to the right input field when the label stays visible.
People read from top to bottom. Placing a label below the input may cause confusion about which label belongs to which input.
When a user starts typing the placeholder disappears, so if the placeholder is used as the only label, the user can get confused on what to fill out.
If you use links inside a label, assistive technology, like a screen reader user may get confused about what to fill out, keep the label text to the point. Use the description to add extra information.
Gravity Forms makes sure that the description is also read out for people with a screen reader. Use that field to give extra information.
Examples
Label: Name
Placeholder: For example Jane Doe
Label: Date
Description: Please use format dd/mm/yyyy to enter the date.
Tabindex
Avoid using a positive tabindex on form controls.
Some users can’t use a mouse, for example because they are blind or don’t have fine motor skills. Then they can use the keyboard to navigate a website. If you use the tab key you can jump from focusable element to focusable element (like a link, button or a form element).
If you add a positive tabindex to a form element, that element will be the first that gets focus on a page. In fact you are hijacking the natural focus order. That can be very annoying for someone who is navigating the site with a keyboard and just wants to access the main menu and not subscribe to your newsletter.
Give the user control and don’t decide for them.
Use of Color
Usually the colors of your forms are determined by the WordPress theme you are using. If you want to change the colors in the customizer, please keep a few things in mind:
The color contrast between text and its background and borders and their background must be sufficient. This is explained in the Accessibility Documentation for Developers.
Don’t refer to or give meaning to color. Like: “Press the green button to continue”.
Not everybody has perfect eyesight. By giving text and borders a good color contrast against its background, you are assured most people can find and read it, even with an iPad in the sun.
8% of all men and 0.4% of all women are color blind. They could miss the reference to the color.
HTML Blocks and Section Breaks
Make sure an HTML block or Section Break doesn’t contain content that is essential for filling out the form. Assistive technology, like a screen reader may miss this content as it’s not announced when the fill out a form.
Use the description field with an input to add essential information. As the description field will be read out for blind users by their screen readers.
About Naming
Make links, labels and buttons easy to understand on their own. Don’t let your users guess, or have to read all around a link or button to see what’s happening. Use descriptions if more information is needed to fill out an input.
For example:
Give a button a clear text. “Submit” is very generic. What about “Subscribe”?
Give a link a describing text. “Click here” is not really useful. What about “our privacy statement” as link text? Write your sentences so that the link text stands out on its own, without forcing the user to read around the text to know why they should click here.
Give a clear description with a new password, like: Please enter password of more than 8 characters long.
Give Users an Idea About What to Expect
Do you have a form with multiple steps? That’s a good idea to break a long form into manageable pieces for the user. But don’t keep users in the dark about how much steps it takes to fill out a form.
If you use page breaks, also set a visible progress bar.
People with an anxiety disorder (and actually, everyone else too) will feel much more comfortable if they know what to expect. Inform users on the amount of steps. Give them a way to return to previous steps to double check if everything is filled out properly.
Give buttons and links a descriptive text so it’s clear what to expect when a user clicks a button or link.
reCAPTCHAs
Accessibility best practice: CAPTCHAs and reCAPTCHAs can be very challenging to fill out for people who are blind or have a cognitive disability or aren’t that web savvy.
Please consider if you really need them. You may need to find another way to prevent spam. Enabling the Anti-spam honeypot can be an option for your site or use a spam protector plugin.
Googles reCaptchas V3 may be an option, but also can violate the privacy of your users. It’s complicated.
First of all: don’t put the burden of preventing spam on your users, you may block real users from filling out your form.
Form Validation
What is Required?
Not all users know what the asterisk () means. So if you indicate a required fields with an asterisk (), put a line above the form with an explanation or add (required) within the label.
Custom Validation Messages
Use the Custom Validation Messages with the form inputs to provide meaningful error messages. A text like “This field is required” can be improved on, for example “Please enter your full name”.
Carefully written error messages are essential. Giving informative feedback on an omission or mistake will keep user irritation to a minimum.
Give the user all the help you can offer to fill out a form, including your contact information if you really want the user to be able to fill out the form.
Recommended Resources
Website Forms usability: Top 10 recommendations
Forms that Work (book)
Designing Good Questions by GOV.UK
The Question Protocol: How to Make Sure Every Form Field is Necessary
IntroductionLimitationsYour WordPress ThemeGeneral SettingsForm SettingsForm Fields To AvoidField SettingsGeneralAppearanceAdvancedAdding a form to a page
Introduction
What steps do I need to take to create an accessible form with Gravity Forms?
This questions can seem daunting when you are starting work on your project. The good news is that Gravity Forms is built to comply with WCAG 2.1 AA, the global standard for web accessibility. This article takes you through a number of the settings and form fields to help educate you as to what to use (and what to avoid) to move your particular form towards the best possible outcome for all users.
This is a checklist, written as a short and easy to use way check your forms. If you want to know about the “why”, please read the accessibility documentation in the Knowledge Base.
Limitations
This checklist is an aid to help you get your form as accessible as possible, but it is not a guarantee.
There are a number of external factors that can affect accessibility, and some areas of accessibility research differ in their views of exactly what is needed, but this article will help you lock down some of the most common settings and options that can affect accessibility. If you have strict compliance requirements, we recommend you bolster the knowledge provided in our documentation with the expertise of an accessibility consultant or advisor. That’s what we did!
Additionally, note that form elements from plug-ins are not included in this checklist, such as those added by the Gravity Forms payment add-ons.This checklist was written for Gravity Forms 2.5, and we will look to periodically update it when there are accessibility improvements or changes in the forms.
Your WordPress Theme
First a word about the WordPress theme you are using. The color contrast between the text and the background is important. Your visitors must be able to read the content in a form.
Gravity Forms ships with it’s own stylesheet (CSS). The color contrast is optimised for a white background color, but your theme may have a darker background color that makes text unreadable when you use the Gravity Forms stylesheet. Check the color contrast ratio between the text and it’s background. It is recommended that ratio be 4.5:1 or higher.
Don’t disable the whole stylesheet only for the color contrast. Remember that the CSS also controls the look and feel of the form elements and the way error messages are displayed, which can also affect accessibility.
Depending on your theme, it may be possible to adjust or overrule some of the CSS using the customizer, or in the CSS of your theme. If needed, discuss options with your site developer or contact the theme provider for advice.
General Settings
Go to the Gravity Forms settings page under Dashboard > Settings and set:
Output Default CSS: “On”.Output HTML5: “On”.
Form Settings
For a newly created form, go to the Form Settings tab and check the following settings that are important for accessibility:
Label Placement: “Top aligned”Sub-Label Placement: “Above Inputs”.Validation Summary: “On”.Required Field Indicator: Ensure the option to show a required field indicator is selected.Form button: Choose “Text”. Use descriptive text.Form button Conditional Logic: Do not enable conditional logicEnable legacy markup: “Off”.
Form Fields To Avoid
The following field types can create accessibility issues, and are not recommended for use in an accessible form.
MultiselectHTML blocks with text that contains essential informationSection breaks with text that contains essential informationreCAPTCHA V2 (an accessible alternative is the honeypot option, as can be found in the form settings).
Field Settings
The form fields settings can be found in the right hand sidebar when you create or edit a form. If a setting is not mentioned here, it has no known accessibility issues.
General
Field Label: always fill out the Field label, explain clearly to the user what needs to be filled out.Input mask: do not use an input mask. Leave that box unchecked.
Appearance
Field Label Visibility: always use a visible label, never hide it.Sub-Label Placement: above input.Custom Validation message: if possible, write meaningful to-the-point custom error messages. Enhanced User Interface: do not enable the enhanced User Interface for dropdowns.Multi-File Upload: do not enable Multi-File Upload with the File Upload field. Using single file upload is ok.
Advanced
Rich text Editor: Do not enable the Rich text editor.Autocomplete: Enable autocomplete for name, address and email fields. The default fields for these fields have the autocomplete values already filled out.
Adding a form to a page
Add the block for a form to the page and select the block settings:
Form settings: enable the Form Title.Advanced settings: do not set a positive tabindex. Keep the tabindex value -1. This means that no tabindex will be set.Do not add more than one of the same form to a web page. Each form on the page must be unique.
IntroductionFrom the Form List ScreenFrom the Form Editor Screen
Introduction
Each of your forms has its own set of settings and options that affect only that form. This is different to the global Gravity Forms Settings that affect all your forms. This article shows you how to access your form-specific settings.
From the Form List Screen
Hover over the form title you wish to change in the list.When the menu appears below the form title, click or hove over settings to expose a drop down showing Form Settings. Now you can edit the settings you need. Once you are done, don’t forget to scroll to the bottom and click Save Settings.
In this animation, we access the Form Settings from the list view, and make a small change to the form title.
From the Form Editor Screen
Hover over or click Settings in the top bar.In the drop down menu that appears, click form Settings.
In this animation, we access the Form Settings from the Form Editor, and make another edit to the form title.
Notice: In June 2017, the PayPal IPN began requiring SSL/HTTPS on all IPN callbacks. If you are using the PayPal IPN, you will need to obtain an SSL certificate. As such, this is a deprecated article left here only for historical reasons.
While an SSL certificate is a great idea in almost all use cases (especially when entering any personal information), some users may choose not to use one.
Most payment services, such as Authorize.net, require an SSL to receive payments, as the data is processed from within your site. The good news is, this is not the case for the PayPal Standard Add-On.
When submitting a payment through a form using the PayPal Standard add-on:
The user fills out the form that contains their total price.
The pricing and user is then redirected to PayPal’s website to complete the purchase.
After completion, the user and payment completion are then directed back to your website.
Using this method, no payments are being processed directly on your site, and therefore an SSL is not required. Since all sensitive information is being entered directly to PayPal, there is no need for an SSL to encrypt this sensitive data.
IntroductionWhat does Gravity Forms provide with a GoDaddy starter license?Can I get any help from Gravity Forms for my GoDaddy starter license?How can I see the license key for my GoDaddy Starter license?Do I have a Gravity Forms account to go with my GoDaddy license?How do I upgrade a GoDaddy starter license to a fully featured Gravity Forms license?I’ve switched my website hosting; can I transfer my GoDaddy starter license?
Introduction
All GoDaddy managed WordPress accounts include a free Gravity Forms Starter license for one year. Read more below to learn which features are and are not included.
What does Gravity Forms provide with a GoDaddy starter license?
A GoDaddy starter license provides:
– access to automatic updates and future releases of Gravity Forms (core plug-in)
– access to the normal GoDaddy support and services you are entitled to
It does not provide access to:
– official Gravity Forms add-ons
– access to Gravity Forms official support
Can I get any help from Gravity Forms for my GoDaddy starter license?
We will happily answer simple Contact Us questions and refer you to our public help documentation for questions regarding installation, updates, and how to upgrade your license, etc.
For anything more complex, such as help with setup, conflicts, debugging forms, etc, you will need to purchase a paid Gravity Forms license, which entitles you to our Priority Support service.
How can I see the license key for my GoDaddy Starter license?
A GoDaddy starter license is installed for your GoDaddy website automatically. You do not receive (nor do you need) a license key.
Do I have a Gravity Forms account to go with my GoDaddy license?
No, Gravity Forms accounts are not created for GoDaddy starter licenses, and these licenses are not linked to our account system. You would need to purchase a license from Gravity Forms in order to obtain a full Gravity Forms account.
How do I upgrade a GoDaddy starter license to a fully featured Gravity Forms license?
You can purchase directly from us but keep an eye out for special offer banners on your WordPress dashboard. These may snag you a discount on your upgrade, offered just to GoDaddy starter license customers!
I’ve switched my website hosting; can I transfer my GoDaddy starter license?
No you cannot. The Starter license is usable only on a GoDaddy hosted website. You would need to purchase a new Gravity Forms license.
