How Accessible are WordPress Forms by Default? with Gen Herres

>> AMBER HINDS: Welcome to WordPress Accessibility Day. How accessible are WordPress forms by default? With speakers Gen Herres, owner of Anphira, and Kevin Andrews, independent accessibility consultant and owner at Unlocked Freedom Access. A few announcements before we get started. If you haven’t been before, we have a Facebook group that you can use to connect between meetups. You can find it if you go to cacebook.com/groups/wordpress.accessibility or you can just search WordPress accessibility on Facebook and find the group that way.

It’s a great way to connect with people in between events, share things you’re working on, ask for advice, help other people with accessibility in WordPress. If you are interested in finding other upcoming events or you want to find the recording from this event or future events, you can go to equalizedigital.com/meetup. This is being recorded. It will take us about two weeks to edit the video, get corrected captions and a full transcript, and then we will post it up on that page on our website.

If you want to get notified via email, then we highly recommend that you join our email list, which you can do if you go to equalizedigital.com/focus-state. We send out upcoming event reminders and we send a weekly newsletter on Wednesdays that includes news related to web accessibility from all around the web and it will include the links when the recording for this meetup is available. The other way that you can catch meetups is in audio-only format on our podcast, which you can find at accessibilitycraft.com.

We are seeking additional sponsors for the meetup. This is part of the official WordPress meetups program, but the community foundation told us that unfortunately, they don’t have the budget to pay for captioning or sign language interpretation, both of which we have today. We needed to go out and find sponsors. If your company or you would be interested in helping to support having these accessibility features at our meetup, we would very much appreciate it. You can get in contact with myself or Pella if you email us at meetup@equalizedigital.com and we can share information about sponsorship with you.

You can also find that on the meetup webpage. There’s a link over to information about sponsorships. You can also email us at that same email address if you have any suggestions for topics that you would like to learn if you would be interested in speaking, we are always looking for speaking, or if you need any additional accommodations to make the meetup work for you. Who am I? I’ve been talking at you. I am Amber Hinds. I’m the CEO of a company called Equalize Digital. We are the organizers of the WordPress accessibility meetup.

Today we are also the caption sponsor because we did not have a separate caption sponsor, so we are covering the cost of captions. Equalize Digital is a mission-driven organization and a corporate member of the IAAP. We are focused on WordPress accessibility. We have a plugin, Accessibility Checker, which scans WordPress websites for accessibility problems and puts reports in the admin and on the front end of the website with the goal of making building accessible websites easier. You can learn more about us or our plugin if you go to equalizedigital.com. If you are a X or Twitter person, you can tweet us on X @equalizedigital.

We do have a sponsor for our sign language interpretation today. If you have not found the sign language interpretation, you can go in the Zoom bar. There is a globe and it should say interpretation on it. That will allow you to open up the interpretation in a separate window. Then you can see as things are signed out. Our interpretation today has very generously been covered by Ninja Forms. Ninja Forms is one of WordPress’s oldest form-building plugins. They are proud to serve users from around the world, from all walks of life, and from different stages of online growth.

From small businesses and local nonprofits that make up the core Ninja Forms user base to universities, hospitals, and even Fortune 500 companies, Ninja Forms will scale with you from startup to wherever you are aiming for. Thank you. Huge shout out to Ninja Forms for sponsoring our sign language interpretation today. You can learn more about Ninja Forms if you go to ninjfForms.com. We always encourage people to say thank you to them. They are on X @NinjaForms, also on LinkedIn. If you want to go and thank them for sponsoring sign language interpretation, it helps to let them know that it makes a difference that they have helped to make this more accessible. Thank you to Ninja Forms.

I have a couple of upcoming events for Meetup that I want to tease or let you know about. On Monday, October 21st at 7:00 PM Central Time, Ricky Onsman from TPGI will be presenting about PDF accessibility on the web, tricks, and traps. If you’re interested in PDF accessibility, that will be a great Meetup to tune in for. Then on Thursday, November 7th at 10:00 AM Central Time, so the same time slot next month, Ron and Kevin from CodeGeek are going to be presenting on building an accessible and highly usable transportation website.

Specifically, they’re going to be sharing a bunch of work that they put into their bus routes schedule table that allows people in the town that they worked on the website for to view and understand the schedules for the buses in that town, including with screen readers and all sorts of other assistive technology. It should be a very interesting case study type of presentation. Then the big event that is happening next week is WordPress Accessibility Day 2024. WordPress Accessibility Day is a free 24-hour virtual conference. It’s going to start next Wednesday, the 9th at, for me, it’s 9:45 AM Central Time, and it will go for a full 24 hours. It will be held on Zoom with live captions and sign language interpretation.

Registration costs absolutely nothing. Please go register if you have not yet. You can do that if you go to 2024.wpaccessibility.day. I am very excited to introduce today’s speakers, Gen Herres and Kevin Andrews. Gen is an experienced WordPress developer, a DHS-trusted tester for Section 508, a well-known speaker, and an accessibility advocate. She also organizes the Baltimore WordPress Meetup Group. Kevin is a certified web accessibility specialist, deeply committed to going beyond mere compliance. Kevin has a strong background in WCAG, Section 508, and accessibility standards.

I’m going to add spotlights and pull both of you up here and then I will stop sharing my screen and let you take over. We will be using the Q&A feature during today’s webinar, so I am going to go off-screen and let Gen and Kevin present. If you have any questions, please post them in the Q&A, and I will come back at the end and make sure that they get those answered. Thanks so much, Gen and Kevin. Welcome and take it away.

>> 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. 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.

• View “How Accessible are WordPress Forms by Default?” Google Slides.
• Access “How Accessible are WordPress Forms by Default?” Resources Page.