Strategies for Creating Accessible Websites Using Divi Theme and Page Builder: Renee Dunn

>> AMBER HINDS: Welcome to WordPress Accessibility Meetup: Strategies for Creating Accessible Websites Using the Divi Theme and Page Builder with Renee Simmons. If you haven’t been before, just a few announcements to kick us off. We have a Facebook group that you can use to connect between meetups. The Facebook group can be found if you go to facebook.com/group/wordpress.accessibility, or you can just search WordPress Accessibility on Facebook search and you should be able to find the group. It’s a great place to share what you’re working on, ask questions, get plug-in suggestions related to accessibility, get feedback on things, or help other people and answer other people’s questions.

As I mentioned just a little bit ago, the meetup is being recorded. You can find all of the upcoming events and all of the recordings from past events in one place if you go to our website, equalizedigital.com/meetup. It takes about two weeks to get corrected captions and a full transcript, and then the recording will be up. You will also get notified when it is available if you are on our email list. We share them right at the top of our newsletter that goes out once a week on Wednesdays, and you can subscribe to that if you’re not already subscribed if you go to equalizedigital.com/focus-state.

The other place where we release this is we release the audio only version on our podcast, accessibilitycraft.com, or if you search Accessibility Craft in your favorite podcast player, you can find it there as well. We had quite a few people ask us to do that because they said they didn’t want to watch YouTube videos. They just wanted to be able to listen, so the audio will be put up there as well. It’s a slight delay. We publish the transcript and the video first, and then it usually comes out either later that week or the following week, kind of close by. We are seeking additional sponsors for the meetups.

I know that we have some spots for live captioning available coming up here in the fall. While this is part of the official WordPress meetup program, they told me that they do not have any funds to help with the cost of captioning or transcription or sign language interpretation or anything that would make this meetup accessible, so they said go out and find sponsors. If your company would be interested in sponsoring and wants to learn more about that, please reach out to us. We very much appreciate anyone who can help cover the cost of making this accessible to all of our attendees.

If you have any suggestions for the meetup or you need any additional accommodations for the meetup or you’re interested in learning about a specific topic or potentially speaking at a meetup, you can contact myself and Paula, my co-organizer, if you email meetup@equalizedigital.com. That is the other way to contact us if you’re interested in learning about sponsorship. My company is Equalize Digital, as I mentioned. We are a mission-driven organization and a corporate member of the International Association of Accessibility Professionals.

We’re focused solely on WordPress Accessibility, and we have a WordPress plug-in accessibility checker that scans for accessibility problems and provides reports on the post-edit screen to help make building accessible websites easier. It doesn’t replace manual testing. You still need to do manual testing, but it can really speed up a lot of the testing as you’re working and is a great tool to use as part of your manual testing tool set. I’ve already said our website a lot of times, so I’m not going to say it again, but if you are someone who is on the socials, we are most active on X, and you can find us there at Equalize Digital, but we’re also on LinkedIn and Facebook as well.

We do have a live captioning sponsor for this evening. We have to give a big shout-out to GoDaddy, who has very generously sponsored a lot of live captioning for our evening meetup. GoDaddy’s mission is to empower a worldwide community of entrepreneurs by giving them all the help and tools they need to grow online, including a simpler, safer WordPress experience. GoDaddy provides a managed WordPress experience that is as easy as it is effective.

The latest version of WordPress comes pre-installed with exclusive themes, plugins, and tools to get you up and running quickly with automated backups, updates, malware removal, so that all the pros who use GoDaddy can spend less time on monotonous maintenance and more time building their businesses. You can learn more about GoDaddy if you go to GoDaddy.com. We also highly encourage people to tweet or if you’re on LinkedIn, post a thank you to our sponsors and tell them that you appreciate them sponsoring the captions for this event because it is very important and they are not inexpensive, and we very much want to help the sponsors know that we value that they are supporting that.

If you are willing, you can just tweet them at GoDaddy a quick, “Hey, thanks for sponsoring captions for WordPress Accessibility Meetup,” and we would very much appreciate you doing that. I have a couple of upcoming events that I want to talk about. The next meetup for WordPress Accessibility Meetup will be on Thursday, September 5th at 10 AM US Central Time. I know it’s not a super friendly time for our friends in Australia and that part of the world, but that will be our next meetup.

Quay Morgan from Ninja Forms will be presenting about Ninja Forms’ journey learning to be accessible and sharing their perspectives from a WordPress product company and what they’ve learned about accessibility and how they’re working to improve the accessibility in their own product. It should be a really great live story of what it looks like to have an accessibility journey. Then the normal September meetup that would be for this time slot is going to be canceled because that is the week of WordCamp US, so we will not be having that regular meetup.

That said, if you will be at WordCamp US, stay tuned because later this week I hope to have the details figured out and we’re going to try and have an in-person meetup at a local brewery, so it will be like a live accessibility craft meetup, which should be sort of fun. We will be doing that instead. Then we’ll be back on Thursday, October 3rd at 10 AM Central Time with Navigating the Future: Using WordPress Menu Blocks That Work for Everyone with Michaela Lederman and Eli Frigoli.

The other event that I want to shout out, and I changed my slides because I’m just reusing an image from there, but WordPress Accessibility Day 2024. If you’re not familiar with WordPress Accessibility Day, it is a separate event from the meetup, but a lot of people who come to the meetup help to organize it. It is a separate nonprofit organization and it is a 24-hour event. It’s a free Zoom conference with live captions and sign language interpretation, single track, all about WordPress Accessibility.

It’s going to be on October 9th and 10th. No matter where you are in the world, there will be some talks during business hours for you. We encourage everyone to go and register. You can register if you go to 2024.WPAccessibility.Day. No WordPress in the URL, we are not breaking any rules. Hopefully, we’ll post a link to that in the chat. I am very excited to introduce our speaker, Renee Dunn. Hi, Renee.

