Learning to be Accessible, Perspective from a WordPress Product Company: Quay Morgan

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup, Learning to be Accessible, Perspectives from a WordPress Product Company, with Quay Morgan, brand director at Ninja Forms. Before we get started, I have a few announcements that I want to share. First of all, our Facebook group is a great place to connect between meetups. You can find it if you search WordPress Accessibility on Facebook, or if you go to facebook.com/groups/wordpress.accessibility. You can share what you’re working on, ask questions, get plug-in recommendations, help other people with accessibility. We welcome everyone to join that group. Everyone always asks, is this being recorded? Yes, it is being recorded. You can find upcoming events and past recordings all in one place if you go to equalizedigital.com/meetup. It takes us about two weeks to edit the video and get corrected captions and a full transcript available. Once we have that, then we will post up the recording. You can find it on that page if you bookmark it, or the other way to get notified when the recording is available is to join our email list. You can join our email list at equalizedigital.com/focus-state. We send out event announcements so you get notified of upcoming webinars.

We also send out a weekly on Wednesday’s email newsletter that rounds up accessibility news from around the web. That is where we post links when we have the recordings available. You can also tune into our podcast, Accessibility Craft, which is available in audio, captioned video format, and also as a fully written transcript that is transcribed by a human, at accessibilitycraft.com. We will post the audio from this meetup there as well, if you prefer to listen to it.

We are seeking some additional sponsors for the meetup. I think we have a live caption sponsorship opening up for the fall. Looking for someone to help with covering the cost of live captions. Then of course, always appreciate assistance with the cost of transcription and things after the meetups are done for the recordings. If you are interested in sponsoring the meetup, please contact us. You can email meetup@equalizedigital.com. That goes to myself and Paula, my co-organizer. We’d be happy to share information with you. This is part of the official meetup program.

Unfortunately, the Meetup Community Foundation doesn’t have the budget to cover the cost of accessibility enhancements for our meetup groups, so they said go out and find sponsors. That’s why I give this pitch at every meetup. You can also email that same email address if you have topics that you’re interested in learning about, if there’s any additional accommodations that you would like us to make to make the meetup work better for you, or if you are interested in speaking. We, I think, have all of our speakers lined up for the year, which is super exciting.

We are pretty soon going to be starting to think about what Q1 of next year looks like. If you think you might be interested in speaking early next year, please do email us. Who am I? I am Amber Hinds. I am the lead organizer for WordPress Accessibility Meetup, and I’m the CEO of a company called Equalize Digital. We are a mission-driven organization and a corporate member of the IAAP, which is the International Association of Accessibility Professionals. We’re focused on WordPress accessibility, and we have a WordPress plugin accessibility checker that scans for accessibility problems and provides reports on the post-edit screen to help make building accessible websites easier.

I’ve said our website a lot, so I’m not going to say it again. The social platform we are most active on is X, and you can find us @equalizedigital on X, formerly known as Twitter. I guess we don’t need to say that anymore. We have two sponsors that I want to thank today. GoDaddy is sponsoring the live captions that we have for this event. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience. GoDaddy provides a managed WordPress experience that is as easy as it is effective.

The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly, with automated backups, updates, and malware removal so that our pros can spend less time on monotonous maintenance, and more time building their businesses. If you want to learn more about GoDaddy, please go to godaddy.com. We always encourage people to send a quick tweet or a LinkedIn message thanking our sponsors and letting them know that their sponsorship makes a difference as in is important, helps people enjoy meetup.

It also tells them that I did what I promised I would do. If you are willing to go tweet a quick thank you to GoDaddy, or tag them in a LinkedIn message and thank them for a live caption sponsoring, you can tag them at GoDaddy. Of course, we have our American Sign Language interpretation sponsor today, which I’m so happy about, and that is Ninja Forms. Ninja Forms is one of WordPress’s oldest form builders. They are proud to serve users from around the world, from all walks of life, and from different stages of online growth.

From the 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’re aiming for. You can learn more about Ninja Forms if you go to ninjaforms.com. Please do tweet or LinkedIn message them a thank you for sponsoring the interpretation today. You can find them on X @ninjaforms.

If you missed it when I first said this at the very beginning, if you weren’t in yet, if you’re interested in seeing the interpretation, you can find that at the bottom of your screen. There’s an icon button that looks a little bit like a globe. If you click on that, you can then toggle on American Sign Language and find the interpretation. You can watch it. You can open it in another window and put it wherever you want on your monitor or even on a second monitor.

