WordPress Accessibility Showcase for Global Accessibility Awareness Day (GAAD)

>> AMBER HINDS: Welcome to our WordPress Accessibility Day Showcase in honor of Global Accessibility Awareness Day 2024. I’m so excited to have the wonderful representatives that we have here today from various plugin and theme companies. As we were discussing what we wanted to do for this year’s GAAD event, we were talking about how it would be really nice to have some people come that are either just starting out in their accessibility journey with their products or are further along. I’m never going to say done because I don’t think we ever are. In fact, in our plugin, we released a tab fix for our tabs in our meta box this week.

>> STEVE JONES: Yesterday.

>> AMBER: Yesterday, says Steve. I’m very excited. I’m hoping that it might introduce you to some new products or make you aware of some accessibility features and products you weren’t aware of. If you are a plugin or theme developer, or you’re building custom plugins and themes for clients, I’m hoping it might inspire you to think about ways that you can improve the accessibility in what you’re building. I’m going to do slightly fewer announcements this time just because we don’t have as much time.

We are the caption sponsor for today. If you’re not familiar with me, I’m Amber Hinds. I’m the CEO of a company called Equalize Digital. We are a mission-driven organization that focuses on WordPress accessibility, and we make the Accessibility Checker plugin, which you’ll learn more about in just a little bit. We are doing a 25% discount now through May 23rd. You can use coupon code GAAD24, that the number 2 and 4, to get that discount. If you’ve been thinking about buying Accessibility Checker, now is a great time to do it.

I have two upcoming events I want to tease. Our next regular meetup is on Monday, May 20th at 7 PM Central Time. Simon Minor, he’s going to be talking about building empathy with stakeholders to drive accessibility. You can learn more about that event and register for it on our website equalizedigital.com/meetup. The other event I want to shout out is WordPress Accessibility Day. I and we also have on this call, Joe Dolson are two of the co-lead organizers and members of the board for WordPress Accessibility Day.

It is a separate non-profit, and we run a full 24-hour event. This year, it’s going to be on October 9th and 10th. We have both calls for sponsors and calls for speakers open right now. If you’re interested in sponsoring or speaking, please go. We do pay our speakers. We have a $300 stipend for our speakers. Please go apply to speak. You can learn more about the event if you go to 2024.wpeaccessibility.day. Now, what the plan is, is we’re going to go in alphabetical order by name of the tool.

I’m going to be popping people on so they can give a short introduction of the tool and some things they’ve been doing for accessibility. Then I will stop sharing my slides, and we will do a panel. I’m going to pull up my partner, Steve, and I’m going to go away. You can feel free to introduce yourself and your tool.

>> STEVE: All right, glad to be here. My name is Steve Jones. I’m CTO at Equalize Digital and creator of the Accessibility Checker WordPress plugin that automates accessibility scanning, monitoring, and reporting. We developed the Accessibility Checker to democratize accessible testing. Traditional SaaS tools are often too expensive for many clients, developers, and individuals. We aim to create an affordable, fully featured accessible scanner without per-page or per-scan fees. To achieve this, we included our full set of accessibility rules in the free plugin version, removing cost as a blocker altogether.

We also took a step further by providing enhanced features in our pro plugin to help scan and resolve issues at scale, such as scanning custom post types, generating full site reports, and tracking accessibility improvements over time. We believe that extensive documentation is crucial to accessibility success. By integrating the Accessibility Checker directly into the WordPress post edit screen and making it available via the front end of your website as well, we created a vital educational tool that provides instant feedback and resources.

We also designed the plugin to be accessible to users with varying abilities. The interface is intuitive and easy to navigate, with features like screen reader and keyboard support, ensuring that everyone, regardless of their technical skills or abilities, can effectively use the tool. The Accessibility Checker is truly a tool for everyone, bringing comprehensive and affordable accessibility testing within reach for all WordPress users.

>> AMBER: Great. Thank you, Steve. The next person that we’re going to have on our panel today is going to be Michelle. Michelle, could you introduce yourself and share a little bit about the solution you’re going to be talking about?

>> MICHELLE SCHULP HUNT: Sure. Hey, everyone. I’m Michelle. I am the Director of UX Engineering at Lone Rock Point, and I’m the lead front-end developer on our new product called CivicPress. CivicPress is a WordPress full-site editing theme that is fully integrated with the US web design system. For those of you that don’t immerse yourselves in US government details, the US web design system was created to provide a consistent, usable, and trustworthy user experience across all US government websites through a unified design language and site structure.

CivicPress exists to help federal government agencies modernize their websites and meet the requirements of the Integrated Digital Experience Act of 2018 and OMB M-23-22, which is titled Delivering a Digital-First Public Experience. Among many requirements, Delivering a Digital-First Public Experience prioritizes accessibility as a key pillar. One of the thing it says is that agencies should design websites and digital services to be usable by all people, including those with disabilities, without the need for adaptation or specialized design to the greatest extent possible. That’s a big deal.

In addition, there has been a long-standing desire for a no-code web builder for government in the US, and with the continuing maturity of the WordPress block editor, we recognized an opportunity to deliver a solution. We integrated the structure and principles of the US web design system into a full-site editing block editor experience. In doing so, we are trying to prioritize accessibility in every step of the process, from the design decisions to the code quality to creating intuitive options for the content creators that are going to be using the theme. That’s us.

