Changelog 008: 2025 Year in Review

Introduction and Year-End Reflections

Steve: All right. We are live.

William: Hey! 

Steve: How’s it going, William? 

William: Yeah, it’s going good. 

Steve: Let’s… 

William: Last one of the year. 

Steve: Last one of the year. We made it.

Alright. 

Going Live and Year in Review

Steve: Looks like we are live on YouTube.

Check out X and see if we’re live there as well.

And it looks like we are live. Alright, I’m gonna repost this.

We’re live today. We are talking about the year in review. We made it, William. It’s December. How do you feel? 

William: Tired. 

Steve: Tired? 

William: It’s been a long year. 

Steve: Long year of feature updates on the Accessibility Checker. 

William: Yeah. Feature [00:01:00] updates and a bunch of other things. Yeah. Non Accessibility Checker things, non… 

Steve: Life, raising children.

William: Yeah. Just pretend that doesn’t happen. That’s probably the hardest part of everyone’s life. 

Steve: Yeah. Yeah. Cool. 

It looks like everything’s going out, yeah.

Welcome to the live stream if anybody’s joining or watching after the fact we appreciate it. We are going to take a little bit of a look back.

It’s like those old sitcoms, right? Where they would have that episode. That was like the flashback episode, right? 

William: The filler episode.

Steve: Yeah. The filler episode. Don’t call us out. It’s not a filler episode. This episode is going to be packed with all kinds of helpful information about Accessibility Checker and what we did this year and the struggles a little bit of the how the sausage is made for the year.

But yeah, so this is gonna be our flashback episode. Our greatest hits of the year.

We’re glad that you’re joining. If [00:02:00] you’re not aware we have this, livestream every couple weeks, and we talk about new features and thing upcoming features and changes to the Accessibility Checker.

This is intended to be a little bit of a technical deep dive, but also a little bit of a informative livestream for users of Accessibility Checker or potential users of Accessibility Checker.

Accessibility Checker is a WordPress plugin that is an automated accessibility scanner to help you identify accessibility issues on your website and fix those accessibility issues.

What do you think, William? 

Major Updates and New Plugins

Steve: We jump right into the year in review. So I, 

William: Yeah. 

Steve: I thought we would start with kind of the big hitters, right? Like some of the major things we did this year, so it wasn’t just fixing bugs, squashing bugs, and creating new features in Accessibility Checker.

We actually released two [00:03:00] new plugins this year.

Do you wanna talk about the first one? 

William: Yeah. 

Multi-Site Plugin Overview

William: The first plugin we released this year was the Multi-Site Plugin. It allows users to basically have full control over how their licenses get applied across a network.

Some users might have five site license, but a network that contains seven sites, they get to prioritize which site get those license. When I say five sites, that might not be, that might not be so troublesome to visit each site individually and apply your license, but when we’re talking about license sizes that reach 50 licenses. People are not gonna wanna manually go to all of those sites. So, primary reason for this plugin is management of the licenses.

As a site benefit, all the things that are required to rig up to manage licenses also allows you to see all of the errors and warnings across the entire network as well. So, in addition to managing your licenses, you can also see the current [00:04:00] stats of all of these sites in the network. You don’t need to have the license activated on all of these sites to get stats.

Obviously, we have the free plugin that runs completely without a license and has full scan all the same rules all built in. So, all of the site stats will be available to see in this plugin, in addition to managing the license.

And while you’re managing the license, you’re also… if you have the professional single site license, you get the plugin, the pro plugin, but on higher tiers you get access to some of these add-ons. And we, again, all the things that were required to be rigged up to manage the licenses meant that we could also manage all of these add-ons all from this one single pitch.

Steve: Yeah. And that is a great explanation. Also, Settings. Did you mention Settings about…? 

William: I did not mention Settings.

So, why would you configure 50 different [00:05:00] sites when you can just come here, configure one, and then close your settings across all of them? 

Steve: Yeah. Yeah. 

William: So this is probably… I haven’t actually used this feature myself.

I think this probably saved a few people many hours of time. 

Steve: Yeah.

So, you can basically, you can choose a Network Default Site, any Site on your WordPress Multi-site as the Default. We have a dropdown to choose which Site, and then you can select the other Sites, and then you can choose “Copy settings from the default site,” and you Apply that.

It’s actually going to set, take all the Settings, take the Settings from that one Master Site and copy it to all the other subsites.

Yeah, so this is a very awesome plugin for people managing large networks for agencies. This is an Add-on plugin to that to the Agency Customer level plan for Accessibility Checker.

William: So, users with [00:06:00] 20 licenses?

Steve: Yeah. So… 

William: You’re not gonna wanna visit 20 individuals in a network. 

Steve: And, a little bit of a teaser for things to come. We have had some internal talks about bringing some of this being able to export and import settings to the Accessibility Checker Pro Plugin for people that are setting up large networks of Sites that are not inside of a Multi-site install. So, trying to bring that feature to our Premium Pro Plugin as well.

Cool. So that’s multi-site. Anything else on that? 

William: I don’t think so. I think this covers all the features. It doesn’t have a lot of features of its own. It just takes advantage of the features of all of the Individual Network Sites.

Steve: Yeah. Yeah. Totally. 

We released this plugin early in the year. We actually started it… I think late last year. And then, of course, we went through development and by the time we got everything ready to launch, it was the new year. I think we launched this in January. [00:07:00] 

William: Wow. That long ago. 

Steve: Yeah. So, any of our current Agency License holders if you haven’t tried it and you’re running a Multi-site give it a try.

Archive WP Plugin Introduction

Steve: So, the next big feature, and so we mentioned this in our last live stream, so we’re just touch on it here and not go too deep, but the the next plugin we released is actually not an Accessibility Checker Add-on. Sure, it’s complimentary to Accessibility Checker because it’s accessibility adjacent.

Is the ArchiveWP plugin, this is a premium only. Standalone plugin that doesn’t require Accessibility Checker. It is a plugin to help you manage outdated content while maintaining accessibility compliance.

Has a lot of features in it, like where you can take your Post and migrate ’em to a Custom Post Type called Archived Content, and it’ll store all the Metadata, it’ll migrate the Terms to a new Taxonomy [00:08:00] so that you can have Front-End views to filter those. It’ll automatically assign 301 redirects.