There are a couple of upcoming events that I want to make sure everyone is aware of. A big thing to note is our normal third Monday of the month event that would be on September 16th at 7:00 PM is canceled, because that is the week of WordCamp US. You can cross that off on your calendar, we won’t be meeting then. We will be back on Thursday, October 3rd at 10:00 AM Central, so the same time slot, October 3rd. The presentation will be Navigating the Future: Using WordPress Menu Blocks That Work for Everyone. The speakers will be Michaela Lederman and Eli Frigoli.

Then on Monday, October 21st at 7:00 PM Central time, or for our friends in Australia, that’s 10:00 AM, Ricky Onsman from TPGI will be presenting PDF Accessibility on the Web: Tricks and Traps. The other big event that is happening soon, please go register, is WordPress Accessibility Day 2024. WordPress Accessibility Day is a single-track 24-hour virtual conference. It is totally free. You can make a donation if you want, it’s a nonprofit organization, or you can join for free. You do have to register though, because it is held on Zoom and that is how you get access to Zoom.

We will have live captions and also American Sign Language interpretation. That event is October 9th through 10th. No matter where you are in the world, there’s going to be a talk during your business hours, and you can register if you go to 2024.wordpressaccessibili– sorry. I do this every time because I’m looking at the logo. [chuckles] Try again. I need to put the URL on this slide so I can read it. You can register if you go to 2024.wpaccessibility.day.

I am very excited to introduce today’s sponsor, and of course, his company very generously is a sponsor, but also today’s speaker, Quay Morgan. Quay is the brand director at Ninja Forms, where he’s worked for the better part of the last 10 years in various roles. He’s a former science teacher and got pulled into WordPress through a friend with a little plug-in that started taking off. Welcome, Quay. We’re very excited to have you.

>> QUAY MORGAN: Thank you. Thank you for having me. Hello to everybody.

>> AMBER: I have stopped sharing. I am going to turn off my camera and microphone and let you take it away. For everyone, just so everyone is aware, we do have the Q&A module activated for this webinar. If you have questions, please post them in there. I will join at the end to pass those along to Quay. Thank you.

>> QUAY: Thank you. Thanks, again, for having me. I tried to jump the gun there. I was a little bit excited to see somebody from Alpharetta. Extra hello to you. You’re about 45 minutes south of me. I’m in the Chattanooga area. Hello to everybody. I will admit to being just a little bit nervous to stand in front of people passionate about accessibility when as a product, we are not where we want to be yet. We have done a lot of work recently though. I think it might be helpful to share my experiences so far. I hope anyway that it will be helpful to share our experiences.

The more people that I’ve talked to about accessibility, the more that I get the impression that a lot of WordPress companies have been slow to act for a lot of the same reasons that we have been at Ninja Forms. I would like other companies to be able to learn from our experiences because I know that there’s a whole awful lot of us that are not where we want to be or need to be yet. I’d also like to convey to the accessibility community in general what our hurdles have been. I know that accessibility is extraordinarily important to you, and that a lot of your work includes awareness and raising awareness, and helping people get past the hurdles that we’ve recently been experiencing ourselves.

Hopefully, the perspective that I can offer is helpful in encouraging others to get on board and get started if they haven’t already, and get further if they have gotten started. Reflecting back over the last 10 years or so that I’ve been with the company, two things have stood out with regard to accessibility. Those things are awareness, not a lack of awareness, but the nature or the kind of awareness that’s out there, and the perceived complexity of getting your product accessible or moving towards a place where you can maintain an accessible product.

I’d like to unpack both of those things, awareness and complexity or perception of complexity, with a little bit of background. Shallow awareness is common in my experience. What I mean by that is awareness of accessibility as a set of technical requirements only. It’s hard to not be aware of accessibility, period. We hear about it. We’ve heard about it. There are regulations coming over the horizon that turn the torque up on people to get there if they haven’t already. It’s not that people aren’t aware of accessibility.

The nature of that awareness is often just as a set of technical requirements to be attained. Years ago when I started with Ninja Forms, I did almost exclusively was content creation and support. Spent a lot of time reading comments on blog articles that our readers would leave, and questions in our support queues. We did get lots of questions about accessibility. Are you WCAG 2 compliant? When will you be fully WCAG 2 compliant? Can we have an area label added to this or that?

It was obviously something that was important to these folks. From our seat, it was almost always presented just as a set of technical requirements or compliance concerns. The interest seemed mostly limited to public sector orgs, which gave us too narrow of a perspective. It was usually presented to us as nice to have. Fine, if you don’t have that, we can have one of our developers add it on, et cetera. Which is a little bit strange to me looking back, realizing how important it is for certain institutions and organizations to be compliant.