>> AMBER: Great. Thank you. The next person that we’re going to have on our panel that I am excited to introduce is is Miriam from Elementor. Miriam, could you give a little introduction for yourself and talk about Elementor, if anyone hasn’t heard of it and how accessibility plays into Elementor?

>> MIRIAM SCHWAB: Sure. Hi, my name is Miriam Schwab. I’m head of WordPress relations at Elementor. Elementor is well known for our page builder plugin, and Elementor provides web creators with the tools they need to build and host websites. You many not be aware, we have very wide reach though. We power more than 10% of the web and have over 16 million active installs of our plugin. Because of our wide reach, accessibility is a priority for Elementor. We can be quite impactful with changes that we make to millions of sites.

Over the last two years or so, accessibility starts to has become more of a priority at Elementor, and many releases included accessibility improvements, significant ones and meaningful ones. Some examples are replacing semantic HTML, and adding HTML attributes that are relevant, improved keyboard navigation and more, which I can talk about as we go on. Also going forward, we’ve done backwards fixes in the product, but also at this point going forward, whenever new features are being worked on, there is a part of the workflow that now addresses accessibility.

I’m proud of what we’ve been doing. Obviously, it’s a very big project, considering that the plugin has so much functionality, wide-ranging widgets, forms, all sorts of things. We have to address all of that, but a lot of work has been done, a lot of it has been accomplished, and going forward, there’s more plans. Like I said, it’s been a priority for us.

>> AMBER: Great, thank you. All right, so our next person that we’re going to bring up to introduce herself and her product is Morgan from Gravity Forms.

>> MORGAN: Hello, I’m a software engineer for Gravity Forms. If you don’t know Gravity Forms, it is the most powerful solution for building custom forms. You name it, if you can do it with a form, Gravity Forms will let you do it. E-commerce, contact forms, newsletter signups, and a whole bunch of things that never occurred to me that you could do with forms, you can do with Gravity Forms. As of 2020, it is now possible to make completely accessible forms with Gravity Forms. You can make forms that are WCAG 2.1 AA compliant.

Obviously, that depends on what settings you’re using. It is possible to make forms that are not accessible, but it’s very important for us to make sure that people can make forms that are totally accessible with Gravity Forms.

>> AMBER: Wonderful, and it looks like you have a link on the slide. Do you mind just reading out and sharing in brief what that is in case anyone can’t see the slide?

>> MORGAN: Yes, our URL is gravityforms.com, but if you go to gravityfor.ms/accessibility, that is a page in our documentation site that has our commitment to accessibility, some tips for creating accessible forms, and some guidelines about exactly what settings you need to use to make sure your forms are accessible.

>> AMBER: Wonderful, thank you. Sorry, all the button clicking, you guys, it’s a little bit super fast. All right. I am very excited. Joe, as I mentioned before, is our co-organizer, co-lead for WordPress Accessibility Day and does a ton for the WordPress community, and so he’s actually going to talk about two of his plugins today. The first one is My Calendar. Do you want to introduce yourself and introduce My Calendar, Joe?

>> JOE DOLSON: Certainly. I’m Joe Dolson. I’m a WordPress Core Committer, Plugin Developer, and Accessibility Consultant Educator. I do stuff. My Calendar is a plugin I built specifically focused on managing events. It’s a pretty full-featured event manager with venue information, event information, categorization, all of the things you expect from an event management plugin, but it’s also heavily focused on accessibility.

One of the unique features of it is the fact that it includes management for your event’s accessibility features, things like whether or not it has ASL, captioning, various features like that, and also the venue accessibility so that you can document whether this venue is wheelchair accessible, whether it has bariatric seating, all the various things that might be relevant to a specific location, because this calendar is really built on the idea that accessibility is an all-encompassing experience for events.

You need it to be accessible so that people can get to your event page and learn about the event. You need it accessible for the managers of that content, but it’s also crucial that the patrons who will actually come to your event are able to get to the event and know what to expect when they get there, and so those event accessibility features are a very important part of it. On the link there, that’s basically just my general page for information about the plugin. There’s also a doc site. It’s joedolson.com/my-calendar.

>> AMBER: Wonderful. Thank you. All right. Then our next person that is going to introduce themselves is Daniel from Popup Maker.

>> DANIEL: Hello, everyone. I’m Daniel from Popup Maker, or Code Atlantic to be specific. I’ve been building WordPress products for 15 years. Well, 15 years, I’ve been in the WordPress premium plugin space. This will actually be Popup Maker’s 10th anniversary coming up in November. I’ve been building products that sell for about 12 years now. With Popup Maker and most of our products, we found that user requests were the main driver of accessibility, but I guess we adapted accessibility much sooner than most others.

We were kind of doing the tweaks before WordPress as a whole was moving that direction, but that was mainly just out of user requests. I would attribute most of our growth to following user requests. That was a huge driver. The plugins themselves, we tried to make sure that the admin editing experience is both fully compliant and you can get around the entire thing with keyboard or voice tools, as well as the front end.

Our popups for Popup Maker, for example, are fully WCAG compliant. They do focus trapping. Once the popup opens, it traps the tab, so they can’t get out of it, leading to confusing cyclical tabbing issues. Then we use all the ARIA attributes as well just to make sure that everything works properly for your popups just the way the rest of your website does. That’s pretty much it. We focus on getting things done early and as quickly as possible, I guess, when adapting to new guidelines and stuff like that.