You can, you can revert these changes as well. If you migrate a Post and you realize that “Oh, I shouldn’t have done that,” you could actually restore that to its original location. And by location, I mean it’s original Custom Post Type and its Taxonomies will be restored to their original location as long as those Taxonomies still exist.

But, not only is it utilitarian in that way that it gives you this tool to migrate between these Custom Post Types. It also comes with a full set of Blocks and Patterns to help you create the Front-End page.

We have three Blocks in there.

There’s a Disclaimer, so this is for accessibility compliance, labeling your content as Archived Content. And, just a little side note on that, and the reason why you would want to archive content from an accessibility standpoint is a lot of laws and regulations around [00:09:00] accessibility will allow for an exclusion of Archived Content. So, if you label content as Archived and you don’t update it after that fact that it can be considered Archived Content and it may be excluded from certain accessibility requirements.

So, we’ve got these blocks. We’ve got a Disclaimer Block in there. We’ve got a Filters Block, which holds all the Filters. You can Filter by the Custom Post Type, you can Filter by the original Custom Post Type, you can Filter by the Migrated Terms and you can Filter by a Search, Keyword Search.

And then, there’s a third Block which is actually the Loop output, which is a dynamic, Dynamically Loaded Content that loads your Loop and it loads it real fast and it refreshes without a page refresh.

And then, we’ve taken those blocks and we’ve given you a couple Patterns as well, so that you can apply this directly to a Page with just one click of a Button. You’ve got this Pattern for a Left Align Layout or a Right Align [00:10:00] Layout. Actually, we removed the Right Align Layout, sorry. The Left Align Layout and the Center Alignt Layout because it really doesn’t make sense to put Filters on the right hand side and it causes some weird flow issues for responses. 

William: Yeah. Tab index issues. 

Steve: Yeah, totally.

The ArchiveWP Plugin is a Full Featured Plugin to help you manage Archived Content, and we worked really hard on this in October. William and I were just are getting carpal tunnel from all the typing or all the prompting.

William: I think you did an awful lot of prompting on this one. Yeah. By the day I came in, I had to clean up some of that prompt work. 

Steve: That’s an interesting take, right? So we’ve… The history of Accessibility Checker is that, Accessibility Checker is getting ready to turn five years old.

So next year Accessibility Checker will go to Kindergarten.

Five years ago, AI was not part of our development workflows. Not at all. It, [00:11:00] it didn’t exist. Open AI may have just been a recently founded company at that time. We used to write every line of code by hand. And nowadays, we’ve got a lot of AI implemented in our workflows, and I think the ArchiveWP was probably the first big plugin that we tried to implement that to its fullest without going down the road of Vibe Coding, which you’re not gonna, you’re never gonna get to, 

William: I don’t see people making viable products…

Steve: No. Yeah. 

William: With Vibe Coding .Maybe next year. 

Steve: Yeah. Yeah. So we call it, what do we call it? We call it Pain Prompting, is that what we call it? 

William: I think it was a bit painful sometimes. Although, to be fair, the AI, there were a lot of things that might have been quite complicated for a human. 

Steve: Yeah. 

William: In this plugin. And it did require cleanup. I don’t think the AI is quite at the point where it rates fully production ready yet. Someone is still gonna have to [00:12:00] follow behind. 

Steve: Where it’s interesting, like with the ArchiveWP Plugin, how the AI would lead to discovery in some sense, where you would ask, you’d use the ask feature to ask questions about, should this redirect? Or it would come up with kind of, it would come up with ideas and you’re like, you know what, that might be an interesting feature to add to the plugin. So, in some sense it’s good for discovery of features when you’re massaging a plugin like ArchiveWP into its final state, because that was one thing that kind of I found interesting about ArchiveWP was the initial idea of it.

And, a little bit of background on that is that this was actually a plugin that we created for a customer, for one of our remediation customers that needed something similar. And, we had the idea, other clients are gonna need this. We have more clients that need this, and why don’t we make it so that it’s something that can be utilized across many websites. And as any developer knows, making something [00:13:00] for one website and making something for all websites is quite the fee. 

William: It’s quite a lot of additional work to make it work across websites. 

Steve: So, the original version, used like Shortcodes to output stuff and was very opinionated on its design and layout.

Whereas ArchiveWP is very non opinionated on the design and layout.

Now, we’ve… 

William: I will step in actually here and say that while the original implementation of this on the client website was based on Shortcodes, and we have built this plugin based on Blocks, Shortcodes are still available and they’re fully equivalent to the Blocks.

So, if you have a website that does not use the Block Editor or a Custom Post Type that is not yet Block enabled, you are still able to use these Blocks wherever you choose just by implementing the Shortcode, and secretly you might discover there’s some additional features of those Shortcodes that weren’t exposed to the Blocks.

Steve: Yeah. 

William: If someone wants to [00:14:00] do some digging in. 

Steve: Yeah. Yeah.

There’s a lot of attributes under the hood, and that’s what William’s trying to say.

Yeah. And ArchiveWP does have a Onboarding Wizard that will actually help you build this Page. It’ll create the Page if you haven’t created it, or it’ll let you choose an existing Page and they’ll actually implement the Block Patterns or the Shortcodes with a tiny bit of HTML markup to get some layout into a Classic Editor Page.

What we’ve tried to do with ArchiveWP, is we’ve tried to make this process as easy and seamless for the end user to… one, get the Plugin installed, to get a Page created and to archive their content. Literally within a few clicks, you can have all your content archived into its own Custom Post Type, isolated from all the other Custom Post Types with disclaimers for accessibility compliance. And, it took a lot of work to get from that initial piece that we [00:15:00] made for the client to a fully functional Premium Plugin.

So, it looks like we have Daniel on the live stream. Oh, Hi Daniel. And Daniel says, “Thank you for all the improvements this year.”

Our pleasure Daniel.

William: I was on a call with Daniel a couple of weeks ago debugging a thing, so it’s nice to see people 

Steve: Oh, awesome.

William: People coming in. 

Steve: Cool. 

William: So if you find more problems, just reach out. 

Steve: Yeah, we’re here to help ,Daniel. Thanks for joining us and look forward to a lot more next year.

We are in the planning phases of features and new things for Accessibility Checker for next year.

Cool. Those are the major releases. Two new plugins this year.

But, we didn’t neglect our existing plugins and we have done a lot on that side.

This next feature, I don’t know if feature is the right word, but this next, area [00:16:00] that we implemented throughout all the plugins. It was huge. And, if I’m being a little honest William and I were a little apprehensive to undertake this because we knew it was going to be quite the undertaking.

