091: How Accessible are WordPress Forms by Default with Gen Herres

This episode is a recording of an October 2024 WordPress Accessibility Meetup where Gen Herres explores how accessible various WordPress form plugins are by default. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: How Accessible are WordPress Forms by Default? with Gen Herres.

Listen

Links Mentioned

Summarized Session Information

This session explored the accessibility of popular WordPress form plugins, evaluating how well they meet WCAG and Section 508 standards in default settings. The discussion emphasized the importance of manual testing over automation for detecting form accessibility issues, especially as new laws like the European Accessibility Act come into effect.

Key issues discussed included common accessibility errors such as improper use of ARIA, incorrect label handling, misuse of fieldsets, and placeholder reliance. The session also highlighted the significance of providing clear error messages, proper color contrast, and adequate font sizes.

Screen reader testing revealed inconsistent form experiences, particularly in the handling of name fields, checkboxes, radio buttons, date pickers, and consent boxes. Despite these challenges, some plugins like Gravity Forms and Contact Form 7 were praised for their semantic HTML and user-friendly features, while others still required improvements.

The session concluded with practical advice for both users and plugin developers: users should contact vendors for accessibility compliance information and ensure their forms work as intended, while developers were encouraged to respect site settings and provide more customization options for managing styles.

Session Outline

  • Form basics
  • Test environment setup
  • The forms
  • Recurring errors
  • Screen reader test
  • The spreadsheet
  • Things that were nice
  • What plugins do wrong
  • User responsibilities

WordPress form accessibility basics

It’s essential to learn from experience, particularly the mistakes made by others when developing form plugins. Forms are a critical component of almost every website, and improving their accessibility enhances user experience and benefits website owners by increasing form completion rates.

Most WordPress users do not modify the default settings of form plugins, making it essential to evaluate the accessibility of forms based on these default configurations.

Automation tools are largely inadequate for testing forms, as they miss many issues. Therefore, manual testing is crucial. Upcoming laws like the European Accessibility Act (2025) and updates to existing laws in the US, Canada, and Australia will place additional requirements on form accessibility, pushing many developers to ensure their products meet WCAG 2.1 or 2.2 standards.

As an example of the importance of accessible and streamlined forms, Equalize Digital’s accessibility improvements to their purchase process led to significant increases in user engagement and sales. Moreover, common form-related issues, such as email deliverability problems, often stem from website configurations rather than the form plugins.

Several coding resources, including the US Web Design System, W3C tutorials, and Mozilla Developer Docs, offer valuable examples and best practices for creating accessible forms.

Key recommendations include ensuring every input has a label, avoiding placeholders, and making form fields and buttons visually distinguishable and easy to interact with.

WordPress form accessibility test environment setup

The test environment was set up using a fresh WordPress installation with the default 2024 theme, as plugins are often tested against default themes for compatibility. Basic caching plugins were included, default contact forms from various plugins were used, and additional standard fields were added. These fields were selected based on experience working with over 1,000 websites. They included fields like name, email, phone, text areas, number fields, checkboxes, radio buttons, consent forms (e.g., GDPR), full address, date entry (relative and absolute), and select fields.

The initial test involved a screen reader, as it can quickly highlight accessibility issues, ensuring that forms are accessible to users who rely on this technology. The importance of accessibility was emphasized, noting that the global disabled population has significant disposable income, making accessible forms a business imperative.

Forms were also evaluated against both WCAG and Section 508 criteria. Although the standards are similar, some key differences exist. For example, while WCAG allows hidden labels in specific instances (e.g., a search field with a button), Section 508 mandates visible labels or instructions in all cases. Therefore, a form might pass WCAG but fail Section 508 due to these differences.

The forms

The presentation included several popular form plugins, most eager to participate and receptive to feedback. The plugins tested were:

  • Contact Form 7 (10 million installs)
  • Fluent Forms (500,000 installs)
  • Formidable Forms (400,000 installs)
  • Forminator (500,000 installs)
  • Gravity Forms (971,000 installs, based on BuiltWith)
  • Ninja Forms (800,000 installs)
  • WSForms (8,000 installs)

WSForms joined as a replacement after another plugin opted out. Notably, WPForms, with over six million installs, declined to participate, and no accessibility information was available on their website.

Page builder forms are not included, so it’s best to have centralized management through dedicated form plugins. Page builder forms often complicate website maintenance, especially when a form is duplicated across multiple pages, leading to significant inefficiency during updates.

While many popular plugins were tested, not all could be included in the evaluation.

Recurring errors

Forms can use ARIA, but should they?

ARIA should be used cautiously and only when necessary. The general rule is that bad ARIA is worse than no ARIA at all. Semantic HTML should always be the first choice, and ARIA should only be added in cases where it’s truly needed. Many plugins made the mistake of overusing ARIA attributes like aria-label and aria-labelledby, which often led to more confusion and accessibility issues than they solved.

Fields only need one label

Several plugins made the error of applying multiple labels to form fields, such as using a visible label, an ARIA label, and a placeholder. This redundancy creates unnecessary complexity. The correct approach is to use a single label with a for attribute properly associated with the input field. This simplifies the code and improves accessibility by eliminating conflicting or redundant information.

Divs are not fieldsets

A recurring issue was the misuse of fieldsets to group entire forms. Fieldsets are intended to group related form elements like checkboxes or radio buttons, not to wrap the entire form. Some plugins placed a fieldset around the entire form, causing screen readers to repeat the form’s name for each field, which is both unnecessary and frustrating for users. Proper use of fieldsets involves grouping small sets of related items, with a legend that provides context for that specific group.

Placeholders are not labels

Placeholders should not be used as a substitute for proper labels. While visible in the field, placeholder text can create confusion, particularly for screen reader users, as it is often read aloud and can be misleading. An example was given where a placeholder for a phone number (EG +13004005000) was not only unhelpful for users but also provided incorrect formatting guidance. Labels should be clear and distinct from placeholders to avoid this confusion.

Helper text

Helper text is important in guiding users, especially for fields requiring specific input formats, such as dates. This text should be placed directly after the label and made accessible using ARIA-describedby. Relying on tooltips was discouraged because they often aren’t accessible, and users may struggle to activate them or keep them visible while filling out a form. Using helper text is a more reliable way to provide necessary guidance to all users.

Autocomplete helps users

The use of autocomplete values was another area where many plugins fell short. Autocomplete allows browsers or password tools to correctly fill in common fields, reducing errors and improving the user experience. Without proper autocomplete values, browsers make guesses, which are often incorrect. Adding the appropriate values, such as autocomplete="given-name", ensures that inputs are filled in correctly and efficiently.

Don’t validate until field entry is done

Premature field validation was a common issue, with some forms triggering validation on every keystroke. This behavior caused screen readers to constantly announce validation errors, interrupting users as they attempted to fill out fields. To avoid these interruptions, validation should only occur after the user has completed their input. Additionally, some forms validated fields too early, reading out error messages before the user had finished entering data, further complicating the form completion process.

Color contrast

Maintaining sufficient color contrast was another critical area highlighted. Labels and buttons must have a minimum contrast ratio of 4.5:1, while all other user interface components require a contrast ratio of 3:1 in every state, including hover, focus, and error. Plugins that modify form elements must ensure that these components meet the necessary contrast requirements to avoid accessibility barriers.

Font size

Font size is another important aspect of form accessibility. It was noted that a minimum size of 1rem is widely accepted because it respects the user’s preferences and allows for scalability. Many plugins, however, hardcoded font sizes like 12px or 13px, which are too small for most users. Plugins should avoid overriding larger default font sizes and should ensure that line heights are relative to the font size rather than fixed in pixels to prevent text from becoming unreadable when larger fonts are used.

Screen reader test

During the screen reader testing, Kevin Andrews, a native screen reader user, and Gen discussed various accessibility issues encountered in form plugins. They highlighted specific problems with key form components.

Name field

One of the recurring issues was the inconsistent labeling of name fields. Some plugins failed to programmatically connect the labels for first and last names, causing screen readers to only announce “name” without clarifying which field was being filled out. This ambiguity made it difficult for users to know whether they were entering their first or last name. For example, in Ninja Forms, the first field was labeled as “name,” and the second field had no label, leading to confusion.