>> AMBER: Wonderful. Thank you. All right. We’re going to pop back over. I debated this, but we’re going in alphabetical order. We’re going to go back to Joe Dolson as soon as I find that button to spotlight you. If you could give us a quick overview of what WP Accessibility is, please.

>> JOE: WP Accessibility is definitely unique in this group of plugins because it’s not a product. It has really no monetization of any kind, but it is one of my most popular tools, for better or for worse. It is essentially a tool I built to fix problems in WordPress. It takes things that are known potential problems either in WordPress Core or in WordPress themes and just repairs them. The reason it’s able to do that is because these are well-known items.

For example, with missing Core form labels, that’s going to be your comment form or your search form. It can just look at the page and say, “Okay, I can see there’s a comment form. I can easily recognize it because the WordPress Core code is known.” It just checks, says, “Are there labels here?” If not, it sticks them in because those are known forms and it can predict what they’re going to be.

It’s a good tool if you’re stuck in a situation where you have a theme that is not accessible, but you can’t just change it or remediate it itself, but ultimately, the main purpose for WP Accessibility is to drive people to awareness of potential problems. One of the main things I’ve been adding over the last few years has just been surfacing the issues it’s correcting to the user. It’s added a stats dashboard that tells people, “Hey, this is what WP Accessibility has done on these pages.”

It does also include some features that you can use to enhance accessibility, like the ability to make your alt text visible on images with a toggle, similar to what you might see on Twitter or other social media platforms where there’s a little button on the image that can expose the alt text for that image.

>> AMBER: Great. All right. That is our panel. Let me stop sharing and I’m going to make sure that we have everybody spotlighted. Just give me one second. While we are doing that, I do want to note, we’re going to run through a few questions, but we will have time to answer questions that you all might have. There is a Q&A module in Zoom. If you can put your questions there, they’re a little bit easier for me to track than in the chat. If you have any questions while we’re working through our panel discussion for any of these WordPress product developers, please feel free to throw them in there.

I wanted to start with talking about how accessibility has maybe evolved over time within products. Where did it start? Where is it now? How is it changing? We didn’t really talk about this, but you guys can feel free to jump in if you want, or we can go in order that we went in before. You can decide.

>> JOE: Well, I’ll just dive in. I’m going to dive in because, I mean, My Calendar, I built it from the very beginning to be an accessible plugin, but I built it in 2009. Over the course of 15 years, that’s an enormous amount of change. Not the least of that is the fact that, in 2009, WCAG 2 was only a year old. The ARIA specifications had not yet been released and weren’t released until 2014. HTML5 didn’t become a recommendation until 2014. All of those are enormous changes that I’ve had to implement over the years to change what was accessible about the plugin.

That’s a continuous process. Everything that needs to be accessible is changing nonstop as the web evolves and as the expectations of the user evolve for what’s considered to be accessible. Something that was accessible in 2009 would now be looked at as just being terrible.

>> STEVE: Yes, I would say from our perspective, we have to hit this at two angles. We have to hit it from the perspective of evaluating accessibility and making sure that our rule set is in line with the current guidelines and also modifying those rule sets to be compatible with WordPress, making sure we’re not creating a lot of noise, like flagging spacer blocks and stuff. Things that we know WordPress does and making modifications in that regard. The other side of that is that we do spend time improving the actual accessibility of our UI elements in the back end of WordPress as well.

Like Amber briefly mentioned at the beginning, we actually released a feature yesterday in the plugin that refactors some of the tabs to be more accessible. Now, were they usable before? Yes. But are they better now? Yes. It’s just a constant thing that we try to do and improve upon. There’s people in the community like Joe and Alex Stine that submit issues to our repo and great accessibility recommendations, and we try to prioritize those.

>> DANIEL: I’ve personally spent way too much time optimizing interfaces with Alex, probably to the point where we could have stopped a day in and we ended up spending five days just over-optimizing and improving things. There’s always small room for improvement, but I think you can get to a good base point where the majority or even all of your users can use the products properly, even if everything’s not completely optimized. I think that should be the goal of any product is to get to that base optimization where there’s nobody falling through the cracks, and then if you have further enhancements, obviously, that’s the way to approach it.

>> MICHELLE: I think the human partnership is important to state here too. We are a newer product that we’re working on, we’re pre-launch right now. Obviously, we’re trying to make decisions with our code and with the things we’re doing to not build something that doesn’t work. I think the human partnerships both in some of you being able to support Gravity Forms, working with Accessibility Checker, making sure that our stuff works there, but also we had an accessibility audit done by Equal Made LLC. Like, “Please go through everything.”

They were able to identify several existing issues, many of which we’ve been able to remediate. For the ones that we aren’t, we’re making it public as an ongoing discussion of here are the issues we’ve been made aware of. Some of these issues come from WordPress itself. Some of these issues come from the US web design system. Here’s what we’re doing to work on them. I think those human partnerships working with people has really made the difference because you can only automate it so far.

>> DANIEL: I think finding people who use accessibility tools in their day-to-day, like Alex, is important too. There’s only so much somebody who doesn’t actually use these tools on a day-to-day basis for their own needs can do. There’s a lot of little nuances how the speech-to-text works that you’re not going to find just tapping to a page really quickly. It’s the day-to-day usage that you’re going to really find the things that need tweaking.

Joe: I always tell people that as a non-expert, non-native user of a screen reader, you can do a really good job of micro-testing, testing very specific interactions and making sure these two things work well together. As far as overall usability, you can’t get there unless you really know the tools and have an experience of what you expect from them.