That may be a matter of perception on the receiving end, my perception. This was our main point of contact with accessibility as a concern or as an interest. That’s how it came across in our perception, right or wrong. I think this level of exposure is pretty typical of product companies across the board. Not all, but fairly typical. We only never saw the layer in-between us and the real need. We only ever saw the companies and organizations talking to us about, we need this, we need that, would be nice if you could do this.

We never saw past that in our interactions to the individuals that rely on assistive technology to use the internet, to make full use of the internet. That is why I call that a shallow awareness. It’s just an awareness of the set of technical requirements. It lacks the awareness of the negative impact that inaccessibility has on individuals. It lacks the awareness of the harm, essentially, that we are causing others by having a product that is hard to use if you’re only sat down with a keyboard in front of you.

That’s practically impossible to use if you’re trying to use voiceover or similar technology to read because there’s no context for what’s on your screen. I want to be careful that I’m not offering any of this as an excuse, but context only. We were ignorant of the wider impact. We were ignorant of the impact of accessibility beyond our own users to the end users, to the people that they serve. That level of awareness, that has to evolve for, in my opinion, for adoption to be where it needs to be, where we’d all like it to be.

Product companies need to see accessibility as a technical requirement to their customers and have a deeper understanding of the people that it impacts beyond your own customer base. I don’t know how to do that at large, kind of sharing, reflecting. For me, personally, it was motivated by my own family. My son has special needs. He’s benefited greatly from, we’re in the United States, so from IDEA, from the Americans with Disabilities Act. He’s autistic, nonverbal. I’m no stranger there to pursuing appropriate accommodations, especially in education. Just in the context of, man, we go out to eat, and the man loves chicken tenders. I know pretty much everywhere has chicken tenders, but man, there’s a whole menu full of stuff right here. I can set that down in front of him, but unless it has pictures, he can’t parse what he wants to eat. It occurred to me at some point, that’s where my brain finally made the connection that this is not one-on-one what we’re talking about here, but it’s related.

The accommodations that my son needs to fully participate in a restaurant experience, it’s not completely different from the way we– our experience that we have online. If we’re not making accommodations, then not everybody is able to take full advantage of the technology in front of them. That is where we need people to move to for them to have a full awareness of the impact of accessibility. It’s not a feature set. It’s human decency. It’s about being able to give people what they need to make the most out of their experience online.

Something that I didn’t really pick up on until even later in the same train of thought is it’s not just a set of technical requirements, but it’s about being inclusive and making the online experience accommodating for everyone, cultural variations and the neurodivergent spectrum alike. I don’t know how to get people there, but it’s certainly what did it for me. It’s not that we didn’t care about people before then. We just didn’t realize this isn’t just a technical failing. This is really bad, we’ve got to fix this. We can’t have this knowledge now and go forward without doing something about it.

That was a very strong motivator for me and a very strong motivator for us. It’s my hope that if we can move other people to that level of awareness, then they would be far more motivated to do the right thing and to get our house in order, beyond awareness, related to but beyond, moving on to perceived complexity of taking on accessibility. As my awareness started to grow, as our awareness started to grow, we started having conversations about the technical side of accessibility. What is this going to look like? This is something that we have to tackle.

Now, what’s it going to look like to really dig into it? We ran into some early blockers. These all turned out to be misconceptions, fortunately. There were plenty of perceived early blockers. Again, my hope is in sharing some of this, we can help get people past this in a little bit more timely fashion than we did. Some of those include the notion that we can’t ever be accessible fully because it’s something that we don’t control. It’s something that we don’t control how our code is output on the front end of a website. We’re a form builder, but there are other people with this same–

A form, it goes on to the front end, and the theme is really what controls a lot of the presentation of the form on the page. Even if we designed our forms in a way that was fully accessible, which “fully accessible”, we really didn’t even understand at the time what– still it’s an evolving understanding, but certainly at the time didn’t have a concept really of what it meant to be fully accessible, if there even is such a thing. It’s an evolving process. We can’t control it. We can’t control what theme a person gets. There’s a whole lot of themes out there, and a whole lot of them, they’re not great.

What’s the use in putting all of this effort into it ourselves if the end output is not going to be what we want it to be because of another decision the user made? Again, these are misconceptions. These aren’t good notions to hold on to, but that was one of the things that was bantered about a lot early. Another is the complexity of accessibility, just as in terms of figuring out what do we do? What does accessible even look like? None of us in the company were really familiar with what it was like to use a screen reader or to navigate a website with only a keyboard on the technical side.