William: This was a lot more effort than expected and also exposed some interesting things for me about the way WordPress handles this under the hood.

This is was my first deep dive into this in a very long time. 

Steve: Yeah. Yeah.

So, do you wanna say what it is, William? 

William: Yeah. 

Internationalization and Translations

William: We fully, we tackled internationalization of our plugins this year, so we have made them fully translatable as far as we could.

If you find anything that’s missing translation functions, let us know. But, we’re quite confident we’ve caught everything at this point. We translated the plugins, our entire suite into [00:17:00] theory plus languages, at least theory too, but some plugins have a couple more. 

Steve: Yeah. So what does that mean? Why would we do this?

William: Accessibility of content is not necessarily just about how the content behaves in the browser. Sometimes, it’s inaccessible for someone because they don’t speak English and that, is a problem for, but more than half of the world does not speak English. And now our plugin is available to a lot more people who will now be able to take advantage of these features and the users of our plugin becomes more accessible due to the translations and the users of those people’s website become more accessible due to the fixes that we provide or help these site owners do. So, it’s partly about reaching more people. But, it also is just, it’s just the right thing to do, actually. 

Steve: Yeah. Yeah.

Basically translations and internationalization is accessibility. [00:18:00] And it really is.

It actually is taking the Accessibility Checker and then making it available for more people and in doing so, and it goes to show sometimes your own apprehension or, dare I even say, our own biases when you say we don’t need to do that, or that’ll take so much time, it’s not worth the time or something, and you don’t think it’s really gonna have a benefit.

To our surprise, we think it has had quite the benefit in our install counts from different countries. Germany being probably the top country that we’ve seen the most adoption from after implementing this internationalization.

Now, there’s some, that coincides with a lot of the European Accessibility Act coming into place and Europe having, not Europe Germany having, probably some of the more stricter requirements. 

William: I think they’re definitely a first to implement type country where they lead the way in a lot of these things. In addition to Germany, though, have noticed an awful lot more Asian [00:19:00] users 

Steve: Yeah. 

William: Coming in and, identified by the fact that I can’t read their names sometimes.

Steve: Yeah. 

William: Coming in Korean, Japanese. So a lot more people in languages that I would not have expected. These are countries that might not have the same regulations in the way that Germany does. 

Steve: Yeah. 

William: But, these are still using our plugin and may maybe they would have if we hadn’t translated it, or maybe they wouldn’t.

We’ll never know because we now offer these translations.

Steve: Yeah. Yeah. I think it was great. And I think it’s a little bit of us practicing what we preach and we implemented this just before our team went to WordCamp Europe and so that we could… us as an American company flying over to Europe saying, “Hey, we’re here to support you as the European Accessibility Act comes into place.” It was on us to practice what we preach a little bit, if we’re gonna support these European countries and other countries, Asian countries [00:20:00] throughout the world, that we should make this plugin readable to everybody and I think it was probably one of the best things we did this year.

William: And it, it definitely has. It was worth the time. 

Steve: Yeah. 

William: Can’t said that about every feature that we took tried. In hindsight is great. In hindsight, we were mistaken to put this off for so long. 

Steve: Yeah, I think so. From a technical perspective, how do you translate the plugin into that many languages?

William: Before we say how we get into translating it for so many languages, let’s just maybe talk a bit about how translations in WordPress works, because this is the first time I have undertaken a large translation project in WordPress since the more common, I wanna say commonization, I don’t think that’s a word, but it’s the closest that I can get to strings inside JavaScript files far more common now than it would’ve been just five [00:21:00] or six years ago. And PHP, we have well understood translation functions. We use the double underscore type functions and it does static analysis using “get-text” so it finds the translations, it converts it into a pop file. Translators can take the pop file, they can generate individuals for their each language. So a static analysis.

However, when you have JavaScript in your plugin, quite often you use magnification or amplification of the JavaScript code because we always wanna deliver the smallest packages possible to the client. And, when that code has been magnified or amplified is really quite difficult to discover where those strings are inside of the content. And this was a challenge I didn’t foresee being a problem, but it ended up actually being a huge issue for me is how to find these strings inside modified JavaScript files [00:22:00] because we can find them quite easily in our source code because it’s nice broken into lines. All of the tokens still exist there, but in the magnified files we have to do some configuration hurdles to get it to keep those translation files there. And once you have those translation files, they actually don’t get built in the same way and delivered as PHP translations through, there’s actually JSON files that you also need to deliver to the client site whenever there’s a translation available.

So yeah, translations are a lot more complicated than they used to be. If you have to support JavaScript, which in this day, most of us have to support JavaScript translations. 

Steve: Yeah. Yeah. 

Yeah, so we had some technical hurdles to get over. We actually had to set our mindset a little bit around it too, where it was like our plugins are, our strings are mostly all translated. There might be some like low hanging strings that were missed over the [00:23:00] years. And it was like in our heads we’re like we just need to, we need to get the mechanism in there to translate these and these translations are a little bit AI assisted and, we need to have the workflows built into our pipeline so that these translations happen with every release. And then once we have that, then we can go back and clean up code where there are some strings that may not be translated correctly.

So in our heads it wasn’t like, “Oh, we’ve gotta go through five plugins, fix all the strings.” And no, it was like, “Let’s put the mechanism in place. Things are translated, all the strings, like 90% of the strings are ready to go. Let’s just put the mechanism in place and get the translation files for those. And then we’ll go through.” 

William: And it turns out that once we had put the mechanisms in place, it became much easier to discover where we had missed the string somewhere, because we could, I’m pretty sure I could confidently navigate and read our plugin in [00:24:00] French at this point because French was the language that I chose when I was debugging things.

But if you’re reading the sentence in French and suddenly you see an English word, that’s missing a translation function. And that really did help us to get I wanna say almost all of them, but at very least we have covered 98% of all of the strings in our plugin. 

Steve: Yeah. 

Yeah. Totally.

Cool. 

Accessibility Checker Pro Enhancements

Steve: So let’s move on to Accessibility Checker Pro.

What did we do this year in Accessibility Checker Pro? We expanded the scanning capabilities. We added the ability to scan Post Type Archives and Taxonomy Terms, which we’ve spoken about on the previous change log livestream.

Do you want to speak to that at all, William?

William: Yeah. 

