071: GAAD 2024 WordPress Accessibility Showcase

This episode is a recording of a special event we held in honor of Global Accessibility Awareness Day, where representatives from WP Accessibility, Gravity Forms, Elementor, CivicPress, My Calendar, Popup Maker, and Equalize Digital shared information about their WordPress products, and went in-depth into how each team is working towards improving and maintaining accessibility. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: WordPress Accessibility Showcase for Global Accessibility Awareness Day.

Listen

Summarized Session Information

The WordPress Accessibility Showcase for Global Accessibility Awareness Day featured a panel of experts discussing the evolution of accessibility in their products, the challenges they face, and their future goals. Representatives from Accessibility Checker, CivicPress, Elementor, Gravity Forms, My Calendar, and Popup Maker shared insights on how they are working to improve accessibility in WordPress, the impact of evolving standards, and the importance of community feedback and collaboration.

The session highlighted the continuous efforts to enhance accessibility, the balance between user demands and maintaining accessibility, and the significance of integrating accessibility into product development workflows.

Q: How has accessibility evolved over time within your product? Where did it start? Where is it now? How is it changing?

Joe shared his experience with My Calendar, an accessible plugin he built in 2009. Over 15 years, there have been substantial changes in accessibility standards and technologies. When My Calendar was first developed, WCAG 2 was only a year old, ARIA specifications were yet to be released, and HTML5 had not become a recommendation. These developments required continuous updates to maintain and enhance the plugin’s accessibility. Joe emphasized that what was considered accessible in 2009 would not meet today’s standards, reflecting the ongoing evolution in web accessibility. Joe concluded by emphasizing the limitations of non-native screen reader users in testing overall usability. While non-expert testers can effectively micro-test specific interactions, achieving overall usability requires in-depth knowledge and experience with accessibility tools.

Steve discussed how Accessibility Checker approaches accessibility from two angles: evaluating accessibility based on current guidelines and improving the accessibility of their UI elements in WordPress. The team ensures their rule set is compatible with WordPress, avoiding unnecessary noise and flagging. They also focus on enhancing the user interface’s accessibility, such as recently refactoring tabs to be more accessible. Steve highlighted the importance of community feedback and collaboration, mentioning contributors like Joe and Alex Stine, whose input helps prioritize accessibility improvements.

Daniel shared his experience optimizing interfaces, often collaborating with accessibility experts like Alex. He emphasized the importance of achieving a base level of optimization where all users can use the products properly, even if everything isn’t perfectly optimized. Daniel believes the goal should be to ensure no users fall through the cracks, with further enhancements building on this foundation. Daniel reiterated the importance of involving users who rely on accessibility tools daily. Users like Alex provide valuable insights that go beyond what developers can achieve through quick tests. Daily usage reveals nuances and areas needing improvement, underscoring the value of real-world feedback.

Michelle discussed CivicPress’s approach to accessibility, emphasizing the value of human partnerships. As a pre-launch product, CivicPress aims to avoid building something that doesn’t work. Collaborations with tools like Gravity Forms and Accessibility Checker are crucial for ensuring compatibility. Michelle also highlighted the importance of accessibility audits which identified issues they could remediate. Transparency and ongoing discussions about unresolved issues, some stemming from WordPress or the US web design system, are essential for continuous improvement.

Q: As you’re working on making accessibility changes, is there anything surprising or that you’ve learned through the process, or is it particularly challenging to accomplish in the WordPress environment?

Daniel emphasized the difficulty in keeping up with changes in accessibility guidelines like WCAG. He noted the lack of a direct communication channel from rule-making bodies to developers, leading to delays in implementing new standards. Typically, users notify them of new requirements, making developers the second to discover. Daniel acknowledged the need for better communication and proactive seeking of updates by the developers themselves.

Daniel suggested that improvements in WordPress Core, similar to the privacy policy generators, could provide a unified framework for accessibility tools. This would allow plugins to integrate better and offer consistent guidance to users. He emphasized that each plugin would develop its own solution without a unified approach, leading to inconsistency and confusion.