>> RENEE DUNN: Hi.

>> AMBER: Renee has been a web developer for over 20 years and has been building sites on WordPress since 2010. She has built sites for nonprofits, business-to-business, business-to-consumer, and government organizations. She is the owner and principal consultant for Elevage Digital, focusing on SEO and website accessibility. We are so excited to have you here. Welcome, Renee.

>> RENEE: Thanks, Amber.

>> AMBER: I am going to stop sharing. I will let Renee take over sharing her screen. There is a Q&A module that is part of Zoom. If you are able to please add any questions there, then at the end of Renee’s presentation, I will come back and I will pass those along to her and we’ll make sure to answer all of your questions. It’s just a little easier to track them if you put them in the Q&A rather than in the chat. I’m going to go away and let you get started, Renee.

>> RENEE: Great, thanks, Amber. Happy to be here. Hopefully, this will be interesting for people. It seems like we have a lot of Divi users and maybe some developers. Hopefully, some of this will be useful, good new information. I’m going to go ahead and skip past the intro slides since, we kind of covered all of that already. Like I said, I’m in Fredericksburg, Virginia, which is about an hour south of Washington, DC. I’ll kind of dive right in and talk about how I got started on this path. I partner with another local agency here in Fredericksburg, and a lot of their clients are local governments and commissions and various related quasi-government organizations.

Earlier this year, the Department of Justice came out with their new rules regarding accessibility. Now, all of these sites that they work with have to meet the WCAG 2.1 AA success criteria, and they have between two and three years to start meeting those requirements. All of their sites are built in Divi. I wanted to try to start looking at ways to be able to achieve the WCAG success criteria and given that a lot of them, it’s government, the budgeting cycles are slow, the decision-making process can be slow, we didn’t really think that it was going to be feasible to move these sites to a new maybe more accessible by default platform.

It became important to really figure out what can we do with the sites on Divi as they are. I will say that what I’m going to talk about is mostly focused on Divi 4. I did look at what’s publicly available about Divi 5, and there is an alpha demo out there now. From what I can tell, it doesn’t look like they are addressing accessibility as part of Divi 5. If anybody on this call knows more, feel free to maybe put some information in the chat, but from what I can tell, it doesn’t look like that Divi 5 is really addressing any of the accessibility issues.

What are those accessibility issues? If you haven’t watched Amber’s webinar from a couple, I guess, maybe a couple months ago, where she did a really extensive analysis of a lot of the different page builders out there and how well they meet various accessibility requirements out of the box. Spoiler alert, Divi was at the bottom of that list. Some of the reasons for that are they don’t have a skip to content link included, so users can’t bypass the navigation. There, if you’re on a mobile device, you don’t have the ability to zoom in and out. If you’re trying to magnify the text, you don’t have the ability to do that.

There is no focus indicator. The Divi CSS has explicitly removed that. The dropdown menus are not keyboard accessible. The mobile navigation is not keyboard accessible. If you’re using the default header, the search icon and the form itself in the top are not accessible. There’s no label on the search form. The other thing is if you’re using a keyboard or screen reader, you can access that search form even when it’s hidden and so that is a failure for a specific WCAG success criteria.

The other thing is if you are using things like the button or some of the other modules that include icons and you’re adding those icons as part of the styling, the way Divi does that is through the before and after pseudo elements. They’re being added in through CSS, but the problem is that what you end up hearing if you’re using a screen reader is the symbol’s name, which has absolutely no semantic relationship to what is actually being displayed on the screen. For example, if you have just the basic left and right arrows, what you hear is four and five. It’s random, that isn’t being hidden from the screen reader and it really has no, like I said, semantic relationship to what is being displayed.

That is by no means an extensive list, just to say, of what some of the issues are with the theme. That’s just some of the bigger ones. There are also issues related to some of the individual modules. For example, if you’re using the accordions or the tabs or the toggle modules, none of those features are keyboard accessible. If you’re using the blog module, there’s the ability to include the “read more” link, which is considered an ambiguous link. That would be a WCAG failure and there’s no way to add an ARIA-label for those links.

The button module is a little bit of a misnomer because what it actually creates is a link. Buttons are meant to launch functionality. Launch a pop-up or submit a form versus a link is meant to take you to another page. The Divi button module really creates a link. Like I said, it’s not even doing what it says but then there’s no way to add an ARIA-label onto those elements and there’s no way to actually create a button. There’s all kinds of issues wrapped up in that. The contact form and the email opt-in forms that are available, those labels are hidden.

The required fields are not marked properly, and if you generate an error through these forms, those errors are not conveyed to the screen reader. The slider module doesn’t have accessibility or accessible name associated with the errors. Again, if you’re using a screen reader, when you get to a slider, you hear things like four and five for those errors. Why is it so hard to solve all the problems with Divi? I think one of the biggest challenges is that there just isn’t support from the theme provider. That’s definitely a little bit of an uphill battle. Of the things that need to be fixed, there are a number of them that can’t be fixed with JavaScript alone.

You do need to edit PHP or the theme files to address some of the issues that exist with the Divi theme. There’s also so many different options for configuring Divi, and I’m sure that’s why so many people love it, because there’s just so many different things you can toggle on and off. There’s so many different ways to style it but that can create a challenge in terms of testing and being able to account for all of those different vARIAtions. If you use the Divi theme builder to create like a custom header or footer, there are WordPress-based hooks and Divi-based hooks that are ignored, basically.

It makes it harder to include custom functions that maybe manipulate the menu or deal with, again, some of the different issues that exist. Divi also uses JavaScript to dynamically generate a lot of what you see on the page, and so it can be hard at times to use additional JavaScript to target some of those dynamically generated items. What are some options that we can employ to try to deal with these issues? The first one is use a different theme, which seems counterintuitive, but I kid you not. I have seen this recommendation in Divi support tickets where people are asking about skip to content links and focus indicators.