Checkboxes and radios

Problems with checkboxes and radio buttons were mainly due to the lack of fieldset grouping. Screen readers could not provide clear context without proper grouping, leading to confusion. For instance, users would tab into a checkbox list without knowing what question they were answering, creating a poor user experience. Four of the seven plugins had issues with grouping checkboxes and radio buttons, making navigation difficult.

Date picker

While most date picker fields were problematic, Contact Form 7 stood out for its accessibility. It allowed users to navigate the calendar with arrow keys and correctly read out dates. Other plugins required guesswork from the user regarding date formats (e.g., whether to input MM/DD or DD/MM), which made form completion frustrating, especially for an international audience.

Consent box

Consent boxes showed a wide variety of issues. Some plugins provided clear and complete information about the requested consent, while others merely read “checkbox required” or failed to include the full consent text. The inconsistency in communicating consent could lead to users unknowingly agreeing to terms they couldn’t read. Kevin highlighted that this is a critical issue, especially in sensitive areas like healthcare or voting, where privacy and informed consent are essential.

Confirmations

The handling of confirmation and error messages varied greatly across plugins. Contact Form 7 immediately read confirmation messages, while others did not provide clear feedback or reloaded the page without informing the user.

Some forms lost focus after submission, leaving users unsure of whether their form had been submitted. Error messages were often generic (e.g., “invalid data”) and didn’t guide users on how to fix the error, creating a frustrating experience for both screen reader and sighted users. Gravity Forms was praised for providing a well-organized list of error messages at the top of the form, with links that took users directly to the fields needing correction.

The spreadsheet

The presentation moved on to discuss the spreadsheet, which contains detailed test results for various form plugins. The spreadsheet includes a tab with notes, links to the screen reader testing video, and a list of fields tested. It also references Section 508 and WCAG criteria, explaining what each requirement means. Versions of each form plugin are noted, along with accessibility information, although only Gravity Forms and WSForms had published accessibility details.

Several recurring issues were highlighted across the tested criteria. Helper text placement was problematic for most plugins, as it was often positioned below the field, making it difficult to find and sometimes covered by autocomplete suggestions from password managers. Screen reader testing revealed that many labels and instructions were insufficiently descriptive or programmatically associated, causing confusion for users.

A recurring issue involved plugins grouping entire forms with a fieldset, which led to screen readers reading out the form name before every field—especially problematic with Apple VoiceOver. Date and time pickers often failed to work with screen readers, with Contact Form 7 being the notable exception for having a well-functioning date picker. Another common issue was the lack of helpful error messages, with some forms providing vague instructions, such as “invalid data,” without explaining how to correct the error.

Despite some of these issues, many plugins performed well on simpler accessibility criteria, like meaningful sequence and avoiding keyboard traps. Focus order was generally well-implemented, and most plugins had proper labels, though some plugins used labels that wrapped input fields, which is less ideal. On mobile devices, most plugins adapted well, but several failed when text was resized, especially when select fields were set in pixels, causing overflow.

The spreadsheet also includes a pass count for each plugin, but Gen advised against using this as a definitive measure of accessibility. Since not all issues occur across all types of forms (e.g., not all forms include date fields), a simple pass count might not fully reflect a plugin’s accessibility performance.

Things that were nice

Each form plugin had certain aspects that stood out positively during testing, particularly in how they handled accessibility.

Contact Form 7 was praised for having the best date picker, which worked smoothly and read dates clearly with a screen reader. Additionally, it respected the default theme settings, avoiding common issues with contrast on focus states, labels, borders, and buttons by not overriding theme styling.

Fluent Forms also did a good job with the date picker, which worked with a keyboard, though it fell short in terms of screen reader compatibility. Like Contact Form 7, Fluent Forms avoided many contrast issues by leaving theme font sizes and colors unchanged.

Formidable received positive feedback for ensuring that checkbox and radio labels were properly read out by screen readers, which was a welcome improvement compared to other plugins. The form also handled error submission well, taking the user to the first field with an issue, and had a well-implemented consent field.

Forminator was highlighted for its good handling of confirmation messages. After submission, the confirmation was immediately read out, which helped users understand that their form had been successfully submitted.

Gravity Forms was regarded as the best overall by default. It excelled by using semantic HTML and employing far less ARIA than other plugins. The inclusion of autocomplete by default was another positive aspect, making it more accessible out of the box.

Ninja Forms stood out for marking required fields clearly, which some other plugins struggled with. The plugin also provided a privacy policy link before the consent field, allowing users to review the policy before making a decision. Error messages were handled well, and the date field was accompanied by the appropriate “described by” attribute, ensuring users knew the required formatting.

WSForm was noted for having a good consent field and for using semantic markup for name and email fields. Like Formidable, WSForm also took users to the first field with an issue upon submission and error messages were read out clearly, ensuring a smooth experience for screen reader users.

What plugins do wrong

The main issue highlighted in the discussion about what form plugins typically do wrong was their tendency to modify site settings. Most websites include multiple forms—search forms, comment forms, contact forms, e-commerce forms, and more.

It is essential for all these forms to look consistent across the website. However, many plugins override theme settings with their own extensive CSS, causing forms to look different from one another and disrupting site cohesion.

This results in developers needing to write significant amounts of custom CSS to undo the plugin’s changes, which is frustrating and time-consuming.

Subjective: Leave my site settings alone

Contact Form 7 was praised for leaving site settings untouched, ensuring that forms match the rest of the website’s design. In contrast, other plugins that made modifications often introduced accessibility issues. The common developer complaint is that these plugins overwrite carefully designed site styles, requiring developers to spend extra effort restoring consistency.

What can users do?

Users have a couple of options to address these issues. They can complain directly to plugin developers, requesting that their site settings be respected. Alternatively, users with PHP knowledge can dequeue the plugin’s style sheets and replace them with only the necessary CSS (such as for error and confirmation messages). However, this process is often frustrating and can break on theme updates, which is why many users opt to override only the problematic CSS.

What can plugins do?

Plugin developers could improve their products by resetting fewer styles and allowing their forms to inherit more from the website’s existing styles, promoting consistency.

Another useful feature would be to include a checkbox in the plugin settings, giving users the option to disable plugin styles altogether or to load only essential styles (like those for error and confirmation messages). This would allow forms to integrate smoothly with the rest of the website without the need for extensive customization, and the plugin would remain responsible for ensuring that any changes they make are accessible.

User responsibilities

Users bear significant responsibility when building accessible forms. A key recommendation is to contact your vendors now about the accessibility of the plugins and themes they provide. With several new laws coming into effect between 2025 and 2027, such as the European Accessibility Act, vendors are required to provide information on their product’s accessibility compliance. Users should reach out to vendors with requests for accessibility conformance information, ensuring that the products they use meet WCAG 2.2 level AA or other required standards.

Form creators’ responsibility is to make thoughtful decisions when building forms. Since plugins don’t know the context in which their forms will be used, it’s up to the user to ensure that forms work as expected and comply with accessibility requirements. Users should be vigilant about testing their forms to avoid issues such as JavaScript conflicts that could break functionality or introduce accessibility barriers.

An example of what not to build was provided with a poorly designed login form, which lacked labels, used placeholders incorrectly, and had contrast issues, making it inaccessible to screen readers and frustrating for users. This highlights the importance of adhering to best practices when creating forms.

For those interested in learning more, various resources were shared, including the Easy Ally Guide’s YouTube channel and website, WordPress Accessibility Day, and the Accessibility Craft Podcast. These platforms offer valuable tutorials, guides, and tools to help users improve their understanding of accessibility and build better forms.

Transcript

>> CHRIS HINDS: Welcome to the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.

And now, on to the show.

>> GEN HERRES: All right. I am Gen Herres, and today is how accessible are WordPress forms by default? What we’re going to cover in today is form basics, testing environment setup, the forms that joined us, the recurring errors that we found in these forms, screen reader test, the spreadsheet, the things that were nice about the various plugins, what plugins universally do wrong, and finally, we’ll wrap up with a quick user responsibilities because it’s not just on the plugin. It’s also on all of us who use those plugins to build things.