That was a five year desirable feature that took event a long time to implement that feature predated me even working on any of this code. I didn’t know that was a feature that was desirable [00:25:00] at first, but it turns out quite desirable. Steve actually came up with it the way we could solve this under the hood as effectively building our entire plugin is set up around the ethos of Post IDs and Archive Pages do not have Post IDs, which was the real complication here. And Steve had the idea of why can’t we just virtually create these IDs? And as such we do, we just virtually create a Post for every single one of the Archive Terms that wanna be scanned. And we can store our data on the Virtual Post, allowing us to scan every single Archive Page you have on your Site, which includes Custom Post Type Archives, as well as all your Taxonomy Archives, like Categories, Tags, or any Custom Taxonomies that you create that have archives visible. So yeah, all of those Pages are now scanable and you can get results in the same way that you would get results for typical Posts. [00:26:00] They’re reflected in your overall Site Report and if you have the Export Plugin, you can export all those results as well and Filter them to the Individual Archive that needs fixed.

I will say that I discovered that you usually don’t need to scan every single Archive. So, we do have some form of Smart Sampling built in. Because, if you have one Category Archive, it’s probably the same as all the other Category Archives in Terms of its construction. So, you theoretically only need to scan one. But, what we do have is we scan one that it is representative of a maximum number of Posts, so it’ll show Pagination and the minimum number of Posts. Ideally it won’t have Pagination and so we cover at least two, at least three Taxonomies or each three Pages per Taxonomy Type. 

Steve: Yeah.

William: In the Smart Sampling mode, you can of course turn on full sample and you can just scan every single [00:27:00] Page, which is probably what a lot of customers might end up doing, but… 

Steve: Right. 

William: That can take a very long time if you have thousands of Terms. 

Steve: And lots of Custom Post Types. 

William: Yeah. 

Steve: Yeah.

Like William said, five years ago, this was probably, this is probably feature number one that was on our list, and, and it just got kept getting pushed because of the complications around it like William said about, our Archive Pages are Dynamically Generated Pages, they’re generated on the fly basically, and there’s no Post ID, if there’s no Post ID, there’s no Post Meta and the Accessibility Checker requires Post Meta quite a bit.

Us coming up with… us putting our engineering heads together and coming up with a unique way to slot that into the plugin without a complete refactor of the whole plugin was a huge win for us and a huge win for our users. Now that they can get more coverage in their scans and have more assurance that their website is being scanned for [00:28:00] accessibility compliance.

Along with that, William, you wanna talk about the next one? 

William: Performance wins. 

Steve: Before that, there’s a bullet point above that. 

William: Yeah. Yeah.

So, you have a Post Page and a Front Page in most WordPress websites. Previously, we weren’t always scanning them, depending on what the configuration is. Now, we actually go our way to make sure that we do scan your Blog Page, and also your, Front Page, if your Front Page is almost always gonna have an ID. But, your Blog Page may not, if you have not assigned a Static Page to it, and if you had not assigned a Static Page to it, we previously may have missed it, but no, that isn’t the case. We will actually try and scan that page all the time now. Due to the fact that we could, it’s technically an Archive for the Posts and is now discoverable and virtually exists. 

Steve: Yeah. Just like another… it’s not an Archive Page, but kind, but it is 

William: it’s an Archive Page internally.

Steve: Yeah. But, [00:29:00] we can’t capture it as an Archive Page the same way, so we’ve gone the extra step to consider that as well.

Now, there is some other considerations beyond Archive Pages and Main Post and Blog Post Page, and there are other things that we’re looking to add in such as Author Pages.

And was there anything else besides that? 

William: I did previously look into for my own use Element or Templates. Not only can we scan actual things that are considered as Pages, we can probably quite soon start scanning things that are considered as partials, such as Element or Templates, Page Templates for Gutenberg. Any number of individual components that Page builders implement that are available through some form of URL rewrite feasibly, we can create a Virtual Post ID for and scan in a live page type of way. So, no immediate plans on what [00:30:00] we will scan next, but floodgates are ready to open on that one. There’s lots of options of what we could scan. 

Steve: Yeah, totally. Cool.

So like you said, Performance. So, this year…

William: amber did actually just comment in FSE templates. Yeah, exactly. 

Steve: Yeah. Totally soon.

Yeah. Yeah. So Full Site Editing Templates. Yeah, exactly. Those are little pieces that we could probably push through the same mechanism that we did the Archive Page.

And now there is a whole, there’s a bigger picture here too, right? Like we can keep chasing the WordPress rewrite Template part thing, or we could switch how Accessibility Checker works and actually start pulling from direct URLs based off of site map or some kind of scraping of the website.

Yeah, totally.

Performance. This was a big one, but I feel like this was a feature that was implemented under the radar.

William: It was. This was actually [00:31:00] performance of the Full-Site Scanner was looked at partly due to, I don’t wanna say a great many, but a larger than other Issues Type of support request that comes in is to do with the Full-Site Scanner, particularly, how fast it is. As we all know, it isn’t actually very fast in a lot of cases. So, as part of some of those complaints from Users, we looked at how the queries work, how we gather the Posts.

And first off, we actually made it immediately faster by dropping one half of our scanner. We dropped the faster half, we had the two part scanner, we dropped the faster half. So, we’re only left with the slower part. But, that does speed up the scanner generally.

But, in addition to that, there was query optimizations and some caching added that actually does for, it won’t benefit the majority of sites. But for large sites, you’re looking at 5, 6, 7, 10, 20 times faster sites [00:32:00] for very large sites. If you have a site that has a hundred thousand posts on it, the Full-Site scanner will be dramatically faster for you after we made those query optimizations. And, there are definitely more of them to come. 

Steve: Yeah. Yeah. We’re talk about this here in a little bit too, on why we dropped that first half of the scanner when Williams says we dropped the first half of the scanner.

What we’re talking about is there, it used to have two passes. There was a 

William: Yes. 

Steve: Under the hood, it was a PHP scan and then it was a JavaScript scan because we had some rules that were written in PHP and all we had to do was parse HTML for that, and then we had some rules that were written in JavaScript, which actually would pull up the actual Website Page and scan it from the Front-End with the Full Rendered Page.

William: Actually at first, all of the rules were in PHP, aside from, yeah, color contrast. So, we would run the JavaScript scan only for Color Contrast at first, which unfortunately is the [00:33:00] slower half of the scan. 

Steve: Yeah. But more accurate half. 