I have seen where support will recommend using a different theme that has those already built in. Another option would be to disable some of those more problematic modules and use an alternative. For the blog module, you could create a custom loop in a theme file, potentially use some custom fields if you want to be able to have the ability to define custom ARIA-labels in your list. For the contact form and email opt-in form, basically you would just need to use a different form tool. For example, Gravity Forms or maybe Ninja Forms, if that’s something that they’re working on with their tool.

For the sliders and galleries, potentially find an alternative or better yet, is there an alternate way that you can present your content that doesn’t require a slider at all? Those are some different options that you can look at. I will also show you, there is a plug-in, this one’s to the bottom. This plug-in here, Divi Module Builder, actually lets you build custom modules that you can create yourself depending on the needs of your site. It allows you to create custom fields and then completely control the HTML output and the CSS to display different features.

That’s a interesting tool to play around with. Then if you’re someone who manages multiple sites for clients, you can create a custom module and then they have a companion plug-in that then basically lets you convert your custom module into a plug-in that you can then install on multiple sites. If you’re a developer, that’s an interesting way to potentially work around some different things and create an interesting user experience also for your content authors. There’s also a few plug-ins that already exist that maybe people have tried, or there’s actually a new one that we’ll talk about in a minute.

The first one is the Divi Accessibility plug-in. This is the one created by CampusPress. It’s been around for a while, and so maybe this is one that people have tried. It’s unclear if this is still being maintained. I think the last update in the GitHub repository was October of last year, so I’m not sure, again, if anybody here has any insight and knows if it’s still being maintained or not. That might be helpful information for people and it does fix some of the basic Divi theme issues. This is just a local dev site that I have that has the Divi Accessibility plug-in on it.

If I use my tab key, you can see I have skip to content link, and then if I tab through WordPress plug-in, you can see the logo is highlighted. I’ve got a focus indicator, and they do allow you to control the color for that. I can tab through the navigation. One thing that still doesn’t make the search icon keyboard accessible, but it just takes you directly to the form, but again, you have to tab through all of the menu items to get to that. I’m going to tab through all the content here real quick, just to get to the bottom. The social media icons that are at the bottom in the default Divi themes that are– with the Divi Accessibility plug-in, it has added a role of button to these links.

I’m not entirely sure why, because they are just basic links. I’m not sure why the role of button was added onto these. I don’t think that that is correct in terms of ARIA attributes. That was just one thing that I noticed with this plug-in. Again, if you’re just using the default Divi theme header without too much navigation, this could be a good option. Again, like I said, it does add the “skip to content” link, the focus indicator, and the ability to tab through to the dropdowns. It does not work for things like the full-width header style or the slide-in.

If you’re using some of those different header styles, this isn’t going to work to make those other header styles accessible. There’s another one called Divi Assistant, and this is created by PA Creative, go ahead and switch this one real quick. The Divi Assistant, they do a lot more than just accessibility. Their tool provides all kinds of different Divi little extra functionality and admin tools and things like that. One of the things that they do include is a few accessibility fixes. It’s very similar in functionality to the Divi Accessibility plug-in in terms of it adds the “skip to content” link.

It adds the focus indicator with a color that you can control. It does add the ability to zoom in and out on mobile and tabbing through the navigation, just like I showed you a minute ago with the Divi Accessibility plug-in. You can still hear and access the hidden search form. You can still tab through it, and you hear it on the screen reader. That’s still an issue because that is a failure for WCAG. The accordion toggle and tabs, it’s a little better, but there are still a few usability issues with those in terms of using the keyboard and then again, this one doesn’t work either for the slide in and full screen menu options.

Again, if you’re just using the default Divi header style, this is potentially an option. There’s a new kid on the block. Divi-Modules has created a set of plug-ins that just came out in May. They’re also having some CSS issues because all of their skip links are showing on their site right now. That just started the other day. Like I said, they have three plug-ins that you can buy individually or as a bundle. They do have a sidebar. It’s not horrible, honestly. I tested with NVDA, and you really don’t know that it’s there other than you hear that open accessibility sidebar.

Otherwise, if you’re using a screen reader, you honestly don’t know it’s there. The biggest thing for me when I tested it is that it really just doesn’t do anything super useful. I’m going to launch it on their screen. It controls language, like if you want to convert things to a different language. It has a lot of the normal options in terms of changing text size and colors and things like that, but these are really things that you should just be built into your site design in the first place in terms of having good color contrast, having the ability for people to resize text and things like that.

I did test, they do have a seizure setting that is supposed to reduce animation. In my testing, it did not actually do that. I did a good amount of testing with all three of these on Chrome and with NVDA, and found more than a handful of issues. I have let the developer know, and they are going to try to address some of those, but they have to get through their Divi 5 updates first. I will show you, I have a dev site with this installed on it. Just do some interesting things, and there is some potential here. Again, you can add your focus indicator, and control the color for the focus indicator.

They also have, like I said, there’s three different skip links that they include. There is a “skip to navigation”, there is a “skip to content”, and there is a “skip to footer” link. A little bit more than you see with a lot of other tools. The other thing that I find helpful with this one is that you can define multiple IDs to use where that skip link might go. Basically, they’re going to use the first one that is encountered. Why would anybody want this? I’ve at least encountered in one situation using the event calendar plugin, where the individual event pages that it creates will actually remove the ID, the div that has the ID of main-content.

If you have a “skip to content” link that is targeted at main-content, then on the pages that the event calendar creates, you now have a broken skip link. It is nice here that you can add, kind of a fallback option in case you’re using a tool that would remove that primary ID. Like I said, it’s kind of broken up into multiple plugins. That’s the accessibility tweaks. They also have one called accessibility attributes. The interesting thing with this one is that it will add the ability to define various ARIA attributes on a module-by-module basis.

