Listen
In this episode, we discuss common accessibility problems found in WordPress plugins and offer practical advice on when to evaluate, remediate, or abandon third-party software that has usability issues.
Mentioned in This Episode
- WordPress Accessibility Facebook Group
- Gravity Forms
- The Events Calendar
- FacetWP
- Elementor
- Beaver Builder
Transcript
>> CHRIS HINDS: Welcome to episode 034 of the Accessibility Craft Podcast, where we explore the art of creating accessible websites while trying out interesting craft beverages. This podcast is brought to you by the team at Equalize Digital, a WordPress accessibility company and the proud creators of the Accessibility Checker plugin.
In this episode, we discuss common accessibility problems found in WordPress plugins, and offer practical advice on when to evaluate, remediate, or abandon third-party software that has usability issues.
For show notes and a full transcript, go to “AccessibilityCraft.com/034.”
Now on to the show.
>> AMBER HINDS: Hey, everybody. It’s Amber, and I’m here today with Chris.
>> CHRIS HINDS: Hey, everybody.
>> AMBER: And Steve.
>> STEVE JONES: Hey. How’s it going, everyone?
>> AMBER: And we are going to be talking today about accessibility in WordPress plugins. But first, we’re going to have a beverage. What are we drinking today, Chris?
>> CHRIS: So we are going to be giving a craft mocktail a try, so this is zero proof, zero alcohol. We’re trying Zero Proof Watermelon Mojito by Recess, which is not something I’ve tried or I think even seen before. But their big claim is they have some of those adaptogens and additives in this, so it’s got Guayusa. I don’t know if I’m pronouncing that right. It’s got some botanicals in there, and it is made with real juice. The whole can is only 25 calories.
>> AMBER: 5% juice. It’s not like a total juice.
>> CHRIS: Yes, that’s true.
>> STEVE: What’s an adaptogen?
>> CHRIS: Good question.
[laughter]
>> AMBER: Everyone, Google, really fast.
>> CHRIS: One of those buzz words that I think make health-obsessed people want to buy things.
>> AMBER: [laughs] It got me because it said “watermelon,” and it’s still 100 degrees here. That has been the theme of the drinks lately, and I was, like, “Watermelon into summer. That sounds like a good drink.”
>> CHRIS: Well, and it’s mojito, so it’s mint too, so you have double cooling happening.
>> STEVE: Yes.
>> CHRIS: And it’s got a goby in it.
>> STEVE: “An adaptogen are plants and mushrooms that have been found to help the body respond to stress, anxiety, fatigue, and overall well-being.” So this should be excellent for developers.
[laughter]
>> CHRIS: Yes, and this is our second. We’re still recovering from Ward Camp US, so we’re going to continue our recovery with this mocktail. Do we want to crack it open and again give this a try?
>> AMBER: Yes. It also says it has some caffeine in it. It says less than half the caffeine in a cup of tea, but it does have some caffeine, so maybe that’ll give you a slight buzz if you’re a caffeine person.
>> CHRIS: I pretty much don’t feel caffeine unless I’m chewing on coffee beans at this point. I’m pretty sure my body has fully adopted.
>> AMBER: It’s because you drink coffee all day long.
[laughter]
>> CHRIS: All right.
>> STEVE: I don’t know how many you said of these, Chris, like 12 or something? My wife has pretty much drunk all of them except for the one.
>> CHRIS: So it’s a chick drink, is what you’re saying.
>> STEVE: Yes, yes.
>> AMBER: OK. I’m smelling it and it smells like a Jolly Rancher.
>> CHRIS: Yes. Actually, you’re right. It’s spot-on. It does smell like a Watermelon Jolly Rancher. I smell some of that mint too. Let’s give this a taste.
>> AMBER: Oh, I like it. It’s got a good mojito flavor, like, it’s minty. It’s not as watermelon-y as I might like, but I really like it. I have no complaints about this.
>> CHRIS: No. I don’t have any complaints either. I definitely lose the watermelon to the mint. The bubbles are nice. It’s not overly effervescent. It’s not overly sweet, but you do get some sweetness. I can taste the agave. You know, what I’m not getting is a weird botanical aftertaste that masks all the pleasant flavors, like we’ve had with a couple of other of these drinks that have these additional additives in them, so yes, this is good. I can see why there’s only a couple left at your house, Steve.
>> AMBER: Steve, what’s your verdict? You haven’t said.
>> STEVE: No, it’s good. I like it. If I was to tweak it, I’d probably be more watermelon than mint.
>> AMBER: But would you buy it again?
>> STEVE: I think I have to because of my wife.
[laughter]
>> AMBER: Yes. I really like this. This is probably my favorite of all the, like, fake alcohol drinks we’ve had, like mocktails. This is definitely my favorite. It has good flavor. The very first one we had tastes like water, and then the other ones had this weird plant-y rosemary soapy something going on, but this is nice. It’s clean. It doesn’t have the plant flavor. I get the mint and a little bit of fruit.
>> STEVE: “Take a recess from buzzed to balanced, from replacement to enhancement. Welcome to the new kind of party”
>> CHRIS: Yes. Also, their tagline is apparently, “A drink for when you don’t want one.” So that’s kind of an hashtag. I feel that way very often. For most of WordCamp US, I was having sodas with limes, so I appeared to be partying with everyone else, but I wasn’t.
>> AMBER: You were just laughing at all the drunk people. [laughs]
>> STEVE: There you go.
>> AMBER: You’re, like, “You think I’m laughing with you, but really…” [laughs]
>> STEVE: “I’m taking notes.”
>> CHRIS: Yes.
>> AMBER: OK, so I think this is a winner. I’m going to totally finish this while we do this episode, sometimes I don’t finish the beverages, and I’m excited to drink more because I haven’t tried them until now.
>> CHRIS: Yes, I know. At our house, we still have 10 left.
>> AMBER: Yes, we have, so Recess has a bunch. Since we do this podcast, I get all these ads on Facebook and stuff for craft beverages, but mostly they’re all non-alcoholic, so I guess Facebook has pinged me as somebody who’s interested in non-alcoholic beverages. Or maybe you can’t even advertise alcohol on Facebook. But they have a lot of different flavors, so I would definitely go try more.
>> STEVE: Yes. Very good.
>> CHRIS: Yes. Maybe another Recess flavor will make its way onto “Accessibility Craft” in the future. I’ll definitely remember to check them out again.
So let’s shift over to talking about accessibility mistakes in WordPress plugins, and I have the privilege of being the person that gets to ask the questions today, because I don’t do our auditing, and I don’t look at the accessibility of a lot of plugins in a really granular way, so I might throw in some comments here and there, but we’re going to lean on our two more technical guests to get us through some of these questions and these ideas.
So first, how would we go about assessing a plugin to see if it’s OK to use, if we’re concerned about our website being accessible, which we should be?
>> AMBER: Yes. I might start with that. Actually, last night, I was working on the volunteer handbook for the WordPress Accessibility Day website, and previously, we had it in a Google Doc, but we decided for better accessibility, it should be a web page, because Google Docs can sometimes be challenging for screen-reader users, and I put it on and I was, like, “This thing is really long, it needs a table of contents.”
Normally, when we build table of contents, Steve does makes a custom block, but I don’t know how to do that. [laughs] I don’t know how to magically make table of contents show up, so I was, like, “I’m going to go see what’s available,” and I searched on “WordPress.org” in the plugin directory, and there are 12, maybe even 20, because I didn’t go multiple pages deep. Different table of contents plugins, and then I got really brave and I was, like, “I’m going to live stream this in our Facebook group, testing them.” I did two and then I had to go away to a volunteer training, and then Alex was commenting, and he’s, like, “Let’s get on.” So he got back on.
So if anyone wants to, if you’re in our Facebook group, you can go find a 20-minute video of me, and then an-hour-and-15-minute video of me and Alex, where Alex is sharing his screen and testing these plugins and trying to decide. But I mean, really the best way is to test it. Put it on a sandbox site. Don’t put it on your live site, if you can.
>> STEVE: Yes, yes.
>> AMBER: And just try and go through it with a keyboard, then with a screen reader. I mean, gosh, with these plugins, we were also testing the back-end, because he was the one who was configuring them. I should have been crying, but I was laughing so hard, because Alex, who is going to be a future guest on this podcast, by the way, Alex Stein, he’s kind of hilarious. [laughs] And he goes in, and we just hear, “This plugin has table of contents,” like, all the headings on the left in the block editor, and then next to each one, there’s a little button with a pencil on it, and a button, and then a second button with, like, an eyeball on it, so you can either edit the heading in that list of links, or you could hide it, and he goes and it’s just like, “Button, button, button, button.” And he goes, “Oh, this isn’t good.”
[laughter]
Then he just keeps going through it, because it was a list of maybe 40 headings with these. Just buttons that said nothing. [laughs]
>> STEVE: Yes.
>> AMBER: So yes. What do you do when you’re testing, Steve?
>> STEVE: When you asked the question, Chris, I was thinking more in the back-end than the front-end, when you were talking about trying to find the table of contents block that you could use. But I guess it makes sense that you were trying to find one that was accessible in the front-end. I mean, it’s kind of interesting too.
We’ve had requests with our Accessibility Checker Plugin to exclude other plugins’ accessibility issues from the reports.
>> AMBER: Wait, have we really? I missed that support ticket.
>> STEVE: Yes, yes, so Query Monitor, not to call out Query Monitor because I love that plugin. It’s amazing. I use it all the time, and I will say a little piece on that in my testing of it. But we had a user of our plugin who wants us to exclude the Accessibility Checker output on our scans, and I think we also were excluding the WordPress Admin Bar, because that can be filtered, right? Any plugin can inject anything they want into that, and it could introduce accessibility issues for logged-in users, right? So we’ve added an exclusion for that as well.
In my testing, I will say, I didn’t notice any issues being picked up in Query Monitor, but that may be because I didn’t have any… You know, what’s inside a Query Monitor can change based on what’s on the page, right?
>> AMBER: Yes.
>> STEVE: Like, if there’s more errors or outputs or whatever, right? So I will say I didn’t notice any, but obviously that user of the plugin was, you know, every post they were on and they’re logged in, right? The plugin’s logged in, and when it scans, it’s finding those errors, so you can use some automation tools to check. I think Wave would run in the back-end of WordPress, right?
>> AMBER: Yes, if you want to check the back-end.
>> STEVE: Yes.
>> AMBER: But even if we’re just talking about choosing the front-end, and maybe that’s sort of an interesting point on the, like, excluding the Admin Bar. It might be that if you don’t allow people to log into your website, or even if you do, maybe you’re blocking the Admin Bar for them, and you know that no one on your team at least currently has disabilities, then it might be fine for us to exclude that, because it’s not really impacting your customers. It’s only impacting people on your team, and you have more control over when or if the accessibility matters for your team. But yes, I think using the automated checkers is helpful. I do that on plugin demo websites all the time.
I think my first go, if I’m trying to pick a plugin is, I sometimes go by the number of installs, like, I’ll usually start with the highest number of installs, which is maybe not fair to newer plugins?
>> STEVE: Yes, yes, same.
>> AMBER: But I do that, and then if they have a demo, I’ll go try and look at their demo website first, because I was, like, “That might save me a lot of time not having to put it on a fake site.” But then if they don’t have one, then I usually will… Spinup(WP). I use Local to do local sites. The one that’s owned by WP Engine, Local WP, and I just have a sandbox site that I’ll sometimes install the plugin on and all. Yes, I’ll do the same thing that we would do for auditing a live website to try and figure out common problems.
>> STEVE: Same here. Yes. Try the keyboard on it and see how it works.
>> CHRIS: Yes.
>> STEVE: What I think would be cool for plugin devs in their “readme,” right? What outputs in their description if they have some kind of accessibility statement, is that the right word, about their plugin? I mean, that would be kind of cool. Like, if you’re going through and you’re trying to find an accessible plugin, which they should all be accessible, right? But a lot of times… That’s specifically what you were looking for, Amber, right? It was accessibility, and if you would have put that in your readme, some kind of statement about your commitment to accessibility in your plugin, I think that would help get more downloads.
>> CHRIS: Do you ever look for or ask for a VPAT? Or have you ever done that?
>> AMBER: So we have advised that our clients, like our Higher Ed clients, ask for them, because they’re technically required to ask for them. I don’t, because my assumption is there are no WordPress plugins outside of mine. [laughs] And maybe a very small handful of plugins that are actually connected to, like, a SaaS service. They’re not just like a WordPress plugin that have them.
I think most WordPress plugin developers have probably never even heard of a VPAT. If you haven’t heard of a VPAT, it is a voluntary product accessibility template, which is a document that you can go through where you basically list where your software either partially meets or doesn’t meet at all every individual Web Content Accessibility Guideline, success criterion, and other success criterion, like for section 508 or for European accessibility laws, and If you’re selling to the government, like the federal government… NASA, for example, when they bought our plugin, they were, like, “You need to provide a VPAT or we will not buy your plugin.” So if you think you’re going after enterprise, as a plugin developer, you should definitely have those.
We got asked by another plugin that NASA is considering using, and they asked them for VPAT and they’re, like, “We don’t have one.” So then they contacted us to be, like, “How much would it cost for you to audit our plugin and help us write a VPAT so that we can get this contract with NASA?” So you definitely need them. I’m assuming that they don’t. I think having an accessibility statement would be neat.
I had a conversation with Mika [phonetic] before she left. She’s someone who was really big in the plugins team for many, many years, and we had an interesting conversation on Macedon about plugin reviews, and right now, outside of the initial submission, there’s not any oversight on plugins and their quality, right, Steve?
>> STEVE: No. No.
>> AMBER: And what I would love to see WordPress do.., and this was what she and I sort of talked back and forth on Macedon was, integrating WPCS with plugin pushes, and having a visible label that makes it really clear to users in the plugin directory if a plugin passes or fails, because those are easy automated checks, and I think it could be interesting to even build into that some baseline accessibility. Now could you get everything? No. But there are certain things that you could probably check with a scan of the plugin’s code and flag, like, “This might be not good from accessibility standpoint.”
>> STEVE: Yes.
>> AMBER: So I think that would be neat to see. I have no idea if we would ever get there. But…
>> STEVE: I mean, I could see that starting a huge fight in the WordPress community, right? Especially when, you know, people are always trying to keep up with accessibility world view, and Core as well, right?
>> SPEAKER 1: 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.” A WordPress native tool, Accessibility Checker provides reports directly on the post-edit screen. Reports are comprehensive enough for an accessibility professional or a developer, but easy enough for a content creator to understand.
Accessibility Checker is an ideal tool to audit existing WordPress websites, find accessibility problems during new builds, or monitor accessibility and remind content creators of accessibility best practices on an ongoing basis.
Scans run on your server, so there are no per-page fees or external PPI connections. GDPR and privacy compliant. Real time accessibility scanning. Scan unlimited posts and pages with Accessibility Checker free. Upgrade to a paid version of Accessibility Checker to scan custom post types and password-protected sites, view site-wide, open, issue reports, and more.
Download Accessibility Checker free today at “EqualizeDigital.com/accessibility-checker.” Use coupon code, “Accessibility Craft,” to save 10% on any paid plan.
>> AMBER: Yes. I think what she had said was maybe it happens when you hit a certain threshold of users, so you don’t get those sorts of scans when you only have 100 active installs, but the moment you hit 10,000 is when it’s going to start, because it’s like a lot of people are using this. You could be adding significant security risks, right? Or other quality issues, and accessibility is certainly one of those, so maybe it’s based on the plugin install count threshold, or maybe it’s an opt-in that plugins could opt into, where they could get some sort of test from the accessibility team. Now, of course, who’s going to do that? [laughs]
>> STEVE: Yes. Yes.
>> AMBER: But maybe they pay for it. Maybe that’s an optional thing that they could pay for, and then that pays someone on the accessibility team for their time to audit, and then they fix whatever problems; it gets retested, and then they get a badge, and that’s part of the foundation. Now, I know Matt Molik [phonetic] has said it’s hard to pay people out of the foundation because it’s not really set up that way. But there’s the Open Collective or something that Courtney Robertson started for being able to pay contributors? So there are nonprofits that maybe that could run through. I don’t know, but that would be neat.
>> CHRIS: So when we’re testing plugins, and we frequently test plugins, what are some of the most frequent accessibility problems that you both see or that we encounter?
>> AMBER: You want to go first, Steve?
>> STEVE: “Button, button, button, button.”
[laughter]
Right? What Amber said earlier?
>> AMBER: Well, I mean, boy, at least those ones were buttons. There’s also plenty of things that are just spans or divs or links, all the time. I think a lot of developers do not understand the difference between a link, which is supposed to take you somewhere to another webpage or lower down on the same page or higher up or whatever, and a button which is supposed to engage in interaction.
>> STEVE: Right, and because a JavaScript will allow you, you can target any element. Then they could use a span or a div as a button, right? It can get pretty messy. I think that’s probably the biggest, right? I think that’s number one. One of the biggest issue.
>> AMBER: Yes.
>> CHRIS: So if we were to put a pin in that as far as summarizing, is it just like not tagging things appropriately in HTML, basically?
>> STEVE: Yes, not using the right semantic markup for its intent. Yes.
>> AMBER: I think another area where we see a lot of problems are with Accordions, and there’s a lot of different plugins that include Accordions in different places, or they have Accordion Blocks or things like that, where those don’t function properly? Carousels are a big one. But I think a lot of that comes down to the lack of the button controls that are accessible buttons, so I really feel like that’s a huge problem. Color contrasts can be a problem?
>> STEVE: Yes. Color contrast, modals, forms.
>> AMBER: Oh, yes, so with modals, like we talked about before, managing focus is a big issue. Those table of contents plugins, one of the things we were looking for on that was, if Alex followed a link to a heading, did the screen reader then read out, and did it shift focus? Or did it just visually scroll the page, but not actually move his focus? And I feel like a lot of the plugins that use, like, smooth scroll have problems with that, like, they’re not managing focus appropriately. Carousels, too, typically don’t manage focus very ideally.
>> STEVE: Yes, and style. Yes, the styles for focus, and… Yes, what else?
>> AMBER: Oh, yes. Gosh. If you are a plugin developer, you should never ever, like, there is literally no reason why you would ever say, “Outline zero” or “Outline none” on colon focus. You should never remove the focus outline, ever.
>> STEVE: Yes, because even if you don’t put anything, the browser or the theme would inherit, and there might be something there that’s useful to a keyboard user. But when you go and override the styles and force it not to have it, then that’s trouble for you. That happens a lot.
>> AMBER: Yes, and that’s what’s so frustrating. You can put a plugin that does that in a theme that has good focus indicators, but the plugin styles will take precedence because they’re closer to the element in the style tree, however you say that. I don’t know if that’s the technical way of saying that. Steve can correct me. But they’ll override whatever is happening in the theme, and that’s really frustrating.
>> STEVE: Yes, so just like missing or incorrect aria labels, that happens quite a bit.
>> CHRIS: What about like excessive aria labels? Have you ever encountered were they’re being overused?
>> STEVE: Maybe not overused, but incorrectly used. Icons a lot of times are not hidden, so the icons read out when you tab to them, or it reads out like as like… In the screen reader, like, visual text thing, you know, it shows like broken font square. You know what I’m talking about?
>> AMBER: Yes.
>> STEVE: Because it can’t actually show it, but.
>> AMBER: Yes, so I think, like, inaccessible names or accessible names that are ambiguous. Actually, we were looking at a carousel. You double-checked it for me on a plugin that on one of the websites we were auditing, they had just used a plugin to create the carousel, and I think the “previous” and “next” slide buttons were just like an arrow pointing, or like a bracket. I don’t even know what it is.
>> STEVE: Yes, yes, yes, yes. Yes, it was like a greater-than sign.
>> AMBER: Yes, so I think it would say, like, “Button, greater than.” [laughs]
>> STEVE: Yes, yes.
>> AMBER: Which makes no sense, right? “Button, less than.” [laughs] Or if you have buttons that do the same thing for different elements, so for example, when I was talking about the table of contents block with the edit buttons, which those were unlabeled, but it wouldn’t be good enough to just say, “Edit, edit, edit.” Like, you would need to say, “Edit, heading,” and then say the heading. “Edit, heading,” and then say the heading, so that they’d be different and unique from one another, because they have different and unique functionality.
>> STEVE: Yes.
>> AMBER: Yes, so I see that a lot in plugins too, where maybe they’ve tried and they’ve gotten close, but they’re missing the whole, like, everything needs to be really unique and just clear to people?
>> STEVE: Yes, so I think another thing that I see sometimes is inaccessible media content, where it’s a custom block or something, and it adds images or video, and it doesn’t always give you options to… Or it doesn’t output the alternative text or the caption or description, so we’ve seen this in themes and stuff before, where it’s outputting the image, but it’s not grabbing the alt text that’s been defined in the WordPress Admin, so I’ve seen that quite a bit.
>> AMBER: Yes. Actually, what that also kind of leads me to is, I think a big accessibility mistake that plugin developers sometimes is giving too much freedom to users, so one of the table of contest box that we looked at yesterday, it had so many settings that I was just overwhelmed. We don’t even know, like, all these different settings. But it had the option of having your table of contents in an un-ordered list, which was default, which is what I think was good. Un-ordered list, which might be fine, because, technically, it is ordered or none, and then I’m, like, “Why?” Like, we didn’t even test it, but I’m, like, “I guess it would put it in divs or p tags or something,” but why? Why would we give that option to users? It’s a list. It should be a list.
>> STEVE: Yes.
>> AMBER: Or I’ve seen, like, on Form plugins where they have the option to remove the label. One of the table of content plugins had animation, and you could make your table of contents zoom in, fade in, fly in. [chuckles] And I’m just, like, “Well, that’s great, but why?” I’m, like, “Let’s not,” because it’s actually horrible. [laughs]
>> STEVE: Because the more features you put in your plugin, the more it’s going to get downloaded or sell, right?
>> AMBER: Yes. I mean, I guess. That’s what they’re trying to do. They’re trying to differentiate. But at the same time, it’s, like, “Why don’t you differentiate on, like, quality code, not giving your users options that they’re just going to abuse and not understand?”
>> STEVE: Sometimes options under the hood are fine to an extent, right? But I think the plugin dev should make those decisions, like, “Out of the box, what does this do?” And those should be the correct decisions. Now, if there’s a minor use case where you want to flip what the list markup is, then maybe there’s a use case for that, but maybe there’s not, right? Like, it’s going to provide bad accessibility.
So you want to do it right out of the box and then decide what settings should go in there, and just because somebody goes on the support form and asks for a feature, it doesn’t mean you have to put it in there if it’s not the right thing for your plugin, or if it’s not the right thing for accessibility, because you’re just adding technical debt to yourself that you’re going to have to maintain moving forward. Plus it’s probably bad. It could be bad as a whole from an accessibility standpoint.
>> AMBER: This is sort of a tangent, but I’m curious, how have you been assessing that when people ask for things in our plugin?
>> STEVE: Well, my default is, “No.”
[laughs]
>> AMBER: You asked for something, “No, we’re not going to do it.” OK, everyone who purchases our plugin, you did not hear him say that. He really cares about your feature request. [laughs]
>> CHRIS: [playfully] No feature for you.
[laughter]
>> STEVE: No. I mean, it happens. Yes, this is a tangent, but we can go down this road. It happens differently with different requests, right? There’s definitely been times where we’ve gotten requests and I’m just, like, “No,” because I know it’s going to be extremely difficult to implement.
>> AMBER: So is that always a “No,” or is it more of kind of like a, “Not right now”?
>> STEVE: It’s more like, “Oh, I just don’t know if we can do this in a timely manner.” And then there’s times where a request has come in and I’m, like, “Yes, this is cool.” And I’ll open an issue, and then Amber will be like, “No, we shouldn’t do that.” [laughs] So it kind of goes both ways.
>> AMBER: Yes. I’m trying to remember an example, but [laughs] I can’t think of one.
>> STEVE: Yes, there was one recently. I think maybe it came in through Chris, like, there was a client that Chris had spoke to or something and I was, like, “Yes, that sounds cool. We should do that. We can implement it pretty easily.” And then Amber was, like, “No, I don’t think we should do that.”
>> AMBER: What was it? Do you remember?
>> STEVE: I don’t remember.
[crosstalk ]
>> CHRIS: We’re in the territory of having thousands of users now, and it’s happening more and more frequently, the requests, and there are some that I filter out that are just outlandish, or they just aren’t in keeping with the values of our company.
I’ve had multiple requests of, like, “Can we run the scan privately and hide the reports from our clients?” And I’ve had that request multiple times, and this podcast is the first time I’ve brought it up with you all. But I’m, like, that’s a bit of an ethical concern to offer the option to hide the results of an accessibility scan from certain users.
>> AMBER: I don’t know. Well, I could see doing it in certain user roles. I know we’ve talked about maybe eventually getting to a point where, like, an author can only see the issues that are created in the content, because they can’t control the header in the footer, and it’s just noise for them? So I don’t know. I could maybe see that, but yes, it is…
>> CHRIS: Yes, in that use case. But the request I was getting was, “Can we hide it all together, and only have admin see anything at all?” And so I’m kind of, like, “Then what’s the point?” [laughs]
>> STEVE: Yes. There might be a use case to have it by user role, right? Because I know when we do our enterprise projects and stuff, we’re not just making WordPress websites. They could be anything. They could be something like SaaS built on top of WordPress, a portal, so there could be a use case where there are certain users in there that you wouldn’t want to see the output, right?
>> AMBER: Yes. Oh, you know, actually, I do know one that someone asked. It was an agency, and they said their clients really want to have one of those little floating icons on the front, like an accessibility icon, like an overlay ads, and they were, like, “We don’t want an overlay, but the client really wants to have that because they think that it will help their customers’ perception of their website.” And I was, like, “I mean, floating bugs in and of themselves can be accessibility issues,” [laughs] especially for.., and I was, like, “I mean, there’s a footer thing. You can’t just have them.” And they’re, like, “They really want it.” And I was, like, “We’ll think about it.” [laughs] But really I was going, “No. I mean, I don’t know.” I was, like, “Well, would it just be there and not do anything?” And he’s, like, “No. You could click on it and it would open a modal that would talk about accessibility, like a little short blurb, and then you could go to the accessibility statement for more or something.” I don’t know.
It would probably be a really good marketing for us if people had our logo all over their website. But at the same time, it doesn’t feel like a good choice.
>> CHRIS: Is it good marketing for us if the act of having that feature available produces accessibility issues, right? That might be bad marketing for us.
>> STEVE: Or if they’re thinking of it as, like, “We’re endorsing this website as accessible,” right?
>> CHRIS: Yes, there’s also that.
>> STEVE: Where an automated tool such as Accessibility Checker can only check what can be automated, right? Like, it requires human being. I don’t know.
>> AMBER: Yes, so that’s an example of something that someone asked for that I was like, “I don’t think this is good for accessibility, so we shouldn’t do it even though people…” I mean, it wasn’t like a lot of people asked for it. I think probably when you’re doing that, you also sort of take the feature request and you prioritize things that a lot of people are asking for?
>> STEVE: Yes.
>> AMBER: That said, also prioritize accessibility.
>> CHRIS: Yes. All this to say that, like, all the WordPress product companies out there that might listen to this, we are sympathetic to users asking for things. It happens. Just be cautious with what you implement.
>> STEVE: Yes.
>> CHRIS: So when we’ve identified accessibility problems in a plugin, and this happens frequently in the course of our audits and even when we’re evaluating things to use for our own purposes, what are some recommended avenues for fixing those problems?
>> STEVE: Yes. I think this dovetails a little bit into what we were just talking about, when we get feature requests, right? I think an area that people don’t always default to when they find that a plugin’s not accessible is, go back to that plugin developer, open a support ticket with them and ask them to fix it. Request a feature of them, right? And if they’re prioritizing things correctly, then they should update it, right?
I know when we get requests for a feature, especially like bugs, I try to get those turned around within 24 to 48 hours, a lot of times, just to show that our plugin is in active development. We’re listening to our clients or our customers or users, because there’s a free plugin. I want to them to feel like they’re not just downloading a plugin that’s just going to live on their website forever. I want them to feel like there’s real people behind this, and that we’re listening, and I think other big plugin companies are the same way.
Didn’t you have some input on some stuff with Gravity Forms, Amber?
>> AMBER: Yes. Carl, who’s the owner of Gravity Forms, he did connect me with one of their devs, and he’s, like, “If you come across accessibility problems, this is who you can email.” The Events Calendar right now has been really great.
We have a client that we’re doing remediation for, and they had, like, a homemade event calendar plugin that was just so bad, which we can probably circle back to, that it was like it wasn’t worth fixing, and so I was, like, “Well, let’s put you on The Events Calendar. I think it will do everything you need.” But we had to test it, and there were a few things that came up, and this is challenging because they purchased a license for it, but I didn’t have the login, so I couldn’t request support, so I just went to the free “WordPress.org” support forums and I posted some accessibility issues. But then what I did.., and I’ll tell you, I think that this really helps with getting traction, especially with those bigger companies.
I also tweeted about my support requests and I tagged them, and so then I got, on Twitter, their marketing team, and then a couple people messaged me on post status from their team. They were, like, “Wait, we actually really appreciate this.” And they added me to, like, a private Slack, so as we continue testing, we could flag things for them faster, and they’re, like, “Here’s the dev who’s assigned to work on the issues you raised.”
So I think, for sure, especially if it’s a really large plugin, raising it… Now I don’t always have as much of success with smaller plugins, like, that’s owned by a hosting company. They have a lot of money. They have an active team. There might be plugins that are like ours that only have one full-time developer, or there’s a lot of plugins out there where it’s a freelance developer who’s doing client work and sometimes maintaining their plugins, which we’ve been there, so those, I don’t feel like we get as much. I’ve raised things with them and flagged it as accessibility, and they’re sort of, like, “OK, we’ll take note,” or, “We’ll see if we can fix it,” and then you never hear anything, sometimes they don’t even reply.
>> STEVE: Yes, so the flip side of going to the plugin dev and advocating for them to fix it, or like Amber said, leveraging the community, if you don’t feel like your voice is being heard, tag Amber. I’m sure she’ll help you. I’m sure she’ll help you holler that around the internet.
>> CHRIS: Amber is loud.
>> STEVE: Yes. [laughs]
>> AMBER: I hope you mean that in a good way.
[laughter]
>> CHRIS: I do. Not like volume loud. I mean, loud in terms of reach in the WordPress space. It’s a compliment.
>> STEVE: That’s right, so I think the flip side of that’s the technical side, right? When you’ve got a plugin, you really want to use it on your project. The plugin developer can’t turn around a fix quick enough, so you got to take things into your own hands. That’s when things can get a little hacky, but sometimes it has to happen, right?
A plugin that we’ve used a lot in the past, and it’s progressively gotten better, is FacetWP, so this is dynamic content being loaded into the page, so that can present a lot of different accessibility issues, and then there’s lots of forms, right? Like every little Facet is a form, right? So we’ve had to write our own kind of sheet of JavaScript that goes in, and there’s a filter in Facet to show the labels, but I think it just puts them like in an h3 or something. It’s like it doesn’t always do it the right way, so we’ve had to go in and modify that quite a bit with some JavaScript on top. You know, we just hook into, like, Facet, load it, or something like that, then we rewrite JavaScript to add labels where we need them or to change some markup the way we need to add some Aria labels.
>> AMBER: Yes. I think that it’s an option, and obviously we’ve done that to fix a plugin that we want to use, or that is already on use on the site and it’s too hard to remove. I do think if you can, it is always better to get the plugin developer to do it, because then everyone gets the accessibility fix, not just the one website. But also, I think the downside is that when you fix it with JavaScript, there’s no guarantee that fix will be maintained.
So this happened with us. We adjusted our checkout page with easy digital downloads because it had some issues, and it worked for, you know, six months, seven months, eight months. This is in the very beginning, and then luckily we weren’t getting a lot of sales then. At one point in time, someone was, like, “Your checkout page doesn’t work.” And we were, like, “What?” And we have to go look, and while there is an update to easy digital downloads, that then conflicted with the JavaScript that one of our devs had written to fix an accessibility problem.
To some degree, you’re signing yourself up for technical debt or extra maintenance when you patch something with your own JavaScript.
>> STEVE: Yes, totally. I know a lot of us don’t do this, and I know a lot of us have automatic updates on plugins, but from an accessibility standpoint, like inside your organization, you should probably have some kind of process to updating your plugins that requires… Especially if you’ve had to do some JavaScript hacking like this, that you need to test the new version for accessibility again before updating your plugin. Now we could do a whole episode on that, but yes, I think you’re always kind of chasing. Yes, it’s technical that you’re kind of chasing the plugin. Every update, you’ve got to make sure that your fix still works, right?
I will say, another thing, since we’re talking about FacetWP, which, not to call out a plugin… I think that they’ve been improving it, and it’s a great plugin. We love it. We’ve used it a lot, right? But I don’t particularly like when plugins require you to install an add-on for accessibility.
>> AMBER: Oh, yes, so theirs, by default, accessibility is turned off, and then there’s like a filter. It’s not even an add-on. It’s like a developer has to do it, right? It’s a filter you have to add to a theme or something?
>> STEVE: Well, I think it used to be an add-on. Maybe I’m mistaken plugins, or maybe we had an add-on for Gravity Forms a long time ago, but…
>> AMBER: Oh, yes, we did for Gravity Forms. We used to use the WCAG 2.0 fields for Gravity Forms before they did their big revamp.
>> STEVE: Their big accessibility update, yes. I think in Facet, now there is a toggle inside of the settings, to toggle on accessibility features. Why would you allow them to make an inaccessible form, right?
>> AMBER: Well, and even, like, in that land, why is it off by default? PapaMaker has that too, but theirs is on by default. But then if you go to settings, there’s a way where you can uncheck the box for accessibility.
>> STEVE: Yes.
>> AMBER: I’m, like, “At least it’s on by default.” But I’m, like, “Why? I don’t understand.”
>> CHRIS: [crosstalk ] if it like a backwards compatibility thing. Do you think it’s backwards compatibility? Like, maybe enabling accessibility features causes some conflict on, like, legacy –
>> STEVE: Yes, totally.
>> CHRIS: – implementations?
>> AMBER: You think so?
>> STEVE: Yes. I think that’s probably an excellent point, Chris, and I’ll give you some development props for thinking that. But I think you’re probably right. You’re probably right. That’s probably what it is. It’s probably to maintain backwards compatibility, because you got to think, every attribute you add to an HTML element can be targeted with either JavaScript or CSS, right? So if you have an Aria label on there and it’s wrong, any user could have wrote their own JavaScript to target that attribute, and then if you remove it, their CSS is going to break.
>> AMBER: Yes. Probably the best Accordion plugin, I think it’s just called Accordion Blocks, maybe. It’s pretty close on accessibility. We’ve used it before, and we’ve also used it on a project and modified it. But he had headings that he ended up adding a role of button to, because he ended up realizing late that he needed to fix it, and he did that. It’s mostly right. It reads OK with the screen reader, it functions fine with the keyboard. But when you add a role of button to a heading, that heading no longer shows up in the headings list.
Now there is a workaround, which is you could put the same heading inside the Accordion, and then that heading would show up in the headings list. But somebody flagged this for him. I saw on his support forum on “WordPress.org,” and he basically was, like, “Yes, I’m not going to fix that.” Because the fix is that the heading tag has to go outside the button, or the button tag has to go outside the heading. One of the two, right? They can’t be a heading with a roll of button, and that would be a style breaker for every website.
I personally am, like, “Break all the styles, [laughs] choose accessibility first.” But I can see, as a plugin developer, that’s a decision that has to be made.
>> STEVE: Yes.
>> AMBER: And then as a user or a developer of websites for clients, that’s where you start debating, and it’s a little bit like, “It’s mostly correct.” And sometimes you’re, like, “It’s mostly correct. It’s OK.” Like, it doesn’t show in the heading list, but I know of a workaround, so I might still use that plugin versus the other Accordions that can’t even be opened, right?
>> STEVE: Yes, yes, and then in the third option… There’s probably a lot more than three options, but I mean, you can always fork it, right? You can always fork it, make it better, make it yours.
>> CHRIS: Yes. Well, that leads me to something I was going to say, because I think that happened on not a fork, but something like that. Akin to that happened maybe even on our plugin, where someone saw an issue and they just submitted a pull request or said, like, “Hey, can you add me?” And so if you’re a developer and you’re assessing plugins, and there’s one problem to fix, and you know how to fix it, you could just ask the developer, “Hey, I know how to fix this. Can I just ship you some code for you to review?”
>> AMBER: Yes. All plugin developers, if you’ve got a free plugin, you should have an open GitHub repo.
>> STEVE: Yes, totally.
>> AMBER: Because we’ve had multiple people submit to us. Now, it’s harder with a paid plugin. Those don’t always usually want to have open GitHub repos.
>> STEVE: Right. But people have reached out to us, and we’ve added them to the private repo for the pro plugin so that they can submit a PR to us. But yes, we’ve had several people outside of our organization commit pull requests to the Accessibility Checker free plugin, which we always appreciate, so you can take the initiative to fork it and submit a PR, and it might get rolled in. They might give you some credit and, you know, it benefits the community.
>> AMBER: So the other thing that we haven’t really talked about yet on auditing. We’ve talked about, you find problems, you might try to contact and ask them to fix it. You might fix it yourself or submit a PR. But the other option is, sometimes it’s so bad that you just abandon completely, and I’m curious, Steve, for you, where that line is, because I know sometimes I’ve asked you, like, “Can you fix this?” And you’ll be, like, “No.”
[laughter]
So how do you see that line?
>> STEVE: I think it’s a case-by-case basis. If it’s something I can get in there and fix with JavaScript fairly easily, I think…
>> AMBER: Is that like a number of lines of JavaScript? Like, what’s easy?
>> STEVE: I think it’s a number of hours, and what kind of deadline you’re under for your project. If we’re working on a web project or something, there’s always a deadline, so we’re always on a time crunch, so you’re always weighing, like, “Should I try to hack and fix this plugin to work? Or should I just rewrite it? Or should I find something else?”
So you’re always trying to balance all those things, what’s going to be the quickest, and a lot of times the quickest wins because of deadlines, and I’m not sure if that’s always the best answer. Right. The best answer would be, if the plugin’s being used by 50,000 people, try to get this guy to fix it, or try to submit a PR to it and get him to roll your fix in, right? Because that benefits everybody. But the reality is, in a service-based business, sometimes things just have to get done, and maybe that’s four lines of JavaScript fixes it, right?
Although if it’s a plugin that’s doing a bunch of dynamic content loading in, and I can’t find the Ajax hook that’s doing it, and I can’t listen for that, the right one, or I do and I just can’t get things to happen in the right order, right? It loads, or my script executes before it’s done loading, like, if there’s times where I can’t get those things to line up, then it’s probably time to move on.
>> AMBER: Yes.
>> STEVE: I think something, too, that we’ve been doing a little bit more in our organization is, we don’t have like a definitely defined list of approved plugins that we can use on projects, but we definitely have a very minimal set of plugins that we use on every project. We have like a base theme, you know, a base install with these plugins and stuff, so we’ve become very picky about the plugins that we use on websites. A lot of it has to do with Gutenberg too, and, you know, trying to Maintain compatibility with Gutenberg just being very choosy.
Like Amber said, there’s an Accordion Block. You go grab the Accordion Block, you throw it in there. “Well, I need a block that does this.” You go find that one, you throw it in there, right? And six months later, they’ve updated, and your website doesn’t even look the same, right? So we’ve been very picky, where it’s, like, “We’ll use this one block library, but we’re only going to use these two blocks out of that library.
>> AMBER: And honestly, we’ve been discussing like… Not even like. I think I’m building a website right now that it’s all Core and custom blocks and that’s it. We’re not putting any other blocks on it.
>> STEVE: Yes, and then the rest of the blocks are custom coded. That way, we can control that block. We can maintain it. We can control the accessibility of it, because when you start to talk about plugin blocks and accessibility, fixing those to be accessible, it’s a much higher bar than old school, just straight PHP, JavaScript plugins, so you get in the realm of React, and you probably don’t even have the build scripts for some of those blocks if they don’t provide a public GitHub repo.
>> AMBER: Yes. I think some of it is probably like a skill decision too, because you probably have a higher threshold for, “Oh, I’ll just fix it” than I do.
>> STEVE: Yes.
>> AMBER: And probably I have a higher threshold than maybe even Chris does. Like Chris might be, like, “It doesn’t work. Delete plugin.” [laughs]
>> CHRIS: My threshold is maybe a-quarter-inch above the floor. [crosstalk ] My next step is, “Amber, Steve, help.” That’s my next step.
[laughter]
>> AMBER: I think if you’re an agency or a freelancer and you’re building websites for people, and the plugins have accessibility problems, and you find them, but you’re not doing a lot of custom coding, you’re more implementing with existing tools, it’s probably easier to just change your tool set, and just be like, “Hey, we’re not using this third-party add-on anymore,” or, “We need to change.” And I think, too, sometimes it also falls a little bit under how central the component is, so it’s really easy to swap out your social-media link plugin.
>> CHRIS: Yes.
>> AMBER: Like, it’s such a minimal impact on the site, right? But maybe it’s more challenging to swap out your event calendar, like, that’s going to be more work, and so then you might say, “OK, well, how much is wrong with The Event Calendar?” First, like, “How much I might have to restyle a new one, or spend time re-entering new events if there’s no way to import them in.” A lot of plugins you can import or content in now, but still, I think you might weigh that a little bit, but against your skills, for sure.
I think, probably, it gets frustrating for agencies or freelancers when they’ve been using this plugin set for a long time or a theme stack, and they know it, and then it comes up that, like, everything you use.
I talked to someone at WordCamp US, and she’s building everything with Divi, and I was just, like, “I’m sorry, you’re not.” And she’s not a custom coder, and she’s got all these client websites, but she’s interested in accessibility, and I was, like, “This is a hard point, but you’re pretty much…”
>> CHRIS: You have to switch tools.
>> STEVE: Yes.
>> AMBER: “If you decide that you’re serious about accessibility, you’re going to have to be willing to learn in a new stack.” And I think that’s probably frustrating for people, and that might be why some people don’t like accessibility.
In an ideal world, the plugin devs fix their stuff. If you’re building websites for clients and you don’t see that train happening with your stack, I would start looking into a new stack as soon as possible.
>> STEVE: Yes, and we could do a whole episode on page builders, which I think we may have.
>> AMBER: Well, we talked about Elementor. Maybe we should not just pick on Elementor. We should go play around with other page builders and record separate episodes for each of them.
>> STEVE: Yes, yes. They all have their weaknesses and their strengths when it comes to accessibility, some are better than others. I got that too. At WordCamp US, somebody came up to me, they asked me a question: “Which page builder would you use for accessibility?” And I gave them my answer, right?
>> AMBER: Which was what, “No page builders?”
STEVE: Yes, yes. Well, I mean, he asked “page builders.” So I had to answer with a page (builder), right? My answer, I’ll say it here, was Elementor, just because of the community around it, and I think the support you can get for it, and probably for longevity. I kind of feel like Elementor is at the top of the game when it comes to page builders, and he got this sad look on his face, and he’s, like, “Oh, I build everything in Beaver Builder.” [laughs] I was like, “Well, I mean, it’s not that you can’t make it accessible with Beaver Builder.” I was, like, “Where you need to be careful with Beaver Builder is some of the add-ons.” Like, you need to vet your add-ons.
>> AMBER: But it’s the same way with Elementor too.
>> STEVE: Yes, yes, exactly. It’s not that you can’t make it accessible with those things. It’s just that you have to be very careful, like, are you using Beaver Builder Core? Or are you using like 50 other plugins that go with Beaver Builder, right? It’s like you have to vet each one of those.
>> AMBER: Yes.
>> CHRIS: I have heard from multiple independent sources during and after WordCamp US that Elementor has been stepping up their game on the accessibility front, and has evidently been patching a lot of accessibility problems that have been lingering around for months or years. Anne Bovelett was one that was shouting them out in a positive light, and I tend to trust her judgment on things like this, because she’s ruthless if someone’s not, you know, stepping up.
>> AMBER: I’ll say one of the hard things that I have about people asking us that question.., and I get it a lot because I run Meetup and that kind of stuff, so Elementor we have used in the past at our agency. I built my personal website in Elementor, so I know it. I’ve only ever used Beaver Builder one time, and then I think we also audited one website with Beaver Builder, where we didn’t build it, but it was built by someone else, and we audited, or maybe two, actually, and there’s a whole bunch of other builders like Oxygen and Bricks and all this stuff that I’ve never even looked at, like, one time, and so that kind of question is a little bit hard for me, because unless I was an influencer or a content creator, like some of these YouTube people that spend their time trying products and testing them out, and I sometimes do test stuff when I’m writing my articles for the Admin Bar, but I’m not really in those, and so I might probably choose Elementor too, because this is the only one I’ve actually ever used, right? But I think that’s what’s a little bit hard about that question.
>> STEVE: Yes. It’s not like a daily driver for us, right? We stick with Gutenberg and custom.
>> AMBER: Yes, and we’re not, you know, staying on top of every new plugin outside it, because that can be a full-time job in and of itself.
>> CHRIS: Yes. That would be a full-time job for 50 people with the size of the WordPress ecosystem, like keeping tabs on all that.
>> AMBER: Yes. Well, I think we’re about at our hour mark, so I don’t know if anyone has any closing thoughts about choosing plugins or accessibility in plugins?
>> CHRIS: If you have the knowledge and the skills, help make plugins you like more accessible.
>> STEVE: There you go.
>> AMBER: Yes. For me, I think the only way we’re really going to have an accessible WordPress is if all of the plugins are accessible, so that users who know nothing about web development and nothing about accessibility will just have an accessible website by default, so that would be my hope for it.
If you’re a plugin dev listening to this, you have the ability to change the world.
>> STEVE: There you go. Speak out. Submit a pull request. Put a bug in there, yes. We all got to do our part to push this forward.
>> CHRIS: All right, everybody. Well, thank you both for being the answerers of the questions today, and we will see you all next time on “Accessibility Craft.”
>> AMBER: Bye.
>> CHRIS: Bye.
>> STEVE: See you.
>> SPEAKER 1: Thanks for listening to “Accessibility Craft.” If you enjoyed this episode, please subscribe in your podcast app to get notified when future episodes release. You can find “Accessibility Craft” on Apple Podcasts, Google Podcasts, Spotify, and more, and if building accessibility awareness is important to you, please consider rating “Accessibility Craft” five stars on Apple Podcasts.
“Accessibility Craft” is produced by Equalize Digital and hosted by Amber Hinds, Chris Hinds, and Steve Jones. Steve Jones composed our theme music. Learn how we help make thousands of WordPress websites more accessible at “EqualizeDigital.com.”