Joe highlighted that being deeply embedded in the accessibility community helps in staying informed about changes. However, he agreed that a direct communication channel would be beneficial. Amber suggested joining email lists and connecting with the community to stay updated, an approach Joe affirmed.

Joe noted the challenge of balancing user requests with maintaining accessibility. Users often ask for features that may compromise accessibility, and developers must decide whether to implement them. This balance is crucial to ensure that products remain accessible while meeting user demands.

Miriam discussed Elementor’s community-driven approach. Developers actively seek user feedback, especially for significant updates like the mega menu overhaul. This feedback loop with the community ensures that products meet user needs and accessibility standards. Miriam highlighted the importance of involving users and getting external perspectives to build better products.

Miriam explained that Elementor focuses primarily on technical accessibility, ensuring the front-end code is compliant. However, users can still create inaccessible content without being guided properly. Elementor aims to provide hints and tips to users, indicating when their actions may reduce accessibility. Miriam mentioned the potential of AI to assist in this process, making it easier for users to create accessible content without being experts.

Morgan shared the challenge of educating users who may not prioritize accessibility. Gravity Forms strives to balance providing features users want, like multi-select fields, with educating them on accessibility best practices. Despite notices warning about non-accessible elements, some users still prefer convenience over accessibility. Morgan emphasized the difficulty of keeping customers happy while promoting good practices.

Michelle echoed the sentiment that accessibility is not just about technical compliance but also about empowering content creators. CivicPress focuses on ensuring that content creators can build accessible content without needing extensive knowledge. She highlighted the importance of supporting users in making informed decisions and providing tools that facilitate accessible content creation.

Amber discussed Accessibility Checker’s goal of guiding users in maintaining accessible websites. The plugin provides hints and checks to ensure users adhere to accessibility standards. Amber highlighted the importance of integrating such guidance into all plugins, suggesting that a unified approach in WordPress Core could help developers implement these features more effectively.

Q: Can you tease something coming in your product from an accessibility perspective or share any future goals for accessibility that you have?

Steve revealed that the Accessibility Checker plugin will soon integrate deeper with the Deque Axe-Core library. This integration will enhance rule accuracy and leverage Axe-Core’s extensive work, tailored for WordPress. Additionally, the team is working on segmenting issues by user role to reduce unnecessary alerts for certain users, such as editors. Looking further ahead, the plugin aims to assist in the remediation process by offering fixes for specific accessibility issues.

Michelle explained that CivicPress, a theme designed to work seamlessly with the US web design system, will integrate Pa11y into their DevOps process via GitHub Actions. This integration will help capture accessibility issues early in the development cycle. Moreover, CivicPress will bundle Accessibility Checker Pro to enable ongoing monitoring of user content accessibility. This ensures site owners can maintain accessibility as they create and manage content.

Miriam discussed Elementor’s ongoing commitment to integrating accessibility into their workflow. They plan to continue applying new best practices and patterns to their features. Future updates will include more hints and tips to help users build accessible sites, such as contrast and alt text guidance. These improvements aim to support users in creating accessible content more intuitively.

Morgan shared that Gravity Forms is focusing on improving the accessibility of their admin screens, which is currently lacking in this area. An accessibility audit has been conducted, and incremental changes are being made. The upcoming Gravity Forms 2.9 version will feature significant accessibility improvements in the form editor. The team is committed to making the dashboard accessible and addressing one of their key challenges.

Joe outlined his plans for both My Calendar and WP Accessibility. For My Calendar, the next major goal is to improve the management of venue and event accessibility features, addressing an outdated internal architecture. For WP Accessibility, Joe aims to expose more information to users and guide them on remediation. He also plans to split WP Accessibility into two plugins: one for adding permanent accessibility features and another for temporary remediation fixes. This modular approach will help users maintain long-term accessibility without unnecessary overhead.