When you’re adding or editing a module within a page, if you go to the advanced tab, there’s a section called accessibility attributes, where you can define these, whether it be a label or giving it a role, description, all of these different various ARIA attributes. On the elements tab here, you can define what div gets the role equals main. Again, that’s super helpful because otherwise you would have to edit a whole bunch of various theme files to cover all of your different page, your posts, your pages, all of your different archives, different types of pages.

You would have to edit each one of those individually. Again, it has that option to set multiple IDs in case one is not there, there’s a fallback. Where there are some problems, obviously, you may be able to tell just by looking at the admin tools. They have some color contrast issues with their admin tools. That’s potentially problematic. With the ARIA attributes, it’s cool that they’ve provided the ability to set those things on a module-by-module basis. The problem is where they’re putting that code currently isn’t correct. There’s still some challenges there that needs to get worked out.

The other thing that is a little problematic is– they have the option here where you can add role equals link and role equals button based on different IDs or classes that you define. They’re adding role equals link to all A tags, which actually goes against the ARIA documentation. If you’re using an A tag, then it is by default a link. Then this class here, this et_pb_button, is the class that gets assigned to the button module. Like I said earlier, that module really is creating a link. They are removing the role equals link and they are giving it role equals button.

Again, it’s not fully correct the way that they are adding these different roles. If you’re someone who doesn’t know ARIA as well, you’re probably going to assume that what they’re putting here by default is correct but I don’t think it is fully. Again, it’s got some interesting potential. There are still some challenges. Like I said, I did send the developer for this some feedback and they are open to trying to improve it but they are, like I said, working on their Divi 5 functionality first, their updates first. Because I couldn’t find an existing plugin that did all the things that I wanted and needed it to do, I started working on my own, essentially.

It’s really more of a collection of various functions and scripts that I have just pulled together as a plugin just to make it easier to add on various sites. It does have the zoom in and zoom out functionality. It does have the “skip to content” link. It does have a focus indicator. You can control the color. I’ve fixed the labels for the social media icons in the footer so that if you’re using a screen reader and you’re just getting the list of all the links that are available on a page, that they’re represented appropriately. They don’t show up as just undefined or unlabeled.

The mobile menu and the dropdown menus are all keyboard accessible including all of the various header styles, full width, slide in, things like that. I added an ARIA-label on the blog module, which is basically just read more and then the name of the post. There’s code that prevents you from tabbing to the hidden search form and you don’t hear it on a screen reader if it’s not visible. Again, adding keyboard support for the search icon and adding a label to that form. Adding some CSS for if you have settings on your device to disable animations. Basically, honoring that setting.

Then adding support for the accordions and toggles and tabs for keyboard accessibility. There are a couple things, if you notice on this slide, that have a little asterisk system. That is because it does require some changes to the header.php file. Like I said at the beginning, there are just certain things that you can’t really successfully do with JavaScript alone. Just for a quick, so you can see what this looks like. This is, again, another dev site that I have. If I use my tab key, I can get past the WordPress admin. Then I have a “skip to content” link that appears.

You can see I’ve got a focus indicator and you are able to change that color. I can tab through all of the front menu options. I can also use my arrow keys to go forward and back. Just to point out a few different things. Right now, I’m on the animation link. You can see that it has the focus indicator around it, which is separate from the arrow that indicates there is a dropdown menu. With this, animation in this instance is a link. It will take you to another page. It is separate from the button that would expand the submenu. If I move over to the last item in the list that says tests with the dropdown icon, you can see that that whole item has the focus indicator and that is because in this situation, this is not really a link.

It’s just a placeholder for the submenu items. That is treated as a button instead of a link and that is why it gets the focus indicator around the whole thing. I can use my enter key to expand. I can use my tab to move back and forth between those menus or those submenu items. I can also use my tab key to get to the search icon. If I hit enter, it will expand the form. I can tab through that and close it back and get back to the regular header. I’m going to tab through the content real quick. Again, this is just a basic blog module listing some of the recent posts.

If I right click on this and do the inspect tool, then we can see that on this link. I have an ARIA-label and it just says read more of post three, where post three is the name of the post. Well, this is just a basic, it’s all placeholder tags. Again, just trying to address a little bit more, especially in terms of the menus, because the sites that I’m working with, we have a whole slew of different menu styles so I did put a lot of effort into trying to make those a bit more keyboard accessible. I’ll show you the animation page real quick. Just if anybody has sensitivities with motion, just be aware that this page does animation.

By default, the text, this first paragraph zooms in and the second paragraph slides up. Those are just different animations that Divi allows you to add onto your content. If I go over to my settings and I turn off my animation settings, and then if I reload this page, then we don’t get any of that zoom in, slide up, slide in, any of that kind of animation is disabled. In addition to the basic plugin that has, a lot of this functionality, I did create a companion that has a custom version of the button module and a custom version of the icon module.

Again, trying to address, one, the issue with the icons and hiding the icons from screen readers, adding in support for an ARIA-label, and then basically making that distinction between is it generating code for a link or is it generating code for a button. If you use the pound sign as your link value, then the output will be a button, as opposed to if you put an actual URL in the link value, then you will get a link. Just I’ll flip back over to my dev site and you can see what that looks like. All of your normal Divi styling still applies. you can add your icon on the left or the right.

You can have different hover colors. You can have your icon show up only on hover or all the time, so all of those various things that you could already do with the Divi button module. In terms of the code that gets output, so in this case, this is actually producing the actual button element. I can define an ID, potentially you might use that ID then to associate JavaScript with this button. You can define the ARIA-label. You can define the actual text that is visible. Where it says “read more”, I can make that whatever text I want. Then the icon instead of being applied with the pseudo element, there’s actually a span tag here that has the ARIA hidden equals true and that is what is going to pull in the icon.