>> AMBER: I think on that note, it might be interesting to go into, for you all, as you’re working on making accessibility changes, is there anything that’s been surprising or that you’ve learned through the process or maybe particularly challenging to accomplish in the WordPress environment?

>> DANIEL: Keeping up with the changes, to be honest. WCAG, they have a public notification thing, but there’s no real channel to get that to me unless I go seeking it. Either our users come to us with new stuff that they want to see done in our plugin, so we’re actually second to find out because the users found it first. There just needs to be a better communication channel from these groups who create the rules and stuff down to the level. That’s probably on us too, not just them.

>> JOE: I think if you’re really embedded in the accessibility community, you hear about them no matter what, you can’t avoid it. I don’t know that there’s a great channel for that.

>> AMBER: Join our email list. We send links of stuff. I don’t know. I feel like you have to get connected to people, right?

>> JOE: Yes.

>> AMBER: Miriam, I know that you’re doing stuff with Elementor, and one of your developers actually came in the WordPress Accessibility Facebook group and posted, he was working on totally redoing your mega menu, which has released, and he posted and asked for feedback. Is that something that you all have written for your team, like here are places you can go? Or did he just do that? I don’t know if there’s something other product developers could learn from that, about how to go find people to test things.

>> MIRIAM: Yes, that’s someone from our team named Hein, and he and someone else named Rami, they basically lead our accessibility efforts, which is amazing that two people can do so much. Obviously, there’s more people involved on the R&D team, but they lead these initiatives. Elementor, most of our users are using our free plugin, the Core plugin that’s available on the WordPress repository. We also have publicly available GitHub repo where people can submit issues. A lot of our product development and testing and QA that applies to accessibility as well is based on putting out there to the community and getting people’s feedback.

I’m guessing that Hein figured that out on his own, and it’s a great approach to doing it. It’s one of the best ways to make sure that you’re building good products by getting that type of external perspective, where, like you were saying, we’re all in the weeds, so we don’t always notice everything. It’s good to have people from the outside coming in. Also, that specific feature was actually a community effort. I think there was a lot of demand for that, not demand in a bad way, but we really could use this. We need this. That was taken seriously.

Because it came from the community, also went back into the community to be like, “Hey, what do you guys think? How does this look to you? Do you have any feedback? ” In general, that kind of feedback loop with our users and the community is pretty strong in our product development. I highly recommend it on almost every aspect of product development. It really helps fine tune things. That’s what happened there, more or less.

>> AMBER: Go ahead, Morgan. I’m sorry. Go ahead, Michelle.

>> MICHELLE: I’m sorry, go ahead.

>> AMBER: I was just going to ask Morgan if there’s anything that they found challenging or surprising when they were working on accessibility to Gravity Form.

>> MORGAN: There are a lot of challenges, especially building a product that– a lot of you have products that are geared towards people who care about accessibility. You have an accessibility checker. Anybody coming to this product already cares about accessibility. Our product users, a lot of people come to us because they can use our product to build accessible forms but we also have a lot of customers who just want to build forms and accessibility isn’t something they particularly know about or care about.

Sometimes it’s been a challenge trying to educate people within the product. Like, you can add a multi-select field to your form. Multi-select fields are not accessible. There’s no way to make them accessible. They’re terrible, but people want them in their forms. We’ve got a notice in the form saying, “This is not accessible.” There’s this challenge of trying to educate people about best practices while also letting them make their own decisions about what to do and particularly educating people who maybe it wasn’t on their radar that accessibility is something they should care about. That’s been a challenge for us.

It’s frustrating when we build a feature like– just in the past week or two, I got a request. We have a little legend at the top of a form saying, “asterisk means this field is required.” There was somebody complaining, “I want to get rid of this. I don’t want that thing there.” No, you need that there. Please leave it there, please. Trying to balance keeping our customers happy while also not helping them make bad decisions.

>> MICHELLE: That’s actually a really great tie into some of the stuff I was going to say. The thing that we’ve been really learning and embracing about accessibility is that it’s not just about making sure that your code is usable by assistive devices or making sure that your color contrast meets some standard. Accessibility isn’t just about like the technical side of things. The content that you’re creating is also an extremely important part of accessibility. I know we are doing a theme. We’re working with content creators and form creators are also content creators, right?

How do we empower the content creator to not take our theme that we put a lot of work into making sure it was technically good and then build content that isn’t accessible because they can. What we’re thinking about holistically is how do we empower the content creators to build accessible content? What can we do to help them? I think that’s an important part of the process because yes, they’re not necessarily going in there thinking, how can I make something accessible? They’re just saying, I want to write some content and we want to help them be able to do that accessibly without them having to think about it.

>> MORGAN: Forms in particular, that really comes up because it’s something the user is interacting with. Sure, you can have all the color contrast you want, but if you’ve got 500 fields in your form, that’s still going to be really hard for people to deal with. We see a lot of, oof, anybody actually capable of filling out this form? That has nothing to do with having disabilities or needing assistive technologies. It’s just, you’re a human being and you only have so much brain capacity. How can you absorb this information well?

>> JOE: I think that figuring out that balance point between making it possible for your users to do the things they want to do while keeping the things as accessible as you want them to be is really quite challenging. I’ve definitely encountered that a lot with My Calendar because people are constantly asking for things and I don’t want to provide that. I don’t think you should do that. I’m not going to add it. It’s certainly frustrating and it’s a difficult thing to figure out exactly what to do about.