Well, what do we do? We go to the WCAG 2 site, and it is overwhelming. There’s a lot there. I can understand why there’s a lot there, but, man, it looks like a wilderness that’s going to be really, really difficult to navigate without a guide. Just figuring out where to get started, it’s pretty complex-looking. Turned out not to be as un-navigable as I was afraid it was, but it certainly looks that way. That leads to a perceived notion of expense that’s, in our case anyway, far out of line with reality. We thought, man, we’re going to have to outsource this, or we’re going to have to bring in a third-party agency in some form of long-term contract.

It’s going to be pricey. That’s not true or hasn’t been in our case, but the perception of it can certainly be a blocker, especially to smaller companies, as most WordPress product companies are. It turns out I don’t think of us as a huge company. We only have about, what, 15 or 20 folks working in the overall Saturday drive, which Ninja Forms is part of. Even for us, that was a little bit scary, like, all right, we’re going to have to budget for this. It turns out, we don’t. Not to the degree that we did. I can see a lot of people getting to that point and stopping because they look at it as a thing that we have neither the capacity nor the budget to take on, so we just can’t do anything about it.

Another misconception is that because we didn’t code Ninja Forms from the start with accessibility front and center, that we’ll have to rebuild everything in order to be accessible. It turns out that’s not the case either, but that was a fear we had. There’s also a binary perception of accessibility, that it’s only meaningful if we’re all the way there. Taking bite-sized chunks out of it doesn’t really matter until you get there, wherever there is. I don’t think that people understand that there’s lots of improvements, lots of incremental improvements that can be made, and with each increment you make the experience better for somebody, a lot of people on the other side of things.

Then not so much a blocker to get started, but the tendency to look at accessibility as a monolithic chunk of work. Back to the not being able to increment or take bite-sized pieces out to make it better. It’s one big thing that we’ve got to take care of. It’s not as much of a blocker to get started, but it can– it’s a notion that needs to be dispelled quickly or early on in the journey, because it’s very much– being accessible, I’ve learned it’s very much an evolving process. It’s not something that you attain, put it in the books, and walk away from.

It’s like maintenance on a home or a vehicle or something of that nature. If you’re really behind, yes, there’s a whole lot that’s got to be done. If I haven’t changed my oil in two years, I’ve probably got more than an oil change that I’m due for, right? You knock things out, and then you can continue on without it being this monolith that you’ve always got to push. Hopefully that makes sense. Getting past this for us was really, on our part, just stubbornness and a drive to make it better. Making it better is a company value that it’s been something that the owners have never stopped talking about since the very first day I started with Ninja Forms, and rightly so.

We’ve got to continue to evolve. We’ve got to continue to make things better. With the burgeoning awareness of the broader impact beyond the technical requirements, this just wasn’t anything that we could, “It’s too complicated, we’re not going to do anything about it.” We can’t do that. That’s not acceptable. We had to figure it out, so I just started plugging away and chipping at it. It felt like a guy with a hammer and a chisel working on a boulder for a while. We got past it.

We dove into parsing the WCAG 2 standards. I got lost and spent a lot of time roaming in circles for a while there, started collecting and organizing user requests. We have a spreadsheet that we keep all the feature requests, all the things that people want, wish, nice to have, this, that, and the other. Starting to see some patterns. That helped a lot in adding context to the technical stuff that we knew about, like real-world context of because this is lacking when I try to use the form using this technology, this is what it looks like for me.

We were able to start grouping things together, help me see an organizing pattern to follow when the big breakthrough for me really was discovering a W3C forms tutorial. That sounds like a simple thing, but that was the guide that we needed. It basically gave us a checklist of technical requirements that we could start with, to the best of our understanding. We didn’t understand everything on the list still, but it gave us a place to start and it gave us a map to move through things well. We started to approach things from the front-end display of our forms.

Figured that this is where we can make the biggest difference for the most people because we’re not talking about just things for our users and our customers, but, again, those end users, the real people out there using the forms across the world. If they’re able to move through it with– if there’s feedback or any other odd sounds on the line, I apologize. I just saw a bit of a comment there. There’s people and animals, and everything around here that may be making all kinds of odd noises at odd times. Apologies. Maybe my son humming to himself over here.

He’s watching Sonic the Hedgehog on the couch next to me. The front-end form display was where we figured we could make the biggest impact the fastest for the most people, so that’s where we started. We focused on the end user experience, navigating forms. We began that by developing a set of internal standards based on what we found between the W3C forms tutorial and the WCAG 2 standards. We need to make our own set of internal standards that we can hold ourselves to over time. We ran those internal standards through an accessibility professional, [inaudible], if anybody’s familiar with her.