Daniel discussed the upcoming version 2 of Popup Maker, which involves a complete backend overhaul using JavaScript and React. This update will include extensive accessibility testing and improvements. Additionally, Popup Maker is developing a new SaaS service, ensuring its backend is fully accessible. This dual focus on the plugin and SaaS service underscores their commitment to accessibility.

Q: Joe, how does your calendar address accessibility better than some basic ones we use, like Spiffy Calendar?

Joe explained how My Calendar addresses accessibility compared to other basic calendar plugins like Spiffy Calendar. Although he hasn’t specifically reviewed Spiffy Calendar, Joe highlighted the key accessibility features and options available in My Calendar that set it apart.

My Calendar employs an accessible, responsive table for the main calendar layout. The table headers represent the days of the month, and the table retains its accessibility semantics when converted for mobile devices. This ensures users can navigate the calendar easily using assistive technologies, maintaining a user-friendly experience regardless of the device.

To further enhance accessibility on mobile devices, My Calendar offers three alternate layout options. One option is a responsive table that maintains accessibility semantics. Another option is a mini calendar version that omits event titles and includes a button to expand a modal for more details. The third option is a list view of events, which can be easier to navigate on mobile devices. These options provide flexibility and ensure the calendar remains accessible across different platforms.

In addition to the table layout, My Calendar provides a list view and a card view. These alternative views offer additional flexibility and can be more accessible for users with varying needs and preferences. Joe emphasized that these features are designed to provide an accessible and user-friendly experience, ensuring the calendar’s usability across various devices and for users relying on assistive technologies.

Q: Morgan, can you expand more about accessibility in the back-end of Gravity Forms?

Morgan addressed the ongoing efforts to improve accessibility in Gravity Forms’ back end, acknowledging Taylor’s previous inquiry about this area. A key focus is enhancing the ability to reorder fields in the form editor, a feature currently in development. However, due to the complexity of the changes involved, this improvement will not be included in the upcoming 2.9 release.

The development team is transitioning the form editor to React, a significant overhaul requiring careful implementation to ensure functionality and accessibility. This transition progresses slowly to avoid potential issues from such a substantial change. In the meantime, Morgan mentioned the possibility of implementing a temporary fix to make reordering fields easier. This demonstrates the team’s commitment to continuously improving accessibility in Gravity Forms, even as they work towards larger, more permanent updates.

Q: Daniel, does Popup Maker block whatever is behind the modal or pop-up?

Daniel confirmed that Popup Maker effectively manages tab focus when a modal or pop-up is active. Unlike some other plugins, Popup Maker traps the tab focus within the pop-up, preventing users from navigating to components behind the modal. This ensures that the focus remains within the pop-up until it is closed, enhancing accessibility by providing a seamless user experience.

Out of the box, Popup Maker automatically focuses on the first focusable element within the pop-up when it opens. Users cannot tab outside the pop-up until it is closed. However, Daniel mentioned that users have the option to disable the overlay for a given pop-up, which makes it act more like a pop-over or supplemental content. In this configuration, the tab focus trapping is disabled, but this is an intentional choice that users must configure themselves.

Amber noted that Popup Maker could be triggered by various actions, such as time delays, user interactions, or button clicks. This versatility allows it to function similarly to other tools like Easy FancyBox but with better accessibility. Daniel added that Popup Maker can be hooked to any element on the page, even those that cannot be edited directly, such as navigation menus or header buttons. Additionally, Popup Maker is compatible with various form plugins, including Gravity Forms, ensuring that forms embedded in pop-ups remain accessible and functional.

Q: To what extent are you compatible with multilingual tools such as WPML?

Joe mentioned that My Calendar does not work well with WPML due to its independent database architecture, which operates outside the standard WordPress posts table.