>> MIRIAM: At Elementor, our focus in terms of the accessibility work we’ve been doing has actually primarily been around technical accessibility. Making sure that our front end code output is more and more accessible. We’re not there 100%. I don’t know if we’ll ever be there.

>> AMBER: I don’t know if anyone ever is there though.

>> MIRIAM: The idea is to always be making progress. The progress is primarily focused on that. Then, like you’re saying, someone can then come and just build a horrible website with the page builder because they can. Also, they should be able to build whatever website they want, even if it’s horrible. Everyone doesn’t have to be the most amazing web builders. They want a website up there. They want to express themselves in some way. Go ahead and do it. You don’t have to be a web designer and creator, expert and also SEO and also accessibility.

We take care on the code side, on the front end code side, a lot of that, but then what happens on the content creation side? That’s some of what we’re working on next, which is hints and guiding tips to indicate to people like, “Okay, you’re about to do something that will make your site less accessible or inaccessible to certain people. Take that into consideration.”

I’m not sure how much more we can do, except for maybe AI, which I know [inaudible] I’m talking about. Sorry, it’s a key word. AI will actually be the next level of this, where it can really, really help guide users to build their websites and create their content in a way that’s accessible. Also, remove that need to be experts from them and offload it to to AI. That feels like the hope for the content creation side.

>> AMBER: I know that was our goal with our plugin because we would build websites that were so accessible and hand them off to our clients and then our clients would come back and be like, “What happened?” Before Gravity Forms, I feel like Gravity Forms was the one I first saw that had those hints. Core has some hints, about color contrast or if you’ve forgotten to put alt text on something or explaining what the alt text field is for, but I would love to see all plugins do that, having some guidance in them. I think that’d be great.

>> DANIEL: That probably requires some improvements to Core, similar how they added the privacy policy generators and stuff in Core. They need framework for us, the plugin developers, to build around, if that makes sense. The best place for anything like that to start would be in WordPress Core improvements with a toolkit.

>> AMBER: What does that mean specifically, like adding filters that you put that hook into to add your own message?

>> DANIEL: Not just that, possibly even you’re talking about scanning tools and stuff like that. If you want to do contrast checking, you need something that’s persistently on the page, checking you and notifying you. Then if it shows up in my elements, then maybe I customize the notice. I don’t really know what it looks like, but you have to decide things you want to accomplish across all of these plugins and then give them a unified set of tools to notify.

I mean, think about how archaic admin notices are right now with no single unified entry point. It’s the Wild West, every plugin has their own. They all show up at once. They all don’t show up at once. Without a unified thing, you’re going to get the Wild West approach and everybody’s going to throw their own solution. If you want to really solve this across everybody, it’s got to be from the Core first. That’s a whole other panel.

[crosstalk]

>> AMBER: I know. We’d have a full panel discussion on that. All right. I do want to transition into some of the questions that we’ve had coming into the Q&A. Before I do that, can each of you tease something that’s coming in your product from an accessibility perspective, or maybe share any future goals for accessibility that you have. Maybe we can go in the same order that we did initially. Steve, that’ll put you up first.

>> STEVE: All right. I’m up first. I think in the very near future, a little tease for the plugin is that we’re creating a deeper integration with Deque Axe-Core library. We’re coupling our rules with Axe-Core and modifying a lot of those rules to cater towards WordPress. The net result of that is just going to be more accuracy and being able to utilize all the work that’s gone into that library itself and bringing that fully into our plugin. A little further out, the role of the plugin has always been to evaluate and report on accessibility issues. We’re working on taking steps beyond that.

First of all, segmenting issues out by user role to reduce noise to certain users. For example, editors don’t need to be alerted to global accessibility issues on the website in most cases, but admins likely do need to be notified of global accessibility issues. Then I think maybe even a little further out is I think the Accessibility Checker is going to mature into aiding in the remediation process by offering fixes for certain accessibility issues.

>> AMBER: Great. You guys remember what order you were in?

>> MICHELLE: I think it’s alphabetical, so I think we were next. Sure. Obviously as a theme, it’s going to be delivered a little bit more like a software as a service. I can’t really speak to how it’s working, but it’s not just a theme. As a theme, we have a responsibility, obviously, to stay up to date, not only with Core WordPress, but also with the USWDS and continuing to document all of that at our accessibility URL I shared earlier. Internally as part of our process, we are going to be integrating Pa11y, I think that’s how you say it. I never know how to pronounce the 11, into our DevOps process via GitHub Actions.

What we’re trying to do is capture accessibility issues in the code as early as possible in the software development cycle. This is across everything we do but this is going to have a major impact on CivicPress. Also for the people that will be using our product, we’re going to be bundling CivicPress with Accessibility Checker Pro every time so that, again, when it comes to content creation, the site owners, the content creators will be able to monitor the ongoing accessibility status of their content within all CivicPress powered sites.

>> MIRIAM: I think I’m next, alphabetically. We’re going to be continuing applying accessibility to new features as I mentioned, that is part of our workflow. In addition, as new best practices and patterns become available, we’re also trying to apply them as well and that’s part of our future roadmap as well. In terms of new things that we’re going to be offering, it comes back to trying to improve how users build the sites so more hints and tips around things like contrast, alt tags, alt tag length even, things like that. That’s also on the roadmap and coming sometime soon.

>> AMBER: Wonderful.

