This changelog episode kicked off our first livestream of the year with a focus on maintenance and accuracy. We shipped a set of quiet but important fixes that improve the accuracy and reliability of your accessibility data.
These updates focus on accuracy and long-term reliability. Refinements to metrics, rule behavior, and UI feedback ensure Accessibility Checker continues to deliver clear, reliable results for dashboards, audits, and client reporting. Maintenance isn’t just cleanup; it’s a feature.
Here’s a complete recap of what we covered.
Watch the Video
Video Transcript
Steve: [00:00:00] All right. I think we’re live.
William: Yeah. Looks like. Yeah.
Steve: Happy New Year.
William: Yeah. Feels like it’s been a long time since we’ve done one of these.
Steve: Yeah. Yeah. This is the first changelog livestream of the new year.
William: Yeah.
Steve: So, let’s make sure everything’s going out all right.
Lemme double check.
Double check on YouTube, make sure we’re streaming and it looks like we are.
All right. Cool.
Alright. Welcome anybody joining us. We’re give a little bit of time. We’re a little bit late. Technical issues over here with some microphones and stuff, but [00:01:00] I think we’re good now. Everything’s coming in loud and clear and today is a special day where we need William to be very clear because Steve is dealing with just Winter, with a cold in the head that just will not go away.
So, William’s gonna be, need to be our clear voice today. So, you’re seeing me.
William: That’s gonna be rough for me.
Steve: Yeah, you’re see me sucking off cough drops and drinking… my usual Diet Coke. And look, William, my kids got me…. I don’t know if you can see in the background, over the break, my kids got me a a light up. I don’t have it lit up, coke sign in the back, Diet Coke sign.
William: They know you better than anyone.
Steve: If you listen to the Accessibility Craft podcast, you’ll know that I’m a huge Diet Coke fan, but we, I just ran out, went up to the fridge, no Diet Coke. So, what’s the second best choice? Here’s your second best choice Diet Dr. Pepper.
William: I’ll just go for the full sugar option.
Steve: No, I can’t [00:02:00] drink sugary drinks anymore. They’re just too sweet and I feel like I’m killing something and all the aspartame.
William: Yeah, I don’t do the diet stuff. I’m just just full sugar.
Steve: You run on full sugar. Cherry. There you go.
William: Cherry Coke today.
Steve: Yeah. That’s interesting. That’s…
William: I tried the orange coke. That stuff’s horrible.
Steve: Orange coke?
William: Yeah.
Steve: I don’t think I’ve had orange coke. Is it like a…?
William: Don’t have it.
Steve: Don’t have it.
William: It was so bad.
Steve: Yeah. Cool. I have to see if it comes out somewhere. And try it or don’t try it, but yeah.
Here we are changelog episode number nine. First of the year 2026. We are talking today about quiet releases and important fixes.
We debated a little bit about what to talk about because we spent December you know what, a lot of people spend December in those quiet few [00:03:00] weeks before the holidays…
William: Hiding from their families.
Steve: Hiding from their families.
Cleaning things up, preparing for the new year, right?
If you’ve been listening to these changelogs for any period of time, over the last nine episodes, we’ve been releasing a lot of features. We spent the end of December doing a bug squash go at it and believe it or not no huge features released during that time.
But, this kind of maintenance work and these kind of bug fixes that kind of, bugs get logged and put in the backlog for whenever. And it is a feature to actually group those together and put them out because it makes the fixes, issues, edge case issues for certain people and makes the plugin just that more, much more solid.
So, what I plan on doing is just laundry listing some of those features, and that’s going through ’em and talking about ’em. And why we did that and why it’s important to the plugin [00:04:00] to spend time on those things.
In this changelog, if you haven’t joined us, we talk about the Equalize Digital Accessibility Checker WordPress plugin. It’s an automated accessibility scanning plugin to help your WordPress website become and stay accessible. It’s a whole platform. It’s a whole suite of plugins at this point. We have the Accessibility Checker free plugin, which you can get on our website or on WordPress.org for free. It’s very full featured. Our whole rule set is included in there.
And then we have a Pro Plugin that expands those features and gives you Full Site Scanning and unified global issues, tracking pages.
And then we have add-ons for that as well.
We have our Audit History Add-on to get historical data on your coverage over time.
We have a Multi-site Add-on to manage Accessibility Checker through a multi-site network.
And an Export Plugin to help you export your issues to CSV to do with what you would want to import those [00:05:00] into another system, a spreadsheet or whatnot. Cool.
The versions, the current versions of the two main plugins that we’re gonna talk about, which is Accessibility Checker and Accessibility Pro. If you have the latest, which Accessibility Checker Pro version 1.360, and Accessibility Checker Pro, version 1.190. If you’re looking for these features, make sure you’re updated on the most recent version of the plugins.
Like I said, not a flashy release cycle, but important nonetheless. And focusing on correcting these things just gives you users more trust in our product and it makes our product more reliable.
And let’s jump in.
Metrics and Scoring Accuracy. You wanna run through this first one, William?
William: Yeah. So let me just refresh myself about the exact specifics of this one. I feel like it [00:06:00] was forever ago.
Steve: Yeah. So let me give you a little pointer. I did link the give PRs.
William: I just clicked that…
Steve: to help us refresh our minds, yeah.
William: So actually I do remember this one now.
In this one so.. No Scan Posts is a State that the system can be in. So, if you have a brand new website and just installed this plugin. None of the Posts are gonna be scanned. That was, that is a legitimate state and it is not a state that was accounted for very well in previous iterations.
So, now what we are doing is we are checking for scannable Post Types, ’cause not all Post Types are gonna be scannable. You might have them disabled, you might have them. So you might have a post type enabled at one point and then disabled at another point. There could be dangling data for that, in which case some of the numbers might not be entirely accurate.
I can probably [00:07:00] showcase this maybe in my very broken dev site if you wanna…
Steve: Yeah. Gimme a screen. I’ll pop it up. Yeah.
William: Yeah, It will be this one.
Yeah. So, this is my messy test site. I literally just recently completed a scan on this and there is 43 URL scanned. But, if we were to count, so two of four post types. So if we were to count the posts and pages which are scanned, you would actually find out that I only have 41 in total, so two posts are dangling. And that is because previously I had the CPT enabled and I broke something that allowed these two issues, these two URLs to remain in the database, which is quite common while I’m developing things. So these numbers would never properly reflect ’cause the other [00:08:00] numbers are generated based on these URLs scanned and if I update to the latest version of the plugin in my local, this number will go down to 41, because this is not a scannable post type anymore. Previously. It wasn’t accounted for in this number, which was a cascade of issues or slight inaccuracies across some of these other numbers. So as far the URLs scanned, 21 with 100% score. But, realistically, this is actually only 19 with 100% score and which puts the average issue density 3.15 would probably be slightly higher. Yeah.
Steve: Yeah. Cool. It’s important. So you’re are, you’re talking about, you’ve jumped down to the second one with the density score.
William: I think they’re both
Steve: [00:09:00] One and the same.
William: The cascade.
Steve: Yeah.
William: And this, that’s being fixed by fixing the past the scan book post types.
Steve: Yeah. So, like with jumping back to the past test percentage, William said that no scan is actually a state, and this could be on the individual post as well, not just here globally. But, if there was no scan, this was showing 100% correct.
William: Correct. So, this would always be 100% if there was no failed tests, which is not accurate for a site that has never had to scan.
Steve: So now it’ll say zero or not applicable?
William: It says N/A.
Steve: Yeah.
William: Not applicable.
Steve: Not applicable.
So we did this and it’s important for, if a user installs the plugin and they have yet to scan anything, they may come here and go, oh, I don’t have any problems. They immediately just see that dashboard. ‘Cause it’s not 100% apparent that just installing alone [00:10:00] doesn’t run something.
William: That’s true. Yes.
Steve: There was a time where in the plugin we did actually did kick off a Full Site Scan on initial install all if you had the Pro plugin. But, we actually have moved away from that because I think that actually created more confusion than anything because it was something that was done without any action being taken.
This is just a small fix for us to ensure that state, that valid state of nothing being scanned is communicated correctly in our reports.
William: Yep.
Steve: On the density side so ignored issues and density score.
William: Yeah. So, I will point out, so for the past test percentage, fixing this issue did fix some other things, like I was saying. So, only scannable post types was not always what was being reflected here. In addition, this issue density was never taken into account how many items were ignored. [00:11:00] So, if you ignore all of these error and warnings, technically your issue density is zero. If you have none of these.
So let’s say it has 43 unique errors, 26 unique warnings, and three ignore items. If I ignore all of these, the density should be 0 and the average issues per page should also be 0. Because we have ignored the items effectively saying that they are not issues and that should not be reflected here.
Steve: Whereas before we weren’t properly considering that.
William: Correct. So this average issue density, and a number of these issues like URLs with 100% score, they were not accounting for when the issues were ignored. Because ignored is maybe a missed number because ignored doesn’t really mean you’re ignoring the issue. What ignored really means is not an issue. It isn’t unresolved. It [00:12:00] is. You have looked at it manually and you’ve decided it’s not an issue and thus it is a resolved problem. So it should go away in all of the metrics that you are accounting for.
Steve: Yeah. And this is something that we’re working on for new features coming out in this year is some cleanup around language. William said an important thing there about ignored items. And when it comes to remediating accessibility issues, ignoring is not necessarily a positive action.
Like we shouldn’t really be ignoring things. Our errors and warnings are really what they are. An error is something that we can, with a great sense of accuracy, say this is an issue programmatically, we can programmatically determine that this is an issue. And a warning is basically us prompting you to say, “Hey, we think this is an issue, but we need a human to validate that this is an issue.” And then on top of that’s when you would [00:13:00] use the ignore feature to, “okay, the Accessibility Checker plugins telling me this is a warning, or this needs some human review.” So, I reviewed it. It actually is fine. It’s a image is that doesn’t have alt text, but it’s decorative, so it shouldn’t have alt text. And then you can ignore it and you can maybe write a little message, say, “Hey, this is a decorative image.” And that essentially ignores the issue. But in essence what it is, you’re not ignoring it. You’ve actually remediated it. You’re actually saying this is not an issue. So we are working on some language changes to make that more clear when you’re doing your auditing and you’re remediating with Accessibility Checker.
William: Yeah. So I will just show people how the ignore works. So, if you’re on a single issue page, and this is an issue, and I will be clear, this legitimately is an issue, but for the sake of demoing, so we have these action icons in the right [00:14:00] hand side beside every single issue.
If you open it in the details panel and click ignore, and you can leave a comment here. So you can say, “Not an issue because…” And then you can describe exactly what it is.
Steve: Yeah.
William: Of reason you’re ignoring this issue form. Because as I said, you’re not ignoring it. You’ve verified this is okay. I’m not gonna click this button to confirm this because this legitimately is an issue on this page, but…
Steve: Right.
William: The demo, demo that.
Steve: Cool. So those are a couple of the improvements that we’ve made on those two things as in regards to reports and improving the accuracy of those Full Site Stats.
What are you doing now? So Williams adding an image to his editor, his favorite…
William: My favorite Thanksgiving GIF.
Steve: So this is a [00:15:00] GIF of a Thanksgiving Turkey that we actually used in some, we were creating a plugin to Pause Animated GIFs. And this is actually an animated GIF, right?
William: Yes, so this is right as an animated GIF, but this is a static image. It just has made a data that implies it is animated, and I could not figure out why.
Steve: Yeah. So William hates this image because of the trouble it took. But, it was a good edge case for us in testing animated GIFs, and when a GIF actually sends messages to us that it is a gif and when it’s not. So you’re adding an all…
William: Yeah. So this image and I saved the page, it came up with an empty alternative tag or empty alternative text. So I’ve added an alternative text that just says “An image.” We saved the page, and now this warning has changed, is now considered as a [00:16:00] low quality alternative text.
Steve: You’re jumping ahead too, so we can talk about that now since you’ve…
William: Yeah. I put this up. Yes. Previously this would not have been flagged, but this is clearly a low quality alternative text, and we have a series of words or phrases that we believe is considered as a low quality alternative text, like “an image,” “graphic bullet,” or “an image of,” and now this gets flagged as a proper warning to look at, because maybe your alternative text is an image. Maybe that’s literally an image that has text that says “an image.” That would be legitimate alternative text. But in most cases, it’s not gonna be.
Steve: Yeah. So this was an improvement to image has oh, sorry, what’s the name of the rule?
William: Image all invalid.
Steve: Image all invalid.
William: Or [00:17:00] low quality alternative text is the nice name.
Steve: Yeah. So we have a whole set of keywords that we check against. I have to bring it up to remember what they all are.
William: I have the list here. The list it’s essentially quite short, but the, if it starts with the phrase “graphic of,” “bullet,” “image of,” or “an image,” or if it ends with the word “image” or “graphic,” is the general checks. We additionally check for exact match keywords of things like “photograph, drawing, painting, artwork, logo,” and maybe 20 other specific phrases. But the term and image previously was not caught.
Steve: Yeah.
William: And I have seen this in the world many times. People put that as their alt text.
Steve: Yeah. ’cause when you’re remediating images that are missing alt text, sometimes there’s a pull [00:18:00] to ” Oh, it needs alt text. I just need to put something in there and then it’ll tell me it’s fine.” And really the quality and the context of what you put in that alt field is of vital importance.
Because if somebody’s, using a screen reader that you know that has visual impairment, they can’t see the image and they come across it and the screener says, “An image” like, how’s that have any value to the user?
William: Yeah. Because the screen reader would read out that it is encountered an image.
Steve: Right.
William: Already.
Steve: And in that case, it’s almost like you trying to say, you trying to check a box that it has an alt, it’s telling me it needs alt text. I put it in image, but you actually made it worse because even without alt text, it’s just a considered a decorative image and it just moves on. So you’re adding just completely false bad context to it. Whereas before it didn’t even get in their way. So why did we add this keyword? So this rule’s been around for many years [00:19:00] and this came in through a request from a user.
William: I think this must have came in from a request from a user, because I don’t think we would’ve thought to action on this out of nowhere.
This has to have been a user request.
See if I can try and find…
Steve: Yeah, I’m looking too.
William: The origin.
I actually believe this might just be a very old ticket.
Steve: Ticket
William: That we’ve had in the backlog that was not accounted for a very long time and finally we had time to tackle it.
Steve: So yeah, I have the PR open, but I’m having a hard time finding the issue ’cause it, it didn’t tag the issue on the PR . I’m pretty sure this has been open for quite some time. And that kind of goes back to the whole reasoning for doing this.
And I know that through this kind of bug squashing session we went through that there was a ticket that I think has been open for four years [00:20:00] or five years. It was like a really low issue number. And it’s funny how these things can sit in a backlog for so much time and why it underscores the importance of doing these types of bug squashes from time to time and creating that value.
Now from a development workflow standpoint, we try to keep our backlog fairly clean. We operate under the principle that if it’s super important, it’ll surface again or it’ll come up again. But, this one actually stuck around inside of GitHub for quite some time.
Okay. So that’s a small improvement, but I think it goes a long way to always refine these rules and make them smarter or better. And whenever we come across, somebody using it in another context, we add that ” An image.” I never would type that, but maybe
William: I’ve seen it.
Steve: Yeah.
William: Online people put this for whatever reason.
But yeah, improving the rules that already exist was a bit of a theme in [00:21:00] the last release we did.
The next item on our list is to do with improper uses of links. I’ve created this text link here, which contains the pound sign as it’s HREF value, which is an improper link. This ideally should be a button or it should have a real anchor point after the pound sign. So we refined this rule and there is some cases where this HREF no longer mirrors, and that is if you alter the role of this element. So if you want the role of this element to be a menu item with aria-expanded on it. So this could be a link that triggers a dropdown.
Steve: Yeah.
William: It’s the most commonplace I’ve seen this. So if we make it a rule of menu item and give it aria-expanded and receive this, [00:22:00] technically this improper link should go away. Okay. It did. So it’s just the one original improper use of link that I have. So this is no longer improper because this is a menu item that expands an element, and on a menu item, HREF is ignored by the screen reader or by any assistive technologies. Because when you use the role value on any element, it changes its semantic value. So to a screen reader, this is no longer an anchor text or a link, this is a menu item and potentially should appear inside of an ordered list or a menu or something else.
Steve: Yeah. This is a very interesting one, and oddly enough, this one is also three years old. But, it’s interesting because it is an extreme edge case. This was actually brought up to us on a WordPress.org support ticket many years ago. Three years ago to be exact. [00:23:00] And then Amber Hinds, our CEO had a kind of a discussion in our accessibility Facebook group about it, what people thought about the kind of edge case and the consensus was that yeah, adding the correct attributes here, role=”menuitem” aria has popup = true actually does make this a proper use of a link as far as a screen reader goes. And William was saying, we could take this a step further since we think this is an edge case. We could take this a step further and actually only validate links with these attributes inside of nav landmarks.
William: We could, however, the, you said Aria has pop-up, which may be preferable for a dropdown. This is aria-expanded, which I thought maybe a dropdown menu, but it’s probably quite useful for accordion, trigger [00:24:00] items.
Steve: You would, you’d probably want to have…
William: Ideally you would want a button, but you…
Steve: as far as attributes, you probably would want to have role=”menuitem” and aria has popup = true and in what certain context you would have aria-expanded=false. Did that pass with what you have there?
William: Yes. So this is what exactly we check aria-expanded=false. I do not believe we are explicitly checking aria has popup.
Steve: Yeah, maybe that’s fine.
William: That is aria has popup, right? There’s no space.
Steve: Yeah. Yeah. Correct. Equals true. Yeah. It would need to be true.
William: Oh, it looks like it doesn’t like that.
Steve: Huh?[00:25:00]
You’re running latest.
William: Yes. So the change we did made was explicitly for aria-expanded, not aria has popup, but that might be a cycle backing add.
Steve: Yeah, totally. We can definitely confirm that we have this logic correct. But we’re just, we’re trying to check edge cases more here and this is a valid use. Now, I would say it’s not a recommended use, but you can do it.
Cool. Anything else on that one?
William: Nope, I think that’s everything I’ve taken a note of whether we wanna investigate has popup as well. I think we probably do because this was a specific edge case we were adding affordances for. We probably didn’t consider the has popup edge case as well.
Steve: Yep.
William: No [00:26:00] harm at the same time tackling that.
Steve: Cool. Alright, so we did some UX and some quality of life fixes as well. Let’s run. We got a handful of these.
So highlighter controls are now translatable.
Earlier this year, if you saw an earlier changelog, you would’ve heard us talking about translations. And translations was something that we started taking very seriously last year with the. European Accessibility Act going into full force and seeing a lot more adoption in Europe and basically practicing what we preach making the plugin as accessible to as many people as possible. We started taking translations very important. But from a development standpoint, that can be daunting, right? Sure. If you have a mechanism to translate the plugin into 30, I don’t know, two or three languages like we have now, that’s great, [00:27:00] but your plugin actually has to be coded in a way to be translate to bulk.
William: Yes, and a thing that we found is that almost all of our PHP translated strings were already translated, but quite a number of our JavaScript strings, and not just quite a number of our JavaScript strings, quite a number of JavaScript strings in general are not properly wrapped in translation functions.
Steve: Yeah, tell everybody where you’re at.
William: Yeah. So I’ve changed the language of my test website into French and I’m now visiting the front end of my site. I’ve opened up the front-end highlighter and now we can see that each of the buttons in the front-end highlighter are now translated. Previously, the next and previous buttons were not translated.
Steve: It looks like your name is covering up that highlighter a little bit there.
William: Oh, let me, oh, I should have moved it to the other side. I can just delete my name, right? [00:28:00] That could work.
Steve: We have a setting in the settings where you can move where that the front-end highlighter floats on the page.
William: Yeah. But, unfortunately, I’ve changed this to French now, and I…
Steve: Let’s see if William, let’s see if William can change the setting when it’s set to French.
Is that it?
William: Is that one? I can’t read this, but I know that’s…
Steve: I can read that. Yeah.
William: So yeah, I’ve moved the front-end highlighter to the right hand side, and now we see that we have French on all of the buttons. I do see we have some over spill issues, this is to be tackled.
Steve: Ah, that’s good catch.
William: For this future.
Steve: Yeah, because strings become much longer based on…
William: In some cases.
Steve: Or shorter.
William: They change in size and we have a fixed amount of space available here. So if I go to that page, that actually has an issue on it. [00:29:00] So yeah, all of this is now translates as far as, most of these strings. I see that this “How to fix it,” string is not translated. I think that is because of where that comes from, but…
Steve: Yeah. so this is a technical thing, right? This is…
William: I think, so this is not that it hasn’t been translated. This is that we are grabbing it and injecting it in English rather than, yeah the correct translation.
Steve: But all these controls, so the update here was on the controls down here.
William: Yes.
Steve: And a customer did surface this for us. So if you’re a user of Accessibility Checker, contact our support if you see something that isn’t translated and we will fix it right away.
William: Yep. I almost like to fix an issue that a user really is experiencing and not just ones that have been sitting for a long time.
Steve: And users of different languages really are the best user testers than us. We [00:30:00] switch it to a language that we don’t understand and then we try to fumble around and find things.
And but yeah, so we’re just working to make sure, try to get everything inside the plugin as translated as humanly possible.
We did better help on links and tool tips. So, this is basically just, a housekeeping item of going through and making sure that our links to all of our documentation throughout the plugin, there’s lots of links to documentation for every rule. We have 40 some rules, and we actually just did, went through and did an audit to ensure that every one of those links were properly set to the right documentation. Over the years documentation pages can change. We run some redirects on those as well and ensuring that everything lines up. So we have some ID [00:31:00] matching that goes on. And through that audit we actually, we found one documentation link that was linking to the wrong piece of documentation so we fixed that.
And why do I mention that? Like I mention it just because this bug scrub really is a good point where we can go through and fine tune and go through and make sure that everything is working the way we intended to. ’cause sometimes when you’re in full feature release cycles, you can oversee these things. So it’s just another way that we’re ensuring that the plugin is always being maintained and updated and accurate.
All right. Fixes that unblock savings and settings. And also we bring this up too, to show that we’re human, that we have a plugin that’s very testable, but no piece of software is [00:32:00] immune to regressions in coding. A regression is typically when something is working and you change either something in regards to that or something else and your unit test doesn’t catch it and it actually breaks a little bit of functionality or the functionality regresses to a functional but not a perfect state to where it was.
Do you want to explain this one a little bit, William?
William: Yeah. So the specific thing we’re talking about here is the Scan Speed Sign. Previously, so the first item in this list is Fast, and Fast is the Default Option for this setting because it is first in the list. So I have this set to slow and if I reload this page, you will see that it remains on slow. If I change it to normal, scroll down and save, it reloads and it stays on normal.
The bug was that we were not outputting the stored [00:33:00] version from the database. So if I were to change this to slow, slowest, or normal and then save it, this is the speed that the scan will run at. However, when this page was load, the regression meant that it would always default to fast, and that doesn’t mean that it was saved as fast in the database unless you explicitly come down and save the changes this would store in the database the correct value until you make that change and save.
So this was a regression and there is unit tests to make sure that the stored value is correct after these have been saved. However, there is no end to end or integration test to make sure the UI displays the correct value. And as such, we never noticed because when I would test this, I would come in, I would change the scan speed, I would save, and then I would visit the full-site scanner and I would check that it is scanning at the selected speed. I didn’t always look to see whether it reloaded the page correctly and for a while it [00:34:00] wasn’t.
Steve: And the reason why that regressed is we were actually… The Free Accessibility Checker plugin and the Pro Accessibility Checker plugin integrate with each other quite a bit.
And you can think about the Free Accessibility Checker plugin as Core. It’s the Core plugin. And then The pro plugin extends the Core plugin with advanced features and as Accessibility Checker grows and becomes more full featured and does more things there are settings that really intertwine a lot and where the functionality of those settings happen. Whether , those settings are defined in the Pro Plugin or in the Free Core Plugin those have changed and they continue to change so that we can create more advanced functionality.
William: Yes. So this scan speed setting originally was created inside of the Pro Plugin. At a certain point it became, [00:35:00] it made sense to move this scan speed setting and some of the other settings over into the free plugin and for it to not be active when the pro plugin isn’t installed. And it was at that point that this regression was introduced because the key changed.
Steve: Yeah.
William: So like the Free key versus Pro key.
Steve: Yeah. So a little bit of insider info for developers out there. The prefix, right?
William: Yes, the prefix on the key change from edac, and we have another one for Pro, which is edac-p.
Steve: Yeah.
William: And the prefix change because of where this was moved to, but the setting option being a pro setting, it contains the P, which was not reflected in, just this setting. I believe all the other settings were fine.
Steve: Yep. Totally. So that was a interesting one and a short-lived one. I think that only,
William: it’s also one that user know and reported.
[00:36:00] So as we said earlier on, if you see anything, let us know and we will almost there only fix it within the next release in most cases.
Steve: Yeah. And like I said, this was a short-lived regression. I think it was only between one release, so…
William: I think it was a release and I think it was more like half of a release before it was reported and then it was fixed I think within three or four days.
Steve: Yep. Cool. Alright. That brings us to some Pro Plugin Stability things that we have implemented.
And the first one is Sorting Indicators Improved Usability. So this one actually, we have another PR in regards to these.
Yep. Looks like we lost William. He’ll be back in a second. Hold on.
William: Oh, I’m back.
Steve: [00:37:00] You’re back. There you are.
William: Okay. I don’t know what happened there, but maybe my kids are on Netflix again.
Steve: That’s right. Yeah. They’re using up all the bandwidth.
William: It still says I’m sharing though. Do you still have my screen?
Steve: No.
William: Let me see. I can stop and start again.
Steve: No. I’ve got it.. Oops. Let’s bring William’s screen back up. Alright.
Yeah. So we do have another PR open in regards to this that hasn’t gone out. That’s correct?
William: I have that PR here, I believe.
Steve: Okay.
William: You’re right. I don’t have that PR here.
Steve: Yeah. Yeah. I can see it’s not sorting correctly. Do you wanna switch to that?
William: I can pull that in. Yeah. If I can find…
Steve: I’ll switch back to our lovely faces here while William jumps into the code and pulls down a PR.
So, we added the ability to sort these columns and and that’s just good for accessibility. It’s good for people auditing to be able to filter the [00:38:00] table columns to the way that they see fit so that they can see what the most important rules to tackle are.
And then we actually have a little bit of a improvement to that we have in a open PR that we’ll go out in the next release here in probably next week.
As we listen to Williams mechanical keyboard
William: I swapped to quieter switches.
Yep. So I think I got that pulled down for the fix.
Steve: Yeah. Cool. Let me jump back. Lemme pull your screen back up. All right. Yeah.
William: So the thing that we were specifically going to call out is that previously you could sort these fields, but there was never an indicator beside them to show what the sort [00:39:00] is.
So, now for example, I can click this WCAG level failure and it shows the top arrow is highlighted to indicate that it’s sorted ascending. And if I click it again, sort descending. And that’s true for all of these items.
Steve: Yeah. And so what we’ve done is we’re giving you a visual indicator of the sorting order, and I believe we were doing some screen reader work too, to make sure that announces to the screen reader the correct direction as well.
William: Yes, there is a label here that says sort descending, sort ascending as it changes.
Steve: Yep.
William: Yeah, previously you could sort by these, but there was not an indicator that visually showed people…
Steve: Yeah.
William: …order.
Steve: Yeah. So in a earlier release like towards the middle of last year we updated this Open Issues [00:40:00] Page with some additional items, severity and WCAG level.
And if you’re here, William, you might wanna open the screen options.
Is that on this page or the next page?
No, it’s not on this page. It’s on the next page.
We added severity and WCAG level and with that we had to update our sorting to prioritize severity and then issue count. Whereas before I think we were prioritizing like the type and then the count.
William: Yeah. Error first, and then warning.
Steve: Yeah. And it did have sort functionality. But now what we’ve done is we’re doing what everybody’s doing. We’re trying to improve our own accessibility and we never considering it done.
William: There’s always improvements that can be found and made for certain people,
Steve: Right. And we didn’t wanna hold the feature up to get it out, but we wanted to ensure that we can visually show that sorting direction.
So if William jumps through to [00:41:00] a rule here on, he goes from the open issues landing page to an individual issue rule, you can see we are surfacing, seeing a lot more information here as well with the severity and why it fails and why it matters and how to fix it. Where you previously only got a little bit of this in the front-end highlighter and then you would have to click over to our documentation
William: You can also click to the documentation to get to the article. So if I click this documentation, we have a very thorough in depth article on how about exactly what this issue is, how to fix this issue and why you might wanna what the impact on accessibility is.
Steve: Yeah, totally. But in the screen options, and the reason why I’m bringing up the screen options here, is because nobody uses these. I don’t think, is this the correct location for the screen options?
William: I only see the number of items on this one. What is it you’re looking for?
Steve: I thought we surfaced an explanation of severity [00:42:00] somewhere.
William: Oh, it is in the Help Tab.
Steve: Oh, it’s in the Help Tab. Okay. Yeah. See, this is why I bring it up because even I, as a 20 plus year user of WordPress rarely click on this Help Tab.
William: No, I don’t think very many people click on the Help Tab, but it is the exact explanations for the severity and the types exist in the top level help…
Steve: Right.
William: Dropdown.
Steve: And there are links clicking off to…
William: Yes.
Steve: Also to some documentation as well.
If you jump back to the Landing Open Issues page, I think it’s there too, isn’t it?
William: Oh, maybe, yeah.
Steve: You just have to click on help. It’s under Help. So we’re trying to get,
William: So this details the Types here. So understand the Issue Types. So we have Errors and we have Warnings. And Errors are something we’re certain are a problem and Warnings are something we might not be certain and we really need you to manually take a look at what we’re flagging. [00:43:00] And now such context exists here to explain that to users, which I think previously some users were confused by.
Steve: Cool. Alright, so the next one’s a this one’s an interesting one and I think I worked on this and it’s UTC times to give more accurate time reports on ignoring items.
So we had been using server time. Is that correct, William?
William: Yes. Almost always. We just grab time from the server, whatever the server has available, which it’s sometimes UTC sometimes it is almost always based on where the server’s located in the world.
Steve: Right.
William: Which may not necessarily be where your website is host like is used.
Steve: Right? So we just wanted to bring some more accuracy to the ignore dates when those dates get logged and that [00:44:00] they actually follow the time zone that you have selected inside of WordPress.
William: So I’ve ignored the end of… I don’t know what page it was on.
Steve: This is easier if you do it on a single page. You’d have to jump over to the ignore log to then see it.
William: Yeah I don’t have a great many.
Steve: Do you remember which one it was?
William: I do not know exactly which one.
Steve: Yeah, just go to an individual post page.
William: Oh, the issue doesn’t exist anymore on this page. As soon as it re-scanned. Yeah. I’ll find an issue. Sure. Probably. So on this one,[00:45:00]
if I were to just ignore this issue.
So I’ve clicked the ignore action. I’ve typed the message in the comment box that appears, and then I’ve clicked the ignore action button, and now we have some metadata. So it says the username, which is role check, which is the username on this website I have. And the date, which January 15th, 2026 at 7:56 PM, which is my time. Which is what? Which is UTC
Steve: UTC one, right?
William: UTC one in Summertime.
So this is actual UTC time for me. 7:56 PM
Steve: So if you go to your settings and change your time zone now. Leave that post open.
So he is going to settings on the dashboard. He’s gonna change it from [00:46:00] UTC to
William: What’s yours? Plus five? Something….
Steve: Five or six I think
William: I’ll set that to five.
And if I just reload this page…
Steve: It’s ignored. Go down. Oh it’s ignored. It gets filtered under, yeah, there you go.
William: It’s open, ignore, and now it says 12:56 PM on the 16th. So in plus five hours is tomorrow.
Steve: So yeah, that’s definitely not my UTC.
William: Oh UTC minus five.
Steve: Hold on. It’s New York UTC. I’m not good with UTC and so
William: I went the wrong direction.
Steve: Yeah.
William: I went forward instead backwards.
Your time is minus five.
Steve: Yeah.
William: Yeah, as you see the server [00:47:00] time it’s stored in UTC time, which means whatever time your site is set to the offset is properly attribute.
Steve: So this is just another small fix that just is us trying to make things more accurate and make more sense to you.
And where this comes in handy is if… we’re looking at expanding the features of Accessibility Checker to where it’s more conducive for teams to work on, right?
And as you can see, William and I, we live on opposite sides of the planet. I’m in America and he’s in Europe and our times zones are quite different. And if we’re auditing and and remediating a website and putting ignores in, it’s nice if the time reflects where we are, if he puts it in at seven or eight o’clock his time now, and that I see it as three o’clock my time.
William: Yes. And that is what you would expect, really.
Steve: Yeah.
William: You would expect to see the actual time in your local zone, [00:48:00] or not necessarily your local zone, but whatever the website is set to it should be normalized.
Steve: Yeah. So just another tweak to bring in some stability there.
So another stability thing, William, and I don’t know how much you wanna talk about this, but we improved the SSS verification of our API endpoint in the Pro plugin.
William: Yes. And not just for this one Pro plugin, but across all of the suite of our add-ons that we were not necessarily verifying the SSL certificates, which I believe was the way the source code was delivered from EDD.
Steve: Yep.
William: And we never made any changes to it, but it turns out that we were not verifying the certificates that were being sent.
So it, in a very unlikely situation where someone was clever enough to men in the middle and provide a fake SSL, it wouldn’t have been caught. Whereas now it will be caught. We will [00:49:00] not make the connection if the SSL certificate does not validate. And there is a filter if you’re working in local development or working on sites that are on intranet that doesn’t have an SSL certificate, you can turn that filter back off. Or you can use, if it were to turn the verification back off if you want. But by default it should have been on in the first place, and now it is.
Steve: Awesome. So Security Improvements bring more stability as well.
All right. The last one here License Messages Clearer by Role Capability. So that’s a weird way to write it, but explain that to us in plain English.
William: Yeah, so I almost pulled up my license key and showed it. I can’t do that.
But yeah, some users, so if there is not a license key on this website, then there will be a notice. And I let me pull this to my other screen and just remove my license key and I will show you the license [00:50:00] key issue.
Yeah, I’ve deactivated the license.
Steve: All right, let me pull your… I don’t have your screen up. Do you want me to pull it up?
William: I pulled it a different page. Yeah, you can pull it up. I use the different screen for
Steve: Alright.
William: Here. You can see this error message here that says, “Accessibility Checker is installed, but requires an active license key to function, please enter your license key.” And if I click on that link, it takes me into the license page. So, I have managed options because I’m a full admin on this test site. But what if you didn’t, if you were a content editor, you would still see a message, but you would not know… it wouldn’t direct you to enter your license key. It would direct you to asking admin to install it.
Steve: So it actually will flip and say something else for non-admins.
William: Or anyone that doesn’t have…
Steve: The capability.
William: Manage options capability, [00:51:00]
Steve: Yeah. So do you have a user you can switch to show that or…?
William: I don’t on this test site.
Steve: Okay.
William: So I’m gonna just find what the message is.
Or do you know what the message is?
Steve: It’s something about contact your site administrator to have them update the license.
So this is just another step and, one, only showing messages to who they actually apply to. And two, giving context to somebody that may want to use the plugin but doesn’t have the capability to add the key.
And this is all kind of future looking things to bring Accessibility Checker into a more of a full auditing tool that a full team may be using and to start separating out different capabilities or building in custom user capabilities into Accessibility Checker.
Okay.
So cool. That’s our [00:52:00] list.
William: We’re at the end.
Steve: …of bug squashes that William and I worked through over the December month. And these are ongoing things, but we decided to group a bunch and do a big push there with, where you don’t have a lot of time to like really get into big features.
And we spent a good portion of December actually planning what we’re doing in 2026 for accessibility and the features and the roadmap that we will be working through. And we’re excited to share some of that, those things with you when they become available.
We have already dived in and Williams’s been working over the last couple weeks on some new features and new things that we have coming your way.
William: Yeah, I think the first UI improvement might drop before our next changelog. So they will either get to see that in the actual plugin or we will demo it.
Steve: Yeah. Yeah. So that’d be an exciting. So look for that here in [00:53:00] two weeks. We have this live stream every what is it? We, second and fourth?
It used to be every two weeks, but I think it is now gonna be every second and fourth. Yeah, we’re off a little bit for this January, because actually the first the first Thursday in January was January 1st, which it, that would’ve been, we were not in the office.
William: There’s five Thursdays. Five Thursdays this month.
Steve: So we’re trying to have two of these a month so that we can go through and show you what’s new and demo what’s new inside the plugin. Thank you for joining us.
If you use Accessibility Checker, we would kindly ask that you go to WordPress.org and give us a glowing five star review on how useful you find the plugin to be.
William: And if you don’t think it’s a five star review, send us an email.
Steve: Yeah. Send us an email and whatever grievance that you have, we will work to make that four star or four [00:54:00] and a half star, a five star. And we’ll be happy to help out in any way we can.
You can reach out to us on X and we have a Facebook group that you can join. And we look forward to talking to you there.
And if you haven’t tried out Accessibility Checker, I employ you to go to EqualizeDigital.com/Accessibility Checker and download the plugin for free and give it a try. And let us know if you have any feedback.
So thanks for joining us. We’ll catch you here again in a couple weeks. Bye.
William: See ya.
Metrics & Scoring Accuracy
Passed Tests Percentage When Nothing Has Been Scanned Yet
One of the biggest improvements in this release cycle was the correction to how we handle sites that haven’t been scanned yet.
Previously, if a site had no scanned posts, the dashboard could display a 100% passed test score. This reflected the absence of failed tests, rather than the presence of completed scans.
We fixed this by recognizing when no posts have been scanned yet and handling that case explicitly.
Now:
- If nothing has been scanned yet, the passed tests percentage displays as N/A.
- This prevents a brand-new site from appearing as though it has already passed accessibility checks.
This is especially important for new installs, where users often land on the dashboard first and expect the data to reflect reality.
Accuracy matters more than pretty numbers.
Scannable Post Types and Cascading Accuracy
We also corrected how scannable post types are counted in metrics.
During the livestream, we demoed scenarios where:
- Custom post types had been enabled and later disabled.
- Old scan data remained in the database.
- The dashboard showed more scanned URLs than actually existed.
Including those extra URLs affected metrics such as URLs with 100% scores and average issue density.
We now:
- Only count currently scannable post types.
- Exclude dangling or disabled content from totals.
- Prevent cascaded inaccuracies across reports.
This ensures the dashboard reflects the content currently being scanned.
Density Scores & Ignored Issues
Issue density is intended as a signal, not a penalty.
Previously, density scores and averages included ignored issues, which didn’t reflect how ignored items are intended to be treated in Accessibility Checker.
As a result, ignored issues are now handled as follows:
- Ignored issues are no longer included in density calculations.
- Average issues per page properly drop when issues are reviewed and ignored.
- URLs with 100% scores update accurately once issues are resolved or dismissed.
Ignored Does Not Mean Unresolved
During the livestream, we spent time clarifying what “ignored” really means.
Ignoring an issue doesn’t mean it’s being overlooked. It means:
- A human reviewed it.
- Determined that it is not actually an accessibility issue.
- Documented the reason with a comment.
From a reporting standpoint, the issue is treated as resolved and reflected accordingly in metrics.
Rule Improvements & False Positives
Low-Quality Alt Text: Catching “An Image”
We improved the Low-quality Alternative Text rule to catch cases where alt text technically exists but provides no meaningful information.
During the demo, we showed an image with alt text set to “An image.” This previously passed checks, but provides little useful information. Screen readers already announce images, so this kind of alt text doesn’t add helpful context for users.
We now identify this as low-quality alternative text and surface it for review.
What we check for includes:
- Phrases like “an image,” “image of,” and “graphic of.”
- Alt text ending with “image” or “graphic.”
- Exact matches like “photo,” “drawing,” “artwork,” or “logo.”
We’re not evaluating how descriptive the alt text is, only flagging clear cases where it provides little context. In rare cases, the text may still be appropriate, which is why this remains a warning for human review.
This is a good example of using automation to highlight clear issues while leaving final judgment to an auditor.
role="menuitem" with aria-expanded: Avoiding False Positives
Another long-standing edge case we addressed involved links with href="#".
Normally, this is flagged as an Improper Use of Link. However, during the livestream, we demoed a scenario where:
- The link uses
role="menuitem". - It includes
aria-expanded. - It functions as a dropdown trigger.
In this context, the element is no longer treated as a link by assistive technologies; it’s a menu item. The href is ignored, and the previous warning became a false positive.
We updated the rule to account for this real-world markup pattern.
This reflects a broader principle:
- Real-world WordPress sites don’t always match ideal spec examples.
- Being more accurate sometimes means loosening rules.
- Avoiding false positives builds trust.
UX & Quality-of-Life Fixes
Highlighter Controls Have Expanded Translation Support
We continued improving translations across the plugin, building on our recent expansion to 32 languages and focusing this time on JavaScript strings.
In the livestream, we switched a test site to French and demoed the front-end highlighter:
- Navigation buttons are now translated.
- Labels reflect the site’s language setting.
- Previously untranslated UI controls are now localized.
This work supports broader adoption in multilingual contexts and reflects the growing importance of accessible tooling, particularly as accessibility regulations continue to expand in Europe.
Better Help Links in Tooltips
We audited in-plugin help links and supporting documentation throughout the plugin and fixed cases where:
- Links pointed to outdated pages.
- Redirects were relied on unintentionally.
- Tooltips referenced incorrect documentation.
These are small fixes, but they help ensure in-context guidance remains clear and reliable when reviewing issues and remediation steps.
Improvements to Saving and Settings
We updated how the scan speed setting is displayed after saving to ensure it reflects the selected option.
What changed:
- The selected scan speed now remains visible after saving.
- Settings display consistently when the page reloads.
This update ensures the scan speed setting accurately reflects the option you’ve chosen.
Pro Plugin Stability Improvements
Sorting Indicators Improve Usability
We improved table sorting in the Pro plugin by adding:
- Clear visual indicators for ascending/descending order
- Screen reader announcements reflecting sort direction
This enhances usability for auditors who rely on sorting to prioritize issues by severity or WCAG level.
UTC Times for Consistent Reporting
We updated how timestamps are stored and displayed for ignored issues.
Now:
- Ignore actions are stored in UTC.
- Displayed times reflect the WordPress site’s time zone setting.
During the demo, we changed the site’s time zone and showed how the ignore timestamp adjusted accordingly. This is especially helpful for distributed teams working across regions.
SSL Verification for API Requests
We standardized SSL certificate verification for license and API requests across Pro and add-on plugins.
As part of this update:
- API requests now verify SSL certificates by default.
- Secure connections are consistently enforced across environments.
- Filters remain available for local or intranet development setups where certificate verification may not be applicable.
This is a behind-the-scenes improvement that strengthens baseline security without changing normal usage.
License Messages Clearer by Role & Capability
We refined license-related admin notices to better match user roles.
Now:
- Administrators see messages prompting them to enter or fix license keys.
- Non-admins see guidance to contact a site administrator instead.
This avoids confusion for editors and contributors who don’t have permission to manage licenses.
Wrap-Up: Maintenance Is a Feature
This release cycle focused on strengthening the foundation of Accessibility Checker to support accurate, reliable reporting over time. These updates help ensure the plugin:
- Delivers clear and consistent accessibility data
- Reflects real-world content and configurations accurately
- Handles edge cases thoughtfully and predictably
- Scales well for teams and long-term accessibility efforts
Careful, ongoing refinement is what keeps accessibility tooling reliable as sites, teams, and requirements evolve.
We’ll be back with new features soon.
If you’re using Accessibility Checker and have feedback or questions, you can reach out to our support team.
Join Us for the Next Livestream
The Accessibility Checker Changelog livestream airs on the second and fourth Thursdays of the month, alternating with our plugin release schedule. Each episode will feature demos, technical deep dives, and previews of new features. Follow us on YouTube to get notified when we go live.
To learn more, 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.