She’s been a grand help for us in that. We conducted an internal audit then using those standards of all the fields on the front end. We cataloged everything that we did well and everything that we didn’t do well. Turns out it was a fair mix. We were doing some things great, but it was mostly by accident or through the grace of having clever developers that anticipated some of this back quite a long while ago. Yes, that is her. Thank you. We started fixing things just one at a time. I got together with our engineers and said, here is our internal standards.

Most of the work, I didn’t– I did not create the internal standards. This was between me and our engineers, and our engineers did the bulk of the work. They had an idea then going in, here are our standards, here’s how our fields line up against those standards right now, so we know exactly what we have to fix. Let’s start to group these things in the order that it makes the most sense to begin working on and tackle them one by one. We started that work maybe earlier this year. Out of 27 fields that are available for users to choose from in the core plug-in, about 21 of those now meet those standards.

That’s a big improvement. We’re not where we want to be yet. We got a long way to go. Front-end form display is just one aspect of it. We also need to pay attention to our plug-in admin in WordPress and our form builder so that folks can not just enjoy forms on the end user end, but also build forms and navigate the admin and the WordPress admin. That’s looking like another wilderness. Hopefully, given my experience with the front-end form display, it’s not as bad as it looks. Once we get into it, we can do this thing. It’s interesting trying to figure it all out.

We also need to get our website in order and other satellite communications like email and YouTube. We’ve begun an expedition in our internal parlance expedition to rebuild our website almost from scratch. We know we have tons of accessibility issues there. I had never used a screen reader in getting onto our website or a page with our form on it. It was very enlightening. More people should do that. Voiceover in Mac is what I used. Oh, man. We got some work to do. We’re looking ahead to fixing that shortly and tackling the admin of our plug-in.

We’re doing this with the recognition that it’s not just one-time work. It’s long overdue maintenance that we need to get in place and then figure out a plan for moving forward and keeping it that way, and continuing to evolve. Regression testing is one example of that in our front-end form display. All over our fields, as we fix things, we put regression testing in to make sure that we don’t break them down the road.

That’s bringing it back to the top, fostering full awareness, not just awareness of the technical requirements or regulations that are coming down the line or compliance concerns of users, but the full awareness that includes an awareness of the impact that we’re having on real people by being inaccessible, the negative impact that we’re having on real people. This needs to be front and center more than I’ve seen it, and how to get other people past the perceived complexity.

I’m not sure other than talking about it and say, hey, look, this is what we figured out, and it wasn’t hardly as bad as we thought it was going to be at first. It’s a work in progress. Hopefully this helps. This is about all I have prepared to speak on, Amber. I could probably ramble for a little while longer, but I understand that there’s a Q&A bit, so I’ll shush and let people ask questions.

[silence]

>> AMBER: Sorry, it always takes me a moment to find myself again and put myself back up there. I wanted to start by just– I think it’s in your comments, you were seeing some of that, but just in case you didn’t see any of them, Richard said, thank you for embracing progress over perfection and not allowing, as you were talking about, it feels overwhelming, like, oh, we just have to do it perfect or do it all. Talking about that is really meaningful. I appreciate you highlighting that as well. Then Jeffrey said thank you for sharing about your family and experiences, Quay.

Thank you very much. I really do think that as this goes, it really is a journey. That’s something that as us as an agency, on our agency side, that we have thought a lot about and why we try and advocate for, even if it’s just a tiny bit, like doing a little bit of testing and fixing each month and just doing a little bit over time. Because as you said, I think those small changes can build up to having a really big impact. Sometimes a small change, like just fixing your navigation menu to have the drop-downs visual when you tab to them, that can have a major impact even though it’s just one change and not everything’s fixed.

A lot of what you shared really resonated with me. It looks like we just have one question right now. I have a few that I wanted to follow up with. For anyone, if you do have questions that you want to ask Quay, please post them in the Q&A, and we will ask him. The first one is from Mark. Mark says, “I’m curious how much of the feedback from self-identifying users with disabilities impacted your development process? Did you track how much of your feedback were from self-identifying users with disabilities versus other types of users like coders, developers, et cetera?”

>> QUAY: We did not track that, no. Looking back at that, that’s probably a dumb call on our part. We categorized everything that looked remotely like accessibility. Keep in mind, this is multiple people across the team that are in support and reading these support tickets. Anything that remotely sounded like it might be accessibility-related was categorized in the sheet as an accessibility-related item. I went back and reviewed those.