>> MORGAN: In Gravity Forms, our front end is accessible but the work in the dashboard is not in a lot of ways and it’s actually a little embarrassing how some of our settings forms in the back end are really not accessible at all. We have had an accessibility audit done of all of our admin screens and we’re incrementally making changes there. Gravity Forms 2.9 is going to come out sometime this summer and you’ll see some accessibility improvements in the form editor in 2.9, and we’re continuing to gradually work on making the entire dashboard accessible.

>> AMBER: That’s exciting. Joe, do you want to talk about both of yours at once?

>> JOE: Yes, why don’t we do that? For My Calendar, of course, I just released a major update two weeks ago and that revamped the navigation, added a new templating structure, replaced the style editor and some other major change, I don’t remember what. Right now, I’m kind of between major changes but my next accessibility goal for it is actually to really improve the way it manages venue and event accessibility features because that is something I built a long time ago and the internal architecture of it is terrible and it needs some work.

>> AMBER: We’re always our best critic or our worst critic, I don’t know.

>> JOE: No, I think it’s a legitimate thing to say that it’s terrible. I mean, honestly, the accessibility information for an event is stored as a serialized array. It’s not great. For WP Accessibility, mostly, I want to just continue exposing more information to the user and trying to get people to be aware of whether or not those remediation features are actually doing anything on their website and give them some more guidance about what to do about that because the reality is I would ultimately like to split WP Accessibility into two plugins.

I’d like it to be one plugin which adds features because those are permanently useful and you may always want those and a completely separate one that does the remediation stuff which is honestly stuff that in the long run you should just not be using but I can’t tell people, “You should just install WP accessibility, find out what it fixes, change that, and then get rid of it because you might actually be using these features,” but splitting a plugin is not an easy task. Figuring out how to distribute those features, that’s not going to be fun. Should have done it 10 years ago.

>> STEVE: There you go.

>> AMBER: An example of that, you have the toolbar or the color contrast toggle that maybe people would want forever and not have to code that into their email.

>> JOE: Or they might want to have the button that toggles alt attributes on their images for visibility. That might be something they want forever. They might want the thing that highlights images without alt text in the admin. That might be something that they want forever.

>> DANIEL: Accessibility features versus checkers.

>> JOE: Right. Whereas the thing that remediates comment forms that don’t have labels, well, once you’ve added labels, you don’t need that. It’s not going to do anything if the form has labels, but it’s just wasted cycles in the scripting.

>> AMBER: It’d be something where they could just go fix that in their theme and then they don’t need a plugin to do it.

>> JOE: Right. Yes. Just modularize it and then you don’t have to separate into plugins.

>> DANIEL: [inaudible] the entire scanner disable.

>> AMBER: Daniel, what about Popup Maker? What do you have coming there?

>> DANIEL: Popup Maker version 2 has been long in the works, but we updated a bunch of other products. We’re moving everything to JavaScript React in the backend. Tons of accessibility work as we replace fully accessible forms with new stuff that has to be completely tested from scratch again. That’ll be fun. Though we’re using a lot of off the shelf stuff from Gutenberg component libraries and stuff like that, which will speed things up but at the same time, I tend to find all of the bugs in those and that requires completely separate line of fixing things.

That’s where we’re heading with that. We’re also actually bringing a SaaS service to the market, which is pretty cool. We’ve got to make sure that that’s accessible too for the backend. It’ll be fun.

>> AMBER: Awesome. Well, I’m going to go through some of the questions that we have in the Q&A module. If anyone watching has questions for our panelists, please post them there and we will work through them. Joe, it looked like the first one was for you. Heather asked, how does your calendar address accessibility better than some basic ones we use like Spiffy Calendar? I haven’t heard of this. I don’t know.

>> JOE: I have heard of Spiffy Calendar. I’ve never looked at it. I can’t really directly answer the question of how is it different from Spiffy Calendar? I can tell you how it does the main table layout, which is to say that it is an accessible responsive table with three alternate options for how it can work on mobile, depending on your preferences. The table is a straightforward table, with the table headers are the days of the month but then it’s responsive, but retains the accessibility semantics when it is converted for mobile.

It also has an option so that you can have it just switch to a different output on mobile devices, can either be a mini version of the calendar that omits the titles of events and just has a button to expand a modal, or it can be a list of events on mobile devices. That can be tricky just because having different output on different devices can really mess with your caching.

>> AMBER: You do have a list view as well–

>> JOE: There is also a list view and a card view.

>> AMBER: Great. Awesome. Morgan, I think you maybe addressed this already, but Taylor had asked more about accessibility in the back end, and it sounds like you are working on that, and that’s coming soon.

>> MORGAN: Yes. Specifically the ability to reorder fields in the editor. We are working on that. That’s not going to happen in 2.9. That’s going slowly because we’re moving towards React in the form editor too. That’s a big change that we need to do very carefully. Yes, we are working on it. I have seen Taylor’s plugin for reordering things, and if that’s going to take a long time, we might put in a temporary fix to make that a little bit easier but we’re working on it.

>> AMBER: Wonderful. Gary had asked, Daniel, this is a question for you. Does Popup Maker block whatever is behind the modal or pop up? Gary has tried with other plugins and the tab key gets components that are behind the pop-up on other clients?