William: Yes. Dramatically more accurate. That’s why we could not do color contrast in the PHP skin the first half.

Steve: Actually, even going further back when, we talked about Accessibility Checker getting ready to turn five years old. The scan was all initially PHP, and even our Color Contrast was PHP. But, out of the necessity to make it more accurate, we started switching that to JavaScript over time. And like I said here in a little bit, we’re talk a little bit more about that switch to JavaScript. 

Implementing WP-CLI Commands

Steve: But, aside from that William has done a lot to implement to make the plugin much more WP-CLI compliant and, or I don’t know if compliance is the right word, but ready? We’ve been working on a lot of our own commands.

William: Yeah, so selfishly, because I had actually created some commands for my own development purposes, that later on was answered or mentioned [00:34:00] by… Chris had mentioned that a client had asked for some of these WP-CLI commands and I was able to say ” Oh yeah, I’ve been using that already. That’s mine.”

I had to do a bit of cleanup to make it production ready. But now, we have shipped a handful of WP-CLI commands and we have added a couple more over time. Primarily, maybe the most useful one for an average user would be a programmatic way of getting the individual Scan Stats for a Single Page if you had such a need or the Full-Site of scan sets as also if you had such a need. And I can imagine a few people might programmatically wanna grab them rather than having to log into a whole bunch of individual sites and check their numbers.

Steve: Yeah, and things like license key activation, deactivation, adding the license key, things like that. 

Partnerships and Hosting Integrations

Steve: And a lot of that was done in prep with some some of the partnerships that we’ve put together this year with some of our hosting [00:35:00] partners so that they can be able to run CLI commands in their pipelines to be able to activate and deactivate and add license keys to the plugin.

One of our more recent partnerships is with Cloudways and some of these requests came from them as well to be able to do these things.

William: Yeah technically a hosted partnership now can retrieve a key from a customer and then make everything from that point onwards entirely seamless in their platform. They could activate the plugin, install, activate, and trigger scans across some of the pages. 

Steve: Yeah. 

William: All entirely programmatically before a user even has to make it anything other than the purchase to get their key. And actually they could just install free as well. So some of these platforms can now seamlessly get that up and running. 

Steve: We’re doing more to expand Accessibility Checker for hosting companies as well, so that we can make it available to their client base and make integrating [00:36:00] into those hosting plans more seamlessly.

Hosting companies reach out to us. We’ll get you an integration and we’re, we’ll get up and work it. 

Accessibility Checker Pro Features

Steve: Man, we’re running long on time and we got a lot to get through, so we’re gonna… I’m gonna rapid fire some more things here.

On Accessibility Checker Pro workflow we, I’m gonna run through some of these real quick.

We added Filtering by Post Status, so whether it’s a Draft or Published, etc. 

William: And this was a highly requested feature. People don’t wanna scan their Drafts because they don’t see any, they might have 10,000 drafts. 

Steve: Yeah. 

William: They’re never gonna be published. 

Steve: Totally. So you can Filter those out.

You can actually see the Post Status inside the Open Issues Table in Accessibility Checker Pro now.

We added Landmark Selectors to the Issues Table as well. We’re talking about this. We added Landmarks and free as well. We’re talking about that. Allowing users to pinpoint the specific location of landmarks. So, we’ve just surfaced that inside of the Open [00:37:00] Issues in the Pro Plugin.

We improved rule descriptions and Metadata to provide better contacts on accessibility issues. This was a huge undertaking that Amber took to rewrite some of these descriptions and how to fix it.

We’ve added severity to issues and we’ve added some kind of intelligent severity sorting to our issues and the UI to help you surface not only the issues with the… ’cause it used to Sort By Errors and Warnings and then a secondary search on the Issue Count. So now, it, it is extended to sort by Severity and then Issue Count. So, what we’re trying to do inside the plugin is always expose to you what you can action on and get the most results from.

What else? Let’s see. And then, like I said, the Severity. So, that’s a lot of [00:38:00] the kind of a lot of the big features that we’ve added to pro. Of course, we are always squashing bugs and fixing other things in that regard. 

Accessibility Checker Free Updates

Steve: But let’s move on to Accessibility Checker Free. We call it Core sometimes, but the plugin that you can get from WordPress.org.

You wanna run through this first one, William?

William: Yeah. We added Rescan and Clear Issues Buttons, and these are just nice to have user facing features. These are things that we do programmatically quite often by going into the database, clear issues. No longer do we have to do that as developers, but being able to clear issues, sometimes fixes edge case bugs. If someone changes Post Types or does unusual things disabled to plug in for a while, turn it back on. So “Clean Issues”, it just resets the Post and then you can just click to Rescan and you can immediately get fresh results. 

Steve: Yeah. 

William: You can also use that, if you haven’t thoroughly tested this with a lot of different [00:39:00] builders, but if you use a Front-End Page Builder, you now have a Rescan Button on the Front-End that you can then scan as you change your content. It works with some builders. I haven’t tested all of them. 

Steve: Yeah. 

William: If you have a builder that it doesn’t work on, let us know. 

Steve: Yep. Yeah. We know that it works really well with Elementor. We are… 

William: Beaver Builder works with most, for the most part. 

Steve: We currently are working with Etch to get Accessibility Checker working fully with the Etch website builder. And we’re looking forward to implementing that. And if anybody, any other builders have problems, feel free to reach out to us. And we’ll get those fixed. 

William: And as another nice UI feature, we no longer overlap icons on the Front-End. So, if you’re using the Front-End Highlighter and an issue has two different Warnings or one warningand one Error assigned to it, those icons will no longer overlap each other. They will be stacked neatly side by side, so you can click on each one individually and see the relevant information [00:40:00] about that specific issue. 

Steve: Yeah. Where before if you had multiple stacked right on top of each other, you had to use the arrows, the next and previous areas to get to ’em.

William: And sometimes those issues might not be next to each other in the order stack so you would jump up and down on the page. 

Steve: Yep. Cool.

New Smarter Rules. We are always trying to refine our rules to make them better. Amber’s always opening tickets for us to, with new ideas on how to make the rules smarter and more intelligent and help with her own audits of things.

This first one… 

William: yeah, so it’s a shame that Daniel isn’t still here. He did say he had to drop off, but this was what the caller had with Daniel a few weeks ago, was about another improvement we made to the Video Transcript Detection.