On the other side, kind of same idea, I’ve actually defined a URL so in this case, it’s going to put out an actual A tag to create a link. Again, I can add an ARIA-label. I can, again, change the read more to whatever text I want. Then, again, got the ARIA hidden equals true so that you’re not going to hear it from the screen reader. There’s also the ability to add a full class on it. If you want your button to be the full width of the container that it’s in, there is the ability to do that. Again, with the icon module, basically, if you just wanted to put an icon on the page next to some text, it is basically just going to produce a span tag that gives you that icon.

Again, with the ARIA hidden equals true, there is the option to make it a link if you specify a link value. Again, it would output the proper A tag then wrapped around that span tag that gives you that icon. A little bit more flexibility and functionality than the standard button. If this is interesting to you and you want to play around with it, I have the GitHub links here. github.com/elevagedigital/fix-divi-a11y is the basic plugin. You can use it like in its entirety or pull out– like I said, it’s kind of a collection of different functions and scripts. You could grab whichever pieces are useful and don’t worry about the parts that aren’t.

Then the companion plugin is at github.com/elevagedigital/fixdivi-a11y-modules. If you use it as the plugin in its entirety, then once it’s installed, you can go to settings and Fix Divi A11y to set your focus indicator color. I would obviously recommend testing all of this in a development environment before you put it on a production site just to make sure that it doesn’t, because like I said, there’s so many different things that you can do with Divi. I haven’t tested it extensively with tons of other Divi add-ons and things like that. Just definitely test in a development environment first.

The other thing that you will want to do is, like I said, basically create a child theme and you will need to update the header.php file. Within the plugin code, there is a file called header-new.php. You would copy that into your child theme area and again this adds code that is needed to help with the search icon and form and then also some of the mobile and if you’re using the slide-in headers to help make those more keyboard accessible. There’s also one more file in there that it’s just like some random code snippets that I’ve also used. They’re not themes that I think apply to so many sites, so I didn’t really include it as part of the core plugin code, but it is just a file there.

I’ll show you real quick what these things do. Again, a warning that the page that I’m going to pull up does have motion by default. This is one of the sites that I’ve been working on. This is fxbg.com. This is the tourism website for the city of Fredericksburg where I live. When you first load the page, there isn’t really a header across the top. It’s just the little mobile hamburger off to the side. If I start to tab on this page, so I get my “skip to content”, and before I had included this code, the next place that gets focused basically with the tab key is the logo, but the logo was hidden, and so being able to focus on something that isn’t visible on the screen is a WCAG failure.

Basically the code that I added, when that logo gets focused, it basically forces that whole header to expand so that it’s visible. That was the first thing. That was the first bit of code that’s in that extra file. The other is to add a button here so that you can pause this background video because, again, we want to be able to have that for WCAG compliance to be able to have a way to stop the video. Like I said, there’s basically two little code snippets in that extra text file to be able to accomplish those two things. That’s kind of what I’ve been able to do so far.

Again, I haven’t done anything with Divi 5, so once that is released, I’ll have to do some testing and figure out if there are any additional changes or updates that need to be made for Divi 5 support. Just other ideas that I may end up including in the future, maybe a custom blog module to, again, better control the code that is output for the blog module. Possibly a custom slider. There is an area on that fxbg.com site that currently has some image gallery sliders that we’re still trying to figure out how we want to deal with, and potentially an icon bulleted list.

I know that’s a popular feature in some of the other page builder tools, and I don’t think there’s a really good way to do that right now in Divi, so that might be something else that I look at doing in the future. That’s the main part of what I wanted to show, but I’m happy to take any questions that anybody has.

>> AMBER: Yes, let me find myself here. All right, we did get some questions. I just have to say, this is so amazing, Renee, not only preparing the existing solutions, but also providing a free link to get one that works on GitHub. Thank you so much, and it’s amazing. I’m going to run through the questions, so if anyone has any questions that they want to put in the Q&A, I’ll pass them along to Renee. The first question came from Ron. He’d asked, have you ever seen if Elegant Themes offers any official stance on web accessibility?

>> RENEE: I haven’t. No, that’s a great question. I haven’t seen where they’ve definitively, as the company, come out and said one way or the other, but like I said, I have seen within Divi support tickets where they just recommend you use something else.

>> AMBER: I can say what I know about this, which is that I have done some searching because I did this around the time that I was testing all the different page builders, and I tried doing site:Google searches, so I would just get results from their website, and I also checked their Terms of Service. Their Terms of Service doesn’t say either way, because there’s some WordPress plugins that literally say our stuff is not accessible. It doesn’t mention accessibility at all in their Terms of Service. Then they have blog posts that talk about accessibility, that are on their company blog and why it’s important.

The thing that I found interesting about their blog posts is when they’re talking about the things to do for accessibility, they don’t mention things like you should have a skip link or you should have focus indicators. They tend to go more to like alt text or things that can be done in their tool. It’s almost to the point that I’m like, “Are they intentionally leaving this out because they don’t want to highlight the fact that theirs can’t?” I don’t know.

>> RENEE: Yes, I’ve seen those same posts.

>> AMBER: I don’t know. There was some conversation in the chat about Divi 5 and other people saying similar things to what you said. Let me see if I can find some of that. Let’s see. Diana had said, “I know they’re saying 5 will not start with enhancements, but I’m hoping the foundation is getting accessibility going. It’s very frustrating right now that their support is not very helpful with accessibility questions.” I think what I heard was that 5 is more about an internal refactor for them than about adding anything new. Is that what you heard?

>> RENEE: That’s kind of what I’ve seen. It’s a little bit like refactoring the admin experience to be faster and things like that. It doesn’t look like any of the underlying HTML is going to be radically different.

>> AMBER: Maybe they’ll see this and it will motivate them to want to do that. Star had asked, “With the suggestion of using a different theme, what are their considerations that you might need to take into account if you were to, for example, go to WordPress.org and choose an accessibility ready theme and use the Divi builder with a theme?” Is there anything that you are aware of?