>> DANIEL: Correct. As soon as the Popup opens, we actually trap the tab in focus. You won’t be able to focus or tab outside the Popup until it’s closed. You can disable the overlay for any given pop-up, making it less of a pop-up and more of a pop-over or supplemental content to the page, in which case the tab focus trapping is disabled but that’s an intentional choice you have to turn on and then configure yourself. Out of the box, yes, it does that. It automatically focuses the first focusable element in the Popup when it’s opened. Then they can’t get outside of it until you close it.

>> AMBER: That plugin can be used not just for time triggered or user triggered. It could also be triggered by a button click. Like easy fancy box or something like that that’s not accessible. You could use Popup Maker to do the same thing.

>> DANIEL: Correct. You can hook our pop-ups to pretty much any element on the page, even if you can’t edit the element itself, which is nice little nice to have. Some themes don’t let you edit the nav menu or the header buttons, for example, so you can still tap into those. Then, of course, it works with pretty much all of the form plugins. You throw a Gravity Form in there and it just works as well.

>> AMBER: Great. Karen had asked, maybe it’s broadly for everyone. Karen says her clients who care about accessibility often need to also accommodate languages other than English. To what extent are the accessibility vendors also compatible with multilingual tools such as WPML? Anyone want to jump on that one?

>> JOE: I’m not.

>> AMBER: My Calendar doesn’t work well with WPML?

>> JOE: No. It uses an independent database architecture, so it’s outside of the posts table and that makes working with translation plugins really a huge hassle.

>> DANIEL: Our targeting rules make working specifically with WPML a little difficult because of the way that they map. Say if you have a post that’s post ID one and it’s in English and the Spanish version is number two, but you target your pop-up to only show the post number one, but then they change the language. Now, which post are we supposed to check whether they’re viewing or not?

There’s this remapping of data points because they’re checking like an end-to-end connection and we’re checking another different end-to-end connection and it all has to be remapped. We have some fun with them and we actually have back channels with most of those teams to try to work out those problems over time. [crosstalk] We do work with them, but it’s not my favorite plugin.

>> JOE: I’m just waiting for Core to finally do multilingual because honestly, at this stage, I feel it’s soon enough that it’s just not worth my time to try and make it work with all of these plugins and it is worth my time to just say Core will have multilingual eventually and then I will implement it.

>> DANIEL: I think this goes back to what I was mentioning earlier about the accessibility tools within Core. Until this is fundamentally solved in the right place, it’s going to be an archaic mix of solutions.

>> JOE: That’s the thing, like you have to do it differently for WPML and then something else for Polylang and I’m like, I’m an independent developer. I’m doing this by myself. I don’t have that kind of time.

>> MIRIAM: Elementor is not an accessibility tool per se, so I mean, we’re compatible with WPML, but beyond that and from an accessibility perspective, however accessible WPML is, more or less for our users.

>> MICHELLE: I would say as a theme, we are as compatible as WordPress Core is. We’re trying not to do anything. What I will say is as a theme, we are trying to write our styles in a new modern way that is flexible with left to right versus right to left. We haven’t tested it extensively because we’re mostly targeting the US government and US government agencies, but they obviously also have language needs. That’s where we’re at with that.

>> MIRIAM: Elementor is very right to left compatible, considering both of the [crosstalk] are real. It’s already right to left. In fact, in the beginning, at least in some ways, it worked better to left. We’re good on that front.

>> AMBER: Steve, do you want to speak to where languages right now in our accessibility checking? Because I know it generally works, but there’s a few gaps in some of our rules that don’t. I’m not totally sure if they all do non-English yet.

>> STEVE: I share the same sentiment that Joe and Daniel expressed. The challenges of being compatible with plugins like WPML. We do what we can for localization, to be compliant with localization for Core to get those strings translated properly but some of the keywords in our rules, like if we’re checking for certain keywords in an alt text or in a link, some of those may not be completely translatable currently.

>> AMBER: Okay. I’m going to try and get through some of these fast just because of time. Taylor had asked, Miriam, can you share anything? Have you all started to think about accessibility in the editor of Elementor?

>> MIRIAM: Definitely. We’re aware that it is not compatible. It’s not accessible. When starting to work on accessibility, it was not exactly a low-hanging fruit, but the highest impact type of work. People interacting with Elementor sites are actually the visitors. If you consider each site is built by one or two people, but then how many people are actually visiting the site? We wanted to make sure that the front end code was accessible and help our users build their sites in a more accessible way. That was a priority. Also, keeping in mind that Elementor’s code base is almost eight years old.

June is going to be eight years and it’s massive. Everything is like a massive uphill battle. Also, in terms of checking backwards compatibility. This is not an excuse. It’s an explanation as to why it’s a big challenge to take something that big and that old and make accessible. On the horizon, it’s something that we’re very aware of. It is something that’s important for us. I don’t have any TA on that, so unfortunately, I’m sorry to say right now, we know it’s not, and I don’t know when it will be, but it’s on the roadmap for accessibility. Sorry. That’s not a great answer but that’s what it is.

>> DANIEL: The big plugin.

>> AMBER: It is a journey always, I think. I think we only have time for one more question and I know there are a lot here. I will work with our panelists to try and get answers to any questions. We can post those answers when we do the recap. What I’d like to end on is a good question that Mark posted, which we touched on a little bit. At what point, do you cross a bridge and say no to a product release because it’s not accessible? I’m curious to hear if you all have ever had that. For the product developers who are watching this, what advice you might have for them?

>> STEVE: I think for us, a company called Equalize Digital that specializes in accessibility.