If videos were not, or the transcripts were not directly adjacent in terms of the markup, there might have been cases where it was missed. And that was the case on Daniel’s website. That is now fixed, and the detection of video transcripts [00:41:00] should be far more reliable for everyone based on that change. It was already quite reliable. There was just some edge cases that meant it may not work. 

Steve: Right.

And landmarks. We’ve talked about this a little bit in on when we’re talking about pro, but we have added Landmark Location Feature to show exactly where landmarks are in the DOM. That’s in the Front-End Highlighter it actually will list you what the Landmark Location is in the Details Tab on a Post or in the Open Issues from the Pro Plugin. You can click on that and it’ll open it up in the Front-End Highlighter and highlight that Landmark Location. So just doing more to try to show you where Issues are, and we actually have plans to expand that, to be able to start segregating out Issues based on which User Role should be seeing which issues. Basically an Editor probably doesn’t need to see in the Header and Footer. Those are Global Issues.

William: They may wanna see them still, but they probably can’t fix [00:42:00] them. 

Steve: Action on them. 

William: Position to fix them. So maybe you might wanna show them only Actionable Issues, in which case an Editor might only see Issues that are directly inside the Content Area or the Main Tag. 

Steve: Yeah. So cool.

Then , Links. We improved checks for Anchor Exists Missing Title Attribute and New Window Warnings. Was this one you worked on, William? 

William: I think I’ve touched most of these rule tweaks over the year. I cannot remember which ones exactly. However, a lot of these were improved from… something we’re gonna talk about in a minute. The JS conversion. A lot of these rules got dramatic improved. 

Steve: Yeah. 

William: Accuracy due to some switchovers. Including the next one that’s in this list for the Underlined Text as well. And I will also put Amber a bit on the spot here and call out that there might also be a Naked Links rule. 

Steve: Yeah.

William: Soon pending some [00:43:00] documentation work. 

Steve: Yeah, that’s my favorite one. Naked links.

William: That, that’s actually quite a common problem that we should be flagging and detecting from. 

Steve: What is a Naked Link? 

William: It’s when you’re just copy and paste the link directly from your address bar and it might contain all those letters and numbers that they use for tracking, or it might be nested 16 levels deep, and for a screen reader, every one of those characters is gonna be read out and that just is a horrible experience for someone who might not be visually impaired. 

Steve: Yeah. Yeah, we are. So we have implemented the Naked Links rule and this is a little bit how the workflow works, right? And a recommendation for a rule gets added to either, our ideas board or as an Issue in GitHub and then sometimes William or I are have a minute and we’re like, “Ah, we’ll pick this one up.” And then we, “oh, that was easier.” 

William: It never takes just a minute. 

Steve: This one was more complex than that, right? And then we get it, and [00:44:00] then we assign it to Amber and we wait for documentation, and once we get documentation, then we’ve released it out to the world for you guys.

Because releasing a rule without documentation on what does this mean and how do I fix it, and what are the implications of this, is not a great user experience. But not only that, like when you get the idea for we try to compare like we, we use Axe-core in our plugin, but an extremely extended version of it. We hook into it, we change it, we group rules together, we don’t use some of their rules, we use some of our completely own custom rules.

And in this case William the recommendations that came from Amber about what is a Naked Link was far more verbose than what say Axe-core does to detect those.

You good? 

William: Oh, I think my internet is, getting a bit off. 

Steve: Oh, okay. Okay. Oh

Oh, it is a bit off. Okay. So William is now frozen, so I will talk. 

William: There’s something yeah. So you talk, gimme one second. 

Steve: All right. [00:45:00] So William goes and kicks his kids off of the internet. I’ll talk about Naked Links.

That’s what he’s doing.

Anyway, whether it has a protocol on it or doesn’t have a protocol on it, making those decisions on what actually constitutes a Naked Link… I think what we’ve come up with goes pretty far to making it a very usable rule that doesn’t create a ton of noise for the end user.

That’s a little bit of a sneak peek on a rule to come.

But to that, William, since we’re talking about rules and JavaScript and Axe, can you talk a little bit about why we decided to finally jump and just migrate everything over to JavaScript scanning? I can’t hear you. You mute it? Yeah.

William: Lemme know if you can hear me. Oh, maybe. Is that better? 

Steve: You’re, no. Yeah, there you go. 

I think you’re good. Try to talk. 

William: Yeah, I think I’m back. I just disabled Netflix.[00:46:00] 

Steve: Oh no, he’s frozen again. 

William: Oh, 

Steve: Yeah. You’re still cutting out a little bit there, bud.

William: There you go. You’re back. I’m back for one second, but I’m probably gonna disconnect again in a second. I’m gonna… 

Steve: Yeah. Yeah. 

William: I’m gonna have to shut down some stuff on their end.

Steve: You on the router? Cutting them out. 

William: Yeah. I’m not cutting out the right things apparently. 

Steve: That’s right. 

JavaScript Scanning Migration

Steve: We used to scan in PHP. We migrated to a hybrid approach. Then this year we went full in, we did a major sprint to get these all converted over to what we call JavaScript rules. And what we mean by that is these, this is scanning code and logic that can be run on the actual rendered page. So we can pull up a [00:47:00] page, we can insert our scanner into it, we can scan the page and get vastly more accurate results than we ever could with just straight up PHP parsing.

William: Yeah. 

The perfect example probably is the Color Contrast.

Steve: Yeah. 

William: Is the first one that was transitioned because you have to read all of the JavaScript, all of the CSS and all of the HTML to try and determine what color an object might be inside the DOM, and that might actually be influenced by external JavaScript that runs that you will never really be able to know in a PHP scan. So unless you render the Page, you won’t know the actual color, and you may also not understand what the background color would be to do an actual comparison. Once you render the Page, all of those things with, a guaranteed for certain, there’s no question in what color is on top of what color if you actually render the Page.

There’s a lot of other rules, like the Underline Text [00:48:00] rule we briefly mentioned earlier on. There’s a bunch of different ways you can underline your text. You can literally just use text decoration, a style row, but you can also use Border Bottom on a row, and we cannot detect that in PHP, but static analysis, we cannot determine what a thing looks like.

However, with JavaScript we can see that and it is literally the difference between making an educated guess and actually being able to see what the thing is gonna look like to a user on their website. 

Steve: Yep. 

William: There’s a huge difference between static scan and a live Page scan. The downside of the Live Page Scan is that it takes up more resources and it’s a bit slower because of the nature of how you have to render the Page, but it is millions of times more accurate. 