Slides and links are available at easya11yguide.com learn. This will be repeated several times during the presentation, and I’m sure that Paola will post the link in the chat. We’re going to start off with form basics. Why are we doing this in the first place? Wisdom comes from experience. Also, as a quick note, I will be reading important content on the slides, so you do not need to see the slides to get the presentation value. Wisdom comes from experience, and one of the best ways to get experience is to let others make mistakes for you.

It is a great time to learn from what other plugins have done and learn lessons about what has gone well and what has gone poorly because we don’t have time to make all the mistakes ourselves. Thank you to all the form plugins who joined us. I know it can be very scary to get up here and be on display publicly. I am not trying to shame you. I am trying to educate the community and the fact that you have volunteered to be up here and to be willing to say, “Okay, these mistakes happened, but we can all learn and move forward,” and so I applaud all of you for joining us.

The reason why I focused on forms is that they are on just about every single website out there. By making forms even a little bit more accessible, we make the internet a much better experience for all of the users. We also make websites better for website owners because the easier it is to fill out a form, the easier it is to complete a form, the more forms get filled out. It’s just that simple. I chose to do all of these by default because the reality is, I have been in the WordPress space for almost 15 years now and people don’t change defaults. I have seen literally over 1,000 websites that I’ve been asked to work on over the years and users do not change the defaults.

They drop the form plugin, they activate it, they click the default contact form, they add some fields, they click publish, and that is all that most people will ever do. I wanted to judge you on how that is. Since I always get asked about automation and what automation does and doesn’t cover, automation is downright very, very poor at testing forms. It found a few of the color contrast issues and one of the tools identified that there was placeholder text. That was it. There were well over 100 errors between all of these different plugins and we discovered about four of them via automation.

If you’re working on forms, you absolutely have to have manual testing. Some upcoming laws that are going to come into effect. The European Accessibility Act, or EAA, comes into effect in June of 2025 and that will affect several of these form companies. For the first time that I’m aware of, this law will allow people who are not having a qualified disability to actually file complaints. In most laws around the world, someone has to have a qualified disability. That means a significantly impactful disability. If someone is colorblind, they don’t have a qualified disability. If someone’s legally blind, they have a qualified disability.

In the European Accessibility Act, people who sell to Europe and either have two million in global revenue or 10 or more employees need to comply. That is going to affect quite a few of these form plugins. The US ADA Title II and HHS, which is Health and Human Services, and ADA is the Americans with Disabilities Act, those come into effect in early of 2026 and those will require WCAG 2.1 Level AA for a large number of websites in the local and state government for the ADA and for healthcare providers, which includes a lot of small providers, for health and human services.

In Canada, the Accessibility for Manitobans Act is coming into effect fully for everyone in May of ’25 and Australia is currently updating their national law to WCAG 2.2. In evidence of easier forms get filled out, Equalize Digital had recently overhauled their accessibility checker sign-up and purchase process. They eliminated a whole bunch of non-essential fields and they streamlined the process and they also ensured that everything was actually accessible and easy to use and they got a significant increase, a 90% increase in the free opt-ins and a 60% increase in the purchases and they discussed this in a recent Accessibility Craft podcast episode.

Email deliverability for your forms. This was not tested and it is always a big issue with forms and it’s not the form plugin’s responsibility to make sure that your website can send email. Lots and lots of websites have form problems because they can’t send email. If you’re having form problems, it might not be your plugin, it might actually be that your website can’t send email properly and we did a whole presentation of the Baltimore Meetup about fixing broken website forms and making sure that they can actually send email. That’s in the slides and links.

I want to talk about some resources for code examples and testing. The US Web Design System is a fantastic resource for getting a whole bunch of code that has been checked against WCAG 2.1 Level AA. W3C, which is the World Wide Web Consortium, has a whole section of form tutorials. Those include code and explanations about the code. There is also a section on ARIA patterns and that includes more complex patterns, why they get used, and code for them. I was recently working with a plugin developer who’s doing a fancy combo box and so we’ve been going through a bunch of the different ARIA patterns and working to make it screen reader accessible.

Mozilla has some really great reference documentation for coding examples and the W3C Design System has some really good tips with code and I’m actually going to switch over to that for a moment and talk about some of their top tips for forms from the W3C. Number one, every input needs a label. Do not wrap inputs in labels, put labels above the input. So I did not fault any of the form plugins on this one specifically. I allowed the label to wrap the input without giving them an issue. It is, however, a preference to have the label before the input and correctly programmatically assigned.

Do not use placeholder on input fields. I faulted a lot of plugins on this one. Make form fields look like form fields. Form fields need to be visually distinguishable from their background. This means that they should have a border on them and it’s also recommended that they have a minimum height of 44 pixels to make them easy to click on mobile devices or for people who just have a shaky mouse. Make sure that buttons look like buttons.

Now we are going to hop quickly to the Mozilla Developer Docs and this is a great place to get information about how to code certain things. Here I have on the screen how to code a checkbox and Mozilla has an example for us of how to code this and it includes a field set to start, a legend which includes the directions on what you’re supposed to do with these checkboxes, and then the individual checkboxes which include both an input and a label. Back to our slides. We’re going to quickly talk about the test environment setup. We started with a brand-new WordPress installation.

I used the default 2024 theme. Plugins are always encouraged to check themselves against the default themes so that’s why I chose the default theme. I added just some basic caching plugins which were on my hosting system and I grabbed the default contact us type form from all of the contact form plugins and then I proceeded to add fields. I did this because, again, I have worked on over 1,000 websites in my experience and this is what the vast majority of people actually do.

The fields that I looked to test were fields that I have seen used a lot. This is name, and that may or may not have been a single field or a first and last field, email, phone, single line text field, text area field, number field, URL field, checkboxes, radio buttons, a required consent such as GDPR and privacy policies, full address if it was available, date entry and if it was available, I used both a relative date and an absolute date. A relative date is when would you like to schedule an appointment for your dog’s grooming. That is going to be a date relative to today. Do I want to do it for next week or in a month? That’s something that having today as a date is very important for context.

This is normally a big calendar picker and then an absolute date is what was my dog’s birth date. That would be the example of an absolute date. I don’t want a giant calendar picker. I just want to type it in and of course a select field. The first test that we ran on all of these after they were built was a screen reader test because this will quickly identify a lot of issues. People who use screen readers need to actually be able to complete the form. Recent information from one of the international organizations I can’t remember which one at the moment but it said that the disabled population of the world has about two trillion, yes, trillion with a T in disposable income.

You definitely want to make sure that those people can fill out your forms. We tested for some specific criteria against both WCAG and also Section 508. The reason is there’s a few differences that are slight but important between Section 508 and WCAG. WCAG will allow a hidden label in some instances such as a search box. If the entire form is a single search field and a search button, WCAG actually has in their examples that this is permitted as long as there is still a screen reader label available.

However, Section 508 requires a visual label or instructions on every single case and so it will fail Section 508 even if this particular example of a search form passes WCAG. The form plugins that we went with. Most plugins were thrilled to be included and very receptive to feedback. The following plugins were included and I will quickly list them along with their estimated install count from the WordPress repository or in the case of Gravity Forms from BuiltWith. Contact Form 7 at 10 million. Fluent Forms at 500,000. Formidable at 400,000. Forminator at 500,000. Gravity Forms at 971,000. Ninja Forms at 800,000, and WSForms joined us at 8,000.

They were kind enough to join us because someone else opted out. Because I’m going to get asked about this, what about WPForms? They have over six million installations but they declined to participate. They were the only one who declined. I did check their website and they had no information on their accessibility. I will also get asked about what about Page Builder Forms. I don’t like Page Builder Forms. I prefer to have all of my forms in one location where I can easily find and update them. The reason is I have had to fix numerous websites where someone put a form into one page on a builder and then duplicated that page 40 times.

To fix something in that form, I now have to go into 40 separate pages and edit them all. When I do that, I replace them all with an actual form plugin so that now in the future, the next time they ask for an edit, I only have to do it once. I selected a number of popular plugins and I could not test every one. Some recurring errors that showed up. Forms can use ARIA, but should they? The number one rule of ARIA is that no ARIA is better than bad ARIA. Always use semantic HTML first and only add ARIA when needed. Now there are definitely cases when ARIA is needed, but always make sure that you’re writing good semantic HTML first.