>> RENEE: No, I mean, you would just have to do extensive testing. If you go to the extent of using a different theme, then honestly, why also then use the Divi page builder? There’s there’s other themes/page builder options that are potentially better, that are going to work better together rather than trying to force something to work.

>> AMBER: You might have to write more CSS because I bet you there’s things in their page builders that it assumes is coming out of the Divi theme. Probably the Divi theme active, then you might have to do some styling that you wouldn’t otherwise have to do.

>> RENEE: Yes, probably. I honestly just threw it out there because that is a thing that they recommend.

>> AMBER: Yes, but maybe not the best solution.

>> RENEE: Right.

>> AMBER: Okay. Marcy said, “Is there any place to access the documentation for accessibility requirements? Would there be a way to prioritize the list of must do items?” Could you share how do you create your list of must do items? What references do you find most helpful when you’re trying to figure out what accessibility fixes needs to be made on your client sites?

>> RENEE: Yes, at this point, I have so many different things bookmarked. I also do accessibility audits for for these government sites that I’ve been working with, I, basically, have a spreadsheet that has all of the various WCAG success criteria. Then I just go through each of them on every page that I’m testing. I go through each one and just figure out, does it work, does it not? Does it kind of work, does it kind of not? That’s kind of my approach, because like I said, with focusing on some of these government organizations and the fact that they have to meet the WCAG 2.1 AA at this point, that is, essentially, the checklist that I use.

>> AMBER: I did post a link in the chat to WCAG 2.2. If you are not familiar with that, that’s the official internationally recognized thing. You’re saying, Renee, that you’ve taken this and put it in a spreadsheet with different things you need to check for each success criterion, and then you use that as your own internal checklist?

>> RENEE: Yes.

>> AMBER: Also, I don’t know, maybe we don’t need to screen share anymore. I don’t see any questions that are about can you show us anything. Okay, let’s see. Ron had a question which– let me see if I can find that and see if someone followed up with it. I think he had asked something to the effect of, does anyone know if there’s any sort of lobbying effort? Then David replied and said, “I’ve been trying to begin a dialogue with Elegant Themes on multiple occasions asking how and where we might report issues and have a forum for getting those issues addressed. They don’t seem to feel like it’s a priority.”

David’s question is, “With the DOJ stating plainly that–” Well, he said, “All Title II and Title III business websites must be compliant with ADA, why is it that Elegant Themes is still treating compliance as a luxury?” Of course, neither of us work at Elegant Themes, so we can’t speak for them. Are you aware of any place where users get together to say to Divi, “Hey, this is a priority,” or where you can upvote features? Do you have any thoughts on what– [chuckling] Being external to Divi, I think none of us can really say why do they not seem to care, but any thoughts you have on this?

>> RENEE: I don’t know. I haven’t done a ton of research into like where people go other than just support tickets to make their unhappiness known. The other thing, too, is Divi, I mean, this is an international, internationally used, plugin at this point. Like I said, I had someone email me the other day from Germany. With the European Union Accessibility Act that’s going to go into effect next year, I think I saw that if you meet WCAG 2.1, that may work for the European Union stuff.

Again, it’s not just the American state and local governments that are the issue. If you’re using Divi around the world, that now it’s going to become an issue in the European Union in the next six months. Yes, I feel like there needs to be much more than just an American-focused way of directing the input but more of a global thing.

>> AMBER: Yes. I think, broadly, what I can say is, as an observer of people who build plugins or software and someone who also makes my own, but I think sometimes when you get a lot of feature requests, you have to weigh how important you think they are. I suspect there’s some lack of understanding at Divi about, perhaps, how large of a population is impacted by lack of accessibility on websites. Like they just literally don’t understand the stats or they have never had a personal experience.

I know when I first started theoretically building accessible websites, it was one thing until we started having people with disabilities test our work and talking to them. I had friends who were blind. Now it’s very different, right? It’s personal and so, perhaps, they’ve never had those experiences. I am not giving them an excuse at all, but if I’m trying to get inside their head like, maybe, that’s what they’re thinking, they’re like, there’s not enough money here, and it’s such a small percent of the population, and it doesn’t matter.

Then I think the other thing is, is a lot of these laws currently, they target the website owner. They don’t target the producer of software that is used to build the website. From a legal perspective, perhaps they’re not worried about risk. Where risk may happen is if their revenue goes down because people who have Divi websites look at it and say, “It’s cheaper to rebuild faster.

Now, I don’t know if that’s the case with old Divi because it has all the shortcodes, and they have solid lock-in. There’s some other builders where you remove the builder and in five minutes it looks like you never had that builder, but Divi is not one of those, and so perhaps it becomes– like you were talking about RFP cycles are long, building a whole new website is this huge thing, and so it’s easier to just remediate.

I don’t know, but I feel like that’s what’s going to impact them. If people stop renewing their license, and they send them a message, and they say, “I canceled my subscription because your stuff is not accessible,” and, “Here’s the one I’m choosing to switch to instead.”

>> RENEE: Yes, I think that’s right. I’m seeing a lot of people in the chat say that it’s going to have to be voting with your wallet and stuff like that. The site BuiltWith that shows you all these different stats about like who uses what tools to build their website, the– I did notice the trend line in how many sites use Divi. It has been declining. Now, it’s not like a super sharp decline, but it’s enough to notice over a period of time. There may already be some people who are starting that voting with their wallet and moving away to other tools.

Interestingly, that Divi-modules, that bundle, I did mention to the person who owns that, about the sidebar, and he did make the comment that, of the three, that one is having the lowest purchase. There does seem to be an indicator that people just aren’t buying that one because they don’t want to have a sidebar on their website, so that’s good.

>> AMBER: That’s a decent transition into our next question which is, someone had asked if you had any thoughts on some of these other helpers like UserWay or AccessiBee. Do you want to share any thoughts on those in your opinion?

>> RENEE: No, I don’t want to get into any legal stuff.

[laughter]

