In this episode, Amber and Steve, along with special guest (and Equalize Digital Senior Plugin Developer) William Patton, take a deep dive into how our team approached building an accessible WordPress plugin for multi-sites.
Listen
Watch
Mentioned in this Episode
Transcript
Chris: 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: Hey everybody, it’s Amber, and I’m here today with Steve.
Steve: Hello everyone.
Amber: And we invited our developer, William Patton, here today. Hey, William.
William: Hey.
Amber: Do you want to introduce yourself for our audience?
William: Yeah, sure. So, my name is William. I’m based in Scotland. Apologies if the accent throws you off a bit. It’s not the most understandable. I’m a WordPress developer. Spent a long time, mostly making and breaking things, break them, learn how they work. A lot of breaking goes on. Yeah, that’s me.
Amber: And you are lead plugin dev doing a lot of the coding for our Accessibility Checker plugin.
William: Exactly.
Steve: Yeah, yeah. Well, we love your accent, William, and we’re glad to have you on the podcast. So since this is your first time on and you are Scottish, we asked you to pick a Scottish beverage. So, normally Chris handles this. So we’d like to hand that honor on to you and have you introduced today’s beverage.
William: Yep.
Amber: So wait, before you do that, I forgot I’m supposed to do something. Which is I’m supposed to tell everyone that this is episode 108 of Accessibility Craft. And if you want show notes or full transcript, you can go to AccessibilityCraft.com/108.
Today’s Beverage
Amber: William, I will let you take it away.
William: So I picked this is a drink called Irn Bru. It is very popular here in Scotland. It is one of the only drinks here that sells more than Coca Cola, which according to statistics is a pretty big thing. The flavor is undetermined. I will let you tell me what it is supposed to be.
Amber: So, we should describe this. It’s a soda, right?
William: Yes, exactly.
Amber: Caffeinated soda.
William: Mildly caffeinated.
Amber: I don’t know what this means. It says on mine that it has 200 kilojoules of energy. What does that mean?
William: We don’t like putting calorie counts on things. We use kilocalories instead, kilojoules.
Amber: Oh, okay. And it is bright orange for anyone who is listening and not watching this in video form.
William: The color of rust. Yes, it is not orange flavored,
Amber: But it looks like it should be like it looks like it should be an orange pop. But it’s not.
William: Yeah, we just like to confuse the world.
Amber: All right, so this beverage history wise it goes back to 1901 I think. And it has a whole Wikipedia page if you want to look it up. A lot of our beverages don’t have Wikipedia pages with all like the hundred year history of this beverage. And I did note on there that in 2020, no, yeah, 2010 they were told they had to remove their food coloring and they still haven’t done it. And I noted on my ingredient label that it says, may have an adverse effect on activity and attention in children.
William: But we don’t use the names of food colorants, so we use what we call e numbers, as additives so it probably has, you know, red 5, yellow 2, whatever those names are, but we will list them as e numbers as opposed to the actual name, so you don’t know which is which.
Steve: So I will say…
Amber: This will make me hyperactive is what you’re telling me.
William: It might.
Steve: More than usual and…
Amber: Am I hyperactive?
Steve: Yeah, kinda. I Would say that this is probably our first drink we’ve ever done in a plastic bottle.
Amber: Oh, is it really?
Alright, well we’re gonna give this a open here. And you have one too, right William?
William: Yes. I’m gonna wait to see what yous think before I open mine. I know what this tastes like.
Steve: So it stays on. See, Amber?
Amber: Oh yeah! Yeah, so the lid has two little arms that attach it over to the plastic band that’s normally around there. That is interesting. Alright. Well, okay. It doesn’t smell like orange, but it kind of has a fruity smell.
Steve: It smells like the, like the orange Hi-C at McDonald’s.
Amber: I have, I can’t even remember the last time I drank orange Hi-C, so I don’t know.
Steve: !I can’t either, but I, I’ve had it. Okay? Okay.
Amber: But it’s not gonna taste like orange?
So, I’m a little bit afraid, I said this in our campfire, I’ll repeat it here for the podcast. We said it had iron. I was like, is it going to taste like blood? Like I think about iron supplements I had to take when I was pregnant because I’m a vegetarian. And they’re like, your iron is low. They just taste like blood to me.
Steve: Yeah.
Amber: Is that what this is going to taste like?
William: It does have some iron content in it, but I don’t think it’s a lot.
Steve Literally Licks a Hammer
Steve: So, William, you described it as it’s like licking a hammer.
William: Yes.
Steve: So, so for that I’m…
William: You brought a hammer?
Amber: Oh my god, yes!
Steve: I’ve gone into the garage and found it.
Amber: Did you wash it?
Steve: No. It’s gotta be like rusty, right?
William: Don’t hurt the flavor. Yeah.
Steve: Yeah. That washes, washing the hammer washes away all the flavor, so we’re gonna do a comparison here.
Amber: Alright, wait. I, okay, so I tasted it. You know what it kind of has an under taste to me of? It kind of tastes like bubblegum. Not that I’ve had bubblegum in a really long time either.
William: This is a common thing, yeah.
Steve: It’s a lot stronger than I thought it would be. Like, the flavor. I definitely was expecting more of an Orange Crush kind of flavor than what I’m getting.
Amber: Yeah, I think it tastes like bubblegum.
William: I think it’s kind of mixed fruits.
Amber: Steve, I really want to see you lick the hammer now.
Steve: !Alright, here we go, here we go.
William: Mixed fruits and a hint of gerders, as the marketing says.
Steve: So, the edge of the hammer has been hammered, so it’s kind of clean, so I should probably lick the side. . It doesn’t have the same tingle, but the hammer might taste better.
Let me wash that down with some.
Amber: The things we do for marketing.
William: Good for your immune system. Seems like Steve needs a bit of an immune system boost these days.
Steve: Between the Irn Bru and whatever I got from this hammer I hope I’m up on my tetanus shots.
William: People drink the Irn Bru before they go out on a Friday night, and they drink it on the Sunday when they get home after drinking too much all weekend.
Amber: This is a hangover cure, is what you’re saying?
William: It’s what people use it like.
Steve: I mean, it’s pretty watery. It’s pretty watery. It’s not like thick or anything like…
Amber: How does this compare? I don’t remember like we’ve had and we had an energy drink. Is this like an energy drink? Does it have that much?
William: It’s probably less caffeine than about an average coffee I would think.
Steve: It’s okay, it’s pretty sweet, you know, I like more of the you know, the diet stuff but…
Amber: So when I… You give it a middle?
Steve: I give it a thumbs in the middle.
Amber: Yeah, I give it a thumbs down because I’m a snob about food colouring and all that stuff. And also the bubblegum flavour is a little, it’s weird that I think, I really think it tastes like bubblegum.
William: That is a common thing people say.
Amber: Okay, so it’s not just me.
William: It is, yeah. It’s, the recipe apparently has 30 different flavour notes in it. It’s also a secret recipe. Only three people know it. They can’t fly on the same plane. Same as the Coca Cola recipe.
Steve: Really?
Amber: Are you a big thumbs up on this drink, William? Do you always have it in your house?
William: I do always have it at home. I think everyone in Scotland always has Irn Bru nearby. But it’s middle of the road for me, actually. We have lots of other options. I’m mostly a Coca Cola guy.
Amber: Yeah. Well, you are in good company if you are a Coke fan on this podcast.
Steve: That’s right.
Amber: So I will say, when I was looking for pictures of this to use on our cover image, I came across, there’s a whole bunch of recipes out there.
Where you can make stuff like food with Irn Bru. I found a like chicken wing glaze, pork slow cooker, but my absolute favorite. Did you guys click the link and look at the Irn Bru trifle?
William: I have had the Irn Bru trifle before.
Amber: Was it like this where it was like flambéed?
William: Oh, I didn’t click the link. Let me see.
Amber: Oh, man, you have to look at the image at the top. So yeah this is like, I mean, this recipe is probably horrible. You’re gonna die from eating too much of this, but it says you take trifle sponges, which I think are like ladyfingers, like you’d put in tiramisu, Irn Bru, so you like soak them, a custard, orange jello, blood oranges, and then you use egg whites and you whip them up like you would make a meringue. And you know, pile it on the top kind of like a baked Alaska, then you pour whiskey on it and set the whiskey on fire.
Steve: Dude, that sounds good. We should do that.
William: That is a fancy trifle. I’ve never had one like that.
Amber: It’s a very fancy trifle made with the orange brew soaked lady fingers.
William: When I’ve had this as a child, we used to put Irn Bru in the jello and it would just be cool whip on the top of it, you know, no meringue. You don’t cook this for me. You would just mix it, put it in the fridge.
Amber: So, I have to say, Jell O is already loaded with sugar. Iron Brut has a lot of sugar. Was your Jell O really sweet?
Steve: Yeah.
William: We did just eat it like candy when I was a kid.
Just get the cubes, eat them.
Steve: I don’t know, did you guys do this? We would put fruit in it. Cut up fruit.
William: I’m not a big fruit guy.
Steve: Inside the Jell O, like a fruit cocktail.
Amber: Yeah, my mom would always do that Jell O salad with fruit. I don’t like Jell O.
Steve: Yeah.
Amber: Anymore. Also, Jell O’s not vegetarian, so.
Steve: Oh, yeah, because it’s made of bones, right? Yeah.
Amber: And hooves and stuff. Just telling you, it’s gross if you really think about what Jell O is.
Why Did We Build a Multi-Site Add-On Plugin?
Amber: Well, we invited William here today because we recently released a new add on for Accessibility Checker. And I thought it would be good for us to have a dev friendly conversation about the process of building and testing that specific add on.
So today’s topic is coding an accessible WordPress plugin for multisites. And we’re going to be talking about our Accessibility Checker multisite add on, which is included for people at the agency and enterprise levels for free. It’s not something extra that you have to purchase. And, and really what went into why we built it, what challenges we might’ve encountered, what were some of the accessibility considerations with building the plugin.
So I’m hoping we can have a conversation that’s good for a lot of different plugin developers out there who are thinking about building things. So, Steve, do you want to kick us off and just sort of give people some background information on what that plugin is, what it does, why we built it?
Steve: So, I think we built it out of kind of requests from some of our, you know, more enterprise clients such as universities, that will run large multisites with hundreds of websites and they have a need for being able to quickly activate the accessibility checker on a large number of websites or collect the stats and things like that.
So what the plugin is it’s a network level plugin. You network activate it, and then in your multisite network, you get a settings tab and called accessibility checker where you can do three, three things. So you can check your we call it test summary, which is really like on a single site, you have site stats, right? That we collect about, you know, the state of the accessibility on your website. And what this does is it collects all those into a table for all active, all sites that have accessibility checker active, and it displays those all in one place. And you can, you know, you can quickly click over, use action links to click over to the single site and you can just manage this all in one place.
You can also network manage the license. So you can set the license key. You can then activate the license on any site, any number of site based on how many activations you have. Sure, there’s a limit there. If you have a 50 site license or a hundred site license, right. But you can assign or remove the license key and you can activate and deactivate the plugins, and this includes Accessibility Checker Free, Pro, Audit History, Export, so our add ons, so you can all, you can manage those all there, network wide. And then lastly, the plugin has settings management. So you can define a default site where the settings of that site, you could then copy to any number of sites on your network.
So, so say you set site four, whatever that’s named, right? And then you then have a table of all your sites and you can choose. I want to choose all these sites and then you can copy those settings directly from the network tab to all of those, or on install, it’ll copy those settings as well.
And that’s kind of in a nutshell, that’s kinda what the plugin does. It’s just a network level management of Accessibility Checker across all of your sites in a multi-site install.
Amber: Yeah. Which, if you can imagine having 500 or 1, 000 websites and wanting to roll out a plugin to them all, this really is a helpful feature.
You don’t have to go individually do all that setup work. I’m going to talk about what it, what went into building it. But first let’s take a quick commercial break.
Brought to you by Accessibility Checker
Steve: 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.
Thousands 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’re a content creator or a developer, our detailed documentation guides 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 percent on any plan.
Does Building For Multi-Site Add Complexity?
Amber: So, this is the first time that we have ever built a plugin that was specifically for multisite. We’ve released lots of plugins, but they always just work on the sub site level. I’m sort of curious because I don’t, I literally have no idea what you’re going to say. You might tell me that there’s nothing different about that, but I’m curious when you’re building a multisite plugin, William, is that, is there anything more special that needs to be taken into account to make it work at the network level?
William: There’s nothing in particular for it to be detected. However, there is a breakdown between your primary website, which operates as if it is a single site on its own, and the actual network dashboard, and the line between them gets a little bit blurry. So, plugins activated on individual sites only operate on those individual sites, but plugins activated at the network level become loosely available everywhere, and thus can interfere in ways that are somewhat unpredictable.
Amber: What does that mean?
William: So, at the network level, as a developer, we quite often rely on things like globally available constants as part of the PHP runtime, and at the network level, will those constants be available in the same way they will be on individual sites is uncertain due to the order of operations.
So when you’re on the network admin, you haven’t fully loaded the primary site, and thus all of its plugins aren’t fully bootstrapped at the point where you might want to activate them. So you have some interesting, almost hacks, that are required to handle the hook order when you perform your operations.
So, it acts as if it’s almost a fill site, but it isn’t.
Amber: Wasn’t, wasn’t there something too where initially we were trying to figure out if a license could be activated not on the main site but everywhere else and you ended up determining that site number one pretty much always has to be active? Was there something there?
William: Yes. Although that was not necessarily a quirk of multisite, that was an interact, one of the weird interactions between our license system and multisite forced us to have the license activated on the primary site. Otherwise at the network level, the plugin couldn’t update itself.
Steve: Yeah, I think that was probably one of the most challenging parts of it from a technical standpoint. It did kind of make us take a step back a little bit and have to add things to the core plugin which we sometimes call Free. But the core plugin, free core plugin, the one that you can get on the WordPress repository.
But we did have to go back and kind of add some things to that for considerations for multisite and actually like, to some degree, we kind of had to really test our plugin’s abilities in a multisite and so where we have before you go through and you do some user testing and you’re like, yeah, it activates, it deactivates.
And now this is a much more, you know, much more entangled into the multisite. And we had to. We had to update some of our APIs, or maybe, I think William, you created some new API routes to be able to pass stats and stuff into the multisite. So, so it actually was kind of an improvement, you know, in that core plugin as well.
And just making sure that it all works very seamlessly and smooth with multisite.
Amber: Yeah, I think I remember there was something about adjusting how some of the tables functioned. As well like on activation and deactivation in a multisite network. Depending on if it was network activated or only activated on single sites.
So, I feel like when you initially build a plugin, most plugin devs don’t really think about multisite as much. And I know we tested it a little bit because we knew it would be used on multisites. And our website is a multisite, but our website gets weird because we can’t actually activate it on the site where we serve the updates because it has this weird, which I think is normal. That’s just like an EDD thing. Like you can’t run your plugin on the site that is serving the updates.
Steve: The API, yeah.
William: I’m not sure if it’s true that most developers forget to account for what you say, I think what’s more realistic is that we choose to ignore it, in a lot of cases. It is full of quirks and uncertainty, and if you choose to ignore it, then you don’t have to deal with them. And that’s not to say that plugins generally work on individual sites in a network just fine, without any affordance. I think the affordance is what happens at network level as some we choose to ignore.
Steve: Yeah, and I think that, I mean, there was enough consideration for multi-site built into the plugin from its onset to account for multi-site. Because you, like we have a custom database table. We have a couple of custom database tables and we do store the site ID where the issue is generated.
So that the plugin can run on multisite without, you know, conflicting issues. So, we were set up to some degree for it anyway, which was good. But, but no, I mean, I definitely think this was a good practice in making sure it fully works and making sure the experience is smooth and seamless for the user. And I think a lot of plug in devs do ignore multisite because I think that the usage of multisite is, I don’t know, I don’t know what the actual usage of it is, but, I would assume it’s fairly low, but if you segment out the audience that we’re trying to reach you know, universities, government, right? These are entities that are required to meet some level of compliance and accessibility compliance.
Amber: It probably really does depend upon audience and it, that is so interesting, you know, and why I think as a plugin developer, you have to really understand who you’re targeting with your products, because it became pretty important for us to have a multisite add on, but I could see a lot of plugins, if they’re targeting just like small businesses, the likelihood of a small business having a multisite, it’s probably very low.
Steve: Yeah. And I think we had that conversation right. Our team, we definitely had the the healthy debate back and forth, you know, on the product on, you know, this is going to take X number of weeks to do is that worth it?
You know, where we could move on to something else. You know, when you’re a small team, if you’re going to dedicate six weeks sprint to this one feature and we can, and it really doesn’t net us anything, right, it’s kind of like. It could be a waste, but we determined that we were willing to take that risk and that, you know, we had enough of a demand for it, that it could help serve those customers better.
How We Approach Building Admin Interfaces
Amber: Yeah. So Steve, you had mentioned user experience, and I think it’s worth discussing a little bit about how we have been refining our approach to styling in admin screens. So initially, our, when we first launched, we were just using only core WordPress admin styles and not really adding our own styles.
And then we’ve sort of been doing more. And I felt like the network admin does look a lot more polished than maybe some of our other admin screens, even today. Because it is, you know, the most fresh thing that we’ve launched, but I think there’s this fine line, right? Where I’ve seen plugins that are so custom, it’s really hard to understand how to use them because they just look so different from WordPress.
You don’t even feel like you’re in WordPress on their admin screen. Or, you know, if you stick to core WordPress only, it can look really dated. And I’m wondering if you want to talk a little bit about how we approach like the style and the design direction on the plugin or any considerations.
Steve: So, I mean, I wouldn’t say that I have this all figured out and that it’s this huge, awesome design pattern that I’ve come up with.
But you’re right. The, you know, the kind of the options, the options fields that come out of WordPress when you do it the WordPress way, a lot of times are, it’s pretty bland. It’s pretty you know, it’s like a gray background with an input field and a button, right? With not much consideration.
There’s some layout involved. It’ll move like your label to the left of the input field. And so it’s not terrible, but you’re right. It does initially out of the box look very dated. So I think on this plugin, what I did was I went through and it kind of went through a couple iterations.
You know, William did a first pass and William’s looking at it technically. He’s trying to get the stuff on the page. And I really didn’t have to do a lot of refactoring kind of the structure of what was being output, but it was more thinking, just thinking about it with a design eye.
Instead of using the typical text heading, let’s replace that with our own branding, right? Let’s, what is a consistent design pattern, going on here. And then kind of establishing that a little bit. WordPress will do that a little bit out of the gate, but you can modify a lot of that.
It doesn’t have to be an H1 at the very top, right? You actually have to put that stuff in there. But so, the branding and then it goes down to the main heading, like having let’s put a little bit of style in that. Let’s throw an icon to the left of that heading to give it a little bit of uniqueness. And then you know your next heading level which is going to be in what I call a set a section. And then the sections so you can have multiple sections with within a framed. So I put a white background on like the main part of the page, right?
So it’s not that WordPress gray background and just thinking about, you know, adding some borders to that and then thinking in sections and then really the table, I didn’t modify. The table outputs are pretty much WordPress core outputs.
Amber: Which is probably good because people know how to use those, right?
Steve: It’s familiar. You want to strike a balance between making it look nice and being familiar. And you’re right. Some plugins will install and it’s this one page react app or view app in the settings and it takes it over and it’s this whole new UI you have to learn just to update the settings of a plugin.
So, I mean, I’m not saying that’s bad or there’s not a place for that, but I want to make it look nice, appealing, easy to read. A page easy to scan, because we are an accessibility company after all, right? If I establish, you know, Heading 1 looks like this, Heading 2 looks like this, and 3 looks like that, I’m going to make it consistent throughout these three pages, right?
So it’s kind of just defining a pattern and sticking to it. And and it wasn’t too difficult. I think I did that in, you know, like a day or so. And but it gives it a little bit of a polish above what WordPress does out of the box. Now there are some considerations about some of the, you know, the options, outputs for accessibility and stuff that, that you have, you can modify it or you can choose not to use that altogether, which a lot of plugins are doing these days.
But so it’s a little bit of my thought process around styling those pages.
So I don’t know if you have any extra thoughts to add, William, there on design or anything that came up while we were working on it.
William: Not so much extra, but I am, you know, as a backend developer primarily, I’m mostly, I kind of like how WordPress looks and I, you know, it is bland and I like bland. And I did try at first when I started building this plugin, I did consider building my own table.
Everything fully custom and I reverted back to using WordPress list table so that it is familiar for users and that felt better to me. I did also include standard ish looking WordPress options which is actually what Steve ended up having to come back in and make pretty. Because I didn’t necessarily care about how pretty it was as I was building it.
For me that wasn’t important. For Steve, that was slightly more important than for me.
Amber: Yeah, I mean, that’s a good division though, right? Somebody who really cares about back end, somebody who cares about front end, right? You get good opinions, I think, when you’re doing that. If it’s just one dev working on something, then sometimes you don’t get a full picture of how something should be.
The Importance of Accessibility Being a Frequent Touch-Point
Amber: So, of course, this wouldn’t be an Accessibility Craft episode without a conversation on accessibility. I want to talk about our approach to accessibility testing as we build. I think maybe we could go in the order of William, Steve, me. Because that’s kind of the order in which we see and test code or our plugins.
So William, do you want to talk about your approach to accessibility testing?
William: Yes. So, right off the bat, I use Linux as my operating system, which does not actually have very many good options for screen readers. So, my first point of reference for accessibility testing is actually some of those JavaScript applets that ensure you have you know, the correct headline order, and you also highlight your ARIA labels and a lot of my first pass is manually verifying that they’re in the right place and that the right items exist.
And beyond that, I do have access to a screen reader called Orca, which I run, which is very lackluster in comparison to JAWS or NVDA. And once I have built things, as I think is correct, I will generally pass that off to Steve and he will run Safari voiceover in his browser and give me some feedback on that.
And then as a final step for larger projects, I will actually go get my laptop and run things through NVDA as a screen reader. And throughout the entire, you know, development process, I am a keyboard navigator. Not as a requirement, but as a choice. So I almost always I’m dealing with tab issues instantly as they occur.
So, you know, that benefits me as a fully sighted and fully keyboard and mouse capable user. I prefer using keyboard, so yeah, that is for me the initial process. And I do have to lean on Steve or others for some additional checking because of the limitations of screen reader access on Linux.
Steve: So, so yeah, it’ll come to me and this kind of doesn’t all happen in one fell swoop, right? We, a lot of times we segment out in a kanban cards for certain tasks, right? And they’re moving along and we’ll go back and forth on things. Yeah. I’ll typically just, you know, start using my keyboard and turning on voice over and listening to things and seeing, and this in particular, right.
We’re using, you know, tables. And in those tables, there’s checkboxes and icons, so we need to make sure that, you know, they’re labeled, or there’s a label, ARIA labeled by that correctly labels that checkbox, so it’s not just an empty checkbox. And we had some icons, I think in an initial pass, we had, you know, icons for like active, inactive state, or unlicensed, or licensed and, and then I think Amber just saw it like in a demo or whatever. And, you know, her accessibility spidey sense goes off, right?
Amber: You know, I think this is this is an interesting point because there’s this whole idea sometimes, right, of the quote, right way to do software development, which is maybe you list out all the features that are needed and then you design the whole thing and then you hand it off to a developer. But the reality, a lot of times in development is that especially at a small company is we don’t have designs for everything.
We maybe don’t even have a fully fleshed out, this is exactly what needs to be built. We have a general like problem that has to be solved that gets handed over to a developer. And, and so then in our team meetings, sometimes you guys will just share progress and you get like a mini check. So what you were saying, Steve, was I think William was doing like show and tell or something at a team meeting and I’m like, hey, wait, are those only icons and no words? Some people might find icons confusing.
Steve: Right.
Amber: We should have an icon with text next to it. And but I think that’s probably the reality for a lot of WordPress plugin developers is that you’re kind of like iterating as you go. And so I think from a testing standpoint, having like tiny check ins is probably better than just like way at the end.
Steve: Yeah. And I think what I’m doing, like it’s that whole shift left thing, right? Like we’re trying to get this accessibility stuff as, as well done as we can before it gets to, to Amber or to, you know, to, to our accessibility specialist, right?
So that in development, we’re thinking about it right out of the gate, right? William’s doing it and then I’m doing some user testing and I’m checking it as well, right? And then it gets to Amber or our user tester and it’s just, my hope from the development team is that it makes it out of develop and it needs very little accessibility work done. Or it’s, and we’ll get to this a little bit later, but, or it’s a complicated accessibility problem.
I think, William, I think there was a little bit of as far as accessibility, I think with our errors and our alerts, I think that you kind of went a little bit over me, above and beyond what, like, how most WordPress sites would want to speak about that?
William: There was a reason for that. So some of the data that we are operating on is particularly complicated to announce changes for.
So let’s say, for example you can see 17 or let’s just run number say 10 sites and you choose to operate on five of those sites. We can announce that five sites have had the plugin update. But what if you have a hundred sites and you’re activating default settings on all of them? And some of those sites have the settings applied and some of them don’t based on logic we have in the plugin.
We need to announce that and we need to say which sites, we need to help people get to those sites. It just is, it is almost impossible to announce table updates that have happened programmatically in a neat and tidy way for a user. And generally the way most plugins and the way WordPress Core handles this is the page reloads.
It doesn’t announce updates. And on page reloads, if you’re lucky, you will get a notification that says settings have been saved or something. But some plugins don’t even announce that. But that isn’t actually really a useful message. You know, tells people go have a look at the table, whereas what I have tried to do is I know how many sites taking again the settings page update.
I know how many sites have updated their settings. I can at least tell people 16 sites have updated and here is the list of IDs and they can themselves use their hotkeys to reach those IDs because those IDs are navigable by screen readers. They don’t necessarily need to tab through an entire table of 50 items to see those.
They will know those IDs. And on top of just showing that message, also make sure that it gets triggered as an ARIA live region on page load. So it doesn’t just appear and you have to tab into it. It will be announced, pages reloaded, here’s the message.
Amber: Yeah, I feel like that’s the kind of thing where we’ve tried to go above and beyond what WordPress Core does.
Even really thinking about that. Because of course, logically, we’d all be like, no user wants to have to sort through a massive table and figure out what changed. But a lot of times that is the reality. And so I appreciate that you put a lot of work into that. And I know it did take a bunch.
Another thing with the notifications was normal default WordPress notifications is they’re always up at the top and we had some issues. So one of the things I do when I do testing is I’ll do a lot of zoomed in testing. And so I would zoom to 200, 400%. And I would do all the operations to make sure that it could still function.
In that scenario and then I initially I discovered what that either the success or the error message, isn’t visible because it was just in the normal WordPress spot. And so you had to come up with a way to move those, right, William, into the viewport?
William: Yes. So I don’t always move them to the correct place.
Sometimes what I’m trying to do is detect whether it is visible in the viewport, and if it is not visible in the viewport, then focus, we’ll have to shift to make sure that someone who has a magnifier or just, you know, not even someone with a magnifier, literally me, who has fully vision. If that alert isn’t in page, I have no idea that it appears, right?
It’s not just an accessibility issue for people with extra needs. It just is a general user issue. And I think that is a general user issue that not everyone even has attempted to solve. And it turns out it’s not very difficult to shift the focus when it is required. Someone has taken an action, it is acceptable to refocus them on the outcome of the action.
And it was not difficult to do in terms of technical code changes. Yeah, I kind of, I’m not sure why it isn’t just the norm.
Amber: Yeah, we also had a whole like a mini conversation around this with the use of snack bars because some parts of WordPress Core are using Snackbar notifications now. But there’s actually multiple issues related to them on Gutenberg GitHub, and accessibility, and I think we read through all the comments from the accessibility team and users who’ve commented on those issues, and we ended up deciding as a result not to utilize Snackbars. Because It just didn’t seem like they could be used in a good way that was actually accessible.
William: Yeah, so the issue in particular is actually really, you’ll need to tell me the numbers of this one, Amber. I do not know those numbers off the top of my head from the guidelines. But this is about being able to control the timing. If something is going to disappear, you have to be able to dismiss it by choice.
And if something is going to dismiss on a timer, you need to be able to control that timer. And unfortunately with snack bars, there is no control. Snipers will just disappear after 30 seconds or whatever they’ve chosen their default to be. There will be no persistence and also no notifications.
Amber: Oh, sorry. I was just going to say the way WordPress Core can handle that, but like it doesn’t make sense for a plugin developer to do this. It needs to be consistent. I think the way WordPress Core could maybe handle that is on your user settings, you could have a setting where you can say, keep you know, notice visibility timing and the default might be 30 seconds. But you could have the option to change it to I don’t know, 10 minutes if you know that you need that, right?
William: Or just keep it forever, right? An option to not have the modal dismiss and have to be manually dismissed. But that runs into an issue of stack contexts. How many notifications can stack on top of each other and how do you interact between them?
Amber: Or do they move up?
Steve: Yeah, that’s what they do.
Amber: Right, yeah.
Steve: Currently,
Amber: But, which I think is a valid solution to that problem in Gutenberg. But the thing is, it doesn’t make sense for us to add a solution for that to our plugin that would only apply to our notifications and not to all of WordPress notifications like that should exist in core.
William: So I was at first using the snackbar component as is directly from WordPress core and you know, I can’t change that. There’s no hooks to change it. You know, I could write it again myself. We shouldn’t do that, right? We should if we improve that we should contribute that back or someone should improve it and merge it.
Steve: Yeah, so like another kind of thing that sparked a little bit of conversation with, within our own organization. And we reached out to people in the community as well, is that we have a dropdown on the license. I think it’s on the license management. Yeah, on the license management page where you can assign a license, remove a license activate core plugin, activate Pro plugin, activate Audit History, activate Exporter, deactivate core plugin, you know, and so on.
So you can see that this select menu can get kind of, kind of, it’s not a ton of options, but it’s just you, there’s activating things and deactivating things. So it’s kind of like a little confusing. At least I found it confusing, so I kind of started seeking out like a solution to this. Maybe adding dividers in there just for a visual like difference and then I came across the the element, the opt group element.
I think I was searching the Mozilla MDM docs and so opt group, so you can actually put this opt group option. It’s like the same, you put it in the same as the, do you surround, I think you surround the options with it, right, William?
William: Yes, yeah, options live inside of it, inside the select box.
Steve: Yeah, so basically what I’ve done is I’ve created like three groups, right?
One called license, one called activate, and one called deactivate, and I’ve filtered the options into the appropriate groups, right? So, So I’m like, okay, this, I think this is fine. It kind of like on a screen reader, it kind of reads a little weird. I forget what it says. I’d have to retest it, but what, moreover, what it does is like in dark mode on a Mac, those labels are not the color contrast does not meet color contrast, right?
They’re just grayed out over a back black grayish background. Right. And then I think it was kind of the same, even in light mode. Right. But in Firefox, it wasn’t that way, right, William, for you?
William: Correct. So those styles come from the user agent styles, and you do not necessarily have any level of control in them from your style sheet, for example.
They are injected by the operating system. The operating system has decided whatever browser you’re choosing to use has chosen whether they implement those or not. So if you use iOS, they’re going to look different if you’re on Safari on a Mac, or for me, Chrome on Linux. And for me, actually, it looked fine in both light mode and dark mode, but in Chrome for Steve on a Mac, it didn’t.
Steve: So, so Amber reached out to the community, and do you want to speak about kind of what the conclusion of that was?
Amber: Yeah, I mean, so we had this whole debate because they failed color contrast. In some scenarios for some users, not always. Now, technically they don’t read as disabled, but they’re not something you can click and disabled elements like a disabled button is allowed to fail color contrast.
So, so I was, we were debating because I do agree that the dropdown looks better without, with having these divisions, and it is more helpful for users to have the divisions. So I did a little research, I ended up posting on some of my social media, on my Twitter, and or X, I always do that, and Blue Sky, and talked to a few people. I actually found, I can link this in the show notes, Adrian Roselli had really good posts where he had gone through and looked at those and different things, and I talked to a few people, because I’m like, is this a problem?
We don’t want to put, we don’t want to put accessibility problems into our plugin. And what came back is because this is something that we can’t control and there’s no way. Like I know Steve, you tried, you were like, is there any way I can target this? No. They said, you know, you can still use it. It wouldn’t count as a WCAG violation because it’s not something that the website can control.
And their solution was, you know, if it does make sense to use it, do that, but open bugs with the browsers. To notify them that this is something that the browsers have to fix. So we did end up deciding to keep them after talking to a few people we trusted in the community. Adrian being one of them who gave a lot of good information, but some other folks as well.
And and I do think it’s better. It does a little bug me that in certain color modes, in certain browsers, it doesn’t pass. It’s a little irritating, I think, but you know, perhaps.
William: An interesting thing about this particular issue is that this is not, this is a fully sighted user problem, right? This reads perfectly fine for a screen reader and works great with a keyboard. This is a sighted user problem and it is interesting for someone who’s fully sighted to deal with issues. It’s like flipping the script, right? We’re often considering people who are other, who have other needs, whereas someone who considers themselves as using the web as intended is running into an issue that is like a change of pace on things.
Steve: Yeah, and I’ll just, you know, final, I’ll add that the, for me, it was definitely like one of those, like, where you start weighing things, right? And for me, it was like, I just find I find this so confusing not having these broken up into groups. Cause if I’m going in I don’t want to accidentally click deactivate when I mean activate.
I don’t, you know, assign license, remove license. And I will say that we didn’t originally, and I’ll give credit to Amber for this. We didn’t originally have it, the labels set as a sign license, remove license. We actually had that, that said activate license and deactivate license. So it said activate license, deactivate license, activate core plugin, deactivate core plugin, you know, so like in my mind, it was really driving me crazy not having these divided out.
So I was like, so, so you start weighing those things and, but Amber suggesting to change those labels actually, I think was the greatest thing and it really didn’t cross my mind and Amber’s. Well, why don’t you just make it say assign and remove.
Amber: Yeah. Yeah, it is interesting. Like sometimes just language changes can really help a lot with accessibility.
Like we’ve talked about on other episodes of the podcast, ambiguous links. And just you know, adjusting wording in certain ways can really make things make a difference. I suppose if we didn’t want to use the options group. Like we could potentially have three different drop downs, right? Like one for assigning licenses, one for activating plugins and one for deactivating plugins, which perhaps if we build this out and we end up having, you know, I don’t know, 50 add ons.
I can’t imagine that we will, but let’s say we did. That’s probably a point where I would say, okay, we’d probably want to have different dropdowns because there’s only so many options you can put in a select before it becomes unwieldy.
William, Steve, and Amber Each Give Their #1 Accessibility Tip for WordPress Plugin Devs
Amber: So we are about at time. I’m wondering if we want to close out with our best advice for WordPress plugin developers who want to build plugins that are more accessible in the admin as well, because we talk a lot about front end of websites, but not always about the admin. And I’m curious if, either of you have thoughts and we can go through and share our best advice. Kind of like elevator pitch style.
Steve: Yeah. So I’ll try to answer mine without stealing everybody else’s answer. But the I would kind of like with everything, I would definitely try to implement the accessibility as early on in your development as you can, as you’ve heard William speak, he’s thinking about it, right out of the gate. Now, does it get it right every 100 percent of the time? No, it goes through a couple levels of refinement, you know before the final product. But I would just think about the things that you’re going to introduce into your libraries that you’re going to introduce into your plugins and consider the accessibility of those things as well and. But my big thing is that just make it part of the process. Functionality of your plug in matters, right?
If it doesn’t function it has no point. It matters, but the function out, but that functionality doesn’t exclude accessibility. So, so when you’re thinking about it, as simple as this drop down is right, like all the brain power that we kind of threw ideas off of each other about what to even call these things like to make, to differentiate them from each other, right?
Even though they do the same thing at the end of the day or to group them. Right? I think those are all great accessibility things to do early on in the process and to be thinking about throughout the whole process. And it’s just I think it’s with that, with everything, right? You need to consider accessibility early and you need to consider it often.
Amber: What’s your best advice, William?
William: I mean, Steve said he hopes it doesn’t steal it, but he kind of did. I will add to that though that, you know, as someone, so I am not an accessibility specialist by trade, I am a developer by trade and accessibility is an add on skill that I’ve acquired through building things that are required to be accessible.
And the one piece of advice I would give is don’t create fancy markup. Markup should just be simple headers, paragraphs, select boxes, input fields. The closer you can go to just standard HTML markup, the easier of a time you will have overall. At least for me as someone who’s not an accessibility specialist, some of the nuances of more complex things like autocomplete, don’t build that, I think is really my advice here.
Don’t get too complicated. Keep things simple.
Amber: And my best advice is get lots of feedback along the way. So if you can try to break things up into small pieces, that’s going to help you, because if you just save your accessibility testing until the end, then you might get real frustrated if you find out you have to go back and start over on something.
So, I know a lot of us are running fast. We have small teams. Maybe we don’t have an expert designer in a lot of cases. We’re just, you know, building our plugins and doing it without a design just with a general idea. So, the more feedback you can get, whether that’s, you know, in house, with your own team or bringing in an accessibility vendor just to review things or users who use your plug in.
I mean, I think that’s why people do betas too, right? Any feedback you can get before you release something and, at key points throughout the build process even before you have a beta is gonna be really helpful.
Steve: Awesome.
Amber: I think that’s about it.
Steve: Yeah
Amber: We have, I have quite a bit of my drink left I don’t know Steve has his hammer which he likes better than the soda.
Steve: I got a little bit of drink left. Actually a lot of drink and a whole lot of hammer left. So…
William: I have quite a lot left.
Amber: You’ll have that hammer for a long time and no teeth.
Steve: Here’s your thumbnail.
William: As much as people from Scotland will hate me for this, I think I’m going to go put this back in the fridge and offer it to one of my kids and I’m going to get myself a can of Cherry Coke.
Steve: There you go. Well, it was great having you on the podcast, William.
Amber: Thank you for joining us and thank you everybody.
Don’t forget to like and subscribe and all those things and we’ll be back in two weeks with another episode.
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 5 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.