Unfortunately, we had the links to the actual tickets with the actual users talking. I wasn’t just reading a synopsis in the spreadsheet. It wasn’t always clear. For the most part, it seemed to be companies, like I said earlier, mostly organizations, public entities that are more tightly regulated and in some cases just cannot use a product that is not WCAG 2 compliant. That was the bulk. Were there folks in there that were self-identifying? I honestly don’t recall. Probably.

>> AMBER: I expect most of your feedback probably came from developers or a customer who had had their website audited and then they submitted. The good thing or the downside, I don’t know how you look at it, but usually if we visit a website, unless you’re someone who understands code and you inspect the code, you don’t actually know what technology is building the form on that website because it’s not like they’re– unless you have a janky one where you’ve embedded an iframe and it says embedded from Google Forms.

Otherwise, you have no idea what’s building that. I think a lot of users wouldn’t even know which company to reach out to. They just reach out to the website owner probably directly. I was curious about that. Have you explored having users come in and test forms or test your own website? Is that something you’ve thought about doing?

>> QUAY: There’s not a mass invite for people to come in and test. That’s an interesting idea. I mentioned running those internal standards through an accessibility expert, an outside professional. We will be working closely with her as we redesign the website. She will certainly be testing. That will be one of the primary areas of feedback that we’re looking for from her. It was slightly off-topic, but we’ve got this idea that one of the owners, James, very succinctly put together, we want everything to be fab.

We want it to be fast, accessible, and beautiful. That’s the one big standard for our website as we go through it. It’s right there in the core requirement for the new site. We will have somebody paying attention to it. I haven’t really thought about having people that use these technologies every day. That’s actually a really good idea. I’m going to steal that and talk about it some more.

>> AMBER: You should. Take internally. I’m sure that there are people in the WordPress community, certainly in the WordPress accessibility Facebook group, I’ll just give that little pitch there, there are blind people in that community, and you could probably post if that was something. Also, I just think you might have people in your Ninja Forms users already that if you were to send– I don’t know if you send regular emails out to your users. You could maybe send an email out that says, we’re going to have an upcoming testing opportunity. We’re looking for people who use screen readers every day, that sort of thing. Maybe they will talk to you.

>> QUAY: Absolutely. That’s a really good idea. I have made a note. I’m going to follow up on that. That’s a cool idea.

>> AMBER: I’m curious if you could share one or two concrete examples of maybe difficulties that you ran into with making the front end of some of the fields accessible and how you approached resolving those difficulties. I’ve seen some forms, and not on yours, but where they have a searchable combo box. That’s very not accessible. Then, there’s conversations about can we make it accessible or things like that. Sometimes product owners aren’t even sure, this seems really difficult, how would I even figure out how to tackle it? I’m wondering if you have any thoughts you could share on that with maybe a specific example.

>> QUAY: I wish I could. As I’m thinking about it, I am not an engineer, not a developer. I couldn’t code my way out of anything at all. I have some very, very smart and talented engineers on the product team. Most of my involvement in this has been to try to take what we saw as a hugely complex topic and bring it together into a actionable course of action plan. That process was a lot of me writing up, this is what I want to see, passing that off to an engineer or engineers, and then taking that and saying, this is how we can approach this best.

From listening to them talk about actual complexity, I know our star rating field has been a beast. That’s one of the ones that remain as. It’s not in good shape right now. Then we have a select image field that’s been a bear to wrestle with, and our date-time field have been– We intentionally put those off until near the end of our front-end accessibility expedition, because we knew that they were going to take– pretty much everything else we could bundle up in groups and say we’re going to work on this group of work and this group of work, those three fields specifically we’ve set aside for this needs its own track, this needs its own proposal and focused work, this one field.

Those are the three fields, date, time, the select image, and the star rating field that we’re giving that treatment. Technically, why they’re complex enough that they need to be treated that way? Because my engineer told me that’s the best way to approach it. Sorry.

>> AMBER: I’m also not a developer, so I frequently have things where I’m just like, someone told me this is the way it goes. I believe them.

>> QUAY: They’re really, really smart in that regard. If they tell me this is how we’re going to approach work, cool, let’s do it. I don’t tend to dig into the– not that I’d understand it if I did.

>> AMBER: I think something that’s interesting, too, about those particular fields, maybe thinking about in contrast to, for example, an email field or just a plain text field, is that they might also be used less in forms. From a prioritization standpoint, sometimes maybe it makes sense to fix the name field and the email field first because you know, almost every form is going to have those fields, so you can have a bigger impact in that way. Versus the star rating maybe isn’t as commonly used.