Steve: Yeah, and you need to leave the Page open and let it run because we need to use your browser to de determine these things. Whereas when we were doing the PHP, the [00:49:00] static analysis, we didn’t need that because we actually were not rendering the Page. So it does require a little bit more resources and a little bit more complexity to do what it does, but this is actually what makes Accessibility Checker different than almost any other scanner. This is what actually brings like enterprise SaaS Accessibility Scanning that cost a fortune. This is what actually we’re doing to take that and bottle it into a WordPress product and bring it to the vast majority of users that don’t have the resources or don’t want to pay for those super expensive accessibility enterprise accessibility tools. 

William: A lot of those super expensive tools are just running Axe-core right out of the box. They’re not doing any customization or any tweaking.

I was quite surprised that with our bucket of, however many rules we have, we only actually take direct verbatim from Axe-core, a [00:50:00] handful, maybe five or six of those rules. And the rest of these custom rules are extensions of Axe-core rules, or some of them are very WordPress specific rules.

We’re not just gonna give you generic answers the way some of these, like Online Scan Tools are gonna gonna manage. We’re literally going to interpret the results of the scan and provide only the valuable items. As far as we deem. We might not have be pulling out all of the valuable items as of yet from Axe-core. Over time we will be adding more rules, more custom rules, and more things that can be scanned against those rules. 

Steve: Yeah ’cause we’re not just looking to build like a base level compliance scanner. We’re actually looking to build a Full Featured Auditing Tool to help you audit a website and we expose what we call Warnings, which are actually things that were prompting you as an auditor or a just a web [00:51:00] developer or a website creator, a content creator. We’re actually prompting you to say, “Hey, we can’t programmatically tell you with certainty that this is an issue, but we think it is.” We want you to look at it. We’re doing a lot to help come alongside you and to assist in that audit of these websites to make ’em as accessible as possible.

Along with that conversion, William found the need to really make sure that our, if we’re writing and extending so much of Axe-core, we need to ensure that what we’re doing is right and that we don’t have any regressions when we change other rules.

William: Yes. So before I say how we did this, let me tell you how we used to do this. We had the WordPress website, it had the launch bunch of content on that website, and we would update the plugin on that website. We would visit the website, scan the page, and we would see what it finds, what it doesn’t. And we had lists of things that we expect should pass and things that shouldn’t. And that was all live content on a live [00:52:00] website that we had access to. And that was how we previously were testing this.

Automated Testing with AI

William: Now we have almost every single rule or every rule that we transitioned in the most recent batch, I think it’s probably 90, 95% of all the rules that we run in our scanner now have fully automated JS tests. This was an excellent use of AI we discovered, because we had the content for most of these rules elsewhere, and we were able to tell the AI, “Here’s the content we have. Generate these tests.” That automate verification that these things pass or these things fail and everything we make a change to a rule. These tests get run and it tells us whether we have broken a rule or improve the rule. And if someone comes to us with an issue that these rules do not detect, we just add it to these unit tests and we can change our rule or change our tests till we get it to pass or fail.

And not like we legitimately wanna fix exactly what’s reported. So we [00:53:00] take the markup snippet directly from these problematic websites and verify them against their actual rule. The way JS works is it literally spins up and tests against this exact markup so we have a pretty high degree of certainty that if we fix it in our tests is fixed on someone’s website.

Steve: Yeah. This is a living and growing test suite, like William said, and we’re continually adding to it. And we don’t remove these. It just builds up. We’ve got thousands of code snippets that get tested when these rules run.

We can even do like test driven development in respects to that where if say Amber says we should do this rule, we should do this check. We should check for this certain thing, and this is what I think would be a failure, or this is what I think would be a pass. We can actually take those. Put ’em into the test first before we even write the check or the rule. And we can actually take that and then use AI to prompt it to say, [00:54:00] “Hey, can you try to make a rule and a check to go along with this?”

William: It’s sometimes hit and miss. 

Steve: Yeah. 

William: Actually do think the AI works better the other direction where we write some of the codes… we start off with basic unit tests and then we ask it to look at the code we’ve written and extend the unit test to make sure that things we change, don’t break something or, to highlight things that the AI has actually been surprisingly good identifying gaps in the tests that we have. So we might have a series of 10 tests and we can prompt the AI and the AI might come back and say, “Here’s 15 edge cases that you didn’t consider.” And we just instantly put them in and we run the tests, and sure enough, some of them might pass, some of them might fail, some of them might be incorrect. And we need to continue tweaking the rule to make sure that the answers we get in the end from the tests are exactly what we expect. 

Steve: Yeah. And as far as regressions, like we have some rules that actually we’ll share [00:55:00] helper code across multiple rules. And if you modify that or you modify a certain rule, you can actually, you have a lot of checks and balances there to ensure there’s no regression that… 

William: Yeah, like for example, if we modify how we handle aria-hidden 

Steve: Yeah.

William: In terms of visible content, if we modify the helper that we use for that, that could break a whole bunch of things because that is actually a base requirement for a lot of screen reader back rules. If it’s already hidden, the screen reader won’t ever see it and that might be a problem. We might actually one flag that it’s hidden and tell you need to un hide this. Or if it is hidden in its problematic content, maybe we don’t need to tell you that’s an Issue because the screen reader can’t see it. So it is important that works. 

Steve: Yeah. 

William: We need to make sure that our helper does not get broken. 

Steve: Yep.

That’s a rundown on what we are doing on our end to ensure accuracy, to make sure that your issues are actual issues, not false positives.

We [00:56:00] are continuing to bo build a huge library of tests to ensure that with every update that that all of our rules continue to work and that we don’t create any downstream problems.

We are running short of time. I think it’s time for another lightning round to finish up. 

William: You go later on round than I’ll maybe enable.

I will turn Netflix back on. 

Steve: Yeah, so we did some Dashboard Tools in the plugin. We integrated Accessibility Checker into the Site Health. We’re all adding some more information in into there to not only help you see that there… so now in the Site Health that actually flag if you have accessibility issues on your website and it flags, the different Warnings that come with the Site Health. So, we’re trying to expose Accessibility Checker there. When you run Site Health, you can see if there’s accessibility Issues that need to be addressed on your website.

We added an Admin Toolbar with quick links. Now this is the most easy thing, but it’s [00:57:00] one of William and my favorite things is now having just a Toolbar with links in it that we can quickly jump to our sentence pages.