Daniel explained that Popup Maker faces difficulties with WPML, particularly with targeting rules. In WPML, post IDs for different languages are mapped differently, which complicates the targeting of pop-ups. For instance, if an English post ID is mapped to a Spanish version with a different ID, the plugin struggles to target the correct post when the language changes accurately. Despite these challenges, Daniel mentioned that they maintain communication channels with multilingual plugin teams to address these issues, although it remains a complex task.

Miriam noted that Elementor, while not primarily an accessibility tool, is compatible with WPML. Elementor’s focus is on ensuring that its users have a seamless experience with WPML, as the accessibility of the multilingual tool itself influences this compatibility. Elementor is well-suited for right-to-left languages, reflecting its versatility in supporting various language needs.

Michelle highlighted that CivicPress, as a theme, aims to be as compatible with multilingual tools as WordPress Core allows. They strive to write styles that accommodate both left-to-right and right-to-left languages, though extensive testing has not been conducted. The primary target audience for CivicPress includes US government agencies, which may have language needs, and the theme is designed to be flexible in this regard.

Steve expressed a similar sentiment to Joe and Daniel regarding the challenges of integrating with WPML and other multilingual plugins. While Accessibility Checker works to comply with localization requirements for WordPress Core, certain features, like keyword checks in alt text or links, may not be fully translatable. This indicates gaps in multilingual support, although efforts are made to enhance compatibility where possible.

Q: Miriam, have you all started to think about accessibility in the editor of Elementor?

Miriam Schwab acknowledged that the Elementor editor currently lacks accessibility. She explained that while this is a recognized issue, the initial focus of their accessibility efforts has been on the front end of Elementor-built sites. This prioritization was based on the higher impact it would have, as the visitors interacting with the sites vastly outnumber the developers building them.

Miriam elaborated on the challenges faced in making the Elementor editor accessible. Elementor’s code base is nearly eight years old, and the extensive work required to retrofit accessibility into such a large and complex system is daunting. Ensuring backward compatibility while implementing accessibility improvements adds another layer of difficulty.

Despite these challenges, making the Elementor editor accessible is a recognized and important goal for the team. Miriam emphasized that it is on the roadmap for future development, although she could not provide a specific timeline for completing these improvements. The team is aware of the issue and is committed to addressing it, but the scale and complexity of the task mean it will take time.

Q: At what point do you cross a bridge and say no to a product release because it’s not accessible?

Steve and Amber from Equalize Digital emphasized that their threshold for releasing an inaccessible product is high. Given their specialization in accessibility, they have rigorous testing processes, including multiple blind users testing the admin interfaces. If an accessibility issue is identified, they prioritize it highly and may require acknowledgment from clients or include an accessibility statement outlining the issue. Their goal is to ensure that all releases are fully accessible, and they have a lower tolerance for releasing something that isn’t.

Daniel explained that while accessibility is a key focus for Popup Maker, the sheer scale of their user base sometimes necessitates rapid releases to address critical issues. If a non-accessibility-related bug could disrupt many users, they might quickly release a fix and follow up with an accessibility patch soon after. Daniel mentioned that he actively incorporates accessibility practices during development but acknowledged that immediate, critical bug fixes might take precedence in certain situations to prevent widespread issues.

Miriam discussed the importance of accessibility in Elementor’s development workflow, noting that it is now integrated into creating new features. While some features may still be released without full accessibility due to various constraints, the team strives to minimize these occurrences. Miriam highlighted the importance of addressing accessibility now to avoid extensive future fixes and to ensure that their products are set up for success, both technically and legally. She stressed that making current features accessible will reduce the need for extensive backward compatibility work later.

Transcript

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

This episode is a recording of a special event we held in honor of Global Accessibility Awareness Day, where representatives from WP Accessibility, Gravity Forms, Elementor, CivicPress, My Calendar, Popup Maker, and Equalize Digital shared information about their WordPress products, and went in-depth into how each team is working towards improving and maintaining accessibility. For show notes and a full transcript, go to AccessibilityCraft.com/071.

And now, on to the show.

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

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