>> AMBER: I’ll say it. In my experience, people with disabilities don’t actually use those tools or like them and sometimes they can cause problems. I always recommend- We can probably throw a link in the chat. overlayfactsheet.com has a lot of information. The other thing I’ll say is, UsableNet, they look at all of the lawsuits every six months and put out a report on what it was. Last year, for the whole year, about a quarter of the lawsuits were against companies that already had one of those widgets on their website, and they got sued for not being accessible, and they had one of those. [crosstalk] will fix your problems or protect you legally.

>> RENEE: Yes. I think there’s also a class action lawsuit now against– Is it AccessiBee, I think?

>> AMBER: AccessiBee-

>> RENEE: Yes,-

>> AMBER: -is being sued by [crosstalk]

>> RENEE: -because it doesn’t do what they claim that it does.

>> AMBER: The business had AccessiBee, and the business got sued, and so they said, breach of contract. The whole time, AccessiBee had been sending them reports being like, “Your website is 100% accessible,”-

>> RENEE: Oh, geez.

>> AMBER: -and they were like, “You kept telling me it was, but clearly it wasn’t.” I would not recommend those. It’s better to go in and fix. I think the difference between the plugins like what you made is, yes, it might use JavaScript to fix things, but it’s very targeted to the specific builder and the specific component. It’s not broadly saying, I could work on Divi or Squarespace or Wix or some other– WordPress 2024 or whatever. It’s very targeted and so it is much more likely to actually fix the problems than these other tools that are generic, I think.

>> RENEE: Yes. I’m also not making any claims that this is going to make your website 100% compliant because there’s, obviously, like 7,000 other problems that could exist, that this is really only tackling a very specific–

>> AMBER: Hopefully not 7,000. [laughter]

>> RENEE: This is targeting a very specific set of problems. Like I said, definitely test on a development environment first because I’ve– Basically, I’ve only been working with this with a limited number of websites at this point. The ones where I’m specifically helping them, and so who knows. There could be all kinds of other plugins out there that there may be conflicts that have to be addressed. Like I said, the universe that I’ve been working with right now has been pretty small, so definitely do extensive testing before you put this on a production environment.

>> AMBER: Okay. It’s really hard to know what all the server environments and all the plugin configurations and all the things are going to be like, so yes, totally get that. Rob was asking, “How do you balance accessibility with beautiful design?

>> RENEE: [laughs] I am not a designer.

>> AMBER: Someone else gives you the design and you code it out?

>> RENEE: Yes. I do partner with yet another agency in town. They are the designers. We just go back and forth. I was actually doing this today where they will come up with the design in something like Figma, and I will start to be like, okay, there’s color contrast issues here that we have to deal with, or this might be problematic when it gets into production. I kind of let them come up with the design and then we go back and forth about, like, this might be problematic, this needs to get tweaked a little bit.

Then once it goes into production, which they use Elementor for their websites, so then I’ll go through and do more functional testing. Like, okay, we need to tweak this or things like that. I’m just not a designer so somebody else has to come up with the pretty, and then I help figure out how to make it functional. [chuckles]

>> AMBER: I want to say it’s a little bit of, I don’t know if it’s a misnomer or something, but I don’t know if I agree that you have to balance accessibility with beauty. I think that really accessible things can be very aesthetically pleasing and look beautiful on the web. There are some really great examples of that. They can even have even surprising functionality that makes them interesting, so I would push back on that a little bit.

We build websites, they don’t all look the same. They’re not all dark. Some people think color contrast means everything has to be maroon and black and dark blue [chuckling] or something, but that’s not the case. You can have pastels. You just have to have them on a darker background or have light te– or dark text on your pastel background, right? You can have all kinds of different colors, and you can have engaging functionality, and you can have, very interesting graphics, and it can still look, “beautiful” and be accessible.

Yes, I think you’re right, though. Sometimes, as a developer, you have to look at the Figma files and go back to the designer and say, “Hey, explain–” Sometimes I’ll just start with, “Can you tell me more about what you were thinking for the functionality of this section?” {chuckles] Sometimes I’m looking at it, and I’m like, hmm. [laughter] Right? Then have some of the conversation around, okay, well, how do we think this would work with a keyboard and not just a mouse? Like, okay, maybe we need to come up with an alternative for that situation.

>> RENEE: Yes. It helps when, like I said, the designers that I’m working with, they understand. It’s not like I’m coming back behind them and being like, “No, you can’t do that.” They want to be able to have their be accessible, and so it’s a good back and forth to have that, like, “Oh, cool. I never would have thought of laying something out that way, and that’s cool,” so it’s a good kind of back and forth relationship.

>> AMBER: What’s best practice for keeping the total cost of ownership of websites low when paying attention to accessibility throughout the site’s entire life cycle, not just at the beginning? Do you have any thoughts on that?

>> RENEE: I think it probably goes back to just having a good design to start with so that you’re not having to spend a whole bunch of time and money with extra plugins and extra code to remediate it. If it’s a good design to start with, then, yes, you don’t have to worry about things like buying the extra plugins or doing all the extra remediation and then worrying about what happens when all those things have to be updated and everything like that.

>> AMBER: I think another way, when I think about how do you help keep the ongoing costs related to accessibility down, so one is training. Whoever is managing the website. Whether it’s your content person on your team or the client that you’re handing the website off to, they have to be trained on how to enter their content and maintain their content accessibly.

Our plugin, I think, is helpful for reminding people, [chuckling] but just training and ongoing training, like reminder training, is helpful.

Especially if you have a client that they edit their website once every three or four months, you probably need to at least have annual, “Hey, let’s have a quick hop on and here are things I notice.” I also think, too, there’s a line there, whether it’s some revenue threshold or business size, which is different based on every law, [chuckling] and different localities around the world, but there’s definitely a line where website owners just have to expect to pay some amount to invest in their website on an ongoing basis.

