This episode is a recording of an August 2024 WordPress Accessibility Meetup where Renee Dunn from Elevage Digital shared strategies, lessons learned, and code examples for improving the accessibility of web pages built using the Divi theme and page builder. WordPress Accessibility Meetups take place via Zoom webinars twice a month, and anyone can attend. If you want to watch a video recording from the meetup, you may do so on the Equalize Digital website: Strategies for Creating Accessible Websites Using Divi Theme and Page Builder: Renee Dunn.
Listen
Links Mentioned
- View “Strategies for Creating Accessible Websites Using Divi Theme and Page Builder” Website Slides
- WordPress Page Builder Accessibility Comparison
- WordPress Theme Usage Distribution on the Entire Internet
- Web Content Accessibility Guidelines (WCAG) 2.2
- Overlay Fact Sheet
- New Class Action Lawsuit against AccessiBe
- OZeWAI Ask the Professionals 26 July 2024 on YouTube
- Equalize Digital Terms of Service
- The Admin Bar Accessibility Weekly
- Elevage Digital Website Accessibility Audits
Summarized Session Information
In this session, Renee Dunn explores strategies for making websites built with the Divi Theme and Page Builder more accessible. Working with local government agencies, Renee navigates the challenges of meeting the new WCAG 2.1 AA guidelines issued by the Department of Justice while constrained by budget and time limitations.
Renee details key accessibility issues inherent in Divi, such as missing skip links, inaccessible mobile features, and problematic focus indicators, as well as challenges in addressing these issues due to the lack of developer support from Divi. She provides several practical solutions, including third-party plugins and her custom accessibility plugin, to address common accessibility gaps in Divi.
The session includes a demonstration of Renee’s custom plugin, which adds features such as zoom functionality, customizable focus indicators, proper labeling for screen readers, and improved keyboard accessibility for menus and search forms. Renee also introduces her companion plugin, which addresses the Divi button and icon modules to generate the correct HTML elements and ARIA attributes.
Renee encourages testing her plugins in development environments and emphasizes the need for continued adaptation as new versions of Divi are released.
Session outline
- Introduction to Divi accessibility
- Divi 4 vs. Divi 4 accessibility
- Key Divi accessibility issues
- Challenges in addressing Divi accessibility issues
- Potential solutions
- Renee’s custom Divi accessibility solutions
- Practical implementation and examples
- Closing thoughts
Introduction to Divi accessibility
Renee Dunn, based in Fredericksburg, Virginia, shares insights on creating accessible websites using the Divi Theme and Page Builder. Working closely with local governments and agencies, she has had to ensure that the websites she works on meet the new WCAG 2.1 AA accessibility guidelines issued by the Department of Justice. Given that many of these websites are built on Divi and transitioning to a more accessible platform is not feasible due to budget and time constraints, Renee embarked on finding solutions to improve accessibility within the Divi ecosystem.
Divi 4 vs. Divi 5 accessibility
Renee primarily focuses on Divi 4 for her accessibility improvements. After researching Divi 5, she found that the new version does not appear to address accessibility issues. Renee encourages anyone with more information to share, but for now, her efforts are concentrated on Divi 4.
Key Divi accessibility issues
Divi has several known accessibility issues:
- No skip to content link: users cannot bypass navigation to access content directly.
- No mobile zoom functionality: users cannot zoom in and out on mobile devices, making text magnification impossible.
- No focus indicators: Divi’s CSS explicitly removes focus indicators critical for keyboard navigation.
- Inaccessible menus: dropdown menus and mobile navigation are not keyboard accessible.
- Missing labels: for example, the search form is unlabeled, leading to issues with screen reader usability.
- Screen reader confusion: icons added through CSS appear to screen readers as random characters unrelated to their visual representation (e.g., arrows being read as “four” and “five”).
- Module accessibility: many modules, such as accordions, tabs, and toggles, are not keyboard accessible, and the button module creates links instead of actual buttons.
These are just a few examples, with many more issues relating to Divi’s modules, such as blogs, contact forms, sliders, etc.
Challenges in addressing Divi accessibility issues
Renee highlights that a significant hurdle in solving Divi’s accessibility problems is the lack of support from the theme’s developers. Some issues require more than just JavaScript solutions; they need direct modifications to PHP or theme files. Divi’s vast array of customization options also challenges testing for all variations.
Potential solutions
Renee offers a variety of strategies to address these challenges:
- Switch themes: although not ideal, switching to a more accessible theme is sometimes recommended, even by Divi support.
- Disable problematic modules: for example, replacing the blog module with a custom loop in the theme files or using third-party form tools like Gravity Forms instead of Divi’s built-in options.
- Divi module builder: this plugin allows users to create custom modules that control HTML and CSS, offering more flexibility for developers who manage multiple sites.
- Use of plugins: Renee discusses several plugins that attempt to fix some of Divi’s accessibility issues:
- Divi Accessibility Plugin by CampusPress: this plugin addresses issues such as adding skip to content links and focus indicators. However, it does not work with all Divi headers and is not always maintained.
- Divi Assistant by PA Creative: similar to Divi Accessibility, it adds some accessibility features but does not fix everything, especially issues with hidden search forms and certain navigation elements.
- Divi-Modules Plugins: these plugins provide additional skip links and allow for defining ARIA attributes module-by-module. However, they still have some incorrect implementations that need further refinement.
Renee’s custom Divi accessibility solutions
After facing the limitations of existing plugins and Divi’s inherent accessibility issues, Renee created her accessibility plugin to address the gaps. This plugin is a collection of functions and scripts bundled into a single tool that can be installed across multiple websites. It offers a variety of features aimed at improving accessibility, including:
- Zoom functionality: Renee’s plugin enables users to zoom in and out on web pages, a feature not available by default in Divi, particularly on mobile devices. This allows users with visual impairments to magnify text and other elements easily.
- Skip to content links: the plugin adds skip to content links, allowing users to bypass navigation menus and jump directly to the page’s main content. This is especially helpful for keyboard users and those relying on screen readers.
- Customizable focus indicators: focus indicators are crucial for users navigating with keyboards, as they highlight the active element on the page. Renee’s plugin restores this functionality, which Divi’s default CSS removes, and allows users to customize the color of these indicators for better visibility.
- Improved labeling for screen readers: the plugin fixes label issues in Divi’s footer and social media icons. Before this fix, these elements would appear as undefined or unlabeled links to screen reader users, but with the plugin, they are appropriately labeled and identified.
- Keyboard-accessible mobile and dropdown menus: Renee made mobile menus and dropdowns accessible by keyboard. Previously, these elements were inaccessible without a mouse, but her plugin adds the necessary ARIA attributes and keyboard interactions to improve usability.
- ARIA-Label support in blog modules: Divi’s blog modules often generate “Read More” ambiguous links when screen readers encounter them. Renee’s plugin adds ARIA labels to these links, making them descriptive by including the post title, which helps screen reader users understand the context of the links.
- Search form fixes: one major issue Renee fixed was the hidden search forms. By default, Divi allows screen readers to access search forms even when hidden. Her plugin prevents this by ensuring search forms are only accessible when visible. Additionally, the plugin adds ARIA labels to the search form, improving accessibility further.
- Animation controls: Renee’s plugin respects device settings that disable animations for motion-sensitive users. If a user has animations disabled, the plugin ensures that any animations applied in Divi, such as zoom or slide effects, are turned off.
She also built a companion plugin that provides custom versions of Divi’s button and icon modules, addressing specific accessibility concerns:
- Custom button module: the default Divi button module creates links rather than buttons. Renee’s custom button module generates proper button elements when needed. If a user sets the link value to a pound sign (
#
), the plugin will output a<button>
element instead of a link. This ensures the correct HTML element is used for actions that trigger functionality, like submitting a form. - Custom icon module: similar to the button module, the custom icon module generates accessible icons. It ensures that icons are correctly marked with
aria-hidden="true"
when they are purely decorative, preventing screen readers from reading out unnecessary information. - Custom blog module: Renee is working on a custom blog module to better control the code output for blog listings, mainly focusing on making the “Read More” links fully accessible and descriptive.
- Custom sliders and icon lists: in the future, Renee plans to tackle more complex modules, such as sliders and icon bulleted lists, to ensure they meet WCAG standards.
These plugins are available on GitHub for other developers to experiment with, customize, and implement in their projects. Due to Divi’s complexity and variability, Renee encourages testing these solutions thoroughly in development environments before pushing them to live sites.
Practical implementation and examples
Renee walked through practical implementations of her custom plugin to demonstrate how it enhances accessibility on Divi sites. Below are a few of the examples she showcased, highlighting improvements with clear visual indicators:
- Tab navigation and focus indicators: Renee demonstrated how her plugin enhances keyboard navigation. As she pressed the tab key, the “Skip to Content” link appeared, allowing her to bypass the top navigation. Each interactive element, such as links and buttons, had a clear focus indicator that was customizable in color. This provides better visual cues for users who rely on keyboard navigation.
- Improved menu accessibility: one of the most significant enhancements was making Divi’s various menu styles fully keyboard accessible. Renee demonstrated how the plugin allows users to navigate through a menu using arrow keys. She also highlighted how submenu items, previously inaccessible without a mouse, now had clear focus indicators and could be expanded and collapsed using the keyboard.
- Accessible search form: Renee demonstrated the improvements to Divi’s search form. Before, the form was hidden but still accessible to screen readers, creating confusion. With her plugin, the search form is only accessible when visible. When triggered by pressing enter on the search icon, the form expands, allowing keyboard users to interact with it.
- Blog module enhancements: Renee showcased her custom blog module in action. She navigated through a list of blog posts using the tab key. The “Read More” links had ARIA labels that indicated the post title, making them fully descriptive for screen reader users.
- Animation control example: Renee presented a page with animations enabled by default, such as zoom-in effects and sliding elements. After activating her plugin’s animation control settings, she demonstrated how the same page would load without animations, in line with the user’s device preferences for reduced motion.
- Custom button and icon modules: Renee demonstrated how her custom button module generates the correct HTML elements based on the context. For instance, if the link value is set to a pound sign (
#
), the plugin generates a<button>
element rather than a link. Similarly, her custom icon module correctly hides decorative icons from screen readers, ensuring a cleaner, more accessible experience.
In her presentation, Renee encouraged users to test the functionality of the plugins in a controlled development environment before applying them to live sites. Due to Divi’s extensive customization options, unforeseen issues can arise when using multiple third-party add-ons. Testing ensures that all components work harmoniously and the intended accessibility improvements are practical.
Closing thoughts
Renee encourages developers to test all solutions in a development environment before deploying them on live sites, as the complexity of Divi’s customization options can lead to unforeseen issues. She continues to explore new solutions for Divi accessibility and plans to stay updated on changes with Divi 5.
Transcript
>> CHRIS HINDS: Welcome to 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.
And now, on to the show.
>> AMBER HINDS: 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.
>> STEVE JONES: This episode of Accessibility Craft is sponsored by Equalize Digital Accessibility Checker, the WordPress plugin that helps you find accessibility problems before you hit publish. 1000s of businesses, non-profits, universities, and government agencies around the world trust Accessibility Checker to help their teams find, fix, and prevent accessibility problems on an ongoing basis.
New to accessibility? Equalize Digital Accessibility Checker is here to teach you every step of the way. Whether you are a content creator or a developer, our detailed documentation guide you through fixing accessibility issues.
Never lose track of accessibility again with real-time scans each time you save, powerful reports inside the WordPress dashboard, and a front-end view to help you track down hard-to-find issues.
Scan unlimited posts and pages with Accessibility Checker free. Upgrade to Accessibility Checker Pro to scan your website in bulk, whether it has 10 pages or 10,000.
Download Accessibility Checker today at equalizedigital.com/accessibility-checker. Use coupon code accessibilitycraft to save 10% on any plan.
>> RENEE: 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.
>> 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, 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.