ARIA-label and ARIA-labelledby were overused by several plugins. Fields only require one label. Label for your field ID. Sorry, let me start over. Here’s an example from some of the form plugins. In this example, we have a label on a first name field. There’s a visible label, which is first name. There is also an ARIA-label, which is first name. Then the input field has a placeholder, also a first name. Then in this example, I also show that it has an ARIA-labelledby referencing back to the original label.

Now there are three things here that need to be deleted to improve this code and make it more accessible. The first is the ARIA-label on the label element. The second is the placeholder on the input, and the third is the ARIA-labelledby on the input. The label tag has a for parameter and that references the input. There is no need to use an ARIA-labelledby when the label already has the for. I wrote out the correct example for how this would all break down. That is a label tag with the for attribute filled in. This label happens to have an ID. Then it has first name.

The input tag is an input type text and it has an ID on it. Divs are not fieldsets. This was a recurring issue regarding checkboxes and radios and entire forms. Several of the form plugins put a fieldset around the entire form. Some of the screen readers will then read out the name of the form which is put into the legend tag of the field set for every single field in the entire form. That is really, really annoying to screen reader users. Fieldset is designed to group together a small set of related items such as checkboxes or radios. It is not designed to encompass an entire giant form. Fieldsets should be used when talking about checkboxes and radios.

Here I’ve got an example. We have fieldset, legend. Within the legend, we have the label for the group. Basically, the question we’re asking people to answer. Then we have inputs. When we’re using radio buttons and checkboxes, we want to make sure that the input has a name and that is going to be the group. That’s a grouping of related fields that allows us to group those together. Then we have the labels to go with the radio buttons. This allows the browser to do all of the work. You’ll notice I have no ARIA included in this because, for basic checkboxes and radio buttons, you don’t need them if you use semantic HTML.

Placeholders are not labels. Placeholder text is read out. If you put placeholder text in, it gets read out and the contents can be rather painful. Here’s an example of a phone number field and the placeholder is EG +13004005000. That’s really annoying and not helpful to a screen reader user to have that read out. Additionally, in this particular form field, that’s not actually the required formatting for the phone number. That’s actually very confusing to sighted people who are looking at the form.

Next up is helper text. It is really important to have helper text for fields that require specific formatting, such as dates. There are a lot of different ways to write a date. If you don’t provide specific instructions on how to write that date, people don’t know what to do. You should put the field or the description above the field just after the label. I have an image example where it says date absolute as the label and then the helper text is MM/DD/Y Y Y Y. This is the standard formatting of dates in the United States.

This provides both screen reader users and sighted users information on how to fill out this field correctly. Since it’s a description, I would use an ARIA-describedby on the input with a reference to that description. 

>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. 1000s of businesses, non-profits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility problems on an ongoing basis. 

New to accessibility? Equalize Digital Accessibility Checker is here to teach you every step of the way. Whether you are a content creator or a developer, our detailed documentation guide you through fixing accessibility issues.

Never lose track of accessibility again with real-time scans each time you save, powerful reports inside the WordPress dashboard, and a front-end view to help you track down hard-to-find issues. 

Scan unlimited posts and pages with Accessibility Checker free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000.

Download Accessibility Checker today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any plan.

>> GEN: It’s important not to use tooltips, and there’s two reasons. One, most of the tooltips aren’t accessible, and two, it doesn’t show and just sit there as information to the user. The user has to actually figure out how to click on the tooltip, which most of them are not of a minimum tap size. It can be very difficult for people to even activate the tooltip to even see the formatting. Then, of course, it disappears while you’re trying to actually type things into the input field.

Helper text is the way to go. Autocomplete helps users. It is really important on common fields, especially in your templates for your default contact forms to include autocomplete values. This allows your inputs to get correctly filled out. Otherwise, the browser takes guesses, and in many cases, those guesses can be wrong. When you add the autocomplete, the browser or the password tool then knows exactly what to put into the specific fields. I have an input tag, type of text, and I have autocomplete=given-name.

W3C has a full list of all of the allowed autocomplete values, and those should be used. Don’t validate your field until the data entry is completed. We encountered this on a couple of different forms where it was reading out information about the field on literally every single key press. This was incredibly annoying for the screen reader. Some of them also validated a field after we left it and then started reading out the error message while we were trying to enter a different field’s input. That was not helpful.

Color contrast. Labels and buttons require a 4.5:1 ratio for contrast. User interface components, which is basically everything in a form, require a 3:1 contrast ratio. This includes hover, focus, and errors. All of the states, all of the time. If your form plugin is modifying these things, it is your responsibility to ensure that those modifications meet the color contrast. Font size. It’s generally agreed upon that 1rem is a good font size minimum. This means that the browser and the person’s personal preferences influence how big the text is, just as it should be.

If someone sets a personal preference, we should respect that. It is well agreed upon that 12 pixels and 13 pixels and even 14 pixels are too small. Your form plugins should not be creating your font sizes in pixels. To start with, you definitely should not be overriding a website where the default font is already larger than 1rem and sending it down to 12 pixels. You also need to make sure that your line heights are set relative to the font size, not set in pixels. Many of the form plugins were setting their line height in pixels, which meant that if I used a larger font size on the page, text got lost.

Now we are on to the screen reader test, and I’m going to bring in Kevin Andrews to chat a little bit about the screen reader testing. We do have a YouTube recording of the screen reader testing that’s available, and that link’s going to get dropped in the chat, I’m sure, by Paola. It was very informative. The first one I have up is the name field. Do you want to talk about this, Kevin, a little bit?

>> KEVIN ANDREWS: I’m just looking at our notes. We definitely, and maybe you can kind of talk about some of the more specific parts of each of the plugins, but as far as the name field, we ran into different issues where you– depending on how it was coded, the form itself, we ran into issues where I didn’t– as I’m a native screen reader user, and also, you on the technical side as well. There were times we would run into this where I didn’t know, am I looking at the first name, the last name? It would just say name.

You had cases where first, it was pretty obvious from a visual standpoint what you were supposed to type into it, but the word first was not programmatically connected to that label name in any way, so I had no idea. Is it just name? I think in one instance, you can watch the YouTube video, which gets into a lot more detail, but you could definitely tell I had a hard time, was it– I just put the first and last name in where it said name.

>> GEN: On Ninja Forms, they had name as the label, and it was over two separate fields. They had descriptive text below the fields for first and last, but those were not programmatically associated. There was no autofill set up for the autocomplete attribute, and to a screen reader, he had absolutely no idea what he was supposed to do with these fields. The first one, field read off the word name. The second field read off nothing.

>> KEVIN: I think it said edit.

>> GEN: Yes, it was really a challenge.

>> KEVIN: Which then means that then you’re like, “Okay, I guess I won’t type anything in there.” Now it becomes a game of guesswork, and you could potentially be a field off. “Oh, it was actually last name, but I think maybe it’s email,” so it just turns into a nightmare.

>> GEN: The next one was checkboxes and radios. We had a lot of issues with these due to the lack of a fieldset.

>> KEVIN: We ran into, and again, I highly encourage everyone to watch the YouTube video. For example, with the checkboxes, we ran into a lot of, it would ask what was your favorite, type of chocolate or something, I think. A lot of times you would tab through it, and because it wasn’t grouped in a programmatic way, you would just land on the first item of the checkbox. What the heck is it asking me? We ran into this on several occasions.

>> GEN: Four out of the seven.

>> KEVIN: Similar with the radios. The radio buttons were also lacking proper grouping, so it was just like, “What am I answering?”

>> GEN: Exactly. The next field was the date picker field. This one, I was a little surprised. Contact Form 7 was the one that had the really good date picker. You were actually able to use your arrow keys. It actually read out and said September 26th. It read out really good info and allowed you to complete the form. On all of the others, we had issues.

>> KEVIN: A lot of guesswork. Do I do 09/26? I know we have people from all over the world, so is it 26/09? You have no idea because it doesn’t give you any of that feedback, any of that guidance, or instructions.

>> GEN: The next one was the consent box. This one ended up being a real smattering of different things. Sometimes it would say consent required. Sometimes it would give a link first. Sometimes it just said checkbox required. Sometimes it read out the whole label. There was a lot of variety.

