As Accessibility Checker has grown, so have the ways teams use it. Some WordPress users need to review accessibility reports, others need to dismiss issues or run scans, and some should only have access to a specific feature. Our latest updates provide more granular control over these responsibilities without requiring site owners to give users broader WordPress permissions than they need.
In our latest changelog livestream, we introduced the new Permissions Settings in Accessibility Checker and demonstrated how administrators can control access for default and custom WordPress roles. We walked through the permissions available in Accessibility Checker Free, Pro, Audit History, and Export, including controls for dismissing issues, viewing the front-end highlighter, accessing Issues Explorer, running full-site scans, and exporting data.
We also took a look under the hood at the WordPress capabilities supporting these settings, the security safeguards we built around them, and how permissions are handled during installations, upgrades, add-on changes, and settings transfers. These updates give site administrators more flexibility while helping ensure Accessibility Checker data and actions remain available only to the appropriate users.
Here’s a complete recap of what we covered during the livestream.
Watch the Video
Read the Transcript
Steve: Let’s get it kicked off. Welcome to the Accessibility Checker live stream.
I’m Steve, and we have William here. I’m here. And, Will, is that … Are you gonna go by Will on this one?
William: No. William’s fine.
Steve: We’ll do the short. I’ll do Steve, you be Will.
And so if anybody’s joining, glad that you’re joining us.
Somebody said good morning. For me, it’s afternoon.
William: Okay. 7:00 PM for me.
Steve: For William, it’s evening. But, yeah, good morning, wherever you’re joining from.
Cool.
Like I said, this is the Accessibility Checker live stream. This is where we go over some of the newest features and changes inside of our Accessibility Checker plugin, which is an automated accessibility scanning plugin to help your WordPress website become and stay accessible.
Accessibility Checker is a suite of plugins. It’s not just one plugin. We have a free WordPress plugin that is very full-featured, called Accessibility Checker, and then we have Accessibility Checker Pro that brings in the more advanced features.
And then we have a few add-ons. We have a Audit History Add-on for tracking accessibility reports over time. The Multisite Add-on for adding, network-wide governance to Accessibility Checker to be able to apply your settings and your license keys and all those things straight from the network level.
And then we have an Export Plugin that allows you to export your Accessibility Checker data to a CSV file.
So with all that, William, what are we talking about today?
[00:01:59] Introducing Permissions
William: We’re talking about allowing and disallowing people to do all of those things that you just mentioned.
Steve: That’s right, permissions.
From permissions, controlling which WordPress roles can access reports and take specific actions.
Just a little bit of background on this, that I think is worth touching on for those joining in. Why permissions and why now?
William: I’ll let you say the why now, but… because my answer would be never do this.
But yeah, loosely we have a bunch of different capabilities that are gated by various different requirements in WordPress, like the ability to edit posts, the ability to ignore issues, and previously they were not super granular. They were pretty globally applied. And now, and we’ve had various support tickets with people asking for… why can’t certain user do a thing? Why can’t this, why can this user do a thing that we don’t expect them to? So the time was, the time was five years ago to do this.
Steve: Yeah.
William: But better late than never.
Steve: Yeah. We did take some steps in this direction five years ago, but we baked in kind of some permissions around who had the ability to dismiss issues, but which was a very kind of simplistic approach. And then there were some other permissions that arose over time that we piggybacked off of that one setting to have this setting act globally as a permission gate.
But through some recent, audit remediation projects that we’ve been working on, and like William said, some of the support tickets that have been coming in as of late, there have been a lot more in-depth inquiries into permissions and who can do what.
Where in the past we would make some assumptions around what roles typically will use Accessibility Checker, and we’re finding that the different User Roles are, they’re wanting… there’s a lot… I don’t know if this is all the security stuff coming up as of late, but people seem to be having more strict policies around permissions inside their WordPress admins, and we’re having to grant Accessibility Checker permissions to roles that we hadn’t originally expected would need those permissions.
And also not just the permission to dismiss or see reports, but actually to separate the two out. So there may be certain roles that they actually want to be able to just see the reports, but not actually action upon the issues, and it may be the other way around. So we started on this journey of kind of fix this for those client needs and for those customer needs, and then it ballooned as sometimes these features do.
William: It started as an editor role needs to be able to scan their pages, and it became weeks of pain.
Steve: In the process of building software sometimes you look for that quick win. You look, okay, we have this setting already. Can we shoehorn this in or piggyback off of this to achieve the immediate need, right?
And then there’s… And then you could take a step back and say, well we actually really should rethink this, and we should really rethink permissions granularly, how each action inside the plugin correlates to a core permission. And then going even further than that, saying, “It’s not enough for us to just create the capability, but we also need to be mindful of the capability permissions that WordPress core comes with out of the gate.”
Whereas we could create a capability, and you could use a user role editor and apply that capability however you see fit, and it opens up that feature, it opens up that REST route, right? But we actually found that could be quite dangerous. And we’ll talk through some of this a little bit here too about some of the gating and the floor and the respect that we’re taking of currently applied roles.
[00:06:44] Version Requirements
Steve: But, before we jump in, just a little bit, of the requirements here. This actually required changes in almost all the plugins. Actually, I think all the plugins did get changed, but-
William: All of the plugins. Yep.
Steve: But Accessibility Checker version 1.48, Accessibility Checker Pro version 2.3.0, Accessibility Checker Export 1.5, and Accessibility Checker Audit History 1.6. The multisite actually did get an update too, but it was just a notification of something that we’ll touch on here in a little bit.
[00:07:29] Permissions Settings
Steve: So William, with that preamble done, do we wanna pull up your screen and start-
William: Yeah.
Steve: Walking through some of this?
William: Let’s have a quick look.
Steve: All right.
William: Yep. Really the entry point to all of this is a new Permissions tab we have on our Settings page.
If you visit our Accessibility Checker Settings and the Permissions tab, this is what you will be presented with. General, a short Description, Title, and basically a User Role selector box, and obviously a Button. Some nice design that was provided by Steve, because you don’t wanna see what this looked like when I built it.
But yeah in this select box, all of the roles that are available on the website will exist, with exception to the Administrator User. I will say upfront that the Administrator User can do everything. They do not have to have capabilities granted or taken away, or they can’t be taken away. And this is just to prevent an Administrator locking themself out of a feature that they won’t be able to re-grant on their own.
If we pick any of these User Roles, so let’s just pick the Editor Role, you now have three, four separate groups of individual capability grants. Accessibility Checker free, by default everyone will have these three options, which is they can Dismiss their own issues, Dismiss issues on any post, which we will touch on in a minute, and Front-End Highlighter. And these three capabilities are in the free plugin for everyone.
The Pro plugin has some additional capabilities. Dismiss globally, Issue Explorer access, and Full-site scan capability. And the Audit History only has one page, View Audit History. That’s the only capability for that. And the Esport plugin also only does one thing, Export data.
And all of these capabilities can be granted individually as needed based on whatever way you set up your own website.
I will also say that if you have custom roles, they will appear in this list as well. My test site only has core provided roles, but all roles will appear in this list to pick from.
So yeah, that’s the Editor Role. An editor can be granted effectively anything by default as chosen. But let’s take a look at the Subscriber Role. A Subscriber Role by default only has read post capabilities, I believe, and as such are ineligible to be granted any of the other capabilities, with exception to the Front-end Highlighter. Anyone can see the front-end highlighter if you choose any logged in user.
[00:10:27] Under the Hood
William: Yeah, I guess this is perfect time to talk about the floor.
Steve: Yeah. Let’s touch on that a little bit. So this is what I alluded to a little bit at the beginning, was that, this respect for the floor or capabilities, they had to have certain capabilities, edit post or edit other posts, things like that.
So, yeah. Here you can see in the UI that these are disabled. And can you touch on kind of our reasoning behind-
William: Yes. The TLDR is that Users… so a Subscriber User cannot edit any posts, and as such will always be ineligible for dismissing their own issues. However, when we dismiss an issue, we store that in post metadata, and you’d need to be able to edit the post to update post metadata. Now, I will be clear that you can absolutely bypass that very easily. We have chosen not to because that feels a bit like a security risk. And same is true of editing other users’ posts is a separate capability. You can’t dismiss globally ever if you can’t edit other users’ posts, because almost certainly you will be ignoring other people’s things on a large website.
But yeah, edit posts and edit others’ posts are really the main gates we have here for the floor. So anyone who doesn’t have one of those two capabilities will always be ineligible for any mutation backed capabilities we provide in any of the plugins.
Steve: So if you… so to go a little bit deeper on that a little bit, if you were to say, since these are custom capabilities, they are available.
If you were using a User Role editor and you actually applied one of these, capabilities to, say, a Subscriber Role, that they don’t have edit permissions.
William: Yes. We actually have two gates. We have the custom capability, which is what we have added, which can be granted granularly to individual roles. However, any time we check a custom capability, we also check whatever the floor is as well, and the floor is what enforces security. It means you can’t accidentally give a subscriber access to dismiss issues globally, where they could effectively read all of the issues or disable all the issues on your website. That would be a potential leak of data if we allowed the capability singularly to override the core base requirement that we picked when we created the features.
Steve: So from a programmatic standpoint, there’s a gate here in the settings to not allow you to choose that.
William: Yes. That exact same gate exists at the point where we validate someone has a capability. We also validate the floor exists as well. And there’s two reasons for that. First off, general security is, it is good to make sure that your things are protected behind applicable core capabilities, first off. But secondly, if someone changes the level of a role later on, we still need to be backing them.
So you could install another plugin that allows the author to edit everyone’s posts. By default, they can’t. If that happens, and they still don’t have the edit other users’ posts capability, they still can’t be given this capability. It’s always double gate.
Anything that mutates anything.
Steve: And we check it on the API calls as well.
William: Yes.
Steve: That’s what I’m alluding to here, was, like, even if these were applied through other means besides our UI, that we actually still will block that access.
William: Anywhere you run these,
Steve: Yeah.
William: Any, if you make an API call, if you click a button in the UI, or even if you use WP-CLI to run any of our updates, the secondary gate, or both of the gates are always applied to every single instruments I create. Helper functions, they enforce whatever this floor level is, regardless of what’s checked here.
Steve: Yeah. Yeah. And when you talk about security, we’re trying to… We’re trying to keep parity with what WordPress Core’s, kind of permissions are in this regard, and respect those, yeah, for security reasons. But also, this could expand beyond, one user role could end up with access to pieces of data from another user role that the site owner doesn’t really want them to have access to. It could be PII of somebody’s information that’s been scanned in our database that we then don’t want to overexpose that to people that shouldn’t have it. Or in this case, it may be fine because we’ve actually, you’ve given that user role that access, like you have to manually turn it on as the site owner. But-
William: Yeah, so there is an unintended consequence of that.
Take a scenario where you want an author role on your website to be able to edit any post at all. Giving them the capability to edit any post effectively allows them to gain export capabilities to export the entire site data. Now by default, they will not get that capability, so having edit other users’ posts doesn’t immediately allow them to export all of the Accessibility Checker data. So that’s the real point of the double gate, unexpectedly granting access by allowing people to edit things shouldn’t give them access to all of the things.
Steve: Yeah, totally. So you’ll see here if the user role doesn’t match the floor that, between edit and edit other posts, that the setting will be grayed out. You also have grayed out settings if your license key is not active in Pro, if you have, Pro features, and the helper text that William outputs underneath the capability will tell them that’s the reason, right?
William: It will. So if your license has expired, you will have a different message here underneath each one that says, “License expired, update your license key,” and-
Steve: What does that say for… since this doesn’t have the capability, can you read that out for?
William: You mean the licensing? So I have an active post-
Steve: No, no.
I’m saying just,
William: Oh, gates…
Steve: We can see. I wanna, I want to say it.
William: Okay. So requires the ability to edit other users’ posts is one of the gates, and the other main gate is requires the ability to edit posts. And depending on which capability you’re looking at, it will tell you exactly which capability is required for that user role. So requires the ability to edit posts, requires the ability to edit other users’ posts.
Steve: Now, are there… Now this is a rhetorical question that I already know, but for our listeners, but are there any areas where we actually stepped out of the floor a little bit?
William: There is one specific area.
So dismiss issues across any posts. It says, “Dismiss and reopen accessibility issues on any post, even if the user cannot otherwise edit it.” So out of all of the capabilities we have here, this one is the only one that purposefully oversteps core requirements. You still need to at least have the ability to edit posts, which is effectively your own posts.
You can grant a user that can only edit their own posts the ability to dismiss posts, dismiss issues on any post. This is the only capability that oversteps core’s existing capability grants of, for edit other users’ posts would be required to dismiss an issue generally on a post that you weren’t the author. And we did call that out by saying even if the user cannot otherwise edit it.
Every other capability has a minimum floor that matches what the core expectation would be. This one is one step below what the core expectation would be, and that is because we might have… we know that some customers have auditor type roles that should be able to ignore issues once they’ve verified they’re fine, but not necessarily able to edit everyone’s posts on the website.
This is the one overstep, but aside from that, every other one has expected minimums.
Steve: Does this help facilitate contributors as well? ‘Cause there is a, unique caveat with the contributor role that I think a lot of people, even myself-
William: This does.
Steve: … overlook.
William: A Contributor Role could be granted this one because Contributors do have the edit post capability, but they can only edit their own posts prior to them being published. Once that post publishes, they would no longer be able to dismiss issues, scan the posts, do anything at all, which-
Steve: Yeah.
William: … is unique for Contributor. But, you might have a user that is a Contributor or effectively someone who you don’t want to be able to edit all the content on the website, but still be able to audit the issues.
And this is the one capability that allows for that, with the caveat that it does ever so slightly step one… It goes one level above what the core capability would allow alone.
Steve: Yeah. Cool.
Can we test one? Can we, look at, So one area that I like here is that, we’ve had several requests for the Front-End Highlighter not to output on the front end for certain User Roles.
William: Correct.
Steve: So now this-
William: If we go to the subscriber, I do have Front-End Highlighter enabled for the Subscriber Role as part of the test. But by default, a Subscriber Role will get no capability ranks at all. So if I were to save these permissions, and then I switch to a Subscriber Role, visit the front end, there is no-
Steve: Oh, hold on.
Let me hide you and me.
William: Oh.
I can move it to the other side actually.
Steve: No, it’s all right.
William: That’s it. Yeah, so there is no Front-End Highlighter available in the lower right corner where it would normally appear. So if I switch back to my Admin User, you see it, it does appear. If I click on it, it opens it, it shows me the issues. So if I go back to the Settings page, Permissions, and I choose the subscriber again, and I give it the Front-End Highlighter permission, save this, and then I switch to the Subscriber Role again, visit the front end, now they can see it.
Some people have asked for the ability to let other users see this.
I will call out that if we scroll to these issues, you can’t ignore any of these issues because you don’t have any mutation capabilities. You don’t have the literal capability to ignore issues.
You also… if you look in the menu setting, you also can’t rescan either because you wouldn’t be able to save the issues as a contributor.
Steve: Yeah, it’s totally basically like a read view.
William: Yes. If I were to switch to, the Full Editor Role, they also have this available to them, and they can clear issues and rescan the page from the menu because they are a Full Editor. But if I were to switch back to the admin… We need to add the permissions link in that menu.
Steve: Yeah.
William: Look for this, and then I visit the editor, and I remove their ability to see the Front-End Highlighter, save it, and then I switch to the Full Editor again, visit the front end, they can no longer see it. It is able to be granted to users that previously wouldn’t have been able to see it, but also removed from users that previously would have been able to see it, and that’s a choice of the Site Admin. It’s not a choice we’re making upfront anymore.
We have some defaults where by default an editor will be able to see it, but you can remove that grant as the site admin if you choose.
Steve: Yeah. And another request that we’ve gotten a lot was allowing certain User Roles to see, the Audit History reports, where they generally were not able to see that unless they were an admin role or-
William: Correct.
Steve: Or they fell within hat kinda global permissions setting that we had before.
William: Yeah.
As a full Admin, I can see Audit History. If I change to a user that only has the export capability, no longer see it. Gets redirected away. But this user has export, can visit the Export page. And if I were to change various different roles…
So I’ve got these all set up as different test users with the user switch plugin. So Audit History only. We hover over the Accessibility Checker menu, you see the only item available for them is Audit History. If I pick the Explorer only role, we can see similarly under the Accessibility Checker menu, they can only pick Issue Explorer. So individual users can be granted-
Steve: While you’re here in the Issues Explorer, and for our people watching, if you haven’t tried out our new Issues Explorer, give it a try.
We have a past live stream all about the Issues Explorer.
So you’ve granted them the ability to get to the Issue Explorer, and I’m guessing this role actually has dismiss capabilities as well.
William: I just switched back to the Admin Role-
Steve: Oh, okay.
William: …Who has capabilities. So yeah, I was able to come in here and dismiss this issue.
If I switch to export only role… Oh, not export, explorer only role. And back to the explorer. Try to click on this issue. Oh, I guess I’ve also granted them-
Steve: No. I don’t think it’ll work.
William: Oh, it doesn’t?
Steve: Yeah.
William: Sorry.
Steve: Yeah. Yeah. So you can… So this is a little bit of a UI catch too, that we actually don’t remove that panel, but I think that was for a specific reason, wasn’t it?
William: I don’t remember the specific reason, but I do remember it being somewhat complex to hide this just for individual capability grants.
Steve: Yeah, because you’re doing a per user capability look up any time that panel-
William: Yes.
Steve: … Is rendered.
William: That’s exactly it.
Steve: Yeah.
William: It is too unperformant to check every single post one at a time.
Steve: In most cases, we do try to hide the UI if we can, and it can be done in a performant way. But in this instance, it looks like, either this is a future solve or we’re just not able to do it in a performant way without a lot of changes to this little React app.
William: Yeah. And just for people who can’t see it, if you try to dismiss an issue and you don’t have the capability, you do get an error message back from the API that says, “Sorry, you’re not allowed to do that.”
And it’s the same if you pick any…
Steve: Yeah. And this likely… this is a little bit of a fail-safe too if, these capabilities are granted by other means than our UI, right? Through a User Role Editor.
William: Correct. If there is a mix of capabilities available, and it is mixed up somehow by someone maybe manually swapping individual users with the role editor plugin, this is the gate end effect, basically.
This is an API call where this gets returned from. So regardless of what the UI shows, if they’re not supposed to be able to do something, the API will also still block it.
Steve: Yeah. Not just what the UI shows, but regardless of how the capabilities are actually applied.
William: Correct.
Steve: If it doesn’t meet that floor requirement.
Now, maybe we could sit with that for a minute and go a little bit deeper, and we did this ourselves a little bit when we implemented the floor here for security reasons. And the reason we do that, like William said, is Accessibility Checker saves data to the user meta. We need to modify the user meta, and things that can be scanned and caught in our scanner and stored in the Accessibility Checker table can actually be information that maybe not every user at every level should see.
But we did sit with this, and we did think about- Is this appropriate? Should we be taking that extra step to make those decisions, or should we just make the capabilities and let the user open up whatever they wanna open up, and regardless of the implications of what data may be exposed to what user?
‘Cause we can very well do that, and I think if we get a lot of feedback that is something we requested, we may open this up further in the future. But we kinda felt like taking a little bit of a safe approach here. I don’t know if you have anything to add to this, William, about opening it all the way up and letting the user decide.
I think that absolves, since it’s all user defined, I don’t think there’s huge, security impli-
William: We can let a user make it insecure if they choose to do that. I would rather by default we try our best to make sure that they can only pick secure options. However, I will call out that there is a filter available for anyone who is developer-orientated, if they did wanna bypass our minimum floors. They could edit them if they choose, but that is a developer decision only, not something that we expose anywhere right now.
Steve: In that line of filters, is there a way through the filters that we’ve provided that somebody could grant these permissions at the user level rather than at the User Role level?
William: Yes, there absolutely is. These capabilities are standard WordPress capabilities, and if someone knows how to use the WP role class, they could grant those capabilities to whoever they choose, either to roles directly or even to individual users. We only offer role-based grants in the plugin through the permissions tab, but if someone was so inclined and they wanted an individual user, regardless if the role to have certain capabilities, they could grant those capabilities themselves with some code. Or through the User Role Plugin, User Editor Plugin. There is plugins available as well if you want to do it in a UI, but we do not expose that ourselves through the plugin.
Steve: Cool. You touched on it very briefly, but I just kinda wanna jump back a few steps and ask again why in the Settings the Administrator Role is not listed as a role where you can control Permissions?
William: That was a specific choice. We decided that Administrators should always have all of the capabilities at all times. In fact, if you have Manage Options, you can, if you have Manage Options on a website, you can almost do anything you choose at all times.
That’s not just with our plugin, that’s generally how WordPress determines who an Administrator User is, if they have Manage Options.
We didn’t want someone to accidentally be able to remove access themself as an Administrator. But even more than that, Core’s own ethos is that Manage Options is top tier permission.
Steve: Yeah.
William: There isn’t anything really above that, unless you’re talking about a multi-site which, Super Admin capabilities. But on a single site, Manage Options is the highest capability level available.
And if you have Manage Options, you can edit your own capabilities.
Steve: So it’s kind of pointless, right?
William: Yes. Yes, exactly.
[00:32:03] Installation and Upgrade Behavior
Steve: Cool. Very good. Let’s move on, and let’s talk a little bit about the installation and upgrade behavior. So new installations receive the conservative, default permissions, correct?
William: Yes. And off the top of my head, I can’t remember exactly the combination. But there is a slight deviance to what the old defaults were. The old defaults were that only Administrators had access to any of the things. The new default is that Editors will be able to ignore their own posts. Authors will also be able to ignore their own issues on their own posts, and both of those people will see the front-end highlighter by default.
Steve: Yeah.
William: That is the new default, and that is a deviance to what the old standard was.
The old standard we had the ignore I think it was the ignore roles- Same …
Steve: It was ignore permissions. Yeah.
William: And that was basically the grant that allowed you to see things or ignore things, and you could just pick a role in that, save it, and that user would effectively get all of the access to all of the things feasible.
If you do have an option saved with custom values from previously though, we will not grant the new capability defaults, so we will honor whatever that checkbox was set to from the old option. So there is a difference for new installs versus upgrades.
We took the philosophy of never giving someone access to something they don’t already have.
Steve: If I have Accessibility Checker installed previous to this version, and I have in my ignore permission setting, I had Editors and Authors set to ignore permissions, when I upgrade to this version, there is an update process that will carry those permissions over?
William: Correct. Whatever the Editor would have had access to previously, which would effectively be, the dismiss issues on any post, dismiss globally for an entire layer, and dismiss own issues. These four will be honored. Actually, no. Let me correct that. They will never get the any post. That’s always a selective choice. So these three issue, capabilities- dismiss own issues for an entire layer, and dismiss issues globally is what it will migrate to if this editor was set to be able to ignore issues in the old site.
Steve: I think you may have touched this on a little bit too. So if I have Accessibility Checker and I upgrade to Pro and I get new capabilities, I come in at the default level of those as well.
William: Correct. Default level is dismiss issues globally if the setting was checked previously. If there was no setting, then only admins are gonna be able to dismiss globally.
Steve: And if a user disables an add-on, right? Say they have the Export Add-on, and then they set permissions, and then they disable the Export Add-on ’cause they don’t need it, and then they re-enable it later on, the permissions will come back to life, right? Because the settings.
William: Right.
If you delete the xport plugin, it does not delete whatever options you have selected for the user here. Those are only deleted if you uninstall the base plugin with the checkbox that says to delete all the data. Otherwise, permissions get retained, across activations, disables, deletions of everything except the free plugin is the only one that actually has the capability to delete data on uninstall.
Steve: Cool. So we talked a little bit about our Multisite Plugin and there’s some import/export features inside of this inside of Accessibility Checker Pro as well.
William: Correct.
Steve: We debated back and forth about should we allow permission settings to actually be included in these imports and exports and in the Multisite Plugin by copying over those…
Our Multisite Plugin will allow you to copy settings to all your subsites. And, then that raises a question in a multisite. There’s a lot of difference in how users are applied per subsite.
William: Yes.
If you’re the only user in a multisite instance, then it is a fair assumption that you are the Site Owner of every site in that instance.
But in our experience, most multisite instances have Site Sdmins, which are not the necessarily Super Sdmins. And in that case, it actually should be up to the Site Admin to decide who has access to the various different capabilities. I had a lot of back and forth while I was working on these features to decide whether we export those settings or allow them to be migrated. And in general, the decision was that exports from one site should never carry permissions to another site for security reasons. People should know upfront what they were importing, and that is in line with how a lot of exports work outside of our plugin or just generally on the internet, as the capabilities are rarely ever exported then allowed to be re-imported.
Because for example, I could export all of the settings from this local test site and give it to someone to import into their production website. This is a local site, and I have less concern over security than someone who’s running a live production website.
Steve: On our import export screen, you’ve put up a notice here that reads, “Security related settings, user permissions, and role capabilities are not included in export or import. Configure permissions manually on each site.” And we will do a similar message in the Multisite Add-on as well, right?
William: It’s exactly the same message on the multisite. And the multisite previously did export the old ignore roles permission, so that did change in the Multisite Plugin. We will no longer export that or clone that across websites, for the reasons I just outlined, right?
The Site Administrator should really be the person who decides who has access to which things.
Steve: Yeah.
William: And most multisites in my experience are not single admin, they are multi admin. That’s generally the point of the multisite.
Steve: Yeah. And, on multisites we’ve seen variating, levels of governance and control, and it’s not always done in the most, elegant way. So we decided that we don’t wanna circumvent access to things that a sub-site owner or admin is not aware of. So if we were to implement this in the Multisite Add-on, we think we would need to have a governance layer and an approval layer, where if you tried to apply permissions to a sub-site, that sub-site’s admin would have to approve those before they get applied.
But there’s a lot of steps in that, and then we felt that there’s a lot of potential for confusion or potential for things to become stale over time. So we decided to err on the side of caution here, again, making sure that those permissions are explicitly set with manual controls on every website.
And, we’ve been taking a lot of care with Accessibility Checker, throughout its life, but even more now with the rise of AI and AI bots being able and agents being able to scan and find security vulnerabilities. we’re not just-
William: If we weren’t being considerate-
Steve: Yeah,
William: … of that, we would’ve got flagged by some AI bot that found the vulnerability. We were very-
Steve: Yeah.
William: … explicit in making sure that almost everything we have included here is gated by existing capabilities. Aside from the one that is a slight overstep, but being considerate of that actual allows any of the plugins to be updated in any order or completely out of order, or one plugin never to be updated and nothing will break.
Everything that was previously the gates would still exist-
Steve: Yeah.
William: … in any of those plugins.
Steve: Yeah, the mission here with Accessibility Checker is to make the web more accessible, right? But, the mission here is twofold, or maybe even more than twofold, but, security and how the Accessibility Checker handles your data and how it exposes your data as well has become, of the utmost paramount concern for us as well.
So some may look at these user permissions that we’ve implemented and say, “These are restrictive. Why can’t I just give a subscriber all the permissions to do whatever?”
William: I will tell you a story about the time where someone wanted to have access to the full-site scanner, and then instead of being able to give that, just decided to make that Author a level user or Full Administrator on the website. That is a pretty big security consideration for that person to do that. We actually don’t wanna force you to have to give elevated Core permissions to someone just so they can access a subset of our plugin’s capabilities.
[00:42:32] What’s Next for Permissions?
Steve: Yeah. And this sets the stage for many capabilities to come, right?
William: Yeah. I think- I hope we take a little break. But yes, this adds the framework that makes it fairly simplistic to add additional capabilities and enforce those grants-
Steve: Yeah.
William: … anywhere in any of the plugin or any other add-ons we may build.
Steve: Yeah, we have lots of things we are cooking and lots of ideas, and having a whole permissions layer like this definitely makes everything much more secure and gives us a very clear path forward.
I just wanna… We do have an article on this already, before our changelog live stream post goes out. If you would like to read up on this, you can find that at EqualizeDigital.com/Accessibility-Checker/Permissions-Settings.
Where you can learn about a lot of the things we went through today. This is already out in the wild, so update your version of Accessibility Checker to get these new permissions.
William: Also if you can, let us know if we were correct in the floors that we picked on these, or if you have other capabilities that you may have expected that we didn’t include here, now is the time to get those in.
Steve: Yeah.
William: So let us know.
Steve: Let us know. We always appreciate the feedback. I’m glad everybody could join us today. And, William, great work on the User Permissions. We will give you a little bit of a break after this.
William: I’m sure you’ll find a better project as well.
Steve: Yeah.
On to the next project.
Hope everybody has a great day. Please like and subscribe if you’re watching on YouTube, and look for the next, Accessibility Checker live stream next month.
Take care. See y’all.
William: See ya.
Introducing Permissions
WordPress already has capabilities controlling actions such as editing posts, editing other users’ posts, and managing website settings.
Until now, Accessibility Checker permissions were relatively broad. We had an existing setting for controlling who could dismiss issues, and some later features relied on the same setting as a general permission gate. As Accessibility Checker grew, and as we heard from customers with more complex WordPress user roles and security policies, we knew we needed a more granular approach.
Different organizations structure their WordPress users in different ways. A role we may not have originally expected to use Accessibility Checker might be responsible for reviewing accessibility reports. Another role may need to see accessibility issues without being allowed to dismiss them. Some users may need to take action on issues without receiving broader access to other Accessibility Checker features.
Moving Beyond a Single Permission Setting
Our previous approach started with permissions around dismissing accessibility issues. As we introduced new features, we sometimes used that same setting to control access to additional functionality.
What initially appeared to be a request to let an Editor scan a page quickly expanded into a larger reconsideration of how permissions should work throughout the plugin. We needed to examine each action, associate it with a dedicated capability, and determine how that capability should interact with the permissions WordPress already provides.
Creating custom capabilities was only part of the solution. We also needed to respect the security boundaries established by WordPress core.
A custom capability could theoretically be assigned to any role through code or a user role editor plugin. However, opening a feature or REST API route based only on that custom capability could expose information or allow changes a user should not otherwise be able to make.
Our new system combines granular Accessibility Checker capabilities with baseline WordPress capability requirements. We will explore those safeguards in more detail under the hood.
Version Requirements
The permissions system required coordinated changes across nearly all of the Accessibility Checker plugins. To use these features, the following versions are required:
- Accessibility Checker 1.48.0
- Accessibility Checker Pro 2.3.0
- Accessibility Checker Export 1.5.0
- Accessibility Checker Audit History 1.6.0
The Multisite Add-on also received an update, although its change primarily relates to how we communicate the handling of permission settings across sites.
Permissions Settings
The main entry point for the new permissions system is the Permissions tab under Accessibility Checker > Settings.
During the livestream, we opened this tab and demonstrated its role selector and permission groups. Administrators can choose an eligible WordPress role and decide which Accessibility Checker capabilities to grant to that role.
All roles, except the Administrator role, available on the website appear in the selector, including custom WordPress roles. The Administrator role is intentionally excluded because administrators, and other users with the manage_options capability, always retain full access.
After selecting a role, the page displays separate groups of permissions for Accessibility Checker Free, Accessibility Checker Pro, Audit History, and Export. You can grant each available capability individually based on how the website is managed.
Accessibility Checker Free Permissions
Every website using the free Accessibility Checker plugin has access to three permission controls.
Dismiss Issues on the User’s Own Content
This capability allows users to dismiss and reopen accessibility issues on content they are otherwise permitted to edit. It is useful for Authors, Editors, and other content contributors who are responsible for addressing accessibility problems within their own work.
Dismiss Issues on Any Post
This permission allows someone to dismiss and reopen accessibility issues on any post, even if they cannot otherwise edit that post.
This capability supports workflows in which an accessibility auditor needs to review and dismiss issues across the website without receiving permission to edit all of its content. Because it intentionally goes slightly beyond the user’s normal content-editing access, we clearly identify this behavior in the setting description.
View the Front-End Highlighter
This capability controls whether a role can see the Accessibility Checker highlighter on the front end of the website.
We have received requests both to make the highlighter available to additional roles and to prevent it from appearing for roles that previously had access. Administrators can now make that decision for their own websites.
Accessibility Checker Pro Permissions
When Accessibility Checker Pro is active and properly licensed, three additional controls are available.
Dismiss Issues Globally
This capability permits a user to dismiss an accessibility issue globally. Because a global dismissal can affect issues across content created by multiple users, it requires a higher baseline level of WordPress access.
Access Issues Explorer
This permission controls access to Issues Explorer, our centralized interface for reviewing and managing accessibility issues across the website.
Access to Issues Explorer is separate from permission to dismiss issues. This distinction allows a role to view the information in Issues Explorer without automatically receiving permission to change issue statuses.
Run Full-Site Scans
This capability allows the selected role to initiate a full-site accessibility scan. It gives administrators a way to provide access to the scanner without making someone a full WordPress administrator.
Add-On Permissions
The Audit History and Export add-ons each introduce an additional capability.
The View Audit History permission allows a role to access reports that track accessibility results over time. The Export Data permission allows a role to export Accessibility Checker information, including accessibility data, scan statistics, global ignores, and Audit History reports where applicable.
These permissions are independent. A user can receive access to Audit History without receiving access to Export, or access Export without being able to open Audit History.
Demonstrating Role-Based Access
During the livestream, we demonstrated how these settings affect different WordPress roles.
We first selected an Editor. Because Editors already have broad content-editing capabilities in WordPress, they are eligible for most of the available Accessibility Checker permissions. An administrator can grant or remove each capability based on the Editor’s responsibilities.
We then selected a Subscriber. Subscribers typically have only basic read access, so most of the permission controls were disabled. However, a Subscriber can still be granted permission to view the front-end highlighter because viewing the highlighter does not require the ability to modify content or Accessibility Checker data.
Controlling the Front-End Highlighter
To demonstrate this behavior, we switched to a Subscriber account without the front-end highlighter permission. When we visited the front end of the website, the highlighter was absent.
We returned to the Permissions settings, granted the Subscriber access to the highlighter, saved the change, and switched back to the Subscriber account. The highlighter then appeared and could be opened to view the accessibility issues on the page.
For a user without dismissal or scanning capabilities, the front-end highlighter functions as a read-only view. The Subscriber could see the issues but could not dismiss them or rescan the page.
We also demonstrated the reverse scenario with an Editor. After removing the Editor’s highlighter permission, the control no longer appeared for that role. The site administrator can therefore grant the highlighter to roles that previously could not see it and remove it from roles that previously could see it.
Limiting Access to Individual Reports and Tools
We also used test accounts to demonstrate access to individual Accessibility Checker admin pages.
A user with only the Export capability could access the Export page but could not access Audit History. A user with only the Audit History capability saw Audit History as the only available option under the Accessibility Checker admin menu. Similarly, a role with only Issues Explorer access could open Issues Explorer without receiving access to other areas.
These demonstrations show the central benefit of the new system: access to one Accessibility Checker feature no longer needs to provide access to everything else.
Under the Hood
The controls on the Permissions settings screen are powered by dedicated WordPress capabilities. We created separate capabilities for the actions available throughout Accessibility Checker Free, Pro, Audit History, and Export.
However, granting one of these custom capabilities is not always enough. For actions that modify data or provide access to information across the website, we also check for an appropriate baseline WordPress capability.
Establishing a Minimum Capability Floor
We refer to the baseline WordPress requirement as the capability floor.
For example, Accessibility Checker stores information about dismissed issues with the related content. A user needs permission to edit the post before they can update the associated information. A Subscriber who cannot edit posts is therefore ineligible to dismiss issues.
Permissions involving content created by other users generally require the ability to edit other users’ posts. A user who cannot edit other people’s content cannot typically dismiss issues globally because the action could affect accessibility results associated with content throughout the website.
The two primary WordPress capabilities we use as floors are the abilities to:
- Edit posts
- Edit other users’ posts
Any Accessibility Checker capability that changes data is protected by both the custom plugin capability and its corresponding WordPress capability floor.
Why We Use Two Permission Gates
We enforce these requirements in two places. The Permissions settings prevent an administrator from selecting an incompatible capability for a role, and the same validation occurs whenever a user attempts the action.
This means the capability floor is checked when someone clicks a button in the interface that makes an API request. It also remains in effect if someone assigns an Accessibility Checker capability through code or a third-party user role editor.
The double gate protects against unintended combinations of permissions. For example, another plugin could modify a role so its users can edit additional content. That change should not automatically give those users permission to export all Accessibility Checker data or dismiss accessibility issues globally.
A broader WordPress editing capability does not automatically unlock every Accessibility Checker feature. The user must also receive the specific Accessibility Checker capability.
These checks also help protect data found during accessibility scans. Scanned content could contain information that should not be visible to every WordPress user. We want to avoid exposing site-wide accessibility data simply because someone received an unrelated content-editing permission.
When a Role Is Not Eligible for a Permission
If a selected role lacks the required WordPress capability floor, the corresponding permission control is disabled. Helper text beneath the control explains whether the role needs the ability to edit posts or edit other users’ posts.
A setting may also be disabled when its associated Pro feature or add-on lacks an active license. In this situation, the helper text explains a valid license is required.
These messages help administrators understand why a capability is unavailable, rather than presenting a control that cannot be used successfully.
The Exception for Dismissing Issues on Any Post
The Dismiss Issues on Any Post capability is the one intentional exception to our usual alignment with WordPress core permissions.
Normally, a user would need permission to edit other users’ posts before taking an action associated with that content. With this capability someone can be permitted to dismiss accessibility issues on content they cannot otherwise edit.
We created this exception for auditor-style roles. An accessibility reviewer may need to confirm that an issue is acceptable and dismiss it without receiving permission to modify the page itself.
This permission can also help with the Contributor role. Contributors can edit their own unpublished content, but their access changes after the content is published. Granting this Accessibility Checker capability can allow a Contributor or similarly restricted role to continue auditing accessibility issues without providing broad content-editing access.
We call out this exception directly in the setting by explaining that the role can dismiss and reopen accessibility issues on any post, even if the user cannot otherwise edit it.
Testing UI and API Enforcement
During our Issues Explorer demonstration, we showed what happens when someone can open Issues Explorer but does not have permission to dismiss issues on any post.
For performance reasons, the dismissal panel may still appear if the user has any of the dismiss capabilities. Determining whether to hide it on an issue by issue basis would require checking permissions against individual posts as the interface is rendered, which could be too resource-intensive.
The action remains protected even when the control is visible. When the user attempts to dismiss an issue without ability to edit the post or the capability to dismiss on any post, the API blocks the request and returns the message, “Sorry, you are not allowed to dismiss issues.”
This API validation functions as an important fail-safe. Even if the interface shows a control or capabilities were assigned through another plugin, the action cannot be completed unless the user satisfies both permission gates.
Supporting Individual User Permissions
The Permissions tab provides role-level controls, but the underlying capabilities use the standard WordPress capability system.
Developers can use the WordPress role and user APIs to assign capabilities directly to a role or individual user. A user role editor plugin may also provide a visual interface for making those assignments.
We do not currently expose individual-user controls within Accessibility Checker. However, the capability framework supports more granular implementation when a developer needs it.
We also provide a filter for developers who deliberately need to modify or bypass one of our selected capability floors. We chose to keep this as a developer-level decision rather than offering it as a general option in the settings interface.
Why Administrators Are Not Listed
The Administrator role does not appear in the permission selector because administrators always have full access to Accessibility Checker.
More specifically, users with the WordPress manage_options capability receive all Accessibility Checker capabilities. On a single WordPress site, manage_options represents the highest standard capability level. Someone with that access can also modify capabilities, so allowing the user to remove their own Accessibility Checker permissions would provide little practical protection and could create unnecessary lockouts.
Multisite installations also have the concept of a Super Admin, but on a standard single site, users with manage_options retain full access at all times.
Installation and Upgrade Behavior
We designed the installation and upgrade process to avoid unexpectedly expanding access on existing websites.
Defaults for New Installations
New installations receive conservative default permissions.
By default, Editors, Authors and Contributors can dismiss issues on their own content, Editors and Authors can view the front-end highlighter. Subscribers do not automatically receive any Accessibility Checker capabilities.
These defaults differ slightly from the previous behavior, under which administrators were generally the only users with access unless another role was selected through the legacy Ignore Permissions setting.
Administrators continue to have full access regardless of the default role settings.
Preserving Existing Permissions During Upgrades
Existing websites may already have roles selected through the previous Ignore Permissions setting. When those sites upgrade, we honor the access those roles already had by migrating the setting to the corresponding new capabilities.
Our guiding principle was to avoid granting someone access to something they did not already have. If a website has saved custom permission choices, we preserve those choices instead of applying the defaults used for a new installation.
The new Dismiss Issues on Any Post capability is always an explicit choice and is not automatically granted during the migration.
Activating Pro or an Add-On
Activating Accessibility Checker Pro or an add-on introduces new capabilities, but it does not automatically grant those capabilities to non-administrator roles.
For example, if the previous Ignore Permissions setting allowed a role to dismiss issues globally, the applicable access can be preserved when Pro is available. If no previous setting granted that access, only administrators receive it automatically.
This approach prevents a plugin activation from silently expanding what other users can do.
Retaining Permissions When an Add-On Is Deactivated
Permission selections remain stored if an add-on is deactivated or deleted and later reinstalled.
For example, if an administrator grants a role access to Export and then deactivates the Export add-on, that selection is retained. When the add-on is reactivated, the permission becomes available again.
These stored permissions are removed only when the base Accessibility Checker plugin is uninstalled with the option to delete all plugin data. The free plugin is responsible for the shared settings used across the plugin suite.
Excluding Permissions from Settings Imports and Exports
Accessibility Checker Pro includes settings import and export tools, while the Multisite Add-on can apply settings across subsites. We carefully considered whether role and permission settings should be included in those processes.
We decided that security-related settings, user permissions, and role capabilities should not be transferred automatically between websites.
Roles can have different responsibilities from one website to another. A settings export created on a local test site may be imported into a production site with very different security requirements. Automatically applying the original permissions could give users access the production site administrator did not intend.
The import and export screen now includes a notice explaining that these settings are excluded and must be configured manually on each website.
Permission Settings on Multisite Networks
The same principle applies to WordPress multisite.
A multisite network may have a Super Admin, individual Site Administrators, and different users assigned to each subsite. In many networks, the Super Admin is not the person responsible for day-to-day access decisions on every site.
The Multisite Add-on previously copied the legacy Ignore Permissions setting across websites. It no longer copies that setting or the new role capabilities. Instead, each Site Administrator must configure permissions explicitly for their site.
We considered whether a network-level governance and approval process could allow permissions to be pushed to subsites. Such a system would need to ensure that each Site Administrator understood and approved the access being granted. It could also introduce confusion if roles or responsibilities changed over time.
For this release, we chose the clearest and safest approach: permission settings must be reviewed and applied manually on each site.
Providing Access Without Elevating WordPress Roles
Granular Accessibility Checker permissions can also reduce the need to give users unnecessarily powerful WordPress roles.
Before this update, an organization that wanted someone to run a full-site scan might have made that person an Administrator because there was no direct way to grant only the required access. Giving someone a much higher WordPress role for one plugin feature introduces a significant security concern.
The new framework lets administrators grant access to individual Accessibility Checker features while respecting the user’s existing WordPress role and its security boundaries.
What’s Next for Permissions?
This release establishes a framework we can use as Accessibility Checker continues to grow. We can now create additional capabilities, connect them to the appropriate WordPress permission floors, and enforce them consistently throughout our plugins and add-ons.
We have more features and ideas in development, and this permissions layer gives us a clearer and more secure path for introducing them. It also allows us to revisit existing workflows with more flexibility around who can view information and who can act on it.
The new permissions are available now. Update Accessibility Checker and the applicable Pro and add-on plugins to begin configuring access for your WordPress roles.
You can also review our existing permissions documentation. We welcome feedback about the baseline capability floors we selected and any additional permissions your organization may need.
Join Us for the Next Livestream
The Equalize Digital Changelog livestream airs on the fourth Thursday of the month. Each episode will feature demos, technical deep dives, and previews of new features or plugins. Follow us on YouTube to get notified when we go live.
To learn more about Accessibility Checker, download Accessibility Checker or upgrade to Pro.
If you have feedback or questions, you can connect with Steve Jones on X or join our Facebook group.
We look forward to sharing more soon in the next changelog.