>> QUAY: That is true. If it might help with context here, we were pretty convinced going in that we’re not going to be able to get all of our fields behaving the way we want them to on the front end without diving into the code and rewriting fundamentally how we’ve constructed some of these fields. We took that as a given going into this project that not everything was going to be able to be done and what we’re working on is a first pass that we’re going to have to rebuild the plug-in anyway. Some of this is going to have to wait till that. Turns out that that’s not been true of anything.

>> AMBER: That’s good to know. It was easier than you thought it would be.

>> QUAY: Yes. Actual complexity versus perceived complexity. There’s a big gulf there.

>> AMBER: Mark asked, “What was the tipping point that got two members of your team on board to solving accessibility issues together, assuming that point is the snowball effect for your company as a whole?”

>> QUAY: I’m looking for that question. Could you repeat it?

>> AMBER: I know you talked a little bit about your personal experience with your son, and making the connection that some of the things he’s experienced, drawing that connection to your company and the forms and the internet. I think he’s asking, so that was a connection you had. Was there a tipping point for the company as a whole or something that got more than one person interested and then it became the snowball where it becomes part of the culture of the company?

>> QUAY: Yes. It was talking about the awareness of what this is actually because the whole company, this shallow awareness that I spoke to, that was pretty much all of our– we’re all pretty normative folks. Nobody in the company relies on, for example, keyboard-only inputters, frame readers. It it was ignorance, plain and simple. It was ignorance of the impact that being inaccessible had that meant we hadn’t done as much as we should have been doing all these years. It was the awareness of, this isn’t– try to sit down with Ninja Forms on a page and go grab NVDA if you’re on Windows, or VoiceOver if you’re on Mac and just sit there and try to use a form.

Throw a few radio list fields and select fields and things like this. Close your eyes and try to navigate that thing. Of course, there’s a little bit of a learning curve. It was for me, anyway, to get familiar with VoiceOver and how it functioned. I had to go through the Mac tutorial a few times on it. After I got comfortable, I could fairly well close my eyes, navigate a page and be okay. If we put a form on the page with especially particular fields on there, there is no context for what you were doing. You hit the form and you got lost. Putting that in front of people and, here, try this, see what it’s like for each and every individual out there trying to–

We’ve got about 800,000 active installs. There’s a whole lot of people out there that are requiring– that need this technology to be able to use our forms. Look at what the experience is like for these folks. It didn’t take much from there. My role as brand director is to bring things to the attention of the team that are directions that we need to be heading in. This was a really easy sell. Once everybody realized what the experience was like, it started to go pretty quickly.

>> AMBER: I think that’s a really interesting or a good way of saying this. Giving people the firsthand experience maybe is a good way to reach that tipping point internally if you’re someone that’s trying to advocate for this in your company. I know I say a lot. If I give podcast interviews, I’ll tell people, just turn your mouse off, put it in a drawer, and try using your entire website with only your keyboard.

Can you actually do it? I wonder almost if product companies– this should be a thing where maybe on Global Accessibility Awareness Day, you just say once a year, we’re going to make everyone literally experience. You have to use our product today with a screen reader, like what you’re saying, because maybe that will be the tipping point that makes people realize, I got frustrated and I can see my screen.

>> QUAY: It’s what I was trying to get at. Once you get that level of awareness, it’s hard to say we’re not going to-

>> AMBER: To ignore it.

>> QUAY: -do anything about this. There are certainly people in the world that just won’t care, but there are a whole lot of people that will that are just in a position of ignorance. It’s very easy to be aware of accessibility in the technology space, but I think that deeper understanding of impact, human impact, is lacking.

>> AMBER: James chimed in in the chat and said that your leadership has been integral to bringing this to the level of importance that it deserves. I think we should all applaud you on that.

>> QUAY: Thanks.

>> AMBER: Richard asked if you are sharing your experience with other product development companies, and if so, how? Specifically, that it’s not as tough or as overwhelming as you thought. Obviously, you’re here now sharing. Have you or has Ninja Forms done anything extra or written any blog posts or anything out there that we could share with folks about this experience?

>> QUAY: This is my first foray into that quest, if you will, right now. This is the very first thing that I’ve done external to the company on this topic. I sure would like to do a whole lot more about it. I am not a part of the deaf community. I’m not a part of the visually impaired community or what have you, but I absolutely do understand pursuing appropriate accommodations. That’s something I’ve been passionate about for a long time. I just never made the connection.