>> KEVIN: This one is pretty– these are all very important. I would argue this is definitely– I wouldn’t know if I wouldn’t say most important, but definitely something as we talk about things like health care and voting and a lot of other areas where privacy and I’m agreeing to something, I need to know what I’m agreeing. I need to be able to read the consent before I purportedly agree to that thing. That’s very important. I think that is getting overlooked a lot in some of these forms.

>> GEN: There have been lawsuits regarding privacy in terms of service and judges have ruled that if the privacy policy or the terms of service were not accessible to a screen reader user, they do not apply. The person could not possibly have consented, and they are not bound by any of that. Which has resulted in some rather significant sums of money. The last field was the confirmation messages. We had a whole bunch of interesting situations with confirmation messages and also error messages.

>> KEVIN: The forms are starting to run together.

>> GEN: We had some situations where it was read out immediately. Contact Form 7 immediately read out the error message. Some of them just did a bunch of page reloads and you weren’t really told anything.

>> KEVIN: Oh, and then your focus was lost too. I think that was one of them.

>> GEN: Some of them, they read out the confirmation and then it immediately disappeared, so that was great in case you missed it. Then there were also some where the confirmation was read, but it wasn’t visually scrolled to. You heard it, but I didn’t see it.

>> KEVIN: Then I think as far as error messages, I think there was also–

>> GEN: Were a huge motley crew. Gravity Forms did a nice job with the error message at the very top and they scrolled to this on the error. They gave out a list of all of the different error messages, and they were even links directly to the fields. Then some of the others, it would present you one error message, and sometimes it would jump you to the field. Sometimes it wouldn’t. It didn’t always tell you how you had to actually fix the error message. It just said invalid data. That was a great message.

>> KEVIN: Just not very helpful. Especially with error handling, anything like that, tell me how to fix it. Don’t make me– invalid data is one of the most irritatingly generic messages. It doesn’t tell me anything. Now I just don’t want to fill out the form. It just creates a really frustrating user experience.

>> GEN: It’s frustrating to sighted users too, because when it says invalid data, I’m like, “You didn’t tell me what you want. I don’t understand.” We are going over to the spreadsheet now. The spreadsheet is available at the link to get the spreadsheet. Paola has put that link into the chat. If she would kindly put it in the link and then into the chat again, that would be awesome. Here we have the tested criteria. We have the different contact form plugins. I have a tab that has notes on it. The notes also includes a link to the screen reader testing and it includes what fields we did.

There is a reference on section 508 criteria and what the heck those things mean. There’s also a section on the WCAG criteria and what the heck those mean. I included the version for each of the forms. If I was able to find accessibility information specifically for this form plugin, I included it. As you can see, I was only able to find accessibility information for two of them, Gravity Forms and WSForm. I’m going to just kind of quickly go through some of these tested criteria that showed up as common errors.

The helper text was routinely an issue. Pretty much everyone put their helper text below the field, which means that it is not visually available to people, especially on something like a text area. It’s not above the field and therefore it might not be easily findable for a lot of people. Also autocomplete tools, such as password managers and browser password managers, they all drop their autocomplete information below the field. If your helper content is below the field, that is exactly what they have covered up.

The screen reader test is– of course, make sure to watch that video. A quick pop over to the Section 508 reference, which talks about visual label instructions being sufficiently descriptive. This was an issue with a lot of the different form plugins. Some of it was missing and sometimes it didn’t tell you how to complete the form. For example, on the date formatting, it is very important on dates or phone numbers to provide exactly the formatting that people need to use.

Many of the labels were not programmatically associated or the descriptive text was not programmatically associated. That was a recurring issue. Formidable and Forminator had a field group covering the entire form, which meant that Contact Us or Contact Form demo was read out with every single field by Apple VoiceOver. That was a very unpleasant experience. The date and time pickers were a recurring issue because they just did not work with the screen reader in many cases. Contact Form 7, like I said, had a really, really nice one. I just want to call them out for having such a good one.

Error identification was a recurring problem because it didn’t tell us what we were supposed to do about the error. Invalid error didn’t help us much. Ninja Forms had a particularly challenging error. When we went to the email field and then we left the email field to return to a previous field, on every single key press in the field that we were now active, it read out the email field’s error message for every single key press. That was very, very challenging.

Error suggestion was a recurring issue. If the form has error detection, you need to properly suggest error messages and how the person is supposed to fix them. Gravity Forms had a particularly strange one. On the name field, if it wasn’t filled out, they asked, “What if you wanted to send a birthday cake?” Which really makes me go, “Why on earth are we talking about birthday cake?” It’s a name field. I don’t want you to send me a birthday cake. I don’t want to fill out this form. I don’t want you sending me random cakes. No, I didn’t give you my birthday either. That was a very upsetting message for privacy reasons and because I don’t want random birthday cakes.

Some of the criteria that people did very well on, meaningful sequence. This is usually one that most form plugins and plugins in general pass, and that’s putting content into a good sequence. No one had a keyboard trap. Focus order was in the correct order. They didn’t do anything really strange on focus or on input, such as submitting a form. Most of them did, in fact, use a label field, although, for several of them, it would be preferred if the label field was separate from the input field rather than the label field wrapping around the input field.

Reflow, they all did quite well with switching to mobile, working on a phone. That went over very well, but where several of them had difficulties was on the criteria for resized text. They had a lot of overflows, specifically on the select, because they were setting the size of the select in pixels. When you set the size of a select in pixels, you can’t resize the text to be larger and have it still inside the container. Just quick scanning through for some other issues that we hadn’t already covered.

There is at the bottom of this sheet a pass count, and this just counts up the number of times that there’s a pass. I want you all to know that the pass count is not what I would consider most accessible versus least accessible because not all issues are the same. For example, an issue that only occurs on a date field isn’t going to show up in most forms, because while date fields are becoming significantly more popular with scheduling forms online, there’s still a lot of contact forms that don’t have them. I wouldn’t use the raw pass count as the total winner and loser.

Some things that were nice about the plugins. Contact Form 7, definitely the best date picker. Bravo. That was so well done. They also did a great job not overriding my theme settings. They didn’t have the contrast issues with focus state. They didn’t have contrast issues with labels. They didn’t have contrast issues with borders. They didn’t have contrast issues with the submit button. All of that because they left my theme settings alone. Fluent Forms, their date picker did work with a keyboard, however, did not work with a screen reader. It’s progress, but not all the way there.

They did make sure to leave my theme font size and color alone, so they avoided having some contrast issues because they just left it alone. Formidable. The checkbox and radio labels were read out. This was a happy surprise after some of the others. The error on submit takes us up to the first field with the issue, which was a nice handling of that, and they had a nice consent field. Forminator, they did a nice job when it was submitted, reading out the confirmation message immediately.

Gravity Forms is what I would consider overall best by default. They used the best job with semantic HTML, and they used far less ARIA than most of the others, and they had autocomplete by default on. Ninja Forms did a nice job showing fields marked as required. A lot of others had issues with their marked required fields. They gave out the privacy policy link before we actually got to the consent field, which was a nice, pleasant little surprise. Like, “Oh, I could actually read the privacy policy before I have to think about consenting to it. That’s pleasant.”

The error messages were read out well, and the date absolute did actually have the associated described by so that it read out the required formatting. WS Form had a good consent field. Most of their code was using semantic markup for name and email fields. The error messages were read out and errors on submit took you to the first field with the issue. Now I’m going to get out my soapbox. What plugins do wrong as an overall group? They modify the site settings. Most websites don’t have just one form. They have a search form, they have a comment form, and they have a contact form.

On my fancier sites, I have e-commerce form, I have filtering forms, I have a bunch of other different forms all coexisting. I have email subscribe forms. I have lots of different forms that all show up on my same website and of course, my customers, my clients, and of course, their website visitors would like it if all of these forms looked basically the same. Most of these form plugins overrode my theme settings and went and wrote out a ton of their own CSS, which made them all look different and therefore not match the rest of my site.