>> AMBER: We might have a lower threshold for shelving something.

>> STEVE: Yes. It takes a lot for us to release something that’s not accessible. If that was to happen, then it would probably require some sort of sign up from the client, them acknowledging the accessible issue. Or we have an accessibility statement that outlines that accessibility issue. The threshold for us releasing is pretty high if we’re not releasing something that’s fully accessible.

>> AMBER: I think in our plugin too, we’ve done a lot of testing and we’ve had multiple different blind users test the admin and that kind of stuff. We try to be really thorough, but as I mentioned, sometimes we miss stuff and so it does go out. We do have a process and we critical priority if we get something with an a11y flag in our GitHub repo as an issue.

>> DANIEL: I typically just push the update, but I also think that while I’m coding it, I’m tabbing and using all of the tools and I guess I’ve built my developer knowledge base that I automatically add area attributes where there’s necessary. It’s probably a mixed bag. It’s probably, we wouldn’t ship it if it was truly just broken, busted. As a non-accessibility first plugin, as a product who focuses on just being accessible as a feature, it’s not the end all if we need to push a bug fix or something that’s not compatible completely because with almost a million users, we have to get these solutions out to the most number of people quickly as to prevent a bleeding or an exponential growth of support tickets and things that could be prevented entirely. Then we always try to follow up very quickly with remediations on anything that we missed or something like that. It’s a yes and no answer.

>> AMBER: I think that’s a really valid point that when you have a very large user base, and if somebody reports something that could be breaking the front end of everyone’s website, maybe you have to just patch that thing real quick and then follow up with an accessibility patch as a second in that.

>> MIRIAM: For us, like I mentioned, that accessibility has become part of our workflow for new features, which is great. I’m sure that some features for various reasons get released when they’re not fully accessible or that it hasn’t passed that check due to constraints, time constraints, who knows what, that kind of thing. I think for Elementor, a lot of products, we’re now trying to fix eight years of stuff and so we don’t want to be there again. The more we do now in real time, the less we’ll have to do backwards compatibility and try to fix things like down the line.

I mean, this is my personal perspective, but accessibility is very important, but it’s going to become in higher demand and requirements for technical reasons and for potentially even, legal reasons. We all want to be set up for success around that, and so doing that now as much as possible, again, nothing’s perfect, but as much as possible, I think it’s just saving us all a lot of pain down the line and just generally also making sure that in the present, our products are more accessible to people.

>> AMBER: Great. Well, I really appreciate you all taking an hour out of your day on Global Accessibility Awareness Day to share your expertise and your thoughts. I will follow up, as I mentioned, and see if we can get some additional answers to any of these questions. As a quick recap, can we just go around and say where someone can get in touch with you if they want to follow up with you personally about your products or what you’re working on.

>> STEVE: Same order, I guess, right?

>> AMBER: Yes, let’s do it.

>> STEVE: Okay.

>> JOE: We know it now.

>> STEVE: You can find all the details about us at equalizedigital.com. If you’re looking for me personally, I can be found in most places that I would like to be found, @stevejonesdev on Twitter, GitHub, and other places.

>> MICHELLE: Sure. If you’re looking for CivicPress, I’m sharing a specific link in the chat if you’re interested in learning more specifically about CivicPress or how to get started with that. Otherwise, if you’re looking for me personally, I am pretty easy to find. I’m @marktimemedia on the X, formerly known as Twitter. Lone Rock Point is also on Twitter. You can find all of us there.

>> MIRIAM: You can find Elementor on various social media platforms. We would love for people to submit feedback and issues to us. You can do that on our GitHub repository. Just look for Elementor GitHub, you’ll find it. There’s instructions there on how to submit issues. We have quite a big and active Facebook group, Global Elementor Community, so you can also raise issues there or ask questions. We have quite an active community and also our own moderators there. If you want to get in touch with me, a good way is you can DM me on also the X, formerly known as Twitter. My DMs are open. I’m @miriamschwab there.

>> MORGAN: If you want to get in touch with me, there are contact forms on gravityforms.com or you can email me, morgan@rocketgenius.com. I saw several people in the Q&A and in the chats offering to do testing. I would love to have a group of people help test out Gravity Forms. If you’re interested in doing that, please email me, morgan@rocketgenius.com and we’ll get that going. Thanks.

>> JOE: I think it’s me now.

>> STEVE: Yes.

>> JOE: You can find me at joedolson.com. I am a sole developer. If you submit to any of my contact forms, it goes to me. If you submit a support request on any of my plugins, it goes to me. You can find me on most social media, @joedolson, J-O-E D-O-L-S-O-N. If what you want to learn from me is more about how to make WordPress accessible, I’m going to drop a link in the chat, which is to my LinkedIn learning course, which is on that topic. It’s a three-hour course on making WordPress sites accessible. I can only answer so many emails about it.

>> AMBER: Watch the course first, then ask questions.

>> DANIEL: You can reach out. I put links in the chat over there for my Twitter. Twitter, @daniel_iser, if you want to reach out for developer stuff. If you have questions for our product team, we have dedicated and awesome support. I recommend using any of the support forms on wppopupmaker.com/support. If it’s not popupmaker specific, then code-atlantic.com/support.

>> AMBER: Great. Thank you, everyone, so much. I’m just going to give a second for the captions to catch up with us, and then I will end the webinar. Have a wonderful day, everyone. Daniel: Thanks, you all.

>> MIRIAM: Thanks.