Now that the connection has been made, man, the world could use a little bit more of that. I don’t know exactly where to get started, except for, I knew Chris and Amber, you did this and the WP Accessibility Meetup. While that sounds like a fair starting point, what’s next? I’m not real sure, maybe. Hoping to get some recommendations, even. We’ll see. This won’t be the last of it.

>> AMBER: Thank you. We really appreciate you coming here. Of course, we’ll be sharing this, and hopefully people will listen to it in audio form on the podcast, or see it on YouTube or something, and get that message. I would say though, for sure, ideas on that front, blog post on the Ninja Forms blog would be great, talking about that. Probably good marketing for you all as well to make people aware of the fact that Ninja Forms fields are more accessible and can be used on websites that have the requirements that you mentioned.

Maureen asked, “Is it possible to tell us WordPress developers which fields have been made accessible and which ones are not so that they can avoid using the non-accessible ones for building?” This leads me to a question of, are you putting any notices in the admin on those fields that say, for things like if someone leaves a label blank, do you warn them, you really need to have a label on this, you shouldn’t leave the field blank?

>> QUAY: That is one of those awareness of technical requirements only. How to better advocate through our implementation in the plug-in is absolutely something that is on my radar. That was one label specifically was something that [inaudible] pointed out to me whenever she was doing her audit. She did an audit both of the plug-in and our standards. That was the example that she used of where we could improve on communicating how to be– education. We know that now. We didn’t, not too long ago, but we do now. That is something that we can use the plug-in to educate on what shape that’s going to take.

How we’re going to implement that, I’m not real sure right now. That’s something that I would absolutely like to do because that’s part of the evolving nature of it, I believe, because the 27 fields that are in Ninja Forms right now are not going to be the same 27 fields a year from now, two, three, five years from now. How people can best make use of these fields, that’s part of it. We don’t have anything in there right now. The three fields, to directly answer the first part of that The three fields that you want to steer away from right now, if you absolutely need your form to be front and accessible that you’re building for a client, the star rating field, the select image field, and the date-time field, everything else. Our submit field has a couple. I’m looking at a spreadsheet that my engineer provided me with back a while ago that we’ve been working on. The submit field, when you tab into the element, not when there has been an error on the form. If there’s an error on the form when you tab into the submit button right now, it doesn’t tell you where the error is. We need to fix that. There are a couple of other fields. The checkbox list field, the notification of the label is not clear, and the notification of field type is not clear when the label is hidden. There’s a couple little issues with other fields, little in terms of the technical overhead. It’s going to take us to fix it, not necessarily the impact. The submit field and the checkbox list field, conditionally, in niche circumstances, are going to have a couple of little problems. Date-time, select image, and star rating are the only three fields that are like, “Oh, gosh, this is a real pain to use right now or unusable [inaudible].”

>> AMBER: Great. I think that’s good progress, though, going from where you were to now, and only having three that are on your to-do list as opposed to the beginning. What was the timeline on that journey? How long did that take to get to where you are right now?

>> QUAY: Oh, I’d have to dig through Basecamp to tell you exactly whenever we started working with the internal standards. That was the first thing we started to develop. I think that I asked our engineering team to develop those internal standards based on some specific parts of the WCAG 2 guidelines and that W3C forms accessibility tutorial back in March of this year.

>> AMBER: That’s fast progress.

>> QUAY: Pretty fast. Yes. We’ve benefited from a pretty amazing project management system that our owners have put together, cobbled, tailor-made for us that we’re trialing this year. That’s part of being able to move a lot faster than we have in the past. It’s not as hard as we thought it was going to be.

>> AMBER: I’m really glad to hear that. Hopefully, other product leads or owners or anyone working on a product takes that to heart and is willing to dive in and maybe not be as afraid of it based on your example. Thank you. I don’t see any other questions. I think we’re going to let everybody get back to their day a little bit early. Thank you again so much for sharing your experience and answering everyone’s questions. Can you give a quick blurb on where people can find you again, Quay, if they want to follow up with you personally or Ninja Forms? Whatever works best.

>> QUAY: You can add Ninja Forms on X. That will inevitably get to me. I’m also on LinkedIn. There’s not a whole lot of Quay Morgans in the world. If you search me on LinkedIn, I should be there. I can always provide a link to my profile there if you want to welcome anybody to DM me with follow-up questions or what have you.

>> AMBER: Great. Of course, Ninja Forms’ website, if you want to check out the plug-in, is ninjaforms.com. I’m going to just give a minute for our interpretation to finish, and then I will end it. Everyone, have a great day. Remember, no meetup on our normal Monday meetup, but we will be back next month, and we will also have sign language interpretation next month.