Developers really don’t like it when we have to then write a whole bunch of our own CSS to override your plugin CSS that overrode our theme CSS that we wrote in the first place. It is a very, very common complaint among developers. Some of the plugins I’ve had to deal with over the years have literally required hundreds of lines of CSS to override and reset things back to the way I set them originally with about three lines of CSS. On this leave my site settings alone, Contact Form 7 did a great job. They left it alone. The others ended up causing accessibility issues with their modifications.

Every single one that made modifications ended up causing issues somewhere. What can the users do about this? We can complain to the plugin developers to tell them to leave our styles alone. We can also dequeue the style sheets. This does require PHP knowledge and then it requires us to find and copy in all of the essential CSS such as for error and confirmation messages, which can be really frustrating and annoying, especially on theme updates, which is why I frequently end up just overriding the CSS I need to rather than dequeuing their CSS.

What it would be really great if plugins did. It would be really wonderful if you just reset fewer things and allowed your plugins to inherit more from the website to enforce consistency throughout our websites. It would also be great if you added checkboxes to your settings areas so that we could choose to load absolutely no plugin styles or we could load just the essentials such as those for error messages and confirmation messages, thereby allowing the majority of us to just check that box and then have the form present in a nice cohesive manner with the rest of our website without us having to dequeue various style sheets and write tons of CSS ourself.

Of course, any choice that the form plugin is making, the form plugin is then responsible for making sure that that choice is accessible. The user responsibility for users as they build their forms. Contact your vendors. We have lots and lots of new laws going into effect in 2025, 2026, 2027, all over the world. Contact your plugin and theme vendors and say something similar to I have a client who falls under the European Accessibility Act and requires a website that is WCAG 2.2 level AA conformant. What information do you have on the accessibility conformance of whatever product you’re asking about?

Per some of the new laws, like the European legislation, vendors are actually required to have information on the accessibility of their products. They should be getting this information together anyway. When you’re building out your forms, it’s, of course, your responsibility to not make bad choices and to instead try and make good choices. The plugins don’t know where they’re going to be placed. They don’t know in what context they’re going to be placed, so they can’t make decisions about that. You need to verify that your forms are actually working as you expect. You never know when another plugin is having a JavaScript issue and that could impact the form’s ability to work as intended.

Many of the accessibility issues do end up getting caused by people creating the content. Here’s an example of a very poor login form. This login form fails contrast all over the place. It has two fields. The intention is an email and a password field. However, there are no labels. The placeholder on the email field says when a screen reader reads it out, bruce@wayne-enterprises.com edit text with autofill menu. That’s not a very helpful label. That’s the field. It’s bruce@wayne-enterprises. The second field for the password, how that’s read out for a screen reader, eight characters, secure edit text with autofill menu. Eight characters? I don’t understand what that is supposed to be.

To wrap up, some more information about me. The Easy Ally Guide has a YouTube channel. The link is, of course, in the slides and links for the presentation. We also have a website filled with tutorials, guides, tools, and services. WordPress Accessibility Day is next week, 24 hours of accessibility talks. This is the WordPress Accessibility Meetup and of course, there’s the Accessibility Craft Podcast where the accessibility meetups are syndicated to. Slides and links for this presentation, as well as others, are available at easya11yguide.com/learn. Just to make it clear, I was not compensated by any of the forum plugins for any of this work but if they would like to contact me later to have them review my work, thrilled to have them. Please feel free to contact me in the future. All right. I’m sure there are questions in the Q&A, Amber.

>> AMBER: Yes, there are. Thank you so much for that. Let me figure out where the Q&A went. There we go. Okay. I’m going to jump around because there’s a couple that are related. Let’s talk about placeholder text first. Obviously, so someone is saying not to do– did you mean to say don’t do placeholder text instead of labels or were you saying never to use placeholder text?

>> GEN: The official W3C design system says, do not use placeholder text. Period. It very rarely is of any value. A far better use is to use the helper text before the field using an ARIA described by and have that helper text write out what it is supposed to be. You want someone to write their email address, you could put an example of how to format an email address in that descriptive text.

You have a date field. You can put an example of how you want that formatted right above it. That way, once people started entering, they still have access to the information.

>> AMBER: I think that is a great explanation on there and following up on that, is there a preferred format for phone numbers? I’d be curious, Kevin, as a screen reader user, if you have opinions on this as well.

>> KEVIN: On the phone number or the placeholder or both?

>> AMBER: Or both, yes. You have a placeholder opinion as well, why don’t you chime in with that first?

>> KEVIN: The placeholder, it is a terrible idea. I see them all the time, especially working with various clients. I would say, yes. Where at all possible, avoid them. Don’t use them. Like Gen said, I would reiterate, helper text, the thing is, when you enter– as soon as you start entering into one of the text field that’s using a placeholder, you immediately lose the placeholder. Then it’s like, what am I supposed to do?

Then the thing that’s trying to be the label, but is actually a placeholder, is now gone. And so you then– if you forgot what you’re entering into it then you have to delete and then it reappears and it’s cognitive overload. It’s a bad experience. They usually have poor contrast. As far as– sorry, Jaws is yammering at me. As far as the phone number field, I think it’s– I don’t have one preference over another. I just want to know how to type it in.

It should be clear how it should be entered and also just allow for some wiggle room. That’s not very technically raised, but can I do one, two, three, four, five, six? If I have to enter hyphens, make it super clear. Just make it clear what I’m supposed to do.

>> AMBER: I’m curious– Go ahead Gen.

>> GEN: When I was working with a client, they had a lot of users and they had just a ton of needs for phone numbers to be entered in a lot of places and they also needed to have very, very clean data in their database. We allowed for the two different types of entry to be acceptable and we clearly labeled that in the message that they could type in just a string of 10 numbers. That’s the length of a US phone number. Or they could type in three numbers, dash three numbers, dash four numbers.

Either of those two was acceptable and when we stored it to the database, we put the appropriate dashes in so that everything in their database was super clean and so that users had the option to just quick type.

>> AMBER: I’m curious from communicating the formatting standpoint to a screen reader, depending upon your verbosity settings in your screen reader, it may or may not actually communicate to you if there is a parenthesis or if there is a hyphen, I’m guessing. I’m curious, Kevin, would you like hypertext that actually spells that out? Like says something like enter a 10-digit phone number, including hyphens, like with the words, or is it enough to just have it that way?

>> KEVIN: If the input does require hyphens, I would find that helpful to know because if it doesn’t say including hyphens, then I’m not going to do it. I’m just going to enter the 10 digits if it’s a US phone number.

>> AMBER: Because the screen reader may or may not actually tell you that in their example, there are hyphens.

>> KEVIN: Yes. Being cognizant of the fact that people have different verbosity settings, punctuation settings, and it just makes it super clear. That’s my recommendation.

>> AMBER: Denim had asked when we’re talking about helper text, should that just be in a div with an ID that is referenced by– he asked ARIA labeled by, but I actually think we’d want to use ARIA described by. Is that sufficient to have it in a div with an ID that is referenced with ARIA described by?

>> GEN: I find it works fine for the screen readers to just do it that way. I’ll frequently just stick it into a paragraph tag instead, but I’ll do a paragraph. I’ll give it an ID. It’ll say what it needs to say and then in the input, it’ll be the ARIA described by.

>> AMBER: It might be worthwhile to comment on why we’re saying to use ARIA described by instead of ARIA labeled by. Does one of you want to take that?

>> GEN: Kevin.

>> KEVIN: Might need a little refresher on that. I know ARIA described by is the recommendation and what I’ve recommended as far as providing supplemental text or supplemental information. You could also do that, say, with a button. You have the label, whatever it is, and then any– it’s not critical information, but it’s helpful to have.

>> AMBER: The difference is the ARIA labeled by is going to actually override the label. If you were to use ARIA labeled by to reference helper text, then when they get to the input, it won’t actually read the label, it will only read the helper text. You still want to reference the label and then use described by to just add supplemental like you were saying.

>> KEVIN: Yes, label led by and ARIA label both. I think those take priority in how the accessible name is calculated.

>> GEN: If I’m going to write the HTML, I guess just to clarify this, I’m going to start with a label tag. I’m going to say label, I’m going to have a “for” and that four is going to reference the actual input field. Then I will have the text and I will close my label tag. Then the next one, personally, I’m going to go with a paragraph tag and I’m going to give it an ID and then that is going to be my helper text.