William: Yep. Go straight to the Site Health Page. No longer having to double click. Or the fixes Page specifically? 

Steve: Yeah, the Fixes Page. We’re just trying to make things more accessible and easier to navigate to.

We have some add-ons. We did some work on add-ons as well this year.

We have our Export Add-on. Our Export Add-on now includes a WCAG levels and the Severity level in the export. We are actually looking at adding some more features to the export to be able to export issues at the Post level. That is an upcoming feature that we’re looking at for the Exporter Plugin.

Then in our Audit History Plugin we added a filter to customize which user capabilities are allowed to view the Audit History Page.

William: Yep. This one also came from a customer request.

[00:58:00] So you know, anyone who has any issues or any desirable features, they have sent them our way because we almost always try to implement the things that you request because we can only come up with so many great ideas on our own. 

Steve: Yep. 

William: You always come up with some more.

Steve: Yep. Those are some of the top things, and like I said, a whole litany of bugs that have been squashed throughout the years, but we do not have time to go through each one of those.

But, just these are all the things that we’re doing to improve the Accessibility Checker to make it easier for you to use and to make it more accurate and to help you make your website as accessible as possible.

Upcoming Features and Plans

Steve: So, what are we doing next?

William: Next it’s Christmas time. 

Steve: It’s Christmas. 

William: So, we’re taking a break, but then yes.

Then after the break we are doing Email Reports. And not just email reports. These reports will also provide access to some new information that you have to jump through some loops to find, such as [00:59:00] identifying the top five pages on your website with Issues. So yeah, these reports will be available to everyone, I want to say, not just paid users. 

Steve: Yep. 

William: So yeah, more to come on that. 

Steve: Yeah. This is actually a feature that’s in the works right now. It’s not even part of the 2026 roadmap, but it’s a part of this year’s roadmap. But as you said, the year’s winding down and Equalize Digital…. we like to treat ourselves and our team to a nice week off at the end of the year, just as a little thank you for all the hard work and to have a… 

William: Forcing me to spend time with my family. 

Steve: Forcing me to spend time with your family.

And, so yeah, so basically what it is gonna be the free plugin. You’re gonna be able to connect it with your my dot equalize, what we call it, my dot, so it’s your dashboard on my.equalizedigital.com. You will be able to connect your free plugin with the dashboard if you don’t have [01:00:00] an account. If you got the plugin from WordPress.org, you can create an account on my.equalizedigital.com and make that connection. And once that’s connected, we will get your Summary Report at certain intervals, and we will send you emails about the Accessibility Status of your website, a little report on, and William said, some new features in that report that aren’t currently in the plugin, where we’re identifying the top pages that need to be addressed so that you can get that right into your inbox. You can see what pages have problems with, and you can action on those right away.

And there is a lot that goes along with that as well. We have thoughts and ideas and these are just ideas about, we can expose those reports inside of your my.equalizedigital.com dashboard, and we can start to do some, a little more historical, we can expand the Audit History Plugin that we have, we can start doing that at an even bigger [01:01:00] level and expose exposure from some of that.

William: I also wanna mention that again, Audit history is currently only available and higher to your licenses and with the addition of the email reports, that is actually going to introduce at least the currently versus last access to History of Issues for free users as well. So this is not just a, all the fanciness is not gonna be only for paid users. Free users will absolutely get a lot of benefit from this feature being available as well. 

Steve: Right? Yep.

What it also does is it allows you to collect the accessibility status of multiple websites into one dashboard on my.equalizedigital.com. 

William: Potentially just one email as well monthly.

Steve: Yeah, so a lot in the works there.

In December, Equalize Digital goes into kind of planning mode a little bit and we start to plan out what we’re [01:02:00] going to work on for the next year and we are currently in the throes of that this week and we’re doing a lot to plan new features for the next year.

I’m super excited to share what those are with you all in future live streams. Once we all get a unified decision on what those are and we start there. 

William: I let slip of one that we might not make the roadmap, but I’m absolutely going to do here, which is some more advanced rules. You might wanna look at whether your tabs are correct, as opposed to just do tabs exist on the page, or they’re correctly. 

Steve: Component Level Accessibility. 

William: Might be a set of rules in the future.

There might be some other experimental rules. 

Steve: We don’t wanna give these ideas all away. Our competitors are watching and they’re gonna. 

William: Maybe. 

Steve: They’re gonna steal all of our ideas. No. It’s fine.

But no, we are always thinking about these things, like William said, component level scanning. We can identify a component. Why don’t we just scan the whole component to make sure it’s [01:03:00] compliant. Tabs are hard, they’re hard to make accessible, so why don’t… 

William: Hard to make accessible from a development standpoint, but actually quite easy to recognize when they’re wrong from a programmatic standpoint. 

Steve: Yeah, totally. 

William: Let’s do that.

Year-End Reflections and Thank You

Steve: Cool. Do you have any closing thoughts for 2025, William? 

William: It is been a busy year. Done a lot more than we had time to go through here. Made a lot of development improvements in the plugin consistently, which, is reaping the benefits of how quick we can get these features out now. And, hopefully next year is a year full of features now that we’ve done a lot of that cleanup.

Steve: Yeah. Yeah. So my kind of 2025 recap is that yes, busy is a word I would cap the year off with a whirlwind year of busyness and that just shows what Equalize Digital is doing, and what we’re putting into this product to make it useful for the our users and our commitment to pushing accessibility [01:04:00] forward from technical perspective of identifying and fixing issues and continuing on with that and what other areas can we help in this audit and remediation of accessibility.

And I just want to end by saying, any listeners or customers or users of Accessibility Checker, thank you. Thank you for trying out the plugin. If you haven’t used it, please grab it. It’s free. It’s extremely full featured free plugin. None of our rules are gated behind a paywall.

All of our rules. 

William: You get all of the scan capability for every Post. 

Steve: Yeah. 

William: The same as everyone else. 

Steve: So I just wanna say thank you anybody that’s tried out to plugin all the people that we interact with feel free to reach out to us. We’re all, we’re happy to give advice, we’re happy to look into bugs and just wanna wish everybody a Happy New Year and we look forward to getting back to it next year.

William: I think we will see you on, I said the 7th of [01:05:00] January. 

Steve: Yeah. 

William: The eighth maybe. Yeah, the week after we’re back. 

Steve: Yep. Next live stream will be probably around the first week of the year. So look for us then. Thanks for joining us.