I don’t think it’s realistic to think, “We’re going to build it, and it’s going to be exactly the way it was when we built it 10 years from now, and I’m not going to pay anyone to monitor it or to update things when plugins update.” Especially not in WordPress, right? Maybe with static HTML, but then who wants that website, you know? I think there’s probably some education there and that there’s a base level.

I think the biggest thing is making sure that the content people, they’ll do it and test your plugins in a dev site before you update them live and report issues back to the plugin developer if they’re introducing a problem. That’s a thought I’ve had, too, like we’ve talked about when we do remediations. If we find things in a theme or a plugin, we’ll try to, yes, we could fix it, but then it’s only for this one site, but also that means we have to spend our time which gets billed hourly to the client.

If we find it, and we just report it to the theme developer or the plugin developer and then they release an update, I don’t have to bill the client for the work to build that update, so it’s cheaper for the client. Also, it has the benefit of everyone gets the fix, not just my client, so there’s some of that. Let’s see. Scott said, “I assume many of us use Divi because it allows a greater deal of freedom in site design at a reasonable cost to the client.” This is sort of related on budgets and complying with laws. I guess that was a little bit of a duplicate, but I don’t know if you have any extra thoughts on budget or pricing or anything like that.

>> RENEE: Not specifically. I definitely agree with everything you said, that definitely the training and just making sure that people understand what they should and shouldn’t be doing. Education here.

>> AMBER: Then it looks like the last question that I have in the Q&A right now is, “What about the agency practice of having clients sign a waiver when they decide accessibility isn’t a priority, and they won’t budget it for it? Are agencies still going to be liable?” I’m going to ask that question and say, we can’t give you any legal advice because neither of us are lawyers, so I don’t know if they’re liable or not if you [chuckles] sign a waiver. Is that you’ve ever done?

>> RENEE: I have language in my contracts that basically say that, I, to the best of my ability, it’s we’re trying to meet the WCAG standards. This was even before all these rules that say, okay, fine, we’ll use WCAG as our technical standard. I’m just like, this doesn’t mean that you necessarily will comply with ADA or any other law, and you should definitely check with a legal professional.

Especially if I did a full website, basically at the time that the project is done, I make a backup at that moment so I know exactly this is where I stopped being involved, and that’s what the site looked like as of that moment. If they go and do something five minutes later that is problematic, I kind of have that like, that didn’t involve me. I just have that point of reference.

>> AMBER: That’s smart. You’d have a zip that you store in a drive, a Dropbox folder or something, so if you had to reference it, you could?

>> RENEE: Yes.

>> AMBER: It’s probably also handy when the client accidentally deletes their entire website. [laughter]

>> RENEE: Luckily, I haven’t, knock on all the wood, I haven’t had that yet, [laughs] but yes, I could, I could see that being helpful.

>> AMBER: We also have contract language. Our contracts defines accessibility in the contract as WCAG compliance. It specifically states that it doesn’t include legal compliance. Then there’s a section our attorney wrote that says we’re not a law firm. It’s literally in our terms of service that our attorney’s like, “You need to have this. Just in case. Then in our statement of work, when we list out what’s included, like in-scope items, we will list out the components that are going to be accessible. Which for us is the definition of WCAG conformance.

It will be like header, footer, sidebars. Pages that our team has manually compiled that are in-scope, which are listed somewhere in the like design in dev list. Then it will say like, anything that comes out of the theme, because we built a custom theme, but anything else is explicitly not in scope for accessibility. We’ll say to people, let’s say you’re importing 500 blog posts from your last website, we will train you on how to go through them and fix them if you want to do that, or you might have a discussion about whether you actually want to keep all 500 blog posts. Right?

Sometimes we just delete content that’s not helpful. They could then pay us to audit and remediate, but we’re never going to promise accessibility of something we haven’t looked at. I can’t say it’s accessible if I or if someone on my team has not tested it. That’s how we handle that. We have had times where they’ve literally asked for something that is in a section we guaranteed would be WCAG compliant and then they asked for this specific thing. As much as we fought with them, they were like, “No, it has to be this way.”

In that instance, we had them sign something that said that they understood that they were asking for XYZ in this part to function in this way, like I described it, and this would violate this success criteria of WCAG. They were releasing us from our obligation for that one component for WCAG conformance. That was how we handled that when we talked to our attorney. Again, talk to your own attorney. I don’t know. Maybe it won’t actually protect me legally, [chuckles] but that is what we did. [chuckling]

Alice asked for a sample of the language. I will tell you our terms of service, which has the stuff about not being a law firm and stuff, you can actually get in the footer of our website because they’re visible to everyone. I can find that real quick. I don’t know if you have any contract language anywhere public.

>> RENEE: I have some stuff on public pages on my website, yes.

>> AMBER: Maybe if you have a few links you could throw in the chat. That’s our terms of service. The other things where I wrote some in– I keep thinking I need to put these on my website. I wrote a series for the admin bar, which is a really fun Facebook group for agency owners, if you haven’t heard of it. I’ll just share a link to this last year, Accessibility Weekly. There are a couple of posts which were at the end of my series, so they’re at the top of that page about accessibility.

Web Development Contracts is the title of one of them that is relevant and has some contract language. Like from our statement of work, which we don’t have public because it’s unique to every client. Hopefully, that’s helpful. I saw, Renee, you threw one in there as well.

>> RENEE: Yes, I had to just change it to everybody, though. That’s just a service page that there’s a legal disclaimer at the bottom of it.

>> AMBER: Well, I think those are all the questions that we had. This has been a great presentation, as I said, and a wonderful conversation, so thank you so much.

>> RENEE: Oh, thank you.

>> AMBER: Thank you, everyone, who stuck with us for the full hour and a half. We’ll be back in two weeks with another WordPress Accessibility meetup. Bye.

>> RENEE: Bye.

View “Strategies for Creating Accessible Websites Using Divi Theme and Page Builder” Website Slides.