So enter your date formatted MM/DD/YYYY. Close my paragraph. Then I’ll have my input. This is going to be, say, a text area. Input text. It’s going to have an ID. That’s the ID that’s referenced in the label and then I’ll have the ARIA described by and that references the paragraph. Hopefully, that helps people.

>> AMBER: Yes, thank you. Going back on the placeholder, Dinesh had asked, can we use placeholder text on screen but hide for screen reader because it causes confusion for screen reader users? They’re wondering, could you just have visual placeholder text, which wouldn’t–

>> GEN: It is technically possible, but that’s not actually how the placeholder attribute on an input field works. You’d have to write your own fancy script to do it but again, the rule from W3C design system is do not use placeholder text. Honestly, it tends to cause more confusion than it ever solves. Put labels on your inputs. Add your “described by” if needed.

>> AMBER: I think the other thing I noticed, David commented in the chat that he as– and he’s a sighted person, I know this, with placeholders, he has had to cut– look at what the placeholder was, cut the content out that he had started typing and then paste it back in because he had forgotten. He says it becomes frustrating when there is no visible label or visible description text.

The other thing to keep in mind with placeholder text as well is that most default styles, it fails color contrast. You might have a low-vision user who can’t see that as well, whereas your helper text is going to have normal color contrast.

>> KEVIN: Yes, definitely low contrast. It benefits everyone to have an actual visible label that is explicitly there. I also think– Oh, I was just going to say, also, if you have a placeholder and then tried to hide it from screen readers, one, I don’t recommend that for the reasons we’ve said. Also, just thinking about the fact that the screen reader would then probably, as I could imagine it just saying the input, it would just tell you that it’s an edit field and then you have no idea what it’s requesting. Just something to keep in mind. Sorry, I cut you off.

>> AMBER: No, that’s totally fine. I was just going to switch topics a little bit. I think we’ve gotten all of the placeholder. Yes, okay. Amit had asked when should you use or not use autocomplete attribute in forms?

>> GEN: Basically, when you want the person’s default contact information to be entered. For example, if you have a basic contact form asking for their first name, last name, email address, phone number, and a text field, let’s say, you would put autocomplete on first name. You would put autocomplete on the last name. You would put autocomplete on the phone. You would put autocomplete on the email because most likely, the person wants their defaults dropped into those fields.

Now, if you’ve got a shipping and a billing address, typically you would put the autocompletes on the billing information, but not necessarily on the shipping information. Although I do believe there are shipping options available on the autocomplete list. I’d have to double-check the list.

>> AMBER: The division that we always use is, are you asking for information about the person filling in the form? I have four children and I have to go fill out forms for their schools and it drives me bananas that they don’t use this and I have to fill in every form four times. What’s interesting is you need to use it on things that ask about me, the parent. My name should have an autocomplete, but the field that asks for the child’s name should not have an autocomplete because that’s not asking about me, the person submitting the form, that’s asking about some other human being.

That’s the division that we use is, are you asking for this core information about the person submitting the form, not about other people?

>> GEN: On that topic, don’t forget that WCAG 2.2 added the redundant entry item into the WCAG criteria. If someone is filling out the same type of form, for example, not just a regular contact form, which they’re really going to fill out once, if they’re filling out a form like register my child for something, there’s a very good chance they have more than one child. You have to actually not request the parent information more than once because that’s part of redundant entry.

>> AMBER: Or if they’re logged into an account and you have it saved on their account, so this would impact e-commerce stores, I think, which is where if you already know what their billing and shipping address is when they go to the checkout page, it should default to that with an option to change it, but it shouldn’t require them to retype it every time. Janet Sullivan said, do you recommend the use of JavaScript plugins that add a compliance? Oh, wait, hold on. We’re going to skip this for a minute.

Let’s go on to forms and we’ll come back to that. Sorry. Okay. Daniel had asked, even though default configuration is your main point, could you give any guidance on which forms issues can be mitigated by a user who is actively attempting to build an accessible form? He noted that some of the things you highlight are bad defaults that could be easily overwritten, but obviously, some of the things you highlighted could not be easily fixed by the person building the form. Do you have any thoughts about that?

>> GEN: For example, placeholders can normally be removed. If the form sticks a placeholder in there by default, you can get in there and you can delete the placeholder and just save the form that way. Some things that can’t be fixed are, of course, the actual semantic markup. If they have not done the semantic markup properly, it’s unlikely that you can fix that in the settings.

Some of them might have something for a checkbox and radio to apply a field set, but for the most part, if they don’t do the semantic markup correctly or if they add a bunch of extra ARIA that shouldn’t be there, that’s not something that you can fix in the form settings. Now, a few of the form plugins do have the ability to add ARIA, and of course, the rule of ARIA is don’t use it if you don’t need it, but sometimes it is helpful to add ARIA in some circumstances.

It is nice that the form providers have that field available, but again, most of the time you don’t need it.

>> AMBER: I was curious because you had mentioned the issue with gravity forms and the notification for a birthday cake or something. When you set up your test–

>> GEN: [Crosstalk].

>> AMBER: When you set up your test for that– [laughs] We’re just going to talk over each other. I was curious, when you set up your test for that, did you create a blank form and put fields in it or did you use one of their templates?

>> GEN: For every single one, I grabbed the template. For every single form, I grabbed the default template because that is–

>> AMBER: Rather than like building a unique–

>> GEN: No, that’s not what people do. What I found, the vast majority of people who are out there building forms, they just click the default contact form, get started. That’s what I did. Error messages are normally very customizable.

>> AMBER: I think to Daniel’s point, there’s definitely things about these you can fix, but you have to know to fix them or to look for them or to change them and so probably what these form-building plugins need to think about is how can they make the most generic and most correct template possible? Because that is probably what a lot of people are going to use, like you’re saying.

>> GEN: The vast, vast majority of people are going to use whatever you leave as the default because they assume that you know more than they do. They’re going to leave the default alone. I’ve talked to numerous DIYers over the years. Baltimore WordPress has a ask me anything several times a year, and yes, people are always saying, I didn’t change the setting on whatever plugin it was because I thought that the developer knew more than I did. That’s just a recurring theme.

>> AMBER: Denim asked a good question and I’m curious what both of you think about this. What is your take on doing this material design model where you put the label into the input, make it look like placeholder text, and then when you type– when someone clicks into the field, it shifts up so it stays visible and it is actually the label. Do you have any opinions on that?

>> GEN: I have seen that gone wrong more than I have seen it gone right. I remember I was looking at Webflow and they do that material design thing. They have the field showing up and then they push up on a text area the label towards the top, and what happens is as you fill up the text area, the text in the text area overlaps with the label. Now we have literally overlapping text and you can’t read either of them.

Also, a lot of times when they do that push up, they end up dramatically shrinking the size of the label and you end up at 12-pixel font size.

>> AMBER: Or 10.

>> GEN: Or 10. Yes, it ends up being really small. The reality is while you think you want it to look prettier, if you actually want people to fill it out, they need it to look like what they expect because people are visiting your website in the context of every single website they’ve been on previously and all these other websites that they’ve been on previously have a specific pattern that they’re accustomed to. When they see that same pattern on your site, they feel comfortable. They feel like, oh, I know exactly what I’m supposed to do.

When you start going outside of this huge context of things they’ve dealt with, they tend to have more problems.

>> AMBER: I’ll admit, we do this for customers when they ask for it. I think it’s 100% better than the alternative of not having a visible label. [laughs] It is interesting because it’s so widely used as a pattern now that arguably some people have probably encountered– I mean, even the Google search, if you just go to google.com, like that search field, I’m pretty sure does that. Most of the–

>> GEN: It’s a box [crosstalk].

>> AMBER: I’m not saying Google is great. I’m just saying, I do think it’s a pattern that a lot of people have experienced. I don’t think it’s the best pattern. I think you’re right on that but if you get a design or a client who’s like, I really want to only use placeholders and not have visible labels, this is maybe the happy medium to ensure that you have a visible label, but still give them that slim design. I don’t know.

I will say though, I’m going to post a link in the chat to a YouTube video that everyone should go watch later. It is hilarious from Haydon Pickering, who makes incredible videos and content about user experience and user interface. This video is called What Happened to Text Inputs? He literally talks about this and how it’s a dark pattern that Google and some other big things started. Even going to where there’s not even a box around the input.

That’s something that we don’t even talk about, but styling the inputs where people can clearly see the field borders. If you have not watched this video, you should go watch this video. It is hilarious, but also 100% correct. I don’t know why we went down this weird design path of we have to make things look so simple or bare bones to the degree that people don’t even realize it’s an input they can click in.

We have a couple of specific questions about the forms. One was about– someone said, I’ve been using WP forms and I’m wondering if I should go back to Contact Form 7 based on what you found. What are your thoughts on– did what you find mean people need to make changes? And I don’t know if we necessarily need to call out that specific one, right? Or just in broadly in general about how people should interpret your findings.

>> GEN: I wouldn’t necessarily go to Contact Form 7 as it will require you to write a lot of your own HTML in its current state and update a lot of your own HTML, which is why I said on that spreadsheet, don’t just take the sheer number of past counts as gospel for which one you should choose because some of those failures only affect one or two fields. You might not be using them.

I did not test WP forms as they requested me not to test them, so I don’t know how accessible they are. They have no accessibility statement on their website. They have no accessibility information about their plugin and from a 10-second accessibility test on their website, their website itself is not. It has significant issues to be found in 10 seconds. I would not use their form plugin based on that information.

If you want to write all your own HTML, go ahead and use Contact Form 7, but it does require you to know what you’re doing with HTML and write quite a bit of it yourself so I would probably not use that one. As I said, the overall winner, I would give to Gravity Forms. I’ve already spoken with Mark Westgard from WS Forms, and he has already started implementing a bunch of the feedback.

I know that that is going to definitely be happening and that’s going to be improving soon so I would consider that one. I know I got responses from several of the other plugins that they are going to be putting in the feedback into their forms very soon. Fluent Forms, I had worked with Fluent Forms on fluent booking and they had put in and done a lot of improvements on fluent booking when I worked with them on that one.

I do think that Fluent Forms will be putting in, they’ve responded to that, they’re going to put it in. How soon? I don’t know, but I do feel pretty confident that they will be making updates. The others have also responded very positively. I would think that a number of them will be putting in some updates. How soon or how many of them? I don’t know. Again, the form plugins, they’re more than welcome to reach out to me again in the future, although I won’t put in another 20 hours of unpaid testing, but they can pay me to test, retest the plugins, and give them feedback.

>> AMBER: You know what I would say for someone who is listening to this or watching this is, the way I think about this is you, especially if you pay for one of these plugins, you have a lot of power to go to them and submit issues and say, hey, I really care about this, can you focus on accessibility? And in most of my experience, a lot of plugin and theme developers are very responsive to that kind of feedback.

And so if you can rally, particularly if they have a Facebook group community or something there and say, and go post there and get several people, so it’s not even just you to go and say, hey, this is important, we care about that. I think they will put that in. I’m going to say right now, I don’t want anyone’s takeaway from this to be, I should switch to Contact Form 7.

I actually really suspect that the only reason their install count is very high is because there are a large number of unmaintained websites from 10 or 15 years ago that are using it because it was one of the first and only free form plugins, not because it’s actually the best solution.

>> GEN: It’s also that it has a giant– once they really took the first, the number one slot for most installs, then what happened was everyone was like, “Oh, they’re the most popular.”

>> AMBER: It’s like a self-fulfilling prophecy then.

>> GEN: Yes.

>> AMBER: I think any of these forum plugins are going to be more powerful, they’re going to give you a lot more and I know a lot of them, the ones you’ve talked about also, we– obviously Ninja Forums, who’s a sponsor for the sign language interpretation for today, but also you could go back and watch the recording from Clay Morgan’s talk where he was talking about their journey. They know that they have improvements, they’re working on improvements, it’s been a huge focus that they’ve put in over the last six months.

I think a lot of these companies are working hard on accessibility and the biggest thing I would say is the more they can hear from the people who are their customers that it’s important, the faster they’re going to prioritize those fixes over other fixes. That’s what I would do first and then if you don’t get a good response, then that’s when you’re like, okay, well, now you quote, vote with your wallet.

But I would try to go to them first and see if they’ll fix the things and then if they won’t, then choose a different solution that is willing to commit to accessibility. I like your point, Gen. If they have accessibility information on their website, that is a good sign over an alternative that doesn’t.

>> GEN: The ones who don’t have it need to definitely get it up in the near future.

>> AMBER: We are about at time. I want to go real quick through the– and probably this is a quick one, on the date pickers where they’re not accessible, can you provide an example of an alternative?

>> GEN: Most of them, if the date picker, the big giant date picker is not accessible, what you can use is many of them have a text field alternative and that is a text field and it just uses– I’m blanking on the word. A pattern.

>> AMBER: It’s like a date format pattern?

>> GEN: It uses a pattern recognition, which is very easy to do with text fields and so in Gravity Forms specifically, there is input and you mark that you want to– I don’t remember the exact name for it, but it’s a pattern and then there’s an option for date. Then you just use that.

>> AMBER: You can also use the Gravity Forms day field and turn off the date picker. Then it’s just a field you type in. They also have one where it separates out So it’s month, day, and year. It actually creates three different fields. Daniel said, for any of the three– and maybe we could just real quick go around, which form builders do you personally use when building forms? Kevin, do you have WordPress websites that you maintain and any form builders that you use personally?

>> KEVIN: Not really for myself. UFA hasn’t had a ton of that yet in terms of stuff with WordPress clients and forms. It’s come up a little bit, but we haven’t really gotten too much into the plugin game yet so this has actually been informative for me as well.

>> AMBER: What do you use, Gen?

>> GEN: I have a number of maintenance clients. We have Fluent Forms, we have a couple of old sites that are still using Forminator. Gravity Forms is what I use for anything that needs to be complicated. I just did a super complex big thing spreadsheet pipe into a custom JavaScript that then pipes over to a Gravity Forms. Then I do have WS on a couple of sites.

>> AMBER: You’ve got experience with a lot of them.

>> GEN: I have used in the past every single plugin here.

>> AMBER: Great.

>> KEVIN: I know this isn’t always feasible, but I don’t know. I do like Google Forms, especially– I mean, it’s not always possible, especially for more complicated situations but Google Forms, based on my experience and doing stuff with users is never-

>> GEN: Yes, they have labels and inputs.

>> KEVIN: -a bad idea. If that’s all you need, yes, it’s not bad.

>> AMBER: We’re pretty much out of time but can we just give a quick yay or nay on using an overlay or a JavaScript plugin to add a compliance web layer to the website?

>> KEVIN: No,

>> GEN: Nay, never.

>> AMBER: Everybody says nay. We did get that answered. Not a great option. If you want to learn more, go to overlyfactsheet.com. Gen and Kevin, where can people get in touch with you if they want to follow up?

>> GEN: For me, it is the Easy A11Y Guide website, which is easy, A-1-1-Y, guide.com.

>> KEVIN: For me, UFA, Unlocked Freedom Access, is a little bit newer. Our website is kind of still in the works. People can email me. Just my first and last, Kevin– I don’t know– should I type it or say it? I don’t know what–

>> GEN: I’ve also got a link to your LinkedIn profile.

>> KEVIN: Oh, well. That’s fine. Go there.

>> AMBER: Is LinkedIn good?

>> KEVIN: Yes, LinkedIn’s fine. Do that. It’s easy.

>> AMBER: Okay. Kevin Andrews on LinkedIn and we’ll get– Gen just posted it in the chat for everyone if they want it.

>> GEN: It’s also with the slides and links for the presentation is Kevin’s LinkedIn.

>> AMBER: Great. Thank you both so much and thank you everyone for attending. Have a great day.

>> KEVIN: Thanks.

>> CHRIS: Thanks for listening to Accessibility Craft. If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find Accessibility Craft on Apple podcasts, Spotify, and more. And if building accessibility awareness is important to you, please consider rating Accessibility Craft five stars on Apple podcasts. Accessibility Craft is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we helped make 1000s of WordPress websites more accessible at equalizedigital.com.